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

[Joel E. Denny]

Hi Akim,

On Fri, 3 Apr 2009, Akim Demaille wrote:

> So I think we should phase out %debug and the like, and make them be sugar for
> "%define debug", a bit like Flex did with %option.  It should make a smaller
> code base, and more possibilities.

I agree.  I started something similar with %pure-parser and %define 
api.pure.  See parse-gram.y for the tricks to make it backward compatible.  
Maybe your %<flag> action should use that code.

> - factoring comes with a price: the error messages will go from "unexpected
> %debug" to "unexpected %<flag>".  Big deal?

Those angle brackets don't convey the right meaning to me.  Maybe I expect 
them to mean a type tag as in the grammar file.  I think this is a small 
price, and we might be able to find some better notation.  Besides, I 
vaguely recall that %printer is eventually going to be used in syntax 
error messages.  Is that right?

> - should -Derror-verbose and -Derror_verbose be the same?

What if we just accept "%define error-verbose"?  I'd like to convert 
api.push_pull and lr.keep_unreachable_states to use dashes as well.

> - locations_flag is a bit more of a problem, as it can be activated implicitly
> when we encounter a @$ or so.  I would like to deprecate (but I guess never
> remove) the implicit use of locations not declared via %locations (well,
> %define locations)).

I think it's fine if @$ and $n imply "%define locations".  We just have to 
be careful about duplicate declaration warnings, but my %pure-parser code 
shows how.

> - we should probably also have priority management so that the grammar file
> can declare %define debug, but be overriden by -Ddebug=false.

Agreed.  We need to generalize Paolo's skeleton_arg and language_argmatch 
functions.  There was some discussion on correct priority some time ago.  
My recollection is that the command line should have higher priority, but 
there should be a warning if a grammar declaration contradicts the command 
line.  If that's too harsh, the warning could be disabled.

> - we should probably also do that for variables that take an argument, such
> --defines=FILE.

This one is a bit tricky.  For example, --skeleton and %skeleton interpret 
relative file names differently.  However, --defines and %defines do not.

> - but where is the limit?  What options will remain true options rather that
> wrappers around muscle-variables?

I'm not sure yet.