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