Re: Exceeded limits of %dprec/%merge?

[Joel E. Denny]

On Fri, 19 May 2006, Derek M Jones wrote:

> Given that there will only be one instance of it perhaps it should
> go on the first rule?
> 
> TU: program ;  %ambiguity <my_reportAmbiguity>
> 
> It could also go in the definitions section:
> 
> %ambiguity my_reportAmbiguity
> 
> I don't see any advantage for either way of specifying it.

I'd say the definitions section makes sense.  The declaration has no 
unique association with any specific rule.

> The function prototype might be:
> 
> YYSTYPE my_reportAmbiguity(yySemanticOption *yyx0,
>                            yySemanticOption *yyx1,
>                            yyGLRStack *yyStack,
>                            YYSTYPE yyZ0,
>                            YYSTYPE yyZ1)
> {
> ...
> 
> return yyZ0;
> }

Exposing internal data structures like yyGLRStack and yySemanticOption to 
the user is scary.  Bison developers would then have to worry about 
backward compatibility issues as we tried to evolve these structures and 
every structure they reference (the list is long) to fix bugs and meet new 
requirements.  This isn't going to fly as is.  Would you like to propose a 
set of functions to act as the user interface to these structures?

I believe you mean for yyZ0 and yyZ1 to be the semantic values associated 
with yyx0 and yyx1.  However, in the current implementation, they haven't 
been computed when yyreportAmbiguity is called.  This is one reason why I 
think %merge (or some generic version) is more appropriate.

Joel