Live data from Hacker News

Algebraic Data Types for C99

github.com

41–50 of 233 posts

Re: Algebraic Data Types for C99

#41
post #6

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

Union types are not the same as sum types.

Re: Algebraic Data Types for C99

#42

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

Tagged unions + pattern matching is what gp wants. You can always encode whatever model you want using any programming language, but language features/ergonomics matter.

Re: Algebraic Data Types for C99

#43
post #6

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

F# too. And Elm. But I get your point.

Re: Algebraic Data Types for C99

#44

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

I generally don't mind C++ for most code when it's absolutely necessary, but I'm not a huge fan of std::variant. Using std::visit to exhaustively match all cases feels hacky. It really would benefit from being a first-class language feature. It's more impactful to a lot of day-to-day code than other things they've worked on, such as coroutines.

Re: Algebraic Data Types for C99

#45
post #39

Earlier 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…

Enums are closed sets and trait objects are open sets. They are conceptually related concepts, but the language puts syntactic distance between the two, and I don't think it should.

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

#46
post #34
post #19

Earlier quoted context omitted.

ADT feels like an unfortunately acronym-collision with "Abstract data types."

More often than not, when I say ADT to someone outside of the FP world, they assume I mean abstract data type.

Or the company that sells the security stickers, for houses.

Re: Algebraic Data Types for C99

#47
post #4

This 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!

> I've known C for almost 20 years

The author is only 19 years old. I feel really dumb now.

Re: Algebraic Data Types for C99

#48
post #41

Earlier quoted context omitted.

Also Typescript https://www.typescriptlang.org/docs/handbook/2/everyday-type...

Union types are not the same as sum types.

TS narrows union types cases based on conditionals like "if" (called discriminated unions in the docs in the past), and supports exhaustiveness checks. How do they differ in functionality from sum types?

Re: Algebraic Data Types for C99

#49
post #36

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

I'm a huge proponent of ADTs being a more comprehensible way to write code than some of the alternatives. But I do have to agree with you that there isn't really evidence that this is a basic mental model.

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

#50

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

>C has always had them, it's called union

It also has all the features of Haskell, since you can implement a Haskell compiler in C.

Post reply on HN