On Fri, Sep 14, 2012 at 10:08 PM, Joel Burget <joelburget@gmail.com> wrote:

[snip]

Also, Maybe and Either are not "implemented as monads". They are defined
using `data` like you suggest:

data Maybe a = Nothing | Just a
data Either a b = Left a | Right b

That's not my point, or my objection. My objection is to people who

present monads showing examples that begin with Maybe or Either, or

these 'trivial monads,' types onto which you can strip monadic

behavior fairly simply. I'm not saying they're bad as monads, or

useless, but I think the step from Maybe as a datatype to using it as

a monad is great enough that explaining monads by way of introducing

them with Maybe as an example is sort of confusing because it

trivializes what's actually going on.

I'm honestly not sure what you mean by Maybe or Either being

"implemented as monads," versus others. Monad is just a type class,

there's always an underlying type. Perhaps you mean that people

actually *care* about things in Maybe outside of it being used as a

monad, versus other things where you don't touch the underlying type.

This isn't intended to start an argument, however, and I'd prefer not

to argue over methodology, I just wanted to throw out there that if

you say "monads, think about maybe, and add some stuff, then that's it

is, what's all the fuss about!?" I think the hard part for people

understanding monads isn't the definition of monads, but rather that

you are forced to really tackle higher order behavior in a very direct

way. (For example, say you're new to Haskell, you probably don't know

about CPS, and you read about Cont in a monad tutorial. Is it the

monad that makes it hard? No, it's probably the concept of CPS.)

kris