Library dilemma / Cofunctor class

Conal Elliott conal at
Sat Jan 13 20:59:29 EST 2007

Thanks, Andrew.

I'd enjoy hearing more input on the location.  I'm inclining to
Data.Cofunctor rather than Control.Cofunctor.  I doubt there's really a
clearly appropriate place for this or most type classes to go.  A beauty of
type classes is that they generalize over uses.  For instance, considering
[] and IO (for starters) I don't know where I'd put Functor.

So I offer rather bold statement that taxonomy (including namespace
hierarchy) and type classes are in conflict with each other,

About Cofunctor, my library includes a notion of "composable interfaces".
These interfaces are consumers of values rather than producers of them,
hence Cofunctor.

Cheers,  - Conal

On 1/13/07, ajb at <ajb at> wrote:
> G'day all.
> Quoting Conal Elliott <conal at>:
> > I'm working on a library that includes a Cofunctor instance.  I'd love
> to
> > import whatever standard module has the Cofunctor class, and maybe use
> some
> > Cofunctor combinators.  But, alas, I haven't found such a thing, and I'm
> > wondering what to do.
> I'd say that the "right" thing to do is first, claim a space in the
> module namespace (presumably Control.Cofunctor) and then, release the
> world's second-smallest Cabalised library (after hnop).
> I am mildly curious as to how you managed to come up with a use for
> covariant functors, though.
> Cheers,
> Andrew Bromage
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Libraries mailing list