gnubol: Re: the X-WHEN stack

[RKRayhawk@aol.com]

In a message dated 12/5/99 6:29:17 PM EST, TIMJOSLING@prodigy.net writes:

<< 
 How do you tell who owns the WHENs with k=1 lookahead?
  >>

Admittedly a tool like bison will insist that we be very clear. I do not have 
a coded grammar that does this, yet it occurs to me that an EVALUATE that is 
in a SEARCH's WHEN clause is different from one that is not. By the same 
token :-)  a SEARCH statement that is in an EVALUATE's WHEN clause is 
different from one that is not.

At some point in time we will have both an E-WHEN rule and an S-WHEN rule in 
concurrent scope. While S-WHEN is the outer scope the lookahead token WHEN 
does not reduce it; but that is only true if an EVALUATE becomes a disruptor. 
WHILE E-WHEN is the outer scope the lookahead token WHEN does not reduce it, 
but that is only true if a SEARCH becomes a disruptor. Incidentally, an 
X-WHEN clause might be disrutpted for a while but the disruption ceases upon 
reduction of the internal statement causing the disruption; and hence it can 
happen multiple times. Importantly the disruption of the reductive 
distinction of a token is a sequential phenomenon within the block of the 
X-when clause.

To me the thing looks like lexical state. This lexical state has a stack 
characteristic that is essentially infinite in depth. 

In any block of code the parsing of a SEARCH token pushes the S-WHEN state 
onto the top of the stack.  In that mode 'WHEN' needs to bubble up from the 
lexer as S-WHEN, capable of reducing SEARCH WHEN clauses, and commencing the 
next. 

In any block of code the parsing of an EVALUATE token pushes the E-WHEN state 
onto the top of the stack. In that mode 'WHEN' needs to bubble up fromt the 
lexer as E-WHEN, capable of reducing EVALUATE WHEN clauses, and commencing 
the next.

The rules for EVALUATE can only see the E-WHEN token. The rules for SEARCH 
can only see the S-WHEN token. (Assuming that no other statement can ever see 
'WHEN') an actual WHEN token is simply unexpected. 

Clearly END-SEARCH pops S-WHEN off the stack, and END-EVALUATE pops E-WHEN 
off the stack.  The stack never goes negative (hand-shaking code might want 
to confirm that a negative transition attempt on the X-WHEN stack corresponds 
to an unexpected END-E/S.)
Also the stack popper needs to be harnessed to implicit scope termination 
logic, which since I am sane I will not try to sketch.

In any given block the stack can be pushed and popped repeatedly, 
representing a sequence of scope delimited statements within the block which 
may hang on a WHEN branch, or anywhere else, including open code.

Further I think we need some kind of X-WHEN stack owner. So that when we 
cross certain boundaries we need not worry about popping, we delete the whole 
stack. For example, probably EOS, paragraph boundaries and section boundaries.

This is a hack, and a hack is a hack.  But the COBOL language is nasty 
hereabouts. But this is rather more in the nature of a fairly recognizable 
lexer state. We can not use bison's state architecture (assuming for the sake 
of illustration LR) because it is merely bi-modal, even if you have exclusive 
and non-exclusive states: we will need a stack structure.

I think this is better than hand coded lookahead, which I characterize as 
courageous because there are so many nesting possibilities and permissible 
sequences that you could encounter things in the near vicinity that are not 
what they seem to naked scan ahead. Furthermore, it is courageous in that an 
interplay between the selected grammar tool's lookahead and the hand-coded 
one can make some example parses very inscrutable it seems, but that is just 
opinion.....

The ambiguity of WHEN is a real assault on a tool like bison. It warrants 
consideration of a hack. 

Bob Rayhawk













--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.