Re: gnubol: subsets

[RKRayhawk@aol.com]

In a message dated 11/24/99 6:40:03 PM EST, 
a ponderous Michael McKernan, mck@tivoli.mv.com writes:

<< 
... and I'll cite this excerpt from the '85 standard.
 (paragraph 6.4.3 Scope of Statements, pg IV-40)
 
 "When statements are nested within other statements which allow
 optional conditional phrases, any optional conditional phrase
 encountered is considered to be the next phrase of the nearest
 preceding unterminated statement with which that phrase is permitted
 to be associated according to the general format and the syntax rules
 for that statement, but with which no such phrase has already been
 associated.  An unterminated statement is one which has not been
 terminated either explicitly or implicitly."
  >>

I am not trying to stretch a point, but because I see code base that varies 
from your interpretation I think the following is worth a try. Note the 
wording " ... is considered to be the next phrase  ...". Note the word "... ne
xt ...".  That perhaps means just what I am saying.  I am not trying to win, 
I am just trying to show how it _could_ mean that.

In this example,
LINE 100    ADD a TO b
LINE 200        ON SIZE ERROR 
LINE 300           SUBTRACT q FROM p
LINE 400               NOT ON SIZE ERROR ...

The NOT ON SIZE ERROR on LINE 400 can not be the "... next ..." phrase of the 
SUBTRACT because we have not encountered the first phrase for the SUBTRACT. 

However,  with the standard quote in hand the following code does not work 
the way I explained, although I am going to advocate the same result I did 
previously

LINE 100    ADD a TO b
LINE 200        ON SIZE ERROR 
LINE 300           SUBTRACT q FROM p
LINE 400               ON SIZE ERROR ...

(Note that here the NOT is absent on LINE 400)
With this line 400, the standard does not say that the second clause is to be 
associated with the outer arithmetic statement now, because of its way of 
wording what I call the duplicate clause problem.  But if you munch on the 
first morsel here, what we may need to be in the business of doing is to 
think that LINE 400 is a "...next ..." of some kind, which means that it can 
not glue to line 300, because it does not have its first. So if it also does 
not glue to LINE 100 because that line already had  "...such ...".  I don't 
see that as saying your interpretation is correct. Instead, LINE 400 does not 
glue, it flies off. 

My overall suggestion is that we do not let anything we can anticipate fly 
off into error recovery mode (using that term technically). The quoted 
standard does not say what to do. The ice wears thin under me here, but I say 
it adheres to LINE 100, but is correctly diagnosed as a duplicate there.  It 
can not glue to LINE 300, because we are not able to see it as LINE 300's 
"...next..."

but the whole thing is cured in the cement sense, by a
LINE 500 END-SUBTRACT
which by vent of bodacious lookahead glues LINE 400 to LINE 300, piece of 
cake, because we no longer need to be trying to fit it as a "... next ...".

An exit light can be seen from this murky strangeness when you glare at "... A
n unterminated statement is one which has not been
 terminated either explicitly or implicitly ..." You see all you need to know 
is that the past perfect "... has not been ..." is really future perfect in 
geek speak.  In fact it is future perfect negation rendered by deep lookahead 
discovery of the absence of the explicit scope terminator, which likely must 
be commuted through your rule hierarchies by _statement_type_ reflected in 
alternate subsetting of arithmetic/I-O rule formats.

The ever gracious Michael McKernan, mck@tivoli.mv.com also writes:

<<
That and my faith that J4, annoying as they may be at
times, is not consciously being malicious.
>>

'Tain't hardly nice, but not especially malicious either, just COBOL.

As far as I can tell one big vendor manages to jam an implied scope 
terminator into an imaginary line 300.5

LINE 100    ADD a TO b
LINE 200        ON SIZE ERROR 
LINE 300           SUBTRACT q FROM p
LINE 300.4*now you see me
LINE 300.5             IMPLIED-END-REAL-BUT-NOT-CORPOREAL
LINE 300.6*
LINE 400               NOT ON SIZE ERROR ...

LINE 100    ADD a TO b
LINE 200        ON SIZE ERROR 
LINE 300           SUBTRACT q FROM p
LINE 300.4*now you see don't
LINE 300.5             ! NOT ! IMPLIED-END
LINE 300.6*
LINE 400               NOT ON SIZE ERROR ...
LINE 500        END-SUBTRACT

This phantom redirects the adhesivity of LINE 400. Piece of cake. It is 
instantiated by the potentially very distant END-SUBTRACT casually sketched 
here as LINE 500; not piece of cake, not k=1.

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.