Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Algebraic Data Types for C99

github.com

Post reply on HN
Print view View original

181–190 of 233 posts

Re: Algebraic Data Types for C99

#181

Post by naasking »

samatman wrote: post #168
naasking wrote: post #87

Earlier quoted context omitted.

> For one, the evidence seems as strong that people generally think backwards from the answer far more than they do forwards from the ingredients. Logic doesn't really have a direction, it works backwards or forwards. Even if you're solving a system "backwards", whatever that means, you still have to satisfy all of the necessary AND and OR constraints for a solution to be valid, so you're effectively still building A…

> Logic doesn't really have a direction, it works backwards or forwards. Implication is one of the primitives in logic, and gives us several of the classic logical fallacies: affirming the consequent, denying the antecedent, fallacy of the converse, and fallacy of the inverse. All of which are examples of trying to work logic as though it doesn't have a direction.

Implication is not primitive, "x->y" is reducible to "not(x) or y". None of those fallacies derive from a lack of direction, but from not being invalid logical deductions.

Re: Algebraic Data Types for C99

#182

Post by naasking »

taeric wrote: post #177
naasking wrote: post #167

Earlier quoted context omitted.

> And this logic is how folks convince themselves that ball players are doing trigonometry when playing. It is just wrong. You're attempting a sleight of hand here by saying "they're" not "doing trig". Clearly they are not doing anything like that consciously , but equally clearly some part of their brain is triangulating objects and predicting trajectories based on gradients, meaning that part is "doing trig and cal…

No. You are confusing the model for the reality. Again, our model may lead to a more impressive reality, but ball players are not doing trig. They are almost certainly simulating things, but that does not require trig. Indeed, it only loosely requires math. Models can be very informal with loose approximations. You seem to think I have to prove your model false to show others don't do that. But I am specifically not…

The ability to build lists requires reasoning. It requires enumeration, inclusion/exclusion conditions, and stop conditions, which necessarily requires logic. This argument is pointless, you go on believing that some people can't use basic logical connectives, I'm sure next you'll say they can't even count.

Re: Algebraic Data Types for C99

#183

Post by ackfoobar »

brabel wrote: post #108
lupire wrote: post #11

Earlier quoted context omitted.

Kotlin is JVM compatible and has ADTs. Java has https://github.com/functionaljava/functionaljava which is unsupported but stable.

Java 21's pattern matching (you don't need functionaljava, and shouldn't really use that unless you're really into FP) is kind of nicer than Kotlin's, because you can automatically "destruct" records in your matches. For Java, see https://www.baeldung.com/java-lts-21-new-features Kotlin's: https://www.baeldung.com/kotlin/when Make up your own mind.

> kind of nicer than Kotlin's, because you can automatically "destruct" records in your matches.

I find positional destructuring of records a bad idea.

https://news.ycombinator.com/item?id=31399737

Re: Algebraic Data Types for C99

#184

Post by bPspGiJT8Y »

im3w1l wrote: post #39
estebank wrote: post #18

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…

> And defining a function that will only accept particular variant is nice

This is possible to achieve (or hack your way through, if you will) by parameterizing the type and using a nullary type (a type which is impossible to have) to exclude specific cases of a sum type. In Haskell this would look like this:

    data Weather a b c = Sunny a | Rainy b | Snowy c

    -- can't snow in the summer!
    onlySummerWeather :: forall a b. Weather a b Void -> String
    onlySummerWeather weather = case weather of
      Sunny _ -> "Got sunny weather"
      Rainy _ -> "Got rainy weather"
      Snowy v -> absurd v
where `absurd :: forall a. Void -> a` "if you give me something you can't ever have, I will give you anything in return".

Re: Algebraic Data Types for C99

#185

Post by endgame »

KerrAvon wrote: post #115

Anyone considering using this should be strongly looking at using Swift or Rust instead. You can build almost any given language idea using the C macro preprocessor, but that doesn't mean it's a good idea to ship production code using it. The worst codebases to inherit as a maintenance programmer are the ones where people got clever with the C preprocessor. Impossible to debug and impossible to maintain.

C99 is a stable target for writing bootstrappable software: there are multiple mature compiler implementations, at least one of which is bootstrappable down to hex0, and the bootstrap chain is not too long.

Re: Algebraic Data Types for C99

#186

Post by [deleted] »

ackfoobar wrote: post #183
brabel wrote: post #108

Earlier quoted context omitted.

Java 21's pattern matching (you don't need functionaljava, and shouldn't really use that unless you're really into FP) is kind of nicer than Kotlin's, because you can automatically "destruct" records in your matches. For Java, see https://www.baeldung.com/java-lts-21-new-features Kotlin's: https://www.baeldung.com/kotlin/when Make up your own mind.

> kind of nicer than Kotlin's, because you can automatically "destruct" records in your matches. I find positional destructuring of records a bad idea. https://news.ycombinator.com/item?id=31399737

[deleted]

Re: Algebraic Data Types for C99

#187

Post by keybored »

samatman wrote: post #140
pajko wrote: post #68

Earlier quoted context omitted.

Seems like Nim can be useful too, plus it compiles to C. https://gist.github.com/unclechu/eb37cc81e80afbbb5e74990b62e...

I've been a Nim respecter for many years, it's slept on in general as a language. The difference here is that Nim compiles to C and you can turn the garbage collector off: Zig compiles C and there's no garbage collector. That means the entire standard library is available when generating object code. It's also trivial to opt-in to the C ABI on a fine-grained basis, by defining a function or struct with the extern key…

Let's say further that you already know Zig exists, and aren't going to use it for reasons that anyone writing a C/Rust/D/C++ program already knows.

At least give Nim a try.

Re: Algebraic Data Types for C99

#188

Post by brabel »

Twisol wrote: post #137
brabel wrote: post #97

Earlier quoted context omitted.

Isn't that a completely useless distinction? For all purposes and intents, the "b" type in L and R should be treated the same, no? What do you gain by not doing that??

No, it isn't "completely useless". If you have a function that will normally return a string, but can sometimes fail due to reasons, you may wish to yield an error message in the latter case. So you're going to be returning a string, or a string. It's not what the content of the data is; it's how you're supposed to interpret it. You have two cases, success and failure, and control will flow differently depending on t…

No disrespect, but that still sounds entirely useless to me. I would never model something as `String | String` as that makes zero sense. You should use a `Result` or `Either` type for that like everyone does.

Re: Algebraic Data Types for C99

#189

Post by keybored »

debo_ wrote: post #19
different_base wrote: post #3

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.

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

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

They were both introduced in the same decade.

Re: Algebraic Data Types for C99

#190

Post by CraigJPerry »

dannymi wrote: post #159
CraigJPerry wrote: post #153

Earlier quoted context omitted.

Product types are one kind of algebraic data type, only 5 languages from that TIOBE page don’t have them so most common langs have ADTs

When you have natural numbers and a multiplication operation (product) would you say that those form an algebra? (ADT means algebraic data type)

You’ve got both a carrier (the set of natural numbers) and a morphism (product operation) so yeah you have an algebra.
Post reply on HN