[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 00/11] support "%define variable {value}"
From: |
Joel E. Denny |
Subject: |
Re: [PATCH 00/11] support "%define variable {value}" |
Date: |
Sun, 7 Apr 2013 17:41:05 -0400 (EDT) |
User-agent: |
Alpine 2.00 (DEB 1167 2008-08-23) |
Hi Akim,
On Thu, 4 Apr 2013, Akim Demaille wrote:
> In order to implement Joel's suggestion for api.value.type, some
> preliminary work is needed to extend Bison to accept more types
> of %define variable values, and to record how these values were
> defined. See
>
> http://lists.gnu.org/archive/html/bison-patches/2013-03/msg00016.html
Sorry for my confusing rambling there about problems with trying to handle
unquoted %define values. Not only does bison already handle them, but I'm
the one who implemented it, years ago! Yikes.
> for more context, but to quote Joel:
>
> > In general for %define, I wonder if we should continue to require quotes
> > for values that are keywords (such as variant, full, none). For values
> > that are code in the target language, braces seem nice. (For other
> > arbitrary values, such as file names maybe, quotes do seem appropriate.)
> > Applying that in the case of api.value.type, we'd have:
> >
> > %define api.value.type union-directive
> > %define api.value.type union
> > %define api.value.type variant
> > %define api.value.type {int}
> > %define api.value.type {variant}
>
> What follows is a first, incomplete, step.
Thanks for taking this up.
> The options -D/-F also need to become brace-aware, and maybe quotes
> aware.
I didn't think about those. Braces and quotes are special in bash, so I
suppose we'd have something like the following:
bison -Dapi.value.type=union test.y # keyword value
bison -Dapi.value.type='{int}' test.y # code value
bison -Dsome.file.name='"foo.h"' test.y # other arbitrary value
It's a little ugly, but that would be consistent with %define. What do
you think?
> The M4 code should start to "typecheck" some of the values (e.g., it
> should warn for %define api.namespace "foo" instead of {foo}).
For old variables accepting code, I agree there should be a deprecation
warning when braces are not used. For new variables, I think it should be
an error.
Would you deprecate quotes when a keyword is expected? I think so. In
the case of lr.type, for example, I suppose that warning would not be
implemented in M4 because it's not specific to a skeleton.
Looking through the bison 2.7 manual, I see no cases of other arbitrary
values, such as file names. If there were, would bison require quotes for
them even when there are no special characters in the value? I think so.
That is, quotes would explicitly distinguish this case from the keyword
and code cases.
I've skimmed your grammar patch, and it looks like you're thinking along
these lines.
- [PATCH 07/11] style: fix comments, (continued)
- [PATCH 07/11] style: fix comments, Akim Demaille, 2013/04/04
- [PATCH 11/11] api.namespace: demonstrate and use {...} values instead of "..." values, Akim Demaille, 2013/04/04
- [PATCH 04/11] grammar: split %union to group together related aspects, Akim Demaille, 2013/04/04
- [PATCH 02/11] style: comment changes, Akim Demaille, 2013/04/04
- [PATCH 08/11] grammar: record the kind of %define variable values, Akim Demaille, 2013/04/04
- [PATCH 01/11] muscle: minor refactoring, Akim Demaille, 2013/04/04
- [PATCH 10/11] grammar: do not add a \n at the end of blocks of code, Akim Demaille, 2013/04/04
- [PATCH 03/11] muscle: refactor, Akim Demaille, 2013/04/04
- [PATCH 09/11] regen, Akim Demaille, 2013/04/04
- [PATCH 06/11] regen, Akim Demaille, 2013/04/04
- Re: [PATCH 00/11] support "%define variable {value}",
Joel E. Denny <=
- Re: [PATCH 00/11] support "%define variable {value}", Akim Demaille, 2013/04/09