Re: Exceeded limits of %dprec/%merge?

[Joel E. Denny]

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

> > 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 
> 
> I take it what you mean is that by publishing an API you are essentially
> suggesting a degree of backwards compatibility and that in this case you
> don't want to make such a suggestion.

Yep.

> Having the ability to print out information on the two possible parses
> is useful. In my case it means I only have to worry about writing
> actions for things I am interested in.

If you construct a parse forest yourself using semantic actions and 
values, you can see all trees from a %merge.  I get that it's a lot of 
work.

> We could hide everything inside an ellipsis, as in...
> 
> YYSTYPE my_reportAmbiguity(YYSTYPE yyZ0,
>                            YYSTYPE yyZ1,
>                            ...)
> {
> /*
>  * People who want to use the 'standard' Bison function for
>  * printing out the ambiguity information can do the following.
>  */
> void (*print_reductions_func)(void *);
> void *semantic_option;
> 
> va_stuff=va_start(yyZ1);
> print_reductions_func=va_arg(va_stuff);
> 
> semantic_option=va_arg(va_stuff);
> print_reductions_func(semantic_option);
> 
> semantic_option=va_arg(va_stuff);
> print_reductions_func(semantic_option);
> 
> return and_now_figure_out_what_to_return(yyZ0, yyZ1);
> }

Who writes print_reductions_func?  What does it do precisely?

> > 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.
> 
> Is there any reason why they cannot be computed before this call happens?

At the moment, the tree underneath a yySemanticOption is resolved 
(destroyed in some sense) in a bottom-up fashion as the deferred semantic 
actions are performed and semantic values are produced.  I'm not 
interested in trying to change this logic.

> >                                          This is one reason why I think
> > %merge (or some generic version) is more appropriate.
> 
> Populating my .y file with all these %merges, just in case ...,
> would be a pain.

I think a generic version of %merge is more reasonable than a replacement 
yyreportAmbiguity.  Generic semantic actions, which I mentioned somewhere 
else on some Bison list, would also be helpful.  For the sake of forest 
construction, these are actually ideas I already had on my personal todo 
list.  However, I hadn't appreciated how a generic %merge might be used 
for reporting conflicts similar to yyreportAmbiguity.

Generics is a feature that will not happen soon.  You can currently 
accomplish the same thing by writing lots of repetitive code.  
Alternatively, you could use something like m4 to create your own 
templates and generate a parser spec from there.

Joel