Re: [boost] modules status (was [Summer of Code] An overview of Boost participation inGSoC 2006)

From: Lally Singh (lally.singh_at_[hidden])
Date: 2006-10-26 19:46:00

On 2006-10-21 21:19:22 -0400, Jeff Garland 
<jeff_at_[hidden]> said:

> 
>> the Wave preprocessor. This proved to be very helpful. We still
>> continue discussions with Lally until now, and it's a good thing!
>> The project continued even after SoC. I'm quite satisfied with the
>> results now.
> 
> You guys might be interested to know that that the committee voted this 
> week to create a TR for modules -- essentially removing it from C++0x. 
> The major problem holding the feature back was the lack of an 
> implementation.  By creating the TR, the pursuit of the feature will 
> continue, but an implementation is essential.  Couple questions.  
> What's the status of things?  Any thought of moving over to gcc and 
> implementing it there?

As a recap for anyone new to the whole project, I was the Boost SoC 
student working on mfront, a preprocessor that took in Modular C++ and 
converted it back to C++ for final compilation.  It used Wave as a 
preprocessor, and Spirit as a parsing library, with a slightly modified 
version of the Hannibal C++ grammar.  The grammar is far from complete, 
but parses a good amount of C++.

Modular C++ allowed constructs such as this:
> // File_1.cpp:
> export Lib { // Module definition header.
>              // Must precede all declarations.
>   import std;
> public:
>   struct S {
>     S() { std::cout << “S()\n”; }
>   };
> } // End of module definition (last token).
> 
> // File_2.cpp:
> import Lib;
> int main() {
>   Lib::S s;
> }

It doesn't have a full C++ grammar, nor does it maintain a symbol 
table.  Also, it outputs C++, which prevents it from doing any language 
transformations that require changes in C++ semantics (without 
re-implementing parts of C+++).

Currently, it parses and transforms the base Modular C++ language, 
along with a module partitions and embedded modules.  It can't do the 
changes in name lookup required, nor does it do some of the 'extras' 
that weren't part of the core language (e.g. a program module, module 
startup/shutdown methods, etc.) --- those were left as post v1.0 
features.

It works by preprocessing its input, transforming the text, and then 
emitting 3 things:
- a source file, to pass into the C++ compiler
- a header file
- a .map file.

The latter two are used for conversion.  The .map file declares what 
modules are defined in which files.  The header files are #included by 
other source files importing the current module.

It currently works on Mac OS X, but it's just plain C++ with Boost on 
it.  It compiles on Win32 out of the box.  It just needs configuration 
files written for setting up #include paths, and #defines relevant for 
the platform.  I'm working on Win32 right now, Linux is next.  The 
prioritization order for that work's based the order of which systems 
are available to me at which time.

 As for implementation under GCC instead of as a preprocessor, I
think that effort spent in extending the grammar (hannibal) to cover
more C++ would have more immediate benefits:
- A publically available C++ grammar!
- mfront could then become a general testing tool for experimental C++ 
features.

Of course, that'd require we have mfront build a symbol table too, but 
that'd be just as useful as the grammar itself.

The transform engine in mfront is pretty generic, and forms a good 
basis for experimenting with new C++ features, as long as they can be 
transformed back into normal C++.  IMHO they're a lot easier (full C++, 
easy access to the input text, only have to output normal C++ text 
instead of gcc trees) than implementing the equivalent in gcc.

Of course, if changing the semantics of C++ is desired, then another 
solution will be necessary -- mfront would have to translate to C, with 
the semantics of C++ re-implemented.  At that point, modifying an 
existing compiler's preferable.

-- 
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech