If I ever implement a product from scratch again, discriminated unions with compiler enforced exhaustive pattern matching is a hard requirement. It’s too powerful to not have.
[dead]
Algebraic Data Types for C99
201–210 of 233 posts
Re: Algebraic Data Types for C99
#202If I ever implement a product from scratch again, discriminated unions with compiler enforced exhaustive pattern matching is a hard requirement. It’s too powerful to not have.
What languages could fit that description today? I don't really understand what it even means but maybe I could understand better if I could look at examples in languages which have them.
Swift, Typescript depending on your opinion with structural typing, and Rust.
Think Scala, Elm and Haskell have it as well.
Having that and elixirs pattern matching would be insane.
Re: Algebraic Data Types for C99
#203Earlier quoted context omitted.
I’m in the latter camp (from Ocaml) and now using Go. Go feels clunky and awkward.
That's because Go is intentionally clunky and awkward in the name of "simplicity". IMO it's charming to some degree, but it's far from perfect and I think you'd need some pretty serious threats to get me to describe it as "elegant" in any way. Rust somehow has more elegance than Go, if only in small parts. Nothing compares to Scheme in the elegance category IMO :)
My view of Go went from being annoyed to "they picked their tradeoffs carefully and consciously and then leaned into them hard to squeeze every ounce of upside out of them" and while it's still not really my preferred aesthetic I now have a lot of respect for the design as a design process.
Meanwhile, getting addicted to scheme many years ago is a lot of why I still mostly write perl, I need 'my' (i.e. expression/block level scoping and you actually have to declare your variables to scope them before use) and closures for the style of programming I like to do.
Rules out python, ruby, and pre-ES6 JS, though JS with 'let' and arrow functions is pretty survivable and will be even more so if the 'do' and 'match' proposals land.
(note: I know go has :=, and while I'm ambivalent about the syntax, the semantics are pretty much what I expect; the above was talking about scripting class languages though hence not mentioning it there)
Re: Algebraic Data Types for C99
#204Earlier 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…
Why would you return `string | string` here? Wouldn't you explicitly mark the error, and return `string | error`? (substitute error with whatever type you want there - null, Error, or your own thing)
Re: Algebraic Data Types for C99
#205Earlier quoted context omitted.
> I believe this is why "anything goes" languages such as LISP Why do you think that Lisp is an "anything goes" language? What's your baseline? I think that C is no less an "anything goes" language, but with a much less pleasant UI. > with no philosophy every programmer becomes an island unto themselves Some people actually think that Lispers tend to be too philosophical
Lisp is anything goes because of macros. Hire ten different Lisp programmers and you’ll get ten different domain specific languages and no one will understand what everyone else has done. If there is a unifying philosophy of Lisp, it’s probably “don’t use macros” and yet so many ignore it! For all its faults, C is quite easy to read and understand, even by beginner C programmers. Yes, C also has macros but their clum…
I'm a Common Lisp programmer. I don't really know how to respond to that except to say, what you describe is not the case at all. Reading others' Common Lisp code is a joy compared to reading others' code in any other language.
Re: Algebraic Data Types for C99
#206Earlier quoted context omitted.
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…
I would be so tempted to name the variable 'ity' instead of 'v'.
Re: Algebraic Data Types for C99
#207Earlier quoted context omitted.
That doesn't matter in practice. If two programming languages have the same underlying feature but one has syntactic sugar to make it very easy to use and the other does not (so is quite cumbersome to use) then you'll find that the library ecosystem for the former language will see the feature in widespread use whereas the ecosystem of the latter will tend to shun the feature. This is one of the social factors of pro…
> "anything goes" languages such as LISP have struggled to gain widespread adoption: with no philosophy every programmer becomes an island unto themselves. There are already two misconceptions. First: "Lisp has no programming philosophies" and styles. Not every program starts by zero. Since Lisp exists since the end 1950s, it has seen quite a lot in programming styles over the years and it may contain traces of sever…
First: "Lisp has no programming philosophies" and styles
You misquoted me. I said no philosophy, singular. In the programming language context, a philosophy is a convention or a standard. Just as many standards implies that there is no standard, many philosophies implies no philosophy.
Everything else you said is evidence for my premise. Hire 3 different programmers, one from each of the communities, and you might as well have 3 different programming languages. That’s not a standard. That’s not a philosophy. That’s anything goes!
Re: Algebraic Data Types for C99
#208Earlier quoted context omitted.
ADT feels like an unfortunately acronym-collision with "Abstract data types."
Yep, people that eventually buy a Modula-2 ADT book, when hunting old stuff, are in for a surprise. :)
I just realised something terrible.
This code is ADTs for C.
At some point somebody's going to call it CADT and jwz will explode.
Re: Algebraic Data Types for C99
#209Earlier quoted context omitted.
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…
By floating the forall., we get another representation type for Void (forall a. a) and `absurd' is one half of that isomorphism :)
absurd :: Void -> (forall a. a)
drusba :: (forall a. a) -> Void
drusba void = void @VoidRe: Algebraic Data Types for C99
#210Earlier quoted context omitted.
What languages could fit that description today? I don't really understand what it even means but maybe I could understand better if I could look at examples in languages which have them.
For example Rust: https://doc.rust-lang.org/std/keyword.enum.html
Also Scala