Re: Visibility and error messages (in named refs).

[Joel E. Denny]

Hi Alex.

On Sat, 11 Jul 2009, Alex Rozenman wrote:

> I would like to return to our discussion about visibility and error
> messages, because the current situation, in my opinion, is not satisfying.
> Now we have a possibility to change things, but when the version will be
> released it will be much more complicated to do.

I hope we can all agree that this feature is complex enough that it should 
be labeled as experimental in the 2.5 release.  That will help us escape 
backward compatibility problems.

> Let's say you start with the following grammar:
> 
> > stmt: IF expr THEN stmt ';'
> > { $$ = new StmtObj($expr, $stmt); };
> >
> 
> You get the following:
> 
> > test1.y:7.27-31: ambiguous reference: `$stmt'
> > test1.y:6.1-4:   refers to: $stmt at $$
> > test1.y:6.20-23:   refers to: $stmt at $4
> >
> 
> OK, you quickly figure out that 'stmt' is ambiguous because it can also
> refer to LHS. You change the grammar as the following (very natural, IMHO):
> stmt[result]: IF expr THEN stmt ';'
> { $$ = new StmtObj($expr, $stmt); };
> 
> And then, you're surprised by the following:
> 
> > test1.y:7.27-31: misleading reference: `$stmt'
> > test1.y:6.6-11:   possibly meant: $result, hiding $stmt at $$
> > test1.y:6.28-31:   refers to: $stmt at $4
> 
> Your conclusions: 1) it's unclear how to get rid of this disturbing LHS ???,
> 2) the error message advices you to write $stmt in order to address $4, but
> this is exactly what you currently have! At this point you probably return
> to positional references ($4).
> 
> It could be suggested that we can improve the error message, but I think
> that it shows more serious problem. If we decided that explicit references
> hide implicit ones, we *must* did it completely, i.e. when user writes
> stmt[result], this 'stmt' must go away from the resolution scope. The
> current behaviour is very hard to explain and to document.
> 
> My second point is about reference to symbols with dots and dashes.
> Currently we have an error in this case. I think that a warning would be
> enough when no ambiguity possible.

I cannot remember the definition for "misleading reference" that you 
eventually chose, and I haven't checked your code.  I suggested it should 
describe the case when there is exactly one "refers to" submessage and one 
or more "possibly meant" submessages.  I think all of your above 
discussion is a good argument that what I call a "misleading reference" 
should be a warning and not an error.

It would also read better to me if "refers to" submessages appeared before 
"possibly meant" submessages.  That is, I want to see the correct 
interpretations before the suggestions.  Within each of those groups, you 
could sort by position in the production.

Thanks for all your work, Alex and Akim.