gnubol: Braiding #1 #2 #3

[RKRayhawk@aol.com]

In a message dated 11/28/99 2:48:19 PM EST, TIMJOSLING@prodigy.net writes:

<< 
 Maybe it isn't clear actually; we need some results from actual compilers.
 
 However lets say the not size binds to the subtract.
 
 add
     size
         subtract
             not size
                display.
 
 How would you specify both size and not size for a verb? The only way you 
seem to
 be end-verb for the nested verbs. But end-verb existed only since cobol 85, 
and
 size/not size from memory predate this. So this interpretation would break
 existing code. Which is not likely to be correct.
 
 Thus I predict the not size will bind to the add.
 
 Tim Josling
 
  >>

That is exactly it. It is the owners of the legacy code who count, not the 
vendors. When you look at it as a legacy code issue, the discussion 
simplifies. We have tripped into an interaction that tries to determine where 
the various conditional clauses glue. That it not the point.  The point is 
that the coder must be able to have an inner  simple arithmetic statement 
reduce, without the redundant END-arith. There is, however, no 'predicting' 
necessary. These are charted seas.

You could build extraordinary complexity out on that  NOT SIZE ERROR clause 
as long as 
you do not drop an unmatched END-SUBTRACT onto it. It will bind back to the 
ADD header, no matter how complex. And that is food for thought, because you 
are certainly allowed to put scope delimited SUBTRACTs out their, just not an 
unmatched END-SUBTRACT, because then it condenses differently. This is not 
associativity. This is concurrent scopes, which must be resolved by the 
presence or absence of a lookahead tokens.

I have been studying this with bison. The matter involves braiding. There are 
three kinds of
braids.
 
Braid # 1 The conditional clauses are alternate positive and negative 
branches of a verb construct. This applies to much more than merely the 
arithmetics. The coder is allowed to deploy the clauses in either sequence, 
in this regard they do not have requisite ordinality. However, the standards 
say that an undelimited inner arithmetic may not have conditional clauses, 
and when such clauses are encountered they are to be bound to the previous 
arithemetic that does '...not...' have '...such...'.  This means we must find 
the antecedent.

So the grammar mechanism that supports braiding must track, via explicit 
rules, the alternate that started the sequence in order to be able to capture 
the alternate that completes the pair. This can be visualized as braiding as 
it can go many layers deep, for explicitly delimited inner conditional 
statements (which some vendor say revert to 'imperative' upon delimiting). In 
any given cicumstance clauses which look like they are inside, are actually 
scopically outside, and must fly past the inner simple arithmetic (because it 
can not be conditional!). And of course excess flyouts can occur. So there is 
an antithesis to "...not...such..." as well as an antecedent.

Braid # 2 Is a separation over time of the actual reduction of rules that 
have some portion of 
their scope concurrent.  Take for example when a super implicit scope 
terminator comes along and ends everything currently open. Loosely speaking 
that happens at one point in the source code, sometimes we can even identify 
the period as the singularity. But in the execution sequence of the compiler, 
reductions do not occur all at once, they occur in sequence. It is really 
important to understand the scopes that could all collapse at once, and 
understand what the actual sequence will be. It is profoundly difficult to do 
that at even just a shallow level. 

But it is useful to keep focusing on the back and forth nature of the 
reductions, as the reduction itself lands a distinct token on the end of the 
stack, thus precipitating the next condensation. Very often it is the scope 
terminator (explicit or implicit) that actually constitutes a mismatch as a 
lookahead for certain concurrent scopes and obsolesces them; but that can 
happen sequentially as reducing rules eliminate certain concurrent and 
competing interpretations of the code ((The inner arithmetic that could be a 
simple unterminated or the begining of another conditional is particularly 
vexatious; as we contemplate it, by definition, as on inner scope)).

Braid #3 Is good luck and bad luck.

It is good luck because it never quite braids, it just tries to.  It is bad 
luck because it means scopes are much much larger than some recent posts have 
suggested.

Obviously arithmetic conditional statements can glue on and on and onto one 
another as long as they have the proper explicit scope terminators, and have 
their cluases in order. But this is true of all conditionals.  And they glue 
to one another.  It goes on and on! ADD does not terminate the scope of a 
conditional ADD statement. ADD also does not terminate the scope of a 
conditional I/O statement.  STRING OVERFLOW conditional clause glue and glue 
and glue, also.

All of these conditional statements are capable of having embedded concurrent 
scope (my terms).  To do this requires exquisite use of the lookahead 
mechanism. But no scope started inside of annother scope can go further than 
the outer scope. So we get intricate two dimmensional braiding around the 
alternates, but we do not get a third dimmension of braiding as amongst the 
distinct categories of conditionals.  In fact the categories are a little 
misleading. ADD is almost as distinct from SUBTRACT as either is from READ. 
It is just that some of the conditionals can be subsetted by the tokens that 
kick off the conditionals. Once you see that you see short cuts but you also 
see how big this issue really is.

This can all be contrasted to the IF/[THEN]/ELSE/END-IF. When you look back 
it is a joy to see that its clauses are ordinal. They do not braid, although 
they permit deep recurse.

EVALUATE WHEN clauses are like IF/THEN/ELSE in that they are really ELSE-IF 
clauses
(except the first which is a [THEN] clause). Still no braiding, and 
essentially a recurse, although it is important that EVALUATE WHEN can be 
handled as a sequence, that is important because it means we can reduce 
quickly. EVEN WHEN OTHER is just another recurse ELSE-IF-ALWAYS, or just the 
last sequence.

SEARCH has similarities to EVAL, but we have the complication of the AT END 
clause. I don't recall ever seeing an NOT AT END on a SEARCH, and suppose 
that it is not possible. But in any event we can treat the whole set of WHEN 
clauses as the NOT AT END clause.
I do not know if the SEARCH statement has ordinal requirements. It might 
braid also, I hope not.

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.