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

[Joel E. Denny]

On Wed, 8 Apr 2009, Akim Demaille wrote:

> > Maybe we should go ahead and rename api.push_pull and
> > lr.keep_unreachable_states in 2.5.
> 
> There's some ambiguity here: do you mean to make - vs. _ indifferent,  
> or simply move to using - ?  I first thought about normalizing _ into  
> -, but afterall I prefer a single name.

I mean move to using "-".

> > Ironically,
> > we didn't think of a good namespace for namespace.
> 
> Why not 'api.'?

Sounds good.

> > These all describe different aspects of the run-time parser behavior.
> > Maybe they should be:
> >
> >  parse.assert
> >  parse.debug
> >  parse.error-verbose
> 
> Good with me.
> 
> > Is assert too general?  Will there ever be other kinds of parser
> > assertions that should be controlled independently?
> 
> I don't think we should go too much in the details.  Maybe I should  
> have put it into api.debug, but it incurs some speed penalty, while  
> api.debug does not (or almost) and can be left active in production  
> parsers, while, IMHO, assert should not.

Ok.

> 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.

> > 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.

> >> - %define locations
> >>  %locations
> >
> > This makes an api change and adds a new task to the parse, so I'm  
> > not sure
> > any specific namespace is appropriate.

Then again, the api change is secondary.  The real point is to request 
that locations be tracked during parsing.

> 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".

> >> - %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.

>        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);
>      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.