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