I noticed that the ZipList newtype in Control.Applicative has no derived instances at all. We can't show a ZipList, check it for equality, or do anything to it except unpack it or treat it like an Applicative or Functor. It seems fairly uncontroversial to suggest adding some instances for it, but there are some minor questions to address: the obvious instances to add might be Eq, Ord, Show, Read, and possibly Typeable and/or Data. Are there any others I've missed? 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. Discussion period: 2 weeks, I guess - Dan
+1
On Sat, Dec 17, 2011 at 1:37 PM, Daniel Peebles
I noticed that the ZipList newtype in Control.Applicative has no derived instances at all. We can't show a ZipList, check it for equality, or do anything to it except unpack it or treat it like an Applicative or Functor.
It seems fairly uncontroversial to suggest adding some instances for it, but there are some minor questions to address: the obvious instances to add might be Eq, Ord, Show, Read, and possibly Typeable and/or Data. Are there any others I've missed? 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.
Discussion period: 2 weeks, I guess
- Dan
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
No objections here, but might it be worth a mention in the docs that the
simple case of
pure x == pure x
will not terminate?
Alex
On 17 December 2011 10:37, Daniel Peebles
I noticed that the ZipList newtype in Control.Applicative has no derived instances at all. We can't show a ZipList, check it for equality, or do anything to it except unpack it or treat it like an Applicative or Functor.
It seems fairly uncontroversial to suggest adding some instances for it, but there are some minor questions to address: the obvious instances to add might be Eq, Ord, Show, Read, and possibly Typeable and/or Data. Are there any others I've missed? 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.
Discussion period: 2 weeks, I guess
- Dan
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
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
* wren ng thornton
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 is actually a newtype, and has been at least since base-3.0.3.1 (the oldest 'base' available on hackage). -- Roman I. Cheplyaka :: http://ro-che.info/
On 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...
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@haskell.org http://www.haskell.org/mailman/listinfo/libraries
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
On 12/17/11 1:37 PM, Daniel Peebles wrote:
I noticed that the ZipList newtype in Control.Applicative has no derived instances at all. We can't show a ZipList, check it for equality, or do anything to it except unpack it or treat it like an Applicative or Functor.
It seems fairly uncontroversial to suggest adding some instances for it, but there are some minor questions to address: the obvious instances to add might be Eq, Ord, Show, Read, and possibly Typeable and/or Data.
+1 btw. -- Live well, ~wren
On Sat, Dec 17, 2011 at 01:37:35PM -0500, Daniel Peebles wrote:
I noticed that the ZipList newtype in Control.Applicative has no derived instances at all. We can't show a ZipList, check it for equality, or do anything to it except unpack it or treat it like an Applicative or Functor.
It seems fairly uncontroversial to suggest adding some instances for it, but there are some minor questions to address: the obvious instances to add might be Eq, Ord, Show, Read, and possibly Typeable and/or Data. Are there any others I've missed? 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.
+1 -Brent
I've created a ticket for this at
http://hackage.haskell.org/trac/ghc/ticket/5787. I've been having some
issues with my local install but should put a patch up very soon.
Dan
On Mon, Dec 19, 2011 at 5:32 PM, Brent Yorgey
I noticed that the ZipList newtype in Control.Applicative has no derived instances at all. We can't show a ZipList, check it for equality, or do anything to it except unpack it or treat it like an Applicative or Functor.
It seems fairly uncontroversial to suggest adding some instances for it, but there are some minor questions to address: the obvious instances to add might be Eq, Ord, Show, Read, and possibly Typeable and/or Data. Are
any others I've missed? 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
On Sat, Dec 17, 2011 at 01:37:35PM -0500, Daniel Peebles wrote: there the
deriving mechanism can give us a less noisy Show instance.
+1
-Brent
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (6)
-
Alexander Dunlap -
Brent Yorgey -
Daniel Peebles -
Edward Kmett -
Roman Cheplyaka -
wren ng thornton