[Haskell-cafe] Type system speculation

[wren ng thornton]

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.

-- 
Live well,
~wren