Re: merge function called AFTER user actions

[Hans Aberg]

On 23 Sep 2005, at 03:33, Derek M Jones wrote:

> If I knew in advance (that is, before the action associated
> with a rule was executed) I could set some variable that
> could be tested in the action to decide whether to handle
> the common case or whether some kind of semantic ambiguity
> resolution was needed.
>
> Unfortunately the function associated with %merge is called
> AFTER the actions are executed.
>
> Looking at the generated parser it seems that simply swapping
> around the call to yyresolveAction and yyuserMerge (in yyresolveValue)
> would achieve what I want (ie, the call to the %merge function
> to occur first).
>
> Does anybody know why the decision was made to have the %merge
> function called last?  This choice seems to be very suboptimal.

What you are asking for, I think is not a merge function called  
before the actions, the latter which are delayed until a merge can  
take place, but a new type of actions that are executed immediately  
during a split. This last, I have discussed with Paul Hilfinger, who  
wrote the GLR parser. But I have no idea when or whether it will be  
implemented n Bison.

  Hans Aberg