Re: Saving/restoring bison parse state

On 14 Oct 1997 00:37:36 -0400
tim@wagner.Princeton.EDU states


  >> 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 *****/
>> #else
>> /* branch 2 */
>> #endif
>>
>> 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
  axample, if
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
  possible resolutions


FUNC1_large(...)
FUNC1_medium(..)
FUNC2_large(...)
FUNC2_medium(..)




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
  case)


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
  compile.


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
  bandwidth.


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.
.
Robert Rayhawk
RKRayhawk@aol.com




--

Return to the comp.compilers page.
Search the comp.compilers archives again.