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