My understanding of a monad is that it isn't currying or recursion though.

E:

I shouldn't even call it an understanding of monads. I've read at least 15+ explanations of what a monad is and still don't grok it.

Apologies in advance for the unsolicited monad tutorial (it's my turn to be that asshole)...

Firstly, saying "`X` is a monad" is the same as saying "class `X` implements the monad interface".

The monad interface is usually defined with `return` and `bind`, but I think it's more instructive to borrow the terminology from JavaScript's `Promise`...

* `Promise#resolve(value)` is the same as `return`, also known as `pure`. It just wraps the given value in a promise.

* `Promise#then(function)` combines both `bind` (when a new Promise is constructed and returned) and the functor method `map` (when a plain value is returned).

To provide a unified monad/functor interface for both `Promise` and `Array` (using `wrap` instead of `resolve):

    // `then` provides both `bind` and `map` depending on the return type of the given function:
    Promise.prototype.map = Promise.prototype.then 

    Promise.wrap = Promise.resolve

    // f maps elements to arrays of elements:
    Array.prototype.then = function (f) {
        return [].concat.apply ([], this.map(f))
    }

    Array.wrap = function (x) {
        return [x]
    }

There's no intrinsic value beyond that shared interface, it just allows you to write abstractions without knowing specifically what kind of monad you're dealing with (like the "do" syntax).

EDIT: BTW, I've purposely skipped a few things in this description, it's meant to be illustrative, not definitive...

Not quite ;) Semigroups are defined by their associative, binary operator of type a -> a -> a. Monoids are that plus an identity value of a.

There Haskell people go again =) You try to define something in simple normal terms, and off they go adding highly specific and technically correct words to what was supposed to be a simple explanation.

(I'm not a Haskell expert, I dabble, done CIS194, half of RWH, and I have no idea what you said -- which is a common problem I run into in the Haskell world, lots of super helpful people that have forgotten what its like to not speak their language)

I think using Haskell's type syntax is misleading in this context (and doesn't really imply the required associativity (much less commutativity if you wanted to consider Abelian monoids)).

The operation of a monoid maps from pairs of things to things. So in terms of types:

    <a,a> -> a

Or for some `twin` type constructor:

    twin a -> a

This is a bit more suggestive also in terms of F-algebras, where the operation has the following signature (f is a functor, or mappable container):

    f a -> a