Unsafe Functions

Donald Bruce Stewart dons at cse.unsw.edu.au
Tue Apr 25 19:49:00 EDT 2006


ashley:
> I would like to start a discussion on the role of unsafe functions in 
> Haskell:
> 
>   unsafePerformIO :: IO a -> a
>   unsafeInterleaveIO :: IO a -> IO a
>   unsafeInterleaveST :: ST s a -> ST s a
>   unsafeIOToST :: IO a -> ST s a
>   unsafeIOToSTM :: IO a -> STM a
>   unsafeFreeze, unsafeThaw,
>   unsafePreservingMatrix, unsafeRenderPrimitive
> 
> perhaps also
> 
>   unsafeForeignPtrToPtr :: ForeignPtr a -> Ptr a
>     (which is already under Foreign.*)
>   hGetContents :: Handle -> IO String
>     (which is lazy rather than unsafe per se)
> 
> * Do you use these, and what for?

    unsafePerformIO,    for making pure functions from foreign library bindings.
    unsafeInterleaveIO, less common, sometimes used to implement low
                        level Chan-like constructs using foreign IO primitives.

> * Is there safe functionality that can currently only be obtained with them?

    Foreign library bindings, as in Text.Regex, use unsafePerformIO extensively. 
  
> * Do you think they should be standardised, and how?
> 
> I'm thinking the unsafe functions should be moved from System.IO.Unsafe 
> and elsewhere to Unsafe, similar to Foreign.*, to better separate them 
> from "real Haskell" conceptually. Also, I would add:
> 
>   unsafeCoerce :: a -> b

Something like:
    Unsafe.IO
    Unsafe.ST ?

This came up recently when discussing why peek and poke aren't 'unsafe'
but Data.Array.Base.unsafeRead/Write are.

It would make it easier to control the system in program like lambdabot,
which evaluate arbitrary user code, and thus need to restrict the
namespace to a trusted base that can't contain any unsafe* functions.
Checking that functions (particularly Array) don't export anything
unsafe was a bit tedious.

-- Don


More information about the Libraries mailing list