[Top][All Lists]
[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
- Re: glr: include the created header, (continued)
- %merge <foo> -> %merge foo ?, Paul Eggert, 2006/07/12
- Re: %merge <foo> -> %merge foo ?, Joel E. Denny, 2006/07/12
- Re: %merge <foo> -> %merge foo ?,
Joel E. Denny <=
- Re: %merge <foo> -> %merge foo ?, Akim Demaille, 2006/07/13
- Re: %merge <foo> -> %merge foo ?, Akim Demaille, 2006/07/13
- Re: %type {...} a b c, Akim Demaille, 2006/07/13
- (no subject), haberg, 2006/07/13