5 ms·

This kind of unsafe union has already been present in the first FORTRAN version from 1956, as the statement EQUIVALENCE. Presumably this was inspired by existi

This kind of unsafe union has already been present in the first FORTRAN version from 1956, as the statement EQUIVALENCE. Presumably this was inspired by existing practices in the assembly-language programs. Many early programming languages have followed the example of FORTRAN. In October 1964, John McCarthy (which had not only been leading the development of the first LISP, but he had also been a major contributor to ALGOL) has proposed the keyword "union" and he had advocated for safer implementations of disjoint union types. The first such implementation has been in ALGOL 68, a few years later. Unfortunately, the C language has taken the "union" keyword from ALGOL 68, but instead of implementing proper disjoint union types, the C "union" has been made essentially identical with the FORTRAN EQUIVALENCE from 1956. The "variant record" of Pascal, was not really better, so that can also be counted as a failure to implement proper union types. For a long time Pascal and C have been among the most popular programming languages, creating bad habits in the use of unions.

pklausler 1y ago
`EQUIVALENCE` was (and is) a storage overlay of variables. It's not part of the type system, and one cannot define a derived type in standard Fortran that contains components with overlaid storage.
- adrian_b 1y ago
  While that is right, what you could do with EQUIVALENCE was pretty much equivalent with what you can do with "union" in C. For some things FORTRAN was more verbose, for other things C is more verbose. Accessing a value was more laconic in FORTRAN, because you omitted the union name and the "." that are required in C. The fact that a union is considered a type in C allows the use of a typedef, which removes the need to repeat the definitions for multiple variables, but that is about the only help that you get in C. Both in C and in FORTRAN you must know the current type of the stored value and there is no protection against using the wrong type. If the current type cannot be determined statically, you must manage manually another variable storing a type tag, in both languages.
  - pklausler 1y ago
    EQUIVALENCE is useful even when the types are identical.
- MarkusQ 1y ago
  Modern type systems grew out of the problems caused by such storage hacks (and the general issues of having a bunch of bits that have to be consistently interpreted in some way). Kvetching about the type system in FORTRAN is like complaining about the Wright Flyer's lack of overhead storage bins.
nyrikki 1y ago
> Unfortunately, the C language has taken the "union" keyword from ALGOL 68, but instead of implementing proper disjoint union types, the C "union" has been made essentially identical with the FORTRAN EQUIVALENCE from 1956. Many word address machines, explicitly the PDP-7, it was only the instructions that changed, with ADD being one's complement and YAD being two's Remember we only got B/C because the PDP-7 didn't have enough ram to implement FORTRAN. Similar reasons C case switch falls through, the PDP-7 SAD instruction forced it. Then they abused that fall through to support lower case on the PDP-11, which would have been powerful enough for the type of union you are talking about. Midas/Macro assembly is tangential related but it is really a side effect of word addressable, accumulator/index machines. IIRC, Lisp is a good example for the difference between equality by value, reference, or even predicated equality. If you want to think about just how limited the PDP-7 was look at the instructions www.bitsavers.org/pdf/dec/pdp7/PDP7_Instruction_list.pdf

pklausler 1y ago

`EQUIVALENCE` was (and is) a storage overlay of variables. It's not part of the type system, and one cannot define a derived type in standard Fortran that contains components with overlaid storage.

adrian_b 1y ago
While that is right, what you could do with EQUIVALENCE was pretty much equivalent with what you can do with "union" in C. For some things FORTRAN was more verbose, for other things C is more verbose. Accessing a value was more laconic in FORTRAN, because you omitted the union name and the "." that are required in C. The fact that a union is considered a type in C allows the use of a typedef, which removes the need to repeat the definitions for multiple variables, but that is about the only help that you get in C. Both in C and in FORTRAN you must know the current type of the stored value and there is no protection against using the wrong type. If the current type cannot be determined statically, you must manage manually another variable storing a type tag, in both languages.
- pklausler 1y ago
  EQUIVALENCE is useful even when the types are identical.
MarkusQ 1y ago
Modern type systems grew out of the problems caused by such storage hacks (and the general issues of having a bunch of bits that have to be consistently interpreted in some way). Kvetching about the type system in FORTRAN is like complaining about the Wright Flyer's lack of overhead storage bins.

nyrikki 1y ago

> Unfortunately, the C language has taken the "union" keyword from ALGOL 68, but instead of implementing proper disjoint union types, the C "union" has been made essentially identical with the FORTRAN EQUIVALENCE from 1956. Many word address machines, explicitly the PDP-7, it was only the instructions that changed, with ADD being one's complement and YAD being two's Remember we only got B/C because the PDP-7 didn't have enough ram to implement FORTRAN. Similar reasons C case switch falls through, the PDP-7 SAD instruction forced it. Then they abused that fall through to support lower case on the PDP-11, which would have been powerful enough for the type of union you are talking about. Midas/Macro assembly is tangential related but it is really a side effect of word addressable, accumulator/index machines. IIRC, Lisp is a good example for the difference between equality by value, reference, or even predicated equality. If you want to think about just how limited the PDP-7 was look at the instructions www.bitsavers.org/pdf/dec/pdp7/PDP7_Instruction_list.pdf