4 ms·

> To do this with a sum type you'd have to have a common super type of string and nil and no other types. I'm not sure you understand sum types. Sum types sub

> To do this with a sum type you'd have to have a common super type of string and nil and no other types. I'm not sure you understand sum types. Sum types subsume normal unions; sum types and unions are essentially the same thing and capturing this kind of return type in Haskell or ML is extremely easy. "Supertypes" are completely unrelated and subtyping is not actually needed in languages with sum types (for example Haskell has sum types but doesn't have any real form of subtyping). For example in Haskell you'd use the `Maybe` type constructor. If your type returns a `Maybe String` that means it either returns a string or nothing.

dllthomas 12y ago
You can implement a (open) sum type with supertypes, though, can't you?
- theseoafs 12y ago
  Sort of. You can effectively do so in a language like Java, which allows you to inspect the types of objects at runtime. For example if you have a class `Foo` with two subclasses `SubA` and `SubB` you could do something like this: public static void test(Foo f) { if (f isinstanceof SubA) { SubA a = (SubA)f; /* ... */ } else if (f isinstanceof SubB) { SubB b = (SubB)f; } } This works okay but you have to implement all the machinery yourself, and for a statically typed language Java is notoriously type-unsafe so if you make a mistake with your casts you're basically not going to find out until you get an exception at runtime. And of course there might be other existing subclasses of `Foo` which means that you get no compile-time guarantee that you didn't miss a possible case. Standard ML approaches subtyping in a very different way that renders this kind of approach impossible. It gives you less freedom in that it eliminates downcasting, but that ultimately results in a safer language. Of course Standard ML has proper sum types with all of their compile-time guarantees so there's little reason for it anyway.
  - deleted 12y ago
    [deleted]
  - dllthomas 12y ago
    The way I was envisioning it, there needn't be any down-casting at the language level. Particularly if you want to close the sum type (which you need anyway if you want exhaustiveness checks): public static void test(MaybeFoo mf) { switch(mf.type) { case MaybeFoo.NOTHING: /* ... */ break; case MaybeFoo.JUST: Foo f = mf.getFoo(); /* ... */ break; } } Still has exhaustiveness checking and no downcasts. Still can throw if you use the wrong get* under one of those branches, so I'm certainly not saying it's ideal, but I think it legitimately expresses a sum type and can be implemented in most any language with small adjustments.
    - bjeanes 12y ago
      I'd never thought about this before in the context of Java. IIRC, Java can not have type-parameterized enums (i.e. generic enums), so a Maybe<T> isn't possible. I hope I'm wrong — it's been a while since I did much Java.
      - dllthomas 12y ago
        Well, you certainly can by expanding the parameterization manually like I did above. I think you're otherwise correct, though - I don't think Java will presently do it for you.
    - tel 12y ago
      This works fine, it just suffers from boolean blindness.
      - dllthomas 12y ago
        Could you elaborate? I think I understand "boolean blindness" but I'm not sure how it applies here. MaybeFoo.type is deliberately an enum. (I could totally be missing/misunderstanding something, though...)

dllthomas 12y ago

You can implement a (open) sum type with supertypes, though, can't you?

theseoafs 12y ago
Sort of. You can effectively do so in a language like Java, which allows you to inspect the types of objects at runtime. For example if you have a class `Foo` with two subclasses `SubA` and `SubB` you could do something like this: public static void test(Foo f) { if (f isinstanceof SubA) { SubA a = (SubA)f; /* ... */ } else if (f isinstanceof SubB) { SubB b = (SubB)f; } } This works okay but you have to implement all the machinery yourself, and for a statically typed language Java is notoriously type-unsafe so if you make a mistake with your casts you're basically not going to find out until you get an exception at runtime. And of course there might be other existing subclasses of `Foo` which means that you get no compile-time guarantee that you didn't miss a possible case. Standard ML approaches subtyping in a very different way that renders this kind of approach impossible. It gives you less freedom in that it eliminates downcasting, but that ultimately results in a safer language. Of course Standard ML has proper sum types with all of their compile-time guarantees so there's little reason for it anyway.
- deleted 12y ago
  [deleted]
- dllthomas 12y ago
  The way I was envisioning it, there needn't be any down-casting at the language level. Particularly if you want to close the sum type (which you need anyway if you want exhaustiveness checks): public static void test(MaybeFoo mf) { switch(mf.type) { case MaybeFoo.NOTHING: /* ... */ break; case MaybeFoo.JUST: Foo f = mf.getFoo(); /* ... */ break; } } Still has exhaustiveness checking and no downcasts. Still can throw if you use the wrong get* under one of those branches, so I'm certainly not saying it's ideal, but I think it legitimately expresses a sum type and can be implemented in most any language with small adjustments.
  - bjeanes 12y ago
    I'd never thought about this before in the context of Java. IIRC, Java can not have type-parameterized enums (i.e. generic enums), so a Maybe<T> isn't possible. I hope I'm wrong — it's been a while since I did much Java.
    - dllthomas 12y ago
      Well, you certainly can by expanding the parameterization manually like I did above. I think you're otherwise correct, though - I don't think Java will presently do it for you.
  - tel 12y ago
    This works fine, it just suffers from boolean blindness.
    - dllthomas 12y ago
      Could you elaborate? I think I understand "boolean blindness" but I'm not sure how it applies here. MaybeFoo.type is deliberately an enum. (I could totally be missing/misunderstanding something, though...)