Proposal: Add IsList instance for ZipList
foo = getZipList $ [f,g,h] <$> [a,b,c] <*> [d,e,i] looks a lot better than bar = getZipList $ ZipList [f,g,h] <$> ZipList [a,b,c] <*> ZipList [d,e,i]
Makes sense to me.
On Thu, Jun 11, 2015 at 4:02 AM, David Feuer
foo = getZipList $ [f,g,h] <$> [a,b,c] <*> [d,e,i]
looks a lot better than
bar = getZipList $ ZipList [f,g,h] <$> ZipList [a,b,c] <*> ZipList [d,e,i] _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
+1
2015-06-11 11:02 GMT+09:00 David Feuer
foo = getZipList $ [f,g,h] <$> [a,b,c] <*> [d,e,i]
looks a lot better than
bar = getZipList $ ZipList [f,g,h] <$> ZipList [a,b,c] <*> ZipList [d,e,i] _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
On Wed, 10 Jun 2015, David Feuer wrote:
foo = getZipList $ [f,g,h] <$> [a,b,c] <*> [d,e,i]
looks a lot better than
bar = getZipList $ ZipList [f,g,h] <$> ZipList [a,b,c] <*> ZipList [d,e,i]
But the second one is less surprising. For my taste it would have been better to give the ZipList semantics to the list type by default, because there are more data types that we can give a ZipList-like Applicative instance. The current non-determinism implementation for Applicative [] and Monad [] could have been used for a special non-determinism list type. But this instance was defined when there was no Applicative. :-(
I personally strongly believe in keeping the Applicative and Monad for a type compatible. Otherwise why the heck did we make Applicative a superclass of Monad? In this case the thing David wants only makes any difference if you explicitly turn on OverloadedLists, so if you never use that extension you'll never care about the instance anyways. -Edward On Thu, Jun 11, 2015 at 11:26 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Wed, 10 Jun 2015, David Feuer wrote:
foo = getZipList $ [f,g,h] <$> [a,b,c] <*> [d,e,i]
looks a lot better than
bar = getZipList $ ZipList [f,g,h] <$> ZipList [a,b,c] <*> ZipList [d,e,i]
But the second one is less surprising.
For my taste it would have been better to give the ZipList semantics to the list type by default, because there are more data types that we can give a ZipList-like Applicative instance. The current non-determinism implementation for Applicative [] and Monad [] could have been used for a special non-determinism list type. But this instance was defined when there was no Applicative. :-(
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
I agree with Edward and David, this instance looks like it would be a
useful addition.
On Thu, Jun 11, 2015, 2:22 PM Edward Kmett
I personally strongly believe in keeping the Applicative and Monad for a type compatible.
Otherwise why the heck did we make Applicative a superclass of Monad?
In this case the thing David wants only makes any difference if you explicitly turn on OverloadedLists, so if you never use that extension you'll never care about the instance anyways.
-Edward
On Thu, Jun 11, 2015 at 11:26 AM, Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Wed, 10 Jun 2015, David Feuer wrote:
foo = getZipList $ [f,g,h] <$> [a,b,c] <*> [d,e,i]
looks a lot better than
bar = getZipList $ ZipList [f,g,h] <$> ZipList [a,b,c] <*> ZipList [d,e,i]
But the second one is less surprising.
For my taste it would have been better to give the ZipList semantics to the list type by default, because there are more data types that we can give a ZipList-like Applicative instance. The current non-determinism implementation for Applicative [] and Monad [] could have been used for a special non-determinism list type. But this instance was defined when there was no Applicative. :-(
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
On Thu, 11 Jun 2015, Edward Kmett wrote:
I personally strongly believe in keeping the Applicative and Monad for a type compatible. Otherwise why the heck did we make Applicative a superclass of Monad?
I was extending the thought of treating a list like it would have ZipList semantics. I thought loudly about what I would have done if I could re-invent Haskell 98. If list would have an Applicative instance with ZipList semantics then it would not have a Monad instance, at all.
In this case the thing David wants only makes any difference if you explicitly turn on OverloadedLists, so if you never use that extension you'll never care about the instance anyways.
When I speak about surprises then I mean the situation where I read code of others, since I am not as much surprised about my own code. In this case someone else has enabled OverloadedLists.
I'd like to avoid situations where adding a LANGUAGE pragma changes the semantics of code Is this one? On 12.06.2015 03:49, Henning Thielemann wrote:
On Thu, 11 Jun 2015, Edward Kmett wrote:
I personally strongly believe in keeping the Applicative and Monad for a type compatible. Otherwise why the heck did we make Applicative a superclass of Monad?
I was extending the thought of treating a list like it would have ZipList semantics. I thought loudly about what I would have done if I could re-invent Haskell 98. If list would have an Applicative instance with ZipList semantics then it would not have a Monad instance, at all.
In this case the thing David wants only makes any difference if you explicitly turn on OverloadedLists, so if you never use that extension you'll never care about the instance anyways.
When I speak about surprises then I mean the situation where I read code of others, since I am not as much surprised about my own code. In this case someone else has enabled OverloadedLists. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/
Good. :) On 12.06.2015 10:27, Henning Thielemann wrote:
On Fri, 12 Jun 2015, Andreas Abel wrote:
I'd like to avoid situations where adding a LANGUAGE pragma changes the semantics of code Is this one?
No, it allows code that would be forbidden without the pragma.
-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/
Good. :) On 12.06.2015 10:27, Henning Thielemann wrote:
On Fri, 12 Jun 2015, Andreas Abel wrote:
I'd like to avoid situations where adding a LANGUAGE pragma changes the semantics of code Is this one?
No, it allows code that would be forbidden without the pragma.
-- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel@gu.se http://www2.tcs.ifi.lmu.de/~abel/
participants (6)
-
Andreas Abel -
David Feuer -
Edward Kmett -
Fumiaki Kinoshita -
Henning Thielemann -
Michael Snoyman