Re: gnubol: subsets

[RKRayhawk@aol.com]

In a message dated 11/25/99 11:28:14 AM EST, TIMJOSLING@prodigy.net writes:

<< 
 In IF, you are allowed to have zero or one conditional statement at the 
end.So:
 
 IF cond
     add a to b
     add c to d
          size error
               display ...
 .
 
 But I can't find any similar rule for evaluate. There could be such a rule, 
but
 there doesn't seem to be one.  >>


The situation is different for IF-THEN-ELSE and EVALUATE-WHEN, here COBOL is 
not so much an upstart.  Associativity works but the WHEN must be high 
precedence. High precedence will force all preceding open scopes to 
terminate. ELSE must have high precedence. END-IF and END-EVALUATE eat thru 
open scopes too, it is high precedence that does that. These tokens are 
distinguished from ON SIZE ERROR or INVALID KEY tokens by the higher 
precedence.

The trick is to fit the verbs into this mix. We want verbs to keep gluing 
into current scopes.

That is why as a first approximation it is better to view the procedure 
division as a set of conditional statements that have structures which 
include headers and attached blocks of code.

You can imbed conditionals inside of conditionals when properly delimited.

A special case conditional statement is the unconditional statement, nudniks 
call that an imperative.  An imperative with decorative unnecessary redundant 
explicit scope terminators or not is a properly delimited conditional (of the 
unconditional variety) that can be imbedded within other conditionals.

The top surface of the procedure division is a set of conditional statements. 
Some of which are of the unconditional variety. Nested within those 
conditionals are other properly delimited statements.

Thus the highest priorities are markers of conditionals, next are the scope 
delimiters,  next are the verbs.

Approximity.

But the markers for conditional clauses of constructs that have alternate 
conditionals are a challenge. First because there is no 
end-conditional-clause marker. Second we might simply need to make it 
invisible to the hierarchy that results from precedence specification. I 
think that very low precedence does that, but we can not let associativity 
glue or break the scan at the encounter point for the irksome conditionals.

Incidentally SEARCH WHEN clauses are mostly like EVALUATE WHEN CLAUSES in the 
precedence and associtivity senses. But that doesn't mean we can use a subset 
of one for the others requirements. We need to experiment and figure out how 
to untangle problems that will occur when one of these is imbedded in the 
other in the absence of its explicit scope terminator. We should be conscious 
of the tiny side effect that will occur when we specify the precedence of 
SEARCH, EVALUATE, WHEN, END-SEARCH, and END-EVALUATE.

In the abasence of explicit scope terminators I do not know how we will 
understand the next WHEN token. We can use associativity to keep gluing and 
if junk shows up that is the coders fault, except WHEN OTHER can not possibly 
glue to a SEARCH, and the SEARCH is permitted to be unterminated. Here to k 
is not equal 1, but the problem is also that WHEN OTHER should reduce the 
SEARCH where as WHEN whatever should shift on good or bad. So we will need to 
apply associativity with care and mark the precedence of this bunch with 
clear intentions.
 
But in sum, the ELSE/WHEN issue is different from the ON SIZE ERROR and 
related conditionals.  The ELSEs and WHENs burn right through verbs back to 
the previous [THEN] or previous WHEN or to the EVALUATE.

Best Wishes,
Bob Rayhawk
RKRayhawk@aol.com

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