|Saving/restoring bison parse state tim@wagner.Princeton.EDU (1997-10-14)|
|Re: Saving/restoring bison parse state email@example.com (1997-10-26)|
|Saving/restoring bison parse state ssome@csi.UOttawa.CA (Stephane Some) (1997-10-29)|
|Date:||26 Oct 1997 22:16:46 -0500|
On 14 Oct 1997 00:37:36 -0400
>> I'm writing a C documentation tool based on a bison grammar >> for C.
>> /* some C code */
>> /***** save all bison state info here *****/
>> #ifdef FOO
>> /* branch 1 */
>> /***** restore bison state info here *****/
>> /* branch 2 */
>> Has anyone tried something like this before?
I have not tried the re-engineering of the bison grammar for C that you are
experimenting with, but I do have a comment to offer.
It seems that your documentation system could face a geometric explusion of
possible text items to reference. For in addition to engineering a successful
save and restore of the bison context that you have sketched, you have the
very major question of what to restore when you exit even a simple binary
if-then-else structure having parsed and resolved EACH branch
There are certainly many things that can happen in the branches, but take the
simple case of further definitions of lexical items.
If branch 1 #defines XYZ as FUNC1 and branch 2 #defines it as FUNC2, then
every use of XYZ now creates two cross references for your documentation
system. Another such if-then-else, could, double that if they interact. For
MEM_MODEL was defined as _large or _medium by alternate branches of a separate
ifdef, but the two text elements were to be pasted together into one of four
So, my point is that the rules of languages allow you to vary defined text (and
other conditional compile referants), but at any one time they are only one
value, and the practical combinations are probably _comparatively_ few. (I
am not ignoring the fact that variables can get reset, focussing on the simple
If you suspend this language constraint the number of possible interpretations
of the program text grows very large very fast, it seems to me. Many of them
would not necessarily be useful, perhaps.
Also the code does not reveal that some of the combinations might be mutually
exclusive. For example, an #ifdef UNIX might have a number text particales
set, some of which would never be engaged in code that is to be generated for
#ifdef MS_DOS. Yet it seems even if the coder's style places these into a
detectible case structure, if you parse all of the branches you will create
the possibility of combinations that do not make sense relative to any real
So, in addition to this comment I suppose I have the questions;
1) Does not parsing mutually exclusive syntactic subjuncts create an invalid
basis for program tables.
2) How do you prevent the cominatorics from expanding beyond the human
But your idea seems excellent. It would be nice to see how different compiles
would gen. It seems that such pseudo parsing, could reveal many bugs before
release of products that ship in source form. Yet it seems to me that the
document base compiler must be constrained somehow to a list of likely
settings for the conditional compile attributes.
The document parsermight then really only need to deal with one
of the combinations at a time.
Return to the
Search the comp.compilers archives again.