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

[Akim Demaille]

Le 7 avr. 2013 à 23:41, Joel E. Denny <address@hidden> a écrit :

> Hi Akim,

Hi Joel!

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

No worries :)

>> 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?

That's what I had in mind.  Consistency and simplicity first.

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

Agreed.  I'm not there yet, all the variables will have to be checked.
I first toyed with api.namespace, which does not feature the warning
yet, but then I will first focus on pushing the renovated api.value.type,
and then only will I proceed on to the other variables.  My interactive
rebases are already painful.

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

But it can be implemented M4 anyway.  I have not chosen my religion
yet.

> Looking through the bison 2.7 manual, I see no cases of other arbitrary 
> values, such as file names.

I have not fully checked yet.

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

Agreed.

> I've skimmed your grammar patch, and it looks like you're thinking along 
> these lines.

I am.

I have another question though: in reality we have four different
means to introduce values: there is also <>.  It would make sense
to use

  %token {int} INT
  %type {int} exp

instead of <int> (actually even when %union is used, it would be
more consistent to use braces given the convention we are establishing
now).  But of course, it would have to be propagated not only to
%printer/%destructor, but also to

  exp: exp "+" exp { ${float}$ = ${float}1 + ${float}2; }

I'm not sure we should make that move.