Add meaningful instances to ZipList

Daniel Peebles pumpkingod at
Mon Dec 19 23:22:07 CET 2011

Whoops, the "data" was just a braino on my part, sorry!

On Mon, Dec 19, 2011 at 4:45 PM, wren ng thornton <wren at> wrote:

> On 12/17/11 1:37 PM, Daniel Peebles wrote:
>> 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.
> To deal with the ugliness of derived Show for single-field record
> types/newtypes I've taken to just moving the projection function outside of
> the type definition. Though, if the data constructor is exported (which it
> hasn't been in my cases) the Haddock will suffer for the change. It's not
> that hard to just write a manual instance though...
> While we're on the topic, is there any reason why ZipList is a data type
> instead of a newtype? Is the extra bottom actually necessary for the
> Applicative semantics? If not, then I'd suggest changing it to a newtype in
> order to remove the extra indirection.
> --
> Live well,
> ~wren
> ______________________________**_________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list