Proposal: Adding on

[Malcolm Wallace]

Nils Anders Danielsson <nad at cs.chalmers.se> wrote:

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