proposal: add 'unsafeCoerce'

[Simon Marlow]

Robert Dockins wrote:
> 
> On Nov 21, 2006, at 8:01 AM, Simon Marlow wrote:
> 
>> Malcolm Wallace wrote:
>>
>>> Taral <taralx at gmail.com> writes:
>>>
>>>> On 11/20/06, Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk> wrote:
>>>>
>>>>>    newtype Wrapper a = Wrap a
>>>>>    convert :: [a] -> [Wrapper a]
>>>>>    convert xs = map Wrap xs
>>>>
>>>>
>>>> Interesting! Looks like the compiler lacks rules for optimizing "map
>>>> id" &c.\
>>>
>>> And not all compilers have optimisation phases.
>>>
>>>> Your coercion does assume that the underlying runtime doesn't have
>>>> some kind of type-tag implementation of type classes.
>>>
>>> I believe this is guaranteed by the definition of newtype in the
>>> Language Report.
>>
>>
>> The language doesn't say anything about the runtime representation  of 
>> newtype. It so happens that the semantics lead to the obvious  
>> implementation of a newtype   as a type cast (that was the reason  for 
>> introducing newtype, after all), but there's nothing to say you  have 
>> to implement it this way.  It would be wrong to require that  
>> unsafeCoerce let you convert between a newtype and its underlying  
>> type across implementations.
> 
> 
>  From Section 4.2.3, from the Haskell report:
> 
> A declaration of the form
> 
> newtype cx => T u1 ... uk = N t
> 
> introduces a new type whose representation is the same as an existing  
> type. The type (T u1 ... uk) renames the datatype t. It differs from  a 
> type synonym in that it creates a distinct type that must be  explicitly 
> coerced to or from the original type. Also, unlike type  synonyms, 
> newtype may be used to define recursive types. The  constructor N in an 
> expression coerces a value from type t to type (T  u1 ... uk). Using N 
> in a pattern coerces a value from type (T u1 ...  uk) to type t. These 
> coercions may be implemented without execution  time overhead; newtype 
> does not change the underlying representation  of an object.

*blink*

I stand corrected (for the second time today, duh, maybe I should check facts 
before trusting my memory next time...).

I have no idea why the report does say that though.  Seems very odd, there's no 
need to mention the representation.  Indeed, the language provides no way 
(absent unsafeCoerce) for a programmer to determine what the representation is, 
so how should we interpret that paragraph?  An invisible requirement or an 
implementation hint?

Cheers,
	Simon