On Sep 30, 2004, at 9:44 AM, Stefan Seefeld wrote:
put out a "request for libraries" of some sort. Things that come to mind quickly: a unification algorithm (for template instantiation/partial ordering), a tree manipulation/rewriting library (for AST transformations), and a flexible symbol table library.
in what sense do you use the term 'library' here ? While I fully agree that is is very useful to approach this big task by splitting it into modules, I doubt it is feasible or even useful to use these entities as separate deployment units.
In the real sense of a library. I'd find it strange if any of these libraries ended up useless; I know I've needed a symbol table on more than one occasion. Whether they're feasible or not... well, we've got bright developers here, right? :)
However, I think we can come up with a high level design that respects the data flow requirements (the complex interactions between the parser and the symbol lookup table notably) yet is flexible enough to let the individual modules evolve in parallel.
I think so, too. The problem with parsers (and compilers in general) is that they consist of a whole lot of really simple things made insanely hard because of tricky language semantics. Parsers don't get optimized because it's then hard to pick out the semantics and rewrite the underlying algorithm (even if both the new and old algorithms are simple). I'm trying to pick out core libraries (or even just separate modules) to force us to keep the language rules independent. Doug