Re: Infinite Loops and Explicit Exits
From: Chuck Stevens (charles.stevens_at_unisys.com)
Date: 11/03/04
- Next message: Richard: "Re: Infinite Loops and Explicit Exits"
- Previous message: Howard Brazee: "Re: Infinite Loops and Explicit Exits"
- In reply to: Lueko Willms: "Re: Infinite Loops and Explicit Exits"
- Next in thread: LX-i: "Re: Infinite Loops and Explicit Exits"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 3 Nov 2004 09:04:13 -0800
"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9K6j-cXPflB@jpberlin-l.willms.jpberlin.de...
> . On 01.11.04
> wrote riplin@Azonic.co.nz (Richard)
> on /COMP/LANG/COBOL
> in 217e491a.0411012238.79aec2c@posting.google.com
> about Re: Infinite Loops and Explicit Exits
>
> anwering Chuck Stevens:
>
> CS>> I'm not convinced it's the job of the COBOL standards committee
> CS>> to eliminate a style of programming.
>
> r> Many things, such as scope terminators _facilitated_ the elimination
> r> of a style, this is quite different from _mandating_ a change, such as
> r> eliminating ALTER, or having NEXT SENTENCE illegal when combined with
> r> END-IF.
>
> For ALTER, there was and is a long transition period.
I'm not sure about "is" as far as the standard goes; it's not in ISO/IEC
1989:2002, but I agree that it did take a while. Part of the reason it was
deprecated was that it was a "widget" on GO TO to begin with.
NEXT SENTENCE has always been illegal in a scope-terminated IF (ANSI
X3.23-1985 page VI-90, 6.16.3, The IF Statement, syntax rule 3.)
NEXT SENTENCE is only defined in standard COBOL in the contexts of IF and
SEARCH to begin with. Its deprecation in those contexts (which is
essentially equivalent to its deprecation everywhere) is the result of the
MISconception, for example, that NEXT SENTENCE within a SEARCH that is in
turn within a scope-terminated IF will proceed to the next STATEMENT within
the IF rather than to the first SENTENCE after the next period. That
reasoning is explicitly spelled out in ISO/IEC 1989:2002 page 833, Annex G,
Section G.1, Archaic language elements, item 3 (q.v.).
For something to be archaized, it looks to me like two factors must be
present: (1) the construct represents a problem in context; and (2) a
construct exists that provides the desired functionality, with fewer or no
ambiguities, in the same context. While the stipulation of the second
factor for ALTER in ANSI X3.23-1985 strikes me as weak, that for NEXT
SENTENCE in the 2002 standard does not. CONTINUE works like NEXT SENTENCE
is MISunderstood to work, and the full complement of scope delimiters can be
used to cover the cases in which it does what the standard says it's
supposed to do. And in any case "there is no plan for the removal of
archaic elements ... "
> As to "NEXT SENTENCE" with in a IF/END-IF structure -- it is simply
> misleading to use it there, ...
No, it's a *syntax error* to use it there, unless it's actually in something
like a SEARCH that's embedded inside the IF/END-IF.
> END-IF is new, and to include NEXT SENTENCE in such a new structure
> should have been specified as a syntax error right from the beginning.
Just out of curiosity, in what way do ANSI X3.23-1985 page VI-60 paragraph
6.16.3 Syntax Rule 3, as well as the distinction between the syntax diagrams
for Format 1 (delimited) and Format 2 (historic) IF statements in ISO/IEC
1989:2002 page 455, 14.8.18, IF statement, fail to accomplish that?
-Chuck Stevens
- Next message: Richard: "Re: Infinite Loops and Explicit Exits"
- Previous message: Howard Brazee: "Re: Infinite Loops and Explicit Exits"
- In reply to: Lueko Willms: "Re: Infinite Loops and Explicit Exits"
- Next in thread: LX-i: "Re: Infinite Loops and Explicit Exits"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
