Add meaningful instances to ZipList

[Edward Kmett]

On Dec 19, 2011, at 4:45 PM, wren ng thornton <wren at freegeek.org> 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...

I just gave in and became good at writing manual instances for these for just that reason.

> 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.

It should be a newtype, there are no semantic issues.

> 
> -- 
> Live well,
> ~wren
> 
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries