Group items tagged

map, (but called fmap in Haskell 98) actually comes from the definition of a functor

That is, if f is a functor, and we are given a function of type (a -> b), and a container of type (f a), we can get a new container of type (f b). This is expressed in the type of fmap: fmap :: (Functor f) => (a -> b) -> f a -> f b If you will give me a blueberry for each apple I give you (a -> b), and I have a box of apples (f a), then I can get a box of blueberries (f b). Every monad is a functor.

The second method, return, is specific to monads. If m is a monad, then return takes an element of type a, and gives a container of type (m a) with that element in it. So, its type in Haskell is return :: (Monad m) => a -> m a If I have an apple (a) then I can put it in a box (m a).

takes a container of containers m (m a), and combines them into one m a in some sensible fashion. Its Haskell type is join :: (Monad m) => m (m a) -> m a

If I have a box of boxes of apples (m (m a)) then I can take the apples from each, and put them in a new box (m a).

bind or extend, which is commonly given the symbol (>>=)

liftM :: (Monad m) => (a -> b) -> m a -> m b liftM f xs = xs >>= (return . f) -- take a container full of a's, to each, apply f, -- put the resulting value of type b in a new container, -- and then join all the containers together.

The function that does this for any monad in Haskell is called liftM -- it can be written in terms of return and bind as follows:

Well, in Haskell, IO is a monad.

Lists are most likely the simplest, most illustrative example

The reason that bind is so important is that it serves to chain computations on monadic containers together.

You might notice a similarity here between bind and function application or composition, and this is no coincidence.

What bind does is to take a container of type (m a) and a function of type (a -> m b). It first maps the function over the container, (which would give an m (m b)) and then applies join to the result to get a container of type (m b). Its type and definition in Haskell is the

xs >>= f = join (fmap f xs)

bind (>>=)

One of them you have seen explicitly -- it's the 'return' method, responsible for packing things up into the monad. The other is called 'bind' or '>>=', and it does the 'unpacking' involved with the <- arrow in the do notation.

the 'bind' method doesn't really unpack and return the data. Instead, it is defined in such a way that it handles all unpacking 'internally', and you have to provide functions that always have to return data inside the monad.

It looks very much like 'unpack this data from the monad so I can use it', so it helps conceptually. In fact, together with the rest of the body of the 'do' block it forms an anonymous lambda function,

A general purpose language is almost useless, if you can't develop user interfaces or read files. We would like to read keyboard input or print things to the terminal.

We have seen that we can solve this problem by expecting a state argument. But what's our state? The state of the terminal?

We seem to have found a useful solution to our problem. Just pass the state value around. But there is a problem with this approach.

A very special feature of Haskell is the concept of generalization. That means, instead of implementing an idea directly, you rather try to find a more general idea, which implies your idea as a special case.

However, the traditional programmer never had to face generalization. At most they faced abstraction,

they are a very abstract structure, which allows implementing functionality at an incredibly general level.

Haskell [1] is a purely functional programming language. Functions written in it are referentially transparent. Intuitively that means that a function called with the same arguments always gives the same result.

askell takes another approach. Instead of passing the world state explicitly, it employs a structure from category theory called a monad.

They are an abstract structure, and at first it can be difficult to understand where they are useful. The two main interpretations of monads are as containers and as computations.

The ⊥ value is a theoretical construct. It's the result of a function, which never returns, so you can't observe that value directly. Examples are functions, which recurse forever or which throw an exception. In both cases, there is no ordinary returning of a value.

Now that Nothing is a valid result, our function handles all cases.

You have some computation with a certain type of result and a certain structure in its result (like allowing no result, or allowing arbitrarily many results), and you want to pass that computation's result to another computation.

a functor is a type constructor PLUS a function fmap satisfying some laws.

I think it's better to use existentials, as they let you define multiple instances for the same type.

People tend to forget that the major difference between ADT's and OO-style classes is really only that with a class you can have many instances in the same program simultaneously, whereas with an ADT you can have only one; but the ADT implementation is still interchangeable.

sequence :: Monad m => [m a] -> m [a]