Using unsafePerformIO safely?

[atravers]

 

@jaror

True, to get modularity, modules have to communicate which assumptions they make about the use of unsafePerformIO in [the] rest of the program.

Unfortunately, those assumptions would need to be pessimistic by default because of transitivity: a definition in one module can indirectly depend on a definition in another which uses unsafePerformIO. For most codebases, that could end up “tainting” many modules, quite possibly the majority of them.

It would then probably be easier to just assume the worst - that any module can be tainted - and not bother with those communications.

---

@jaror

Now I’m also wondering, a use of unsafePerformIO that is often considered safe is if all the side effects are encapsulated. […]

That resembles the “safe-usage” requirements for unsafeLocalState:

unsafeLocalState :: IO a → a

Sometimes an external entity is a pure function, except that it passes arguments and/or results via
pointers. The function unsafeLocalState permits the packaging of such entities as pure functions.
The only IO operations allowed in the IO action passed to unsafeLocalState are

(a) local allocation (alloca, allocaBytes and derived operations such as withArray and withCString), and

(b) pointer operations (Foreign.Storable and Foreign.Ptr) on the pointers to local storage, and

(c) foreign functions whose only observable effect is to read and/or write the locally allocated memory.

Passing an IO operation that does not obey these rules results in undefined behaviour.

It is expected that this operation will be replaced in a future revision of Haskell.

The Haskell 2010 Report (page 269 of 329).

…perhaps this is as close as anyone will get for now to a guide for the safe use of unsafePerformIO.