Re: glr.c: Token definitions

[Akim Demaille]

>>> "Joel" == Joel E Denny <address@hidden> writes:

 > On Mon, 19 Sep 2005, Akim Demaille wrote:
 >> I propose that newer skeletons define the tokens only using enums, not
 >> #defines in addition.  That's already the case for C++, but I propose
 >> that we do the same for glr.c.  In practice, it only means to apply
 >> the following patch.  Any objection?

 > I've been hoping this would happen.  I have a C++ project that can
 > encapsulate either the yacc or GLR global symbols into namespaces.  It's
 > easy to encapsulate yytokentype, but these redundant #define's remain as
 > global namespace pollution.

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.