Monads In Functional Programming

A monad can be thought of as an alternate mathematical "world" that supplements each value and function with extra functionality. They enable a programmer to make the routine parts of a computation implicit, such as the order of operations or the detection of errors, while focusing on the aspects that are more relevant to the problem at hand. To define a monad, the programmer provides a set of rules for attaching the implicit handling to a given value or function, so that executing the function will also execute the monad's calculations. The IO monad, for example, attaches the action of reading input to the calculation that uses the input. One disadvantage of monads is that they do not combine easily; it is not straightforward to attach the functionality of several monads to a single computation. Monad Transformers can achieve this effect when necessary, at the cost of adding complexity. HISTORY After the mathematical background, the concept of monads was first applied to programming in the context of purely functional programming and the Haskell programming language. Earlier versions of Haskell had had inadequate means for IO and monads were devised during the development of Haskell 98 as a suitable system for combining extensible IO 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 System s compete with monads in describing side effects as types. EXAMPLE: MAYBE MONAD 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: par:: Float -> Float -> Float -- Takes two real numbers and returns another 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 : -- "Maybe Float" extends the Float type so that it can represent failed calculations. (//):: Float -> Float -> Maybe Float x // y = ... -- the definition is in next section par:: Float -> Float -> Maybe Float par x y = 1 // ((1 // x) + (1 // y)) We would like that the result of the division operator could be passed into any other function. At the end we might have just a number, or if some divisor was zero, we might have nothing:
	Data Maybe A	Just a Nothing

Information About

Monads In Functional Programming