Well, I apologize for starting this whole thread which involves so many dead kittens :(  I was just trying to help answer a question :) 
I guess I assumed too much.. that someone would think to be careful when using a function with the word 'unsafe' in it...

So, be warned, all Haskellers!  Be careful when using any function that starts with the word 'unsafe'!  You may kill a kitten!  And I guess this says something about using 'unsafe' functions... http://upload.wikimedia.org/wikipedia/en/1/11/God-kills-kitten.jpg (NSFW)...

Cheers and sorry all,
Tim


On Thu, Oct 22, 2009 at 1:59 PM, Gregory Crosswhite <gcross@phys.washington.edu> wrote:
Yes, I was once taught that "Every time you use unsafePerformIO, God kills a kitten,"  so every time I consider using it I first ask myself:  is this really worth an innocent kitten's life?

Cheers,
Greg


On Oct 22, 2009, at 11:32 AM, David Menendez wrote:

On Thu, Oct 22, 2009 at 2:23 AM, Gregory Crosswhite
<gcross@phys.washington.edu> wrote:
For clarity, one trick that uses "unsafePerformIO" which you may have seen
posted on this list earlier today is the following way of creating a
globally visible IORef:

import Data.IORef
import System.IO.Unsafe

*** counter = unsafePerformIO $ newIORef 0 ***

Danger! If the monomorphism restriction is disabled, this ends up
creating a value of type forall a. Num a => IORef a, which can be used
to break type safety.

More generally,

cell :: IORef a
cell = unsafePerformIO $ newIORef undefined

unsafeCoerce :: a -> b
unsafeCoerce x = unsafePerformIO $ do
  writeIORef cell x
  readIORef cell

This way lies segmentation faults. That "unsafe" is there for a reason.

--
Dave Menendez <dave@zednenem.com>
<http://www.eyrie.org/~zednenem/>

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe