Re: Any Method of reading the token values off the stack

[Hans Aberg]

At 21:49 -0400 2004/05/05, Tim Zimmerlin wrote:
>Hans,

Don't forget to cc the Help-Bison list. Every newbie on the list, like you,
seems to forget that.

>I understand that the state is embedded together with the symbol values
>on the stack;

It is the other way around: The states are represented by numbers, and that
is actually all that is needed on the stack. Despite what one sees on books
on parsing, the grammar symbols need not be on the stack, and Bison does
not have it.

> however, I do not know the memory structure.

The easiest way to learn that is to read the parser code that Bison outputs.

> We know that
>an LALR(1) parser generated by bison supplies the $1, $2, etc. values
>from the stack somehow to the actions of the rules.

If the rule has n items, then $k = *(top - (k-1)).

>I would like some API that I can call from the actions of the rules.
>Error recovery needs only "read access" in order to output the token
>values in their proper order for later manual editing. After
>encountering an error, the parser resynchronizes (I hope). I intend to
>let the normal error recovery pop all the incorrect symbols off the
>stack to get to a recovery state.

It already does. Read the parser code that Bison outputs.

>Is there some way within the actions to determine the number of symbols
>& the symbol values?

No. The error recovery just takes place by popping symbols off the stack
until it finds an appropriate error recovery state. I think the Bison
manual has some info about that.

> The symbol values held in the stack are lost
>during normal error recovery, leaving a hole around the error in the
>input sequence of symbols.

You do not say why you want this feature: For cleanup, there is under C an
experimental %destructor feature that lets the parser to do some cleanup
during error recovery. I use C++, which supports cleanup via the language;
so I do not need it. I described how I use C++ in the Bison-Patches list.

>I hesitate to modify the stack because I hope it is not necessary. I
>hesitate to create a separate parse structure due to performance.

If you need some customized stuff, it is easy to write ones own skeleton file.

  Hans Aberg