What is a monad in FP, categorically?

Question

Every time someone promises “explains the monads”, my interest is aroused only to be replaced by disappointment when the supposed “explanation” is a long list of examples ending with some kind of sloppy remark that “mathematical theory "behind" esoteric ideas "is" too difficult to explain at this stage. "

Now I ask for the opposite. I have a clear understanding of category theory, and I'm not afraid of persecution of diagrams, Yoneda lemma or derivative functors (and indeed, in monads and additions in a categorical sense).

Can someone give me a clear and precise definition of what a monad is in functional programming? The fewer examples, the better: sometimes one clear concept speaks of more than a hundred timid examples. Haskell is great for demonstration, although I'm not picky.

Answer 1

As a compliment to Karl, the Monad in Haskell (theoretically):

class Monad m where join :: m (ma) -> ma return :: a -> ma fmap :: (a -> b) -> ma -> mb 

Note that "bind" ( >>= ) can be defined as

 x >>= f = join (fmap fx) 

According to the Haskell Wiki

The monad in category C is a triple (F: C → C, η: Id → F, μ: F ∘ F → F)

... with some axioms. For Haskell, fmap , return and join same as F, η, and μ, respectively. ( fmap in Haskell defines a functor). If I'm not mistaken, Scala calls these map , pure and join respectively. (Scala calls bind "flatMap")

Answer 2

This question has good answers: Monads as additions

Moreover, Derek Elkins’s article “Design Monads with Category Categories” in TMR # 13 should look like the constructions you are looking for: http://www.haskell.org/wikiupload/8/85/TMR-Issue13.pdf

Finally, and perhaps this is really the closest to what you are looking for, you can go directly to the source and see the original Moggi articles on this topic from 1988-91: http://www.disi.unige.it/person /MoggiE/publications.html

See, in particular, "Concepts of Computing and Monads."

---

My own I'm sure too concise / inaccurate:

Start with the Hask category, whose objects are Haskell types and whose morphisms are functions. Functions are also objects in Hask , and are also products. So, Hask Cartesian closed. Now imagine an arrow mapping each object in Hask to MHask , which is a subset of the objects in Hask . Units ism! Then enter the arrow that displays each arrow in the Hask arrow in MHask . This gives us a map and makes the MHask covariant endophone. Now imagine an arrow displaying every object in MHask that is generated from an object in MHask (through a unit) to an object in MHask that generates it. Join! And from this, MHask is a monad (and a monoidal endophone, more precisely).

I am sure that there is a reason why this is due to a lack, so I really refer you, if you are looking for formalism, to Moggy's documents in particular.

Answer 3

Ok, using Haskell terminology and examples ...

Functional programming monad is a composition template for data types with type * -> * .

 class Monad (m :: * -> *) where return :: a -> ma (>>=) :: ma -> (a -> mb) -> mb 

(The class is larger than Haskell, but these are important parts.)

A data type is a monad if it can implement this interface while satisfying three conditions in the implementation. These are the “laws of the monad," and I will leave it to those old explanations for a full explanation. I summarize the laws, because " (>>= return) is an identical function, and (>>=) associative." It really is nothing more, even if it can be expressed more accurately.

And this is the whole monad. If you can implement this interface while retaining these behavioral properties, you have a monad.

This explanation is probably shorter than you expected. This is because the monad interface is very abstract. An incredible level of abstraction is part of why so many different things can be modeled as monads.

What is less obvious, as abstract as an interface, it allows you to generally simulate any control flow template, regardless of the actual implementation of the monad. That is why in the Control.Monad package in the GHC base library there are such combiners as when , forever , etc. And therefore, the ability to explicitly abstract from any monad implementation is powerful, especially with the support of the type system.

Answer 4

I do not know what I'm talking about, but here is my take:

Monads are used to represent calculations. You can come up with a normal procedural program, which basically is a list of statements, as a set of compiled calculations. Monads are a generalization of this concept, allowing you to determine how statements form. Each calculation has a value (it can only be () ); the monad simply determines how the behavior spent on a series of calculations behaves.

Notation really makes this clear: it is basically a special type of language based on operators that allows you to determine what happens between statements. It is as if you could define how ";" worked in C-type languages.

In this light, all the monas that I have used so far make sense: State does not affect the value, but updates the second value, which is passed from calculation to calculation in the background; Maybe closes the value if it ever occurs with Nothing ; List allows you to have a variable number of values ​​passed; IO allows you to safely pass unclean values. The more specialized monads that I used, such as Gen and Parsec parsers, are also similar.

Hope this is a clear explanation that is not completely out of base.

Answer 5

You should read an article by Eugene Moggy "Concepts on Computing and Monads" that explains the proposed role of monads in order to structure the denotational semantics of effective languages.

A related question also arises:

References for learning the theory of pure functional languages ​​such as Haskell?

Since you do not want to wave your arms, you should read scientific articles, not forum answers or study guides.

Answer 6

The monad is a monoid in the endofunctors category, what is the problem? .

Unlike humor, I personally believe that monads, since they are used in Haskell and functional programming, are better understood from the point of view of monads as an interface (as in the answers of Karl and Dan), and not from monads in terms of theory. I must admit that I really only learned the whole monad thing when I had to use a monadic library from another language in a real project.

You mentioned that you didn’t like all the “many examples” tutorials. Has anyone ever pointed you to Awkward squad paper? It is centered on the IO monad, but the introduction provides a good technical and historical explanation of why Haskell first covered the monad concept.

Answer 7

Since you understand monads in a theoretical sense, I interpret your question as a representation of monads in functional programming. Thus, my answer avoids any explanation of what a monad is, or any intuition about its meaning or use.

The answer . In Haskell, the monad is represented in the internal language for a certain category as (internalized) Claysley triple cards.

Explanation : It is difficult to be precise with respect to the properties of the Hask category, and these properties are largely irrelevant to the understanding of Haskell's concept of monads. Instead, for this discussion, it is more useful to understand Haskell as an internal language for some category C. Haskell functions define morphisms in C , and Haskell types are objects in C , but the specific category in which these definitions are made is not significant.

Parametric data types, for example. data F a = ... , are object mappings, for example. F : | C | -> | | -> | C | .

The usual description of a monad in Haskell is in the Kleisli triple (or Kleisli extension):

 class Monad m where return :: a -> ma (>>=) :: ma -> (a -> mb) -> mb 

Where:

• m is a mapping of the object m :| C | -> | | -> | C |
• return - device operation on objects
• >>= (pronounced "bind" by Haskellers) is an extension operation for morphisms, but with the first two parameters replaced (see the usual extension signature (-)* : (a -> mb) -> ma -> mb )

(These maps themselves are internalized as families of morphisms in C , which is possible since m :| C | -> | C | ).

Haskell do is abstract (if you come across this), therefore it is an internal language for Kleisli categories.

Answer 8

The Haskell wikibook page has a good basic explanation.