[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Akim Demaille
Subject: Re: [PATCH] Factor %FLAG at scan level.
Date: Mon, 6 Apr 2009 09:04:23 +0200

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

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.

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 (
  additional runtime assertions to catch non-initialized $$.

- %define debug

- %define error_verbose

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

- %define locations

- %define variant (, and 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.

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]