[Haskell-cafe] Tutorial: Haskell for the Evil Genius

[Kristopher Micinski]

On Fri, Sep 14, 2012 at 10:08 PM, Joel Burget <joelburget at 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