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. 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

-- 
Prof. Peter Sommerlad
Institute for Software: Better Software - Simple, Faster!
HSR Hochschule für Technik Rapperswil
Oberseestr 10, Postfach 1475, CH-8640 Rapperswil
http://ifs.hsr.ch http://cevelop.com http://linticator.com
tel:+41 55 222 49 84 == mobile:+41 79 432 23 32
fax:+41 55 222 46 29 == mailto:peter.sommerlad_at_[hidden]