Functional Programming – Minimal Programmer’s Definition of a Monad

functional programmingjavascriptmonad

I am trying to formulate a definition of a monad without needing mathematical terms or Haskell to understand.

Can a monad be thought of as a function that accepts a value and wraps it such that it meets specific interface and behavioral constraints that have been found to be useful when working in a functional style?

The interface constraints are:

i. It has a type constructor that defines its type (What is this?).

ii. It has a unit function that converts a value to its corresponding monadic type.

iii. It has a "bind" method that takes a monad, a function that takes a some type and returns a monad (is this another monad?), and returns a monad.

The behavioral constraints are:

i. Left identity

Monad(x).bind(fn) == Monad(fn(x)); // for all x, fn

ii. Right identity

Monad(x).bind(function(x){return x;}) == Monad(x); // for all x

iii. Associativity

Monad(x).bind(fn1).bind(fn2) == Monad(x).bind(function(x) {
  return fn2(fn1(x));
});

Is this a minimal definition of a monad?

Best Answer

Mason's answer is correct, and yes you should read my series. To emphasize his point more thoroughly:

Can a monad be thought of as a function that accepts a value and wraps it such that it meets specific interface and behavioral constraints

Yes, but that is not the best way to characterize a monad. You are very close though; we can make small changes to your formulation and arrive at a better characterization.

You say a monad, call it M, is a function that accepts a value and produces a wrapped value. It is the is that is problematic. Rather, a monad has such a function. A monad M is a collection of three things:

A transformation that takes a type and produces a new type. In C# we call such a transformation a "generic type". We have a generic type M<T>, we have a type int, and we produce a new type M<int>.
A generic function unit which accepts a value of type T and produces a value of type M<T>.
A generic function bind which accepts a value of type M<T> and a function from T to M<U>, and produces an M<U>.

That second thing is your "function which accepts a value and wraps it". It's not that a monad is that function; a monad is the combination of the monadic type constructor itself, the wrapper, and the function which binds a new function onto the end of a monadic workflow.

This is why in category theory, monads are sometimes called "triples"; because you need three things to characterize a monad.

Now, you'll note that I do the same thing as you; in my series of articles I characterize a monad as a generic type that obeys certain rules; that is, I say that the monad is the first thing, and that first thing must itself have the second and third things.

How exactly we characterize the relationships between the parts doesn't really matter; what matters is that there must be these three things: a way to "amplify" types, a way to "wrap" values, and a way to transform an instance of a monad into to another by "binding" a function onto it. If you have those three things, and they obey the obvious rules for identity, transitivity, and so on, then you have a monad.

Related Solutions

Does groovy call partial application ‘currying’

Groovy's implementation of curry does not actually curry at any point, even behind the scenes. It is essentially identical to partial application.

The curry, rcurry and ncurry methods return a CurriedClosure object that holds the bound arguments. It also has a method getUncurriedArguments (misnamed—you curry functions, not arguments) which returns the composition of the arguments passed to it with the bound arguments.

When a closure gets called, it ultimately calls the invokeMethod method of MetaClassImpl, which explicitly checks to see if the calling object is an instance of CurriedClosure. If so, it uses the aforementioned getUncurriedArguments to compose the full array of arguments to apply:

if (objectClass == CurriedClosure.class) {
    // ...
    final Object[] curriedArguments = cc.getUncurriedArguments(arguments);
    // [Ed: Yes, you read that right, curried = uncurried. :) ]
    // ...
    return ownerMetaClass.invokeMethod(owner, methodName, curriedArguments);
}

Based on the confusing and somewhat inconsistent nomenclature above, I suspect that whoever wrote this has a good conceptual understanding, but was perhaps a little rushed and—like many smart people—conflated currying with partial application. This is understandable (see Paul King's answer), if a little unfortunate; it will be difficult to correct this without breaking backwards compatibility.

One solution I've suggested is to overload the curry method such that when no arguments are passed it does real currying, and deprecate calling the method with arguments in favour of a new partial function. This might seem a little strange, but it would maximise backwards compatibility—since there's no reason to use partial application with zero arguments—while avoiding the (IMHO) uglier situation of having a new, differently-named function for proper currying while the function actually named curry does something different and confusingly similar.

It goes without saying that the result of calling curry is completely different from actual currying. If it really curried the function, you would be able to write:

def add = { x, y -> x + y }
def addCurried = add.curry()   // should work like { x -> { y -> x + y } }
def add1 = addCurried(1)       // should work like { y -> 1 + y }
assert add1(1) == 2

…and it would work, because addCurried should work like { x -> { y -> x + y } }. Instead it throws a runtime exception and you die a little inside.

JavaScript Monad – When Does a Monad Become a Hammer?

It's hard to tell exactly what you're asking, so this answer is aimed at providing more context about monads. Some preliminaries about monads:

Crockford's monad talk is a poor source for learning about monads (I hate to say this because he's so much smarter than me, and therefore probably understand monads better than I do, but IMHO it gives an inaccurate portrayal of monads). So are lots of other monad "tutorials". If you don't put in hard work making your way through real examples, you'll probably never understand monads.
monads are neither special nor magical. They can be implemented in many (most? all?) programming languages without special support from the language/runtime/compiler/interpreter. They aren't the end-all, be-all of functional programming. But for some reason, they're what we hear about all the time.
monads aren't unique. There are many other related datatypes which are useful in their own right.
there are alternatives to monads, depending on what you want/need to do. Search for "effects systems" and "algebraic effects".
you can often get most/much of the value of monads without explicitly using them. Just implement the combinators that you need and are useful and use them appropriately. Recognize patterns in your code and factor them out, possibly capturing them as combinators. If some of those combinators happen to match the requirements for unit and join, so be it. That doesn't mean you have to think about what you're doing in terms of monads. (But on the other hand, if you do use monads, you benefit from the numerous combinators already in existence for monads, as well as from writing super-generic code).

When is it inappropriate to use monads?

if you have to warp your datatype or the monad laws in order to "make" a monad, you probably shouldn't do that, and should instead ask yourself why you're doing that
if your code doesn't benefit from using a monad, or if it actually gets worse (whether because it's longer, or harder to understand, or harder to test, or harder to maintain, ... etc.), you're probably using monads inappropriately

Best Answer

Related Solutions

Does groovy call partial application ‘currying’

JavaScript Monad – When Does a Monad Become a Hammer?

Related Topic