Re: [PATCH] Named symbol references

[Joel E. Denny]

On Wed, 18 Feb 2009, Akim Demaille wrote:

> My preference goes to the last one.  But, as I wrote in a previous
> email, I understand your resistance, so maybe we can issue a warning
> when "$foo.bar" is used and it turns out a "foo.bar" is a grammar
> symbol.  To remove the warning, the user needs to write $[foo.bar] or
> $[foo].bar in that case.

The warning makes this feel better to me.

We need to consider the case of multiple dots.  I'd say the default 
interpretation of $foo.bar.baz is $[foo].bar.baz regardless of whether 
there exists a foo.bar or foo.bar.baz symbol in the production, and Bison 
should warn the user when either does.  If both exist, there should 
probably be two warnings.

At some point, someone may suggest that, if there exists a foo.bar symbol 
but no foo or foo.bar.baz, then Bison could interpret $foo.bar.baz as 
$[foo.bar].baz without warning.  That could be implemented, but I feel 
this is getting too clever.  It seems simpler and less error-prone to be 
able to read the reference $foo.bar.baz in isolation without looking at 
the production and know exactly how Bison will parse it: always 
$[foo].bar.baz perhaps with helpful warnings.

>  > Perhaps something like "asymmetric renaming of $item".                     
>                                                                               
> I like this idea.  In a collision, no one is allowed to use the               
> collided name.                                                                

Exactly.  That's the concept I was going for.

>  > Also, maybe an error is too strict.  It could be just an optional
>  > warning.  In that case, it wouldn't have to be implemented now.
>  > Once implemented, if the warning never actually proved useful in
>  > practice, we could later remove it.  It's just a guess on my part
>  > anyway.
> 
> Warnings can be turned into -Werror.

True.  Maybe it's safest to implement any warnings before formally 
releasing this feature.

Thanks for your input, Akim.