5 ms·

Back in the day, when memory wasn't as cheap as it is now, there was a strong belief that forcing the user to "waste bits" on a proper sum type was a non-starte

Back in the day, when memory wasn't as cheap as it is now, there was a strong belief that forcing the user to "waste bits" on a proper sum type was a non-starter for a "real" language. It was widely assumed that the reason you were "sharing memory" between two fields was to conserve space, because you were clever enough to have recognized that they couldn't both be used at the same time. But doing so, it was generally assumed, meant that you were space constrained and so anything that took away your precious savings was bad. I'm not saying this was "right" in any sense, but it wasn't just foolish old timers not recognizing that a "better" solution was possible. When you grew up having every single bit of memory threaded by hand (and costing macroscopic amounts of money), you think about memory efficiency differently.

cbsmith 1y ago
Yeah, I remember using untagged unions because the code "knew" which type was the right one to use at the right time and you wanted to save space (and wanted your structures to fit well in registers --and later cache lines).
- setr 1y ago
  I suppose that’s what cobol copybooks are; untagged unions, everywhere, all the time, all at once
NooneAtAll3 1y ago
looking at VSCode and browsers eating RAM as if it's nothing makes me think modern approach isn't that good either
- eru 1y ago
  Maybe, but it's not sumtypes that are to blame.
adrian_b 1y ago
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.
    - 1y ago
rwmj 1y ago
struct page in Linux is this taken to its logical conclusion. https://github.com/torvalds/linux/blob/89be9a83ccf1f88522317ce02f854f30d6115c41/include/linux/mm_types.h#L73 https://github.com/torvalds/linux/blob/89be9a83ccf1f88522317... Edit: A bit of background: https://lwn.net/Articles/565097/ https://lwn.net/Articles/565097/
- tux3 1y ago
  Fun fact: With the advent of folios, struct page is starting to undergo some major changes, with the eventual goal of shrinking it into a single 64bit number. But not to worry, the unreadable mess of C unions is not going away. struct folio will eventually absorb all those fields, and more. The only difference is there's a single folio for a whole set of pages, so moving the data there will save a significant amount of memory. https://github.com/torvalds/linux/blob/89be9a83ccf1f88522317ce02f854f30d6115c41/include/linux/mm_types.h#L381 https://github.com/torvalds/linux/blob/89be9a83ccf1f88522317...

cbsmith 1y ago

Yeah, I remember using untagged unions because the code "knew" which type was the right one to use at the right time and you wanted to save space (and wanted your structures to fit well in registers --and later cache lines).

setr 1y ago
I suppose that’s what cobol copybooks are; untagged unions, everywhere, all the time, all at once

NooneAtAll3 1y ago

looking at VSCode and browsers eating RAM as if it's nothing makes me think modern approach isn't that good either

eru 1y ago
Maybe, but it's not sumtypes that are to blame.

adrian_b 1y ago

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.
  - 1y ago

rwmj 1y ago

struct page in Linux is this taken to its logical conclusion. https://github.com/torvalds/linux/blob/89be9a83ccf1f88522317ce02f854f30d6115c41/include/linux/mm_types.h#L73 https://github.com/torvalds/linux/blob/89be9a83ccf1f88522317... Edit: A bit of background: https://lwn.net/Articles/565097/ https://lwn.net/Articles/565097/

tux3 1y ago
Fun fact: With the advent of folios, struct page is starting to undergo some major changes, with the eventual goal of shrinking it into a single 64bit number. But not to worry, the unreadable mess of C unions is not going away. struct folio will eventually absorb all those fields, and more. The only difference is there's a single folio for a whole set of pages, so moving the data there will save a significant amount of memory. https://github.com/torvalds/linux/blob/89be9a83ccf1f88522317ce02f854f30d6115c41/include/linux/mm_types.h#L381 https://github.com/torvalds/linux/blob/89be9a83ccf1f88522317...