Cobol - Re: "Goto statement considered superfluous"

Author

Re: "Goto statement considered superfluous"

Lueko Willms

2004-09-28, 3:55 am

.. Am 23.09.04
schrieb howard@brazee.net (Howard Brazee)
bei /COMP/LANG/COBOL
in civ3o9$m87$1@peabody.colorado.edu
ueber Re: "Goto statement considered superfluous" (was: If you were inventin

HB> On 23-Sep-2004, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
[color=darkred]

HB> I don't think it would. It already was significantly different from
HB> other languages of the time. We would have used the tool as given
HB> to us.

It is of course quite speculative to make statements about what
would have happend 45 years earlier.

A fact is that the ideas about programming as a social and creative
activity were not yet so evolved and widespread as we have absorbed
them today. That E. Dijkstra's article about the GOTO-Statement had a
reason to be writen and published, and sparked that discussion as it
did, is a living proof of that.

But it would have been possible, als in Algol-60 and maybe other
programming languages of that time (not to speak of Konrad Zuse's
'Plankalkül', a very formalistic language, but with a looping
construct) did have an iteration instruction, is also proof that it
would have been thinkable to include that in COBOL as well. Algol-60
had a "for" statement with a "while" and a "until" clause.

COBOL should have had it at least with the first standard, COBOL-68,
or then at least with COBOL-74.

HB> I also don't think that removing ADD, SUBTRACT, MULTIPLY, and DIVIDE
HB> would have hurt it. We learned to use those verbs because they were
HB> part of the tool.

Well, but those form an important part of the spirit and basic
style of COBOL. I think, nobody has ever had any particular problem
with that (except maybe to realize that in the basic form of MULTIPLY
and DIVIDE the result is in the second operand).

Yours,
Lüko Willms
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Robert Wagner

2004-09-28, 8:55 am

On Thu, 23 Sep 2004 15:25:00 -0700, "Chuck Stevens"
<charles.stevens@unisys.com> wrote:

>ANSI X3.23-1985 reports that one of the criteria to be applied in the
>initial design of COBOL was that it "avoid symbolism as far as possible."
>I think COMPUTE can be considered a violation of that precept: a formula is
>a *symbolic* representation of the steps required to perform a calculation.
>But because formulae were already well-engrained in other higher-level
>languages, their omission from COBOL would have almost certainly been
>regarded as a shortcoming.

When I argued for the superiority of EQUAL TO over =, last year, no
one agreed. Now it seems I was, if not right, at least in concord with
Cobol's design precept.

>And that desire to "avoid symbolism" persists to this day. Although WG4
>ultimately decided to request that J4 add the relational operator "<>" as a
>synonym for "not equal", there was considerable resistance to the idea as
>suggested (right here in this forum) for the 2008 draft precisely because of
>the foreignness of symbolic representations to COBOL. I think the primary
>reason it was finally agreed to is that its absence represented a breach of
>symmetry given the *previous* introduction of <= and >= in ANSI X3.23-1985,
>which some commentors would have preferred had never been done in the first
>place! All three are violations of that day-one expectation for
>"appropriate syntax" in COBOL.

In the interest of symmetry, remember to disallow 'NOT <>' .. or
permit 'NOT <='.

Chuck Stevens

2004-09-28, 8:55 am

"Lueko Willms" <l.willms@jpberlin.de> wrote in message
news:9HQ2SRcPflB@jpberlin-l.willms.jpberlin.de...
> HB> I also don't think that removing ADD, SUBTRACT, MULTIPLY, and DIVIDE
> HB> would have hurt it. We learned to use those verbs because they were
> HB> part of the tool.
>
> Well, but those form an important part of the spirit and basic
> style of COBOL. I think, nobody has ever had any particular problem
> with that (except maybe to realize that in the basic form of MULTIPLY
> and DIVIDE the result is in the second operand).

I was thinking about that, and also thinking about responding to Howard
Brazee to similar effect.

It seems to me that four explicit arithmetic statements -- ADD, SUBTRACT,
MULTIPLY, DIVIDE -- are the "really native COBOL" constructs, and it's
COMPUTE and its acceptance of "arithmetic expressions" that represent the
exception to a basic precept envisioned by the original authors of COBOL.

ANSI X3.23-1985 reports that one of the criteria to be applied in the
initial design of COBOL was that it "avoid symbolism as far as possible."
I think COMPUTE can be considered a violation of that precept: a formula is
a *symbolic* representation of the steps required to perform a calculation.
But because formulae were already well-engrained in other higher-level
languages, their omission from COBOL would have almost certainly been
regarded as a shortcoming.

And that desire to "avoid symbolism" persists to this day. Although WG4
ultimately decided to request that J4 add the relational operator "<>" as a
synonym for "not equal", there was considerable resistance to the idea as
suggested (right here in this forum) for the 2008 draft precisely because of
the foreignness of symbolic representations to COBOL. I think the primary
reason it was finally agreed to is that its absence represented a breach of
symmetry given the *previous* introduction of <= and >= in ANSI X3.23-1985,
which some commentors would have preferred had never been done in the first
place! All three are violations of that day-one expectation for
"appropriate syntax" in COBOL.

-Chuck Stevens

Richard

2004-09-28, 3:55 pm

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> As you say, EQUAL TO and = are synonymous with respect to 1. But your
> preference is irrelevant with respect to 2 unless you're the
> maintenance programmer.

My preference is entirely relevant at all times for the programs that
I am working on.

> It would be nice to have a translating text editor that cast such
> things into the reader's preference. It would be easy to write. I
> don't know why it hasn't been. The closest I've seen was my Cobol
> Beautifier, which I no longer use. It translated = into EQUAL TO
> *unless* the brevity of = made the difference between one line and
> two. In that case, it translated the opposite way.

> My objective is clarity, not dogmatic attachment to purism.

It seems that making a claim as to its superiority is entirely a call
to dogma and purism.

> In this
> case, the clarity of one line vs. two outweighs the clarity of words
> over symbols.

The _clarity_ is exactly whar the reader finds to be clearer. You are
again making the dogmatic claim that words are clearer. They may be
to someone who is more used to the words but they may not be to
someone who is more used to the symbols. You are making an entirely
subjective issue into a vast generalisation, that is exactly what
dogma is.

It would be especially poor (for me) to have an inconsistent usage as
your program did.

Richard

2004-09-28, 3:55 pm

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote

> When I argued for the superiority of EQUAL TO over =, last year, no
> one agreed.

No one (or at least few) agreed that it was _superior_. It generates
the identical code and has no functional superiority. Its textural
quality is dependent entirely on recognition and that is a function of
'what one is used to'.

Personally, having never used the word, and having used symbols as
comparison in several other languages, I find that this is more easily
recognised. Thus _to_me_ '=' is 'superior', though your prefernce may
be different.

> Now it seems I was, if not right,

You may be 100% right for _you_ and 100% wrong for _me_. This is way
your pan_generalizations fail.

Warren Simmons

2004-09-28, 3:55 pm

Again, I would like to point out that the effort to stay away from
smbolic features was deliberate. There were many tools that did tht
kind of think, and the members of CODASYL were bent on disassociate
themeelves from any view of competition. Thus "Business Oriented",
thus Add, Subtract...

It was a move to get something done as fast as possible, the original
schedule for the first spec was 3 months. It took 12. By most measures,
COBOL 60 was enhanced Flow=Matic. Considered to be a good bet for it's
objectives.

Warren

Chuck Stevens wrote:

> "Lueko Willms" <l.willms@jpberlin.de> wrote in message
> news:9HQ2SRcPflB@jpberlin-l.willms.jpberlin.de...
>
>
>
> I was thinking about that, and also thinking about responding to Howard
> Brazee to similar effect.
>
> It seems to me that four explicit arithmetic statements -- ADD, SUBTRACT,
> MULTIPLY, DIVIDE -- are the "really native COBOL" constructs, and it's
> COMPUTE and its acceptance of "arithmetic expressions" that represent the
> exception to a basic precept envisioned by the original authors of COBOL.
>
> ANSI X3.23-1985 reports that one of the criteria to be applied in the
> initial design of COBOL was that it "avoid symbolism as far as possible."
> I think COMPUTE can be considered a violation of that precept: a formula is
> a *symbolic* representation of the steps required to perform a calculation.
> But because formulae were already well-engrained in other higher-level
> languages, their omission from COBOL would have almost certainly been
> regarded as a shortcoming.
>
> And that desire to "avoid symbolism" persists to this day. Although WG4
> ultimately decided to request that J4 add the relational operator "<>" as a
> synonym for "not equal", there was considerable resistance to the idea as
> suggested (right here in this forum) for the 2008 draft precisely because of
> the foreignness of symbolic representations to COBOL. I think the primary
> reason it was finally agreed to is that its absence represented a breach of
> symmetry given the *previous* introduction of <= and >= in ANSI X3.23-1985,
> which some commentors would have preferred had never been done in the first
> place! All three are violations of that day-one expectation for
> "appropriate syntax" in COBOL.
>
> -Chuck Stevens
>
>

Sponsored Links