From "A Fistful of Monads" chapter in "Learn you a Haskell" > When we first talked about functors, we saw that they were a useful concept for values that can b

From "A Fistful of Monads" chapter in "Learn you a Haskell" > When we first talked about functors, we saw that they were a useful concept for values that can be mapped over. Then, we took that concept one step further by introducing applicative functors, which allow us to view values of certain data types as values with contexts and use normal functions on those values while preserving the meaning of those contexts. > In this chapter, we'll learn about monads, which are just beefed up applicative functors, much like applicative functors are only beefed up functors > Monads are a natural extension of applicative functors and with them we're concerned with this: if you have a value with a context, m a, how do you apply to it a function that takes a normal a and returns a value with a context? That is, how do you apply a function of type a -> m b to a value of type m a? Some people might find this easy to understand, but I guess that many people won't. I don't think that it is because they are stupid, rather that most people are concrete thinkers rather than abstract thinkers. You would expect programmers to be more comfortable with abstraction than the general population, but even so, in my experience, the level of abstraction that mathematicians use is a level too far for most programmers. Why should a concept be generalized when you are just learning it? Would you complain that a elementary book on arithmetic fails to mention that the integers form a ring? And that addition is just a special case of a monoid? What advantage is there to this kind of premature generalization?