Unsafe functions

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!

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

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),

• or break equational reasoning (unsafeInterleaveIO).

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.