Re: Proposal for lambda'ing error recovery

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: Tue, 19 Nov 2002 11:31:03 +0100
> 
> my claim is that the manipulation of these variables is <<<< before
> the rest of the process (user actions etc.).

That is true only if you're parsing small things, relative to the rest
of the work that you're doing.  If the parser is the bulk of the action,
then it can become a bottleneck.

In traditional applications parsers are rarely the bottleneck.  The
bottleneck is more typically the lexer (with simple compilers) or the
code generator (with more complicated ones).  But there are some
nontraditional applications where the parser is the bottleneck, and we
should attempt to support them too.


>  Paul> Hmm, but yy_recover_parse_error invokes YYFPRINTF, and the user can
>  Paul> redefine YYFPRINTF.
> 
> What could be stolen?  In addition, YYFPRINTF is quite new, I doubt
> people have found means to abuse of it.

You're probably right about that.  (Though I wouldn't call YYFPRINTF
"new" -- it's already 11 months old!  :-)

> And I honestly don't plan to maintain abuses of internal guts.

Hmm, wait a minute.  You're correct that users shouldn't assume that
YYFPRINTF is called only from yyparse, but the phrase "abuses of
internal guts" is pretty strongly worded, and I suspect that there may
be an underlying philosophical difference here that we should tease
out into the open.

Now, it's not abuse of internal guts for users to define YYFPRINTF per
se, as it is in the Bison manual.  The manual is silent as to whether
all invocations of YYFPRINTF are from the yyparse function, so users
should program accordingly; but it would be an entirely understandable
error for a user to mistakenly think that YYFPRINTF is used only in
that function.

Perhaps part of the problem here is that I have a fairly traditional
view of yyparse.  Traditional yacc generates a single function,
yyparse.  yyparse maintains its own stacks, so it doesn't need
subroutines in order to do its work.  I realize that this view is
dreadfully old-fashioned, but there are some technical advantages to
doing it that way.

flex takes the idea of having a single C function a step further: it
lets the user declare variables that are local to the scanning
function.  These variables can be used as the user likes, and can
improve performance and/or understandability.  Bison uses this feature
of flex; see the "braces_level" and "c_context" variables in
src/scan-gram.l.

I wish a similar feature were available in Bison.  It wouldn't be that
hard to add, but I fear that it would conflict with the direction
you'd like to take yacc.c.  As I understand it, you're trying to break
yyparse up into several separate C functions, and are suffering from
the problems that result from having the functions communicate with
each other.  Adding local variables to yyparse would make that job
harder.