News for hackers. Stuff that matters.
Re:Swift Functors, Applicatives, and Monads in Pictures by wetmore on Wednesday July 15, 2015 @03:49AM (#9890209)
Nobody insists "monoid in the category of endofunctors" is universally preferable. It's a joke.

What you'll usually see people insist is to describe monads by their operations, rather than through metaphor. That is, a monad is a type parametrized by some other type, with the following two functions:

1) return :: a -> m a 2) (>>=) :: m a -> (a -> m b) -> m b

such that three laws hold:

a) return x >>= f == f x b) m >>= return == m c) (m >>= f) >>= g == m >>= (\x -> f x >>= g)

For monads in Haskell, this is the technically correct definition.

That said, most people will tell you the best way to understand monads is to look at a few basic monad instance implementations (Maybe, Either a) and program with them, slowly learning new instances.

Re:Swift Functors, Applicatives, and Monads in Pictures by dllthomas on Wednesday July 15, 2015 @12:17PM (#9892154)
Cleaning up the parent's formatting as I think it's too late for them to edit. Content is unchanged:

That is, a monad is a type parametrized by some other type, with the following two functions:

    1) return :: a -> m a
    2) (>>=) :: m a -> (a -> m b) -> m b
such that three laws hold:

    a) return x >>= f == f x
    b) m >>= return == m
    c) (m >>= f) >>= g == m >>= (\x -> f x >>= g)