Add meaningful instances to ZipList

[wren ng thornton]

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