Re: COBOL ain't quite dead - yet !

On Nov 5, 6:48 pm, "tlmfru" <la...@xxxxxxx> wrote:
Michael Wojcik <mwoj...@xxxxxxxxxxx> wrote in message


In the mathematical sense of proof - yes.  But in view of the fact that no
word can be defined without using other words, which in turn can't be
defined except in terms of other words ... then no.  But so definite and
vehement have been the proponents of GOTO-less programming that one would
think that their stance is based on logic rather than faith.  Rather naughty
of me to think that, I admit.

Do you have any examples of that ?

Either "programs are better without GOTO's" or the absolutist "programs must
be written without GOTO's".


I agree with you that they can't be proved conclusively.  A true statement
is that "writing programs without GOTO's will elminate the possibility of
certain errors".  (Which is an example of a demonstrable proposition.)  All
of which is to say, it behooves us not to be overly emphatic in our claims.


I will assert, unprovably of course, that no non-trivial program can be
written without use of transfers of control (i.e., failing to execute
statements in the order they're written).

If you accept a definition of GOTO's as a transfer of control, then it
follows that it is little different in spirit from a CALL or a PERFORM or
any of the other verbs.  The dirfference is that it's explicit.  Shakespeare
would probably not have said that a goto by any other name would still be a
goto.

Many anti-goto-less programmers seem to focus on the wrong aspects of
the use of go tos.

As I have already said, when examining a program to determine the flow
of control there is nothing wrong with goto. It is perfectly clear
what will happen at that point.

The problem is entirely that when looking at the code and there is a
label then, in a program that has gotos, it is not possible to know
the flow of control around that label without examining the whole
program for references to that label, and to the one above, and the
one above that.

Some standards attempt to make assurances about how flow is allowed to
occur by using signals. In the style under discussion, that used by
Peter, the SECTION keyword is an assurance that there will be no down-
down into this, the name-EXIT paragraph is an assurance that this is
the end and it should not drop-down into the next label, which should
be a SECTION.

However, there is no general automated mechanism that gives an
assurance that this is true except the programmer's claims to be
perfect. Or at least that 'peer review didn't find anything wrong'.

In other, modern, languages there is a _VAST_ difference between their
equivalent of a CALL and PERFORM and GO TO. Perhaps if you had learned
other languages you would appreciate this better.

Your claim that "it follows that it is little different in spirit from
a CALL or a PERFORM or any of the other verbs." is true of assembler
and COBOL and some early BASICs. It is not true of C or Pascal or
derivitives therefrom.

The reason that it is not true of other languages is that there are
_different_ label types and semantics for those labels. You cannot
goto a procedure or function, you cannot perform a branch label.

If i look at a C program and there is prcedure I know _exactly_ the
flow of control around that. I do not have to check to see how the
code gets to this point, there is only one way it can.

In order to make Cobol have some of the advantages of this is is
necessary to ensure that every label can only be accessed in one way.

It could be that if every transfer of control was an explicit GOTO
then this would satisfy the requirement. This would eliminate the use
of PERFORM and would make the program rather tedious, but it would
achieve the stated requirement.

Another way would be to only allow CALLs of nested procedures and
disallow any paragraph or section labels. In fact this is what could
follow in OO programs where METHODs being invoked is the only
mechanism used.

For COBOL programs not written nested or OO the restriction that each
paragraph only be used for one purpose (where the range is target of
goto, perform, thru, dropdown) then there is only one where this can
be verified by a general automated mechanism and doesn't rely on
visual inspection of the complete program and/or assurances of
perfection.

.

Relevant Pages