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.


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

login: root
# chdir /tmp
# cat > fact.f
      integer st(100),ptr,f
      assign 10 to st(ptr)
      goto 100
   10 print 1,n,f
    1 format(' factorial of ', i2, ' is ', i10)
  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
      assign 102 to st(ptr)
      goto 100
  102 continue
      print 3,n,f
    3 format(' fact(',i2,') =', i10)
      goto st(ptr)
# 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:

         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. – another-dave 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. – Leo B. 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. – another-dave 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. – Ian Thompson Aug 26 '20 at 22:45
  • I was poking around bitsavers, and the IBM manuals I looked at all say the same. – another-dave Aug 26 '20 at 22:48
  • 3
    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! – alephzero Aug 26 '20 at 23:04
  • Though by similar argument, one might expect the documentation to report whatever the compiler happened to allow. – another-dave Aug 27 '20 at 0:06
  • 1
    @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. – Leo B. 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. – Leo B. Aug 27 '20 at 16:11
  • My guess is that they were aiming for Fortran IV. – Walter Mitty 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. – Leo B. Aug 27 '20 at 17:42
  • Right. I stand corrected. – Walter Mitty 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.


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


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. – Leo B. 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") – Leo B. 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. – Leo B. Aug 28 '20 at 5:41
  • 1
    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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.