Dylan 'nullable' types [Was: Close review of Language Overview whitepaper]
P T Withington wrote:
I must say, coming from Dylan, es3's undefined and null seem like
overkill... but we're stuck with them now!
I think they feel like overkill to everyone, but yeah. Backward compatibility!
I guess it's one of these things we may try and static-analyze-away.
Cheers, David
P.S.: Should I mention OCaml's option types or Haskell's maybes at this point ?
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!)
On 2007-11-14, at 19:22 EST, Graydon Hoare wrote:
The Dylan equivalent of a nullable type is a union of your type with a
singleton that acts as the sentinel. Most often a singleton of the
boolean false value is used. So there is a macro
false-or(<type>)that expands to
type-union(<type>, singleton(#f)). This works forany type other than a nullable boolean. Because any value other than
#f coerces to true in a boolean context, #f is very similar to nil.
I've never known anyone to need a nullable boolean. (Although I have
seen whacky es3 code that uses true/false/null as a sloppy 3-valued
enumeration -- with attended bug reports when null is passed expecting
it to behave like false.)
I must say, coming from Dylan, es3's undefined and null seem like
overkill... but we're stuck with them now!