Nils Anders Danielsson
However, the "Control." hierarchy is certainly the wrong place for it. The very name Control is intended to suggest things that are slightly outside the usual functional domain - more in the region of imperative control structures.
In that case, why do we have Control.Applicative, Control.Arrow etc., which are purely functional? The only non-functional libraries are those that involve the IO or ST monads (Control.Concurrent, Control.Exception, Control.Monad.ST, etc.).
Well, since I was responsible for the original classification of Control.Monad into the Control hierarchy, I suppose it is all my fault. Monads are of course purely functional too. However, like concurrency and exceptions, at the time they had the "feel" of imperative programming, especially given the sugar of "do" notation. I certainly don't think of the monad concept as being a mere data structure, which is why it does not live in Data.Monad, but as something rather bigger in scope, involving sequence and so on. I'm not totally sure why Applicative has ended up in Control, but arrows are often thought of as "like Monads, only more general", so that would be why Control.Arrow is alongside Control.Monad. I'm not sure that there is a good word to describe all these such things that are more structured than mere data. Perhaps they should really live in a "Category." hierarchy, or "Idiom." (not to be confused with Conor's use of the term), or "Abstract." ? Regards, Malcolm