Re: merge function called AFTER user actions

[Joel E. Denny]

On Mon, 26 Sep 2005, Derek M Jones wrote:

> > This pre-merge user function would be an extra feature. I don't foresee 
> > myself using it, so I really can't justify spending my own time 
> > implementing it and arguing for its acceptance.
>
> Thanks for considering it.  The implementation is trivial and
> I hope the maintainers will add it to the core distribution.

It doesn't look trivial to me, but maybe I'm wrong.  Why not give it a 
shot yourself?  If your testing proves that it does what you think it 
should, submit it to bison-patches and see what everyone thinks.

> I take it you will not argue against this additional functionality.

I won't know until I see the code.  To be sure, I'm not a veteran bison 
developer.  I'm just a bison user who's contributed a few GLR patches 
recently.  My words are far from gospel, but GLR is my main interest in 
bison.

> > Personally, I'd do my best to rework this logic.  Evaluate the two 
> > possibilities in the two semantic actions, and then select one (or both) of 
> > the values in the merge function.  That's how bison is intended to work.
>
> I cannot find any statement about this 'intended' way of working in
> the documentation.

I am certainly not the original author of bison GLR, so perhaps I 
overstepped my bounds with that statement.  However, given that the merge 
function is documented as accepting two semantic values, surely this is 
the intention.  Moreover, there's this quote from section 5.8, 
`Generalized LR (GLR) Parsing':

  Otherwise, if the alternative actions are not ordered by precedence,
  but there the same merging function is declared for both rules by the
  `%merge' declaration, Bison resolves and evaluates both and then calls
  the merge function on the result.  Otherwise, it reports an ambiguity.

> The practical use of glr parsers is very new.  It is to be expected
> that new features will be added as experience grows.

No doubt, but somebody has to be the pioneer.

Joel