Long Live the GOTO Statement

Long Live the GOTO Statement:
http://adamjonrichardson.com/2012/02...oto-statement/

Interesting, I was just thinking this myself as we
convert our F77 code to C++.

Lynn

On 8/02/2012 6:26 a.m., Lynn McGuire wrote:
> Long Live the GOTO Statement:
> http://adamjonrichardson.com/2012/02...oto-statement/

Quoting from the article:

"Let’s look at an example of some code that’s deeply nested. We’re going
to use PHP to craft our example because PHP offers a form of the goto
statement that significantly restricts its use:

Goto targets must point somewhere within the same file and context,
so goto cannot jump out of the current function/method.
Goto targets cannot be used to jump into a control structure, so
goto cannot jump into a loop or switch statement."

Do these restrictions differ from what's always been in Fortran?

Gib Bogle <g.bogle@auckland.ac.nz> wrote:

(snip)
> Goto targets must point somewhere within the same file and context,
> so goto cannot jump out of the current function/method.

> Goto targets cannot be used to jump into a control structure, so
> goto cannot jump into a loop or switch statement."

> Do these restrictions differ from what's always been in Fortran?

If you don't count "extended range of the DO", I suppose not.

In days before SUBROUTINE and FUNCTION were added, tricks using
assigned GOTO were used for subroutines.

I believe that "exteneded range of the DO" has been removed, but
I don't remember when.

-- glen

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> I believe that "exteneded range of the DO" has been removed, but
> I don't remember when.

F77 removed it.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

On 2/7/2012 1:01 PM, Gib Bogle wrote:
> On 8/02/2012 6:26 a.m., Lynn McGuire wrote:
>> Long Live the GOTO Statement:
>> http://adamjonrichardson.com/2012/02...oto-statement/
>
> Quoting from the article:
>
> "Let’s look at an example of some code that’s deeply nested. We’re going to use PHP to craft our example because PHP offers a form of
> the goto statement that significantly restricts its use:
>
> Goto targets must point somewhere within the same file and context, so goto cannot jump out of the current function/method.
> Goto targets cannot be used to jump into a control structure, so goto cannot jump into a loop or switch statement."
>
> Do these restrictions differ from what's always been in Fortran?

Fortran 66 and before could jump anywhere, including
control structures but fortran 77 put a stop to that
nasty practice.

Lynn

On 2/7/2012 2:19 PM, Richard Maine wrote:
> glen herrmannsfeldt<gah@ugcs.caltech.edu> wrote:
>
>> I believe that "exteneded range of the DO" has been removed, but
>> I don't remember when.
>
> F77 removed it.
>
But there was no requirement for a facility to warn you about it until
f90, and this involves setting a standards checking option on many
compilers. It could be very difficult for a compiler to distinguish
something which fit a pre-f77 extended DO range from an outright mistake.

--
Tim Prince

On 2/7/2012 2:19 PM, Richard Maine wrote:
> glen herrmannsfeldt<gah@ugcs.caltech.edu> wrote:
>
>> I believe that "exteneded range of the DO" has been removed, but
>> I don't remember when.
>
> F77 removed it.
>
But there was no requirement for a facility to warn you about it until
f90, and this involves setting a standards checking option on many
compilers. It could be very difficult for a compiler to distinguish
something which fit a pre-f77 extended DO range from an outright mistake.

--
Tim Prince

On 2/7/2012 2:19 PM, Richard Maine wrote:
> glen herrmannsfeldt<gah@ugcs.caltech.edu> wrote:
>
>> I believe that "exteneded range of the DO" has been removed, but
>> I don't remember when.
>
> F77 removed it.
>
But there was no requirement for a facility to warn you about it until
f90, and this involves setting a standards checking option on many
compilers. It could be very difficult for a compiler to distinguish
something which fit a pre-f77 extended DO range from an outright mistake.

--
Tim Prince

Lynn McGuire <lmc@winsim.com> wrote:

> Fortran 66 and before could jump anywhere, including
> control structures but fortran 77 put a stop to that
> nasty practice.

Well, f66 didn't have any "control structures" other than the DO loop.
While jumps into a DO loop were allowed in some cases, they were pretty
restricted cases. That was the "extended range of a DO loop", which Glen
alluded to. You could not just willy-nilly jump into any old DO loop.

Whether compilers would catch the error would be a different question. I
recall on occasion fixing code where someone had invalidly jumped into a
DO loop in ways that did not have anything to do with the extended range
of a DO. Sometimes the code even happened to work the way that was
intended when run on the compiler it was developed on, but that was more
a matter of particular compiler behavior than of being part of the
language. Other times, the code was just plain broken, but testing (if
any at all beyond the level of "it ran and printed results":-() had not
uncovered the error.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

timprince <tprince@computer.org> wrote:

> On 2/7/2012 2:19 PM, Richard Maine wrote:
> > glen herrmannsfeldt<gah@ugcs.caltech.edu> wrote:
> >
> >> I believe that "exteneded range of the DO" has been removed, but
> >> I don't remember when.
> >
> > F77 removed it.
> >
> But there was no requirement for a facility to warn you about it until
> f90, and this involves setting a standards checking option on many
> compilers. It could be very difficult for a compiler to distinguish
> something which fit a pre-f77 extended DO range from an outright mistake.

Yep. Prior to f90, there was no requirement for a compiler to warn you
about *ANYTHING*. All a compiler had to do was be able to run
standard-conforming programs. And well, not necessarily even all of
those. (Yes, there is a list of reasons why a compiler can be standard
conforming and still refuse to run some standard conforming programs;
for example, there can be compiler limits on size and complexity.) If
your program was nonstandard in any way, or even if your program was
standard conforming, but fell under one of the loopholes, you were
completely at the mercy of the compiler developer as to what happened.
That was a quality of implementation issue.

And yes, I understand the difficulty of compiler diagnosis of the
validity. Heck, it wouldn't be hard at all to come up with an example
where the validity depended on run-time input data.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

Richard Maine <nospam@see.signature> wrote:
> Lynn McGuire <lmc@winsim.com> wrote:

>> Fortran 66 and before could jump anywhere, including
>> control structures but fortran 77 put a stop to that
>> nasty practice.

(snip on Extended range of the DO)

> Whether compilers would catch the error would be a different
> question. I recall on occasion fixing code where someone had
> invalidly jumped into a DO loop in ways that did not have
> anything to do with the extended range of a DO.

The need to support Extended range of the DO likely restricts
some optimizations that compilers might otherwise make, and
that would cause problems. It also makes it harder for
compilers to test for the illegal cases.

> Sometimes the code even happened to work the way that was
> intended when run on the compiler it was developed on, but
> that was more a matter of particular compiler behavior than
> of being part of the language.

One I remember from many years ago was an FFT routine that
used nested DO loops to do the bit-reversed path through
the arrays. They put in enough DO loops for the largest
case needed, a GOTO into the appropriate loop, and GOTO out
before the end of the loop. The latter being important
in many cases. (Though no less illegal.)

> Other times, the code was just plain broken, but testing (if
> any at all beyond the level of "it ran and printed results":-()
> had not uncovered the error.

-- glen

In article <1kf3gny.159wdcv1gl3ggN%nospam@see.signature>,
nospam@see.signature (Richard Maine) writes:

> Yes, there is a list of reasons why a compiler can be standard
> conforming and still refuse to run some standard conforming programs;
> for example, there can be compiler limits on size and complexity.

I once wrote a standard-conforming compiler on VMS entirely in DCL:

$ WRITE SYS$OUTPUT "Program too complex for processor"
$ EXIT

I even ported it to unix:

echo "Program too complex for processor"

The quality of implementation is pretty low, though.

On 07/02/12 22:28, Phillip Helbig---undress to reply wrote:

> I once wrote a standard-conforming compiler on VMS entirely in DCL:
>
> $ WRITE SYS$OUTPUT "Program too complex for processor"
> $ EXIT

And some surviving major vendors still follow exactly the same approach.....

Keith Refson

Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de>
wrote:

> In article <1kf3gny.159wdcv1gl3ggN%nospam@see.signature>,
> nospam@see.signature (Richard Maine) writes:
>
> > Yes, there is a list of reasons why a compiler can be standard
> > conforming and still refuse to run some standard conforming programs;
> > for example, there can be compiler limits on size and complexity.
>
> I once wrote a standard-conforming compiler on VMS entirely in DCL:
>
> $ WRITE SYS$OUTPUT "Program too complex for processor"
> $ EXIT
>
> I even ported it to unix:
>
> echo "Program too complex for processor"
>
> The quality of implementation is pretty low, though.

That's a bit of overkill for an f77 compiler, as it isn't required to
tell the user that the complexity is the reason for failure. Seems to me
that you could have omitted the WRITE command and still had a standard
conforming f77 compiler, albeit a little lower still on that quality of
implementation curve. For f90, you do have had to have the diagnostic.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

On 2/7/12 2:24 PM, Richard Maine wrote:
> timprince<tprince@computer.org> wrote:
>
>> On 2/7/2012 2:19 PM, Richard Maine wrote:
>>> glen herrmannsfeldt<gah@ugcs.caltech.edu> wrote:
>>>
>>>> I believe that "exteneded range of the DO" has been removed, but
>>>> I don't remember when.
>>>
>>> F77 removed it.
>>>
>> But there was no requirement for a facility to warn you about it until
>> f90, and this involves setting a standards checking option on many
>> compilers. It could be very difficult for a compiler to distinguish
>> something which fit a pre-f77 extended DO range from an outright mistake.
>
> Yep. Prior to f90, there was no requirement for a compiler to warn you
> about *ANYTHING*.

For any compiler that still supports the ASSIGNed GOTO statement (e. g.
all F90 compilers), there is no requirement to diagnose all jumps into
DO loops. I think something like
assign 50 to joe
...
DO 10 ...
...
if (whatever) assign 10 to joe
...
go to joe
...
10 continue
...
50 read *, test
if (test) assign 20 to joe
go to joe
...
20 continue

is perfectly standard conforming at "compile time". It imposes user
requirements on the run-time values of "whatever" and "test"; but
nothing on the compiler.

F2003 says "Transfer of control to the interior of a block from outside
the block is prohibited", but I don't think there are prohibitions on
statements like GOTO 10 from appearing outside of a DO loop like the
above, the prohibitions are that the statements can't be executed and
that's a user, not compiler, restriction.

Dick Hendrickson

All a compiler had to do was be able to run
> standard-conforming programs. And well, not necessarily even all of
> those. (Yes, there is a list of reasons why a compiler can be standard
> conforming and still refuse to run some standard conforming programs;
> for example, there can be compiler limits on size and complexity.) If
> your program was nonstandard in any way, or even if your program was
> standard conforming, but fell under one of the loopholes, you were
> completely at the mercy of the compiler developer as to what happened.
> That was a quality of implementation issue.
>
> And yes, I understand the difficulty of compiler diagnosis of the
> validity. Heck, it wouldn't be hard at all to come up with an example
> where the validity depended on run-time input data.
>