<div dir="ltr">unsafeCoerce just tells the typechecker to use a different type for that value. Values of all types as stored in memory have pretty much the same basic layout: constructor tag as an Int# counting upward from 0 per type, followed by a pointer for each associated value (or the actual value if it's unboxed; so an Int is stored as an 0# followed by an Int# representing its value), each of these consuming a single basic word (64 bits on a 64-bit platform). So a Bool is the same as an Int# which is 0# or 1#, and for an Either String Int you have a constructor tag 0# for Left or 1# for Right, followed by a single pointer whose associated type is determined by the constructor tag (here, either it points to a String or to an Int).<div><br></div><div>Unpacking and/or unboxing values can alter this and complicate things. See the GHC manual with respect to the UNPACK pragma and -funbox-strict-fields; you may under some circumstances need to disable optimization if you want to (ab)use unsafeCoerce.</div><div><br></div><div>So in short, info tables don't usually come into play at this level. But you can cause core dumps if you're not careful, especially if you do something like coercing a value from a type with 2 constructors to a type that has only 1. It is, however, safe if you ensure the runtime representation of values of both types are the same (but as above, ensuring this sometimes means compiling without optimization).</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 13, 2018 at 10:47 PM Cosmia Fu <<a href="mailto:cosmiafu@gmail.com">cosmiafu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I have noticed that unsafeCoerce is able to<br>
<br>
> Prelude> import Unsafe.Coerce<br>
> Prelude Unsafe.Coerce> data P = P Int Double deriving Show<br>
> Prelude Unsafe.Coerce> data Q a b = Q a b deriving Show<br>
> Prelude Unsafe.Coerce> unsafeCoerce (P 23 2.33) :: Q Int Double<br>
> Q 23 2.33<br>
<br>
And it works even for sum type, and the first constructor always wins.<br>
<br>
> Prelude Unsafe.Coerce> data M a = J a deriving Show<br>
> Prelude Unsafe.Coerce> unsafeCoerce (J "qwe") :: Either String String<br>
> Left "qwe"<br>
> Prelude Unsafe.Coerce> unsafeCoerce (Just "qwe") :: M String<br>
> J "qwe"<br>
<br>
And the documenation for unsafeCoerce# says<br>
<br>
> Casting between two types that have the same runtime representation. One case is when the two types differ only in "phantom" type parameters, for example Ptr Int to Ptr Float, or [Int] to [Float] when the list is known to be empty. Also, a newtype of a type T has the same representation at runtime as T.<br>
> <a href="http://hackage.haskell.org/package/base-4.11.1.0/docs/GHC-Exts.html#v:unsafeCoerce-35-" rel="noreferrer" target="_blank">http://hackage.haskell.org/package/base-4.11.1.0/docs/GHC-Exts.html#v:unsafeCoerce-35-</a><br>
<br>
But info tables for different constructors are different. Why does the<br>
code above work?<br>
<br>
And is it safe to use unsafeCoerce like this?<br>
<br>
Thanks,<br>
Cosmia Fu<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>brandon s allbery kf8nh</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a></div></div></div></div></div>