On Fri, Sep 14, 2012 at 10:08 PM, Joel Burget <joelbur...@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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
