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