Library dilemma / Cofunctor class

[Conal Elliott]

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 spamcop.net <ajb at spamcop.net> wrote:
>
> G'day all.
>
> Quoting Conal Elliott <conal at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20070113/f3941543/attachment.htm