Re: Library dilemma / Cofunctor class

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

G'day all.

Quoting Conal Elliott :

...

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