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
_______________________________________________
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison