Re: [PATCH 00/11] support "%define variable {value}"

[Joel E. Denny]

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.