Earlier quoted context omitted.
Zig is a modern imperative programming language with ADTs: https://ziglang.org/documentation/master/#Tagged-union
Also Typescript https://www.typescriptlang.org/docs/handbook/2/everyday-type...
Algebraic Data Types for C99
41–50 of 233 posts
Re: Algebraic Data Types for C99
#42One of the crimes of modern imperative programming languages is not having ADTs (except maybe Rust) built-in. It is such a basic mental model of how humans think and solve problems. But instead we got inheritance and enums which are practically very primitive.
C has always had them, it's called union. In practice you need to couple it with an enum, and your visitation mechanism is a switch statement. But C doesn't impose that on you and lets you do it as you see fit.
Re: Algebraic Data Types for C99
#43Re: Algebraic Data Types for C99
#44Could you not get most of the benefits of ADTs using structs + unions + enums? I've used the pattern where I had a union of several types and an enum to differentiate which one to pick. Something like std::variant seems to work a bit like a sum type. The only issue is you can't do a clean switch statement that matches on the specific value of a field, but nested switch statements aren't that messy.
Re: Algebraic Data Types for C99
#45Earlier quoted context omitted.
Everyone who hasn't used ADTs and pattern matching doesn't get what the big deal is all about. Everyone who is used to ADTs and pattern matching doesn't get what the big deal is all about, until they have to work in a language that doesn't have them. And everyone who just found out about them can't shut up about them being the best thing since sliced bread. :)
I have mainly used them in Rust. They are nice I suppose, but nothing mindblowing. To me it feels very similar to an interface (trait) implemented by a bunch of classes (structs). I have multiple times wondered which of those two approaches would be better in a given situation, often wanting some aspects of both. Being able to exhaustively pattern match is nice. But being able to define my classes in different places…
There are lots of open design questions for every feature you propose, but all of them have been discussed and have higher or lower chance of making it into the language.
Re: Algebraic Data Types for C99
#46Re: Algebraic Data Types for C99
#47This is the work of a wizard. I've known C for almost 20 years, and never would I have thought the macro system was powerful enough to allow such black magic. This is awesome!
The author is only 19 years old. I feel really dumb now.
Re: Algebraic Data Types for C99
#48Earlier quoted context omitted.
Also Typescript https://www.typescriptlang.org/docs/handbook/2/everyday-type...
Union types are not the same as sum types.
Re: Algebraic Data Types for C99
#49One of the crimes of modern imperative programming languages is not having ADTs (except maybe Rust) built-in. It is such a basic mental model of how humans think and solve problems. But instead we got inheritance and enums which are practically very primitive.
I'm curious on supporting evidence for it being a basic mental model of how humans think? That sounds like a fairly strong claim.
However
What we do see is a bunch of mathematical disciplines that end up creating properties like: AND, OR, Universal, Existential, Implication, (and a few others). They end up in places like: set theory, type theory, category theory, various logics, lattice theory, etc.
Now, maybe they're only copying one another and this is more of a memetic phenomena. Or maybe they've hit upon something that's important for human comprehensibility.
That would be the 'evidence' of the positive effect of ADTs (scare quotes because it might just be math memes and not fundamental). But we can also think about what I feel is legit evidence for the negative effect of lacking ADTs.
Consider what happens if instead of having the standard boolean logic operators and, or, not, xor, we only have the universal not-and operator. Now a straightforward statement like: A && B || C becomes (((A !& B) !& (A !& B)) !& ((A !& B) !& (A !& B))) !& (B !& B) [I think...]. It's more complicated to tell what's actually supposed to be going on AND the '&&' simulation can get intertwined with the '||' simulation. The result being that requirements changes or defect fixes end up modifying the object level expression in a way where there is no longer any mapping back to standard boolean logic. Comprehensibility approaches zero.
And we've seen this happen with interfaces and inheritance being used to implement what would otherwise be a relatively simple OR property (with the added benefit that pattern matching ADTs often comes with totality checking; not something you can do with interfaces which can always have another instance even up to and including objects loaded at runtime).
Re: Algebraic Data Types for C99
#50One of the crimes of modern imperative programming languages is not having ADTs (except maybe Rust) built-in. It is such a basic mental model of how humans think and solve problems. But instead we got inheritance and enums which are practically very primitive.
C has always had them, it's called union. In practice you need to couple it with an enum, and your visitation mechanism is a switch statement. But C doesn't impose that on you and lets you do it as you see fit.
It also has all the features of Haskell, since you can implement a Haskell compiler in C.