Monads in functional programming

From Wikipedia, the free encyclopedia

You have new messages (last change).

Some functional programming languages make use of monads[1] [2] to structure programs which include operations that must be executed in a specific order. The name monad derives from category theory, a branch of mathematics that describes patterns applicable to many mathematical fields.

The primary uses of monads in functional programming are to express input/output (I/O) operations and changes in state without using language features that introduce side effects[3]. They exploit a loophole that, although a function cannot directly cause a side effect, it can construct a value describing a desired side effect that the caller should apply at a convenient time. However, I/O and state management are by no means the only uses of monads. They are useful in any situation where the programmer wants to carry out a purely functional computation while a related computation is carried out "on the side."

The Haskell programming language is a functional language that makes heavy use of monads, and includes syntactic sugar to make monad composition more convenient. All of the code samples below are written in Haskell unless noted otherwise.

Contents

[edit] Motivation

Before discussing the details of monads, it might help to give a motivating example. Consider a function that is undefined for some known values, such as division. Division might occur repeatedly in a calculation, like this one, which returns the resistance of two electrical resistors in parallel:

-- par is a function that takes two real numbers and returns another
par :: Float -> Float -> Float
par x y = 1 / ((1 / x) + (1 / y))

Instead of avoiding any errors by checking whether each divisor is zero, it might be convenient to have a modified division operator that does the check implicitly, as in the following pseudocode:

-- // is an operator that takes two "Maybe Float"s and returns another
-- "Maybe Float" extends the Float type to represent calculations that may fail.
(//) :: Maybe Float -> Maybe Float -> Maybe Float
x // y = ...   -- the definition appears below.

par :: Float -> Float -> Maybe Float
par x y = 1 // ((1 // x) + (1 // y))  -- types do not actually match
                                      -- see below for correct version

With the // operator, dividing by zero anywhere in the computation will result in the entire computation returning a special value of the Maybe monad called "Nothing", which indicates a failure to compute a value. Otherwise, the computation will produce a numerical result, contained in the other Maybe value, which is called "Just". The result of this division operator can then be passed to other functions. This concept of "maybe values" is one situation where monads are useful.

[edit] Concepts

[edit] Definition

The more common formulation of monads for programming (and particularly, the one used in Haskell) is known as a Kleisli triple. The "triple" refers to three mappings that together define a particular monad:

  1. A type constructor that defines, for every type, a corresponding type "in the monad." This type incorporates the original type in a way that allows computations on the original type independently of computations related to the monad. In Haskell's notation, the name of the monad represents the type constructor. If M is the name of the monad and t is a data type, then "M t" is the corresponding type in the monad.
  2. A unit function that maps a value of any type to a value in the corresponding type in the monad. The result is the "simplest" value in the corresponding type that completely preserves the original value (simplicity being understood appropriately to the monad). In Haskell, this function is called return due to the way it is used in the do-notation described later. The unit function has the polymorphic type t→M t.
  3. A binding operation of polymorphic type (M t)→(t→M u)→M u, which Haskell represents by the infix operator >>=. Its first argument is a value of a type in the monad, its second argument is a function that maps from the underlying type of the first argument to another type in the monad, and its result is in that other type. The binding operation can be understood as having four stages:
    1. The monad-related structure on the first argument is "pierced" to expose any number of values in the underlying type t.
    2. The given function is applied to all of those values to obtain values of type (M u).
    3. The monad-related structure on those values is also pierced, exposing values of type u
    4. Finally, the monad-related structure is reassembled over all of the results, giving a single value of type (M u).

Consider how these apply to the "Maybe" example.

  1. A type in the Maybe monad is just the underlying type, plus a value representing "nothing", i.e. undefined.
    data Maybe t = Just t | Nothing
  2. A value mapped into the Maybe monad is just the same value.
    return x = Just x
  3. Applying a function to something that is just a value means applying it directly to that value. Applying a function to nothing produces nothing.
    (Just x) >>= f = f x
    Nothing >>= f = Nothing

[edit] Axioms

For a monad to behave correctly, the definitions must obey a few axioms.[4] (The ≡ symbol is not Haskell code, but indicates an equivalence between two Haskell expressions.)

  • "return" must preserve all information about its argument.
    (return x) >>= f ≡ f x
    m >>= return ≡ m
  • Binding two functions in succession is the same as binding one function that can be determined from them.
    (m >>= f) >>= g ≡ m >>= (\x -> f x >>= g)

In the last rule, the notation \x -> defines an anonymous function that maps any value x to the expression that follows.

[edit] Monadic zero

A monad can optionally define a "zero" value for every type. Binding a zero with any function produces the zero for the result type, just as 0 multiplied by any number is 0.

  • mzero >>= f ≡ mzero

Intuitively, the zero represents a value in the monad that has only monad-related structure no values from the underlying type. In the Maybe monad, "Nothing" is a zero.

[edit] do-notation

Although there are times when it makes sense to use >>= directly in a program, it is more typical to use a format called "do-notation" that mimics the appearance of non-functional languages. The compiler translates do-notation to expressions involving >>=. For example, the following definitions are equivalent:

a = do x <- [3..4]
       [1..2]
       return (x, 42)

a = [3..4] >>= (\x -> [1..2] >>= (\y -> return (x, 42)))

The do-block notation can be used with any monad as it is simply syntactic sugar for >>=.

The following definition for safe division for values in the Maybe monad are also equivalent:

x // y = do
  a <- x  -- Extract the values "inside" x and y, if there are any.
  b <- y
  if b == 0 then mzero else return (a / b)

x // y = x >>= (\a -> y >>= (\b -> if b == 0 then mzero else return (a / b)))

[edit] Examples

[edit] Maybe monad

The Maybe monad has already been defined above. The following definitions complete the original motivating example of the "par" function.

add x y = do
  x' <- x
  y' <- y
  return (x' + y')

par x y = let
  one = return 1
  jx = return x
  jy = return y
  in one // (add (one // jx) (one // jy))

If the result of any division is Nothing, it will propagate through the rest of the expression.

[edit] Identity monad

The simplest monad is the identity monad, which attaches no information to values.

Id t = t
return x = x
x >>= f = f x

A do-block in this monad performs variable substitution; do {x <- 2; 3*x} results in 6.

[edit] Collections

Some familiar collection types, including lists, sets, and multisets, are monads. The definition for lists is given here.

-- "return" constructs a one-item list.
return x = [x]
-- "bind" concatenates the lists obtained by applying f to each item in list xs.
xs >>= f = concat (map f xs)
-- The zero object is an empty list.
mzero = []

In the list monad, a do-block is a list comprehension. For example, do {x <- [1..n]; 2*x} corresponds to the mathematical expression "(2×1,2×2,...,2×n)."

The monads for sets and multisets support the use of set-builder notation similarly. The set monad is useful when the state of a computation is ambiguous, as in a parser that has not read enough input to decide what syntax it is reading. The parser can maintain a set that represents the possible syntaxes, and scan until the set has one item (meaning that a syntax was recognized) or no items (meaning that the input is unacceptable).

[edit] I/O

A monad for I/O operations is usually implemented in the language implementation rather than being defined publicly. The following example demonstrates the use of an I/O monad to interact with the user.

do
  putStrLn "What is your name?"
  name <- getLine
  putStrLn ("Nice to meet you, " ++ name ++ "!")

[edit] State transformers

A state transformer monad allows a programmer to attach state information of any type to a calculation. Given any value, the corresponding value in the state transformer monad is a function that accepts a state, then outputs another state along with a value.

type StateTrans s t = s -> (t, s)

Note that this monad, unlike those already seen, takes a type parameter, the type of the state information. The monad operations are defined as follows:

-- "return" produces the given value without changing the state.
return x = \s -> (x, s)
-- "bind" modifies transformer m so that it applies f to its result.
m >>= f = \r -> let (x, s) = m r in (f x) s

Useful state transformers include:

readState = \s -> (s, s) -- Examine the state at this point in the computation.
writeState x = \s -> ((), x) -- Replace the state.

Another operation applies a state transformer to a given initial state:

applyTrans:: StateTrans s a -> s -> (a, s)
applyTrans t s = t s

do-blocks in a state monad are sequences of operations that can examine and update the state data.

[edit] Others

Other concepts that researchers have expressed as monads include:

[edit] Alternate formulation

Although Haskell defines monads in terms of the "return" and "bind" functions, it is also possible to define a monad in terms of "return" and two other operations, "join" and "map". This formulation fits more closely with the definition of monads in category theory. The map operation, with type (t→u)→(M t→M u), takes a function between two types and produces a function that does the "same thing" to values in the monad. The join operation, with type M (M t)→M t, "flattens" two layers of monadic information into one.

The two formulations are related as follows. As before, the ≡ symbol indicates equivalence between two Haskell expressions.

(map f) m ≡ m >>= (\x -> return (f x))
join m ≡ m >>= (\x -> x)

m >>= f ≡ join ((map f) m)

[edit] History

Eugenio Moggi first described the general use of monads to structure programs.[5] Several people built on his work, including programming language researchers Phillip Wadler and Simon Peyton-Jones, both involved in the specification of Haskell. Early versions of Haskell used a problematic "lazy list" model for I/O, and Haskell 1.3 introduced monads as a more flexible way to combine I/O with lazy evaluation.

In addition to IO, scientific articles and Haskell libraries have successfully applied monads to varying topics including parsers and programming language interpreters. The concept of monads along with the Haskell do-notation for them has also been generalized to form arrows.

As of 2006, Haskell and its derivatives are the only major users of monads in programming. There exist formulations also in Scheme and Perl, and monads have been an option in the design of a new ML standard. Effect systems compete with monads in describing side effects as types.

[edit] See also

Wikibooks
Wikibooks Haskell has a page on the topic of

[edit] References

  1. ^ Philip Wadler. Comprehending Monads. Proceedings of the 1990 ACM Conference on LISP and Functional Programming, Nice. 1990.
  2. ^ Philip Wadler. The Essence of Functional Programming. Conference Record of the Nineteenth Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages. 1992.
  3. ^ Simon L. Peyton Jones, Philip Wadler. Imperative Functional Programming. Conference record of the Twentieth Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, Charleston, South Carolina. 1993
  4. ^ The three fundamental laws of Monad. See this page
  5. ^ Moggi, Eugenio (1991). "Notions of Computation and Monads". Information and Computation 93 (1).

[edit] External links

Retrieved from "http://en.wikipedia.org../../../m/o/n/Monads_in_functional_programming.html"
In other languages