Deprecate Foldable for Either

Edward Kmett ekmett at
Sat Mar 4 05:10:41 UTC 2017

100% this. Cofree Maybe is a a nicely general encoding of a non-empty list
that shows how closely related it is to a rose tree Cofree []. It'd lose
its ability to be folded if Maybe ceased to be Foldable.

When I'm showing how the cofree comonad works, I often take time to work up
those examples along with Cofree ((->) e) as an (infinite) Moore machine.
About 3-4 examples in, it usually clicks.

instances on Either e, and Maybe, Identity, (,) e, etc. are all building
blocks that are commonly used for larger things like this.

As you enumerate all the simple functors we have lying around in Haskell,
looking at what they do when you compute `Cofree f` or `Free f` tends to be
quite informative.

This teaching approach breaks down completely once you start cutting
arbitrary holes in instance coverage and making everyone remember where
those holes are.


On Fri, Mar 3, 2017 at 5:04 PM, David Menendez <dave at> wrote:

> On Thu, Mar 2, 2017 at 1:12 PM, Kris Nuttycombe <kris.nuttycombe at
> > wrote:
>> As with all of these discussions, the point of having Either be Foldable
>> is not that you're going to call foldMap on an Either value directly.
>> Instead, it is that you be able to pass whatever sort of foldable thing you
>> choose (which Either certainly is) to a function that only requires
>> foldability of its input. By removing or damaging the Foldable instance for
>> Either, you don't simply prevent people from encountering problems that
>> will be resolved the first time they test their software - you make a whole
>> universe of nicely polymorphic functions unavailable for them to use
>> without additional effort.
> Not just polymorphic functions. Many higher-order type constructors have
> Foldable instances based on their parameters. For example,
> data Cofree f a = a :< f (Cofree f a)
> instance Foldable f => Foldable (Cofree f a) where
> foldMap f (a :< as) = f a <> foldMap (foldMap f) as
> Without the instance for Either b, we lose the instances for Cofree
> (Either b) and Cofree (Compose [] (Either b)), both of which seem
> reasonable and useful.
> In particular, the idea that one should make all such functions partial by
>> throwing an error is repugnant.
> Yes, that seems like the worst possible solution. Better would be some way
> to give a warning when calling an overloaded function at a particular type.
> --
> Dave Menendez <dave at>
> <>
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list