Add meaningful instances to ZipList

[Alexander Dunlap]

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?

Alex

On 17 December 2011 10:37, Daniel Peebles <pumpkingod at gmail.com> 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 haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20111217/0e40a152/attachment.htm>