[ackfoobar]

> The moment you start ripping cases as distinct types out of the sum-type, you create the ability to side-step exhaustiveness and sum-types become useless in making invalid program states unrepresentable.

Quite the opposite, that gives me the ability to explicitly express what kinds of values I might return. With your shape example, you cannot express in the type system "this function won't return a point". But with sum type as sealed inheritance hierarchy I can.

> C#/Java don't actually have sum-types.

> They're pretty much the same

Not sure about C#, but in Java if you write `sealed` correctly you won't need the catch-all throw.

If they're not actual sum types but are pretty much the same, what good does the "actually" do?

[tomsmeding]

> Not sure about C#, but in Java if you write `sealed` correctly you won't need the catch-all throw.

Will the compiler check that you have handled all the cases still? (Genuinely unsure — not a Java programmer)

[ackfoobar]

Yes

https://openjdk.org/jeps/409#Sealed-classes-and-pattern-matc...

> with pattern matching for switch (JEP 406)the compiler can confirm that every permitted subclass of Shape is covered, so no default clause or other total pattern is needed. The compiler will, moreover, issue an error message if any of the three cases is missing

[brabel]

Yes, that's the whole purpose of marking an interface/class `sealed`.

[sunnydiskincali]

> With your shape example, you cannot express in the type system "this function won't return a point".

Sure you can, that's just subtyping. If it returns a value that's not a point, the domain has changed from the shape type and you should probably indicate that.

  structure Shape = struct
    datatype shape =
        Circle of real
      | Rectangle of real * real
      | Point
  end

  structure Bound = struct
    datatype shape =
        Circle of real
      | Rectangle of real * real
  end

This is doing things quick and dirty. For this trivial example it's fine, and I think a good example of why making sum-types low friction is a good idea. It completely changes how you solve problems when they're fire and forget like this.

That's not to say it's the only way to solve this problem, though. And for heavy-duty problems, you typically write something like this using higher-kinded polymorphism:

  signature SHAPE_TYPE = sig
    datatype shape =
        Circle of real
      | Rectangle of real * real
      | Point

    val Circle : real -> shape
    val Rectangle : real * real -> shape
    val Point : shape
  end

  functor FullShape () : SHAPE_TYPE = struct
    datatype shape =
        Circle of real
      | Rectangle of real * real
      | Point

    val Circle = Circle
    val Rectangle = Rectangle
    val Point = Point
  end

  functor RemovePoint (S : SHAPE_TYPE) :> sig
    type shape
    val Circle : real -> shape
    val Rectangle : real * real -> shape
  end = struct
    type shape = S.shape
    val Circle = S.Circle
    val Rectangle = S.Rectangle
  end


  structure Shape = FullShape()
  structure Bound = RemovePoint(Shape)

This is extremely overkill for the example, but it also demonstrates a power you're not getting out of C# or Java without usage of reflection. This is closer to the system of inheritance, but it's a bit better designed. The added benefit here over reflection is that the same principle of "invalid program states are unrepresentable" applies here as well, because it's the exact same system being used. You'll also note that even though it's a fair bit closer conceptually to classes, the sum-type is still distinct.

Anyways, in both cases, this is now just:

  DoesNotReturnPoint : Shape.shape -> Bound.shape

Haskell has actual GADTs and proper higher kinded polymorphism, and a few other features where this all looks very different and much terser. Newer languages bake subtyping into the grammar.

> If they're not actual sum types but are pretty much the same, what good does the "actually" do?

Conflation of two different things here. The examples given are syntactically similar, and they're both treating the constituent part of the grammar as a tagged union. The case isn't any cleaner was the point.

However in the broader comparison between class hierarchies and sum-types? They're not similar at all. Classes can do some of the things that sum-types can do, but they're fundamentally different and encourage a completely different approach to problem-solving, conceptualization and project structure... in all but the most rudimentary examples. As I said, my 2nd example here is far closer to a class-hierarchy system than sum-types, though it's still very different. And again, underlining that because of the properties of sum-types, thanks to their specific formalization, they're capable of things class hierarchies aren't. Namely, enforcing valid program-states at a type-level. Somebody more familiar with object-oriented formalizations may be a better person to ask than me on why that is the case.

It's a pretty complicated space to talk about, because these type systems deviate on a very basic and fundamental level. Shit just doesn't translate well, and it's easy to find false friends. Like how the Japanese word for "name" sounds like the English word, despite not being a loan word.

[ackfoobar]

You wrote a lot of words to say very little.

Anyway, to translate your example:

    sealed interface Shape permits Point, Bound {}
    final class Point implements Shape {}
    sealed interface Bound extends Shape permits Circle, Rectangle {}
    record Circle(double radius) implements Bound {}
    record Rectangle(double width, double height) implements Bound {}

A `Rectangle` is both a `Bound` (weird name choice but whatever), and a `Shape`. Thanks to subtyping, no contortion needed. No need to use 7 more lines to create a separate, unrelated type.

> the Japanese word for "name" sounds like the English word, despite not being a loan word.

Great analogy, except for the fact that someone from the Java team explicitly said they're drawing inspirations from ML.

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

[sunnydiskincali]

> You wrote a lot of words to say very little.

Substantiate this.

> weird name choice but whatever

I don't think this kind of snarky potshot is in line with the commentary guidelines. Perhaps you could benefit from a refresher?

https://news.ycombinator.com/newsguidelines.html#comments

> Thanks to subtyping, no contortion needed

I see the same degree of contortion, actually. Far more noisy, at that.

> No need to use 7 more lines to create a separate, unrelated type.

You're still creating a type, because you understand that a sum-type with a different set of cases is fundamentally a different type. Just like a class with a different set of inheritance is a different type. And while it's very cute to compress it all into a single line, it's really not compelling in the context of readability and "write once, use many". Which is the point you were making, although it was on an entirely different part of the grammar.

> Great analogy, except for the fact that someone from the Java team explicitly said they're drawing inspirations from ML.

ML didn't invent ADTs, and I think you know it's more than disingenuous to imply the quotation means that the type-system in Java which hasn't undergone any fundamental changes in the history of the language (nor could it without drastically changing the grammar of the language and breaking the close relationship to the JVM) was lifted from ML.

[ackfoobar]

> Substantiate this.

You never gave an example how sum types in Java/Kotlin cannot do what "real" sum types can.

>> weird name choice but whatever

> snarky potshot

Sorry that you read snark. What I meant was "I find naming this 'Bound' weird. But since I am translating your example, I'll reuse it".

> You're still creating an unrelated type

How can a type participating in the inheritance hierarchy be "unrelated"?

> I see the same degree of contortion, actually. Far more noisy, at that.

At this point I can only hope you're a Haskeller and do not represent an average OCaml programmer.

[ackfoobar]

PS rereading this I think "hope you're a Haskeller" might be read as an insult. That's not my intention, here's why I mention Haskell.

1. It's THE other language with a type system based on HM.

2. Variant constructors as functions. OCaml does not do that, Haskell does (slightly more elegant). This hints sunnydiskincali is more familiar with Haskell than OCaml.

3. I was confused by `type shape = S.shape`. How does `RemovePoint(Shape).shape` has the `Point` case removed then? I tried that on a REPL ^1 and it didn't even compile. Again, syntax errors hinting at Haskell experiences.

Well now I've written so much I may as well do a point-by-point refutation: ^2

> you create the ability to side-step exhaustiveness

Big claim, sounds scary to someone not familiar with sum types. But Java/Kotlin both enforce exhaustiveness. You could have provided an example in your second response, instead you dump a bunch of code that does not compile.

> Sure you can, that's just subtyping.

Then you followed up with an example that is not subtyping, but an unrelated type of a new set of new values.

> This is doing things quick and dirty. For this trivial example it's fine

This is not fine. I undersold the verbosity of your "quick and dirty" solution saying "7 lines". To actually work with those two types, the pair of conversion functions `Shape.shape -> Bound.shape option` and `Bound.shape -> Shape.shape` is needed.

> They're not similar at all.

~100 words in the paragraph, gestures to formalization, yet never explained how sum types implemented as sealed inheritance cannot be "enforcing valid program-states at a type-level". Thus my comment "a lot of words to say very little".

> You're still creating a type

I see you removed "unrelated" in an edit. The statement is now accurate but pointless. Of course I need to create a type, how else can I use the type system to say "this function won't return a point"?

> disingenuous to imply the quotation means that the type-system in Java ... was lifted from ML.

It would be more than disingenuous, colossally stupid even, if I did imply that. The wrongness would be on the level of claiming "English and Japanese are in the same language family".

Your cognate/false friend analogy is much smaller in scope, just like Java taking sum types (implementing them as sealed inheritance) from ML.

1: https://ocsigen.org/js_of_ocaml/toplevel/

2: https://xkcd.com/386/

[ackfoobar]

I'm very embarrassed to say this. Those code examples weren't non-compiling OCaml, but valid SML. Once I remembered the existence of the language (in my defence it was never mentioned in the thread), I managed to compile the code, and confirm my suspicion:

`val point: Bound.shape = Shape.Point` type-checks, because `type shape = S.shape`. To drive the point home, so does

    val DoesNotReturnPoint : Shape.shape -> Bound.shape = fn x => x

So the module example does not show "this function won't return a point" as one would have hoped.