[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,
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.
- [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/03
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/03
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/04
- Re: [PATCH] Factor %FLAG at scan level.,
Akim Demaille <=
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/08
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/08
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/09
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/10
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/14
- Re: [PATCH] Factor %FLAG at scan level., Joel E. Denny, 2009/04/14
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/15