@Arjen - I’m a little late to the party, but here is some feedback. I hope these are useful!
2.2 – C (or c) in col 1 is a comment. A numeric character indicates a statement label (and continued into cols 2-5). * was a common extension. D also somewhat common for ‘debug’ lines – as you mention later.
If col 6 had anything other than blank or zero, it is a continuation. Some interpretations of F66 allowed for cols 1-5 to have other characters as commentary when col 6 indicated continuation. But this was later clarified to be illegal.
2.7 – Nowadays best to have subroutines and functions contained within modules to allow interfaces to be explicit. If it is required to have them in separate files, use a module with the necessary INCLUDE statements to incorporate the procedures into the module at compile time.
3.2.1 – I’ve never found a use for DIM either.
3.3 – Better yet, function A should be in a module – which is USEd by the program. If this is not possible, an interface block should be written so the compiler can do proper argument checking.
3.6 – Use procedures in a module. The module can hold state variables between calls to the procedures. (Better yet, define a derived type that can be passed around. That way your example could have multiple accumulators.)
3.8 – You can also make the function return value an ALLOCATABLE. Again, you’ll want the function to be in a module so the interface is explicit to the caller.
5.1 – Hollerith constants, by Standard, were only allowed in DATA statements and as actual arguments in procedure calls. Though as an extension, they were often allowed in other contexts (e.g., right hand side of assignment statements.)
As few as three , or as many as 20 characters might be stored in a scalar variable or individual array element. (E.g., machines with 24-bit word integers vs CDC 60-bit word double precision on either end of the spectrum.) Oftentimes programmers used 1 character for portability and ease of usage. Since could be wasteful of memory, a good compromise was 4 characters per word. This often required non-Standard shifting and masking operations to extract or insert individual characters into the appropriate positions.
DATA statements are only supposed to initialize COMMON block items from within BLOCK DATA program units. To do so otherwise is non-Standard.
5.2 – Again, use modules.
5.3 – Generally the hidden argument should be a size_t these days, not an int. The hidden arguments almost always follow the formal arguments – following the convention of the original unix f77 compiler.
7.1 – Again, use modules instead of COMMON blocks (and BLOCK DATA). EQUIVALENCE is not always so easy to untangle.
7.2 – There were implementations of Fortran 66 which used stack allocation of local variables. (e.g., Burroughs and at least one or two others.) Since the Standard was silent on the issue, these were perfectly legal implementations.
7.3 – DANGER – when using the more modern form of initializing during declaration, the variable automatically gets the SAVE attribute. This may not be what the programmer wants! Unless it is a PARAMETER (or initializer in a derived type definition), it may be better to initialize via an assignment statement.
(Yes, you mention this later in 10.4.)
7.4 – Again, use modules.
8.1 – Originally, units 1-4 were often connected to magnetic tape drives. Unit 5 for card input. Unit 6 for line printer output. And unit 7 for card punch output. But these varied considerably.
8.2 – Prior to Fortran 77, there was no standard direct access (random) file I/O. IBM had DEFINE FILE statement, and the apostrophie syntax in READ/WRITE statements. Other compilers varied considerably. Often resorting to library calls.
9.1 – CRAY pointers were generally used for dynamic memory allocation in the days before ALLOCATABLE. Very very rare to see them used as procedure pointers.
9.2 - .EQV./.NEQV. - Added in Fortran 77. So older codes didn’t use them.
9.3 – Prior to Fortran 77, there were no Standard OPEN or CLOSE (or INQUIRE) statements. Units were assumed to be pre-connected to files/devices at program startup time. Of course this was universally extended in pre-77 compilers in a variety of ways…
to write it up.
. Just kidding but you would be surprised how often it appears in old 1960 era NASA reports that contain full code listings.