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++. Journal of Mathematics in Computer Science Volume 5, Issue 3 (2011), Page 335-356 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@gmail.com> 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@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/tooling