Re: gnubol: Search and Evaluate tests

[RKRayhawk@aol.com]

You have been generous with you time to test and your Test4 is crafty indeed.

In a message dated 12/7/99 6:07:42 PM EST, wmklein@ix.netcom.com writes:

<< 
 000519  400-Test4.
 000529         Search All Tabl
 000539             At End
 000549                 Evaluate Tst
 000559                   When "X"
 000569                   When "Y"
 000579                     Display "When 3"
 000589                   When Other
 000599                     Display "Other 2"
 000609*                End-Evaluate
 000619             When Elem1 (ind) = "Z"
 000629                 Evaluate True
 000639                   When Elem1 (ind) = Elem2 (ind + 1)
 000649                     Display "When 4"
 000659*                End-Evaluate
 000669           .
  >>

This situation has three problems. Least obvious but important the SEARCH 
does not have
an explicit scope terminator, instead it has a period (EOS) implicit scope 
terminator.  Your Test2 suggests that this problem causes no difficutly for 
the compiler you used: the increasingly respected Fujtisu compiler which, 
IIRC, descends from the Ryan-MacFarland compiler, and is a mature product.

I believe that we should be able to recover unterminated conditionals whether 
the implication
comes form EOS, next paragraph, next section, END-PROGRAM, EOF, or the next 
IDENTIFICATION DIVISION in a nested program.  Atleast the simple one deep 
type as in Test2.  Here in the quoted Test4 we have a combination.

The combination is that the second EVALUATE is also not terminated. I am 
convinvced that we could capture that kind of situation even when there are 
two unterminated conditionals that have their scope implicitly or assumedly 
terminated at the same apparent point. I have not read forward in the mail 
bag to see if anyone has posted notes from a trial of this on Big Blues 
boxes. But harkening back to the arith conditionals stacked unterminated, 
there were detection points where multiple nested unterminated conditionals 
callapsed together.  I believe that is possible, essentially infinitely.  I 
think stacking open unterminated same conditionals is dubious at levels two 
and beyond. (as in ADD ON SIZE ERROR ADD ON SIZE ERROR). But stacking 
conditionals of distinct families is more rationals (as in SinE and EinS).

The point is that we need to construct the parser to see the line 669 
situation for what it is, several problems are happening together. We need to 
detect it no matter what we want to do
about it. I am all for keeping it open to potentially allow it as extension, 
and alternatively to tag it as error: allowing some externalized file to set 
the severity level. In the arithmetic conditional stack there is a divergence 
of code base. It will be interesting to see what the pattern is here (and 
whether the compilers are self consistent).

The third problem that occurs at line 609, the absence (due to commenting 
out) of the explicit scope terminator for the first EVALUATE is definitely 
recoverable, because of the presence of the WHEN OTHER. Again, we must detect 
this situation to diagnose it. I would be in favor of keeping open the 
possibility of variably permitting it or diagnosing it as error; the choice 
determined by an external file.

The situation where there is not WHEN OTHER clause is not recoverable.

But with the posted Test4 that you so elegantly constructed, we actually must 
construct a compiler that will see clearly each of those three distinct 
problems; and they are therefore potentially recoverable. We can hard code 
extension, hard code error trap, or externalize the
choice. But we can not escape the need to detect every aspect of the test.

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.