Signature of IO in Haskell (is this class or data?)

Question

The question is not what IO does, but how is it defined, its signature. Specifically, is this data or class, is "a" its type parameter then? I didn't find it anywhere. Also, I don't understand the syntactic meaning of this:

f :: IO a

Answer 1

You asked whether IO a is a data type: it is. And you asked whether the a is its type parameter: it is. You said you couldn't find its definition. Let me show you how to find it:

localhost:~ gareth.rowlands$ ghci
GHCi, version 7.6.3: http://www.haskell.org/ghc/  :? for help
Prelude> :i IO
newtype IO a
  = GHC.Types.IO (GHC.Prim.State# GHC.Prim.RealWorld
                  -> (# GHC.Prim.State# GHC.Prim.RealWorld, a #))
    -- Defined in `GHC.Types'
instance Monad IO -- Defined in `GHC.Base'
instance Functor IO -- Defined in `GHC.Base'
Prelude> 

In ghci, :i or :info tells you about a type. It shows the type declaration and where it's defined. You can see that IO is a Monad and a Functor too.

This technique is more useful on normal Haskell types - as others have noted, IO is magic in Haskell. In a typical Haskell type, the type signature is very revealing but the important thing to know about IO is not its type declaration, rather that IO actions actually perform IO. They do this in a pretty conventional way, typically by calling the underlying C or OS routine. For example, Haskell's putChar action might call C's putchar function.

Answer 2

IO is a polymorphic type (which happens to be an instance of Monad, irrelevant here).

Consider the humble list. If we were to write our own list of Ints, we might do this:

data IntList = Nil | Cons { listHead :: Int, listRest :: IntList }

If you then abstract over what element type it is, you get this:

data List a = Nil | Cons { listHead :: a, listRest :: List a }

As you can see, the return value of listRest is List a. List is a polymorphic type of kind * -> *, which is to say that it takes one type argument to create a concrete type.

In a similar way, IO is a polymorphic type with kind * -> *, which again means it takes one type argument. If you were to define it yourself, it might look like this:

data IO a = IO (RealWorld -> (a, RealWorld))

^{(definition courtesy of this answer)}

Answer 3

The amount of magic in IO is grossly overestimated: it has some support from compiler and runtime system, but much less than newbies usually expect.

Here is the source file where it is defined:

http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-prim-0.3.0.0/src/GHC-Types.html

newtype IO a
  = IO (State# RealWorld -> (# State# RealWorld, a #))

It is just an optimized version of state monad. If we remove optimization annotations we will see:

data IO a = IO (Realworld -> (Realworld, a))

So basically IO a is a data structure storing a function that takes old real world and returns new real world with io operation performed and a.

Some compiler tricks are necessary mostly to remove Realworld dummy value efficiently.

IO type is an abstract newtype - constructors are not exported, so you cannot bypass library functions, work with it directly and perform nasty things: duplicate RealWorld, create RealWorld out of nothing or escape the monad (write a function of IO a -> a type).

Answer 4

Since IO can be applied to objects of any type a, as it is a polymorphic monad, a is not specified.

If you have some object with type a, then it can be 'wrappered' as an object of type IO a, which you can think of as being an action that gives an object of type a. For example, getChar is of type IO Char, and so when it is called, it has the side effect of (From the program's perspective) generating a character, which comes from stdin.

As another example, putChar has type Char -> IO (), meaning that it takes a char, and then performs some action that gives no output (in the context of the program, though it will print the char given to stdout).

Edit: More explanation of monads:

A monad can be thought of as a 'wrapper type' M, and has two associated functions:
return and >>=.

Given a type a, it is possible to create objects of type M a (IO a in the case of the IO monad), using the return function.

return, therefore, has type a -> M a. Moreover, return attempts not to change the element that it is passed -- if you call return x, you will get a wrappered version of x that contains all of the information of x (Theoretically, at least. This doesn't happen with, for example, the empty monad.)

For example, return "x" will yield an M Char. This is how getChar works -- it yields an IO Char using a return statement, which is then pulled out of its wrapper with <-.

>>=, read as 'bind', is more complicated. It has type M a -> (a -> M b) -> M b, and its role is to take a 'wrappered' object, and a function from the underlying type of that object to another 'wrappered' object, and apply that function to the underlying variable in the first input.

For example, (return 5) >>= (return . (+ 3)) will yield an M Int, which will be the same M Int that would be given by return 8. In this way, any function that can be applied outside of a monad can also be applied inside of it.

To do this, one could take an arbitrary function f :: a -> b, and give the new function g :: M a -> M b as follows:

g x = x >>= (return . f)

Now, for something to be a monad, these operations must also have certain relations -- their definitions as above aren't quite enough.

First: (return x) >>= f must be equivalent to f x. That is, it must be equivalent to perform an operation on x whether it is 'wrapped' in the monad or not.

Second: x >>= return must be equivalent to m. That is, if an object is unwrapped by bind, and then rewrapped by return, it must return to its same state, unchanged.

Third, and finally (x >>= f) >>= g must be equivalent to x >>= (\y -> (f y >>= g) ). That is, function binding is associative (sort of). More accurately, if two functions are bound successively, this must be equivalent to binding the combination thereof.

Now, while this is how monads work, it's not how it's most commonly used, because of the syntactic sugar of do and <-.

Essentially, do begins a long chain of binds, and each <- sort of creates a lambda function that gets bound.

For example,

a = do x <- something
       y <- function x
       return y

is equivalent to

a = something >>= (\x -> (function x) >>= (\y -> return y))

In both cases, something is bound to x, function x is bound to y, and then y is returned to a in the wrapper of the relevant monad.

Sorry for the wall of text, and I hope it explains something. If there's more you need cleared up about this, or something in this explanation is confusing, just ask.