[Haskell-cafe] Type system speculation
wren ng thornton
wren at freegeek.org
Wed Dec 9 22:47:56 EST 2009
Andrew Coppin wrote:
> What we're really trying to do here is attach additional information to
> a value - information which exists only in the type checker's head, but
> has no effect on runtime behaviour (other than determining whether we
> *get* to runtime). As far as I can tell, Haskell does not provide any
> way to take an existing type and attach additional information to it in
> such a way that code which cares about the new information can make use
> of it, but existing code which doesn't care continues to work. Any
> comments on this one?
In defense of Haskell, that's not what the semantics of newtype are. The
semantics of newtype declare that the, er, new type is unrelated to the
old type--- despite however they may be represented at runtime. Thus,
allowing functions to ignore the newtype wrapper would defeat the
intentions of using newtypes in the first place. I actually find this to
be one of the most powerful things in the type system of H98, and I miss
having them in every other language where I'm forced to sacrifice
performance or correctness.
As a stop-gap measure you can always make your newtype a functor and
then use (<$>) for application instead of ($) or whitespace.
That said, I've also considered the ability to have a "multi-type"
system where types can be annotated with orthogonal information like
Perl's taint flag (which your example resembles) or which subset of IO
is used for some particular IO x (e.g., which exceptions can be thrown).
There's some trickiness with getting multi-types to work right because
we'd like to be able to restrict certain functions to only accept
sanitized values, or values in a given format, or what have you. That
is, just passing the information around at the type level isn't enough,
we have to be able to restrict it too. It's certainly a worthy avenue of
research to work the kinks out and get a nice workable system.
More information about the Haskell-Cafe