This question has been prompted by a recent question about the assigned GOTO operator.

It appears that some early FORTRAN implementations supported a non-obvious construct: using an indexed variable in the `ASSIGN` operator and the `GOTO` operator, e.g.

``````ASSIGN 10 TO IGO(K)
...
GOTO IGO(K)
``````

This allowed to mimic recursive functions (with appropriately managed local variable frame, if needed) even on platforms with no call stack.

The following program compiles and executes correctly on PDP-11 UNIX V5:

``````Paul Nankervis - paulnank@hotmail.com

Boot> boot rk0
@unix

# chdir /tmp
# cat > fact.f
integer st(100),ptr,f
ptr=1
n=10
assign 10 to st(ptr)
goto 100
10 print 1,n,f
1 format(' factorial of ', i2, ' is ', i10)
stop
100 print 2,n
2  format(' called: factorial of ', i5)
if (n.gt.1)goto 101
f = 1
goto st(ptr)
101 n=n-1
ptr=ptr+1
assign 102 to st(ptr)
goto 100
102 continue
print 3,n,f
3 format(' fact(',i2,') =', i10)
ptr=ptr-1
n=n+1
f=f*n
goto st(ptr)
end
# fc fact.f
# ./a.out
called: factorial of    10
called: factorial of     9
called: factorial of     8
called: factorial of     7
called: factorial of     6
called: factorial of     5
called: factorial of     4
called: factorial of     3
called: factorial of     2
called: factorial of     1
fact( 1) =         1
fact( 2) =         2
fact( 3) =         6
fact( 4) =        24
fact( 5) =       120
fact( 6) =       720
fact( 7) =      5040
fact( 8) =     40320
fact( 9) =    362880
factorial of 10 is    3628800
#
``````

(an aside: allowing quoted strings instead of Hollerith style had been an early enhancement, apparently)

A BESM-6 FORTRAN compiler, directly derived from the CDC 1604 compiler, accepts the code and produces an identical result. A newer (post-1977) BESM-6 compiler rejects it.

G77 rejects the code as well:

``````fact.f:4:
assign 10 to st(ptr)
^
Expression at (^) has incorrect data type or rank for its context
``````

It looks like when FORTRAN was being standardized, the syntax was tightened.

The question is: Was the liberal reading of the syntax, allowing assigning labels to array elements, an "official" one, that is, originated by IBM, or was it an unrelated initiative, adopted by competing vendors (at least DEC and CDC)?

• Is there a DEC (not Unix) PDP-11 FORTRAN compiler with this extension? By personal testing, the DEC F77 compiler on RSX-11M+ rejects subscripts on ASSIGN and assigned GOTO, but then, it's post-standardization. Aug 27 '20 at 1:36
• @another-dave By F77, the requirement that an assigned label must be a simple variable appears to be well-standardized (having been formulated in the Fortran 66 standard), so it has to be an older compiler. On the emulator page, I've tried RT11 and Ultrix, neither seems to include a Fortran compiler. Aug 27 '20 at 5:03
• Later DEC PDP-11 documentation has a single FORTRAN language manual for multiple operating systems, so I assume the compiler core is common. If any compiler has the extension, it will be pre-F77. I vaguely recall RSX/IAS compilers called FOR and F4P. But perhaps the PDP-11 question is moot, since @WalterMitty has found PDP-10 documentation with the extension to subscripted variables. Aug 27 '20 at 12:32

I can't say whether IBM invented this extension or even whether any IBM compiler ever supported it, but at least as of the IBFTC FORTRAN IV compiler for IBSYS version 13 (manual dated 1968), subscripted variables were explicitly prohibited in an ASSIGN.

Assuming the vendor's documentation to be accurate :-)

A System/360 FORTRAN IV manual says the same thing (see page 32). As does this 1982 manual for S/370 - page 46.

• Lots of old IBM documents (including FORTRAN for the 704) at www.softwarepreservation.org/projects/FORTRAN. All those I have looked at require a 'non-subscripted' variable. Aug 26 '20 at 22:45
• I was poking around bitsavers, and the IBM manuals I looked at all say the same. Aug 26 '20 at 22:48
• Back then, compiler writing was more an art than a science, so it's possible something like this "worked by accident" and programmers discovered it whether or not it was documented. There was definitely an attitude back then that the compiler itself defined the language, not the compiler documentation! Aug 26 '20 at 23:04
• Though by similar argument, one might expect the documentation to report whatever the compiler happened to allow. Aug 27 '20 at 0:06
• @alephzero I have an example of a compiler where it does not work by accident: the index in `ASSIGN` is ignored, as if st(1) had been written, and the `GOTO` requires a label list (it wants to see a comma is there is a parenthesis in an assigned `GOTO`), and also ignores the index. The fact that two independently written (I presume) compilers both accept the pattern and compile it properly makes me think that it is not an accident. Aug 27 '20 at 0:09

DEC PDP-10 Fortran documentation says the target of an assigned go to can be a variable or an array element. It sounds like it would allow the construct discussed in this question.

see manual

This edition of the manual is dated 1972.

• Interesting. This looks like a deliberate extension as compared to the Fortran 66 standard. Aug 27 '20 at 16:11
• My guess is that they were aiming for Fortran IV. Aug 27 '20 at 17:04
• The Fortran IV manual another-dave refers to, specifically says "nonsubscripted". Fortran 66 is pretty much an ANSI-blessed Fortran IV. Aug 27 '20 at 17:42
• Right. I stand corrected. Aug 27 '20 at 19:11

The 1966 ANSI standard X3.9-1966 ANSI standard (https://wg5-fortran.org/ARCHIVE/Fortran66.pdf) just says

A GO TO assignment statement is of the form

ASSIGN k to i

where k is a statement label and i is an integer variable name.

so anything other than an integer variable name would have been an extension to Fortran 66.

From the compiler writer's point of view, whether to allow an extension or not would depend on the the syntax of the assigned goto. If it is defined as (Lahey, Fujitsu, ICL)

``````GOTO assign-variable [[,] (labels)]
``````

It would mean that the comma was optional, so

``````GOTO st(10)
``````

could mean goto ST and label 10 was one of the options or goto the label pointed to by ST(10). The problem is not really in the ASSIGN statement but in the GOTO. If the comma is compulsory i.e.

``````GOTO assign-variable [, (labels)]
``````

then it shouldn't be a problem. Once you've gotten over that hurdle, it is quite easy to extend the language to allow assignment of labels to array elements.

OFF TOPIC

The other common use of assigned labels is in format statements. eg

``````ASSIGN 10 to COORD
...
WRITE(1, COORD) X, Y, Z
``````

Bending the rules a bit, COORD could live in a common block and subroutines could use the same write statement and only have the FORMAT statement defined in one place.

• Only statement labels could be assigned using `ASSIGN` operators. Some early implementations (namely, the CDC 1604 one) had separate scopes for statement and format labels, so that ` PROGRAM MAIN<nl> 1 PRINT 1<nl> 1 FORMAT(’ GOTCHA’)<nl> END ` could be written. It works. Aug 27 '20 at 21:47
• Using arrays in place of format labels was in the standard (see 7.1.3), obviating the need to assign format labels to variables. For example, a quine (self-printing program) could be written as in mailcom.com/besm6/runitnew.cgi (click on "FORTRAN quine") Aug 27 '20 at 22:20
• I didn't make it clear that 10 was the label to a format statement.
– cup
Aug 28 '20 at 5:33
• I understood that. However, not a single compiler that I have access to allows format labels in `ASSIGN`. My "gotcha" example shows that some of them would not be able to even if they wanted because of ambiguity, and my quine example shows that there was a standard way to have shared format strings. Aug 28 '20 at 5:41
• Strange - I've been doing that since the mid-70s when I first started using Fortran. I used it on the ICL compilers and later on Data General. It even works on gfortran even though it moans about it.
– cup
Aug 28 '20 at 5:49