[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Named symbol references
From: |
Alex Rozenman |
Subject: |
Re: [PATCH] Named symbol references |
Date: |
Fri, 13 Feb 2009 10:54:44 +0200 |
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).
Re: [PATCH] Named symbol references, Akim Demaille, 2009/02/18