Library dilemma / Cofunctor class
conal at conal.net
Sat Jan 13 20:59:29 EST 2007
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,
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
> > import whatever standard module has the Cofunctor class, and maybe use
> > 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.
> Andrew Bromage
> Libraries mailing list
> Libraries at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries