Re: [PATCH] Factor %FLAG at scan level.

[Akim Demaille]

Le 9 avr. 09 à 06:48, Joel E. Denny a écrit :

> > BTW, I would prefer api.trace ove api.debug for %debug.  No big deal.
> > And then, maybe %api.debug to be what I called %api.assert.
>
> Are you intending to write api.debug and api.trace?  Or do you mean
> parse.debug and parse.trace as above?
> I like both trace and assert better than debug, which is very vague.

So let's go for parse.assert and parse.trace.


> > > I would prefer:
> > >
> > > api.lex-symbol
> >
> > I really am not happy with "lex-symbol", but if you can't do  
> > better, I
> > certainly can't :)
>
> Other than the new prefix, I have nothing so far.

Or maybe we should use the value, like you did for the api.  As you  
noted, it doesn't make sense with other api related things, such as  
%pure.  %define lex.api symbol|pure|global?  Or api.lex.


> > So maybe it should be a namespace per se.  People (I know some) would
> > certainly appreciate more control over the types used here.
> > It's already using %define filename_type to be told... the type of  
> > the
> > filename field, and a hidden control to specify whether we want ctors
> > or not (as it forbids them from being included in unions).
>
> Makes sense.  We could have nested namespaces:
>
>  parse.locations
>
> But people aren't going to like typing that.  Maybe:
>
>  parse.locs
>
> This appeals to me, but maybe others find it ugly.  I can live with  
> just
> "locations".

I prefer "locations".


> > > > - %define variant (lalr1.cc, and glr.cc in my branch)
> > > > Use variants instead of union.
> > >
> > > Maybe use "variants" for consistency with "locations".  That fits  
> > > the
> > > phrase "use variants".  Is it appropriate to think of this as an api
> > > change?
> >
> > Well, that depends what you call "api": AFAIR it does not change
> > anything to yylex/yyparse api
>
> I was thinking of the generated code, so I'm not sure what the right
> namespace is in this case.
>
> > , but it does change the Bison API.  For
> > a start %type <> expects genuine types, no longer type tags bouncing
> > to %union.
>
> I remember we discussed this some time ago as we discussed  
> make_SYMBOL and
> modular grammars.  Of course, I would like to see the same ability  
> in C
> skeletons.

It should be easy to port the code.


> >       return yy::parser::make_TEXT ("I have three numbers for  
> > you.", loc);
> >     case 1:
> >     case 2:
> >     case 3:
> >       return yy::parser::make_NUMBER (stage, loc);
> >     case 4:
> >       return yy::parser::make_TEXT ("And that's all!", loc);
> >     default:
> >       return yy::parser::make_END_OF_FILE (loc);
>
> > (Should the location be before the value in the make_SYMBOLs?  It
> > would probably look nicer.)
>
> Somehow that does look nicer.

I agree.  Will change that.