help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exceeded limits of %dprec/%merge?


From: Derek M Jones
Subject: Re: Exceeded limits of %dprec/%merge?
Date: Fri, 19 May 2006 20:03:13 +0100
User-agent: Thunderbird 1.5 (Windows/20051201)

Joel,

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

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.

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?

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.

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);
}

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?

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.

--
Derek M. Jones                              tel: +44 (0) 1252 520 667
Knowledge Software Ltd                      mailto:address@hidden
Applications Standards Conformance Testing    http://www.knosof.co.uk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]