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@spamcop.net <ajb@spamcop.net> wrote:
G'day all.

Quoting Conal Elliott <conal@conal.net >:

> 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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries