Avoiding IO

From HaskellWiki

Revision as of 04:42, 13 January 2009

Haskell requires an explicit type for operations involving input and output. This way it makes a problem explicit, that exists in every language: Input and output functions can have so many effects, that the type signature says more or less that almost everything must be expected. It is hard to test them, because they can in principle depend on every state of the real world. Thus in order to maintain modularity you should avoid IO wherever possible.

but we want to present some clean techniques to avoid IO.

1 Lazy construction

You can avoid a series of output functions by constructing a complex data structure with non-IO code and output it with one output function.

Instead of

-- import Control.Monad (replicateM_)
replicateM_ 10 (putStr "foo")

putStr (concat $ replicate 10 "foo")

Similarly,

do
  h <- openFile "foo" WriteMode
  replicateM_ 10 (hPutStr h "bar")
  hClose h

can be shortened to

writeFile "foo" (concat $ replicate 10 "bar")

in case of failure.

Since you have now an expression for the complete result as string, you have a simple object that can be re-used in other contexts.

without bothering the file system, again.

2 Writer monad

If the only reason that you need IO is to output information (e.g. logging, collecting statistics), a Writer monad might do the job. This technique works just fine with lazy construction, especially if the lazy object that you need to create is a Monoid.

An inefficient example of logging:

logText :: (MonadWriter String m) => String -> m ()
logText text = tell (text ++ "\n")
 
  do
    logText "Before operation A"
    opA
    logText "After operation A"

3 State monad

Another example is random number generation. In cases where no real random numbers are required, but only arbitrary numbers, you do not need access to the outside world. You can simply use a pseudo random number generator with an explicit state. This state can be hidden in a State monad.

Example: A function which computes a random value with respect to a custom distribution

can be defined via IO

randomDist :: (Random a, Num a) => (a -> a) -> IO a
randomDist distInv = liftM distInv (randomRIO (0,1))

but there is no need to do so. You don't need the state of the whole world just for remembering the state of a random number generator. What about

randomDist :: (RandomGen g, Random a, Num a) => (a -> a) -> State g a
randomDist distInv = liftM distInv (State (randomR (0,1)))

evalState (randomDist distInv) (mkStdGen an_arbitrary_seed)

4 ST monad

In some cases a state monad is simply not efficient enough. Say the state is an array and the update operations are modification of single array elements.

and you can define new operations in ST, but then you need to resort to unsafe operations. You can escape from ST to non-monadic code in a safe, and in many cases efficient, way.

5 Custom monad type class

If you only use a small set of IO operations in otherwise non-IO code you may define a custom monad type class which implements just these functions. You can then implement these functions based on IO for the application and without IO for the test suite.

As an example consider the function

localeTextIO :: String -> IO String

which converts an English phrase to the currently configured user language of the system.

class Monad m => Locale m where
   localeText :: String -> m String
 
instance Locale IO where
   localeText = localeTextIO
 
instance Locale Identity where
   localeText = Identity

where the first instance can be used for the application and the second one for "dry" tests.

newtype Interpreter a = Interpreter (Reader (Map String String) a)
 
instance Locale Interpreter where
   localeText text = Interpreter $ fmap (Map.findWithDefault text text) ask

6 Last resort

When you apply it, think about how to reduce its use and how you can encapsulate it in a library with a well chosen interface.

Categories: Monad | Idioms | Style