Add meaningful instances to ZipList

Alexander Dunlap alexander.dunlap at
Sun Dec 18 08:29:57 CET 2011

No objections here, but might it be worth a mention in the docs that the
simple case of

pure x == pure x

will not terminate?


On 17 December 2011 10:37, Daniel Peebles <pumpkingod at> wrote:

> I noticed that the ZipList newtype in Control.Applicative has no derived
> instances at all. We can't show a ZipList, check it for equality, or do
> anything to it except unpack it or treat it like an Applicative or Functor.
> It seems fairly uncontroversial to suggest adding some instances for it,
> but there are some minor questions to address: the obvious instances to add
> might be Eq, Ord, Show, Read, and possibly Typeable and/or Data. Are there
> any others I've missed? For the Read/Show instances, do we want manual ones
> that don't use the verbose record-style output? Since it's just defined as
> data ZipList a = ZipList { getZipList :: [a] } to get an easy accessor
> (does anyone actually use getZipList as a field for record updates?), it
> might be easier to write the projection manually and change the definition
> to data ZipList a = ZipList [a] with a separate getZipList function, so the
> deriving mechanism can give us a less noisy Show instance.
> Discussion period: 2 weeks, I guess
> - Dan
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list