On 3/14/2018 2:26 PM, Peter Sommerlad wrote:
> Gaby and Bjarne's paper's representation ignores macros (the
> preprocessor in total) and confesses that it is unusable for useful
> refactoring and similar tools.
It's a research paper, not a shipping refactoring tool. Some tools have
and do use it.

Separately: In English "confesses" often implies that something bad has
been done. I suspect you didn't mean that. A good research paper
documents its assumptions and limitations.

> Eliminating replaceable macros is only
> half-way to make it useful for IDEs. There are practical (and since 2005
> also theoretical (by Alejandra Garrido's PhD thesis) representations of
> unpreprocessed code that allow refactoring tooling. The first might not
> be complete and always correct but works (in contrast to the theoretical).
>
> just my CHF 0.02.
>
> Peter.
>
> Bjarne Stroustrup wrote:
>> When considering how to represent C++, please note some previous work:
>>
>> Gabriel Dos Reis and Bjarne Stroustrup: A Principled, Complete, and
>> Efficient Representation of C++
>> <http://www.stroustrup.com/gdr-bs-macis09.pdf>. Journal of Mathematics
>> in Computer Science Volume 5, Issue 3 (2011), Page 335-356
>> doi:10.1007/s11786-011-0094-1
>> <http://www.springerlink.com/openurl.asp?genre=article&id=doi:10.1007/s11786-011-0094-1>.
>> Special issue on Polynomial System Solving, System and Control, and
>> Software Science.
>>
>> https://github.com/GabrielDosReis/ipr
>>
>> Something very similar to that is the representation of modules in the
>> Microsoft implementation.
>>
>>
>> On 3/14/2018 11:55 AM, Boris Kolpackov wrote:
>>> Corentin<corentin.jabot_at_[hidden]> writes:
>>>
>>>> I propose that conforming compilers must generate when compiling a module
>>>> interface both:
>>>> * A non portable, implementation-defined module interface file that may be
>>>> digested by that specific compiler (like it is the case today, as per the
>>>> module TS)
>>>> * A defined, non compiler specific"universal" module interface
>>>> representation.
>>> Another alternative would be to define an API (naturally in C++ -- it's
>>> about time we stopped using other languages for implementing our tools)
>>> that can be used to query the compiler-specific binary module interface
>>> (BMI) files. Each compiler vendor will then provide an implementation
>>> of this API for their format.
>>>
>>>
>>>> Libraries could then be distributed with those modules representations
>>>> [...]
>>> Distributing anything generated opens a can of worms. For example, does
>>> it mean we check-in these representations into VCS since these days this
>>> is the way things are often"distributed"?
>>>
>>>
>>>> For package managers, it could provide a mean to enforce semver at the API
>>>> level (aka that, the dependent project will still build when the source
>>>> dependency is updated, as long as they don't depend anything else than the
>>>> formally describe API).
>>> Yes, having a formal API compatibility verification would be very nice
>>> indeed.
>>>
>>> Boris
>>> _______________________________________________
>>> Tooling mailing list
>>> Tooling_at_[hidden]
>>> http://www.open-std.org/mailman/listinfo/tooling
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling