Re: gnubol: Re: Magic tokens

[RKRayhawk@aol.com]

In a message dated 12/4/99 8:47:38 PM EST, TIMJOSLING@prodigy.net writes:

<< 
 This is why the problem with search and evaluate comes up.
 
 search a
       when x=a(i)
            evaluate b
                  when
 
                   when <<< who owns this 'when'
 etc
 .
 
 Now I know I am going to flag it anyway so but bison doesn't know and 
complains.
 >>


On this it may be useful for you to post the several variations you are 
trying (if easily isolated) and show us the 'problem' bison is having it each 
case. Since we can nest IF-THEN-ELSE inside of IF-THEN-ELSE with a tool like 
this we should be able to get the EVALUATE and SEARCH to nest (either way) 
even if they both have WHEN clauses.

Your posts to the effect of questioning what the standard  allows or requires 
vis-a-vis SEARCH and EVALUATE is a separate and significant question.

Generally I do not think we need special techiniques to get bison to nest 
these (that is no special hand-coded lookahead).

In my experience an EVALUATE inside of a SEARCH WHEN clause is not especially 
strange looking. In your example "evaluate b" is the construct still in scope 
any subsequent WHEN clause reduces the prior WHEN clause and glues onto the 
EVALUATE.  Others may differ. 

For me the only intrigue is a few steps away (not coded in your example); 
does a WHEN OTHER terminate the recurse into the EVALUATEs WHEN sequence and 
allow a subsequent  WHEN to 1) terminate the WHEN OTHER, 
2) terminate the EVALUATE, and 3) glue properly to the outer SEARCH: all in 
the absence of an END-EVALUATE, which is optional, right?

(I am confident that we can use precedent dummy tokens to precipitate a 
reduction of WHEN OTHER upon encounter with WHEN; and then get the 
undelimited EVALUATE to condense generally, but that is not your discussion 
point).

My sence of ease at this comes from the appreciation that context is 
recursive not sequential.

Let me make a few marks on your example to describe my point of view 
specifically
 search a
       when x=a(i)
            evaluate b
                  when c
  
                   when who <<< who owns this 'when'
 etc

While processing WHEN C we are in the WHEN rule. As that rule looks ahead and 
sees WHEN (of WHEN WHO), it reduces. But that just pops back to the recurse 
rule for WHENs within EVALUATES. That rule recurse on WHEN, it does not 
collapse on WHEN number 2 or WHEN number n.

Although we are inside of SEARCH and indeed inside of its "when x=a(i)"
sub-rule, that sub-rule is recursed into something like statements (or 
statement-block). You can not get out of there until the block recurse ends, 
amd since it is rotating recursively on the current statement EVALUATE, the 
statement-block rule has not yet popped.

You have described numerous changes you have made to the grammar which 
indicates that you are doing a tremendous amount of work. For which we are 
grateful. Isolating the WHEN/WHEN thing should be easy. If it feels okay post 
your alternative trials and snip in the bison feedback. There should be 
someone out here who can suggest eleviation of the s/r or r/r problems.

Yet the standards question about S in E, and E in S need to be addressed too.

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.