Monad

hey /prog/, could someone explain the concept of a monad to a C programmer?

It is done.

>>2

IHBT

Think of CPS. Like that.

I'll explain using Haskell. If you're talking about category theory or something else, then sorry, I can't help you.

Basically, Monad is just a typeclass. That means that it has to implement a few functions:

(>>=) :: (Monad m) => m a -> (a -> m b) -> m b - takes a value out of a monad and passes it to a function, which returns a monad
(>>) :: (Monad m) => m a -> m b -> m b - evaluates the first argument, throws away the result, and evaluates and returns the second
return :: (Monad m) => a -> m a - puts a value in a monad
fail :: (Monad m) => String -> m a - returns from a monadic function

What's more important is how they are actually used. They can be used to represent functions with side effects (IO), functions that can fail (Maybe) or just a container for a value ([]). Monads aren't inherently impure - lists are monads, for example.

>>5
Sorry, forgot to mention - monads also have to satisfy a few properties. These aren't enforced by the type system, but if they're not true then it's not a valid monad.

return x >>= f == f x
x >>= return == x
x >>= (\y -> f y >>= g) == (x >>= f) >>= g

http://community.schemewiki.org/?monadic-programming
>Short version:
Pattern for using functions to transmit state without mutation.
>Longer version:
The basic principle is just that you can build up state by passing closures around, adding to the state contained in each closure by creating a new closure containing the extra state and invoking the original closure as necessary.
Monads just formalize that into a pattern with a specific set of operations. Part of the monad pattern is setting things up so you don't have to explicitly pass the state from function to function, it's handled behind the scenes.

>>7
These definitions aren't really right at all. Monads have nothing inherent to do with state. A more accurate definition would be: Monads provide a generalized interface to sequential computation.

>>8
Short version: sequencing computations, occasionally hiding state.

>>8,9
That's also wrong, because it treats monads as if they were alone and original, not a part of the larger sequence "functors-applicative functors-monads-arrows" plus a halo of other related notions.

So, longer version: there are constructed types like List<T>, Action<T>, Nullable<T> and so on. There are several interfaces that allow "lifting" a function operating on basic type(s) (like Func<T, R>) into a function operating on the constructed type (like Func<List<T>, List<R>>, this is Select for example).

Monad is one of such interfaces notable among normal people because it allows proper composition; and among Haskell programmers because it also, almost incidentally, enforces order of computation.

Let's say I'm using a programming language with Lispy semantics (dynamically typed, first-class closures, mutation discouraged but allowed, etc.). Why do I need monads?

>>11
Hello, ``in Lisp'' guy. When you're using lists, you're using a monad.

>>12
It's not him, he would have just called monads ``Jewish pseudo-science''.

>>12
I'm in no way associated with the ``In Lisp'' retard. What exactly do you mean by that?

>>11,14
My apologies.
``Lists'' form a monad, where return is (lambda (x) (list x)), and >>= is (lambda (x f) (append-map f x)).

Monads are more a concept than a thing, and the Haskell's Monad typeclass just encapsulates that concept. You never ``need'' them.