Hi Joel, Thank you for the response. Please see below.
On Thu, Feb 12, 2009 at 4:29 AM, Joel E. Denny <[email protected]>wrote: > > In semantic action > > code we may have: $name.field, where '.field' is a reference to a field > of > > %union component, which is a struct. If dots are allowed in symbolic > names, > > all the name is eaten by the ID. The obvious solution here is > > "($name).field". > Ugh. This may come up frequently with locations. For example, > @left.first_line seems right, but it's wrong. > This makes me wonder if Bison should require brackets after $ and @ as in > the following: > exp: exp[left] + exp[right] { $$ = $[left] + $[right]; } ; > If we say that the brackets following $ and @ are not optional, there > should never be confusion. I totally agree that it may come up very frequently. It seems like my original solution with ($name).field was wrong, because it would affect a lot of code, even when there is no single dot in symbol names. On the other hand, it is not a good practice to pollute semantic action code (which is "C" code, still) with additional foreign (and mandatory) syntax. I think about an intermediate solution, that may look like the following: 1. Dots are not allowed in (explicitly declared) symbol references, so every field reference like "$name.field" will be compiled smoothly. 2. If one needs to reference a symbol containing dots, it may be accomplished by (a) explicitly defined symbolic reference without dots, or (b) by $[some.symbol] syntax. if I write: > pair: item[first] item { $$ = new_pair($first, $item); } > Bison reports that $item is ambiguous? That seems ok because $item is > slightly confusing here. However, what about the following? > lhs: rhs[r] { $$ = $rhs; } > It seems like Bison shouldn't permit $rhs here. The user has promised to > call it $r instead. Can we just add another check after the ambiguity > check passes? > Please allow me to disagree with you. If we say that explicit "r" hides the "rhs" symbol (that's *factually* happens, whatever the error message will say), why then we have an ambiguity in the first case ? -- Best regards, Alex Rozenman ([email protected]).
