> PLEASE, do not use top-level break/continue inside statements provided to of and ifLet; use goto labels instead.
Seems like a pretty big footgun. But otherwise, very cool.
Algebraic Data Types for C99
151–160 of 233 posts
Re: Algebraic Data Types for C99
#152Earlier quoted context omitted.
Absolutely, so you try to seal it in hermetically, only talk to it over a special message bus or something. Sometimes the upgrade path from 6 onwards isn't as nice as it usually is from 8 up, especially if you built with some old undead libraries that require an heroic effort to understand well enough to reimplement. Takes a very special organisation to divert some person-years to pull it off, and as some middle or o…
It makes me sad, but I totally understand why someone would stay with Java 6, for the same reason that there's still COBOL stuff hanging around: the stuff "works" as is, upgrading is expensive, and some business person decided that the cost of the upgrade isn't worth it for the value they'd receive. I do worry that there's "Y2K-esque" bugs hiding in Java 6 programs somewhere. I don't think java.util.date uses 32 bit…
There might be some limit or bug like that in Java 6, but I think time stuff has been backported, so it'd likely be something else. I don't know enough about the JVM internals to speculate on whether the old ones were simpler and less likely to be defective, or not.
By now most types of issues ought to have popped up though, since it was so widely used for such a long time.
Re: Algebraic Data Types for C99
#153Earlier quoted context omitted.
>> not having ADTs (except maybe Rust) built-in Most of the common languages today have product types. Java[1], Rust, Haskell, etc. have sum types. I think it gets a bit more escoteric beyond that though - i don't doubt that there's probably some haskell extension for quotient types[2] or some other category theory high-jinx. Most languages have ADTs built in. [1] https://blogs.oracle.com/javamagazine/post/inside-the…
Your examples, on the TIOBE index, are #4, #18, and #28. https://www.tiobe.com/tiobe-index/
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
Re: Algebraic Data Types for C99
#154Could 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.
The 4th example at https://en.cppreference.com/w/cpp/utility/variant/visit
that uses a class template makes the feature a bit nicer, but still not as ergonomic as something like Rust.
Re: Algebraic Data Types for C99
#155> PLEASE, do not use top-level break/continue inside statements provided to of and ifLet; use goto labels instead. Seems like a pretty big footgun. But otherwise, very cool.
goto is a footgun only if you use it to move from function to function, which btw was what "goto considered harmful" was about. That practice has disappeared, and now goto, within a function, is pretty harmless and quite identical to break/continue in fact.
Re: Algebraic Data Types for C99
#156> PLEASE, do not use top-level break/continue inside statements provided to of and ifLet; use goto labels instead. Seems like a pretty big footgun. But otherwise, very cool.
Using goto instead isn't a problem, but knowing not to use break/continue inside of such blocks is something that you will have to be aware of.
I had written a immediate mode UI out of macros, and this reminded me of that although in my case it is not a problem, although some blocks are ones that you can use "break". For example, you can use "break" to exit out of a win_form block ("goto" also works), while a win_command block does not capture "break" so using break (or goto) inside of a win_command block will break out of whatever block the win_command is in (probably a win_form block; for example, this would commonly be used in the case of a "Cancel" button).
Re: Algebraic Data Types for C99
#157Interesting. Algebraic Data Types are almost always one of the things I miss when I use imperative languages. I have to do Java at work, and while I've kind of come around on Java and I don't think it's quite as bad as I have accused it of being, there's been several dozen instances of "man I wish Java had F#'s discriminated unions". Obviously I'm aware that you can spoof it with a variety of techniques, and often en…
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’m in the latter camp (from Ocaml) and now using Go. Go feels clunky and awkward.
Re: Algebraic Data Types for C99
#158Earlier quoted context omitted.
That's exactly where I am. Pattern matched sum types "feel great" to code in to an expert because they are a concise and reasonably tight way to express the otherwise boring "enumerate over possibilities" code. But they're hard to read for anyone who isn't an expert on not just the language but the type in question (c.f. Rust's Option() idioms all looks like line noise to newbies, etc...). And that's a bad trade. In…
You've got to distinguish syntax from semantics, though. I agree, it's easy to turn a big semantic win into a net readability loss if you choose to represent it with an overly terse syntax that promotes code golf.
Compilers are really smart. It's easy enough in the modern world to demand that a "type" field be checked against all enumerants, preserving the "semantic win". A plain old C switch statement with gcc -Wall will do this today, in fact.
Re: Algebraic Data Types for C99
#159Earlier quoted context omitted.
Your examples, on the TIOBE index, are #4, #18, and #28. https://www.tiobe.com/tiobe-index/
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)
Re: Algebraic Data Types for C99
#160Earlier 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…
> I have multiple times wondered which of those two approaches would be better in a given situation, often wanting some aspects of both. ADTs are closed to extension with new cases but open to extension with new functions, eg. anytime you want to add new cases, you have to update all functions that depend on the ADT, but you can add as many functions for that ADT as you like with no issues. Traits are open to extensi…
I suppose this is a genuine dichotomy, but I feel like it’s missing a more critical difference: ADTs cleanly represent data, even when nothing can be, or needs to be, extended from outside.
For example, a result is a success value or an error. A stock order is a market order or a limit order, and nothing else, at least until someone updates the spec and recompiles the code. Situations like this happen all the time. I don’t want to extend a result to include gizmos in addition to success value or errors, nor do I generally want to extend the set of functions that operate on a certain sort of result. But I very, very frequently want to represent values with a specific, simple schema, and ADTs fit the bill. A bunch of structs/classes, interfaces/traits and getters/setters can do this, but the result would look like the worst stereotypes of enterprise Java code to accomplish what a language with nice ADTs can do with basically no boilerplate.