Re: [PATCH] Named symbol references

[Alex Rozenman]

Hi Joel,

Thank you for the response. Please see below.

On Thu, Feb 12, 2009 at 4:29 AM, Joel E. Denny <address@hidden>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 (address@hidden).