Re: proposal: add 'unsafeCoerce'

Hello, I just wanted to point out that even the 'reasonable' uses of 'unsafeCoerce' (i.e., where a type does not appear directly in a value) may not be compatible between different implementations. Consider, for example, an implementation which turns a polymorphic program into a monomorphic one by generating different versions of functions for each of its instantiations (this is not a new idea). In particular, one also has to specialize constructor functions, which amounts to specializing datatypes. For example, 'Either@Int@Char' and 'Either@Int@Bool' become completely separate types. In addition, we may choose to add only those constructors of a specialized type that actually appear in the program. For example, 'Either@Int@Char' may have both constructors 'Left@Int@Char' and 'Righ@Int@Char', while 'Either@Int@Bool' may only have a single constructor 'Right@Int@Bool'. Now, if we use an integer tag to distinguish constructors, then by using 'unsafeCoerce' we may end up casting 'Left@Int@Char' into 'Right@Int@Bool'. -Iavor On 11/21/06, Malcolm Wallace wrote:

"David House" wrote:

...

...

* cast that changes a phantom type, or changes a type that is not reflected by a part of the value, eg. 'unsafeCoerce (Left 3) :: Either Int a' should be fine for any 'a',

Couldn't we have the following for this case?

castEitherL :: Either a b -> Either a c castEitherL (Left x) = Left x castEitherL z = z

castEitherR :: Either a b -> Either c b castEitherR (Right x) = Right x castEitherR z = z

No actually. Try it! Any compiler will reject the catch-all cases ('z') because you are asking for the usage of z on the rhs to be at a different type than the pattern usage of z on the lhs.

Regards, Malcolm _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries