Re: [PATCH] Re: named references

[Joel E. Denny]

On Wed, 18 Mar 2009, Alex Rozenman wrote:

> Thank you very much for you comments. They were really valuable.

I'm glad I could help.

> I attached a new version of the patch. As you certainly know, it often
> happens that accurate implementation changes feelings about how stuff should
> work.

Sure.

> My current approach is a little bit different from the "consensus" we
> had and based on actual symbols (and symbol names) presented in the
> production. It is based on a very simple principle - report all possible
> ambiguities carefully; compile silently when there are no possible
> ambiguities. I copied some examples of bison's output for various
> combinations of issues. I agree that "too" smart implementations are often
> inappropriate, but clear and understandable error messages may help.

I'm leery of parsers that try so hard to accept the user's input that 
they'll consider all possible interpretations looking for the one 
interpretation that works.  My experience is that this approach can 
severely impede the user's debugging process.  It's better for the syntax 
to be strict and consistent.

> Please note that "asymmetric renaming" warning is not implemented (yet). You
> may consider it "disabled" in the following examples. Actually, I am not
> sure that it would be helpful.

Both Akim and I felt it would be helpful.  I haven't seen any evidence to 
the contrary yet.

> /* an idyllic case */
> if_stmt: IF expr THEN stmt.list[then] ELSE stmt.list[else] FI
>            { $if_stmt = new IfStmt($expr, $then, $else); };
> <no errors, no warnings>

Ok.

> /* a real ambiguity reported regardless of dots, note that dots cannot
>     be a reason for these ambiguities */
> if_stmt: IF expr THEN stmt.list ELSE stmt.list FI
>            { $if_stmt = new IfStmt($expr, $stmt.list, $stmt.list); };
> interpreter.ypp:74.43-52: reference is ambiguous: `$stmt.list'
> interpreter.ypp:73.23-31: (may refer to: `stmt.list')
> interpreter.ypp:73.38-46: (may also refer to: `stmt.list')

I think this would be better if it read:

  interpreter.ypp:73.23-31: (may refer to: `stmt.list' at $4)
  interpreter.ypp:73.38-46: (may also refer to: `stmt.list' at $6)

> interpreter.ypp:74.55-64: reference is ambiguous: `$stmt.list'
> interpreter.ypp:73.23-31: (may refer to: `stmt.list')
> interpreter.ypp:73.38-46: (may also refer to: `stmt.list')

Likewise.

However, are you implying that the following would not generate a warning 
or error because there are no ambiguities?

  if_stmt: IF expr THEN stmt1 ELSE stmt.list FI
             { $if_stmt = new IfStmt($expr, $stmt1.ptr, $stmt.list.ptr); };

If so, I understand the lure of that approach.  Nevertheless, it still 
bothers me that the user's eye must parse the basic syntax of $stmt1.ptr 
and $stmt.list.ptr based on what symbols are present in the production.  
This gets more troublesome as the action and production get longer and 
more complicated.  Again, I think a strict syntax is better:

  if_stmt: IF expr THEN stmt1 ELSE stmt.list FI
             { $if_stmt = new IfStmt($expr, $stmt1.ptr, $[stmt.list].ptr); };

> /* an ambiguity because of dot issue; there is an additional
>     explaination */
> if_stmt: IF expr THEN stmt ELSE stmt.list FI
>            { $if_stmt = new IfStmt($expr, $stmt, $stmt.list); };
> interpreter.ypp:74.50-59: reference is ambiguous: `$stmt.list'
> interpreter.ypp:73.23-26: (may refer to: `stmt')
> interpreter.ypp:73.33-41: (may also refer to: `stmt.list')
> interpreter.ypp:74.50-59: (you may consider using `$[stmt]' or
> `$[stmt.list]')

In general, it might be nicer if the "may refer to" messages always 
include the full bracketed expressions.  Then there's slightly less to 
read in the above messages:

  interpreter.ypp:74.50-59: reference is ambiguous: `$stmt.list'
  interpreter.ypp:73.23-26: (may refer to: `$[stmt].list')
  interpreter.ypp:73.33-41: (may also refer to: `$[stmt.list]')

This is a very minor improvement.  Don't worry about it if it's too much 
trouble.

> /* no ambiguity possible, ".list" interpreted as a field */
> if_stmt: IF expr THEN stmt[then] ELSE stmt FI
>            { $if_stmt = new IfStmt($expr, $then, $stmt.list); };
> <no errors, no warnings>

This still looks like a user error to me.  I think Bison should report an 
asymmetric renaming.

> /* using of mid-rule action */
> if_stmt: IF expr { $<stmtptr>cond = $expr > 0; } [cond] THEN stmt[then] ELSE
> stmt FI
>            { $if_stmt = new IfStmt($<stmtptr>cond, $then, $stmt.list); };
> <no errors, no warnings>

That [cond] looks like a separate grammar symbol.  I'd prefer that space 
is never allowed before the open bracket whether it appears after a symbol 
or a mid-rule action.

Also, the asymmetric renaming bothers me more now as the rule is getting 
more complex.

> /* forbidden access from mid-rule action */
> if_stmt: IF expr { $if_stmt = $then; } [cond] THEN stmt[then] ELSE stmt FI
>            { $if_stmt = new IfStmt($<stmtptr>cond, $then, $[stmt].list); };
> interpreter.ypp:73.20-27: `$if_stmt' cannot be accessed from mid-rule action
> interpreter.ypp:73.31-35: `$then' cannot be accessed from mid-rule action

I believe Bison usually qualifies similar messages with "at $3".  It 
should at least.

Once again, thanks for all your hard work, Alex.  I especially appreciate 
your willingness to discuss the issues with clear examples and English 
rather than relying on your patches to explain everything.  Otherwise, I 
would not have time to participate right now.