Dylan 'nullable' types [Was: Close review of Language Overview whitepaper]

[Graydon Hoare]

David Teller wrote:
> I guess it's one of these things we may try and static-analyze-away.

Yeah. There are representational costs and value-testing costs. Both can 
be optimized away statically or dynamically, in some cases. Depends how 
fancy an implementation you're doing.

> P.S.:
>  Should I mention OCaml's option types or Haskell's maybes at this
> point ?

Speaking as the person who proposed them, the union types in ES4 are 
explicitly intended to capture use-cases made easy in such type systems: 
option types and tree processing.

We followed a slightly circuitous route in developing the feature, mind 
you. Mostly because we already had, and wished to keep, a more-familiar 
form of named data constructor -- classes -- and didn't want to 
duplicate it any more than necessary. Initially I think I proposed to 
follow HaXe's more ML-like lead of recycling the 'enum' form of the C 
family, but this idea lost out during discussion.

At any rate "nullability" in ES4, which is the analogue of option types 
in the languages you mention, is presented similarly: as a union with null.

(The absence of ML/haskell's obligatory data constructors for each 
disjoint union member rewards us with the happy result of being able to 
use a single null though, rather than a freshly-typed NONE for every 'a 
option type it occupies. But then, we are also not trying to support 
type inference!)

-Graydon