Re: [PATCH] symbolic names

[Joel E. Denny]

Hi Alex,

On Sat, 4 Apr 2009, Alex Rozenman wrote:

> if_stmt1: IF expr[cond] THEN stmt[then] ELSE stmt.list[else] FI
>           { $if_stmt1 = new IfStmt($cond, $stmt.x, $stmt.list); };
> 
> Current output:
> interpreter.ypp:56.43-49: reference is invalid: `$stmt.x'
> interpreter.ypp:55.30-33:   possibly meant: $[stmt].x at $4, symbol hidden
> interpreter.ypp:56.52-61: reference is misleading: `$stmt.list'
> interpreter.ypp:55.30-33:   possibly meant: $[stmt].list at $4, symbol
> hidden
> interpreter.ypp:55.46-54:   possibly meant: $[stmt.list] at $6, symbol
> hidden

I don't understand your distinction between "invalid" and "misleading".  
We should make it clear to the user that both $stmt.x and $stmt.list are 
*invalid* references here.  That is, as written, they cannot refer to any 
existing semantic value or any field of any existing semantic value.

I feel the weaker term "misleading" only makes sense when the reference is 
valid and unambiguous but there happens to be an invalid interpretation 
that might mislead.  That is, there is exactly one "refers to" submessage 
and at least one "possibly meant" submessage.

The example I gave in an earlier email was:

  lhs: rhs[first] rhs { $rhs; } ;

Bison would report (ignore my location info):

  interpreter.ypp:74.43-52: reference is misleading: `$rhs'
  interpreter.ypp:73.38-46:   refers to: $rhs at $2
  interpreter.ypp:73.38-46:   possibly meant: $rhs hidden at $1

As a separate issue, I think Akim suggested that last line should be 
rewritten with $first instead:

  interpreter.ypp:74.43-52: reference is misleading: `$rhs'
  interpreter.ypp:73.38-46:   refers to: $rhs at $2
  interpreter.ypp:73.38-46:   possibly meant: $first at $1

I agree.  However, I'd also prefer a strong hint as to how this $first 
interpretation could possibly be confused with the valid $rhs 
interpretation.  I think we need:

  interpreter.ypp:74.43-52: reference is misleading: `$rhs'
  interpreter.ypp:73.38-46:   refers to: $rhs at $2
  interpreter.ypp:73.38-46:   possibly meant: $first hiding $rhs at $1

> Possible output (a smarter implementation):
> interpreter.ypp:56.43-49: reference is invalid: `$stmt.x'
> interpreter.ypp:55.30-33:   possibly meant: $then.x at $4
> interpreter.ypp:56.52-61: reference is misleading: `$stmt.list'
> interpreter.ypp:55.30-33:   possibly meant: $then.list at $4
> interpreter.ypp:55.46-54:   possibly meant: $else at $6

For easy reference, here's the corresponding input for the above output:

  if_stmt1: IF expr[cond] THEN stmt[then] ELSE stmt.list[else] FI
            { $if_stmt1 = new IfStmt($cond, $stmt.x, $stmt.list); };

So, I would rewrite that output as:

  interpreter.ypp:56.43-49: reference is invalid: `$stmt.x'
  interpreter.ypp:55.30-33:   possibly meant: $then.x hiding $stmt.x at $4
  interpreter.ypp:56.52-61: reference is invalid: `$stmt.list'
  interpreter.ypp:55.30-33:   possibly meant: $then.list hiding $stmt.list at $4
  interpreter.ypp:55.46-54:   possibly meant: $else hiding $[stmt.list] at $6

As you can see, the "hiding" phrase doesn't always just repeat the user's 
input, and it makes it clear that hiding is a reason the current 
interpretation is invalid.  Especially for someone who is just learning 
all Bison's rules, I think this information would be helpful.

> I always quote the symbol in the main message because it is taken verbatim    
> from user's input. All other strings in the output are bison "inventions".    
> I think that is important to show exactly what was written by user -          
> otherwise user's confidence will decline.

I now see your point that Bison should print exactly what the user wrote. 
The quotes here don't bother me, but I'd also be fine without them.

> >  (reference to a symbol with dots)
> >> if_stmt: IF expr[cond] THEN stmt.list FI
> >>           { $if_stmt = new IfStmt($cond, $stmt.list, 0); };
> >> interpreter.ypp:76.43-52: reference not found: `$stmt.list'
> >>
> >  I don't understand this one.  What is not found is $stmt.
> >
>
>  I'm not sure "reference not found" is right.  I understand "undeclared
> > identifier", "duplicate definition of identifier", "reference cannot be
> > solved" etc., but I'm not sure that "to find a reference" is right.

The phrase you're now using, "reference is invalid", alleviates this 
problem in my mind.  That is, the entire reference $stmt.list is invalid 
because stmt is not found in the visible names in the production.

> > In the attached patch I separated two cases: "symbol not found" when no
> variants available, and "reference is invalid" when there is single (but
> wrong) variant. So we will have:
> zero variants: "symbol not found"
> one variant: "reference is invalid"

I think it's simpler and clearer to say "reference is invalid" in both 
cases.  That phrase means there are no valid interpretations.  I don't 
think we need a special message that says "we also have no suggestions for 
you".  If there are no submessages, then we have no suggestions.

Thanks.