Re: Parsing nested statements: was Re: gnubol: subsets

[RKRayhawk@aol.com]

We have two examples criss-crossing here that are different. This example, I 
think you originated, was considered.

  IF a > b
      display ...
      add a to b
             on size error
                     display ...
  ELSE
      display ...
       subtract retro-adjust-factor from running-total
               on size error
                    display ...
  END-IF

The IF statement is imperative. But the interior arithmetic statements at the 
end of the blocks are a different consideration as we do not need an 
imperative there. The presence of the ELSE and or the END-IF delimits the 
block. This is somewhat comparable to handing some conditional I/O verb off 
at the end of a block attaching to an arithmetic verb. That really does not 
cause a problem.  Arithmetic hanging on arithmetic and I/O hanging on I/O 
conditional clauses are a challenge.

You see an I/O verb can not terminate any open conditional arithmetic clause 
it just keeps on trucking no matter how many conditional clauses are added 
onto the I/O verb.  And vice-versa.  But wht that means, and this is it if 
you want to access it from this point of view ... arithmetic verbs do not 
terminate the scope of previous arithmetic verbs when they occur in the 
conditional clause. SInce that concurrency commences the next arithmetic 
conditional is in suspense until we can figure the edges of the new 
arithmetic. It is a bit of a dragon, but in this first IF statement there is 
not problem ELSE burns like acid thru the I/O, the arithmetic, the COMPUTE, 
the PERFORM, it burns and burns and burns and just fires its way right back 
to the [THEN] which humorously enough is an optional token, but not an 
optional clause (((triple aside, so when THEN clause code dies ob 
obsolessence people are led to jam a NEXT SENTENCE, oops, in there, so they 
can avoid touching the ELSE or worse inverting the conditional... it all fits 
together. NEXT xyz frequently marks historical structure that people are 
intelligent enought to let lie.  It is just that the world is not straight on 
this NEXT PARAGRAPH thing yet because it is not on their desk top, and they 
just insist on the old code working, and by the way they enjoy monkeying with 
the periods.))) Any way ELSE and END-IF have precedence. They also can not be 
seen as continuations of arithmetic or I/O verbs, so all such open rules need 
to reduce intantly.

WHEN is like that in EVALUATE structures.  As is WHEN in SEARCH constructs, 
and don't mix gasoline and matches. Anyway, this other sample code floats in 
here too, ....

<<
if a>b
   display ...
   add a to b
          size error
                display
                 subtract c from d
                      size error
                          display ...
end-if
.

>>
This too is one of your many nifty inventions. So here the END-IF should 
blaze its way unobstructed back to an ELSE (and failing that the [THEN]). And 
I find myself wondering if I have worked my words carefully enough in all the 
examples.  This example has problems.  I think in some of my intervening 
examples I variously peppered such inner arithmetics with explicit scope 
terminators.   I may have mistated or poorly phrased some of the ideas. The 
ELSE and the END-IF do not make explicit scope terminators, but they 
definitely terminate stuff. 

But in the example at the top of this page there is not problem in either 
branch of the IF-THEN-ELSE because the conditional clause of the arithmetic 
statement does not contain an arithmetic statement. In the examples I posited 
in the inter actions, any drawing out of those forms with inner arithmetics, 
was intended to show that you would need the explicit scope terminator to 
control the meaning.  An ADD/SIZE/SUBTRACT/NOTSIZE/END-ADD glues in the way 
that ignites controversy, in the THEN  clause, the ELSE clause, all WHEN 
clauses, in open code, even inside of I/O verb conditional clauses.

ADD/SIZE/SUBTRACT/NOTSIZE/END-ADD might surprise some, but it is necessary if 
the conditionals are to be non ordinal. I believe that invovles genius 
insight into the cost of labor. It is easier to find coders who will 
transpose the conditionals willy-nilly, then it is to find geeks like us who 
grok associativity.

I believe that 
ADD/SIZE/SUBTRACT/NOTSIZE/END-ADD warrants a warning message no matter where 
it takes up residence.

Now this little puppy
ADD/SIZE/SUBTRACT/NOTSIZE/END-SUBTRACT
gives permission to glue things inside, and is sufficiently explicit to be 
without need of any kind of message. Both the inner and the outer arithmetic 
statements in these bundles are imperative (strange though it may be).

Any how, my musings on that was to try to show how things can be kept straigh 
in side the [THEN] and ELSE clause should one decide to go beyound the 
simplistic structure at the top of this page. .... which you did in the 
second structure.

The subtract oustensibly has a conditional clause, but there is not explicit 
scope terminator for the subtract, so we can not assume to interpret it as an 
imperative. It would be a conditional, which can be what the coder intended: 
because this thing is hanging on another arithmetic statement and you are not 
allowed to hang a conditional statement on a conditional clause, this is the 
twist that turns different ways for different folks. So we must interpret the 
inner arithmetic as a simple arithmetic, which means the syntax conveys the 
intent to attach the conditional onto the preceding concurrently open outer 
arithmetic.

When we have 
  ARITH ...SIZE ... ARITH ... SIZE  ... never-never-land-here

a first glance leads one to believe that the coder intended to try to glue 
the inner conditional clause to the inner arithemtic, when we have
  ARITH ...SIZE ... ARITH ... NOT SIZE  ... never-never-land-here

we come to our senses, realizing that that is the same challenges as

  ARITH ...NOT SIZE ... ARITH ... SIZE  ... never-never-land-here

so obviously
  ARITH ...SIZE ... ARITH ... SIZE  ... never-never-land-here

is just the kind of special case that helps us see that this is not 
associativity, but instead deep lookahead.  The absence of a correct matching 
END-arith for the inner arithmetic forces us upon deep lookahead encounter to 
inerpret the inner arithmetic statement as simple and imperative, because in 
many such cases that is just exactly what the coder wants because they too 
can read. If you are not allowed to code a conditional in there whey would 
the compiler writeres first guess be conditional! Can't they read.

Watch this ... just a part not a complete, I'll just trail off

  ARITH ...SIZE ... ARITH ... SIZE  

at that second SIZE you simply cannot decide if the second SIZE is an error 
or lefitimate code. For example, 

   ADD ... SIZE ... SUBTRACT ... SIZE

might continue

   ADD ... SIZE ... SUBTRACT ... SIZE ... END-SUBTRACT.

It is the END-SUBTRACT that legitimates it, and it might well be ten miles 
away from the SUBTRACT.  My proposition is the END-ADD also works, it just 
produces a different reduction sequence.

It like the conditional clause markers are anti-super-glue.  In the following 
you do not know exactly which type of error the third conditional is upon 
firts encountering it.
  
   ADD ... SIZE ... SIZE ... ADD ... SIZE

If the continuation is 

   ADD ... SIZE ... SIZE ... ADD ... SIZE ...  END-ADD

then the third SIZE clause is not an error at all!

The transposibility of the alternating conditional clauses defeats 
associativity as a tool.
  
So inside of you second invention, to wit, ...
<<
if a>b
   display ...
   add a to b
          size error
                display
                 subtract c from d
                      size error
                          display ...
end-if
.
>>
There is a problem, and the problem is that the outer arithmetic statement, 
the ADD, has two size error clauses. This problem is not help, hurt or 
impacted by the fact that it is in a [THEN] clause, in the sense that if you 
floated this anywhere else without the necessary explicit scope terminators, 
it is still a problem, but I think rather easily diagnosible. The following 
modified version of your second example do not have a problem, although one 
can be irksome.

if a>b
   display ...
   add a to b
          size error
                display
                 subtract c from d
                      size error
                          display ...
                 END-SUBTRACT *pretty clear, everything reduces near by
end-if

But this one revisits the same problem, here END-ADD does what END-IF did

.if a>b
   display ...
   add a to b
          size error
                display
                 subtract c from d
                      size error
                          display ...
    END-ADD *  duplicate size error clauses on ADD 
end-if
.
 These exact examples work out differently for the situation where the 
interior conditional clause is the alternate (that is NOT ON SIZE ERROR), as 
far as error, or acceptable, or warning. But the NOT does dot dertemine 
associativity. I hate to say it but the _type_ of the clause determines that. 
And the type is determined by the presence or absence of a matching explicit 
scope terminator.

What is important is that the code base has been generated through keyboards 
managed handled by folks who transpose the conditionals. COBOL is not a 
lanuage that can be completely managed by associativity. But there are places 
where that helps.

Best Wishes
Bob Rayhawk
RKRayhawk@aol.com

P.S. If you hate all this just keep in mind that by the following code
 SUBTRACT 1 from squirly
    ON SIZE ERROR
       ADD c to d
     NOT ON SIZE ERROR
        DISPLAY "please interpret this message"
  END-SUBTRACT.
 
Might mean two different things, one meaning is allowed the other will not 
happen for them. Interstingly enough, most of the examples we bandy about 
decent from the original most one by Laura, and have had us focuses and ADD 
and SUBTRACT.  In the following, maybe the matter seems more important

 MULTIPLY mega TIMES mega GIVING  giga
     ON SIZE ERROR
        ADD 1 to intermediate-calc-error-count
     NOT ON SIZE ERROR
        ADD 2 TO like-is-copesetic
  END-MULTIPLY.

I think life will be what it seems, some think life can only be copesetic if  
tracking the error count goes peachy-keeno. 
My proposition is that that first interior ADD is a simple ADD, is an 
imperative ADD, and that is what they mean, because the standard told them to 
never code a conditional ADD in there, so they didn't and why can't we see 
it. It is after all the simplest interpretation.  

It is the tools that make us want to go after the longest interpretaion, that 
is the tool language not COBOL. Think COBOL.  Tools lead us to think 
associativity. Alternate conditional clauses do not associate, these monsters 
go into suspended animation, ... promise ya'. 

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.