Re: Fwd: Are Google summer of code 2006 ideas still available?

[Akim Demaille]

>>> "MC" == Matt Cupp <address@hidden> writes:

 > Yes, it was something along those lines.  I have several files that I
 > currently use the same parser for and the code is very big and ugly
 > looking.  I would prefer to be able to break the parsers up based on
 > the type of file they are going to parse.  Problem is they use a lot
 > of the same basic types inside each file type and I don't want them
 > duplicated in multiple files.

Yes, that's why it is much more include-like than import-like.  Still,
I see this work as something to be done in two phases:

- first, design a true AST for Bison
  something to represent the grammar we read.  We have more or less
  something like this in Bison, but much work is done on it, it's not
  "faithful" to the entry, it's already heavily modified.

  Once this AST done, then be ready to process it for real, applying
  all the transformations we want (elimination of useless things,
  elimination of symbolic names, elimination of mid-rule actions, fuse
  the %unions, run semantic checks etc.).

  Maybe we can think about other transformations, such as inlining
  injection rules (see TODO).

- once we have this AST, it should be reasonably straightforward to
  implement the fusion of ASTs, hence to have a nice import
  implementation.

This AST should also be a tremendous help to debug: it should be able
to print intermediate states for debugging the transformations.

I wish Bison was in C++...  Joel, WDYT?  This kind of changes would
really benefit from moving to some simple, standard, portable, C++.
Yeah, I know Paul, there's no such thing as portability, just sweat :)