[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Factor %FLAG at scan level.
From: |
Joel E. Denny |
Subject: |
Re: [PATCH] Factor %FLAG at scan level. |
Date: |
Sat, 4 Apr 2009 12:36:10 -0400 (EDT) |
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.
- [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 <=
- Re: [PATCH] Factor %FLAG at scan level., Akim Demaille, 2009/04/06
- 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