3 ms·

I see many examples where they do exactly what I described, checking for "None" as a parameter value. Sure, it's explicitly named as a possible value, but you S

I see many examples where they do exactly what I described, checking for "None" as a parameter value. Sure, it's explicitly named as a possible value, but you STILL have to make the check yourself. http://tutorial.ponylang.org/pattern-matching/match/#matching-on-type-and-value http://tutorial.ponylang.org/pattern-matching/match/#matchin... I see how it can be used in new and different ways, and is definitely safer, but it's not like the idea of "that thing you want isn't here" goes away by introducing a None type.

steveklabnik 11y ago
I think I prefer the Option type to using a union with None here, for the reason that you state. I'm coming at this from a type theory / language design perspective: unit types are very different than nullable types, though if you write a union type with unit as one of the possibilities, well... EDIT: Sorry, I was thinking of sum vs product here, union types are sum types. So this is the same thing as Option. Sounds good. The advantage of using a union type is that you _have_ to check. This is significantly better than nulls.
- tonyg 11y ago
  They're both sums, but Pony (and e.g. Typed Racket) has unlabelled unions, while Haskell/ML have labelled unions. Pony's (X | None) is not like Haskell's Maybe X in that in Haskell, X could be unit, while in Pony that would collapse the type to just None. In other words, in Haskell, Maybe (Maybe X) makes sense; in Pony and Typed Racket, it doesn't.
  - deleted 11y ago
    [deleted]
  - steveklabnik 11y ago
    Yet another terminology issue: do you mean tagged vs untagged? IE, there's an extra field for the discriminant. Or rather, Pony does _not_ have a discriminant, but Haskell/ML do? (I am 99% sure that's what you mean, but since I already screwed up terms once in this thread...)
    - tonyg 11y ago
      That's roughly it. I was referring to a difference at the type system level, rather than the runtime level, though. Disjoint unions aka sum types (as seen in Haskell/ML etc) entail some runtime way of keeping track which side of the sum any given inhabitant lies on. Tags are one way to do this, but e.g. in a language where pointers/references are never the zero machine word, and unit is represented as the zero word, no tag would be needed for the type Maybe String. Union types (as seen in Pony, apparently, and also in Typed Racket), by contrast, /don't/ preserve information about which side of the union an inhabitant came from. So, disjoint types: A + A ≠ A but union types: A ∪ A = A So expanding (Maybe X) into (X + 1), we have that (Maybe (Maybe X)) = ((X + 1) + 1) ≠ X + 1, but if instead (Maybe X) expands to (X ∪ 1), we have that (Maybe (Maybe X)) = ((X ∪ 1) ∪ 1) = X ∪ 1 = (Maybe X). This is one of the problems with uses of null in languages that have it.

steveklabnik 11y ago

I think I prefer the Option type to using a union with None here, for the reason that you state. I'm coming at this from a type theory / language design perspective: unit types are very different than nullable types, though if you write a union type with unit as one of the possibilities, well... EDIT: Sorry, I was thinking of sum vs product here, union types are sum types. So this is the same thing as Option. Sounds good. The advantage of using a union type is that you _have_ to check. This is significantly better than nulls.

tonyg 11y ago
They're both sums, but Pony (and e.g. Typed Racket) has unlabelled unions, while Haskell/ML have labelled unions. Pony's (X | None) is not like Haskell's Maybe X in that in Haskell, X could be unit, while in Pony that would collapse the type to just None. In other words, in Haskell, Maybe (Maybe X) makes sense; in Pony and Typed Racket, it doesn't.
- deleted 11y ago
  [deleted]
- steveklabnik 11y ago
  Yet another terminology issue: do you mean tagged vs untagged? IE, there's an extra field for the discriminant. Or rather, Pony does _not_ have a discriminant, but Haskell/ML do? (I am 99% sure that's what you mean, but since I already screwed up terms once in this thread...)
  - tonyg 11y ago
    That's roughly it. I was referring to a difference at the type system level, rather than the runtime level, though. Disjoint unions aka sum types (as seen in Haskell/ML etc) entail some runtime way of keeping track which side of the sum any given inhabitant lies on. Tags are one way to do this, but e.g. in a language where pointers/references are never the zero machine word, and unit is represented as the zero word, no tag would be needed for the type Maybe String. Union types (as seen in Pony, apparently, and also in Typed Racket), by contrast, /don't/ preserve information about which side of the union an inhabitant came from. So, disjoint types: A + A ≠ A but union types: A ∪ A = A So expanding (Maybe X) into (X + 1), we have that (Maybe (Maybe X)) = ((X + 1) + 1) ≠ X + 1, but if instead (Maybe X) expands to (X ∪ 1), we have that (Maybe (Maybe X)) = ((X ∪ 1) ∪ 1) = X ∪ 1 = (Maybe X). This is one of the problems with uses of null in languages that have it.