[Haskell-beginners] Re: Thinking about monads

[Michael Mossey]

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
> examples.
> 
> 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.

Thanks,
Mike