[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Joel E. Denny
Subject: Re: Visibility and error messages (in named refs).
Date: Thu, 16 Jul 2009 06:38:25 -0400 (EDT)
User-agent: Alpine 1.00 (DEB 882 2007-12-20)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]