Comment by atherton94027
16 days ago
Genuinely curious, how would you handle cases where a value is unset without NULL? This is a legitimate case that happens a lot in eg data modeling
16 days ago
Genuinely curious, how would you handle cases where a value is unset without NULL? This is a legitimate case that happens a lot in eg data modeling
Sum types, of course.
How do you expect to use sum types in assembly? Remember where C came from and why it was designed the way it was.
A naive sum type is just a tag plus a payload. There is no problem here. If you have enums you could have had sum types.
The historical argument and appeal to assembly is illogical here. The only real argument is that niche value optimization is too complex or too clever for the time so even if sum types were in C, nullable pointers would still exist either way.
I remember why C stayed what it is at least: elitism and gatekeeping. And YAGNI, repeated millions of times, of which only the first few were correct.
You're telling me OCaml / Rust / Haskell compile to fairy pixie dust? Obviously their compilers figured it out and it works.
10 replies →
How are you going to build sum types in a way where you can interact with assembly or machine code? The CPU doesn't know about that stuff
OCaml / Rust / Haskell.
Apparently they found a way to have the CPU know... about "this stuff".
Sum types map down to reading a tag and doing a comparison against fixed values.
I don't know what to tell you, but you're clearly not cut out to be a software developer in either machine code, assembly or C or any other language if you don't understand something this basic.
7 replies →
The way we do it in modern languages with things like std::optional and even that is not the best example.
And higher level languages that works. But what do you do when you get down to low level C or assembly?
You basically end up with null/0 don’t you?
Rust is a significantly higher level language than C, but it can be used it almost all environments where C is used; provided there's a supported compiler target for it. In (safe) Rust, null is basically a guaranteed compiler optimization. Optional / nullable values are represented via Option<T>, which is a sum type of Some(T) and None. When a reference or other pointer-like value (e.g. Box<T>, an owned heap allocation) is wrapped in Option, the compiler can use the invalid bit patterns of T (such as null) to represent the None variant. This is called niche optimization.
So yes, it's nulls underneath, but the developer never has to think about them.
Eventually you end up with registers that probably allow for 2^N values. But the point is not thinking about the machine executing the instructions, but the construction on top of it that has a safer design.
Seeking performance we've been very prone to avoid abstractions and over and over again have shown why we need the safe abstractions.
They already said:
> use the type system to help us use special values safely
... but this is not the place to explain what a type system is or what sum types/maybe/optional/etc. are.