Dylan 'nullable' types [Was: Close review of Language Overview whitepaper]
graydon at mozilla.com
Wed Dec 5 14:27:40 PST 2007
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.
> 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
More information about the Es4-discuss