bison-patches
[Top][All Lists]
Advanced

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

Re: %merge <foo> -> %merge foo ?


From: Joel E. Denny
Subject: Re: %merge <foo> -> %merge foo ?
Date: Wed, 12 Jul 2006 19:50:58 -0400 (EDT)

On Wed, 12 Jul 2006, Joel E. Denny wrote:

> %merge has several interface problems.  See this thread:
> 
>   http://lists.gnu.org/archive/html/bison-patches/2006-01/msg00044.html
> 
> I've been thinking %merge ought to be redone entirely.
> 
> Can we let this sit for now, and then fix the whole %merge can of worms 
> all at once?  That should be the least stressful for the users.

Ah well, here goes....

I think %merge ought to be like %destructor, %printer, %initial-action, 
and Akim's proposed %error-report (to replace yyerror):

  %merger { $$ = new_lhs ($1, $2); }

Now we can add new parameters without breaking backward compatibility with 
old function prototypes.  Moreover, we can consider possibilities like 
YYABORT in %merger.

The question now is, how does the user associate a %merger with a set of 
rules?  He could do it by semantic type (<...> or <{...}>), by nonterminal 
symbol name, or by rule labels:

  %merger { $$ = new_lhs ($1, $2); } [RULE_A] [RULE_B];
  lhs:
    [RULE_A] rhs1 rhs2 { $$ = new_lhs ($1, $2); }
    | [RULE_B] rhs1 rhs2 rhs3 { $$ = new_lhs ($1, $2, $3); }
    ;

It occurred to me that rule labels might prove useful beyond %merger... 
even beyond GLR.  For example, I once discussed the idea of %conflict code 
for dynamically resolving conflicts.  Rule labels would allow user code to 
identify which rules are in conflict and to specify which to select.  It 
would even let him associate a specific %conflict with a specific set of 
rules.

Joel




reply via email to

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