[Top][All Lists]

[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

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'"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.

reply via email to

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