Hi Akim, Joel and all. It's very interesting that several people came up with very similar approaches regarding this issue. I would suggest to use Joel's syntax with brackets plus default names support; exactly like you suggested. Inside of brackets both name, $name and @name will be allowed, having equal semantics, at first.
If there will be no objections on your side, I would like to prepare new version of the patch, paying addition attention to accurate error messages in case of name ambiguities. I also will try to add some tests to the regression suite. Thank you very much for your comments. Akim, could you please answer on my question regarding a bootstrapping problem, just if you have time. It is very disturbing issue, I spent many hours trying to understand it - without success. I've sent it to bison-help mailing list, but had no answer there yet. Please see it here: http://lists.gnu.org/archive/html/help-bison/2009-01/msg00020.html. Kind regards, Alex Rozenman On Thu, Jan 29, 2009 at 2:27 AM, Joel E. Denny <[email protected]>wrote: > On Wed, 28 Jan 2009, Akim Demaille wrote: > > > Joel, I'm sorry to involve you in, but you demonstrated good taste in > > syntactic issues in Bison, so your opinion, if you have some time, > > would be great. > > Thanks. > > You may recall there was a long discussion about this among a handful of > us around 3 years ago. I really don't have time to get too involved in > this again, so I'm just going to offer a proposal based on my recollection > of the previous discussion. I'll probably repeat some of what you two > have already said today, but at least that will tell you where I agree. > > 1. Default names. > > For example: > > invocation: op '(' args ')' { > $invocation = new_invocation ($op, $args, @invocation); > } > > The old $$, @$, $n, and @n could be mixed with $name and @name > arbitrarily, but that's up to the user. For example, some may like the > following better: > > invocation: op '(' args ')' { $$ = new_invocation ($op, $args, @$); } > > However, sometimes default names are not sufficient because of ambiguous > references: > > exp: exp '/' exp { $exp = $exp / $exp; } // Warn that $exp is ambiguous. > exp: exp '/' exp { $$ = $1 / $exp; } // Just one usage is ambiguous. > exp: exp '/' exp { $$ = $1 / $3; } // No warning. > > 2. Overriding default names. > > For example: > > exp[quotient]: exp[dividend] '/' exp[divisor] { > $quotient = $dividend / $divisor; > } > > Besides removing ambiguities, some have pointed out that this is also > useful to abbreviate a long symbol name to make semantic actions more > legible. > > Here's why I suggest square brackets over other notations: > > a. Most binary operators (like ":", "=", "/", ",", "#", etc) seem to lead > to disagreement among us on which order of operands is best. More > importantly, I suspect that the user who doesn't use Bison every day would > find himself rechecking the manual to remember the order. > > b. "exp$quotient" doesn't have the order of operands problem. I dislike > it for two other reasons. I find it hard to read, but aesthetics are > perhaps the least of our worries. More importantly, this notation seems > to imply that locations have not been named. > > c. Some have suggested "exp.quotient", but POSIX Yacc says "." is allowed > in symbol names. > > d. Everyone seems to point out that parentheses collide with EBNF. More > importantly, if Bison one day tries to incorporate EBNF-like functionality > into its current non-EBNF notation, it seems clear that we should still > use parentheses for grouping. > > e. Some point out that square brackets collide with the EBNF notation for > optionality. However, in the Lex and Yacc world, "(...)?" is used for > optionality, so I think we should be free to use square brackets for > something else. > > 3. Suppressing warnings about unused values and possibly locations. > > The idea here was that "exp[]" in a grammar production basically means > that this occurrence of exp has no semantic value. To say it more > concretely, even if exp has a semantic type and a destructor, Bison should > not warn that its value is unused in the semantic action, but it should > warn if it is used. "e...@dividend]" names the location but says there is > no semantic value. "exp[$dividend]" names the semantic value but says > there is no location... in case we ever add the option to warn about > unused locations (which could have allocated memory for, say, a file > name). > > However, I'm going to avoid further comment on the topic of unused values > and unused locations as it seemed to cause most of the confusion in the > last discussion. Maybe it's just not worth all the trouble. In any case, > it need not be implemented initially. > -- Best regards, Alex Rozenman ([email protected]).
