9 ms·

> This has the benefit of giving you the ability to refer to a case as its own type. A case of a sum-type is an expression (of the variety so-called a type con

> This has the benefit of giving you the ability to refer to a case as its own type. A case of a sum-type is an expression (of the variety so-called a type constructor), of course it has a type. datatype shape = Circle of real | Rectangle of real * real | Point Circle : real -> shape Rectangle : real * real -> shape Point : () -> shape A case itself isn't a type, though it has a type. Thanks to pattern matching, you're already unwrapping the parameter to the type-constructor when handling the case of a sum-type. It's all about declaration locality. (real * real) doesn't depend on the existence of shape. 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. They're also no longer sum-types. If you have a sum-type of nominally distinct types, the sum-type is contingent on the existence of those types. In a class hierarchy, this relationship is bizarrely reversed and there are knock-on effects to that. > You declare the sum type once, and use it many times. And you typically write many sum-types. They're disposable. And more to the point, you also have to read the code you write. The cost of verbosity here is underestimated. > Slightly more verbose sum type declaration is worth it when it makes using the cases cleaner. C#/Java don't actually have sum-types. It's an incompatible formalism with their type systems. Anyways, let's look at these examples: C#: public abstract record Shape; public sealed record Circle(double Radius) : Shape; public sealed record Rectangle(double Width, double Height) : Shape; public sealed record Point() : Shape; double Area(Shape shape) => shape switch { Circle c => Math.PI * c.Radius * c.Radius, Rectangle r => r.Width * r.Height, Point => 0.0, _ => throw new ArgumentException("Unknown shape", nameof(shape)) }; ML: datatype shape = Circle of real | Rectangle of real * real | Point val result = case shape of Circle r => Math.pi * r * r | Rectangle (w, h) => w * h | Point => 0.0 They're pretty much the same outside of C#'s OOP quirkiness getting in it's own way.

ackfoobar 1y ago
> 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 1y ago
  > 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 1y ago
    Yes https://openjdk.org/jeps/409#Sealed-classes-and-pattern-matching 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 1y ago
    Yes, that's the whole purpose of marking an interface/class `sealed`.
- sunnydiskincali 1y ago
  > 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 1y ago

> 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 1y ago
> 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 1y ago
  Yes https://openjdk.org/jeps/409#Sealed-classes-and-pattern-matching 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 1y ago
  Yes, that's the whole purpose of marking an interface/class `sealed`.
sunnydiskincali 1y ago
> 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.