Algebraic Data Types in Haskell (serokell.io)

I also do this! It is so painful not to have real ADTs.

While it doesn't bring you Haskell ADTs, it sounds like it could make your `isinstance`-style code a lot cleaner.

Tuples can be emulated using structs but it can generate a lot of boilerplate for a single function. The only alternative to express iterating over "zipped" lists is to have the two lists side by side and iterate using an integer.

However, sum types are just plain missing. I guess interfaces help, but they're really limiting in what they allow and even regular C-style enums are painful and can't be checked for exhaustivity at compile time.

Does anyone have tips on what the "idiomatic" solutions are for these problems?

You should look into functools.singledispatch if you're doing business logic with isinstance. But you should also learn about object-oriented programming, inheritance vs composition, mixins, etc. People get sour on OOP because they should have learned FP first and then imitate/translate FP idioms -- instead of doing something like modeling domain ontologies in object graphs. Likewise, people get sour on FP yadda yadda instead of trying to literally write their programs as proofs to theorems.

It’ll get rid of the ‘isinstance’ and give exhaustive matching. I used to use this pattern a lot when wanting ADT’s in a language without ADT’’s.

    sealed interface Point {}
    record Cartesian(double x, double y) implements Point {}
    record Polar(double r, double theta) implements Point {}

const MyNumberUnion = union { small: u8, medium: u16, large: u32, }

The values of MyNumberUnion can have a small, medium, OR large, but only one of those.

If we were to believe that "build yet another interface every time" was an equally good solution which is just a different flavour from sum types we'd expect to see equivalent APIs in Go with such interfaces and we do not. It's not a different style, it's just worse.

Example, suppose I got a string from a user, u, and I am now trying to see where that string is in another string I have from somewhere, x

In Rust x.find(u) returns Option<usize>, ie either None or Some(number)

But in Go strings.Index(x, u) returns int, and I have to know that the integer -1 is used as a sentinel value meaning "not found" rather than "found at position -1".

OK, so strings don't have great ergonomics, how about file opening? Let's open a file named george.txt which alas might not exist.

In Rust File::open("george.txt") returns Result<File>, ie either an Error or Ok(File)

But in Go os.Open("george.txt") return a tuple with both an error and my file and then I need to check whether the error was actually nil (no error).

> I wonder if there is an interesting interaction between those.

There's a rather rich theory of polynomial endofunctors (i.e. generic types with one type parameter built from products, sums, and non-generic types), and I think monads figure prominently (they're somehow related to the initial algebras for such functors). So there's definitely a relationship there.

    data Bool = False | True
    data Maybe a = Nothing | Just a

On the other hand, `Just` and `Nothing` are constructors, or variants, for values of type `Maybe a`. You can think of them as almost like static factories (as in `Optional.empty()` and `Optional.of(val)` in Java), except that algebraic constructors are invertible: you can match on a value to determine whether it was constructed with `Just` or `Nothing`, and what the arguments to the constructor were.

The dynamic scripting languages can do a "maybe" type because they can do just about anything when it comes to types; what they can't do is enforce correct usage by restrictions, so you write a Maybe type but you can't ever quite be sure it's doing what you think it's doing. This is just something you end up living with in dynamically typed langauges.

For instance you can certainly do:

    type Maybe<X> = { tag: 'just', value: X } | { tag: 'nothing'};
    type Either<X, Y> = { tag: 'left', value: X } | { tag: 'right', value: Y };

    function either<X, Y, Z>(fromLeft: (x: X) => Z, fromRight: (y: Y) => Z, xy: Either<X, Y>): Z {
        switch (xy.tag) {
            case 'left': return fromLeft(xy.value);
            case 'right': return fromRight(xy.value);
        }
    }

(The "sum" and "product" are why they're called "algebraic". You can also analyze them as power series, such as in computing derivatives for zippers)

Intersection types are something else (that Haskell does not have built in to my knowledge).

"union" is slightly imprecise, because sum types are tagged (i.e., a non-discriminated union of Int and Int is just Int, but Int+Int is actually the same as (Bool, Int). True non-discriminated union types are relatively uncommon in static type systems, but TypeScript for example does have them)