Add meaningful instances to ZipList

[Daniel Peebles]

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 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...
>
> 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 haskell.org
> http://www.haskell.org/**mailman/listinfo/libraries<http://www.haskell.org/mailman/listinfo/libraries>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20111219/691c5036/attachment.htm>