Re: Infinite Loops and Explicit Exits

From: Chuck Stevens (charles.stevens_at_unisys.com)
Date: 11/08/04 

Date: Mon, 8 Nov 2004 09:58:46 -0800

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9KErjo-eflB@jpberlin-l.willms.jpberlin.de...

> I would prefer to avoid such a task, and I guess anybody else also
> prefers not to touch this monster, and its fate will be to be replaced
> completely by a package bought or by a complete rewrite in another
> language and, probably, on another platform.

That may not be an option for a production program. That may in fact be the
*long-term* result, or it might not.

> But I would guess that this half-million-line monster can be melted
> down to at most half of those lines, if not even more, and be speeded
> up at the same time.

Maybe, maybe not! ;-)

> CS> There are cases in which EXIT PERFORM is, I think, clearer than GO TO
> CS> <some-arbitrary-paragraph-somewhere>.
>
> That's why it is in the current standard. But I took issue with your
> proposal to allow it to effect a statement like this:

> MAIN SECTION.
> LOOK-AT-THIS.
> PERFORM procedure-name-1 UNTIL condition-1
> PERFORM some-other-procedure
>
> where "procedure-name-1" is somewhere else in the source code, and
> might look like this:
>
> A)
> procedure-name-1 SECTION.
> BEGIN.
> do-something-here
> IF condition-2
> THEN
> EXIT PEFORM
> END-IF
> do-something-else

EXIT PERFORM in your example A would take you to immediately after the
currently-active PERFORM, which is the first one -- in other words, it would
take you to PERFORM some-other-procedure. You wouldn't execute
<do-something else> and you wouldn't test <condition-1>. You'd be done.

> instead of
>
> B)
> procedure-name-1 SECTION.
> BEGIN.
> do-something-here
> IF condition-2
> THEN
> GOTO ENDE OF procedure-name-1
> END-IF
> do-something-else
> .
> ENDE.
> EXIT.

EXIT PERFORM CYCLE would be functionally equivalent to GO TO ENDE OF
procedure-name-1 in this example, I think.

> But the EXIT PERFORM above does something completely different from
> the GOTO in the second example, or in the third example given here:
>
> C)
>
> procedure-name-1 SECTION.
> BEGIN.
> do-something-here
> IF condition-2
> THEN
> EXIT SECTION
> END-IF
> do-something-else
> .

That too is the equivalent of EXIT PERFORM CYCLE, not EXIT PERFORM, in my
proposal. So my response is "Yes, this is different, it doesn't do the same
thing. That's correct."

To get the analogous functionality to EXIT PERFORM, I think you'd need to do
one of two things:

MAIN SECTION.
LOOK-AT-THIS.
     PERFORM procedure-name-1 UNTIL condition-1
     PERFORM some-other-procedure
...
    procedure-name-1 SECTION.
    BEGIN.
      do-something-here
      IF condition-2
      THEN
            SET condition-1 TO TRUE
            GOTO ENDE OF procedure-name-1
      END-IF
      do-something-else
      .
    ENDE.
      EXIT.

or

MAIN SECTION.
LOOK-AT-THIS.
     PERFORM procedure-name-1 UNTIL condition-1
COME-BACK-TO-HERE.
     PERFORM some-other-procedure
...
    procedure-name-1 SECTION.
    BEGIN.
      do-something-here
      IF condition-2
      THEN
            GO TO COME-BACK-TO-HERE
      END-IF
      do-something-else
      .
    ENDE.
      EXIT.

There are other ways to do this, of course! But of the two, I personally
prefer the first.

> But A) would cause something completely different: independently of
> the value of condition-1, it would break the loop and cause the
> program to continue with "PERFORM some-other-procedure".

Yes, that's true.

> And this, the possibility that the condition-1 which guards the
> repetition in the main loop statement is being overrun by some minor
> condition in the PERFORMed procedure is the additional obfuscation
> which the current standard explicitly prohibits, and with good reason,
> and which your proposal would make possible.

It would. That's one reason I am also proposing the Dijkstra-esque
"indefinite PERFORM" alongside it. As a matter of *style*, in fact, I'd
prefer the termination decision be one place or another in a given
PERFORM -- either in the UNTIL clause or in the conditions under which EXIT
PERFORM is executed (and thus the PERFORM UNTIL FALSE functionality) -- but
I don't agree that the *only* appropriate place to put that conditional
logic is on the UNTIL clause, and that the programmer should be obligated to
do what is necessary, be it GO TO ENDE, SET <condition-name> or both, to get
there.

> That is why I object to it, and strongly.

> BTW, it would be better to write instead of A), B) or C) this:

> D)
> procedure-name-1 SECTION.
> BEGIN.
> do-something-here
> IF NOT condition-2
> do-something-else
> END-IF
> .
>
> Shorter, simpler, safer, easier to understand.

Not clear that it's exactly parallel, though!

> The programming langage should provide the means for elegance.
> Begining with COBOL-85, this is really possible by using COBOL.
>
> Elegance comes with simplicity and appropriateness to the task.

I agree absolutely. That's why *my* preference (with or without sections)
is that the programmer be *allowed* to do this.

LOOK-AT-THIS.
     PERFORM procedure-name-1 UNTIL FALSE.
     PERFORM some-other-procedure
...
    procedure-name-1.
       do-something-here
      IF condition-2
      THEN
           EXIT PERFORM CYCLE
      END-IF
      do-something-else
      IF some-arbitrary-complex-set-of-conditions THEN
        EXIT PERFORM
      END-IF
      .

    -Chuck Stevens