Re: Report enhancements

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

Date: Thu, 28 Oct 2004 12:14:40 -0700

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

> The functionality of GOBACK has long been in the COBOL standard by
> means of the EXIT statement -- so why has this duplication been added?

I'm not a fan of GOBACK, and would have argued against it had it been up for
discussion during my tenure, but that wasn't the case.

I don't agree that the functionality of GOBACK is directly and completely
reflected within EXIT, even in '02 COBOL. A GOBACK executed in a
"standalone program" does a STOP RUN, not an EXIT PROGRAM (which in that
context would CONTINUE). I do agree that GOBACK accomplishes what, in a
particular context, might be a STOP RUN, an EXIT PROGRAM, an EXIT METHOD or
an EXIT FUNCTION, but which is appropriate should be obvious from context,
and I personally prefer the explicit instruction to the "generic" GOBACK to
wherever you came from, using whatever method is appropriate to the way you
got here.

> It is not the same to specify a dummy condition test for entering a
> loop on the one hand and to specify that there is no test at all.

Specifying no test at all for a PERFORM is also not the same as specifying
that the PERFORMed code be executed repetitively, as others have pointed
out.

> That a cute compiler and optimizer can prevent that dummy-condition
> being evaluated for every cycle of the loop, does not create the
> clarity of the program for a human reader.

REPLACE does, though. And the execution-time evaluation of the
dummy-condition, when the condition can be shown invariate, isn't the
*standard's* business.

> I repeat what I had stated before: I don't feel an urgent need to
> have that functionality added, because I prefer loops to have their
> proper entry or exit condition at the beginning or the end, but not
> somewhere in the middle. But because the EXIT PERFORM is already in
> the standard (2002), and there _are_ situations where such a loop may
> be needed ... i.e. for the sake of completeness.

Whatever syntax can be constructed for getting into and out of a "perform
forever" should be usable and meaningful in both in-line and out-of-line
cases. The restriction of EXIT PERFORM to in-line functionally restricts
the use of "forever perform" syntax to the in-line subset.

I think a prerequisite for providing syntax for "perform forever" should be
to ensure that we have a *single* way to get out of that "perform forever"
that doesn't involve GO TO, whether the "forever" perform is in-line or
out-of-line. We have that syntax -- EXIT PERFORM -- but it's allowed only
on in-line performs.

Once we have that, how you describe a "perform forever" is pretty much
incidental. Implementations that already allow EXIT PERFORM in out-of-line
performs, and which reduce invariant conditional expressions at compile time
"don't need no steenkin' syntax!", they can do it today.

     -Chuck Stevens

Relevant Pages

  • Re: Stop Run vs GoBack
    ... RM - and any '02 conforming compiler) by using GOBACK. ... While one can design a program to be both a MAIN or a SUB it is ... Exit Program ... If you really think that COPYed procedure code might be sensible then ...
    (comp.lang.cobol)
  • Re: EXIT SECTION/PARAGRAPH
    ... GOBACK, etc. ... so exit should be at the same level. ... This will, in effect, transfer control to the ... perform end-of-program. ...
    (comp.lang.cobol)
  • Re: Perform forever
    ... >>> I see what you're saying, but actually I DO want the controlling PERFORM ... When I exit it I don't care whether it keeps ... >>> need an indefinite PERFORM that will work until some event occurs, ... That statement there is still not a do forever... ...
    (comp.lang.cobol)
  • Stop Run vs GoBack
    ... GoBack is in the '02 Standard. ... as an extension) to code an EXIT Program immediately followed by a Stop Run. ... non-COBOL system or to the operating system. ...
    (comp.lang.cobol)
  • Re: Perform forever
    ... >>> That is a totally reasonable exit condition. ... >> need an indefinite PERFORM that will work until some event occurs, ... > I *never* understood the need for a do forever, ...
    (comp.lang.cobol)