Re: glr.c: Token definitions

[Joel E. Denny]

On Mon, 19 Sep 2005, Akim Demaille wrote:

> I agree.  In fact I'm toying with a C++ wrapper around the glr.c
> parser.  It raised a few issues with the lalr1.cc parser that I'd like
> to sort out so that glr.cc can be a drop-in replacement of lalr1.cc.
> It's in very primitive state, but it's very doable.  But first of all,
> I'd like to clean up (again!) the lalr1.cc parser: there are a couple
> of bad things, including the fact that these tokens are defined in the
> top level namespace instead of instead the parser class...  And many
> other similar details.

It will be great when you have all this fully implemented and documented.
I might drop my own project if your skeletons prove easier to use and more
stable.

My approach has been to add new code to the user's bison spec (and flex
spec), and then use sed to modify the generated parser (and scanner) to
eliminate global namespace pollution and create a parser class.  Starting
with bison 2.0, I believe my approach has no need to determine whether the
user has declared %glr-parser.  It works fine regardless.

The advantage of my approach is that I don't have to write new skeletons.
Essentially, I can reuse the yacc and glr skeletons.  As they evolve, I
have very little work to do to take advantage of and stay compatible with
their improvements.

There are two disadvantages.  The biggest disadvantage is that building
the scanner and parser now requires these additional compilation phases.
As a result, finding parser and scanner spec errors by line number is a
bit annoying.  It would be nice if bison and flex accepted #line
directives. Secondly, I believe new skeletons likely permit a cleaner
design than my tweaks to the old skeletons.

Joel