Editing Ru/IO Inside (section)

=== unsafePerformIO ===

Programmers coming from an imperative language background often look for a way to execute IO actions inside a pure procedure. But what does this mean?
Imagine that you're trying to write a procedure that reads the contents of a file with a given name, and you try to write it as a pure (non-IO) function:

<haskell>
readContents :: Filename -> String
</haskell>

Defining readContents as a pure function will certainly simplify the code that uses it. But it will also create problems for the compiler:

# This call is not inserted in a sequence of "world transformations", so the compiler doesn't know at what exact moment you want to execute this action. For example, if the file has one kind of contents at the beginning of the program and another at the end - which contents do you want to see?  You have no idea when (or even if) this function is going to get invoked, because Haskell sees this function as pure and feels free to reorder the execution of any or all pure functions as needed.
# Attempts to read the contents of files with the same name can be factored (''i.e.'' reduced to a single call) despite the fact that the file (or the current directory) can be changed between calls. Again, Haskell considers all non-IO functions to be pure and feels free to omit multiple calls with the same parameters.

So, implementing pure functions that interact with the Real World is
considered to be Bad Behavior. Good boys and girls never do it ;)


Nevertheless, there are (semi-official) ways to use IO actions inside
of pure functions. As you should remember this is prohibited by
requiring the RealWorld "baton" in order to call an IO action. Pure functions don't have the baton, but there is a special "magic" procedure that produces this baton from nowhere, uses it to call an IO action and then throws the resulting "world" away!  It's a little low-level magic :)  This very special (and dangerous) procedure is:

<haskell>
unsafePerformIO :: IO a -> a
</haskell>

Let's look at its (possible) definition:

<haskell>
unsafePerformIO :: (RealWorld -> (a, RealWorld)) -> a
unsafePerformIO action = let (a, world1) = action createNewWorld
                         in a
</haskell>

where 'createNewWorld' is an internal function producing a new value of
the RealWorld type.

Using unsafePerformIO, you can easily write pure functions that do
I/O inside. But don't do this without a real need, and remember to
follow this rule: the compiler doesn't know that you are cheating; it still
considers each non-IO function to be a pure one. Therefore, all the usual
optimization rules can (and will!) be applied to its execution. So
you must ensure that:

# The result of each call depends only on its arguments.
# You don't rely on side-effects of this function, which may be not executed if its results are not needed.


Let's investigate this problem more deeply. Function evaluation in Haskell
is determined by a value's necessity - the language computes only the values that are really required to calculate the final result. But what does this mean with respect to the 'main' function?  To "calculate the final world's" value, you need to perform all the intermediate IO actions that are included in the 'main' chain. By using 'unsafePerformIO' we call IO actions outside of this chain.  What guarantee do we have that they will be run at all? None. The only time they will be run is if running them is required to compute the overall function result (which in turn should be required to perform some action in the
'main' chain). This is an example of Haskell's evaluation-by-need strategy. Now you should clearly see the difference:

- An IO action inside an IO procedure is guaranteed to execute as long as
it is (directly or indirectly) inside the 'main' chain - even when its result isn't used (because the implicit "world" value it returns ''will'' be used). You directly specify the order of the action's execution inside the IO procedure. Data dependencies are simulated via the implicit "world" values that are passed from each IO action to the next.

- An IO action inside 'unsafePerformIO' will be performed only if
result of this operation is really used. The evaluation order is not
guaranteed and you should not rely on it (except when you're sure about
whatever data dependencies may exist).


I should also say that inside 'unsafePerformIO' call you can organize
a small internal chain of IO actions with the help of the same binding
operators and/or 'do' syntactic sugar we've seen above.  For example, here's a particularly convoluted way to compute the integer that comes after zero:

<haskell>
one :: Int
one = unsafePerformIO $ do var <- newIORef 0
                           modifyIORef var (+1)
                           readIORef var
</haskell>

and in this case ALL the operations in this chain will be performed as
long as the result of the 'unsafePerformIO' call is needed. To ensure this,
the actual 'unsafePerformIO' implementation evaluates the "world" returned
by the 'action':

<haskell>
unsafePerformIO action = let (a,world1) = action createNewWorld
                         in (world1 `seq` a)
</haskell>

(The 'seq' operation strictly evaluates its first argument before
returning the value of the second one).