gnubol: Can anyone help test unterminated EinS and SinE

[RKRayhawk@aol.com]

In a message dated 12/5/99 5:07:37 PM EST, wmklein@ix.netcom.com writes:

<<  -----Original Message-----
   <snipped>
 > Yet the standards question about S in E, and E in S need to be
 > addressed too.
 >
 > Bob Rayhawk
 
 Can you explain to me exactly what the question is concerning this (or give
 me a code example that you have a question about)?  I think that given the
 strict "imperative" enforcement rule, I don't know of any problem with SEARCH
 contained in or containing EVALUATE.  (As I indicated in a previous note,
 there is a rule/question about SEARCH and "implicitly terminated"
 conditionals BUT that only applies when the SEARCH is in an IF/ELSE construct
 (where a conditional is allowed).
 
 
 Bill Klein
   wmklein <at> ix.netcom.com
 
  >>

It is really a code base issue.  One of the mainframe compilers seems to have 
generalized ability to imply scope termination for unterminated condtionals 
when nested in outer conditional statements.

In the easy cases where SEARCH or EVALUATE are explicitly terminated with 
their respective END-SEARCH and END-EVALUATE, there is no issue, those get 
treated like imperatives.

But when that is not the case, when the explicit scope terminator is absence, 
the language in manuals suggest that the compiler will recover by inserting 
implicit scope terminators.

You seem to be saying that SEARCH can only be implicitly scope terminated 
when floating unterminated in an IF/THEN/ELSE nest. Some of us are thinking 
that the problem may arise elsewhere.  Obviously we all realize that we can 
try to code a nested E in an S, or a nested S in an E. But the point really 
is going to have to be is a mainframe compiler accepting these with mere 
warning (not error) and genning code?

((Incidentally -E level diagnostics for unterminated E in S, or unterminated 
S in E would mean we do not have code base, but rather merely competitive 
robust parsers that will be hard to match)).

The implicit terminator insertion occurs when the compiler sees something 
that is clearly the outer statements next clause.  WHEN OTHER, for example, 
does not look like a continuation of a SEARCH.  END-EVALUATE might also 
arguably be a competent implicator for terminating a SEARCH dangling on the 
last WHEN of an EVALUATE.

Expertise is needed in two areas here. Are any compilers achieving this with 
SEARCH dangling unterminated in EVALUATE WHEN clauses, thus confronting us 
with possible code base.  If for any reason we choose to cosider attempting 
it, exactly what does the standard require?  Is this an extension? Are we 
required to flag it when parms say flag extensions? Can the flag waving be 
turned off parametrically, is that acceptable in the standard?

Must of the above are comments on a SEARCH within an EVALUATE. We can turn it 
around however, as I think you have seen discussion of already. Once an 
EVALUATE has garnered a WHEN OTHER clause, it is feasible to implicitly 
terminate it with a WHEN clause belonging to an outer SEARCH that owns the 
previous WHEN clause the SEARCH hangs under.  Again gymnastics is not our 
goal. Specifically, this issues may be relevant to some mainframe compilers 
that have generalized conditional implicit termination beyond the 
IF/THEN/ELSE context. I could be wrong. The issue is firstly a code base 
issue. And then depending what if anything that puts on our menu, standard 
compliance for 'extensions' of this type.

Perhaps someone can help test unterminated EinS and SinE.

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.