Re: Infinite Loops and Explicit Exits

From: Lueko Willms (l.willms_at_jpberlin.de)
Date: 11/02/04 

Date: 01 Nov 2004 23:28:00 GMT

. On 29.10.04
  wrote charles.stevens@unisys.com (Chuck Stevens)
     on /COMP/LANG/COBOL
     in clu41g$1t2b$1@si05.rsvl.unisys.com
  about Infinite Loops and Explicit Exits

CS> One of these proposals relaxes the current restriction that an EXIT
CS> PERFORM or EXIT PERFORM CYCLE statement may only appear within a
CS> PERFORM ... END-PERFORM range.

   I put here my answer which I had written answering another message
by you, since this message had, as I saw on groups.Google.de,
generated quite a debate, and I think that my answer should be here.

   I will add some observations on loops in general which had been
discussed unter "Report enhancements" and then "Perform loop
enhancements".

. On 28.10.04
  wrote charles.stevens@unisys.com (Chuck Stevens)
     on /COMP/LANG/COBOL
     in clro7b$9sf$1@si05.rsvl.unisys.com
  about Re: Perform loop enhancements

>> Too bad that ability isn't complete.

CS> Which ability? The ability to do an EXIT PERFORM CYCLE in an
CS> out-of-line PERFORM? Yeah, I think I'd argue for that, unless
CS> (again) somebody can convince me it's a bad idea!

   I think it is a _very_ bad idea.

   A "PERFORM some-procedure UNTIL some-condition" is something which
I would avoid, since the ripening of the condition which leads to the
termination of the loop is not visible at that point. One should
better PERFORM a sequence of local statements (which might be calls to
remote procedures via PERFORM or CALL or INVOKE or FUNCTION) where the
terminating condition is visible in that context.

   To introduce a condition _within_ such a remote procedure being
PERFORMed in a loop which terminates the loop under a _different_
condition than the one formulated on that procedure call, i.e. PERFORM
itself, is really obfuscating the flow of the program.

   One would have a statement which calls a remote procedure in a
loop, stating the conditions under which this looping execution is to
be terminated (or not started at all), where we would normally expect
that this remote procedure is somehow producing the condition which
was named on the call-loop instruction, so that this loop terminates.

   You now want to allow this remote procedure, not visible to the
looping-call statement, to simply terminate the loop, possibly
_without_ the termination condition specified on the loop-call
instruction, to terminate the loop. Normally one would assume that the
terminating condition on the loop instruction is a valid assertion
that the next statement following that loop-call instruction can rely
on, but what you propose, makes that assertion invalid or dubious.

   I advise against such obfuscation of program flow, and I hope that
my argument has been convincing.

   Let me add that allowing to break a loop in a procedure being
executed by a COBOL statement "PERFORM some-procedure UNTIL some-
condition" in that remote procedure might have been seen as necessary
in a pre-1985-COBOL, but not today, where COBOL provides the
statements to formulate proper repetitions.

   I would instead recommend to do away with any "PERFORM some-
procedure UNTIL some-condition" and replace it with either a call of
that procedure by a simple PERFORM within a local loop (i.e. some
"PERFORM imperative-statement END-PERFORM", or to organize that remote
procedure as a loop. I think it is important to see how the
terminating condition for the loop is coming into being right where
the repetition and its terminating condition is being formulated, and
not seperate the two by what may be pages or screenfuls of other
statements.

   There are three conditions which prompt to repeat a sequence of
statements:

   1. when one knows beforehand, how many repetitions are being done,
e.g. when you know that the fairy queen offers three wishes, you will
"PERFORM the wishing 3 TIMES";

   2. when one knows that there is a finite number of occurences of a
given object, then one formulates a termination condition like that
there can no more objects be fetched for processing, and one will
write in COBOL a "PERFORM UNTIL some-condition ... END-PERFORM".

   Consuming a file is one of those cases.

   Both of the above can be accompanied by VARYING some counter.

   3. Only under condition that there is really an infinite number of
events which have to be processed, like the queues in the operating
system of a computer, or the cars arriving at some toll station, or
any other steam of conceptually non-terminating stream of events would
it be proper to write something like "PERFORM FOREVER some-action END-
PEFORM", and then the "FOREVER" would really a best keyword to express
this conceptually infinite stream.

   As to reading a file, one has to consider that for a file of n
elements, one has to do n + 1 attempts to fetch a new item from the
file, in order to process the n elements in the file.

   Therefore the proper repetition for such a process is not to
formulate a sequence which is performed n + 1 times, i.e. once for
every _attempt_ to fetch an item, but where this sequence needs to be
broken in the middle to avoid processing of an empty, non-existing
item. The proper way is to organize a loop which begins with the valid
assertion of an item being present, and ending with the attempt to
fetch the next item, and to do a first attempt _outside_ and _before_
that loop, which enables the program to determine very simply if the
file contains any items at all.

   So far till now.

Yours,
Lüko Willms http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Er liebte hauptsächlich die Wörter, die nicht in Wörterbüchern vorzukommen pflegen. -G.C.Lichtenberg

Relevant Pages

  • Re: Infinite Loops and Explicit Exits
    ... > CS> One of these proposals relaxes the current restriction that an EXIT ... > termination of the loop is not visible at that point. ... > terminating condition is visible in that context. ... > You now want to allow this remote procedure, ...
    (comp.lang.cobol)
  • Re: Python indentation
    ... Christopher T King schreef: ... >> Well personnaly if i have a loop with the terminating condition ...
    (comp.lang.python)
  • Re: strlen(), K+1: clarification
    ... The new terminating condition is a comparison with 0, ... remarked that one should choose the most natural form for a loop. ... counting down are equally appropriate. ...
    (comp.programming)
  • Re: im REALLY sorry...
    ... where is the terminating condition? ... The loop will continue executing for as long as $rows_returned>0. ... You haven't done much programming, ...
    (comp.lang.php)
  • Re: Houston-related rants was Re: forced merges/inside lane merges/AASHTO "tapered merges"
    ... >> Are you sure about the North Loop and I-45? ... >> in particular the westbound exit for Fondren/Gessner. ... How could HCTRA put an exit ramp for eastbound ... and the West Houston Center Blvd exit still shows Old Westheimer ...
    (misc.transport.road)