Hacker News Reader

Comment by MarkusQ | Hacker News Reader

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.

View on HN

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.

`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.

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.

EQUIVALENCE is useful even when the types are identical.

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.

> 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

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).

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

struct page in Linux is this taken to its logical conclusion.

https://github.com/torvalds/linux/blob/89be9a83ccf1f88522317...

Edit: A bit of background: https://lwn.net/Articles/565097/

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/89be9a83ccf1f88522317...

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

Maybe, but it's not sumtypes that are to blame.

Reply on news.ycombinator.com