Le 7 avr. 2013 à 23:41, Joel E. Denny <[email protected]> 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.
