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 _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
