[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: symbolic names - an updated version
From: |
Joel E. Denny |
Subject: |
Re: symbolic names - an updated version |
Date: |
Sun, 17 May 2009 20:09:00 -0400 (EDT) |
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.