[bodyfour]

Certain ancient FORTRAN compilers would let you do that as well. If the target CPU didn't have a "move immediate" instruction, the compiler would just stash the number into memory. The quickest way to implement it is to just add the number into the symbol table... that way an often-used constant will only need one spot in core.

Of course when your whole compiler has to run in 8 Kwords or whatever, syntax checking isn't a high priority. So if you do "1234 = 0" it would allow it (since '1234' is just a variable in the symbol table) and it actually would change all of the meaning of 1234 everywhere else in the program!

[kps]

I haven't heard of that, and it would be great if you could remember where you found it. It sounds to me like it might be an apocryphal corruption of the following:

Fortran passes arguments by reference. If the compiler uses a constant pool, and (lazily or efficiently, depending on your point of view) passes the constant pool location as an argument, a subroutine could inadvertently modify a constant.

FORTRAN 66 (the first ANSI standard) and FORTRAN 77 forbid passing a constant or expression as an argument that will be modified†‡, thereby blessing this implementation. (Fortran 90 and later are tl;dr.)

† http://www.fh-jena.de/~kleine/history/languages/ansi-x3dot9-... §8.4 p26

‡ http://www.fortran.com/fortran/F77_std/rjcnf-15.html#sh-15.9...

[bodyfour]

It's a war story from my father, so I have to admit that the details could be corrupted. He worked with a variety of machines in the 60s, so it was believable that one had a permissive enough FORTRAN to allow that. It's also possible that your explanation of it being reference-argument corruption.

I'm almost curious enough to fire up a PDP-8 emulator and see what 4K FORTRAN does. Almost. http://techtinkering.com/2009/07/14/running-4k-fortran-on-a-...