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

[Akim Demaille]

Le 4 avr. 09 à 18:36, Joel E. Denny a écrit :

> Hi Akim,

Hi!

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

Yes, I did, thanks!

> > - 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 agree, I felt the same.

> I think this is a small
> price, and we might be able to find some better notation.

Some day, I would really like to find some means for the user to pass  
some yytext to yyerror_syntax error, so that we can have the genuine  
look-ahead string reported in the error message.

> Besides, I
> vaguely recall that %printer is eventually going to be used in syntax
> error messages.  Is that right?

You're reading my mind even before I started thinking.  Amazing trick :)
Well, there are a number of issues with %printer that I'd like to  
discuss at some point, but basically it boils down to the fact that  
it's bound to the parser itself, and now I regret this.  In the C++  
parsers there is now a symbol_type that has (type, value, location).   
I plan to import this in the C skeletons too, but I don't know when.   
I wish I had a proper operator<< and a proper destructor for this  
type, but I can't because %printer and %destructor explicitly provide  
the user with an access to the parser (in particular %parse-params).

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

Yes, I agree, that looks much nice.  Will do (at some point :).

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

I did as you suggested.  I'm not good at naming, so I'm eager to read  
any suggestion about the names to use.   I should write the  
documentation, that would help; in the meanwhile:

- %define assert (lalr1.cc)
  additional runtime assertions to catch non-initialized $$.

- %define debug
  %debug

- %define error_verbose
  %error-verbose

- %define lex_symbol
  yylex returns a symbol_type instead of taking pointers to value/ 
location and returning the type.

- %define locations
  %locations

- %define variant (lalr1.cc, and glr.cc in my branch)
  Use variants instead of union.


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

I don't remember.  I'll look for it.

> My recollection is that the command line should have higher priority,

Yes, definitely.

> but
> there should be a warning if a grammar declaration contradicts the  
> command
> line.  If that's too harsh, the warning could be disabled.

Hum.  Yes, let's have it disabled by default.


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

Ah!  OK, thanks for pointing this out.