Re: Enum for token '0', EOF

[Akim Demaille]

Le 9 juil. 06 à 17:17, Joel E. Denny a écrit :

> On Sun, 9 Jul 2006, Akim Demaille wrote:
>
> > A friend of mine was using END in his grammars in a very specific
> > place (he was making error recovery right before END), that's why
> > I didn't disable it.  Sure, it's wrong to play with it, but quickly
> > enough you have a grammar that generates an empty language if you
> > play too hard, so I didn't care about adding a safety net.
>
> That's fine.  My biggest concern is %type, %destructor, and % 
> printer for
> the end token.  For yacc.c, %destructor isn't normally invoked for  
> the end
> token when it appears in the generated rule 0.  However, for glr.c,  
> it is.
> We'd need to make this consistent if we're going to allow % 
> destructor and
> %type, I think.  Is there any reason to allow it?

I can't think of any, besides being consistant.  After all, *I*
can't find a use, but maybe someone can.  I'd like to see its
destructor called, just as in glr.

As a matter of fact, I have considered adding a BOF in complement of
EOF: it seems that this token would allow to clean some minor details
such as the initial yylval and yylloc.  It also allows to have a
full definition of state 0: BOF is its accessing symbol.  I never
went to the bottom of this, it might be dumb :)

> I'm also working on the per-type and default %destructor and %printer.

For the records, I originally refrained from using per type destructor
and printer, because I don't like the explicit handling of the union
field name.  But I agree it would dramatically simplify today's uses.

> I'm trying to figure out if they should be used for the end token.   
> If the
> answer to the above question is no, the answer to this one is easy.

Honestly, as an answer to your question, another question: is there a  
reason
*not* to allow it.  I didn't see any.

> > > > but I need to signal it in my hand written tokenizer(and it is  
> > > > messy to
> > > > cast
> > > > 0 to the yytokentype enum).
> > >
> > > I'm guessing this feature was originally intended for no more  
> > > than just
> > > that (and giving the end token a user-friendly string alias).
> >
> > No it was not.  The original motivation was truly to provide a string
> > alias while sticking to the existing interface for the other tokens.
>
> Ok, but I guess you don't object to either usage?

I'm not sure what you are referring to.  The use of END in the
rules themselves?  I don't remember how my friend used it, but it
seemed smart, so I'd say I don't object.