Whoops, the "data" was just a braino on my part, sorry!
On Mon, Dec 19, 2011 at 4:45 PM, 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
______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://www.haskell.org/mailman/listinfo/libraries