> Monad is a simple ADT. A data structure with constructors and selectors Are you talking about the Free monad? Or the reification of the monadic operations as

> Monad is a simple ADT. A data structure with constructors and selectors Are you talking about the Free monad? Or the reification of the monadic operations as a dictionary? If so, that's a weird way to describe monads, and not very useful. Monads aren't ADTs in general. > You could write it in Scheme, nothing special Sure, though you might need to manually thread around the monad dictionary. > There is a special form in scheme called delay which basically wraps an expression inside a lambda (all you need is lambda). It's supposed to be a memoized lambda, and not just a lambda (i.e: Force it twice, and it'll only be computed once). > Because you want to hide implementation details of how you hook promises together, you must have constructors and selectors. > To force a promise we just call it as a function > This is what monads really are. Hooking promises/thunks together is only one instance of a Monad. Otherwise, Monads have very little to do with thunks or forcing of thunks. This is not what Monads really are. > The situation in which we really need delayed and encapsulated computations are quite rare, so all this monadic stuff must be thought as a special case, not as a general computation strategy. This may be an argument against lazy evaluation, but it isn't an argument against Monads. Monads are a pretty general computation strategy. > We need no monads or comonads to manipulate elements of a vector If we want to view the vector as a set of "possible results" and use a computation strategy that goes through/generates all possible results of all computations, then the list monad (in vector form) would be useful. If we want to work with vectors that are all of the same length, zipping them together, then the "ZipList" monad would be useful. We don't need monads because a generalization is never needed. Generalizations make code applicable in more situations, and may help separating concerns. > In Haskell, where they deliberately separate so-called pure functions from ones which have side-effects (performing I/O) by marking them with an additional type tag and grouping them in a distinct block of code, You don't really have to "group them in a distinct block of code". "do" notation is just optional sugar. Also, IO is just one instance of a Monad, and the usefulness of Monads goes far beyond IO. Having Monads even if you don't have any purity distinction in your language is still very useful.