This mail is in reply to something posted to the Standard Haskell
WWW page / mailing list. If this is not the best forum for such
responses, please let me know what is.
The quoted material following is drastically elided.
> John Peterson: Typecasts (Another message from Alastair)
...
> The Problem
> ~~~~~~~~~~~
>
> newtype is supposed to introduce a __ZERO COST__ way of changing the type
> of an expression for the purposes of information hiding or to let you
> define two instances for the same representation. For example, the
> following is typical:
>
> newtype Natural = MkNat Integer
...
> The problem comes when you want to convert a list (say) of Integer's to a list
> of Naturals. The only way to do so is to write:
>
> map MkNat xs
>
> and the compiler usually won't be able to optimise this to just "xs".
> (And if it can optimise it, it does so using sophisticated optimisations
> like "foldr-build" which are not widely implemented, are list-specific
> and are rather fragile.)
>
> So newtype fails to provide a __ZERO COST__ way of changing types.
With *current* compilers, yes. But the problem you refer to may be
forgotten about next year, if compiler optimization gets a little better.
If this problem is really important enough to worry about, then
it would not be difficult to do the necessary compiler optimization.
A good compiler will already specialize `map mkNat'.
The problem is just that the compiler may not notice that the
specialized version just traverses a list and reconstructs it.
But a quite simple bottom-up analysis could identify functions which
happen to be identity functions (modulo do-nothing newtype type conversions),
and optimize them away.
Implementing this would be easier than adding support for your
proposed language extensions, I think.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
