help-bison
[Top][All Lists]
Advanced

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

Re: Bison -v Stack Interpretation


From: James K. Lowden
Subject: Re: Bison -v Stack Interpretation
Date: Tue, 19 Dec 2023 21:11:41 -0500

On Wed, 20 Dec 2023 19:58:26 +0100
Dan Ohlsson <danericohlsson@gmail.com> wrote:

> I have difficulties understanding the stack content when executing
> bison with the -v options.  Please explain or give reference to where
> I can find information!

That's a really big question, Dan.  Do you want to come to Brussels in
February to hear my FOSDEM talk?  

Perhaps the best information is in

        8.5.2 Enabling Debug Traces for ?mfcalc?

In the Bison info manual.  To understand it, you have to understand how
the LALR parser works.  If you're like me, that takes awhile to
internalize.  

On any given token, the parser either shifts the token onto its stack,
or reduces the stack.  To me, all the interesting stuff happens when
reducing, because that's literally where the action is.  

             Reducing stack by rule 6 (line 44):

"Rule 6" is among the rules enumerated in the output file if you used
verbose mode.  Line 44 refers to you parse.y file, or whatever was
input to Bison.  Each element in the rule to the right of the colon is
a terminal or nonterminal, and has a value.  But of course you know
that.  

What can be mysterious is when Bison reports a syntax error.  As a
technical matter, it means that the last token retrieved from yylex
matches no rule in the current state.  That is, if in State X there is
no acceptable token T, then T is in error.  (Of course, you can get to
X by mistake too.  There is an infinite combination of shoelaces and
knots.) 

To understand what state X is when T arrives, you also have to consult
the report file produced in verbose mode.  

My last bit advice is this: turn on yy_flex_debug, too (assuming you're
using flex).  Quite often, the T returned by yylex is not the one you
would have hoped for, given the input text, perhaps because the list of
strings it digests has fallen behind what the parser demands.  

HTH.

--jkl





reply via email to

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