[Haskell-beginners] Re: Thinking about monads
mpm at alumni.caltech.edu
Mon Apr 13 18:11:42 EDT 2009
Ertugrul Soeylemez wrote:
> Hello Michael,
> you're basically trying to give monads a better name. Don't forget that
> they are an abstract structure, which means that trying to find
> intuitions or motivations is the same as trying to find real world
> Monads are not a way to pass the result of some function to another
> function. We've got function composition for that. Short-circuiting is
> a feature of particular monads like Maybe, and as you said, you could
> well do without them. In Haskell, monads are an abstract combinator
> class, which brings you mainly two advantages: Generalization of
> functionality and impure operations encapsulated in pure objects.
I think I'm starting to get this. Conventional programming languages rarely, if ever,
deal with abstractions like the functor or monad. In C++ you would need templates to
represent them, and templates are a lot of trouble. OO classes are the main form of
abstraction I deal with.
> Those objects are the monadic values, which can be interpreted in a
> number of ways. I like to interpret them as computations, and this is
> probably the most common interpretation. Have a look at this:
> x :: Maybe Integer
> x = Just 3
I know Maybe is both a functor and a monad, and I was thinking: what's the
difference? They are both wrappers on types. Then I realized, the difference is: they
have different class definitions.
class Functor f where
fmap :: (a->b) -> f a -> f b
(Note how fussy this definition would be in C++. It would be a kind of template, but
would probably look a lot more complex and would require lengthy declarations.)
class Monad m where
a >>= b :: m a -> (a -> m b) -> m b
Like functor, there are types m/f, a, and b, but they have a different organization.
What about my point that the definition of the >>= operator makes it useful to
preserve access to the argument variables of earlier functions in the chain, as follows?
nodin = jacy >>= \finnibar ->
keary >>= \cody ->
return (finnibar, cody)
I suppose this is a property of structuring the code this way, and this is not the
only way to structure it.
So I think what you are saying is that the esseence of the abstraction is in the
definition. I think I need more experience to really understand why computer
scientists were motivated to make that definition. After many years of OO
programming, I immediately analyze a problem in terms of classes and objects... while
monads and functors have barely entered my vocabulary.
I took a look at your tutorial, and I'll go through it in more depth.
More information about the Beginners