Unsafe functions

From HaskellWiki

Unsafe perforatives

[Using the FFI] you can import any C function with a pure type, which also allows you to wreak arbitrary havoc. We enable the user to disguise arbitrary machine code as a Haskell function of essentially arbitrary type. In comparison, unsafePerformIO seems angelic.

Manuel Chakravarty

Definitely not functions![edit]

Regarding the perforative entity val execute: α Beh ⟶ α for PFL+:

Unfortunately execute is not a safe extension to a functional language because it is not unfoldable—witness the expression

(x ⟼ x-x)(execute(i?x. Ret x))

which unfolds to

execute(i?x. Ret x) - execute(i?x. Ret x)

The first executes by reading one value from channel i, then returning 0; while the second reads two values from i, and returns their difference. The first makes one suspension, the second two.

Nor is execute a function; the subexpression execute(i?x. Ret x) can take on two different values in the expression above.

PFL+: A Kernel Scheme for Functional I/O (pages 15-16 of 28).

A rogues' gallery[edit]

These are just some of the various unsafe perforatives lurking in libraries:

  • unsafeLocalState :: IO a -> a
  • unsafePerformIO :: IO a -> a
  • inlinePerformIO :: 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
  • unsafeCoerce# :: a -> b

Unsafe perforatives can:

  • break type safety (unsafeCoerce#, unsafeLocalState, unsafePerformIO),

Their use would require some kind of assurance on the part of the programmer that what they're doing is safe, particularly in multithreaded programs - if they are misused in vain attempts to hide externally-visible effects the resulting code simply will not be pure, whatever type it is given.



unsafe is also a keyword which can be used in a foreign import declaration.


This article is a stub. You can help by expanding it.