Re: Is it always possible to write a COBOL program using only 1 sentence per paragraph?

<docdwarf@xxxxxxxxx> wrote in message news:db0gd8$amg$1@xxxxxxxxxxxxxxxxxxx

> Leaving aside the persnickety labelling for statement, sentence,
> imperative, instruction, what happens at the end of a paragraph (etc)...
> would someone pass this along to The Standards Folks and ask them for what
> reason - given this level of interpretation shown by a rank neophyte -
> they think the function of NEXT SENTENCE is so difficult to grasp?

Well, I guess I'd qualify as A Standards Folk.

What the standard says NEXT SENTENCE ought to do is very clear, and as
stated above. The contexts in the standard in which NEXT SENTENCE may
appear are also clear (and limited strictly to undelimited IF and
undelimited SEARCH statements).

The two problems discussed in the '02 standard can be found on Page 833:
"It is a common belief among users that control is transferred to a position
after the scope delimiter rather than to a separator period that follows it
somewhere. In addition, it is a common source of errors, especially for
maintenance programmers who inadvertently insert a period somewhere before
the actual terminating separator period."

A third unstated issue is that use of NEXT SENTENCE outside the limited
contexts in which the standard allows is a very common implementor extension
(e.g., AT END, INVALID KEY, SIZE ERROR, etc., etc., and their corresponding
NOT phrases). That complicates its interpretation.

A fourth unstated issue is that at least one implementation has supported
the perpetuation in the user community of the misapprehension as to where
NEXT SENTENCE is supposed to transfer control. It is my understanding that
this error is in the process of being corrected, but because of the large
body of existing programs that might be dependent on this erroneous
presumption, the vendor's policy and agreements with its customers requires
a long period of stern warnings from the compiler before the change can
actually be made.

A fifth unstated issue is that *before* the introduction of scope delimiters
NEXT SENTENCE could in most cases reasonably be considered an imperative
statement on its own without impacting parsing much if at all. That
fostered its use in contexts in which the standard did not provide for it
(see issue #3 above).

As the standard says as its closing defense of the archaization of NEXT
SENTENCE, "The CONTINUE statement and scope delimiters can be used to
accomplish the same functionality and such constructs are clearer and less
prone to error."

-Chuck Stevens


.

Relevant Pages

  • Re: what happened to hash-tables
    ... >> You already need hashtables anyway internally for implementing Common ... Many of the people on the committee had much more experience ... The ANSI standard is about memorializing the "Common" practice ... Suppose that the winning extensible hash table protocol is based ...
    (comp.lang.lisp)
  • Re: OO syntax
    ... You have a few people who are proud of their OO implementations giving good reasons why their particular model should be adopted as a standard. ... I am pointing out that the Lua language doesn't offer objects as a primitive type. ... What Lua does instead is to provide meta-mechanisms and some minor syntactic sugar that allows programmers to create and use objects with whatever kinds of semantics make sense for the programmer and application. ... I am saying that I believe that if the people who advocate the various OO systems for Forth would stop thinking in terms of why their OO system is the best and instead focus on factoring what is common between their systems, the result would be a set of primitives that they could layer their OO system on top of. ...
    (comp.lang.forth)
  • Re: Cohens paper on byte order
    ... A normal user (a programmer working with a common ... the program of the recipient. ... transmission of the AES block. ... defined 'standard' functions for doing the conversion ...
    (sci.crypt)
  • Re: Modernizing Common Lisp
    ... standard supported bindings. ... models and socket abstractions that are common enough for standardization. ... hard to inject libraries to write portable code is a good thing? ... but with incompatible interfaces (sort of like the problem ...
    (comp.lang.lisp)
  • Re: NEED: TA7805S & TA7805F Bipolar Linear Integrated Circuits
    ... Sure the part is common, I found it on every website that I went to ... As to "package" type; YES I do need these specific types becasue ... Those parts are standard electrically, but I see they're not standard ... insulating tube you'll want, as that's standard practise in a lot of gear. ...
    (sci.electronics.components)