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 - [email protected]

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.
– dave
Commented Aug 27, 2020 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. Commented Aug 27, 2020 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.
– dave
Commented Aug 27, 2020 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. Commented Aug 26, 2020 at 22:45
• I was poking around bitsavers, and the IBM manuals I looked at all say the same.
– dave
Commented Aug 26, 2020 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! Commented Aug 26, 2020 at 23:04
• Though by similar argument, one might expect the documentation to report whatever the compiler happened to allow.
– dave
Commented Aug 27, 2020 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. Commented Aug 27, 2020 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. Commented Aug 27, 2020 at 16:11
• My guess is that they were aiming for Fortran IV. Commented Aug 27, 2020 at 17:04
• The Fortran IV manual another-dave refers to, specifically says "nonsubscripted". Fortran 66 is pretty much an ANSI-blessed Fortran IV. Commented Aug 27, 2020 at 17:42
• Right. I stand corrected. Commented Aug 27, 2020 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. Commented Aug 27, 2020 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") Commented Aug 27, 2020 at 22:20
• I didn't make it clear that 10 was the label to a format statement.
– cup
Commented Aug 28, 2020 at 5:33
• 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
Commented Aug 28, 2020 at 5:49
• It is possibly one of those features that lots of vendors implemented. It seems to have made its way into F77 but got taken out when they dropped the assign statement in F95.
– cup
Commented Aug 28, 2020 at 11:52