On 2006-10-21 21:19:22 -0400, Jeff Garland <jeff@crystalclearsoftware.com> 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