Monad (functional programming)

[a][b] Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model.

[3][4] Since monads make semantics explicit for a kind of computation, they can also be used to implement convenient language features.

Some languages, such as Haskell, even offer pre-built definitions in their core libraries for the general monad structure and common instances.

With these elements, the programmer composes a sequence of function calls (a "pipeline") with several bind operators chained together in an expression.

Typically, the bind operator >>= may contain code unique to the monad that performs additional computation steps not available in the function received as a parameter.

Undefined null results are one particular pain point that many procedural languages don't provide specific tools for dealing with, requiring use of the null object pattern or checks to test for invalid values at each operation to handle undefined values.

[1][5] However, monads do not actually order computations; even in languages that use them as central features, simpler function composition can arrange steps within a program.

A monad's general utility rather lies in simplifying a program's structure and improving separation of concerns through abstraction.

Because they let application programmers implement domain logic while offloading boilerplate code onto pre-developed modules, monads can even be considered a tool for aspect-oriented programming.

When translated from category-theory to programming terms, the monad structure is a generic concept and can be defined directly in any language that supports an equivalent feature for bounded polymorphism.

[citation needed] The form defined above using bind, however, was originally described in 1965 by mathematician Heinrich Kleisli in order to prove that any monad could be characterized as an adjunction between two (covariant) functors.

According to programming language researcher Philip Wadler, computer scientist John C. Reynolds anticipated several facets of it in the 1970s and early 1980s, when he discussed the value of continuation-passing style, of category theory as a rich source for formal semantics, and of the type distinction between values and computations.

[4] The research language Opal, which was actively designed up until 1990, also effectively based I/O on a monadic type, but the connection was not realized at the time.

[21] The computer scientist Eugenio Moggi was the first to explicitly link the monad of category theory to functional programming, in a conference paper in 1989,[22] followed by a more refined journal submission in 1991.

In earlier work, several computer scientists had advanced using category theory to provide semantics for the lambda calculus.

[3] Several others popularized and built on this idea, including Philip Wadler and Simon Peyton Jones, both of whom were involved in the specification of Haskell.

Formulations now exist in Scheme, Perl, Python, Racket, Clojure, Scala, F#, and have also been considered for a new ML standard.

[citation needed] One benefit of the monad pattern is bringing mathematical precision on the composition of computations.

Monads can lay the groundwork for useful syntactic features while their high-level and mathematical nature enable significant abstraction.

Although using bind openly often makes sense, many programmers prefer a syntax that mimics imperative statements (called do-notation in Haskell, perform-notation in OCaml, computation expressions in F#,[30] and for comprehension in Scala).

A non-monadic version of add in Haskell looks like this: In monadic Haskell, return is the standard name for unit, plus lambda expressions must be handled explicitly, but even with these technicalities, the Maybe monad makes for a cleaner definition: With do-notation though, this can be distilled even further into a very intuitive sequence: A second example shows how Maybe can be used in an entirely different language: F#.

By doing this, any new monad that matches the structure interface and implements its own map will immediately inherit a lifted version of add too.

Their two type signatures are: The first is interested in whether a given file really exists, and as a result, outputs a Boolean value within the IO monad.

The second function, on the other hand, is only concerned with acting on the file system so the IO container it outputs is empty.

IO is not limited just to file I/O though; it even allows for user I/O, and along with imperative syntax sugar, can mimic a typical "Hello, World!"

A free monad can be used to track syntax and type while leaving semantics for later, and has found use in parsers and interpreters as a result.

Technically, a comonad is the categorical dual of a monad, which loosely means that it will have the same required components, only with the direction of the type signatures reversed.

In fact, while not as popular as monads, researchers have found comonads particularly useful for stream processing and modeling dataflow programming.

As an even higher abstraction, arrows can subsume both structures, but finding more granular ways to combine monadic and comonadic code is an active area of research.

[37][38] Alternatives for modeling computations: Related design concepts: Generalizations of monads: HaskellWiki references: Tutorials: Interesting cases: