Re: symbolic names - an updated version

[Joel E. Denny]

Hi Alex,

On Sat, 16 May 2009, Alex Rozenman wrote:

> I prepared a new version of my modification. I changed format of error
> messages and somewhat improved the code. I also supported dashes in implicit
> (as well as in explicit) symbol references.

Thanks for doing that.

The "misleading reference" concept has disappeared from your code.  For 
example:

  start: foo foo.bar { $foo.bar; }
  tmp.y:2.22-29: reference is invalid: `$foo.bar'
  tmp.y:2.8-10:   refers to: $foo at $1
  tmp.y:2.12-18:   possibly meant: $[foo.bar] at $2

$foo.bar is not invalid.  It is simply misleading.  We're going to 
frustrate the user if Bison doesn't give him the exact reason for 
rejecting his code.

> if_stmt1: IF expr[cond] THEN stmt[then] ELSE stmt.list[else] FI
>           { $if_stmt1 = new IfStmt($cond1, $then.f1, $else); };
> interpreter.ypp:67.36-41: symbol not found: `$cond1'

I still think it would be more consistent to say "reference is invalid" 
here.  Also, in other cases, "symbol not found" doesn't make sense anyway:

  start: { $foo.bar; }
  tmp.y:2.10-17: symbol not found: `$foo.bar'

Bison does not parse $foo.bar as a symbol.  Bison parses it as a reference 
to a field of a semantic value of a symbol, and that reference is invalid.

> if_stmt10: IF expr[cond] THEN stmt[stmt.x] FI
>           { $if_stmt10 = new IfStmt($cond, $stmt.x, 0); };
> interpreter.ypp:94.44-50: reference is invalid: `$stmt.x'
> interpreter.ypp:93.36-41:   possibly meant: $[stmt.x].x at $4, `stmt' is
> hidden
> interpreter.ypp:93.36-41:   possibly meant: $[stmt.x] at $4

The first "possibly meant" seems confusing.  I think giving the exact 
hidden reference makes the connection more immediately obvious:

  interpreter.ypp:94.44-50: reference is invalid: `$stmt.x'
  interpreter.ypp:93.36-41:   possibly meant: $[stmt.x].x hiding $[stmt].x at $4
  interpreter.ypp:93.36-41:   possibly meant: $[stmt.x] at $4

The second "possibly meant" seems clear.

> if-stmt-a: IF expr[cond] THEN stmt.list[then] ELSE stmt.list[else] FI
>           { $if-stmt-a = new IfStmt($cond, $then, $else); };
> interpreter.ypp:97.13-22: reference is invalid: `$if-stmt-a'
> interpreter.ypp:96.1-9:   possibly meant: $[if-stmt-a] at $$
> 
> if-stmt-b: IF expr[cond] THEN if-stmt-a[then-a] ELSE stmt.list[else] FI
>           { $[if-stmt-b] = new IfStmt($cond, $then-a.f, $else);
> interpreter.ypp:100.46-54: reference is invalid: `$then-a.f'
> interpreter.ypp:99.41-46:   possibly meant: $[then-a].f at $4
> 
> Some points:
> 1. As you can see from the last two examples, dashes are treated exactly
> like dots. It means that $symbol-with-dashes reference will be rejected and
> a bracketing will be required. On the other hand, symbols like 'if-stmt-a'
> look much more "together" than 'stmt.list', and it is very possible, that in
> someone eyes, it would be much more natural to allow $if-stmt-a without
> bracketing (but '-' is a subtraction in C!). I am still not sure that such a
> inflexible implementation is the right thing.

I like the way you have it now.  In C code, my eyes want to parse 
`$then-a.f' as `$then - a.f' not `$[then-a].f'.

> 2. In example with if_stmt10 there is a very corner case when the reference
> is compatible both with the implicit and the explict references. The error
> message generated in this case looks, at least, hard to understand (but it
> is correct). How can we improve it ?

I think it helps to give the full hidden reference, as I've shown above.

> 3. I also not sure that the style of error messages when I'm directly
> replacing the referenced symbol by an explicit reference (as in if_stmt2) is
> understandable by users. The error message points to an expression that user
> never wrote. I'm in favour of adding words "suggestion" or "you may write"
> into the text.

I like the way you have it now.

> As per you request, I deleted generated files from the patch (however, I
> have no idea what's the correct way to do in git. I'm just not committing
> them, but then I have a problems during "git-pull").

Keep them when you commit.  We normally delete them from our emails so 
others don't have to scroll through them when reviewing.

> I sent my documents to FSF a two weeks ago, I hope they're already there.

I don't see your information listed yet.  Let's give it a few more days, 
and then I'll ask about it.  In my experience, it can take more than two 
weeks.