Infinite Loops and Explicit Exits

From: Chuck Stevens (charles.stevens_at_unisys.com)
Date: 10/29/04 

Date: Fri, 29 Oct 2004 12:01:03 -0700

For those who have been following the "perform forever" and "exit perform
[cycle]" threads, I'm just tidying up the first drafts of two proposals that
I hope to submit Real Soon Now to INCITS/J4 for evaluation and consideration
for a future standard, if nothing else so that they can be added to the
"candidates list" for future consideration.

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

The other proposal is for PERFORM ... UNTIL FALSE. I didn't want to add a
new reserved word and for that reason rejected PERFORM ... FOREVER. I was
concerned about the potential semantic ambiguities that one might encounter
in sequences like "PERFORM ... PERFORM ... UNTIL EXIT PERFORM ...
END-PERFORM ...", which led me away from PERFORM ... UNTIL EXIT. I don't
care for PERFORM ... WITH NO TEST because it really doesn't convey the sense
of iteration. I am not wedded to the syntax I chose, but I think the
technical reasons for avoiding the other three here presented are sound.

Unless WG4 so directs, these capabilities can't be included in the proposed
2008 standard. But I can envision no technical barrier at all to the second
of these, and the only barriers I can envision to the first are
implementor-specific, WG4 *might* acquiesce so long as the additions do not
cause a delay in the production of that next standard.

At the very least this action on my part will ensure that these topics are
on the standards committees' radar screens, and stimulate the discussion and
clarification as to why EXIT PERFORM (with or without CYCLE) was limited to
inline PERFORMs in the 2002 standard.

    -Chuck Stevens

Relevant Pages

  • Re: Infinite Loops and Explicit Exits
    ... As the person who wrote the initial proposal to add EXIT PARAGRAPH/SECTION ... Currently the EXIT PARAGRAPH/SECTION syntax can cause VERY unexpected results if ... > For those who have been following the "perform forever" and "exit perform> " threads, I'm just tidying up the first drafts of two proposals that> I hope to submit Real Soon Now to INCITS/J4 for evaluation and consideration> for a future standard, if nothing else so that they can be added to the> "candidates list" for future consideration. ... > One of these proposals relaxes the current restriction that an EXIT PERFORM> or EXIT PERFORM CYCLE statement may only appear within a PERFORM ... ...
    (comp.lang.cobol)
  • Re: Infinite Loops and Explicit Exits
    ... 04-0195 -- Provide Explicit Infinite Loop Capability ... for a future revision of the standard. ... > One of these proposals relaxes the current restriction that an EXIT ... > or EXIT PERFORM CYCLE statement may only appear within a PERFORM ... ...
    (comp.lang.cobol)
  • Re: Infinite Loops and Explicit Exits
    ... > for a future standard, if nothing else so that they can be added to the ... > One of these proposals relaxes the current restriction that an EXIT PERFORM ... I'm not sure I understand the perform/forever need. ...
    (comp.lang.cobol)
  • Re: Infinite Loops and Explicit Exits
    ... The way EXIT PERFORM acts in COBOL85 ... PERFORM itself, whether inline or not, and EXIT PERFORM CYCLE should land ... > PERFORM refers to the simple basic PERFORM which does not specify any ... > PERFORM is specified to do according to the current COBOL standard. ...
    (comp.lang.cobol)
  • Re: Infinite Loops and Explicit Exits
    ... the proposal is only for the *innermost* active PERFORM. ... I'll have to think about your "EXIT PERFORM [CYCLE] ALL", ... > Do these proposals have a way to exit different levels of perform? ...
    (comp.lang.cobol)