Long Live the GOTO Statement

[Lynn McGuire]

Long Live the GOTO Statement:
http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/

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

Lynn

[Gib Bogle]

On 8/02/2012 6:26 a.m., Lynn McGuire wrote:
> Long Live the GOTO Statement:
> http://adamjonrichardson.com/2012/02/06/long-live-the-goto-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?

[glen herrmannsfeldt]

Gib Bogle <g.b...@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

[Richard Maine]

glen herrmannsfeldt <g...@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

[Lynn McGuire]

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

Lynn

[timprince]

On 2/7/2012 2:19 PM, Richard Maine wrote:
> glen herrmannsfeldt<g...@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

[timprince]

On 2/7/2012 2:19 PM, Richard Maine wrote:

> glen herrmannsfeldt<g...@ugcs.caltech.edu> wrote:
>
>> I believe that "exteneded range of the DO" has been removed, but
>> I don't remember when.
>
> F77 removed it.
>

[timprince]

On 2/7/2012 2:19 PM, Richard Maine wrote:

> glen herrmannsfeldt<g...@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]

Lynn McGuire <l...@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]

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.

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:
> Lynn McGuire <l...@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

[Phillip Helbig---undress to reply]

In article <1kf3gny.159wdcv1gl3ggN%nos...@see.signature>,

nos...@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.

[Keith Refson]

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

[Richard Maine]

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

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.

[Dick Hendrickson]

On 2/7/12 2:24 PM, Richard Maine wrote:
> timprince<tpr...@computer.org> wrote:
>
>> On 2/7/2012 2:19 PM, Richard Maine wrote:
>>> glen herrmannsfeldt<g...@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

[Phillip Helbig---undress to reply]

In article <1kf3rzh.19k98bbyhxv2N%nos...@see.signature>,

nos...@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.

There was once a contest for the smallest self-reproducing program. One
year, the winner was an empty file. They changed the rules after that.

[robert....@oracle.com]

On Feb 8, 1:39 am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
undress to reply) wrote:
> In article <1kf3rzh.19k98bbyhxv2N%nos...@see.signature>,

>
> There was once a contest for the smallest self-reproducing program.  One
> year, the winner was an empty file.  They changed the rules after that.

I know that that was meant as a joke, but it piqued my curiosity.
Is there a programming language that accepts an empty file as a
program?

Bob Corbett

[glen herrmannsfeldt]

robert....@oracle.com wrote:

(snip)

> I know that that was meant as a joke, but it piqued my curiosity.
> Is there a programming language that accepts an empty file as a
> program?

Fortran 66 came pretty close, if not.

I remember a program with a comment after each subroutine indicating
wthich subroutine it was the end of. It made it easier to read
through printed listings. That worked fine, except for the last one
in the file. It generated errors like 'Missing END statement' and
'No Executable Statements' and finally, from the linker, one about
having two MAIN programs.

If you just gave the compiler a single C, it would compile it as
a MAIN program with no statements, after complaining about the
missing END. Maybe also an empty file.

As far as I understand, this was fixed in Fortran 77.

Most other languages require some statement to start the main
program, but not Fortran.

-- glen

[Erik Toussaint]

I think at the very least many interpreted programming languages do so.

Erik.

[Angel de Vicente]

Hi,

I'm not sure if it will accept a 0 size file, but Whitespace only
considers spaces, tabs and line feeds
(http://compsoc.dur.ac.uk/whitespace/). Very weird... :-) (though not
the only one in weird-land.. See, for example,
http://en.wikipedia.org/wiki/Brainfuck and
http://www.bigzaphod.org/cow/)

--
Ángel de Vicente
http://angel-de-vicente.blogspot.com/

[Richard Harter]

On Wed, 8 Feb 2012 23:09:06 -0800 (PST), robert....@oracle.com
wrote:

>On Feb 8, 1:39=A0am, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---

>undress to reply) wrote:
>> In article <1kf3rzh.19k98bbyhxv2N%nos...@see.signature>,
>>

>> There was once a contest for the smallest self-reproducing program. =A0On=
>e
>> year, the winner was an empty file. =A0They changed the rules after that.

>
>I know that that was meant as a joke, but it piqued my curiosity.
>Is there a programming language that accepts an empty file as a
>program?

I just checked; the Lakota scripting language does. I think that is
normal behaviour for scripting languages with a read-eval-print loop.

[glen herrmannsfeldt]

Richard Harter <c...@tiac.net> wrote:

(snip, someone wrote)

>>I know that that was meant as a joke, but it piqued my curiosity.
>>Is there a programming language that accepts an empty file as a
>>program?

> I just checked; the Lakota scripting language does. I think that is
> normal behaviour for scripting languages with a read-eval-print loop.

I checked gfortran with a zero (not even a line terminator)
length file. It gives no error, does generate a .o file,
but with no compiled procedures, not even a main program.

My belief is that Fortran 66 compilers will generate a main
program, but I didn't test it on any yet.

-- glen

[Paul Anton Letnes]

Python certainly does. I assume that several other scripting languages
do, too - a first guess would include perl and ruby, but there are
probably tons of other languages out there, too.

Paul