Re: gnubol: Siemans COBOL2000 - SEARCH and EVALUATE results

[RKRayhawk@aol.com]

I disagree, fairly strongly.  If the diagnostic can indicate where an assumed 
implied termination occurs, it just about tells the coder where to put the 
explicit terminator (in many cases). That enhances the coder's productivity. 

In some cases the fact that scope terminates (by implication) in a very 
surprising place is enough to get the coder way off that track and back to 
the original verb to see how to end it explicitly by intention. The end point 
of scopes as compiled is very useful to the coder, even if they know nothing 
about compilers, and don't like to here about 'explicit' and 'implicit'. They 
can still benefit from knowing the end point that evolved in loose code.

Indeed, a legitimate way to use COBOL is to code minimum explicit scope 
terminators. It is entirely reasonable to allow the compiler to indicate the 
few problems it has, and code 
END-xyz only in those places. 

We experienced programmers who like explicit scope terminators, and we 
compiler writers who would prefer them to be present, are really all together 
as a group off on the sidelines here. It is arguable that one of the effects 
of the accident of legacy code without terminators dragging the new compilers 
into mixed code context, is that we happen to have a standard that allows 
very efficient coding, because explicit scope terminators are not actually 
needed in quite a few circumstances.

Workers are much more productive as a result, and many of them literally rely 
on the compiler to tag those few corners where they were just too lazy. That 
is not bad, it is just real. Users of the compiler, in quite a few cases 
would like you to tell them where the explicit scope terminator belongs, or 
where the compiler has raised some assumptions of its own.

So I think that an embedded unterminated EVALUATE that does have a WHEN OTHER 
should be diagnosed differently from one that doesn't even have that. And the 
way to manifest that distinction is to indicate the end point, as well as the 
start point.

(So I agree with Michael and disagree with Jonathan, quoted in the following 
interaction).
But it is not just an error diagnostic design consideration.  One of the 
advantages of the evolved standard, is that coders can legitimately be lazy. 
Sometimes that will burn them. It is impotant to know that code, unterminated 
code for example, can work for a while; and then later, while not actually 
changed, can be newly nested in some other construct. Then the unterminated 
conditional matters. So old laziness needs new discouragement. This kind of 
maintenance really involves the end point, adn it would be nice if we can 
include the end line number in diagnostics about assumed implied termination.

In a message dated 12/13/99 3:16:08 PM EST, migrate@tiac.net writes:

<< At 11:14 AM 12/13/99 -0500, Michael McKernan wrote:
 >
 >I suspect that the terminator was not assumed at the same point in
 >each listing.  Too bad their diagnostic is not more specific.
 
 As well it should not.  In the first case the WHEN OTHER tells the compiler
 *unambiguously* that an END-EVALUATE has to follow the next statement
 block.  In the second case, regardless of indentation (which means nothing
 in the free-form), the last WHEN rightly belongs as part of the EVALUATE
 and *not* as part of the SEARCH.
 
 The period terminates all statements within the sentence (and the only
 thing to which I compare it, is the way a square bracket balances all
 unbalanced left parens in certain LISP implementations :-)
 
 Regards,
 Jonathan
  >>

--
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.