From fa-ml at ariis.it Sat Apr 1 00:08:17 2017 From: fa-ml at ariis.it (Francesco Ariis) Date: Sat, 1 Apr 2017 02:08:17 +0200 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> Message-ID: <20170401000817.GA11348@casa.casa> On Sat, Apr 01, 2017 at 07:59:00AM +1000, Tony Morris wrote: > A contrary, consistent position would mean there is a belief in all of > the following: > > * the length of any value of the type ((,) a) is not 1 > * 0 is not an integer You keep repeating the same message, I wonder if you read the reply that have been sent to you. From the other thread (in which, after a brief threat to fork the compiler, you asked for explanations), Artyom Kazak kindly answered: > Okay, I have to admit that in this particular instance it's not quite my > intuition which causes the pain. Or rather, it's a different kind of > intuition, which I have acquired from Haskell in particular – "I don't have > to be particularly careful about minor refactorings, because if I change > the type of one thing, the compiler will tell me what other things I have > to change if I want to preserve the logic of my code". The behavior of > 'length' breaks this intuition because "I'll just pass a tuple here instead > of whatever I used before" stops being a (relatively) safe refactoring. No mention of it being "categorically invalid". Moreover, the message you are replying to now (by Svan Penne) is clearly illustrates the dichotomy between *type safety* and *consistency*. Surely everyone (despite their ideas and preferred outcome) can see the two competing interests? From tonymorris at gmail.com Sat Apr 1 01:27:15 2017 From: tonymorris at gmail.com (Tony Morris) Date: Sat, 1 Apr 2017 11:27:15 +1000 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <20170401000817.GA11348@casa.casa> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> Message-ID: I did read it. I chose not to respond. I do not believe it to be a constructive avenue. I am repeating myself far less than the misunderstanding and inconsistency around "tuples." To this end, I believe is worthwhile to continue pointing out the inconsistency, and only slightly less so than those who hold a contrary inconsistent position, who are inadvertently pointing out the inconsistency. 0 is not an integer is a statement of equal validity, buit more obviously not so. If I see "length of tuples", and related misunderstandings and subsequent misrepresentations some number of times, I will respond proportionally. I expect I will see it again in the very near future. I will point to that mistake on the occasion. I hope that is OK. The length of ((,) a) is exactly one. Anything else is ridiculous. Try arguing against that, instead of a position that does not exist ("length of tuples"). I wrote this instance some number of years ago (about 11), and have used it on teams all over the place. Not once was there an issue that was not quickly corrected, and thereby achieving the practical benefits that come with, by providing a better understanding. That understanding is above. The length of ((,) a) is exactly one. Say it with me. On 01/04/17 10:08, Francesco Ariis wrote: > On Sat, Apr 01, 2017 at 07:59:00AM +1000, Tony Morris wrote: >> A contrary, consistent position would mean there is a belief in all of >> the following: >> >> * the length of any value of the type ((,) a) is not 1 >> * 0 is not an integer > You keep repeating the same message, I wonder if you read the reply that > have been sent to you. From the other thread (in which, after a brief > threat to fork the compiler, you asked for explanations), Artyom > Kazak kindly answered: > >> Okay, I have to admit that in this particular instance it's not quite my >> intuition which causes the pain. Or rather, it's a different kind of >> intuition, which I have acquired from Haskell in particular – "I don't have >> to be particularly careful about minor refactorings, because if I change >> the type of one thing, the compiler will tell me what other things I have >> to change if I want to preserve the logic of my code". The behavior of >> 'length' breaks this intuition because "I'll just pass a tuple here instead >> of whatever I used before" stops being a (relatively) safe refactoring. > No mention of it being "categorically invalid". > > Moreover, the message you are replying to now (by Svan Penne) is clearly > illustrates the dichotomy between *type safety* and *consistency*. > Surely everyone (despite their ideas and preferred outcome) can see the > two competing interests? > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From abela at chalmers.se Sat Apr 1 07:24:11 2017 From: abela at chalmers.se (Andreas Abel) Date: Sat, 1 Apr 2017 09:24:11 +0200 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> Message-ID: <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> > The length of ((,) a) is exactly one. Anything else is ridiculous. Now we are even talking of the length of a function. Can it get more absurd?! It is perfectly to limit the concept of "length" to * linear structures (lists, arrays, etc.) [branching structures do not have a length, they may have a size or maximum depth] * which have variable length [why would you otherwise ask for the length?] Thus, the following answers of ghci are highly questionable, (and for the non-washed brain, simply non-sensical). Prelude> length (Left 100) 0 Prelude> length (Right 200) 1 Just make a field experiment. Go to the mathematics department and ask people what is the length of (1, 1), the length of (1, 1, 1). An then count the number of people that respond "1" to both of these questions. And weight it against the people that say something else. On 01.04.2017 03:27, Tony Morris wrote: > I did read it. I chose not to respond. I do not believe it to be a > constructive avenue. > > I am repeating myself far less than the misunderstanding and > inconsistency around "tuples." To this end, I believe is worthwhile to > continue pointing out the inconsistency, and only slightly less so than > those who hold a contrary inconsistent position, who are inadvertently > pointing out the inconsistency. 0 is not an integer is a statement of > equal validity, buit more obviously not so. > > If I see "length of tuples", and related misunderstandings and > subsequent misrepresentations some number of times, I will respond > proportionally. I expect I will see it again in the very near future. I > will point to that mistake on the occasion. I hope that is OK. > > The length of ((,) a) is exactly one. Anything else is ridiculous. Try > arguing against that, instead of a position that does not exist ("length > of tuples"). I wrote this instance some number of years ago (about 11), > and have used it on teams all over the place. Not once was there an > issue that was not quickly corrected, and thereby achieving the > practical benefits that come with, by providing a better understanding. > That understanding is above. The length of ((,) a) is exactly one. Say > it with me. > > > On 01/04/17 10:08, Francesco Ariis wrote: >> On Sat, Apr 01, 2017 at 07:59:00AM +1000, Tony Morris wrote: >>> A contrary, consistent position would mean there is a belief in all of >>> the following: >>> >>> * the length of any value of the type ((,) a) is not 1 >>> * 0 is not an integer >> You keep repeating the same message, I wonder if you read the reply that >> have been sent to you. From the other thread (in which, after a brief >> threat to fork the compiler, you asked for explanations), Artyom >> Kazak kindly answered: >> >>> Okay, I have to admit that in this particular instance it's not quite my >>> intuition which causes the pain. Or rather, it's a different kind of >>> intuition, which I have acquired from Haskell in particular – "I don't have >>> to be particularly careful about minor refactorings, because if I change >>> the type of one thing, the compiler will tell me what other things I have >>> to change if I want to preserve the logic of my code". The behavior of >>> 'length' breaks this intuition because "I'll just pass a tuple here instead >>> of whatever I used before" stops being a (relatively) safe refactoring. >> No mention of it being "categorically invalid". >> >> Moreover, the message you are replying to now (by Svan Penne) is clearly >> illustrates the dichotomy between *type safety* and *consistency*. >> Surely everyone (despite their ideas and preferred outcome) can see the >> two competing interests? >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > _______________________________________________ > Libraries mailing list > Libraries at 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 at gu.se http://www.cse.chalmers.se/~abela/ From tonymorris at gmail.com Sat Apr 1 07:56:40 2017 From: tonymorris at gmail.com (Tony Morris) Date: Sat, 1 Apr 2017 17:56:40 +1000 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> Message-ID: <683e6a1d-aac4-f8a2-6761-523ab35febea@gmail.com> On 01/04/17 17:24, Andreas Abel wrote: > > The length of ((,) a) is exactly one. Anything else is ridiculous. > > Now we are even talking of the length of a function. Can it get more > absurd?! No. It is perfectly reasonable. Go and "ask the mathematics department" or whatever criteria it will take for (the collective) you to understand that. > Just make a field experiment. Go to the mathematics department and > ask people what is the length of (1, 1), the length of (1, 1, 1). An > then count the number of people that respond "1" to both of these > questions. And weight it against the people that say something else. We already agree on the result. Thanks again for pointing out, that I am pointing to the mistake that is repeatedly made. I will just keep pointing to it. Just keep that mistake out of my code, thanks. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From Henrik.Nilsson at nottingham.ac.uk Sat Apr 1 08:42:24 2017 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Sat, 01 Apr 2017 09:42:24 +0100 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> Message-ID: <58DF67F0.9070509@exmail.nottingham.ac.uk> Hi all, > It is perfectly to limit the concept of "length" to > > * linear structures (lists, arrays, etc.) > [branching structures do not have a length, they may have a size or > maximum depth] > > * which have variable length > [why would you otherwise ask for the length?] Just for the record, I could not agree more. Looking up "length", e.g. Merriam-Webster: 1a : the longer or longest dimension of an object What we really are talking about here is counting the number of elements in a data structure. That is clearly applicable to lists as well as trees and tuples interpreted in particular ways. But calling it "length" is not particularly helpful. Nor the effort to reappropriate the very concept of "length" through a categorical interpretation. It would have been a lot better if a name suggesting a sense of counting, or at least a name suggesting that this is something different than the usual length, would have been picked. Maybe elementcount or ever flength. Names matter. /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From ivan.miljenovic at gmail.com Sat Apr 1 10:32:53 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Sat, 1 Apr 2017 21:32:53 +1100 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <58DF67F0.9070509@exmail.nottingham.ac.uk> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> Message-ID: On 1 April 2017 at 19:42, Henrik Nilsson wrote: > Hi all, > >> It is perfectly to limit the concept of "length" to >> >> * linear structures (lists, arrays, etc.) >> [branching structures do not have a length, they may have a size or >> maximum depth] >> >> * which have variable length >> [why would you otherwise ask for the length?] > > Just for the record, I could not agree more. > > Looking up "length", e.g. Merriam-Webster: > > 1a : the longer or longest dimension of an object > > What we really are talking about here is counting the number of > elements in a data structure. That is clearly applicable to lists > as well as trees and tuples interpreted in particular ways. > > But calling it "length" is not particularly helpful. Nor the effort to > reappropriate the very concept of "length" through a categorical > interpretation. > > It would have been a lot better if a name suggesting a sense of > counting, or at least a name suggesting that this is something different > than the usual length, would have been picked. Maybe elementcount > or ever flength. I agree, but on the other hand this should have been done _before_ FTP; at this stage, I lean towards marking this down as one of the known warts of Haskell - possibly with a 3 major version GHC cycle to migrate to a better name once the bikeshedding has been completed - and moving on rather than being revisionist and using this as an excuse to go backwards. So far, the arguments against these instances that I've seen are: * The name of the length function is misleading for such instances (with all respect to Tony, agreed; but see above); I don't think I've seen anyone else complain about any of the other function names though. * Since these classes/instances are now exported from the Prelude, previous code that wouldn't have have type-checked are now valid and thus produce unexpected results (I was against the Prelude export when FTP was being debated, but now - with the possible exception of people learning to program - I think this is a matter of needing to be more aware of the types and using our wonderful REPL environments to test functions rather than blindly just writing code without validating the code logic). TL;DR: I didn't 100% agree with the way FTP was done precisely due to the problems people have with these instances, but now let's not go backwards (and the tuple instances I've found very useful). > > Names matter. > > /Henrik > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete it. > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From abela at chalmers.se Sat Apr 1 11:00:48 2017 From: abela at chalmers.se (Andreas Abel) Date: Sat, 1 Apr 2017 13:00:48 +0200 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> Message-ID: <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> In the end, I should be grateful for the FTP. It will provide amusement for years. Q: What is the length of pi? A: Dunno, infinity? Q: And what is the length of just pi? GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> length (Just pi) 1 ROFL. On 01.04.2017 12:32, Ivan Lazar Miljenovic wrote: > On 1 April 2017 at 19:42, Henrik Nilsson > wrote: >> Hi all, >> >>> It is perfectly to limit the concept of "length" to >>> >>> * linear structures (lists, arrays, etc.) >>> [branching structures do not have a length, they may have a size or >>> maximum depth] >>> >>> * which have variable length >>> [why would you otherwise ask for the length?] >> >> Just for the record, I could not agree more. >> >> Looking up "length", e.g. Merriam-Webster: >> >> 1a : the longer or longest dimension of an object >> >> What we really are talking about here is counting the number of >> elements in a data structure. That is clearly applicable to lists >> as well as trees and tuples interpreted in particular ways. >> >> But calling it "length" is not particularly helpful. Nor the effort to >> reappropriate the very concept of "length" through a categorical >> interpretation. >> >> It would have been a lot better if a name suggesting a sense of >> counting, or at least a name suggesting that this is something different >> than the usual length, would have been picked. Maybe elementcount >> or ever flength. > > I agree, but on the other hand this should have been done _before_ > FTP; at this stage, I lean towards marking this down as one of the > known warts of Haskell - possibly with a 3 major version GHC cycle to > migrate to a better name once the bikeshedding has been completed - > and moving on rather than being revisionist and using this as an > excuse to go backwards. > > So far, the arguments against these instances that I've seen are: > > * The name of the length function is misleading for such instances > (with all respect to Tony, agreed; but see above); I don't think I've > seen anyone else complain about any of the other function names > though. > > * Since these classes/instances are now exported from the Prelude, > previous code that wouldn't have have type-checked are now valid and > thus produce unexpected results (I was against the Prelude export when > FTP was being debated, but now - with the possible exception of people > learning to program - I think this is a matter of needing to be more > aware of the types and using our wonderful REPL environments to test > functions rather than blindly just writing code without validating the > code logic). > > TL;DR: I didn't 100% agree with the way FTP was done precisely due to > the problems people have with these instances, but now let's not go > backwards (and the tuple instances I've found very useful). > >> >> Names matter. >> >> /Henrik >> >> >> >> >> This message and any attachment are intended solely for the addressee >> and may contain confidential information. If you have received this >> message in error, please send it back to me, and immediately delete it. >> Please do not use, copy or disclose the information contained in this >> message or in any attachment. Any views or opinions expressed by the >> author of this email do not necessarily reflect the views of the >> University of Nottingham. >> >> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage your >> computer system, you are advised to perform your own checks. Email >> communications with the University of Nottingham may be monitored as >> permitted by UK legislation. >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at 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 at gu.se http://www.cse.chalmers.se/~abela/ From abela at chalmers.se Sat Apr 1 11:08:59 2017 From: abela at chalmers.se (Andreas Abel) Date: Sat, 1 Apr 2017 13:08:59 +0200 Subject: GHCI says we all drink left-handed Message-ID: GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> data Handed = Handed Prelude> let drink beer = beer Prelude> all drink (Left Handed) True -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www.cse.chalmers.se/~abela/ From dominic at steinitz.org Sat Apr 1 11:18:29 2017 From: dominic at steinitz.org (dominic at steinitz.org) Date: Sat, 1 Apr 2017 12:18:29 +0100 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: Message-ID: <3A121F97-878C-42D0-BE3B-84F5D5D93BE2@steinitz.org> Since "God made the integers…” perhaps the question of whether 0 is an integer is best left to theologians. On the other hand, in set theory a tuple is defined as a set containing two elements and in category theory, a product is a limit of a discrete category with two objects. Of course you can treat a tuple as a decorated container containing one element but I doubt many mathematicians think of them this way. Before anyone points out that I shouldn’t think of types as sets, the same applies to \omega-complete partial orders. Perhaps I had better be explicit and say please no aka -1. > The length of ((,) a) is exactly one. Anything else is ridiculous. Try > arguing against that, instead of a position that does not exist ("length > of tuples"). I wrote this instance some number of years ago (about 11), > and have used it on teams all over the place. Not once was there an > issue that was not quickly corrected, and thereby achieving the > practical benefits that come with, by providing a better understanding. > That understanding is above. The length of ((,) a) is exactly one. Say > it with me. > > > On 01/04/17 10:08, Francesco Ariis wrote: >> On Sat, Apr 01, 2017 at 07:59:00AM +1000, Tony Morris wrote: >>> A contrary, consistent position would mean there is a belief in all of >>> the following: >>> >>> * the length of any value of the type ((,) a) is not 1 >>> * 0 is not an integer Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com From evincarofautumn at gmail.com Sat Apr 1 11:30:54 2017 From: evincarofautumn at gmail.com (Jon Purdy) Date: Sat, 1 Apr 2017 04:30:54 -0700 Subject: GHCI says we all drink left-handed In-Reply-To: References: Message-ID: If we assume that you drink beer: let drink beer = True Then we can conclude that it doesn’t matter which hand you drink with: all drink (Left Handed) == all drink (Right Handed) == True On Sat, Apr 1, 2017 at 4:08 AM, Andreas Abel wrote: > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > Prelude> data Handed = Handed > Prelude> let drink beer = beer > Prelude> all drink (Left Handed) > True > > -- > Andreas Abel <>< Du bist der geliebte Mensch. > > Department of Computer Science and Engineering > Chalmers and Gothenburg University, Sweden > > andreas.abel at gu.se > http://www.cse.chalmers.se/~abela/ > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evincarofautumn at gmail.com Sat Apr 1 11:36:09 2017 From: evincarofautumn at gmail.com (Jon Purdy) Date: Sat, 1 Apr 2017 04:36:09 -0700 Subject: GHCI says we all drink left-handed In-Reply-To: References: Message-ID: If we assume that you drink beer: let drink beer = True Then we can conclude that it doesn’t matter which hand you drink with: all drink (Left Handed) == all drink (Right Handed) == True On Sat, Apr 1, 2017 at 4:08 AM, Andreas Abel wrote: > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > Prelude> data Handed = Handed > Prelude> let drink beer = beer > Prelude> all drink (Left Handed) > True > > -- > Andreas Abel <>< Du bist der geliebte Mensch. > > Department of Computer Science and Engineering > Chalmers and Gothenburg University, Sweden > > andreas.abel at gu.se > http://www.cse.chalmers.se/~abela/ > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub.daniel at gmail.com Sat Apr 1 11:53:11 2017 From: jakub.daniel at gmail.com (Jakub Daniel) Date: Sat, 1 Apr 2017 13:53:11 +0200 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> Message-ID: > On 1 Apr 2017, at 13:00, Andreas Abel wrote: > > In the end, I should be grateful for the FTP. It will provide amusement for years. > > Q: What is the length of pi? > A: Dunno, infinity? > Q: And what is the length of just pi? > > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > Prelude> length (Just pi) > 1 > > ROFL. > >> On 01.04.2017 12:32, Ivan Lazar Miljenovic wrote: >> On 1 April 2017 at 19:42, Henrik Nilsson >> wrote: >>> Hi all, >>> >>>> It is perfectly to limit the concept of "length" to >>>> >>>> * linear structures (lists, arrays, etc.) >>>> [branching structures do not have a length, they may have a size or >>>> maximum depth] >>>> >>>> * which have variable length >>>> [why would you otherwise ask for the length?] >>> >>> Just for the record, I could not agree more. >>> >>> Looking up "length", e.g. Merriam-Webster: >>> >>> 1a : the longer or longest dimension of an object >>> >>> What we really are talking about here is counting the number of >>> elements in a data structure. That is clearly applicable to lists >>> as well as trees and tuples interpreted in particular ways. >>> >>> But calling it "length" is not particularly helpful. Nor the effort to >>> reappropriate the very concept of "length" through a categorical >>> interpretation. >>> >>> It would have been a lot better if a name suggesting a sense of >>> counting, or at least a name suggesting that this is something different >>> than the usual length, would have been picked. Maybe elementcount >>> or ever flength. >> >> I agree, but on the other hand this should have been done _before_ >> FTP; at this stage, I lean towards marking this down as one of the >> known warts of Haskell - possibly with a 3 major version GHC cycle to >> migrate to a better name once the bikeshedding has been completed - >> and moving on rather than being revisionist and using this as an >> excuse to go backwards. >> >> So far, the arguments against these instances that I've seen are: >> >> * The name of the length function is misleading for such instances >> (with all respect to Tony, agreed; but see above); I don't think I've >> seen anyone else complain about any of the other function names >> though. >> >> * Since these classes/instances are now exported from the Prelude, >> previous code that wouldn't have have type-checked are now valid and >> thus produce unexpected results (I was against the Prelude export when >> FTP was being debated, but now - with the possible exception of people >> learning to program - I think this is a matter of needing to be more >> aware of the types and using our wonderful REPL environments to test >> functions rather than blindly just writing code without validating the >> code logic). >> >> TL;DR: I didn't 100% agree with the way FTP was done precisely due to >> the problems people have with these instances, but now let's not go >> backwards (and the tuple instances I've found very useful). >> >>> >>> Names matter. >>> >>> /Henrik >>> >>> >>> >>> >>> This message and any attachment are intended solely for the addressee >>> and may contain confidential information. If you have received this >>> message in error, please send it back to me, and immediately delete it. >>> Please do not use, copy or disclose the information contained in this >>> message or in any attachment. Any views or opinions expressed by the >>> author of this email do not necessarily reflect the views of the >>> University of Nottingham. >>> >>> This message has been checked for viruses but the contents of an >>> attachment may still contain software viruses which could damage your >>> computer system, you are advised to perform your own checks. Email >>> communications with the University of Nottingham may be monitored as >>> permitted by UK legislation. >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at 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 at gu.se > http://www.cse.chalmers.se/~abela/ > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From jakub.daniel at gmail.com Sat Apr 1 12:00:12 2017 From: jakub.daniel at gmail.com (Jakub Daniel) Date: Sat, 1 Apr 2017 14:00:12 +0200 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> Message-ID: > Q: What is the length of pi? > A: Dunno, infinity? > Q: And what is the length of just pi? > > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > Prelude> length (Just pi) > 1 > > ROFL. That is like being surprised about length [1..] and length [[1..]] though. And I imagine nobody would argue that doesn't make sense. I kind of see why people want better name than length but I see no really good argument why the instance is bad. There are no doubt other generalised notions. It also was an unfair question to ask what mathematicians would think the length of (1,1) was. Because the question is not asked in context where we ask about length for the type (a,-) not (-,-). Jakub > >> On 01.04.2017 12:32, Ivan Lazar Miljenovic wrote: >> On 1 April 2017 at 19:42, Henrik Nilsson >> wrote: >>> Hi all, >>> >>>> It is perfectly to limit the concept of "length" to >>>> >>>> * linear structures (lists, arrays, etc.) >>>> [branching structures do not have a length, they may have a size or >>>> maximum depth] >>>> >>>> * which have variable length >>>> [why would you otherwise ask for the length?] >>> >>> Just for the record, I could not agree more. >>> >>> Looking up "length", e.g. Merriam-Webster: >>> >>> 1a : the longer or longest dimension of an object >>> >>> What we really are talking about here is counting the number of >>> elements in a data structure. That is clearly applicable to lists >>> as well as trees and tuples interpreted in particular ways. >>> >>> But calling it "length" is not particularly helpful. Nor the effort to >>> reappropriate the very concept of "length" through a categorical >>> interpretation. >>> >>> It would have been a lot better if a name suggesting a sense of >>> counting, or at least a name suggesting that this is something different >>> than the usual length, would have been picked. Maybe elementcount >>> or ever flength. >> >> I agree, but on the other hand this should have been done _before_ >> FTP; at this stage, I lean towards marking this down as one of the >> known warts of Haskell - possibly with a 3 major version GHC cycle to >> migrate to a better name once the bikeshedding has been completed - >> and moving on rather than being revisionist and using this as an >> excuse to go backwards. >> >> So far, the arguments against these instances that I've seen are: >> >> * The name of the length function is misleading for such instances >> (with all respect to Tony, agreed; but see above); I don't think I've >> seen anyone else complain about any of the other function names >> though. >> >> * Since these classes/instances are now exported from the Prelude, >> previous code that wouldn't have have type-checked are now valid and >> thus produce unexpected results (I was against the Prelude export when >> FTP was being debated, but now - with the possible exception of people >> learning to program - I think this is a matter of needing to be more >> aware of the types and using our wonderful REPL environments to test >> functions rather than blindly just writing code without validating the >> code logic). >> >> TL;DR: I didn't 100% agree with the way FTP was done precisely due to >> the problems people have with these instances, but now let's not go >> backwards (and the tuple instances I've found very useful). >> >>> >>> Names matter. >>> >>> /Henrik >>> >>> >>> >>> >>> This message and any attachment are intended solely for the addressee >>> and may contain confidential information. If you have received this >>> message in error, please send it back to me, and immediately delete it. >>> Please do not use, copy or disclose the information contained in this >>> message or in any attachment. Any views or opinions expressed by the >>> author of this email do not necessarily reflect the views of the >>> University of Nottingham. >>> >>> This message has been checked for viruses but the contents of an >>> attachment may still contain software viruses which could damage your >>> computer system, you are advised to perform your own checks. Email >>> communications with the University of Nottingham may be monitored as >>> permitted by UK legislation. >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at 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 at gu.se > http://www.cse.chalmers.se/~abela/ > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From abela at chalmers.se Sat Apr 1 12:17:25 2017 From: abela at chalmers.se (Andreas Abel) Date: Sat, 1 Apr 2017 14:17:25 +0200 Subject: GHCI says we all drink left-handed In-Reply-To: References: Message-ID: <89f8f0d2-f671-6c70-4d88-597c49608cce@chalmers.se> Indeed. But all (const True) _ == True does not really come as surprise. Not really usable as a joke, the element of surprise is lacking! On 01.04.2017 13:36, Jon Purdy wrote: > If we assume that you drink beer: > > let drink beer = True > > Then we can conclude that it doesn’t matter which hand you drink with: > > all drink (Left Handed) == all drink (Right Handed) == True > > On Sat, Apr 1, 2017 at 4:08 AM, Andreas Abel > wrote: > > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > Prelude> data Handed = Handed > Prelude> let drink beer = beer > Prelude> all drink (Left Handed) > True > > -- > Andreas Abel <>< Du bist der geliebte Mensch. > > Department of Computer Science and Engineering > Chalmers and Gothenburg University, Sweden > > andreas.abel at gu.se > http://www.cse.chalmers.se/~abela/ > _______________________________________________ > Libraries mailing list > Libraries at 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 at gu.se http://www.cse.chalmers.se/~abela/ From lemming at henning-thielemann.de Sat Apr 1 13:39:38 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 1 Apr 2017 15:39:38 +0200 (CEST) Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> Message-ID: On Sat, 1 Apr 2017, Jakub Daniel wrote: > And I imagine nobody would argue that doesn't make sense. I kind of see > why people want better name than length but I see no really good > argument why the instance is bad. There are no doubt other generalised > notions. It also was an unfair question to ask what mathematicians would > think the length of (1,1) was. Because the question is not asked in > context where we ask about length for the type (a,-) not (-,-). And for me the context (a,-) is artificial. From lemming at henning-thielemann.de Sat Apr 1 13:42:40 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 1 Apr 2017 15:42:40 +0200 (CEST) Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> Message-ID: On Sat, 1 Apr 2017, Andreas Abel wrote: > In the end, I should be grateful for the FTP. It will provide amusement > for years. > > Q: What is the length of pi? > A: Dunno, infinity? > Q: And what is the length of just pi? > > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > Prelude> length (Just pi) > 1 > > ROFL. I have to admit that I even accept this more than length on pairs. I used to use Maybe for lists with length 0 or 1. From svenpanne at gmail.com Sat Apr 1 16:25:44 2017 From: svenpanne at gmail.com (Sven Panne) Date: Sat, 1 Apr 2017 18:25:44 +0200 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> Message-ID: 2017-04-01 12:32 GMT+02:00 Ivan Lazar Miljenovic : > [...] The name of the length function is misleading for such instances > (with all respect to Tony, agreed; but see above); I don't think I've > seen anyone else complain about any of the other function names > though. [...] > OK, hereby I officially complain about the other stuff which makes no sense for tuples: maximum (3,2) => 2 minimum (4,5) => 5 sum (6,7) => 7 product (8,9) => 9 Consistent? Yes. Is it really something you expect? No. Do you want this during refactoring? Definitely not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Sat Apr 1 18:45:30 2017 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sat, 1 Apr 2017 13:45:30 -0500 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> Message-ID: > El 1 abr 2017, a las 05:32, Ivan Lazar Miljenovic escribió: > > On 1 April 2017 at 19:42, Henrik Nilsson > wrote: >> Hi all, >> >>> It is perfectly to limit the concept of "length" to >>> >>> * linear structures (lists, arrays, etc.) >>> [branching structures do not have a length, they may have a size or >>> maximum depth] >>> >>> * which have variable length >>> [why would you otherwise ask for the length?] >> >> Just for the record, I could not agree more. >> >> Looking up "length", e.g. Merriam-Webster: >> >> 1a : the longer or longest dimension of an object >> >> What we really are talking about here is counting the number of >> elements in a data structure. That is clearly applicable to lists >> as well as trees and tuples interpreted in particular ways. >> >> But calling it "length" is not particularly helpful. Nor the effort to >> reappropriate the very concept of "length" through a categorical >> interpretation. >> >> It would have been a lot better if a name suggesting a sense of >> counting, or at least a name suggesting that this is something different >> than the usual length, would have been picked. Maybe elementcount >> or ever flength. > > I agree, but on the other hand this should have been done _before_ > FTP; at this stage, I lean towards marking this down as one of the > known warts of Haskell - possibly with a 3 major version GHC cycle to > migrate to a better name once the bikeshedding has been completed - > and moving on rather than being revisionist and using this as an > excuse to go backwards. > > So far, the arguments against these instances that I've seen are: > > * The name of the length function is misleading for such instances > (with all respect to Tony, agreed; but see above); I don't think I've > seen anyone else complain about any of the other function names > though. > > * Since these classes/instances are now exported from the Prelude, > previous code that wouldn't have have type-checked are now valid and > thus produce unexpected results (I was against the Prelude export when > FTP was being debated, but now - with the possible exception of people > learning to program - I think this is a matter of needing to be more > aware of the types and using our wonderful REPL environments to test > functions rather than blindly just writing code without validating the > code logic). My concern is not that people should be able to write trivial-to-check code without actually testing it. My concern (because it has happened to me in real code!) is people may write complex functions with difficult-to-inspect results. The bug that was trickiest to track down was a numerical calculation involving a list whose length was almost always 1, that I performed 'length' on. I wrapped the list in a tuple elsewhere in the code, ghc happily typechecked it, and only in rare cases did I get very weird results. This was deep within a larger calculation, and someone could have easily shipped something like this to production. Tom > > TL;DR: I didn't 100% agree with the way FTP was done precisely due to > the problems people have with these instances, but now let's not go > backwards (and the tuple instances I've found very useful). > >> >> Names matter. >> >> /Henrik >> >> >> >> >> This message and any attachment are intended solely for the addressee >> and may contain confidential information. If you have received this >> message in error, please send it back to me, and immediately delete it. >> Please do not use, copy or disclose the information contained in this >> message or in any attachment. Any views or opinions expressed by the >> author of this email do not necessarily reflect the views of the >> University of Nottingham. >> >> This message has been checked for viruses but the contents of an >> attachment may still contain software viruses which could damage your >> computer system, you are advised to perform your own checks. Email >> communications with the University of Nottingham may be monitored as >> permitted by UK legislation. >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From david.feuer at gmail.com Sat Apr 1 18:53:18 2017 From: david.feuer at gmail.com (David Feuer) Date: Sat, 1 Apr 2017 14:53:18 -0400 Subject: Getting containers updated in Stackage In-Reply-To: References: Message-ID: It's come to my attention that Stackage doesn't have the latest and greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just released 0.5.10.2. It'd be nice to get that fixed, but the containers maintainers do not have the time to take responsibility for Stackage curation. Could whoever's responsible please take care of it? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Sat Apr 1 20:13:35 2017 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sat, 1 Apr 2017 15:13:35 -0500 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> Message-ID: <39C63C40-0197-4203-B51D-91DA1F967427@gmail.com> > El 1 abr 2017, a las 13:45, amindfv at gmail.com escribió: > > > >> El 1 abr 2017, a las 05:32, Ivan Lazar Miljenovic escribió: >> >> On 1 April 2017 at 19:42, Henrik Nilsson >> wrote: >>> Hi all, >>> >>>> It is perfectly to limit the concept of "length" to >>>> >>>> * linear structures (lists, arrays, etc.) >>>> [branching structures do not have a length, they may have a size or >>>> maximum depth] >>>> >>>> * which have variable length >>>> [why would you otherwise ask for the length?] >>> >>> Just for the record, I could not agree more. >>> >>> Looking up "length", e.g. Merriam-Webster: >>> >>> 1a : the longer or longest dimension of an object >>> >>> What we really are talking about here is counting the number of >>> elements in a data structure. That is clearly applicable to lists >>> as well as trees and tuples interpreted in particular ways. >>> >>> But calling it "length" is not particularly helpful. Nor the effort to >>> reappropriate the very concept of "length" through a categorical >>> interpretation. >>> >>> It would have been a lot better if a name suggesting a sense of >>> counting, or at least a name suggesting that this is something different >>> than the usual length, would have been picked. Maybe elementcount >>> or ever flength. >> >> I agree, but on the other hand this should have been done _before_ >> FTP; at this stage, I lean towards marking this down as one of the >> known warts of Haskell - possibly with a 3 major version GHC cycle to >> migrate to a better name once the bikeshedding has been completed - >> and moving on rather than being revisionist and using this as an >> excuse to go backwards. >> >> So far, the arguments against these instances that I've seen are: >> >> * The name of the length function is misleading for such instances >> (with all respect to Tony, agreed; but see above); I don't think I've >> seen anyone else complain about any of the other function names >> though. >> >> * Since these classes/instances are now exported from the Prelude, >> previous code that wouldn't have have type-checked are now valid and >> thus produce unexpected results (I was against the Prelude export when >> FTP was being debated, but now - with the possible exception of people >> learning to program - I think this is a matter of needing to be more >> aware of the types and using our wonderful REPL environments to test >> functions rather than blindly just writing code without validating the >> code logic). > > My concern is not that people should be able to write trivial-to-check code without actually testing it. My concern (because it has happened to me in real code!) is people may write complex functions with difficult-to-inspect results. > > The bug that was trickiest to track down was a numerical calculation involving a list whose length was almost always 1, that I performed 'length' on. I wrapped the list in a tuple elsewhere in the code, ghc happily typechecked it, and only in rare cases did I get very weird results. This was deep within a larger calculation, and someone could have easily shipped something like this to production. > > Tom > Just to add: I don't think I've experienced bugs like these myself, but maximum (89,88) == 88 and friends seem prime for returning seemingly-correct results while a bug lurks, uncaught by the typechecker. Tom > >> >> TL;DR: I didn't 100% agree with the way FTP was done precisely due to >> the problems people have with these instances, but now let's not go >> backwards (and the tuple instances I've found very useful). >> >>> >>> Names matter. >>> >>> /Henrik >>> >>> >>> >>> >>> This message and any attachment are intended solely for the addressee >>> and may contain confidential information. If you have received this >>> message in error, please send it back to me, and immediately delete it. >>> Please do not use, copy or disclose the information contained in this >>> message or in any attachment. Any views or opinions expressed by the >>> author of this email do not necessarily reflect the views of the >>> University of Nottingham. >>> >>> This message has been checked for viruses but the contents of an >>> attachment may still contain software viruses which could damage your >>> computer system, you are advised to perform your own checks. Email >>> communications with the University of Nottingham may be monitored as >>> permitted by UK legislation. >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From svenpanne at gmail.com Sat Apr 1 22:09:08 2017 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 2 Apr 2017 00:09:08 +0200 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: References: Message-ID: 2017-04-01 20:53 GMT+02:00 David Feuer : > It's come to my attention that Stackage doesn't have the latest and > greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just > released 0.5.10.2. It'd be nice to get that fixed, but the containers > maintainers do not have the time to take responsibility for Stackage > curation. Could whoever's responsible please take care of it? > If I see this correctly, there is nothing to take care of: Stackage nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. When a new GHC is released and that ships with a new version of containers, it will be on Stackage. Apart from that, there is nothing you can do: Stackage is there to have a consistent set of packages, so containers is not even in https://github.com/fpco/stackage/blob/master/build-constraints.yaml, because it ships with GHC. That's at least my understanding... -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sat Apr 1 23:23:52 2017 From: david.feuer at gmail.com (David Feuer) Date: Sat, 1 Apr 2017 19:23:52 -0400 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: References: Message-ID: The fact that GHC needs to have its own containers shouldn't prevent a consistent package set from using a different one. The only hypothetical problem would be if the GHC API leaked containers types, but I'm pretty sure it doesn't: they're all wrapped up in newtypes and exported abstractly, unless someone's made a mistake. On Apr 1, 2017 6:09 PM, "Sven Panne" wrote: > 2017-04-01 20:53 GMT+02:00 David Feuer : > >> It's come to my attention that Stackage doesn't have the latest and >> greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just >> released 0.5.10.2. It'd be nice to get that fixed, but the containers >> maintainers do not have the time to take responsibility for Stackage >> curation. Could whoever's responsible please take care of it? >> > > If I see this correctly, there is nothing to take care of: Stackage > nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. > When a new GHC is released and that ships with a new version of containers, > it will be on Stackage. Apart from that, there is nothing you can do: > Stackage is there to have a consistent set of packages, so containers is > not even in https://github.com/fpco/stackage/blob/master/build- > constraints.yaml, because it ships with GHC. > > That's at least my understanding... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonymorris at gmail.com Sun Apr 2 00:56:15 2017 From: tonymorris at gmail.com (Tony Morris) Date: Sun, 2 Apr 2017 10:56:15 +1000 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> Message-ID: Whily you are correct Jakub, I think it's worse than that. Not only is it like being surpised then length [[1..]] == 1, we also have a kind system, so we can ignore the name. length :: f a -> Int We immediately know that values of the kind (* -> *) slot in to the value (f), with a kind checker to ensure we get it correct. Therefore, we can easily reason about the length of values of kind ((,) a) I do find it hilarious that this discussion continued using the term "tuple" as if to make a reasonable point. KIND ERROR. On 01/04/17 22:00, Jakub Daniel wrote: >> Q: What is the length of pi? >> A: Dunno, infinity? >> Q: And what is the length of just pi? >> >> GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help >> Prelude> length (Just pi) >> 1 >> >> ROFL. > That is like being surprised about > > length [1..] > > and > > length [[1..]] > > though. And I imagine nobody would argue that doesn't make sense. I kind of see why people want better name than length but I see no really good argument why the instance is bad. There are no doubt other generalised notions. It also was an unfair question to ask what mathematicians would think the length of (1,1) was. Because the question is not asked in context where we ask about length for the type (a,-) not (-,-). > > Jakub > > >>> On 01.04.2017 12:32, Ivan Lazar Miljenovic wrote: >>> On 1 April 2017 at 19:42, Henrik Nilsson >>> wrote: >>>> Hi all, >>>> >>>>> It is perfectly to limit the concept of "length" to >>>>> >>>>> * linear structures (lists, arrays, etc.) >>>>> [branching structures do not have a length, they may have a size or >>>>> maximum depth] >>>>> >>>>> * which have variable length >>>>> [why would you otherwise ask for the length?] >>>> Just for the record, I could not agree more. >>>> >>>> Looking up "length", e.g. Merriam-Webster: >>>> >>>> 1a : the longer or longest dimension of an object >>>> >>>> What we really are talking about here is counting the number of >>>> elements in a data structure. That is clearly applicable to lists >>>> as well as trees and tuples interpreted in particular ways. >>>> >>>> But calling it "length" is not particularly helpful. Nor the effort to >>>> reappropriate the very concept of "length" through a categorical >>>> interpretation. >>>> >>>> It would have been a lot better if a name suggesting a sense of >>>> counting, or at least a name suggesting that this is something different >>>> than the usual length, would have been picked. Maybe elementcount >>>> or ever flength. >>> I agree, but on the other hand this should have been done _before_ >>> FTP; at this stage, I lean towards marking this down as one of the >>> known warts of Haskell - possibly with a 3 major version GHC cycle to >>> migrate to a better name once the bikeshedding has been completed - >>> and moving on rather than being revisionist and using this as an >>> excuse to go backwards. >>> >>> So far, the arguments against these instances that I've seen are: >>> >>> * The name of the length function is misleading for such instances >>> (with all respect to Tony, agreed; but see above); I don't think I've >>> seen anyone else complain about any of the other function names >>> though. >>> >>> * Since these classes/instances are now exported from the Prelude, >>> previous code that wouldn't have have type-checked are now valid and >>> thus produce unexpected results (I was against the Prelude export when >>> FTP was being debated, but now - with the possible exception of people >>> learning to program - I think this is a matter of needing to be more >>> aware of the types and using our wonderful REPL environments to test >>> functions rather than blindly just writing code without validating the >>> code logic). >>> >>> TL;DR: I didn't 100% agree with the way FTP was done precisely due to >>> the problems people have with these instances, but now let's not go >>> backwards (and the tuple instances I've found very useful). >>> >>>> Names matter. >>>> >>>> /Henrik >>>> >>>> >>>> >>>> >>>> This message and any attachment are intended solely for the addressee >>>> and may contain confidential information. If you have received this >>>> message in error, please send it back to me, and immediately delete it. >>>> Please do not use, copy or disclose the information contained in this >>>> message or in any attachment. Any views or opinions expressed by the >>>> author of this email do not necessarily reflect the views of the >>>> University of Nottingham. >>>> >>>> This message has been checked for viruses but the contents of an >>>> attachment may still contain software viruses which could damage your >>>> computer system, you are advised to perform your own checks. Email >>>> communications with the University of Nottingham may be monitored as >>>> permitted by UK legislation. >>>> >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at 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 at gu.se >> http://www.cse.chalmers.se/~abela/ >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From Henrik.Nilsson at nottingham.ac.uk Sun Apr 2 08:22:40 2017 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Sun, 02 Apr 2017 09:22:40 +0100 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> Message-ID: <58E0B4D0.7040909@exmail.nottingham.ac.uk> On 04/02/2017 01:56 AM, Tony Morris wrote: > length :: f a -> Int > > We immediately know that values of the kind (* -> *) slot in to the > value (f), with a kind checker to ensure we get it correct. Therefore, > we can easily reason about the length of values of kind ((,) a) > > I do find it hilarious that this discussion continued using the term > "tuple" as if to make a reasonable point. KIND ERROR. And it's doubly hilarious that that the above argument is put forward without any regard for picking an appropriate name for the concept, which most certainly is very different from "length" as used in everyday parlance, physics, mathematics, and any CS text-book on data-structures and algorithms I've ever seen. Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From tonymorris at gmail.com Sun Apr 2 08:32:51 2017 From: tonymorris at gmail.com (Tony Morris) Date: Sun, 2 Apr 2017 18:32:51 +1000 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <58E0B4D0.7040909@exmail.nottingham.ac.uk> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> <58E0B4D0.7040909@exmail.nottingham.ac.uk> Message-ID: <7d04ae13-0dae-31ec-49e8-1a392adf3e6a@gmail.com> Join me in not caring about the names. Again, use the types. It's triply hilarious that we have a typed programming language, and an increasingly disproportionate user base who don't know how to use those types. What is this? Amateur hour? Python exists. On 02/04/17 18:22, Henrik Nilsson wrote: > On 04/02/2017 01:56 AM, Tony Morris wrote: >> length :: f a -> Int >> >> We immediately know that values of the kind (* -> *) slot in to the >> value (f), with a kind checker to ensure we get it correct. Therefore, >> we can easily reason about the length of values of kind ((,) a) >> >> I do find it hilarious that this discussion continued using the term >> "tuple" as if to make a reasonable point. KIND ERROR. > > And it's doubly hilarious that that the above argument is put forward > without any regard for picking an appropriate name for the concept, > which most certainly is very different from "length" as used in > everyday parlance, physics, mathematics, and any CS text-book on > data-structures and algorithms I've ever seen. > > Best, > > /Henrik > > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete it. > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From Henrik.Nilsson at nottingham.ac.uk Sun Apr 2 08:47:29 2017 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Sun, 02 Apr 2017 09:47:29 +0100 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <7d04ae13-0dae-31ec-49e8-1a392adf3e6a@gmail.com> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> <58E0B4D0.7040909@exmail.nottingham.ac.uk> <7d04ae13-0dae-31ec-49e8-1a392adf3e6a@gmail.com> Message-ID: <58E0BAA1.5010606@exmail.nottingham.ac.uk> On 04/02/2017 09:32 AM, Tony Morris wrote: > Join me in not caring about the names. Again, use the types. > > It's triply hilarious that we have a typed programming language, and an > increasingly disproportionate user base who don't know how to use those > types. What is this? Amateur hour? Python exists. > I'm sorry, but that's a supremely shallow and entirely polemic argument devoid of any substance whatsoever. And implying that people like those who initiated this thread are "amateurs" and know nothing about types is both offensive and manifestly unfounded. I suggest you check their credentials if there is any doubt on your part. Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From tanuki at gmail.com Sun Apr 2 08:54:45 2017 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Sun, 2 Apr 2017 01:54:45 -0700 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <7d04ae13-0dae-31ec-49e8-1a392adf3e6a@gmail.com> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> <58E0B4D0.7040909@exmail.nottingham.ac.uk> <7d04ae13-0dae-31ec-49e8-1a392adf3e6a@gmail.com> Message-ID: Come on guys, let's keep it respectful, especially considering this is the libraries list. Lively debate is good, but it shouldn't turn to noise. On Apr 2, 2017 1:33 AM, "Tony Morris" wrote: > Join me in not caring about the names. Again, use the types. > > It's triply hilarious that we have a typed programming language, and an > increasingly disproportionate user base who don't know how to use those > types. What is this? Amateur hour? Python exists. > > > On 02/04/17 18:22, Henrik Nilsson wrote: > > On 04/02/2017 01:56 AM, Tony Morris wrote: > >> length :: f a -> Int > >> > >> We immediately know that values of the kind (* -> *) slot in to the > >> value (f), with a kind checker to ensure we get it correct. Therefore, > >> we can easily reason about the length of values of kind ((,) a) > >> > >> I do find it hilarious that this discussion continued using the term > >> "tuple" as if to make a reasonable point. KIND ERROR. > > > > And it's doubly hilarious that that the above argument is put forward > > without any regard for picking an appropriate name for the concept, > > which most certainly is very different from "length" as used in > > everyday parlance, physics, mathematics, and any CS text-book on > > data-structures and algorithms I've ever seen. > > > > Best, > > > > /Henrik > > > > > > > > > > > > This message and any attachment are intended solely for the addressee > > and may contain confidential information. If you have received this > > message in error, please send it back to me, and immediately delete it. > > Please do not use, copy or disclose the information contained in this > > message or in any attachment. Any views or opinions expressed by the > > author of this email do not necessarily reflect the views of the > > University of Nottingham. > > > > This message has been checked for viruses but the contents of an > > attachment may still contain software viruses which could damage your > > computer system, you are advised to perform your own checks. Email > > communications with the University of Nottingham may be monitored as > > permitted by UK legislation. > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonymorris at gmail.com Sun Apr 2 09:03:20 2017 From: tonymorris at gmail.com (Tony Morris) Date: Sun, 2 Apr 2017 19:03:20 +1000 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <58E0BAA1.5010606@exmail.nottingham.ac.uk> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> <58E0B4D0.7040909@exmail.nottingham.ac.uk> <7d04ae13-0dae-31ec-49e8-1a392adf3e6a@gmail.com> <58E0BAA1.5010606@exmail.nottingham.ac.uk> Message-ID: <5943274f-c379-22c0-3182-2ef73345f9b4@gmail.com> That's fine. You are welcome to believe these things. You are welcome to take offense. You are welcome to believe using types responsibly is "shallow and devoid of substance" or whatever thought might best express this position that I find ridiculous. You are welcome to believe I would benefit by checking credentials. I clearly disagree that using types responsibly is shallow, and I also disagree that I would benefit by "checking credentials." I think it would be yet another waste of time to add to those that have been so strongly recommended. That's perfectly fine. Just keep this amateurism out of my code and we can all carry on. Rather than checking credentials, I instead demand that I work and seek others who are skilled at using types. I will fight to retain this ability. I need to hire people for example. I need to know if they are good at writing code, using types, etc. I think it is fair to fight for this ability, without getting personal, as you have chosen to do. I will continue to fight for this ability regardless. Anyway, programmers often degenerate into this personal ploppety poo. So, cheerio. *eyeroll* On 02/04/17 18:47, Henrik Nilsson wrote: > On 04/02/2017 09:32 AM, Tony Morris wrote: >> Join me in not caring about the names. Again, use the types. >> >> It's triply hilarious that we have a typed programming language, and an >> increasingly disproportionate user base who don't know how to use those >> types. What is this? Amateur hour? Python exists. >> > > I'm sorry, but that's a supremely shallow and entirely > polemic argument devoid of any substance whatsoever. > > And implying that people like those who initiated this > thread are "amateurs" and know nothing about types is > both offensive and manifestly unfounded. I suggest you > check their credentials if there is any doubt on your > part. > > Best, > > /Henrik > > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete it. > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From tonymorris at gmail.com Sun Apr 2 09:04:06 2017 From: tonymorris at gmail.com (Tony Morris) Date: Sun, 2 Apr 2017 19:04:06 +1000 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> <58E0B4D0.7040909@exmail.nottingham.ac.uk> <7d04ae13-0dae-31ec-49e8-1a392adf3e6a@gmail.com> Message-ID: <84fbe7a7-8ed2-b071-4bb8-7c9e0613aa6d@gmail.com> It was mostly a joke. Sorry it wasn't understood that way. On 02/04/17 18:54, Theodore Lief Gannon wrote: > Come on guys, let's keep it respectful, especially considering this is > the libraries list. Lively debate is good, but it shouldn't turn to noise. > > On Apr 2, 2017 1:33 AM, "Tony Morris" > wrote: > > Join me in not caring about the names. Again, use the types. > > It's triply hilarious that we have a typed programming language, > and an > increasingly disproportionate user base who don't know how to use > those > types. What is this? Amateur hour? Python exists. > > > On 02/04/17 18:22, Henrik Nilsson wrote: > > On 04/02/2017 01:56 AM, Tony Morris wrote: > >> length :: f a -> Int > >> > >> We immediately know that values of the kind (* -> *) slot in to the > >> value (f), with a kind checker to ensure we get it correct. > Therefore, > >> we can easily reason about the length of values of kind ((,) a) > >> > >> I do find it hilarious that this discussion continued using the > term > >> "tuple" as if to make a reasonable point. KIND ERROR. > > > > And it's doubly hilarious that that the above argument is put > forward > > without any regard for picking an appropriate name for the concept, > > which most certainly is very different from "length" as used in > > everyday parlance, physics, mathematics, and any CS text-book on > > data-structures and algorithms I've ever seen. > > > > Best, > > > > /Henrik > > > > > > > > > > > > This message and any attachment are intended solely for the > addressee > > and may contain confidential information. If you have received this > > message in error, please send it back to me, and immediately > delete it. > > Please do not use, copy or disclose the information contained in > this > > message or in any attachment. Any views or opinions expressed > by the > > author of this email do not necessarily reflect the views of the > > University of Nottingham. > > > > This message has been checked for viruses but the contents of an > > attachment may still contain software viruses which could damage > your > > computer system, you are advised to perform your own checks. Email > > communications with the University of Nottingham may be monitored as > > permitted by UK legislation. > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From adam at bergmark.nl Sun Apr 2 10:47:20 2017 From: adam at bergmark.nl (Adam Bergmark) Date: Sun, 02 Apr 2017 10:47:20 +0000 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: References: Message-ID: Hi David, As far as I know stackage doesn't have a mechanism to say "this might cause version mismatches but I promise it won't", is there even a way to do that with Cabal (which stackage uses)? Cheers, Adam On Sun, 2 Apr 2017 at 01:26 David Feuer wrote: > The fact that GHC needs to have its own containers shouldn't prevent a > consistent package set from using a different one. The only hypothetical > problem would be if the GHC API leaked containers types, but I'm pretty > sure it doesn't: they're all wrapped up in newtypes and exported > abstractly, unless someone's made a mistake. > > On Apr 1, 2017 6:09 PM, "Sven Panne" wrote: > > 2017-04-01 20:53 GMT+02:00 David Feuer : > > It's come to my attention that Stackage doesn't have the latest and > greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just > released 0.5.10.2. It'd be nice to get that fixed, but the containers > maintainers do not have the time to take responsibility for Stackage > curation. Could whoever's responsible please take care of it? > > > If I see this correctly, there is nothing to take care of: Stackage > nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. > When a new GHC is released and that ships with a new version of containers, > it will be on Stackage. Apart from that, there is nothing you can do: > Stackage is there to have a consistent set of packages, so containers is > not even in > https://github.com/fpco/stackage/blob/master/build-constraints.yaml, > because it ships with GHC. > > That's at least my understanding... > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fumiexcel at gmail.com Sun Apr 2 16:11:56 2017 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Mon, 3 Apr 2017 01:11:56 +0900 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (,,) a b In-Reply-To: References: Message-ID: The discussion has diverged to flaming due to a few offensive people. I guess I shouldn't have posted a proposal here, I should have submitted a patch instead. 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : > It's surprising that they are missing (forgive me, I'm not here to make > people grumpy). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Apr 2 16:24:21 2017 From: david.feuer at gmail.com (David Feuer) Date: Sun, 2 Apr 2017 12:24:21 -0400 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: References: Message-ID: What I'm suggesting is a bit narrower: I think stack should probably just ignore GHC boot packages altogether, aside from the necessary ones (I think just ghc-prim, ghc, base, and array, but you'd have to check the full GHC API to be sure). Never use them, and pretend they don't exist. On Apr 2, 2017 6:47 AM, "Adam Bergmark" wrote: > Hi David, > > As far as I know stackage doesn't have a mechanism to say "this might > cause version mismatches but I promise it won't", is there even a way to do > that with Cabal (which stackage uses)? > > Cheers, > Adam > > > On Sun, 2 Apr 2017 at 01:26 David Feuer wrote: > >> The fact that GHC needs to have its own containers shouldn't prevent a >> consistent package set from using a different one. The only hypothetical >> problem would be if the GHC API leaked containers types, but I'm pretty >> sure it doesn't: they're all wrapped up in newtypes and exported >> abstractly, unless someone's made a mistake. >> >> On Apr 1, 2017 6:09 PM, "Sven Panne" wrote: >> >> 2017-04-01 20:53 GMT+02:00 David Feuer : >> >> It's come to my attention that Stackage doesn't have the latest and >> greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just >> released 0.5.10.2. It'd be nice to get that fixed, but the containers >> maintainers do not have the time to take responsibility for Stackage >> curation. Could whoever's responsible please take care of it? >> >> >> If I see this correctly, there is nothing to take care of: Stackage >> nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. >> When a new GHC is released and that ships with a new version of containers, >> it will be on Stackage. Apart from that, there is nothing you can do: >> Stackage is there to have a consistent set of packages, so containers is >> not even in https://github.com/fpco/stackage/blob/master/build- >> constraints.yaml, because it ships with GHC. >> >> That's at least my understanding... >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Sun Apr 2 18:18:29 2017 From: amindfv at gmail.com (Tom Murphy) Date: Sun, 2 Apr 2017 14:18:29 -0400 Subject: Civility notes (was "Traversable instances for (,,) a b") Message-ID: Hi Fumiaki! I agree with you that some poorly-chosen words by a few people have soured this conversation, but please don't let that turn you completely off of the productive conversation most of us are attempting to have! I think it's largely been successful, too: even if many of us haven't changed our -1/+1 votes, I for one have had my ideas challenged and have a more nuanced view than before talking with everyone here. Henning and Edward are two examples (one from each side of the +1/-1 chasm) who have been aided by this discussion, in making important progress to finding a middle ground (each in the form of proposed compiler changes). To the rest of us: Fumiaki regretting having posted here is a pretty stark example of why speaking politely matters. People being scared away and feeling unwelcome is a real phenomenon, and we need to do our part to fix it. I'd propose: - If you haven't read it already, SPJ recently wrote a heartfelt letter on the subject [0]. We've gotten better since then, but clearly we're not finished. - Civility is a norm, and norms sometimes need to be enforced. From a distance, we all look bad (and unwelcoming!) if anyone is hostile and we don't make it clear it's not acceptable. Speak up! That said, everyone makes mistakes - try to give people space to apologize and move on. - If someone says something insulting to you, please take that as a sign to become more polite, not less so. The downward spiral is real. If you're called out for saying something regrettable (again, regardless of if you're +1 or -1 on this issue), *please* take our desire for civil conversation seriously. Responses like (I'm paraphrasing, and not trying to cite anyone specifically): "It was a joke (mostly)" and "It's your fault if you didn't get the joke" are worse than not writing anything at all. Ideal would be a quick "Sorry!" Thanks, all! Tom [0] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita wrote: > The discussion has diverged to flaming due to a few offensive people. I > guess I shouldn't have posted a proposal here, I should have submitted a > patch instead. > > 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : > >> It's surprising that they are missing (forgive me, I'm not here to make >> people grumpy). >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sun Apr 2 20:26:33 2017 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 2 Apr 2017 22:26:33 +0200 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: References: Message-ID: 2017-04-02 18:24 GMT+02:00 David Feuer : > What I'm suggesting is a bit narrower: I think stack should probably just > ignore GHC boot packages altogether, aside from the necessary ones (I think > just ghc-prim, ghc, base, and array, but you'd have to check the full GHC > API to be sure). Never use them, and pretend they don't exist. > My personal understanding of Stackage is: It's a collection of packages with *exactly* one version of each package, and all those versions are guaranteed to work together. (<= Well, at least in the eyes of the resolver, not necessarily in a semantic way) So: As long as GHC exposes its "non-necessary" packages, whatever that means in detail, I doubt that there will be other versions of them on Stackage. That's what Hackage is for... Again: That's at least my understanding... -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Apr 2 20:56:44 2017 From: david.feuer at gmail.com (David Feuer) Date: Sun, 2 Apr 2017 16:56:44 -0400 Subject: Deriving length better: missing method problem Message-ID: GHC 8.4 DeriveFoldable will derive the definition of `null` rather than falling back on the default. This can produce dramatic performance improvements. I would like to do the same for `length`, but unfortunately, there's a problem. ### Why I want to derive length Consider the declaration data Foo a = Foo (Map "String" a) (Set a) A hand-written definition of `length` would look like this: length (Foo m set) = length m + length set This would produce an O(1) implementation of length, since Map and Set are annotated with their lengths. But the default implementation of length (which is what you get when you use `deriving Foldable`) would instead produce length foo = foldl' (\acc _ -> acc + 1) 0 foo which is O(n). Gross. ### What's the problem? There's no problem deriving length for Foo. The trouble comes when trying to derive length for a recursive type. data List a = Nil | Cons a (List a) The most obvious implementation to derive would be length Nil = 0 length (Cons _ xs) = 1 + length xs but this is not tail recursive! That's absolutely no good. What we *want* here is length = lengthPlus 0 lengthPlus acc Nil = acc lengthPlus !acc (Cons _ xs) = lengthPlus (acc + 1) xs We actually could arrange for that in this case, since we see that a `List` contains itself recursively. But what about *mutual* recursion? data List2 a = Nil | Cons a (List2' a) newtype List2' a = List2' (List2 a) Now the deriving mechanism can't see the recursion, and everything is horrible. ### The simplest solution It seems likely that the simplest solution would be what nobody really wants: add yet another method to Foldable: lengthPlus :: Int -> f a -> Int lengthPlus n xs = n + length xs We could derive efficient implementations of `lengthPlus` without any particular difficulty. ### Alternatives? I haven't thought of any plausible alternatives yet. Maybe someone else will. David From tmorris at tmorris.net Sun Apr 2 23:12:37 2017 From: tmorris at tmorris.net (Tony Morris) Date: Mon, 3 Apr 2017 09:12:37 +1000 Subject: Civility notes (was "Traversable instances for (,,) a b") In-Reply-To: References: Message-ID: > It's your fault if you didn't get the joke" This never happened. > Ideal would be a quick "Sorry!" This did. On Mon, Apr 3, 2017 at 4:18 AM, Tom Murphy wrote: > Hi Fumiaki! > > I agree with you that some poorly-chosen words by a few people have > soured this conversation, but please don't let that turn you completely off > of the productive conversation most of us are attempting to have! I think > it's largely been successful, too: even if many of us haven't changed our > -1/+1 votes, I for one have had my ideas challenged and have a more nuanced > view than before talking with everyone here. > Henning and Edward are two examples (one from each side of the +1/-1 > chasm) who have been aided by this discussion, in making important progress > to finding a middle ground (each in the form of proposed compiler changes). > > To the rest of us: Fumiaki regretting having posted here is a pretty > stark example of why speaking politely matters. People being scared away > and feeling unwelcome is a real phenomenon, and we need to do our part to > fix it. I'd propose: > > - If you haven't read it already, SPJ recently wrote a heartfelt > letter on the subject [0]. We've gotten better since then, but clearly > we're not finished. > - Civility is a norm, and norms sometimes need to be enforced. From a > distance, we all look bad (and unwelcoming!) if anyone is hostile and we > don't make it clear it's not acceptable. Speak up! That said, everyone > makes mistakes - try to give people space to apologize and move on. > - If someone says something insulting to you, please take that as a > sign to become more polite, not less so. The downward spiral is real. > > If you're called out for saying something regrettable (again, > regardless of if you're +1 or -1 on this issue), *please* take our desire > for civil conversation seriously. Responses like (I'm paraphrasing, and not > trying to cite anyone specifically): "It was a joke (mostly)" and "It's > your fault if you didn't get the joke" are worse than not writing anything > at all. Ideal would be a quick "Sorry!" > > Thanks, all! > Tom > > [0] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html > > > > On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita > wrote: > >> The discussion has diverged to flaming due to a few offensive people. I >> guess I shouldn't have posted a proposal here, I should have submitted a >> patch instead. >> >> 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : >> >>> It's surprising that they are missing (forgive me, I'm not here to make >>> people grumpy). >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fumiexcel at gmail.com Mon Apr 3 01:44:10 2017 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Mon, 3 Apr 2017 10:44:10 +0900 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <84fbe7a7-8ed2-b071-4bb8-7c9e0613aa6d@gmail.com> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> <58E0B4D0.7040909@exmail.nottingham.ac.uk> <7d04ae13-0dae-31ec-49e8-1a392adf3e6a@gmail.com> <84fbe7a7-8ed2-b071-4bb8-7c9e0613aa6d@gmail.com> Message-ID: Don't think your "joke" made my proposal more convincing or helped anything. 2017-04-02 18:04 GMT+09:00 Tony Morris : > It was mostly a joke. Sorry it wasn't understood that way. > > On 02/04/17 18:54, Theodore Lief Gannon wrote: > > Come on guys, let's keep it respectful, especially considering this is the > libraries list. Lively debate is good, but it shouldn't turn to noise. > > On Apr 2, 2017 1:33 AM, "Tony Morris" wrote: > >> Join me in not caring about the names. Again, use the types. >> >> It's triply hilarious that we have a typed programming language, and an >> increasingly disproportionate user base who don't know how to use those >> types. What is this? Amateur hour? Python exists. >> >> >> On 02/04/17 18:22, Henrik Nilsson wrote: >> > On 04/02/2017 01:56 AM, Tony Morris wrote: >> >> length :: f a -> Int >> >> >> >> We immediately know that values of the kind (* -> *) slot in to the >> >> value (f), with a kind checker to ensure we get it correct. Therefore, >> >> we can easily reason about the length of values of kind ((,) a) >> >> >> >> I do find it hilarious that this discussion continued using the term >> >> "tuple" as if to make a reasonable point. KIND ERROR. >> > >> > And it's doubly hilarious that that the above argument is put forward >> > without any regard for picking an appropriate name for the concept, >> > which most certainly is very different from "length" as used in >> > everyday parlance, physics, mathematics, and any CS text-book on >> > data-structures and algorithms I've ever seen. >> > >> > Best, >> > >> > /Henrik >> > >> > >> > >> > >> > >> > This message and any attachment are intended solely for the addressee >> > and may contain confidential information. If you have received this >> > message in error, please send it back to me, and immediately delete it. >> > Please do not use, copy or disclose the information contained in this >> > message or in any attachment. Any views or opinions expressed by the >> > author of this email do not necessarily reflect the views of the >> > University of Nottingham. >> > >> > This message has been checked for viruses but the contents of an >> > attachment may still contain software viruses which could damage your >> > computer system, you are advised to perform your own checks. Email >> > communications with the University of Nottingham may be monitored as >> > permitted by UK legislation. >> > >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonymorris at gmail.com Mon Apr 3 01:54:35 2017 From: tonymorris at gmail.com (Tony Morris) Date: Mon, 3 Apr 2017 11:54:35 +1000 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <17266fee-093c-c83b-1656-0c1e7869360c@chalmers.se> <58DF67F0.9070509@exmail.nottingham.ac.uk> <59bc5844-5927-b693-42a0-31f1e6ad102f@chalmers.se> <58E0B4D0.7040909@exmail.nottingham.ac.uk> <7d04ae13-0dae-31ec-49e8-1a392adf3e6a@gmail.com> <84fbe7a7-8ed2-b071-4bb8-7c9e0613aa6d@gmail.com> Message-ID: <3a2727d5-6f08-a00d-d063-b33044eee939@gmail.com> Shall we have a big discussion about it? Jeepers creepers mate. Sorry for not apologising correctly. On 03/04/17 11:44, Fumiaki Kinoshita wrote: > Don't think your "joke" made my proposal more convincing or helped > anything. > > 2017-04-02 18:04 GMT+09:00 Tony Morris >: > > It was mostly a joke. Sorry it wasn't understood that way. > > > On 02/04/17 18:54, Theodore Lief Gannon wrote: >> Come on guys, let's keep it respectful, especially considering >> this is the libraries list. Lively debate is good, but it >> shouldn't turn to noise. >> >> On Apr 2, 2017 1:33 AM, "Tony Morris" > > wrote: >> >> Join me in not caring about the names. Again, use the types. >> >> It's triply hilarious that we have a typed programming >> language, and an >> increasingly disproportionate user base who don't know how to >> use those >> types. What is this? Amateur hour? Python exists. >> >> >> On 02/04/17 18:22, Henrik Nilsson wrote: >> > On 04/02/2017 01:56 AM, Tony Morris wrote: >> >> length :: f a -> Int >> >> >> >> We immediately know that values of the kind (* -> *) slot >> in to the >> >> value (f), with a kind checker to ensure we get it >> correct. Therefore, >> >> we can easily reason about the length of values of kind >> ((,) a) >> >> >> >> I do find it hilarious that this discussion continued >> using the term >> >> "tuple" as if to make a reasonable point. KIND ERROR. >> > >> > And it's doubly hilarious that that the above argument is >> put forward >> > without any regard for picking an appropriate name for the >> concept, >> > which most certainly is very different from "length" as used in >> > everyday parlance, physics, mathematics, and any CS >> text-book on >> > data-structures and algorithms I've ever seen. >> > >> > Best, >> > >> > /Henrik >> > >> > >> > >> > >> > >> > This message and any attachment are intended solely for the >> addressee >> > and may contain confidential information. If you have >> received this >> > message in error, please send it back to me, and >> immediately delete it. >> > Please do not use, copy or disclose the information >> contained in this >> > message or in any attachment. Any views or opinions >> expressed by the >> > author of this email do not necessarily reflect the views >> of the >> > University of Nottingham. >> > >> > This message has been checked for viruses but the contents >> of an >> > attachment may still contain software viruses which could >> damage your >> > computer system, you are advised to perform your own >> checks. Email >> > communications with the University of Nottingham may be >> monitored as >> > permitted by UK legislation. >> > >> > _______________________________________________ >> > Libraries mailing list >> > Libraries at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ekmett at gmail.com Mon Apr 3 05:58:20 2017 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 3 Apr 2017 01:58:20 -0400 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: References: Message-ID: That doesn't work if you link against ghc the library. If I run ghc-pkg describe ghc on my slightly old install, it shows depends: array-0.5.1.1 base-4.9.0.0 binary-0.8.3.0 bytestring-0.10.8.1 containers-0.5.7.1 directory-1.2.6.2 filepath-1.4.1.0 ghc-boot-8.0.1 ghci-8.0.1 hoopl-3.10.2.1 hpc-0.6.0.3 process-1.4.2.0 template-haskell-2.11.0.0 time-1.6.0.1 transformers-0.5.2.0 unix-2.7.2.0 If any of these are upgraded independently of ghc then every package that depends on both ghc will start to fail to build due to needing to link two versions of the same dependency. Examples of packages that depend on ghc with wide distribution that lots of folks depend on in at least one configuration of their builds? doctest This makes this a fairly crippling distribution hazard for something like stackage that runs the unit tests that comes with the packages it provides. =) Back in the day ghc used to maintain its own forks of many of its dependencies to avoid some of these sorts of issues. It doesn't do so any more. -Edward On Sun, Apr 2, 2017 at 12:24 PM, David Feuer wrote: > What I'm suggesting is a bit narrower: I think stack should probably just > ignore GHC boot packages altogether, aside from the necessary ones (I think > just ghc-prim, ghc, base, and array, but you'd have to check the full GHC > API to be sure). Never use them, and pretend they don't exist. > > On Apr 2, 2017 6:47 AM, "Adam Bergmark" wrote: > >> Hi David, >> >> As far as I know stackage doesn't have a mechanism to say "this might >> cause version mismatches but I promise it won't", is there even a way to do >> that with Cabal (which stackage uses)? >> >> Cheers, >> Adam >> >> >> On Sun, 2 Apr 2017 at 01:26 David Feuer wrote: >> >>> The fact that GHC needs to have its own containers shouldn't prevent a >>> consistent package set from using a different one. The only hypothetical >>> problem would be if the GHC API leaked containers types, but I'm pretty >>> sure it doesn't: they're all wrapped up in newtypes and exported >>> abstractly, unless someone's made a mistake. >>> >>> On Apr 1, 2017 6:09 PM, "Sven Panne" wrote: >>> >>> 2017-04-01 20:53 GMT+02:00 David Feuer : >>> >>> It's come to my attention that Stackage doesn't have the latest and >>> greatest versions of containers. Stackage nightly is on 0.5.7.1, and I just >>> released 0.5.10.2. It'd be nice to get that fixed, but the containers >>> maintainers do not have the time to take responsibility for Stackage >>> curation. Could whoever's responsible please take care of it? >>> >>> >>> If I see this correctly, there is nothing to take care of: Stackage >>> nightly and LTS both ship GHC 8.0.2, and that contains containers 0.5.7.1. >>> When a new GHC is released and that ships with a new version of containers, >>> it will be on Stackage. Apart from that, there is nothing you can do: >>> Stackage is there to have a consistent set of packages, so containers is >>> not even in https://github.com/fpco/stackage/blob/master/build-constrain >>> ts.yaml, because it ships with GHC. >>> >>> That's at least my understanding... >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Apr 3 08:13:37 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 3 Apr 2017 08:13:37 +0000 Subject: Civility notes (was "Traversable instances for (,,) a b") In-Reply-To: References: Message-ID: Friends I second what Tom says below. Almost everyone expresses their views with respect, even when disagreeing. The exceptions are (in my guess) mostly unintentional, at least in the extent of the offence caused. That does not make them unimportant, because a slow slippage in our collective standards is, over time corrosive. But it does mean that we can draw breath, as Tom has helpfully done here, and without condemning anyone reset our standards. I’ve been talking to a couple of people about whether it would be useful to have an explicit Haskell Community Code of Conduct. Many online communities have one (e.g. Rust), and it might be helpful for everyone to have a concrete baseline rather than an unwritten standard. Any views on that? Simon From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Tom Murphy Sent: 02 April 2017 19:18 To: Fumiaki Kinoshita Cc: libraries Subject: Civility notes (was "Traversable instances for (,,) a b") Hi Fumiaki! I agree with you that some poorly-chosen words by a few people have soured this conversation, but please don't let that turn you completely off of the productive conversation most of us are attempting to have! I think it's largely been successful, too: even if many of us haven't changed our -1/+1 votes, I for one have had my ideas challenged and have a more nuanced view than before talking with everyone here. Henning and Edward are two examples (one from each side of the +1/-1 chasm) who have been aided by this discussion, in making important progress to finding a middle ground (each in the form of proposed compiler changes). To the rest of us: Fumiaki regretting having posted here is a pretty stark example of why speaking politely matters. People being scared away and feeling unwelcome is a real phenomenon, and we need to do our part to fix it. I'd propose: - If you haven't read it already, SPJ recently wrote a heartfelt letter on the subject [0]. We've gotten better since then, but clearly we're not finished. - Civility is a norm, and norms sometimes need to be enforced. From a distance, we all look bad (and unwelcoming!) if anyone is hostile and we don't make it clear it's not acceptable. Speak up! That said, everyone makes mistakes - try to give people space to apologize and move on. - If someone says something insulting to you, please take that as a sign to become more polite, not less so. The downward spiral is real. If you're called out for saying something regrettable (again, regardless of if you're +1 or -1 on this issue), *please* take our desire for civil conversation seriously. Responses like (I'm paraphrasing, and not trying to cite anyone specifically): "It was a joke (mostly)" and "It's your fault if you didn't get the joke" are worse than not writing anything at all. Ideal would be a quick "Sorry!" Thanks, all! Tom [0] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita > wrote: The discussion has diverged to flaming due to a few offensive people. I guess I shouldn't have posted a proposal here, I should have submitted a patch instead. 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita >: It's surprising that they are missing (forgive me, I'm not here to make people grumpy). _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Mon Apr 3 08:17:56 2017 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Mon, 03 Apr 2017 10:17:56 +0200 Subject: [Haskell-cafe] Getting containers updated in Stackage In-Reply-To: (David Feuer's message of "Sat, 1 Apr 2017 19:23:52 -0400") References: Message-ID: <871st9c3bf.fsf@gmail.com> Hi, On 2017-04-02 at 01:23:52 +0200, David Feuer wrote: > The fact that GHC needs to have its own containers shouldn't prevent a > consistent package set from using a different one. The only hypothetical > problem would be if the GHC API leaked containers types, but I'm pretty > sure it doesn't: they're all wrapped up in newtypes and exported > abstractly, unless someone's made a mistake. Fwiw, I just opened up the GHC api haddocks and arbitrarily picked a module and sure enough I was able to find a use of an exposed container type rightaway, specificially `IntMap`: https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.0.1/HscTypes.html#t:ModBreaks I'd expect to easily find more leaked types from containers and other dependencies. Relatedly, I don't think it's a good idea to implement support for internal/private dependencies at this point yet w/o first having the tools to verify that types that are supposed to stay hidden don't leak through the exposed API. Otoh, tools for doing this kind of static analysis are also needed to verify the existing API versioning contract we already use now. And once we have such go-to tooling, it should be easy to build on top of that. However, if we wanted to decouple `ghc` from `containers` (and possibly other packages, such as process/transformers/unix/bytestring/binary) by declaring the use of its `container` types private/internal to `ghc`'s API, we could just go back to do what we did years ago (e.g. in GHC 7.0.4) by using renamed packages like `ghc-binary` (but also revisit the reasons why we don't do this anymore...). Another approach would be to make the `ghc` package recompilable by `cabal`. I briefly tried that[1] but got side-tracked, and I still believe it should be possible to get the `ghc` package to the point where it's an ordinary `cabal`-buildable package. [1]: Not the least, so I could upload it to Hackage and have its Haddocks being generated without too much magic; but more importantly so that cabal would be less constrained when solving for install-plans when `ghc` is involved, as well as GHC HQ being able to more easily pick up new dependencies for `ghc` w/o having to introduce yet another congestion point in terms of dependency constraints (i.e. packages depended upon by `ghc` are effectively frozen to those picked by a given GHC release once `ghc` enters an install-plan). From tonymorris at gmail.com Mon Apr 3 08:30:09 2017 From: tonymorris at gmail.com (Tony Morris) Date: Mon, 3 Apr 2017 18:30:09 +1000 Subject: Civility notes (was "Traversable instances for (,,) a b") In-Reply-To: References: Message-ID: I was hoping an apology could be accepted, and move on. On 03/04/17 18:13, Simon Peyton Jones via Libraries wrote: > > Friends > > > > I second what Tom says below. > > > > Almost everyone expresses their views with respect, even when > disagreeing. The exceptions are (in my guess) mostly unintentional, > at least in the extent of the offence caused. That does not make > them unimportant, because a slow slippage in our collective standards > is, over time corrosive. But it does mean that we can draw breath, as > Tom has helpfully done here, and without condemning anyone reset our > standards. > > > > I’ve been talking to a couple of people about whether it would be > useful to have an explicit Haskell Community Code of Conduct. Many > online communities have one (e.g. Rust > ), and it might be > helpful for everyone to have a concrete baseline rather than an > unwritten standard. Any views on that? > > > > Simon > > > > *From:*Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of > *Tom Murphy > *Sent:* 02 April 2017 19:18 > *To:* Fumiaki Kinoshita > *Cc:* libraries > *Subject:* Civility notes (was "Traversable instances for (,,) a b") > > > > Hi Fumiaki! > > I agree with you that some poorly-chosen words by a few people > have soured this conversation, but please don't let that turn you > completely off of the productive conversation most of us are > attempting to have! I think it's largely been successful, too: even if > many of us haven't changed our -1/+1 votes, I for one have had my > ideas challenged and have a more nuanced view than before talking with > everyone here. > > Henning and Edward are two examples (one from each side of the > +1/-1 chasm) who have been aided by this discussion, in making > important progress to finding a middle ground (each in the form of > proposed compiler changes). > > To the rest of us: Fumiaki regretting having posted here is a > pretty stark example of why speaking politely matters. People being > scared away and feeling unwelcome is a real phenomenon, and we need to > do our part to fix it. I'd propose: > > - If you haven't read it already, SPJ recently wrote a heartfelt > letter on the subject [0]. We've gotten better since then, but clearly > we're not finished. > > - Civility is a norm, and norms sometimes need to be enforced. > From a distance, we all look bad (and unwelcoming!) if anyone is > hostile and we don't make it clear it's not acceptable. Speak up! That > said, everyone makes mistakes - try to give people space to apologize > and move on. > > - If someone says something insulting to you, please take that as > a sign to become more polite, not less so. The downward spiral is real. > > > > If you're called out for saying something regrettable (again, > regardless of if you're +1 or -1 on this issue), *please* take our > desire for civil conversation seriously. Responses like (I'm > paraphrasing, and not trying to cite anyone specifically): "It was a > joke (mostly)" and "It's your fault if you didn't get the joke" are > worse than not writing anything at all. Ideal would be a quick "Sorry!" > > Thanks, all! > > Tom > > > [0] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html > > > > > > On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita > > wrote: > > The discussion has diverged to flaming due to a few offensive > people. I guess I shouldn't have posted a proposal here, I should > have submitted a patch instead. > > > > 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita >: > > It's surprising that they are missing (forgive me, I'm not > here to make people grumpy). > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lemming at henning-thielemann.de Mon Apr 3 08:42:37 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 3 Apr 2017 10:42:37 +0200 (CEST) Subject: Civility notes (was "Traversable instances for (,,) a b") In-Reply-To: References: Message-ID: On Mon, 3 Apr 2017, Simon Peyton Jones via Libraries wrote: > I’ve been talking to a couple of people about whether it would be useful > to have an explicit Haskell Community Code of Conduct.  Many online > communities have one (e.g. Rust), and it might be helpful for everyone > to have a concrete baseline rather than an unwritten standard.  Any > views on that? I think these Code of Conducts make things even worse because then some people start to check every word against these codes. Instead I suggest we make more use of humor. E.g. Carter Schonwald's comment about grumpy people made me think about renaming my prelude-compat package to grumpy-prelude. :-) From tikhon at jelv.is Mon Apr 3 08:52:38 2017 From: tikhon at jelv.is (Tikhon Jelvis) Date: Mon, 3 Apr 2017 01:52:38 -0700 Subject: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b") In-Reply-To: References: Message-ID: Personally, I would not be against a *short and simple* code of conduct that specifically addresses issues we have seen. I'm imagining clear guidelines that help people express themselves in a thoughtful and polite way. Something in the style of the Hacker News commenting guidelines[1] (at least the first four; the rest are specific to HN/Reddit-like sites). One of the best examples I've seen in the wild had a single rule: no personal attacks. It's simple to understand and follow with no risk of stifling or derailing real discussions, and yet unambiguously rules out the majority of rude comments I see online (ignoring spam and outright trolling). I do *not* like Rust's code of conduct specifically. It does not provide clear guidelines on civility/politeness and covers too many other things, including a lot of (often political) baggage. Why is the idea that "everything is a tradeoff" enshrined as a rule? The rule on politeness is clearly deemphasized: "Please be kind and courteous. There’s no need to be mean or rude." is so vague it may as well not be in the code of conduct. We should *assume* people set out to be kind and courteous and help them do that consistently. The "Citizen Code of Conduct" they link to has even more baggage and I believe it should *not* serve as the basis for anything we might adopt as a community. [1]: https://news.ycombinator.com/newsguidelines.html see section "In Comments" On Mon, Apr 3, 2017 at 1:13 AM, Simon Peyton Jones via Haskell-community < haskell-community at haskell.org> wrote: > Friends > > > > I second what Tom says below. > > > > Almost everyone expresses their views with respect, even when > disagreeing. The exceptions are (in my guess) mostly unintentional, at > least in the extent of the offence caused. That does not make them > unimportant, because a slow slippage in our collective standards is, over > time corrosive. But it does mean that we can draw breath, as Tom has > helpfully done here, and without condemning anyone reset our standards. > > > > I’ve been talking to a couple of people about whether it would be useful > to have an explicit Haskell Community Code of Conduct. Many online > communities have one (e.g. Rust > ), and it might be helpful > for everyone to have a concrete baseline rather than an unwritten > standard. Any views on that? > > > > Simon > > > > *From:* Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of *Tom > Murphy > *Sent:* 02 April 2017 19:18 > *To:* Fumiaki Kinoshita > *Cc:* libraries > *Subject:* Civility notes (was "Traversable instances for (,,) a b") > > > > Hi Fumiaki! > > I agree with you that some poorly-chosen words by a few people have > soured this conversation, but please don't let that turn you completely off > of the productive conversation most of us are attempting to have! I think > it's largely been successful, too: even if many of us haven't changed our > -1/+1 votes, I for one have had my ideas challenged and have a more nuanced > view than before talking with everyone here. > > Henning and Edward are two examples (one from each side of the +1/-1 > chasm) who have been aided by this discussion, in making important progress > to finding a middle ground (each in the form of proposed compiler changes). > > To the rest of us: Fumiaki regretting having posted here is a pretty > stark example of why speaking politely matters. People being scared away > and feeling unwelcome is a real phenomenon, and we need to do our part to > fix it. I'd propose: > > - If you haven't read it already, SPJ recently wrote a heartfelt > letter on the subject [0]. We've gotten better since then, but clearly > we're not finished. > > - Civility is a norm, and norms sometimes need to be enforced. From a > distance, we all look bad (and unwelcoming!) if anyone is hostile and we > don't make it clear it's not acceptable. Speak up! That said, everyone > makes mistakes - try to give people space to apologize and move on. > > - If someone says something insulting to you, please take that as a > sign to become more polite, not less so. The downward spiral is real. > > > > If you're called out for saying something regrettable (again, > regardless of if you're +1 or -1 on this issue), *please* take our desire > for civil conversation seriously. Responses like (I'm paraphrasing, and not > trying to cite anyone specifically): "It was a joke (mostly)" and "It's > your fault if you didn't get the joke" are worse than not writing anything > at all. Ideal would be a quick "Sorry!" > > Thanks, all! > > Tom > > > [0] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html > > > > > > On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita > wrote: > > The discussion has diverged to flaming due to a few offensive people. I > guess I shouldn't have posted a proposal here, I should have submitted a > patch instead. > > > > 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : > > It's surprising that they are missing (forgive me, I'm not here to make > people grumpy). > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Mon Apr 3 09:32:01 2017 From: fa-ml at ariis.it (Francesco Ariis) Date: Mon, 3 Apr 2017 11:32:01 +0200 Subject: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b") In-Reply-To: References: Message-ID: <20170403093201.GA749@casa.casa> On Mon, Apr 03, 2017 at 01:52:38AM -0700, Tikhon Jelvis wrote: > Personally, I would not be against a *short and simple* code of conduct > that specifically addresses issues we have seen. I'm imagining clear > guidelines that help people express themselves in a thoughtful and polite > way. Something in the style of the Hacker News commenting guidelines[1] (at > least the first four; the rest are specific to HN/Reddit-like sites). You might be interested in Ruby's COC [1] too. They had a discussion some time ago and Matz&co requirements were "short and to the point". Indeed it's very clear to read. [1] https://www.ruby-lang.org/en/conduct/ From p.giarrusso at gmail.com Mon Apr 3 15:32:27 2017 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Mon, 3 Apr 2017 17:32:27 +0200 Subject: Constraints on definition of `length` should be strengthened Message-ID: TL;DR. One (implicit?) assumption in recent debates on `length` seems to be unfounded, because current docs for Foldable are meant to be much stronger than their actual language, unless I'm missing something. Clarifications welcome. If my understanding is right, I'd suggest somebody fixes the docs. One point is not clear to me, so at present I could not volunteer to fix them myself. In recent debates, it was assumed or implied that `length` must be equivalent to length = length . toList > we also have a kind > system, so we can ignore the name. > length :: f a -> Int > We immediately know that values of the kind (* -> *) slot in to the > value (f), with a kind checker to ensure we get it correct. Therefore, > we can easily reason about the length of values of kind ((,) a) I don't quite get how that argument is supposed to proceed. However that's meant, that seems incorrect because length is a typeclass method, so even the following strawman instance typechecks: instance Foldable ((,,) a b) where length _ = 42 I assume this should violate some law, but the relevant law seems to be forgotten. The most constraining language I can find is the following: > sum, product, maximum, and minimum should all be essentially equivalent to foldMap forms, such as > sum = getSum . foldMap Sum > but may be less defined. but (a) `length` is not even mentioned, even if it's intended (b) I think those should be laws (c) using "should" and "essentially" in "should all be essentially equivalent", seems too weak. I can infer the intention, but this seems insufficient to declare Docs for `length` don't help either: > Returns the size/length of a finite structure as an Int. The default implementation is optimized for structures that are similar to cons-lists, because there is no general way to do better. I mean, these docs use the English word "length", so that actually forbids 42, but that text is too vague to forbid 3 frankly. As I missing something? I also take issue with "may be less defined", and here I'm not sure of the intention, since that declares instance Foldable ((,,) a b) where length _ = undefined as legal. I imagine the point is about taking the length of partially undefined structures, but it's not clear to me why a custom `sum` implementation would be less defined than `sum = getSum . foldMap Sum`. Even ignoring the above instances (which I would never write down), I can't reason much about my code based on those specifications. This situation seems unfortunate. Cheers, -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ From david.feuer at gmail.com Mon Apr 3 15:59:31 2017 From: david.feuer at gmail.com (David Feuer) Date: Mon, 3 Apr 2017 11:59:31 -0400 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: length should be quite well-behaved relative to foldMap: length = getSum . foldMap (Sum . const 1) Another law pretty much everyone agrees on is that *if* f is an instance of Traversable, then foldMap = foldMapDefault That leaves a few trouble spots: 1. There are types that some people think shouldn't have Functor/Foldable/Traversable instances at all, or that some people would like to have Functor and maybe even Traversable instances for without wanting Foldable instances. The latter is impossible because of a superclass constraint. One essential issue here seems to be one of perspective: is Foo x y a container of ys, decorated with xs, or is it a container of xs and ys? Different people tend to think about this differently, and thus form different intuitions. 2. There are some functions that the Prelude re-exports from Data.Foldable when it used to export list-specific versions. Some people would like the Prelude to go back to what it did before. 3. It's extremely difficult to formulate useful laws about instances of Foldable that are not also instances of Traversable. This seems to suggest that Foldable itself is an ad hoc convenience rather than a meaningful abstraction of its own. On Apr 3, 2017 11:33 AM, "Paolo Giarrusso" wrote: TL;DR. One (implicit?) assumption in recent debates on `length` seems to be unfounded, because current docs for Foldable are meant to be much stronger than their actual language, unless I'm missing something. Clarifications welcome. If my understanding is right, I'd suggest somebody fixes the docs. One point is not clear to me, so at present I could not volunteer to fix them myself. In recent debates, it was assumed or implied that `length` must be equivalent to length = length . toList > we also have a kind > system, so we can ignore the name. > length :: f a -> Int > We immediately know that values of the kind (* -> *) slot in to the > value (f), with a kind checker to ensure we get it correct. Therefore, > we can easily reason about the length of values of kind ((,) a) I don't quite get how that argument is supposed to proceed. However that's meant, that seems incorrect because length is a typeclass method, so even the following strawman instance typechecks: instance Foldable ((,,) a b) where length _ = 42 I assume this should violate some law, but the relevant law seems to be forgotten. The most constraining language I can find is the following: > sum, product, maximum, and minimum should all be essentially equivalent to foldMap forms, such as > sum = getSum . foldMap Sum > but may be less defined. but (a) `length` is not even mentioned, even if it's intended (b) I think those should be laws (c) using "should" and "essentially" in "should all be essentially equivalent", seems too weak. I can infer the intention, but this seems insufficient to declare Docs for `length` don't help either: > Returns the size/length of a finite structure as an Int. The default implementation is optimized for structures that are similar to cons-lists, because there is no general way to do better. I mean, these docs use the English word "length", so that actually forbids 42, but that text is too vague to forbid 3 frankly. As I missing something? I also take issue with "may be less defined", and here I'm not sure of the intention, since that declares instance Foldable ((,,) a b) where length _ = undefined as legal. I imagine the point is about taking the length of partially undefined structures, but it's not clear to me why a custom `sum` implementation would be less defined than `sum = getSum . foldMap Sum`. Even ignoring the above instances (which I would never write down), I can't reason much about my code based on those specifications. This situation seems unfortunate. Cheers, -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Apr 3 16:38:52 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 3 Apr 2017 18:38:52 +0200 (CEST) Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: On Mon, 3 Apr 2017, David Feuer wrote: > That leaves a few trouble spots: > > 1. There are types that some people think shouldn't have > Functor/Foldable/Traversable instances at all, or that some people would > like to have Functor and maybe even Traversable instances for without > wanting Foldable instances. The latter is impossible because of a > superclass constraint. One essential issue here seems to be one of > perspective: is Foo x y a container of ys, decorated with xs, or is it a > container of xs and ys? Different people tend to think about this > differently, and thus form different intuitions. I don't know if anyone has a problem with interpreting a custom data type Foo x y as a container of ys decorated with xs - if it is defined for that purpose. Discussion arose solely about the cases Foo = (,), Foo = (,,) x and so on. E.g. I actually proposed to define a custom data type like Decorated x y instead of (x,y) in case you want to have a Foldable instance. From b at chreekat.net Mon Apr 3 19:18:48 2017 From: b at chreekat.net (Bryan Richter) Date: Mon, 3 Apr 2017 12:18:48 -0700 Subject: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b") In-Reply-To: <20170403093201.GA749@casa.casa> References: <20170403093201.GA749@casa.casa> Message-ID: <20170403191848.GA368@fuzzbomb> On Mon, Apr 03, 2017 at 11:32:01AM +0200, Francesco Ariis wrote: > On Mon, Apr 03, 2017 at 01:52:38AM -0700, Tikhon Jelvis wrote: > > Personally, I would not be against a *short and simple* code of conduct > > that specifically addresses issues we have seen. I'm imagining clear > > guidelines that help people express themselves in a thoughtful and polite > > way. Something in the style of the Hacker News commenting guidelines[1] (at > > least the first four; the rest are specific to HN/Reddit-like sites). > > You might be interested in Ruby's COC [1] too. They had a discussion > some time ago and Matz&co requirements were "short and to the point". > Indeed it's very clear to read. +1 to having an explicit code of conduct. All communities have such a code; some are merely unwritten and harder to scrutinize. For a slightly longer example that is still rather clear, Snowdrift.coop has its code here: https://wiki.snowdrift.coop/community/conduct. It can be summarized as, "Act with honor and good will, assume good faith, and do not use hostile language." It's very similar to Ruby's code, with Ruby's first item captured in "act with honor and good will", and Ruby's second and forth items captured in "do not use hostile language". I like that they both include the assumption of good faith. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Digital signature URL: From svenpanne at gmail.com Mon Apr 3 19:47:12 2017 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 3 Apr 2017 21:47:12 +0200 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: 2017-04-03 18:38 GMT+02:00 Henning Thielemann : > > On Mon, 3 Apr 2017, David Feuer wrote: > > That leaves a few trouble spots: >> >> 1. There are types that some people think shouldn't have >> Functor/Foldable/Traversable instances at all, or that some people would >> like to have Functor and maybe even Traversable instances for without >> wanting Foldable instances. The latter is impossible because of a >> superclass constraint. One essential issue here seems to be one of >> perspective: is Foo x y a container of ys, decorated with xs, or is it a >> container of xs and ys? Different people tend to think about this >> differently, and thus form different intuitions. >> > > I don't know if anyone has a problem with interpreting a custom data type > Foo x y as a container of ys decorated with xs - if it is defined for that > purpose. Discussion arose solely about the cases Foo = (,), Foo = (,,) x > and so on. Of course such an interpretation is possible, but let's remember Abelson's famous quote: "Programs must be written for people to read, and only incidentally for machines to execute." When you show somebody a pair and ask "What is this?", how many people do you *seriously* expect to say "Oh, yeah, I've seen that: It's a value on the right decorated by another one on the left!" compared to people telling you something about e.g. cartesian products (which are totally symmetric with no bias to the right or left)? The point is: Using a pair for a decorated one-element container is completely miscommunicating your intent, even if you find a sensible mathematical interpretation for it. All the programs from http://www.ioccc.org/ have a sensible mathematical interpretation, too, but that doesn't mean I want to see them outside of that contest. ;-) > E.g. I actually proposed to define a custom data type like Decorated x y > instead of (x,y) in case you want to have a Foldable instance. *This* is communicating you intent IHMO, and I doubt you need more types for different arities: If you e.g. want to have 3 values for decoration, just use a triple (or something isomorphic) with Decorated. This is much clearer than having a family of Decorated, Decorated2, Decorated3, ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Apr 3 19:56:48 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 3 Apr 2017 21:56:48 +0200 (CEST) Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: On Mon, 3 Apr 2017, Sven Panne wrote: > Of course such an interpretation is possible, but let's remember Abelson's famous quote: > >    "Programs must be written for people to read, and only incidentally for machines to execute." > > When you show somebody a pair and ask "What is this?", how many people > do you *seriously* expect to say "Oh, yeah, I've seen that: It's a value > on the right decorated by another one on the left!" compared to people > telling you something about e.g. cartesian products (which are totally > symmetric with no bias to the right or left)? The point is: Using a pair > for a decorated one-element container is completely miscommunicating > your intent, even if you find a sensible mathematical interpretation for > it. That's what I am saying all the time. From nbouscal at gmail.com Mon Apr 3 20:29:58 2017 From: nbouscal at gmail.com (Nathan Bouscal) Date: Mon, 3 Apr 2017 13:29:58 -0700 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: I expect most people probably agree that it'd be nice to have tuples be an unbiased cartesian product, but the actual fact of the matter is that tuples as they exist in Haskell are biased. We can't just ignore that and pretend they're unbiased. It definitely sucks that the answer people would naively give to "what is a tuple in Haskell" is not the correct answer, but we're stuck in that situation. The question is how to make the best of it. On Mon, Apr 3, 2017 at 12:56 PM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Mon, 3 Apr 2017, Sven Panne wrote: > > Of course such an interpretation is possible, but let's remember Abelson's >> famous quote: >> >> "Programs must be written for people to read, and only incidentally >> for machines to execute." >> >> When you show somebody a pair and ask "What is this?", how many people do >> you *seriously* expect to say "Oh, yeah, I've seen that: It's a value on >> the right decorated by another one on the left!" compared to people telling >> you something about e.g. cartesian products (which are totally symmetric >> with no bias to the right or left)? The point is: Using a pair for a >> decorated one-element container is completely miscommunicating your intent, >> even if you find a sensible mathematical interpretation for it. >> > > That's what I am saying all the time. > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Mon Apr 3 20:48:33 2017 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 3 Apr 2017 22:48:33 +0200 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: 2017-04-03 22:29 GMT+02:00 Nathan Bouscal : > I expect most people probably agree that it'd be nice to have tuples be an > unbiased cartesian product, but the actual fact of the matter is that > tuples as they exist in Haskell are biased. > Tuples *are* unbiased, the bias is just an artifact of seeing them as a curried function, where the positions are "eaten" from left to right. Again, this mathematically correct, but more often than not the main intent of using a tuple- > We can't just ignore that and pretend they're unbiased. > We *can* ignore that, just use Henning's Decorated for an isomorphic variant. > It definitely sucks that the answer people would naively give to "what is > a tuple in Haskell" is not the correct answer, but we're stuck in that > situation. > See above, we are not stuck: We *can* get back normal people's intuition and Haskell's semantics back in line by removing the tuple instances and adding something like Decorated. It is just a matter of priorities: This will temporarily damage the Haskell ecosystem a bit, but in the long run it will be the nicer, more explicit, more intuitive way. > The question is how to make the best of it. > If the tuple instances are removed and Decorated is added, things are easy to fix: The compiler will tell you exactly the places where you were too lazy to define and use a custom data type, and the fix is mechanical. The current situation is quite the opposite: People silently get totally unexpected behavior. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Mon Apr 3 20:52:02 2017 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 3 Apr 2017 22:52:02 +0200 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: [ Hit the wrong button... :-P ] 2017-04-03 22:48 GMT+02:00 Sven Panne : > [...] Again, this mathematically correct, but more often than not the main > intent of using a tuple- [...] > Again, this is mathematically correct, but more often than not, the main intent of using a tuple is not a curried function but a heterogeneous container with no special bias at all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Apr 3 21:01:28 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 3 Apr 2017 23:01:28 +0200 (CEST) Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: On Mon, 3 Apr 2017, Sven Panne wrote: > [ Hit the wrong button... :-P ] > > 2017-04-03 22:48 GMT+02:00 Sven Panne : > [...] Again, this mathematically correct, but more often than not the main intent of using a tuple- > [...] > > > Again, this is mathematically correct, but more often than not, the main > intent of using a tuple is not a curried function but a heterogeneous > container with no special bias at all. I think the special syntax (a,b,c) emphasises the unbiased nature and I think that tuples are often chosen because of that syntax (and not because of the prefix form (,,)). However, I guess we are in the wrong thread. I just wanted to comment on David Feuer whose explanation could be (mis)understood as if there is a controversy about whether custom data types like Foo a b should be considered biased or not. From ekmett at gmail.com Mon Apr 3 21:03:10 2017 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 3 Apr 2017 17:03:10 -0400 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: Discussion has been raised elsewhere about `Either e` just in the last month or so, etc as well. The goal posts slide around quite a bit, almost like there are lots of people with different opinions. Others are fine with the instances but want to monomorphize null, length, maximum/minimum/sum/product/everything, it depends on who you ask and when. -Edward On Mon, Apr 3, 2017 at 12:38 PM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Mon, 3 Apr 2017, David Feuer wrote: > > That leaves a few trouble spots: >> >> 1. There are types that some people think shouldn't have >> Functor/Foldable/Traversable instances at all, or that some people would >> like to have Functor and maybe even Traversable instances for without >> wanting Foldable instances. The latter is impossible because of a >> superclass constraint. One essential issue here seems to be one of >> perspective: is Foo x y a container of ys, decorated with xs, or is it a >> container of xs and ys? Different people tend to think about this >> differently, and thus form different intuitions. >> > > I don't know if anyone has a problem with interpreting a custom data type > Foo x y as a container of ys decorated with xs - if it is defined for that > purpose. Discussion arose solely about the cases Foo = (,), Foo = (,,) x > and so on. E.g. I actually proposed to define a custom data type like > Decorated x y instead of (x,y) in case you want to have a Foldable instance. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon Apr 3 21:07:01 2017 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 3 Apr 2017 23:07:01 +0200 (CEST) Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: On Mon, 3 Apr 2017, Edward Kmett wrote: > Discussion has been raised elsewhere about `Either e` just in the last > month or so, etc as well. The goal posts slide around quite a bit, > almost like there are lots of people with different opinions. I see, Foo can also be Either. From nbouscal at gmail.com Mon Apr 3 21:14:56 2017 From: nbouscal at gmail.com (Nathan Bouscal) Date: Mon, 3 Apr 2017 14:14:56 -0700 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: On Mon, Apr 3, 2017 at 1:48 PM, Sven Panne wrote: > 2017-04-03 22:29 GMT+02:00 Nathan Bouscal : > >> I expect most people probably agree that it'd be nice to have tuples be >> an unbiased cartesian product, but the actual fact of the matter is that >> tuples as they exist in Haskell are biased. >> > > Tuples *are* unbiased, the bias is just an artifact of seeing them as a > curried function, where the positions are "eaten" from left to right. > Again, this mathematically correct, but more often than not the main intent > of using a tuple- > > … no, they're not. What other type of correct is there than mathematically correct? "Zero *isn't* an integer, that's just an artifact of *seeing* it as an integer." > We can't just ignore that and pretend they're unbiased. >> > > We *can* ignore that, just use Henning's Decorated for an isomorphic > variant. > > >> It definitely sucks that the answer people would naively give to "what is >> a tuple in Haskell" is not the correct answer, but we're stuck in that >> situation. >> > > See above, we are not stuck: We *can* get back normal people's intuition > and Haskell's semantics back in line by removing the tuple instances and > adding something like Decorated. It is just a matter of priorities: This > will temporarily damage the Haskell ecosystem a bit, but in the long run it > will be the nicer, more explicit, more intuitive way. > > You can't get tuples to behave like they're unbiased. You can try to hide the fact that they're biased by getting rid of the only possible instances they can support, but that doesn't magically make them unbiased. It sounds like you just want to rename tuples to Decorated. Maybe that's a good idea, but call it what it is. > The question is how to make the best of it. >> > > If the tuple instances are removed and Decorated is added, things are easy > to fix: The compiler will tell you exactly the places where you were too > lazy to define and use a custom data type, and the fix is mechanical. The > current situation is quite the opposite: People silently get totally > unexpected behavior. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlad.z.4096 at gmail.com Tue Apr 4 06:10:03 2017 From: vlad.z.4096 at gmail.com (Vladislav Zavialov) Date: Tue, 4 Apr 2017 09:10:03 +0300 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: There's a way to get unbiased products in Haskell. The trick is to make their kind [Type] -> Type: data family Product (xs :: [Type]) data instance Product '[] = Unit data instance Product '[a] = Id a data instance Product '[a,b] = Pair a b data instance Product '[a,b,c] = Triple a b c ... We could make (a,b) syntactic sugar for Product '[a,b] at type level and for Pair at term level - this would invalidate all asymmetric instances. Unfortunately, this is would break an immense amount of code and violate the Haskell standard. (Another variation is to define Product inductively as a GADT with constructors Cons and Nil, but the result would be a HList that has a different memory representation than tuples). On Tue, Apr 4, 2017 at 12:14 AM, Nathan Bouscal wrote: > > > On Mon, Apr 3, 2017 at 1:48 PM, Sven Panne wrote: >> >> 2017-04-03 22:29 GMT+02:00 Nathan Bouscal : >>> >>> I expect most people probably agree that it'd be nice to have tuples be >>> an unbiased cartesian product, but the actual fact of the matter is that >>> tuples as they exist in Haskell are biased. >> >> >> Tuples *are* unbiased, the bias is just an artifact of seeing them as a >> curried function, where the positions are "eaten" from left to right. Again, >> this mathematically correct, but more often than not the main intent of >> using a tuple- >> > > > … no, they're not. What other type of correct is there than mathematically > correct? "Zero isn't an integer, that's just an artifact of *seeing* it as > an integer." > > >>> >>> We can't just ignore that and pretend they're unbiased. >> >> >> We *can* ignore that, just use Henning's Decorated for an isomorphic >> variant. >> >>> >>> It definitely sucks that the answer people would naively give to "what is >>> a tuple in Haskell" is not the correct answer, but we're stuck in that >>> situation. >> >> >> See above, we are not stuck: We *can* get back normal people's intuition >> and Haskell's semantics back in line by removing the tuple instances and >> adding something like Decorated. It is just a matter of priorities: This >> will temporarily damage the Haskell ecosystem a bit, but in the long run it >> will be the nicer, more explicit, more intuitive way. >> > > > You can't get tuples to behave like they're unbiased. You can try to hide > the fact that they're biased by getting rid of the only possible instances > they can support, but that doesn't magically make them unbiased. It sounds > like you just want to rename tuples to Decorated. Maybe that's a good idea, > but call it what it is. > >>> >>> The question is how to make the best of it. >> >> >> If the tuple instances are removed and Decorated is added, things are easy >> to fix: The compiler will tell you exactly the places where you were too >> lazy to define and use a custom data type, and the fix is mechanical. The >> current situation is quite the opposite: People silently get totally >> unexpected behavior. >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From svenpanne at gmail.com Tue Apr 4 06:11:34 2017 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 4 Apr 2017 08:11:34 +0200 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: 2017-04-03 23:14 GMT+02:00 Nathan Bouscal : > On Mon, Apr 3, 2017 at 1:48 PM, Sven Panne wrote: > >> Tuples *are* unbiased, the bias is just an artifact of seeing them as a >> curried function, where the positions are "eaten" from left to right. >> Again, this mathematically correct, but more often than not the main intent >> of using a tuple- >> >> > > … no, they're not. What other type of correct is there than mathematically > correct? "Zero *isn't* an integer, that's just an artifact of *seeing* it > as an integer." > Tuples are unbiased cartesian products, full stop. All the left bias is coming from currying. If you have a signature of e.g.: fobar :: Int -> (a, b) -> Float -> Bar I can't see any bias here. OTOH: fobar' :: Int -> a -> b -> Float -> Bar Now you have a left bias, because you can partially apply foobar' with e.g. 2 arguments, "eating away" the 'a', but keeping the 'b'. > You can't get tuples to behave like they're unbiased. You can try to hide > the fact that they're biased by getting rid of the only possible instances > they can support, but that doesn't magically make them unbiased. > Again, tuples are unbiased, you just put an interpretation onto them which is induced by currying, but which is not the intuitive one. I want to get rid of that interpretation as the default one, because that's a miscommunication of intents (see previous post). > It sounds like you just want to rename tuples to Decorated. Maybe that's a > good idea, but call it what it is. > Nope, my proposal is: Keep tuples what they are (unbiased heterogenous collections) and make any bias explicit (Decorated). -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlad.z.4096 at gmail.com Tue Apr 4 06:15:29 2017 From: vlad.z.4096 at gmail.com (Vladislav Zavialov) Date: Tue, 4 Apr 2017 09:15:29 +0300 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: > Tuples are unbiased cartesian products, full stop. This statement is not correct. Look at their kind: > :k (,) (,) :: * -> * -> * The same currying business is going on here. One of the types is privileged. To get unbiased products in Haskell, you need their kind to be [*] -> * or similar. On Tue, Apr 4, 2017 at 9:11 AM, Sven Panne wrote: > 2017-04-03 23:14 GMT+02:00 Nathan Bouscal : >> >> On Mon, Apr 3, 2017 at 1:48 PM, Sven Panne wrote: >>> >>> Tuples *are* unbiased, the bias is just an artifact of seeing them as a >>> curried function, where the positions are "eaten" from left to right. Again, >>> this mathematically correct, but more often than not the main intent of >>> using a tuple- >>> >> >> >> … no, they're not. What other type of correct is there than mathematically >> correct? "Zero isn't an integer, that's just an artifact of *seeing* it as >> an integer." > > > Tuples are unbiased cartesian products, full stop. All the left bias is > coming from currying. If you have a signature of e.g.: > > fobar :: Int -> (a, b) -> Float -> Bar > > I can't see any bias here. OTOH: > > fobar' :: Int -> a -> b -> Float -> Bar > > Now you have a left bias, because you can partially apply foobar' with e.g. > 2 arguments, "eating away" the 'a', but keeping the 'b'. > > >> >> You can't get tuples to behave like they're unbiased. You can try to hide >> the fact that they're biased by getting rid of the only possible instances >> they can support, but that doesn't magically make them unbiased. > > > Again, tuples are unbiased, you just put an interpretation onto them which > is induced by currying, but which is not the intuitive one. I want to get > rid of that interpretation as the default one, because that's a > miscommunication of intents (see previous post). > >> >> It sounds like you just want to rename tuples to Decorated. Maybe that's a >> good idea, but call it what it is. > > > Nope, my proposal is: Keep tuples what they are (unbiased heterogenous > collections) and make any bias explicit (Decorated). > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From svenpanne at gmail.com Tue Apr 4 06:50:55 2017 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 4 Apr 2017 08:50:55 +0200 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: 2017-04-04 8:15 GMT+02:00 Vladislav Zavialov : > > Tuples are unbiased cartesian products, full stop. > > This statement is not correct. According to probably all the math books in the world, the statement is correct, at least if we want to see tuples as cartesian products. But if we don't want to do that, the usage of the name "tuple" in Haskell and the (...,...) notation would be confusing misnomers. > Look at their kind: > > > :k (,) > (,) :: * -> * -> * > > The same currying business is going on here. [...] That's an artifact of our kind system, not a consequence of the usual definition of cartesian products. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlad.z.4096 at gmail.com Tue Apr 4 06:58:15 2017 From: vlad.z.4096 at gmail.com (Vladislav Zavialov) Date: Tue, 4 Apr 2017 09:58:15 +0300 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: You want tuples in mathematics and tuples in Haskell to be the same, but they aren't. Call it an artifact of the kind system or a misnomer, but that's the state of affairs. It's counter-intuitive and I don't like it myself. My point is that if you want to fix this, it takes more than to delete a few instances from 'base'. See my other message in this thread about defining unbiased products in Haskell. On Tue, Apr 4, 2017 at 9:50 AM, Sven Panne wrote: > 2017-04-04 8:15 GMT+02:00 Vladislav Zavialov : >> >> > Tuples are unbiased cartesian products, full stop. >> >> This statement is not correct. > > > According to probably all the math books in the world, the statement is > correct, at least if we want to see tuples as cartesian products. But if we > don't want to do that, the usage of the name "tuple" in Haskell and the > (...,...) notation would be confusing misnomers. > >> >> Look at their kind: >> >> > :k (,) >> (,) :: * -> * -> * >> >> The same currying business is going on here. [...] > > > That's an artifact of our kind system, not a consequence of the usual > definition of cartesian products. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From Henrik.Nilsson at nottingham.ac.uk Tue Apr 4 08:33:49 2017 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Tue, 04 Apr 2017 09:33:49 +0100 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: <58E35A6D.9090309@exmail.nottingham.ac.uk> Hi, On 04/03/2017 10:14 PM, Nathan Bouscal wrote: > You can't get tuples to behave like they're unbiased. You can try to > hide the fact that they're biased by getting rid of the only possible > instances they can support, but that doesn't magically make them > unbiased. It sounds like you just want to rename tuples to Decorated. > Maybe that's a good idea, but call it what it is. While I (so far) disagree, I am trying to fully appreciate this argument. The reason is that it seems to me that the above has more to do with specific syntactic details regarding instance declarations for partially applied type constructors, than with what (in this case) tuples fundamentally are in Haskell: essentially Cartesian products. For the sake of argument, suppose some mechanism were adopted to mitigate the bias implied by the (inevitable) ordering of arguments to to type constructors. For tuples, we might imagine some kind of notation inspired by operator sections as a first step, making the following instance declaration possible: instance Functor (,b) where ... Would tuples then still be biased in the above sense, and if so why? Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From jon.fairbairn at cl.cam.ac.uk Tue Apr 4 08:43:59 2017 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Tue, 04 Apr 2017 09:43:59 +0100 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> Message-ID: Tony Morris writes: > A contrary, consistent position would mean there is a belief in all of > the following: > > * the length of any value of the type ((,) a) is not 1 > * 0 is not an integer You say this, but I’m wondering why. (-1) is also an integer, so can you give me an example for the (-1) case? — Jón From vlad.z.4096 at gmail.com Tue Apr 4 09:25:09 2017 From: vlad.z.4096 at gmail.com (Vladislav Zavialov) Date: Tue, 4 Apr 2017 12:25:09 +0300 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: <58E35A6D.9090309@exmail.nottingham.ac.uk> References: <58E35A6D.9090309@exmail.nottingham.ac.uk> Message-ID: On Tue, Apr 4, 2017 at 11:33 AM, Henrik Nilsson wrote: > > For the sake of argument, suppose some mechanism were adopted to > mitigate the bias implied by the (inevitable) ordering of arguments > to to type constructors. For tuples, we might imagine some kind > of notation inspired by operator sections as a first step, making the > following instance declaration possible: > > instance Functor (,b) where > ... > > Would tuples then still be biased in the above sense, and if > so why? > No, tuples wouldn't be biased if (a,) and (,b) could behave the same, i.e. 'f x' could be instantiated as both '(a,x)' and '(x,b)'. However, what you propose is not possible in Haskell and the extension is not straightforward. (1) Writing (,b) would require type-level lambda functions, as it's equivalent to writing '\a -> (a,b)'. Type-level lambdas are not straightforward at all: they conflict with the matchability (injectivity+generativity) assumption about type constructors - currently 'f a ~ g b' implies 'f ~ g' and 'a ~ b' - which is not true for arbitrary type-level functions. Removing this rule would wreak havoc on type inference. The solution seems to be to have two kinds of type-level arrows, as described in Richard Eisenberg's thesis on Dependent Haskell. (2) Even if type-level functions are added to the language, it's very likely that they will be disallowed as class parameters. Notice that classes perform pattern matching on types, and pattern matching on functions is impossible. So even if one could write '\a -> (a,b), writing Functor (\a -> (a,b)) would remain impossible. (3) Assume that somehow we managed to solve those problems. What instance do you define, Functor (a,) or Functor (,b)? Perhaps neither? Or maybe Functor (\a -> (a,a)) to map over both arguments? Hard design questions, many opinions will emerge! Do those instances even overlap? - determining this requires the compiler to reason about function equalities. All in all, I see only two sensible ways to proceed: accept that tuples are biased, or make them unbiased by changing their kind from Type -> Type -> Type to something uncurried. From david.feuer at gmail.com Tue Apr 4 12:18:26 2017 From: david.feuer at gmail.com (David Feuer) Date: Tue, 4 Apr 2017 08:18:26 -0400 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: <58E35A6D.9090309@exmail.nottingham.ac.uk> Message-ID: Vladislav, I wonder if you might propose a language extension to use tuple syntax the way you describe. Such an extension would allow people to tinker with this idea without making the community commit to such a change. On Apr 4, 2017 5:25 AM, "Vladislav Zavialov" wrote: On Tue, Apr 4, 2017 at 11:33 AM, Henrik Nilsson wrote: > > For the sake of argument, suppose some mechanism were adopted to > mitigate the bias implied by the (inevitable) ordering of arguments > to to type constructors. For tuples, we might imagine some kind > of notation inspired by operator sections as a first step, making the > following instance declaration possible: > > instance Functor (,b) where > ... > > Would tuples then still be biased in the above sense, and if > so why? > No, tuples wouldn't be biased if (a,) and (,b) could behave the same, i.e. 'f x' could be instantiated as both '(a,x)' and '(x,b)'. However, what you propose is not possible in Haskell and the extension is not straightforward. (1) Writing (,b) would require type-level lambda functions, as it's equivalent to writing '\a -> (a,b)'. Type-level lambdas are not straightforward at all: they conflict with the matchability (injectivity+generativity) assumption about type constructors - currently 'f a ~ g b' implies 'f ~ g' and 'a ~ b' - which is not true for arbitrary type-level functions. Removing this rule would wreak havoc on type inference. The solution seems to be to have two kinds of type-level arrows, as described in Richard Eisenberg's thesis on Dependent Haskell. (2) Even if type-level functions are added to the language, it's very likely that they will be disallowed as class parameters. Notice that classes perform pattern matching on types, and pattern matching on functions is impossible. So even if one could write '\a -> (a,b), writing Functor (\a -> (a,b)) would remain impossible. (3) Assume that somehow we managed to solve those problems. What instance do you define, Functor (a,) or Functor (,b)? Perhaps neither? Or maybe Functor (\a -> (a,a)) to map over both arguments? Hard design questions, many opinions will emerge! Do those instances even overlap? - determining this requires the compiler to reason about function equalities. All in all, I see only two sensible ways to proceed: accept that tuples are biased, or make them unbiased by changing their kind from Type -> Type -> Type to something uncurried. _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Wed Apr 5 14:51:01 2017 From: ben.franksen at online.de (Ben Franksen) Date: Wed, 5 Apr 2017 16:51:01 +0200 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> Message-ID: Am 01.04.2017 um 03:27 schrieb Tony Morris: > The length of ((,) a) is exactly one. Anything else is ridiculous. Try > arguing against that, Half true: length for this type makes no sense at all since it is not a sequence. So there should be no length defined for it. Just choose a different name. Cheers Ben From carter.schonwald at gmail.com Wed Apr 5 15:41:13 2017 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 5 Apr 2017 11:41:13 -0400 Subject: Civility notes (was "Traversable instances for (,,) a b") In-Reply-To: References: Message-ID: :) I look forward to the ways we all disagree. I personally worry that a code of conduct still has a crucial weakness, .... HUMANS. interpretation of natural language rules or human behavior always has an ambiguous element, and this is why any sufficiently not sure set of rules *must* have a legal enforcment and judicial infrastructure. (i think Tikhon articulates my perspective on code of conducts way better than I could ) On Mon, Apr 3, 2017 at 4:42 AM, Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Mon, 3 Apr 2017, Simon Peyton Jones via Libraries wrote: > > I’ve been talking to a couple of people about whether it would be useful >> to have an explicit Haskell Community Code of Conduct. Many online >> communities have one (e.g. Rust), and it might be helpful for everyone to >> have a concrete baseline rather than an unwritten standard. Any views on >> that? >> > > I think these Code of Conducts make things even worse because then some > people start to check every word against these codes. Instead I suggest we > make more use of humor. E.g. Carter Schonwald's comment about grumpy people > made me think about renaming my prelude-compat package to grumpy-prelude. > :-) > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Apr 5 15:41:28 2017 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 5 Apr 2017 11:41:28 -0400 Subject: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b") In-Reply-To: References: Message-ID: agreed with Tikhon's points, they say it way better than I could On Mon, Apr 3, 2017 at 4:52 AM, Tikhon Jelvis wrote: > Personally, I would not be against a *short and simple* code of conduct > that specifically addresses issues we have seen. I'm imagining clear > guidelines that help people express themselves in a thoughtful and polite > way. Something in the style of the Hacker News commenting guidelines[1] (at > least the first four; the rest are specific to HN/Reddit-like sites). > > One of the best examples I've seen in the wild had a single rule: no > personal attacks. It's simple to understand and follow with no risk of > stifling or derailing real discussions, and yet unambiguously rules out the > majority of rude comments I see online (ignoring spam and outright > trolling). > > I do *not* like Rust's code of conduct specifically. It does not provide > clear guidelines on civility/politeness and covers too many other things, > including a lot of (often political) baggage. Why is the idea that > "everything is a tradeoff" enshrined as a rule? The rule on politeness is > clearly deemphasized: "Please be kind and courteous. There’s no need to be > mean or rude." is so vague it may as well not be in the code of conduct. We > should *assume* people set out to be kind and courteous and help them do > that consistently. The "Citizen Code of Conduct" they link to has even more > baggage and I believe it should *not* serve as the basis for anything we > might adopt as a community. > > [1]: https://news.ycombinator.com/newsguidelines.html see section "In > Comments" > > On Mon, Apr 3, 2017 at 1:13 AM, Simon Peyton Jones via Haskell-community < > haskell-community at haskell.org> wrote: > >> Friends >> >> >> >> I second what Tom says below. >> >> >> >> Almost everyone expresses their views with respect, even when >> disagreeing. The exceptions are (in my guess) mostly unintentional, at >> least in the extent of the offence caused. That does not make them >> unimportant, because a slow slippage in our collective standards is, over >> time corrosive. But it does mean that we can draw breath, as Tom has >> helpfully done here, and without condemning anyone reset our standards. >> >> >> >> I’ve been talking to a couple of people about whether it would be useful >> to have an explicit Haskell Community Code of Conduct. Many online >> communities have one (e.g. Rust >> ), and it might be helpful >> for everyone to have a concrete baseline rather than an unwritten >> standard. Any views on that? >> >> >> >> Simon >> >> >> >> *From:* Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of *Tom >> Murphy >> *Sent:* 02 April 2017 19:18 >> *To:* Fumiaki Kinoshita >> *Cc:* libraries >> *Subject:* Civility notes (was "Traversable instances for (,,) a b") >> >> >> >> Hi Fumiaki! >> >> I agree with you that some poorly-chosen words by a few people have >> soured this conversation, but please don't let that turn you completely off >> of the productive conversation most of us are attempting to have! I think >> it's largely been successful, too: even if many of us haven't changed our >> -1/+1 votes, I for one have had my ideas challenged and have a more nuanced >> view than before talking with everyone here. >> >> Henning and Edward are two examples (one from each side of the +1/-1 >> chasm) who have been aided by this discussion, in making important progress >> to finding a middle ground (each in the form of proposed compiler changes). >> >> To the rest of us: Fumiaki regretting having posted here is a pretty >> stark example of why speaking politely matters. People being scared away >> and feeling unwelcome is a real phenomenon, and we need to do our part to >> fix it. I'd propose: >> >> - If you haven't read it already, SPJ recently wrote a heartfelt >> letter on the subject [0]. We've gotten better since then, but clearly >> we're not finished. >> >> - Civility is a norm, and norms sometimes need to be enforced. From >> a distance, we all look bad (and unwelcoming!) if anyone is hostile and we >> don't make it clear it's not acceptable. Speak up! That said, everyone >> makes mistakes - try to give people space to apologize and move on. >> >> - If someone says something insulting to you, please take that as a >> sign to become more polite, not less so. The downward spiral is real. >> >> >> >> If you're called out for saying something regrettable (again, >> regardless of if you're +1 or -1 on this issue), *please* take our desire >> for civil conversation seriously. Responses like (I'm paraphrasing, and not >> trying to cite anyone specifically): "It was a joke (mostly)" and "It's >> your fault if you didn't get the joke" are worse than not writing anything >> at all. Ideal would be a quick "Sorry!" >> >> Thanks, all! >> >> Tom >> >> >> [0] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html >> >> >> >> >> >> On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita >> wrote: >> >> The discussion has diverged to flaming due to a few offensive people. I >> guess I shouldn't have posted a proposal here, I should have submitted a >> patch instead. >> >> >> >> 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : >> >> It's surprising that they are missing (forgive me, I'm not here to make >> people grumpy). >> >> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> >> _______________________________________________ >> Haskell-community mailing list >> Haskell-community at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.giarrusso at gmail.com Wed Apr 5 16:15:48 2017 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Wed, 5 Apr 2017 18:15:48 +0200 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: Thanks for all the mails, but I'm still missing an answer, so I must have done something wrong. I guess I didn't explain my question well. Or nobody thinks it's worth answering (in which case, sorry, but I'd prefer to be told I'm misguided, over having the question ignored). I'm not asking what length is supposed to do. And I'm especially not trying to argue for a change—I have no new arguments to contribute there. I'm really asking a different question: do length docs actually give a complete specification—it still seems to me they don't. I've given up long ago on proper specifications for library *functions* (beyond types, since they're often not enough)—there, it's less bad, as long as you accept that the implementation is in fact the specification, and information hiding is nowhere in sight. There, proper specs (especially textual one) would be too expensive. But default implementations for typeclass methods are not specs, since you *can* override them. But that's very confusing: can really debate on `length (a, b) = 1` have continued for so long, without noticing that `length = getSum . foldMap (Sum . const 1)` is a fundamental assumption and is not mandated by anything written down? I assume I must be missing something, which is why I asked. Of all incomplete docs, this matters more since `length (a, b)` is so surprising. The unsuspecting looking at docs lacks the facts needed to infer this wart. Spelling out implications would IMHO be even better, for the same reason people state theorems even though they can be proved, but maybe some disagree. A complete spec would be a starting point. Not that anybody has a duty to fix those docs. But if nobody acknowledges docs aren't doing their job, why should anybody attempt a fix? On 3 April 2017 at 17:59, David Feuer wrote: > length should be quite well-behaved relative to foldMap: > > length = getSum . foldMap (Sum . const 1) Thanks, that looks useful to add to docs. I was thinking of `length = length . toList`. > Another law pretty much everyone agrees on is that *if* f is an instance of > Traversable, then > > foldMap = foldMapDefault Cheers, -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/ From ben.franksen at online.de Wed Apr 5 16:18:06 2017 From: ben.franksen at online.de (Ben Franksen) Date: Wed, 5 Apr 2017 18:18:06 +0200 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: Am 03.04.2017 um 22:48 schrieb Sven Panne: > Tuples *are* unbiased, the bias is just an artifact of seeing them as a > curried function, where the positions are "eaten" from left to right. > Again, this mathematically correct, but more often than not the main intent > of using a tuple- Exactly. Currying is nice and convenient but it has an inherent bias. This bias is based on the necessity to choose an order when writing things down in sequence and unavoidable as long as we write programs as linear text. Just because we can curry something doesn't mean we have to give an independent (biased) interpretation to the curried entity. >> We can't just ignore that and pretend they're unbiased. > > We *can* ignore that, just use Henning's Decorated for an isomorphic > variant. And let's not forget Either which IMO should be regarded as an unbiased choice. I don't have a proposal for the name, though. Cheers Ben From eacameron at gmail.com Wed Apr 5 16:22:55 2017 From: eacameron at gmail.com (Elliot Cameron) Date: Wed, 5 Apr 2017 12:22:55 -0400 Subject: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b") In-Reply-To: References: Message-ID: +1 on Tikhon's points as well. Short and sweet. Get to the point. Leave it at that. The bigger it is, the more there is to argue about! On Wed, Apr 5, 2017 at 11:41 AM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > agreed with Tikhon's points, they say it way better than I could > > On Mon, Apr 3, 2017 at 4:52 AM, Tikhon Jelvis wrote: > >> Personally, I would not be against a *short and simple* code of conduct >> that specifically addresses issues we have seen. I'm imagining clear >> guidelines that help people express themselves in a thoughtful and polite >> way. Something in the style of the Hacker News commenting guidelines[1] (at >> least the first four; the rest are specific to HN/Reddit-like sites). >> >> One of the best examples I've seen in the wild had a single rule: no >> personal attacks. It's simple to understand and follow with no risk of >> stifling or derailing real discussions, and yet unambiguously rules out the >> majority of rude comments I see online (ignoring spam and outright >> trolling). >> >> I do *not* like Rust's code of conduct specifically. It does not provide >> clear guidelines on civility/politeness and covers too many other things, >> including a lot of (often political) baggage. Why is the idea that >> "everything is a tradeoff" enshrined as a rule? The rule on politeness is >> clearly deemphasized: "Please be kind and courteous. There’s no need to be >> mean or rude." is so vague it may as well not be in the code of conduct. We >> should *assume* people set out to be kind and courteous and help them do >> that consistently. The "Citizen Code of Conduct" they link to has even more >> baggage and I believe it should *not* serve as the basis for anything we >> might adopt as a community. >> >> [1]: https://news.ycombinator.com/newsguidelines.html see section "In >> Comments" >> >> On Mon, Apr 3, 2017 at 1:13 AM, Simon Peyton Jones via Haskell-community >> wrote: >> >>> Friends >>> >>> >>> >>> I second what Tom says below. >>> >>> >>> >>> Almost everyone expresses their views with respect, even when >>> disagreeing. The exceptions are (in my guess) mostly unintentional, at >>> least in the extent of the offence caused. That does not make them >>> unimportant, because a slow slippage in our collective standards is, over >>> time corrosive. But it does mean that we can draw breath, as Tom has >>> helpfully done here, and without condemning anyone reset our standards. >>> >>> >>> >>> I’ve been talking to a couple of people about whether it would be useful >>> to have an explicit Haskell Community Code of Conduct. Many online >>> communities have one (e.g. Rust >>> ), and it might be >>> helpful for everyone to have a concrete baseline rather than an unwritten >>> standard. Any views on that? >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of *Tom >>> Murphy >>> *Sent:* 02 April 2017 19:18 >>> *To:* Fumiaki Kinoshita >>> *Cc:* libraries >>> *Subject:* Civility notes (was "Traversable instances for (,,) a b") >>> >>> >>> >>> Hi Fumiaki! >>> >>> I agree with you that some poorly-chosen words by a few people have >>> soured this conversation, but please don't let that turn you completely off >>> of the productive conversation most of us are attempting to have! I think >>> it's largely been successful, too: even if many of us haven't changed our >>> -1/+1 votes, I for one have had my ideas challenged and have a more nuanced >>> view than before talking with everyone here. >>> >>> Henning and Edward are two examples (one from each side of the >>> +1/-1 chasm) who have been aided by this discussion, in making important >>> progress to finding a middle ground (each in the form of proposed compiler >>> changes). >>> >>> To the rest of us: Fumiaki regretting having posted here is a >>> pretty stark example of why speaking politely matters. People being scared >>> away and feeling unwelcome is a real phenomenon, and we need to do our part >>> to fix it. I'd propose: >>> >>> - If you haven't read it already, SPJ recently wrote a heartfelt >>> letter on the subject [0]. We've gotten better since then, but clearly >>> we're not finished. >>> >>> - Civility is a norm, and norms sometimes need to be enforced. From >>> a distance, we all look bad (and unwelcoming!) if anyone is hostile and we >>> don't make it clear it's not acceptable. Speak up! That said, everyone >>> makes mistakes - try to give people space to apologize and move on. >>> >>> - If someone says something insulting to you, please take that as a >>> sign to become more polite, not less so. The downward spiral is real. >>> >>> >>> >>> If you're called out for saying something regrettable (again, >>> regardless of if you're +1 or -1 on this issue), *please* take our desire >>> for civil conversation seriously. Responses like (I'm paraphrasing, and not >>> trying to cite anyone specifically): "It was a joke (mostly)" and "It's >>> your fault if you didn't get the joke" are worse than not writing anything >>> at all. Ideal would be a quick "Sorry!" >>> >>> Thanks, all! >>> >>> Tom >>> >>> >>> [0] https://mail.haskell.org/pipermail/haskell/2016-September/02 >>> 4995.html >>> >>> >>> >>> >>> >>> On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita >>> wrote: >>> >>> The discussion has diverged to flaming due to a few offensive people. I >>> guess I shouldn't have posted a proposal here, I should have submitted a >>> patch instead. >>> >>> >>> >>> 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : >>> >>> It's surprising that they are missing (forgive me, I'm not here to make >>> people grumpy). >>> >>> >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >>> >>> _______________________________________________ >>> Haskell-community mailing list >>> Haskell-community at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>> >>> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.giarrusso at gmail.com Wed Apr 5 16:44:49 2017 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Wed, 5 Apr 2017 18:44:49 +0200 Subject: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b") In-Reply-To: References: Message-ID: Rust's code of conduct (and the conduct of leaders) have been very successful at creating a welcoming community. However, those rules were there from the start. What's crucial is that a code of conduct is really agreed upon by a community and its elders. So thanks to Simon Peyton Jones for starting this conversation. In particular, a CoC to address known issues (not just in the present discussion) would probably be easier to agree on. > We should *assume* people set out to be kind and courteous and help them do that consistently. The guideline I find useful is "assume good faith" (used for instance in Wikipedia), as long as you don't have extraordinary evidence. And that's a guidelines that needs to be stated. Opinions on politeness in the wild are much more varied. How polite do you need to be, if somebody insists on being wrong? And with actual trolls? > Why is the idea that "everything is a tradeoff" enshrined as a rule? I don't know if it's a strict rule there, how strict it should be, or whether it works in a CoC. But I find it a very good guideline for educated debate. I learned it (implicitly) in my academic PL training: PL design is founded on math but is no science yet. Debate in hard sciences is different. Because this rule is in fact fundamental to establish respect under disagreement. The Rust CoC says "There is *seldom* a right answer." If a question has a right answer, the others become wrong, misguided, heretics, .... idiots... OK, you can censor the word "idiot", but that won't help much. Or you can admit that reasonable people might disagree on `Foldable ((,) a)` (as most already agree), and give that as a guideline, just as "assume good faith". That doesn't make "2 + 2 = 5" legitimate of course—some "common sense" is still needed. "There is *seldom* a right answer" is an unstated rule in academic papers (where it's implied by peer review), and it IMHO works rather well there, even on the few academics who will loudly proclaim elsewhere there is a right answer. Indeed, I don't want to misrepresent SPJ, but I feel he is often happy to talk about Haskell tradeoffs when they're there, even when others loudly proclaim Haskell is strictly and clearly better than X. Cheers, Paolo On Apr 3, 2017 10:55, "Tikhon Jelvis" wrote: > Personally, I would not be against a *short and simple* code of conduct > that specifically addresses issues we have seen. I'm imagining clear > guidelines that help people express themselves in a thoughtful and polite > way. Something in the style of the Hacker News commenting guidelines[1] (at > least the first four; the rest are specific to HN/Reddit-like sites). > > One of the best examples I've seen in the wild had a single rule: no > personal attacks. It's simple to understand and follow with no risk of > stifling or derailing real discussions, and yet unambiguously rules out the > majority of rude comments I see online (ignoring spam and outright > trolling). > > I do *not* like Rust's code of conduct specifically. It does not provide > clear guidelines on civility/politeness and covers too many other things, > including a lot of (often political) baggage. Why is the idea that > "everything is a tradeoff" enshrined as a rule? The rule on politeness is > clearly deemphasized: "Please be kind and courteous. There’s no need to be > mean or rude." is so vague it may as well not be in the code of conduct. We > should *assume* people set out to be kind and courteous and help them do > that consistently. The "Citizen Code of Conduct" they link to has even more > baggage and I believe it should *not* serve as the basis for anything we > might adopt as a community. > > [1]: https://news.ycombinator.com/newsguidelines.html see section "In > Comments" > > On Mon, Apr 3, 2017 at 1:13 AM, Simon Peyton Jones via Haskell-community < > haskell-community at haskell.org> wrote: > >> Friends >> >> >> >> I second what Tom says below. >> >> >> >> Almost everyone expresses their views with respect, even when >> disagreeing. The exceptions are (in my guess) mostly unintentional, at >> least in the extent of the offence caused. That does not make them >> unimportant, because a slow slippage in our collective standards is, over >> time corrosive. But it does mean that we can draw breath, as Tom has >> helpfully done here, and without condemning anyone reset our standards. >> >> >> >> I’ve been talking to a couple of people about whether it would be useful >> to have an explicit Haskell Community Code of Conduct. Many online >> communities have one (e.g. Rust >> ), and it might be helpful >> for everyone to have a concrete baseline rather than an unwritten >> standard. Any views on that? >> >> >> >> Simon >> >> >> >> *From:* Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of *Tom >> Murphy >> *Sent:* 02 April 2017 19:18 >> *To:* Fumiaki Kinoshita >> *Cc:* libraries >> *Subject:* Civility notes (was "Traversable instances for (,,) a b") >> >> >> >> Hi Fumiaki! >> >> I agree with you that some poorly-chosen words by a few people have >> soured this conversation, but please don't let that turn you completely off >> of the productive conversation most of us are attempting to have! I think >> it's largely been successful, too: even if many of us haven't changed our >> -1/+1 votes, I for one have had my ideas challenged and have a more nuanced >> view than before talking with everyone here. >> >> Henning and Edward are two examples (one from each side of the +1/-1 >> chasm) who have been aided by this discussion, in making important progress >> to finding a middle ground (each in the form of proposed compiler changes). >> >> To the rest of us: Fumiaki regretting having posted here is a pretty >> stark example of why speaking politely matters. People being scared away >> and feeling unwelcome is a real phenomenon, and we need to do our part to >> fix it. I'd propose: >> >> - If you haven't read it already, SPJ recently wrote a heartfelt >> letter on the subject [0]. We've gotten better since then, but clearly >> we're not finished. >> >> - Civility is a norm, and norms sometimes need to be enforced. From >> a distance, we all look bad (and unwelcoming!) if anyone is hostile and we >> don't make it clear it's not acceptable. Speak up! That said, everyone >> makes mistakes - try to give people space to apologize and move on. >> >> - If someone says something insulting to you, please take that as a >> sign to become more polite, not less so. The downward spiral is real. >> >> >> >> If you're called out for saying something regrettable (again, >> regardless of if you're +1 or -1 on this issue), *please* take our desire >> for civil conversation seriously. Responses like (I'm paraphrasing, and not >> trying to cite anyone specifically): "It was a joke (mostly)" and "It's >> your fault if you didn't get the joke" are worse than not writing anything >> at all. Ideal would be a quick "Sorry!" >> >> Thanks, all! >> >> Tom >> >> >> [0] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html >> >> >> >> >> >> On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita >> wrote: >> >> The discussion has diverged to flaming due to a few offensive people. I >> guess I shouldn't have posted a proposal here, I should have submitted a >> patch instead. >> >> >> >> 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : >> >> It's surprising that they are missing (forgive me, I'm not here to make >> people grumpy). >> >> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> >> _______________________________________________ >> Haskell-community mailing list >> Haskell-community at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >> >> > > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Wed Apr 5 18:54:00 2017 From: amindfv at gmail.com (amindfv at gmail.com) Date: Wed, 5 Apr 2017 13:54:00 -0500 Subject: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b") In-Reply-To: References: Message-ID: I'm also +1 to a CoC, although have less of an opinion on what shape it should take. CoCs are an effective way of making people who may feel like outsiders to a community feel more welcome. The Haskell community is amazing and inclusive but not the most diverse, and projects which are doing better on that front largely all have CoCs. In terms of what shape it takes: there are lots of off-the-shelf ones for different needs: I'd suggest picking one of them. Tom > El 5 abr 2017, a las 11:44, Paolo Giarrusso escribió: > > Rust's code of conduct (and the conduct of leaders) have been very successful at creating a welcoming community. However, those rules were there from the start. > > What's crucial is that a code of conduct is really agreed upon by a community and its elders. So thanks to Simon Peyton Jones for starting this conversation. > In particular, a CoC to address known issues (not just in the present discussion) would probably be easier to agree on. > > > We should *assume* people set out to be kind and courteous and help them do that consistently. > > The guideline I find useful is "assume good faith" (used for instance in Wikipedia), as long as you don't have extraordinary evidence. And that's a guidelines that needs to be stated. > Opinions on politeness in the wild are much more varied. How polite do you need to be, if somebody insists on being wrong? And with actual trolls? > > > Why is the idea that "everything is a tradeoff" enshrined as a rule? > > I don't know if it's a strict rule there, how strict it should be, or whether it works in a CoC. But I find it a very good guideline for educated debate. I learned it (implicitly) in my academic PL training: PL design is founded on math but is no science yet. Debate in hard sciences is different. > > Because this rule is in fact fundamental to establish respect under disagreement. The Rust CoC says "There is *seldom* a right answer." If a question has a right answer, the others become wrong, misguided, heretics, .... idiots... OK, you can censor the word "idiot", but that won't help much. Or you can admit that reasonable people might disagree on `Foldable ((,) a)` (as most already agree), and give that as a guideline, just as "assume good faith". That doesn't make "2 + 2 = 5" legitimate of course—some "common sense" is still needed. > > "There is *seldom* a right answer" is an unstated rule in academic papers (where it's implied by peer review), and it IMHO works rather well there, even on the few academics who will loudly proclaim elsewhere there is a right answer. > > Indeed, I don't want to misrepresent SPJ, but I feel he is often happy to talk about Haskell tradeoffs when they're there, even when others loudly proclaim Haskell is strictly and clearly better than X. > > Cheers, > Paolo > >> On Apr 3, 2017 10:55, "Tikhon Jelvis" wrote: >> Personally, I would not be against a *short and simple* code of conduct that specifically addresses issues we have seen. I'm imagining clear guidelines that help people express themselves in a thoughtful and polite way. Something in the style of the Hacker News commenting guidelines[1] (at least the first four; the rest are specific to HN/Reddit-like sites). >> >> One of the best examples I've seen in the wild had a single rule: no personal attacks. It's simple to understand and follow with no risk of stifling or derailing real discussions, and yet unambiguously rules out the majority of rude comments I see online (ignoring spam and outright trolling). >> >> I do *not* like Rust's code of conduct specifically. It does not provide clear guidelines on civility/politeness and covers too many other things, including a lot of (often political) baggage. Why is the idea that "everything is a tradeoff" enshrined as a rule? The rule on politeness is clearly deemphasized: "Please be kind and courteous. There’s no need to be mean or rude." is so vague it may as well not be in the code of conduct. We should *assume* people set out to be kind and courteous and help them do that consistently. The "Citizen Code of Conduct" they link to has even more baggage and I believe it should *not* serve as the basis for anything we might adopt as a community. >> >> [1]: https://news.ycombinator.com/newsguidelines.html see section "In Comments" >> >>> On Mon, Apr 3, 2017 at 1:13 AM, Simon Peyton Jones via Haskell-community wrote: >>> Friends >>> >>> >>> >>> I second what Tom says below. >>> >>> >>> >>> Almost everyone expresses their views with respect, even when disagreeing. The exceptions are (in my guess) mostly unintentional, at least in the extent of the offence caused. That does not make them unimportant, because a slow slippage in our collective standards is, over time corrosive. But it does mean that we can draw breath, as Tom has helpfully done here, and without condemning anyone reset our standards. >>> >>> >>> >>> I’ve been talking to a couple of people about whether it would be useful to have an explicit Haskell Community Code of Conduct. Many online communities have one (e.g. Rust), and it might be helpful for everyone to have a concrete baseline rather than an unwritten standard. Any views on that? >>> >>> >>> >>> Simon >>> >>> >>> >>> From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Tom Murphy >>> Sent: 02 April 2017 19:18 >>> To: Fumiaki Kinoshita >>> Cc: libraries >>> Subject: Civility notes (was "Traversable instances for (,,) a b") >>> >>> >>> >>> Hi Fumiaki! >>> >>> I agree with you that some poorly-chosen words by a few people have soured this conversation, but please don't let that turn you completely off of the productive conversation most of us are attempting to have! I think it's largely been successful, too: even if many of us haven't changed our -1/+1 votes, I for one have had my ideas challenged and have a more nuanced view than before talking with everyone here. >>> Henning and Edward are two examples (one from each side of the +1/-1 chasm) who have been aided by this discussion, in making important progress to finding a middle ground (each in the form of proposed compiler changes). >>> >>> To the rest of us: Fumiaki regretting having posted here is a pretty stark example of why speaking politely matters. People being scared away and feeling unwelcome is a real phenomenon, and we need to do our part to fix it. I'd propose: >>> >>> - If you haven't read it already, SPJ recently wrote a heartfelt letter on the subject [0]. We've gotten better since then, but clearly we're not finished. >>> - Civility is a norm, and norms sometimes need to be enforced. From a distance, we all look bad (and unwelcoming!) if anyone is hostile and we don't make it clear it's not acceptable. Speak up! That said, everyone makes mistakes - try to give people space to apologize and move on. >>> - If someone says something insulting to you, please take that as a sign to become more polite, not less so. The downward spiral is real. >>> >>> If you're called out for saying something regrettable (again, regardless of if you're +1 or -1 on this issue), *please* take our desire for civil conversation seriously. Responses like (I'm paraphrasing, and not trying to cite anyone specifically): "It was a joke (mostly)" and "It's your fault if you didn't get the joke" are worse than not writing anything at all. Ideal would be a quick "Sorry!" >>> >>> Thanks, all! >>> Tom >>> >>> [0] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html >>> >>> >>> >>> On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita wrote: >>> The discussion has diverged to flaming due to a few offensive people. I guess I shouldn't have posted a proposal here, I should have submitted a patch instead. >>> >>> 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : >>> It's surprising that they are missing (forgive me, I'm not here to make people grumpy). >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >>> >>> _______________________________________________ >>> Haskell-community mailing list >>> Haskell-community at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >> >> >> _______________________________________________ >> Haskell-community mailing list >> Haskell-community at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community -------------- next part -------------- An HTML attachment was scrubbed... URL: From nbouscal at gmail.com Wed Apr 5 17:56:13 2017 From: nbouscal at gmail.com (Nathan Bouscal) Date: Wed, 5 Apr 2017 10:56:13 -0700 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: On Wed, Apr 5, 2017 at 9:18 AM, Ben Franksen wrote: > Am 03.04.2017 um 22:48 schrieb Sven Panne: > > Tuples *are* unbiased, the bias is just an artifact of seeing them as a > > curried function, where the positions are "eaten" from left to right. > > Again, this mathematically correct, but more often than not the main > intent > > of using a tuple- > > Exactly. Currying is nice and convenient but it has an inherent bias. > This bias is based on the necessity to choose an order when writing > things down in sequence and unavoidable as long as we write programs as > linear text. > Just because we can curry something doesn't mean we have to give an > independent (biased) interpretation to the curried entity. > As Vladislav showed earlier, the bias is not just the order that things are written in. It is impossible (in Haskell as it exists) to make a Functor instance for (,b). It's not about interpretation, it's part of how the language works. > > >> We can't just ignore that and pretend they're unbiased. > > > > We *can* ignore that, just use Henning's Decorated for an isomorphic > > variant. > > And let's not forget Either which IMO should be regarded as an unbiased > choice. I don't have a proposal for the name, though. > > Cheers > Ben > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Wed Apr 5 18:15:07 2017 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 5 Apr 2017 20:15:07 +0200 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: 2017-04-05 18:18 GMT+02:00 Ben Franksen : > And let's not forget Either which IMO should be regarded as an unbiased > choice. I don't have a proposal for the name, though. > In the dark ages of Haskell's library design, i.e. a long, long time ago, in a distant past, the time where people could actually write significant code without using at least 20 LANGUAGE pragmas ;-), we discussed this already, see e.g. the thread starting at http://code.haskell.org/~dons/haskell-1990-2000/msg07215.html. The final outcome was: Although something like Error/OK would have been better than Left/Right, a slight majority preferred to give a bias to Either. The reasoning was that using "Right" for a "wrong" outcome (i.e. failure) would be a bit obscure, and there was already quite some code using it in the way we still do today. The bias is even explicitly documented in the Haddock docs for Data.Either for ages, so it would not be very wise to change the meaning here after roughly 2 decades. Of course the question remains: What is the totally unbiased standard sum type for 2 alternatives? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub.daniel at gmail.com Wed Apr 5 18:20:32 2017 From: jakub.daniel at gmail.com (Jakub Daniel) Date: Wed, 5 Apr 2017 20:20:32 +0200 Subject: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b") In-Reply-To: References: Message-ID: <9616319F-1D7E-488F-BEAC-68E9577B96CE@gmail.com> What is the expected effect/role of CoC? Is it expected that people would actually exhibit different behaviour because of a document? Is there a reason to believe good behaviour in other communities come from existing CoCs? I honestly doubt people prone to violate such rules tend to read such documents and since there is no way to enforce it, what point is there? Isn't the effort to maintain such a document just a waste? > On 5 Apr 2017, at 20:54, amindfv at gmail.com wrote: > > I'm also +1 to a CoC, although have less of an opinion on what shape it should take. CoCs are an effective way of making people who may feel like outsiders to a community feel more welcome. The Haskell community is amazing and inclusive but not the most diverse, and projects which are doing better on that front largely all have CoCs. > > In terms of what shape it takes: there are lots of off-the-shelf ones for different needs: I'd suggest picking one of them. > > Tom > > >> El 5 abr 2017, a las 11:44, Paolo Giarrusso escribió: >> >> Rust's code of conduct (and the conduct of leaders) have been very successful at creating a welcoming community. However, those rules were there from the start. >> >> What's crucial is that a code of conduct is really agreed upon by a community and its elders. So thanks to Simon Peyton Jones for starting this conversation. >> In particular, a CoC to address known issues (not just in the present discussion) would probably be easier to agree on. >> >> > We should *assume* people set out to be kind and courteous and help them do that consistently. >> >> The guideline I find useful is "assume good faith" (used for instance in Wikipedia), as long as you don't have extraordinary evidence. And that's a guidelines that needs to be stated. >> Opinions on politeness in the wild are much more varied. How polite do you need to be, if somebody insists on being wrong? And with actual trolls? >> >> > Why is the idea that "everything is a tradeoff" enshrined as a rule? >> >> I don't know if it's a strict rule there, how strict it should be, or whether it works in a CoC. But I find it a very good guideline for educated debate. I learned it (implicitly) in my academic PL training: PL design is founded on math but is no science yet. Debate in hard sciences is different. >> >> Because this rule is in fact fundamental to establish respect under disagreement. The Rust CoC says "There is *seldom* a right answer." If a question has a right answer, the others become wrong, misguided, heretics, .... idiots... OK, you can censor the word "idiot", but that won't help much. Or you can admit that reasonable people might disagree on `Foldable ((,) a)` (as most already agree), and give that as a guideline, just as "assume good faith". That doesn't make "2 + 2 = 5" legitimate of course—some "common sense" is still needed. >> >> "There is *seldom* a right answer" is an unstated rule in academic papers (where it's implied by peer review), and it IMHO works rather well there, even on the few academics who will loudly proclaim elsewhere there is a right answer. >> >> Indeed, I don't want to misrepresent SPJ, but I feel he is often happy to talk about Haskell tradeoffs when they're there, even when others loudly proclaim Haskell is strictly and clearly better than X. >> >> Cheers, >> Paolo >> >>> On Apr 3, 2017 10:55, "Tikhon Jelvis" wrote: >>> Personally, I would not be against a *short and simple* code of conduct that specifically addresses issues we have seen. I'm imagining clear guidelines that help people express themselves in a thoughtful and polite way. Something in the style of the Hacker News commenting guidelines[1] (at least the first four; the rest are specific to HN/Reddit-like sites). >>> >>> One of the best examples I've seen in the wild had a single rule: no personal attacks. It's simple to understand and follow with no risk of stifling or derailing real discussions, and yet unambiguously rules out the majority of rude comments I see online (ignoring spam and outright trolling). >>> >>> I do *not* like Rust's code of conduct specifically. It does not provide clear guidelines on civility/politeness and covers too many other things, including a lot of (often political) baggage. Why is the idea that "everything is a tradeoff" enshrined as a rule? The rule on politeness is clearly deemphasized: "Please be kind and courteous. There’s no need to be mean or rude." is so vague it may as well not be in the code of conduct. We should *assume* people set out to be kind and courteous and help them do that consistently. The "Citizen Code of Conduct" they link to has even more baggage and I believe it should *not* serve as the basis for anything we might adopt as a community. >>> >>> [1]: https://news.ycombinator.com/newsguidelines.html see section "In Comments" >>> >>>> On Mon, Apr 3, 2017 at 1:13 AM, Simon Peyton Jones via Haskell-community wrote: >>>> Friends >>>> >>>> >>>> >>>> I second what Tom says below. >>>> >>>> >>>> >>>> Almost everyone expresses their views with respect, even when disagreeing. The exceptions are (in my guess) mostly unintentional, at least in the extent of the offence caused. That does not make them unimportant, because a slow slippage in our collective standards is, over time corrosive. But it does mean that we can draw breath, as Tom has helpfully done here, and without condemning anyone reset our standards. >>>> >>>> >>>> >>>> I’ve been talking to a couple of people about whether it would be useful to have an explicit Haskell Community Code of Conduct. Many online communities have one (e.g. Rust), and it might be helpful for everyone to have a concrete baseline rather than an unwritten standard. Any views on that? >>>> >>>> >>>> >>>> Simon >>>> >>>> >>>> >>>> From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Tom Murphy >>>> Sent: 02 April 2017 19:18 >>>> To: Fumiaki Kinoshita >>>> Cc: libraries >>>> Subject: Civility notes (was "Traversable instances for (,,) a b") >>>> >>>> >>>> >>>> Hi Fumiaki! >>>> >>>> I agree with you that some poorly-chosen words by a few people have soured this conversation, but please don't let that turn you completely off of the productive conversation most of us are attempting to have! I think it's largely been successful, too: even if many of us haven't changed our -1/+1 votes, I for one have had my ideas challenged and have a more nuanced view than before talking with everyone here. >>>> >>>> Henning and Edward are two examples (one from each side of the +1/-1 chasm) who have been aided by this discussion, in making important progress to finding a middle ground (each in the form of proposed compiler changes). >>>> >>>> To the rest of us: Fumiaki regretting having posted here is a pretty stark example of why speaking politely matters. People being scared away and feeling unwelcome is a real phenomenon, and we need to do our part to fix it. I'd propose: >>>> >>>> - If you haven't read it already, SPJ recently wrote a heartfelt letter on the subject [0]. We've gotten better since then, but clearly we're not finished. >>>> >>>> - Civility is a norm, and norms sometimes need to be enforced. From a distance, we all look bad (and unwelcoming!) if anyone is hostile and we don't make it clear it's not acceptable. Speak up! That said, everyone makes mistakes - try to give people space to apologize and move on. >>>> >>>> - If someone says something insulting to you, please take that as a sign to become more polite, not less so. The downward spiral is real. >>>> >>>> >>>> >>>> If you're called out for saying something regrettable (again, regardless of if you're +1 or -1 on this issue), *please* take our desire for civil conversation seriously. Responses like (I'm paraphrasing, and not trying to cite anyone specifically): "It was a joke (mostly)" and "It's your fault if you didn't get the joke" are worse than not writing anything at all. Ideal would be a quick "Sorry!" >>>> >>>> Thanks, all! >>>> >>>> Tom >>>> >>>> >>>> [0] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html >>>> >>>> >>>> >>>> >>>> >>>> On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita wrote: >>>> >>>> The discussion has diverged to flaming due to a few offensive people. I guess I shouldn't have posted a proposal here, I should have submitted a patch instead. >>>> >>>> >>>> >>>> 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : >>>> >>>> It's surprising that they are missing (forgive me, I'm not here to make people grumpy). >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Haskell-community mailing list >>>> Haskell-community at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>>> >>> >>> >>> _______________________________________________ >>> Haskell-community mailing list >>> Haskell-community at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>> >> _______________________________________________ >> Haskell-community mailing list >> Haskell-community at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From jays at panix.com Wed Apr 5 20:00:19 2017 From: jays at panix.com (Jay Sulzberger) Date: Wed, 5 Apr 2017 16:00:19 -0400 (EDT) Subject: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b") In-Reply-To: <9616319F-1D7E-488F-BEAC-68E9577B96CE@gmail.com> References: <9616319F-1D7E-488F-BEAC-68E9577B96CE@gmail.com> Message-ID: On Wed, 5 Apr 2017, Jakub Daniel wrote: > What is the expected effect/role of CoC? Is it expected that > people would actually exhibit different behaviour because of a > document? Is there a reason to believe good behaviour in other > communities come from existing CoCs? I honestly doubt people > prone to violate such rules tend to read such documents and > since there is no way to enforce it, what point is there? Isn't > the effort to maintain such a document just a waste? The advantage of a formal published code of conduct is that when a violation, or supected violation, occurs the ad hoc discussion, which is often acrimonious, can be cut short by pointing to the formal document. oo--JS. > >> On 5 Apr 2017, at 20:54, amindfv at gmail.com wrote: >> >> I'm also +1 to a CoC, although have less of an opinion on what shape it should take. CoCs are an effective way of making people who may feel like outsiders to a community feel more welcome. The Haskell community is amazing and inclusive but not the most diverse, and projects which are doing better on that front largely all have CoCs. >> >> In terms of what shape it takes: there are lots of off-the-shelf ones for different needs: I'd suggest picking one of them. >> >> Tom >> >> >>> El 5 abr 2017, a las 11:44, Paolo Giarrusso escribió: >>> >>> Rust's code of conduct (and the conduct of leaders) have been very successful at creating a welcoming community. However, those rules were there from the start. >>> >>> What's crucial is that a code of conduct is really agreed upon by a community and its elders. So thanks to Simon Peyton Jones for starting this conversation. >>> In particular, a CoC to address known issues (not just in the present discussion) would probably be easier to agree on. >>> >>>> We should *assume* people set out to be kind and courteous and help them do that consistently. >>> >>> The guideline I find useful is "assume good faith" (used for instance in Wikipedia), as long as you don't have extraordinary evidence. And that's a guidelines that needs to be stated. >>> Opinions on politeness in the wild are much more varied. How polite do you need to be, if somebody insists on being wrong? And with actual trolls? >>> >>>> Why is the idea that "everything is a tradeoff" enshrined as a rule? >>> >>> I don't know if it's a strict rule there, how strict it should be, or whether it works in a CoC. But I find it a very good guideline for educated debate. I learned it (implicitly) in my academic PL training: PL design is founded on math but is no science yet. Debate in hard sciences is different. >>> >>> Because this rule is in fact fundamental to establish respect under disagreement. The Rust CoC says "There is *seldom* a right answer." If a question has a right answer, the others become wrong, misguided, heretics, .... idiots... OK, you can censor the word "idiot", but that won't help much. Or you can admit that reasonable people might disagree on `Foldable ((,) a)` (as most already agree), and give that as a guideline, just as "assume good faith". That doesn't make "2 + 2 = 5" legitimate of course—some "common sense" is still needed. >>> >>> "There is *seldom* a right answer" is an unstated rule in academic papers (where it's implied by peer review), and it IMHO works rather well there, even on the few academics who will loudly proclaim elsewhere there is a right answer. >>> >>> Indeed, I don't want to misrepresent SPJ, but I feel he is often happy to talk about Haskell tradeoffs when they're there, even when others loudly proclaim Haskell is strictly and clearly better than X. >>> >>> Cheers, >>> Paolo >>> >>>> On Apr 3, 2017 10:55, "Tikhon Jelvis" wrote: >>>> Personally, I would not be against a *short and simple* code of conduct that specifically addresses issues we have seen. I'm imagining clear guidelines that help people express themselves in a thoughtful and polite way. Something in the style of the Hacker News commenting guidelines[1] (at least the first four; the rest are specific to HN/Reddit-like sites). >>>> >>>> One of the best examples I've seen in the wild had a single rule: no personal attacks. It's simple to understand and follow with no risk of stifling or derailing real discussions, and yet unambiguously rules out the majority of rude comments I see online (ignoring spam and outright trolling). >>>> >>>> I do *not* like Rust's code of conduct specifically. It does not provide clear guidelines on civility/politeness and covers too many other things, including a lot of (often political) baggage. Why is the idea that "everything is a tradeoff" enshrined as a rule? The rule on politeness is clearly deemphasized: "Please be kind and courteous. There’s no need to be mean or rude." is so vague it may as well not be in the code of conduct. We should *assume* people set out to be kind and courteous and help them do that consistently. The "Citizen Code of Conduct" they link to has even more baggage and I believe it should *not* serve as the basis for anything we might adopt as a community. >>>> >>>> [1]: https://news.ycombinator.com/newsguidelines.html see section "In Comments" >>>> >>>>> On Mon, Apr 3, 2017 at 1:13 AM, Simon Peyton Jones via Haskell-community wrote: >>>>> Friends >>>>> >>>>> >>>>> >>>>> I second what Tom says below. >>>>> >>>>> >>>>> >>>>> Almost everyone expresses their views with respect, even when disagreeing. The exceptions are (in my guess) mostly unintentional, at least in the extent of the offence caused. That does not make them unimportant, because a slow slippage in our collective standards is, over time corrosive. But it does mean that we can draw breath, as Tom has helpfully done here, and without condemning anyone reset our standards. >>>>> >>>>> >>>>> >>>>> I’ve been talking to a couple of people about whether it would be useful to have an explicit Haskell Community Code of Conduct. Many online communities have one (e.g. Rust), and it might be helpful for everyone to have a concrete baseline rather than an unwritten standard. Any views on that? >>>>> >>>>> >>>>> >>>>> Simon >>>>> >>>>> >>>>> >>>>> From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Tom Murphy >>>>> Sent: 02 April 2017 19:18 >>>>> To: Fumiaki Kinoshita >>>>> Cc: libraries >>>>> Subject: Civility notes (was "Traversable instances for (,,) a b") >>>>> >>>>> >>>>> >>>>> Hi Fumiaki! >>>>> >>>>> I agree with you that some poorly-chosen words by a few people have soured this conversation, but please don't let that turn you completely off of the productive conversation most of us are attempting to have! I think it's largely been successful, too: even if many of us haven't changed our -1/+1 votes, I for one have had my ideas challenged and have a more nuanced view than before talking with everyone here. >>>>> >>>>> Henning and Edward are two examples (one from each side of the +1/-1 chasm) who have been aided by this discussion, in making important progress to finding a middle ground (each in the form of proposed compiler changes). >>>>> >>>>> To the rest of us: Fumiaki regretting having posted here is a pretty stark example of why speaking politely matters. People being scared away and feeling unwelcome is a real phenomenon, and we need to do our part to fix it. I'd propose: >>>>> >>>>> - If you haven't read it already, SPJ recently wrote a heartfelt letter on the subject [0]. We've gotten better since then, but clearly we're not finished. >>>>> >>>>> - Civility is a norm, and norms sometimes need to be enforced. From a distance, we all look bad (and unwelcoming!) if anyone is hostile and we don't make it clear it's not acceptable. Speak up! That said, everyone makes mistakes - try to give people space to apologize and move on. >>>>> >>>>> - If someone says something insulting to you, please take that as a sign to become more polite, not less so. The downward spiral is real. >>>>> >>>>> >>>>> >>>>> If you're called out for saying something regrettable (again, regardless of if you're +1 or -1 on this issue), *please* take our desire for civil conversation seriously. Responses like (I'm paraphrasing, and not trying to cite anyone specifically): "It was a joke (mostly)" and "It's your fault if you didn't get the joke" are worse than not writing anything at all. Ideal would be a quick "Sorry!" >>>>> >>>>> Thanks, all! >>>>> >>>>> Tom >>>>> >>>>> >>>>> [0] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita wrote: >>>>> >>>>> The discussion has diverged to flaming due to a few offensive people. I guess I shouldn't have posted a proposal here, I should have submitted a patch instead. >>>>> >>>>> >>>>> >>>>> 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : >>>>> >>>>> It's surprising that they are missing (forgive me, I'm not here to make people grumpy). >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Haskell-community mailing list >>>>> Haskell-community at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Haskell-community mailing list >>>> Haskell-community at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>>> >>> _______________________________________________ >>> Haskell-community mailing list >>> Haskell-community at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From amindfv at gmail.com Thu Apr 6 00:25:14 2017 From: amindfv at gmail.com (amindfv at gmail.com) Date: Wed, 5 Apr 2017 19:25:14 -0500 Subject: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b") In-Reply-To: <9616319F-1D7E-488F-BEAC-68E9577B96CE@gmail.com> References: <9616319F-1D7E-488F-BEAC-68E9577B96CE@gmail.com> Message-ID: <15DE6EAB-A68B-46CE-B0AF-D8E6F665DFDE@gmail.com> > El 5 abr 2017, a las 13:20, Jakub Daniel escribió: > > What is the expected effect/role of CoC? Is it expected that people would actually exhibit different behaviour because of a document? Is there a reason to believe good behaviour in other communities come from existing CoCs? I honestly doubt people prone to violate such rules tend to read such documents and since there is no way to enforce it, what point is there? If you'll forgive a strained metaphor: imagine you arrive in an unfamiliar land, one which has a reputation for the occasional food fight. You're wearing nice clothes and don't want your day ruined by getting food on them. Some restaurants have a big sign out front: "Absolutely NO food fighting. Anyone caught food fighting will be ejected". Other restaurants don't have the sign. When picking a place to eat, aren't you likely to gravitate to a restaurant which has a sign? > Isn't the effort to maintain such a document just a waste? Hopefully it'll be very low-maintenance! Tom > >> On 5 Apr 2017, at 20:54, amindfv at gmail.com wrote: >> >> I'm also +1 to a CoC, although have less of an opinion on what shape it should take. CoCs are an effective way of making people who may feel like outsiders to a community feel more welcome. The Haskell community is amazing and inclusive but not the most diverse, and projects which are doing better on that front largely all have CoCs. >> >> In terms of what shape it takes: there are lots of off-the-shelf ones for different needs: I'd suggest picking one of them. >> >> Tom >> >> >>> El 5 abr 2017, a las 11:44, Paolo Giarrusso escribió: >>> >>> Rust's code of conduct (and the conduct of leaders) have been very successful at creating a welcoming community. However, those rules were there from the start. >>> >>> What's crucial is that a code of conduct is really agreed upon by a community and its elders. So thanks to Simon Peyton Jones for starting this conversation. >>> In particular, a CoC to address known issues (not just in the present discussion) would probably be easier to agree on. >>> >>> > We should *assume* people set out to be kind and courteous and help them do that consistently. >>> >>> The guideline I find useful is "assume good faith" (used for instance in Wikipedia), as long as you don't have extraordinary evidence. And that's a guidelines that needs to be stated. >>> Opinions on politeness in the wild are much more varied. How polite do you need to be, if somebody insists on being wrong? And with actual trolls? >>> >>> > Why is the idea that "everything is a tradeoff" enshrined as a rule? >>> >>> I don't know if it's a strict rule there, how strict it should be, or whether it works in a CoC. But I find it a very good guideline for educated debate. I learned it (implicitly) in my academic PL training: PL design is founded on math but is no science yet. Debate in hard sciences is different. >>> >>> Because this rule is in fact fundamental to establish respect under disagreement. The Rust CoC says "There is *seldom* a right answer." If a question has a right answer, the others become wrong, misguided, heretics, .... idiots... OK, you can censor the word "idiot", but that won't help much. Or you can admit that reasonable people might disagree on `Foldable ((,) a)` (as most already agree), and give that as a guideline, just as "assume good faith". That doesn't make "2 + 2 = 5" legitimate of course—some "common sense" is still needed. >>> >>> "There is *seldom* a right answer" is an unstated rule in academic papers (where it's implied by peer review), and it IMHO works rather well there, even on the few academics who will loudly proclaim elsewhere there is a right answer. >>> >>> Indeed, I don't want to misrepresent SPJ, but I feel he is often happy to talk about Haskell tradeoffs when they're there, even when others loudly proclaim Haskell is strictly and clearly better than X. >>> >>> Cheers, >>> Paolo >>> >>>> On Apr 3, 2017 10:55, "Tikhon Jelvis" wrote: >>>> Personally, I would not be against a *short and simple* code of conduct that specifically addresses issues we have seen. I'm imagining clear guidelines that help people express themselves in a thoughtful and polite way. Something in the style of the Hacker News commenting guidelines[1] (at least the first four; the rest are specific to HN/Reddit-like sites). >>>> >>>> One of the best examples I've seen in the wild had a single rule: no personal attacks. It's simple to understand and follow with no risk of stifling or derailing real discussions, and yet unambiguously rules out the majority of rude comments I see online (ignoring spam and outright trolling). >>>> >>>> I do *not* like Rust's code of conduct specifically. It does not provide clear guidelines on civility/politeness and covers too many other things, including a lot of (often political) baggage. Why is the idea that "everything is a tradeoff" enshrined as a rule? The rule on politeness is clearly deemphasized: "Please be kind and courteous. There’s no need to be mean or rude." is so vague it may as well not be in the code of conduct. We should *assume* people set out to be kind and courteous and help them do that consistently. The "Citizen Code of Conduct" they link to has even more baggage and I believe it should *not* serve as the basis for anything we might adopt as a community. >>>> >>>> [1]: https://news.ycombinator.com/newsguidelines.html see section "In Comments" >>>> >>>>> On Mon, Apr 3, 2017 at 1:13 AM, Simon Peyton Jones via Haskell-community wrote: >>>>> Friends >>>>> >>>>> >>>>> >>>>> I second what Tom says below. >>>>> >>>>> >>>>> >>>>> Almost everyone expresses their views with respect, even when disagreeing. The exceptions are (in my guess) mostly unintentional, at least in the extent of the offence caused. That does not make them unimportant, because a slow slippage in our collective standards is, over time corrosive. But it does mean that we can draw breath, as Tom has helpfully done here, and without condemning anyone reset our standards. >>>>> >>>>> >>>>> >>>>> I’ve been talking to a couple of people about whether it would be useful to have an explicit Haskell Community Code of Conduct. Many online communities have one (e.g. Rust), and it might be helpful for everyone to have a concrete baseline rather than an unwritten standard. Any views on that? >>>>> >>>>> >>>>> >>>>> Simon >>>>> >>>>> >>>>> >>>>> From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Tom Murphy >>>>> Sent: 02 April 2017 19:18 >>>>> To: Fumiaki Kinoshita >>>>> Cc: libraries >>>>> Subject: Civility notes (was "Traversable instances for (,,) a b") >>>>> >>>>> >>>>> >>>>> Hi Fumiaki! >>>>> >>>>> I agree with you that some poorly-chosen words by a few people have soured this conversation, but please don't let that turn you completely off of the productive conversation most of us are attempting to have! I think it's largely been successful, too: even if many of us haven't changed our -1/+1 votes, I for one have had my ideas challenged and have a more nuanced view than before talking with everyone here. >>>>> Henning and Edward are two examples (one from each side of the +1/-1 chasm) who have been aided by this discussion, in making important progress to finding a middle ground (each in the form of proposed compiler changes). >>>>> >>>>> To the rest of us: Fumiaki regretting having posted here is a pretty stark example of why speaking politely matters. People being scared away and feeling unwelcome is a real phenomenon, and we need to do our part to fix it. I'd propose: >>>>> >>>>> - If you haven't read it already, SPJ recently wrote a heartfelt letter on the subject [0]. We've gotten better since then, but clearly we're not finished. >>>>> - Civility is a norm, and norms sometimes need to be enforced. From a distance, we all look bad (and unwelcoming!) if anyone is hostile and we don't make it clear it's not acceptable. Speak up! That said, everyone makes mistakes - try to give people space to apologize and move on. >>>>> - If someone says something insulting to you, please take that as a sign to become more polite, not less so. The downward spiral is real. >>>>> >>>>> If you're called out for saying something regrettable (again, regardless of if you're +1 or -1 on this issue), *please* take our desire for civil conversation seriously. Responses like (I'm paraphrasing, and not trying to cite anyone specifically): "It was a joke (mostly)" and "It's your fault if you didn't get the joke" are worse than not writing anything at all. Ideal would be a quick "Sorry!" >>>>> >>>>> Thanks, all! >>>>> Tom >>>>> >>>>> [0] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html >>>>> >>>>> >>>>> >>>>> On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita wrote: >>>>> The discussion has diverged to flaming due to a few offensive people. I guess I shouldn't have posted a proposal here, I should have submitted a patch instead. >>>>> >>>>> 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : >>>>> It's surprising that they are missing (forgive me, I'm not here to make people grumpy). >>>>> >>>>> >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Haskell-community mailing list >>>>> Haskell-community at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>>> >>>> >>>> _______________________________________________ >>>> Haskell-community mailing list >>>> Haskell-community at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>> _______________________________________________ >>> Haskell-community mailing list >>> Haskell-community at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Wed Apr 5 23:46:20 2017 From: tikhon at jelv.is (Tikhon Jelvis) Date: Wed, 5 Apr 2017 16:46:20 -0700 Subject: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b") In-Reply-To: <15DE6EAB-A68B-46CE-B0AF-D8E6F665DFDE@gmail.com> References: <9616319F-1D7E-488F-BEAC-68E9577B96CE@gmail.com> <15DE6EAB-A68B-46CE-B0AF-D8E6F665DFDE@gmail.com> Message-ID: Just had a chance to look at Ruby's CoC, as suggested by Francesco Ariis. It looks like exactly what I had in mind. I agree with Tom that starting with an existing code would be a good idea and, if we do decide to do it, my vote is definitely for Ruby's over the alternatives I've seen. On Wed, Apr 5, 2017 at 5:25 PM, wrote: > > > El 5 abr 2017, a las 13:20, Jakub Daniel > escribió: > > What is the expected effect/role of CoC? Is it expected that people would > actually exhibit different behaviour because of a document? Is there a > reason to believe good behaviour in other communities come from existing > CoCs? I honestly doubt people prone to violate such rules tend to read such > documents and since there is no way to enforce it, what point is there? > > > If you'll forgive a strained metaphor: imagine you arrive in an unfamiliar > land, one which has a reputation for the occasional food fight. You're > wearing nice clothes and don't want your day ruined by getting food on > them. Some restaurants have a big sign out front: "Absolutely NO food > fighting. Anyone caught food fighting will be ejected". Other restaurants > don't have the sign. When picking a place to eat, aren't you likely to > gravitate to a restaurant which has a sign? > > Isn't the effort to maintain such a document just a waste? > > > Hopefully it'll be very low-maintenance! > > Tom > > > > > On 5 Apr 2017, at 20:54, amindfv at gmail.com wrote: > > I'm also +1 to a CoC, although have less of an opinion on what shape it > should take. CoCs are an effective way of making people who may feel like > outsiders to a community feel more welcome. The Haskell community is > amazing and inclusive but not the most diverse, and projects which are > doing better on that front largely all have CoCs. > > In terms of what shape it takes: there are lots of off-the-shelf ones for > different needs: I'd suggest picking one of them. > > Tom > > > El 5 abr 2017, a las 11:44, Paolo Giarrusso > escribió: > > Rust's code of conduct (and the conduct of leaders) have been very > successful at creating a welcoming community. However, those rules were > there from the start. > > What's crucial is that a code of conduct is really agreed upon by a > community and its elders. So thanks to Simon Peyton Jones for starting this > conversation. > In particular, a CoC to address known issues (not just in the present > discussion) would probably be easier to agree on. > > > We should *assume* people set out to be kind and courteous and help them > do that consistently. > > The guideline I find useful is "assume good faith" (used for instance in > Wikipedia), as long as you don't have extraordinary evidence. And that's a > guidelines that needs to be stated. > Opinions on politeness in the wild are much more varied. How polite do you > need to be, if somebody insists on being wrong? And with actual trolls? > > > Why is the idea that "everything is a tradeoff" enshrined as a rule? > > I don't know if it's a strict rule there, how strict it should be, or > whether it works in a CoC. But I find it a very good guideline for educated > debate. I learned it (implicitly) in my academic PL training: PL design is > founded on math but is no science yet. Debate in hard sciences is different. > > Because this rule is in fact fundamental to establish respect under > disagreement. The Rust CoC says "There is *seldom* a right answer." If a > question has a right answer, the others become wrong, misguided, heretics, > .... idiots... OK, you can censor the word "idiot", but that won't help > much. Or you can admit that reasonable people might disagree on `Foldable > ((,) a)` (as most already agree), and give that as a guideline, just as > "assume good faith". That doesn't make "2 + 2 = 5" legitimate of > course—some "common sense" is still needed. > > "There is *seldom* a right answer" is an unstated rule in academic papers > (where it's implied by peer review), and it IMHO works rather well there, > even on the few academics who will loudly proclaim elsewhere there is a > right answer. > > Indeed, I don't want to misrepresent SPJ, but I feel he is often happy to > talk about Haskell tradeoffs when they're there, even when others loudly > proclaim Haskell is strictly and clearly better than X. > > Cheers, > Paolo > > On Apr 3, 2017 10:55, "Tikhon Jelvis" wrote: > >> Personally, I would not be against a *short and simple* code of conduct >> that specifically addresses issues we have seen. I'm imagining clear >> guidelines that help people express themselves in a thoughtful and polite >> way. Something in the style of the Hacker News commenting guidelines[1] (at >> least the first four; the rest are specific to HN/Reddit-like sites). >> >> One of the best examples I've seen in the wild had a single rule: no >> personal attacks. It's simple to understand and follow with no risk of >> stifling or derailing real discussions, and yet unambiguously rules out the >> majority of rude comments I see online (ignoring spam and outright >> trolling). >> >> I do *not* like Rust's code of conduct specifically. It does not provide >> clear guidelines on civility/politeness and covers too many other things, >> including a lot of (often political) baggage. Why is the idea that >> "everything is a tradeoff" enshrined as a rule? The rule on politeness is >> clearly deemphasized: "Please be kind and courteous. There’s no need to be >> mean or rude." is so vague it may as well not be in the code of conduct. We >> should *assume* people set out to be kind and courteous and help them do >> that consistently. The "Citizen Code of Conduct" they link to has even more >> baggage and I believe it should *not* serve as the basis for anything we >> might adopt as a community. >> >> [1]: https://news.ycombinator.com/newsguidelines.html see section "In >> Comments" >> >> On Mon, Apr 3, 2017 at 1:13 AM, Simon Peyton Jones via Haskell-community >> wrote: >> >>> Friends >>> >>> >>> >>> I second what Tom says below. >>> >>> >>> >>> Almost everyone expresses their views with respect, even when >>> disagreeing. The exceptions are (in my guess) mostly unintentional, at >>> least in the extent of the offence caused. That does not make them >>> unimportant, because a slow slippage in our collective standards is, over >>> time corrosive. But it does mean that we can draw breath, as Tom has >>> helpfully done here, and without condemning anyone reset our standards. >>> >>> >>> >>> I’ve been talking to a couple of people about whether it would be useful >>> to have an explicit Haskell Community Code of Conduct. Many online >>> communities have one (e.g. Rust >>> ), and it might be >>> helpful for everyone to have a concrete baseline rather than an unwritten >>> standard. Any views on that? >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of *Tom >>> Murphy >>> *Sent:* 02 April 2017 19:18 >>> *To:* Fumiaki Kinoshita >>> *Cc:* libraries >>> *Subject:* Civility notes (was "Traversable instances for (,,) a b") >>> >>> >>> >>> Hi Fumiaki! >>> >>> I agree with you that some poorly-chosen words by a few people have >>> soured this conversation, but please don't let that turn you completely off >>> of the productive conversation most of us are attempting to have! I think >>> it's largely been successful, too: even if many of us haven't changed our >>> -1/+1 votes, I for one have had my ideas challenged and have a more nuanced >>> view than before talking with everyone here. >>> >>> Henning and Edward are two examples (one from each side of the >>> +1/-1 chasm) who have been aided by this discussion, in making important >>> progress to finding a middle ground (each in the form of proposed compiler >>> changes). >>> >>> To the rest of us: Fumiaki regretting having posted here is a >>> pretty stark example of why speaking politely matters. People being scared >>> away and feeling unwelcome is a real phenomenon, and we need to do our part >>> to fix it. I'd propose: >>> >>> - If you haven't read it already, SPJ recently wrote a heartfelt >>> letter on the subject [0]. We've gotten better since then, but clearly >>> we're not finished. >>> >>> - Civility is a norm, and norms sometimes need to be enforced. From >>> a distance, we all look bad (and unwelcoming!) if anyone is hostile and we >>> don't make it clear it's not acceptable. Speak up! That said, everyone >>> makes mistakes - try to give people space to apologize and move on. >>> >>> - If someone says something insulting to you, please take that as a >>> sign to become more polite, not less so. The downward spiral is real. >>> >>> >>> >>> If you're called out for saying something regrettable (again, >>> regardless of if you're +1 or -1 on this issue), *please* take our desire >>> for civil conversation seriously. Responses like (I'm paraphrasing, and not >>> trying to cite anyone specifically): "It was a joke (mostly)" and "It's >>> your fault if you didn't get the joke" are worse than not writing anything >>> at all. Ideal would be a quick "Sorry!" >>> >>> Thanks, all! >>> >>> Tom >>> >>> >>> [0] https://mail.haskell.org/pipermail/haskell/2016-September/02 >>> 4995.html >>> >>> >>> >>> >>> >>> On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita >>> wrote: >>> >>> The discussion has diverged to flaming due to a few offensive people. I >>> guess I shouldn't have posted a proposal here, I should have submitted a >>> patch instead. >>> >>> >>> >>> 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : >>> >>> It's surprising that they are missing (forgive me, I'm not here to make >>> people grumpy). >>> >>> >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >>> >>> _______________________________________________ >>> Haskell-community mailing list >>> Haskell-community at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>> >>> >> >> _______________________________________________ >> Haskell-community mailing list >> Haskell-community at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >> >> _______________________________________________ > Haskell-community mailing list > Haskell-community at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Apr 6 00:11:10 2017 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 5 Apr 2017 20:11:10 -0400 Subject: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b") In-Reply-To: References: <9616319F-1D7E-488F-BEAC-68E9577B96CE@gmail.com> <15DE6EAB-A68B-46CE-B0AF-D8E6F665DFDE@gmail.com> Message-ID: https://www.ruby-lang.org/en/conduct/ looks pretty reasonable. i like how it makes clear intent while not being very "rules lawyery", because at the end of the day human judgment and feedback is what matters On Wed, Apr 5, 2017 at 7:46 PM, Tikhon Jelvis wrote: > Just had a chance to look at Ruby's CoC, as suggested by Francesco Ariis. > It looks like exactly what I had in mind. > > I agree with Tom that starting with an existing code would be a good idea > and, if we do decide to do it, my vote is definitely for Ruby's over the > alternatives I've seen. > > On Wed, Apr 5, 2017 at 5:25 PM, wrote: > >> >> >> El 5 abr 2017, a las 13:20, Jakub Daniel >> escribió: >> >> What is the expected effect/role of CoC? Is it expected that people would >> actually exhibit different behaviour because of a document? Is there a >> reason to believe good behaviour in other communities come from existing >> CoCs? I honestly doubt people prone to violate such rules tend to read such >> documents and since there is no way to enforce it, what point is there? >> >> >> If you'll forgive a strained metaphor: imagine you arrive in an >> unfamiliar land, one which has a reputation for the occasional food fight. >> You're wearing nice clothes and don't want your day ruined by getting food >> on them. Some restaurants have a big sign out front: "Absolutely NO food >> fighting. Anyone caught food fighting will be ejected". Other restaurants >> don't have the sign. When picking a place to eat, aren't you likely to >> gravitate to a restaurant which has a sign? >> >> Isn't the effort to maintain such a document just a waste? >> >> >> Hopefully it'll be very low-maintenance! >> >> Tom >> >> >> >> >> On 5 Apr 2017, at 20:54, amindfv at gmail.com wrote: >> >> I'm also +1 to a CoC, although have less of an opinion on what shape it >> should take. CoCs are an effective way of making people who may feel like >> outsiders to a community feel more welcome. The Haskell community is >> amazing and inclusive but not the most diverse, and projects which are >> doing better on that front largely all have CoCs. >> >> In terms of what shape it takes: there are lots of off-the-shelf ones for >> different needs: I'd suggest picking one of them. >> >> Tom >> >> >> El 5 abr 2017, a las 11:44, Paolo Giarrusso >> escribió: >> >> Rust's code of conduct (and the conduct of leaders) have been very >> successful at creating a welcoming community. However, those rules were >> there from the start. >> >> What's crucial is that a code of conduct is really agreed upon by a >> community and its elders. So thanks to Simon Peyton Jones for starting this >> conversation. >> In particular, a CoC to address known issues (not just in the present >> discussion) would probably be easier to agree on. >> >> > We should *assume* people set out to be kind and courteous and help >> them do that consistently. >> >> The guideline I find useful is "assume good faith" (used for instance in >> Wikipedia), as long as you don't have extraordinary evidence. And that's a >> guidelines that needs to be stated. >> Opinions on politeness in the wild are much more varied. How polite do >> you need to be, if somebody insists on being wrong? And with actual trolls? >> >> > Why is the idea that "everything is a tradeoff" enshrined as a rule? >> >> I don't know if it's a strict rule there, how strict it should be, or >> whether it works in a CoC. But I find it a very good guideline for educated >> debate. I learned it (implicitly) in my academic PL training: PL design is >> founded on math but is no science yet. Debate in hard sciences is different. >> >> Because this rule is in fact fundamental to establish respect under >> disagreement. The Rust CoC says "There is *seldom* a right answer." If a >> question has a right answer, the others become wrong, misguided, heretics, >> .... idiots... OK, you can censor the word "idiot", but that won't help >> much. Or you can admit that reasonable people might disagree on `Foldable >> ((,) a)` (as most already agree), and give that as a guideline, just as >> "assume good faith". That doesn't make "2 + 2 = 5" legitimate of >> course—some "common sense" is still needed. >> >> "There is *seldom* a right answer" is an unstated rule in academic papers >> (where it's implied by peer review), and it IMHO works rather well there, >> even on the few academics who will loudly proclaim elsewhere there is a >> right answer. >> >> Indeed, I don't want to misrepresent SPJ, but I feel he is often happy to >> talk about Haskell tradeoffs when they're there, even when others loudly >> proclaim Haskell is strictly and clearly better than X. >> >> Cheers, >> Paolo >> >> On Apr 3, 2017 10:55, "Tikhon Jelvis" wrote: >> >>> Personally, I would not be against a *short and simple* code of conduct >>> that specifically addresses issues we have seen. I'm imagining clear >>> guidelines that help people express themselves in a thoughtful and polite >>> way. Something in the style of the Hacker News commenting guidelines[1] (at >>> least the first four; the rest are specific to HN/Reddit-like sites). >>> >>> One of the best examples I've seen in the wild had a single rule: no >>> personal attacks. It's simple to understand and follow with no risk of >>> stifling or derailing real discussions, and yet unambiguously rules out the >>> majority of rude comments I see online (ignoring spam and outright >>> trolling). >>> >>> I do *not* like Rust's code of conduct specifically. It does not provide >>> clear guidelines on civility/politeness and covers too many other things, >>> including a lot of (often political) baggage. Why is the idea that >>> "everything is a tradeoff" enshrined as a rule? The rule on politeness is >>> clearly deemphasized: "Please be kind and courteous. There’s no need to be >>> mean or rude." is so vague it may as well not be in the code of conduct. We >>> should *assume* people set out to be kind and courteous and help them do >>> that consistently. The "Citizen Code of Conduct" they link to has even more >>> baggage and I believe it should *not* serve as the basis for anything we >>> might adopt as a community. >>> >>> [1]: https://news.ycombinator.com/newsguidelines.html see section "In >>> Comments" >>> >>> On Mon, Apr 3, 2017 at 1:13 AM, Simon Peyton Jones via Haskell-community >>> wrote: >>> >>>> Friends >>>> >>>> >>>> >>>> I second what Tom says below. >>>> >>>> >>>> >>>> Almost everyone expresses their views with respect, even when >>>> disagreeing. The exceptions are (in my guess) mostly unintentional, at >>>> least in the extent of the offence caused. That does not make them >>>> unimportant, because a slow slippage in our collective standards is, over >>>> time corrosive. But it does mean that we can draw breath, as Tom has >>>> helpfully done here, and without condemning anyone reset our standards. >>>> >>>> >>>> >>>> I’ve been talking to a couple of people about whether it would be >>>> useful to have an explicit Haskell Community Code of Conduct. Many online >>>> communities have one (e.g. Rust >>>> ), and it might be >>>> helpful for everyone to have a concrete baseline rather than an unwritten >>>> standard. Any views on that? >>>> >>>> >>>> >>>> Simon >>>> >>>> >>>> >>>> *From:* Libraries [mailto:libraries-bounces at haskell.org] *On Behalf Of >>>> *Tom Murphy >>>> *Sent:* 02 April 2017 19:18 >>>> *To:* Fumiaki Kinoshita >>>> *Cc:* libraries >>>> *Subject:* Civility notes (was "Traversable instances for (,,) a b") >>>> >>>> >>>> >>>> Hi Fumiaki! >>>> >>>> I agree with you that some poorly-chosen words by a few people >>>> have soured this conversation, but please don't let that turn you >>>> completely off of the productive conversation most of us are attempting to >>>> have! I think it's largely been successful, too: even if many of us haven't >>>> changed our -1/+1 votes, I for one have had my ideas challenged and have a >>>> more nuanced view than before talking with everyone here. >>>> >>>> Henning and Edward are two examples (one from each side of the >>>> +1/-1 chasm) who have been aided by this discussion, in making important >>>> progress to finding a middle ground (each in the form of proposed compiler >>>> changes). >>>> >>>> To the rest of us: Fumiaki regretting having posted here is a >>>> pretty stark example of why speaking politely matters. People being scared >>>> away and feeling unwelcome is a real phenomenon, and we need to do our part >>>> to fix it. I'd propose: >>>> >>>> - If you haven't read it already, SPJ recently wrote a heartfelt >>>> letter on the subject [0]. We've gotten better since then, but clearly >>>> we're not finished. >>>> >>>> - Civility is a norm, and norms sometimes need to be enforced. >>>> From a distance, we all look bad (and unwelcoming!) if anyone is hostile >>>> and we don't make it clear it's not acceptable. Speak up! That said, >>>> everyone makes mistakes - try to give people space to apologize and move on. >>>> >>>> - If someone says something insulting to you, please take that as >>>> a sign to become more polite, not less so. The downward spiral is real. >>>> >>>> >>>> >>>> If you're called out for saying something regrettable (again, >>>> regardless of if you're +1 or -1 on this issue), *please* take our desire >>>> for civil conversation seriously. Responses like (I'm paraphrasing, and not >>>> trying to cite anyone specifically): "It was a joke (mostly)" and "It's >>>> your fault if you didn't get the joke" are worse than not writing anything >>>> at all. Ideal would be a quick "Sorry!" >>>> >>>> Thanks, all! >>>> >>>> Tom >>>> >>>> >>>> [0] https://mail.haskell.org/pipermail/haskell/2016-September/02 >>>> 4995.html >>>> >>>> >>>> >>>> >>>> >>>> On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita >>>> wrote: >>>> >>>> The discussion has diverged to flaming due to a few offensive people. I >>>> guess I shouldn't have posted a proposal here, I should have submitted a >>>> patch instead. >>>> >>>> >>>> >>>> 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : >>>> >>>> It's surprising that they are missing (forgive me, I'm not here to make >>>> people grumpy). >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Libraries mailing list >>>> Libraries at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>> >>>> >>>> >>>> _______________________________________________ >>>> Haskell-community mailing list >>>> Haskell-community at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>>> >>>> >>> >>> _______________________________________________ >>> Haskell-community mailing list >>> Haskell-community at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>> >>> _______________________________________________ >> Haskell-community mailing list >> Haskell-community at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Thu Apr 6 00:26:19 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Thu, 6 Apr 2017 10:26:19 +1000 Subject: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b") In-Reply-To: References: <9616319F-1D7E-488F-BEAC-68E9577B96CE@gmail.com> <15DE6EAB-A68B-46CE-B0AF-D8E6F665DFDE@gmail.com> Message-ID: This isn't too bad, but if we must have a CoC I would prefer something based upon [Wheaton's Law] (admittedly, it's probably more open to abuse due to lack of defining terms). Wheaton's Law: http://www.wheatonslaw.com/ On 6 April 2017 at 10:11, Carter Schonwald wrote: > https://www.ruby-lang.org/en/conduct/ > > looks pretty reasonable. i like how it makes clear intent while not being > very "rules lawyery", because at the end of the day human judgment and > feedback is what matters > > On Wed, Apr 5, 2017 at 7:46 PM, Tikhon Jelvis wrote: >> >> Just had a chance to look at Ruby's CoC, as suggested by Francesco Ariis. >> It looks like exactly what I had in mind. >> >> I agree with Tom that starting with an existing code would be a good idea >> and, if we do decide to do it, my vote is definitely for Ruby's over the >> alternatives I've seen. >> >> On Wed, Apr 5, 2017 at 5:25 PM, wrote: >>> >>> >>> >>> El 5 abr 2017, a las 13:20, Jakub Daniel >>> escribió: >>> >>> What is the expected effect/role of CoC? Is it expected that people would >>> actually exhibit different behaviour because of a document? Is there a >>> reason to believe good behaviour in other communities come from existing >>> CoCs? I honestly doubt people prone to violate such rules tend to read such >>> documents and since there is no way to enforce it, what point is there? >>> >>> >>> If you'll forgive a strained metaphor: imagine you arrive in an >>> unfamiliar land, one which has a reputation for the occasional food fight. >>> You're wearing nice clothes and don't want your day ruined by getting food >>> on them. Some restaurants have a big sign out front: "Absolutely NO food >>> fighting. Anyone caught food fighting will be ejected". Other restaurants >>> don't have the sign. When picking a place to eat, aren't you likely to >>> gravitate to a restaurant which has a sign? >>> >>> Isn't the effort to maintain such a document just a waste? >>> >>> >>> Hopefully it'll be very low-maintenance! >>> >>> Tom >>> >>> >>> >>> >>> On 5 Apr 2017, at 20:54, amindfv at gmail.com wrote: >>> >>> I'm also +1 to a CoC, although have less of an opinion on what shape it >>> should take. CoCs are an effective way of making people who may feel like >>> outsiders to a community feel more welcome. The Haskell community is amazing >>> and inclusive but not the most diverse, and projects which are doing better >>> on that front largely all have CoCs. >>> >>> In terms of what shape it takes: there are lots of off-the-shelf ones for >>> different needs: I'd suggest picking one of them. >>> >>> Tom >>> >>> >>> El 5 abr 2017, a las 11:44, Paolo Giarrusso >>> escribió: >>> >>> Rust's code of conduct (and the conduct of leaders) have been very >>> successful at creating a welcoming community. However, those rules were >>> there from the start. >>> >>> What's crucial is that a code of conduct is really agreed upon by a >>> community and its elders. So thanks to Simon Peyton Jones for starting this >>> conversation. >>> In particular, a CoC to address known issues (not just in the present >>> discussion) would probably be easier to agree on. >>> >>> > We should *assume* people set out to be kind and courteous and help >>> > them do that consistently. >>> >>> The guideline I find useful is "assume good faith" (used for instance in >>> Wikipedia), as long as you don't have extraordinary evidence. And that's a >>> guidelines that needs to be stated. >>> Opinions on politeness in the wild are much more varied. How polite do >>> you need to be, if somebody insists on being wrong? And with actual trolls? >>> >>> > Why is the idea that "everything is a tradeoff" enshrined as a rule? >>> >>> I don't know if it's a strict rule there, how strict it should be, or >>> whether it works in a CoC. But I find it a very good guideline for educated >>> debate. I learned it (implicitly) in my academic PL training: PL design is >>> founded on math but is no science yet. Debate in hard sciences is different. >>> >>> Because this rule is in fact fundamental to establish respect under >>> disagreement. The Rust CoC says "There is *seldom* a right answer." If a >>> question has a right answer, the others become wrong, misguided, heretics, >>> .... idiots... OK, you can censor the word "idiot", but that won't help >>> much. Or you can admit that reasonable people might disagree on `Foldable >>> ((,) a)` (as most already agree), and give that as a guideline, just as >>> "assume good faith". That doesn't make "2 + 2 = 5" legitimate of course—some >>> "common sense" is still needed. >>> >>> "There is *seldom* a right answer" is an unstated rule in academic papers >>> (where it's implied by peer review), and it IMHO works rather well there, >>> even on the few academics who will loudly proclaim elsewhere there is a >>> right answer. >>> >>> Indeed, I don't want to misrepresent SPJ, but I feel he is often happy to >>> talk about Haskell tradeoffs when they're there, even when others loudly >>> proclaim Haskell is strictly and clearly better than X. >>> >>> Cheers, >>> Paolo >>> >>> On Apr 3, 2017 10:55, "Tikhon Jelvis" wrote: >>>> >>>> Personally, I would not be against a *short and simple* code of conduct >>>> that specifically addresses issues we have seen. I'm imagining clear >>>> guidelines that help people express themselves in a thoughtful and polite >>>> way. Something in the style of the Hacker News commenting guidelines[1] (at >>>> least the first four; the rest are specific to HN/Reddit-like sites). >>>> >>>> One of the best examples I've seen in the wild had a single rule: no >>>> personal attacks. It's simple to understand and follow with no risk of >>>> stifling or derailing real discussions, and yet unambiguously rules out the >>>> majority of rude comments I see online (ignoring spam and outright >>>> trolling). >>>> >>>> I do *not* like Rust's code of conduct specifically. It does not provide >>>> clear guidelines on civility/politeness and covers too many other things, >>>> including a lot of (often political) baggage. Why is the idea that >>>> "everything is a tradeoff" enshrined as a rule? The rule on politeness is >>>> clearly deemphasized: "Please be kind and courteous. There’s no need to be >>>> mean or rude." is so vague it may as well not be in the code of conduct. We >>>> should *assume* people set out to be kind and courteous and help them do >>>> that consistently. The "Citizen Code of Conduct" they link to has even more >>>> baggage and I believe it should *not* serve as the basis for anything we >>>> might adopt as a community. >>>> >>>> [1]: https://news.ycombinator.com/newsguidelines.html see section "In >>>> Comments" >>>> >>>> On Mon, Apr 3, 2017 at 1:13 AM, Simon Peyton Jones via Haskell-community >>>> wrote: >>>>> >>>>> Friends >>>>> >>>>> >>>>> >>>>> I second what Tom says below. >>>>> >>>>> >>>>> >>>>> Almost everyone expresses their views with respect, even when >>>>> disagreeing. The exceptions are (in my guess) mostly unintentional, at >>>>> least in the extent of the offence caused. That does not make them >>>>> unimportant, because a slow slippage in our collective standards is, over >>>>> time corrosive. But it does mean that we can draw breath, as Tom has >>>>> helpfully done here, and without condemning anyone reset our standards. >>>>> >>>>> >>>>> >>>>> I’ve been talking to a couple of people about whether it would be >>>>> useful to have an explicit Haskell Community Code of Conduct. Many online >>>>> communities have one (e.g. Rust), and it might be helpful for everyone to >>>>> have a concrete baseline rather than an unwritten standard. Any views on >>>>> that? >>>>> >>>>> >>>>> >>>>> Simon >>>>> >>>>> >>>>> >>>>> From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Tom >>>>> Murphy >>>>> Sent: 02 April 2017 19:18 >>>>> To: Fumiaki Kinoshita >>>>> Cc: libraries >>>>> Subject: Civility notes (was "Traversable instances for (,,) a b") >>>>> >>>>> >>>>> >>>>> Hi Fumiaki! >>>>> >>>>> I agree with you that some poorly-chosen words by a few people >>>>> have soured this conversation, but please don't let that turn you completely >>>>> off of the productive conversation most of us are attempting to have! I >>>>> think it's largely been successful, too: even if many of us haven't changed >>>>> our -1/+1 votes, I for one have had my ideas challenged and have a more >>>>> nuanced view than before talking with everyone here. >>>>> >>>>> Henning and Edward are two examples (one from each side of the >>>>> +1/-1 chasm) who have been aided by this discussion, in making important >>>>> progress to finding a middle ground (each in the form of proposed compiler >>>>> changes). >>>>> >>>>> To the rest of us: Fumiaki regretting having posted here is a >>>>> pretty stark example of why speaking politely matters. People being scared >>>>> away and feeling unwelcome is a real phenomenon, and we need to do our part >>>>> to fix it. I'd propose: >>>>> >>>>> - If you haven't read it already, SPJ recently wrote a heartfelt >>>>> letter on the subject [0]. We've gotten better since then, but clearly we're >>>>> not finished. >>>>> >>>>> - Civility is a norm, and norms sometimes need to be enforced. >>>>> From a distance, we all look bad (and unwelcoming!) if anyone is hostile and >>>>> we don't make it clear it's not acceptable. Speak up! That said, everyone >>>>> makes mistakes - try to give people space to apologize and move on. >>>>> >>>>> - If someone says something insulting to you, please take that as >>>>> a sign to become more polite, not less so. The downward spiral is real. >>>>> >>>>> >>>>> >>>>> If you're called out for saying something regrettable (again, >>>>> regardless of if you're +1 or -1 on this issue), *please* take our desire >>>>> for civil conversation seriously. Responses like (I'm paraphrasing, and not >>>>> trying to cite anyone specifically): "It was a joke (mostly)" and "It's your >>>>> fault if you didn't get the joke" are worse than not writing anything at >>>>> all. Ideal would be a quick "Sorry!" >>>>> >>>>> Thanks, all! >>>>> >>>>> Tom >>>>> >>>>> >>>>> [0] >>>>> https://mail.haskell.org/pipermail/haskell/2016-September/024995.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita >>>>> wrote: >>>>> >>>>> The discussion has diverged to flaming due to a few offensive people. I >>>>> guess I shouldn't have posted a proposal here, I should have submitted a >>>>> patch instead. >>>>> >>>>> >>>>> >>>>> 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : >>>>> >>>>> It's surprising that they are missing (forgive me, I'm not here to make >>>>> people grumpy). >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Libraries mailing list >>>>> Libraries at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Haskell-community mailing list >>>>> Haskell-community at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Haskell-community mailing list >>>> Haskell-community at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>>> >>> _______________________________________________ >>> Haskell-community mailing list >>> Haskell-community at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From tmorris at tmorris.net Thu Apr 6 03:15:21 2017 From: tmorris at tmorris.net (Tony Morris) Date: Thu, 6 Apr 2017 13:15:21 +1000 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> Message-ID: By "length" here I mean, the function whose name is lima echo november golf tango hotel. I truly do not care what it is called. Follow the types, and the types of the types. On Thu, Apr 6, 2017 at 12:51 AM, Ben Franksen wrote: > Am 01.04.2017 um 03:27 schrieb Tony Morris: > > The length of ((,) a) is exactly one. Anything else is ridiculous. Try > > arguing against that, > > Half true: length for this type makes no sense at all since it is not a > sequence. So there should be no length defined for it. > > Just choose a different name. > > Cheers > Ben > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.fairbairn at cl.cam.ac.uk Thu Apr 6 07:28:54 2017 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu, 06 Apr 2017 08:28:54 +0100 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> Message-ID: Tony Morris writes: > I did read it. I chose not to respond. I do not believe it to be a > constructive avenue. > > I am repeating myself far less than the misunderstanding and > inconsistency around "tuples." To this end, I believe is worthwhile to > continue pointing out the inconsistency, and only slightly less so than > those who hold a contrary inconsistent position, who are inadvertently > pointing out the inconsistency. 0 is not an integer is a statement of > equal validity, buit more obviously not so. You keep using “integer”, but didn’t answer my question. What makes you think that integer is the appropriate set? What do the negative numbers represent in this context? If the answer is “nothing”, you are actually talking about natural numbers, and both the sets ℕ and ℕ⁺ are perfectly respectable. > The length of ((,) a) is exactly one. Anything else is > ridiculous. So that I can understand this, please give an example of a programme where this usage is meaningful. — Jón From abela at chalmers.se Thu Apr 6 07:32:54 2017 From: abela at chalmers.se (Andreas Abel) Date: Thu, 6 Apr 2017 09:32:54 +0200 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> Message-ID: <174a8767-2a4f-eb9b-4a9d-c6f38032d334@chalmers.se> On 06.04.2017 05:15, Tony Morris wrote: > By "length" here I mean, the function whose name is lima echo november > golf tango hotel. I truly do not care what it is called. Follow the > types, and the types of the types. In theory you are right. But in practice, even a programming language is more than grammar. The names make the vocabulary. There is good names and bad names for a function. Good names are the ones everyone uses. Programmers use several programming languages, and they want the names of analogue functions to be the same. They want to come to a new language and reuse their vocabulary without bad surprises, as much as possible. Here is a classic short story of Swiss writer Peter Bichsel about an old man, who decides to name a table a "carpet", a bed a "painting" etc. A Table is a Table http://www.barbarafaessler.com/files/BichselAtableisatable.pdf The outcome is the expected one... > On Thu, Apr 6, 2017 at 12:51 AM, Ben Franksen > wrote: > > Am 01.04.2017 um 03:27 schrieb Tony Morris: > > The length of ((,) a) is exactly one. Anything else is ridiculous. Try > > arguing against that, > > Half true: length for this type makes no sense at all since it is not a > sequence. So there should be no length defined for it. > > Just choose a different name. > > Cheers > Ben -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www.cse.chalmers.se/~abela/ From jon.fairbairn at cl.cam.ac.uk Thu Apr 6 07:33:16 2017 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Thu, 06 Apr 2017 08:33:16 +0100 Subject: Constraints on definition of `length` should be strengthened References: Message-ID: Sven Panne writes: > 2017-04-05 18:18 GMT+02:00 Ben Franksen : > >> And let's not forget Either which IMO should be regarded as an unbiased >> choice. I don't have a proposal for the name, though. >> > > In the dark ages of Haskell's library design, i.e. a long, long time ago, > in a distant past, the time where people could actually write significant > code without using at least 20 LANGUAGE pragmas ;-), we discussed this > already, see e.g. the thread starting at > http://code.haskell.org/~dons/haskell-1990-2000/msg07215.html. The final > outcome was: Although something like Error/OK would have been better than > Left/Right, a slight majority preferred to give a bias to Either. The > reasoning was that using "Right" for a "wrong" outcome (i.e. failure) would > be a bit obscure, and there was already quite some code using it in the way > we still do today. The bias is even explicitly documented in the Haddock > docs for Data.Either for ages, so it would not be very wise to change the > meaning here after roughly 2 decades. I guess this means that Haskell has failed to sufficiently avoid success. If a mistake in library design is bad enough (not necessarily the case for Either, but arguably so), it should be corrected even after 20 years. > Of course the question remains: What is the totally unbiased standard sum > type for 2 alternatives? What are you asking? It sounds like an invitation to bikeshed! In general, though, types such as (,) and Either should be used very sparingly. In many cases it would be better to define a new type for the specific purpose. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk From tonymorris at gmail.com Thu Apr 6 07:53:59 2017 From: tonymorris at gmail.com (Tony Morris) Date: Thu, 6 Apr 2017 17:53:59 +1000 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> Message-ID: I don't think it is the "appropriate" set. It's an example. 0 is in the set of integers. The value 0 is in many sets. ((,) a) is the set of things which are Foldable, and consequently, have a length, which reasoning by the type and kind system, immediately leads to the conclusion that it is (very obviously) 1. I am deliberately picking on the argument, "from obviousness", which is the best counter-argument so far (according to the counter-arguers; hoping not to misrepresent here). This is not only a weak argument, I hope we can agree, but *the exact opposite* is true, where we probably disagree. Our premises: Foldable :: (* -> *) -> Constraint length :: forall f. * -> *. f a -> Int let length = foldl (+) 0 -- or similar let f ~ ((,) a) Anything but length=1 for not only not "obvious", but I argue completely ridiculous, by the definition of length. I am not fond of the "argument from obviousness", but if I am forced to use it, I will, and any counter-argument will still fail. PS: I didn't see your original question, sorry. I just stopped looking at the thread for a bit. On 06/04/17 17:28, Jon Fairbairn wrote: > Tony Morris writes: > >> I did read it. I chose not to respond. I do not believe it to be a >> constructive avenue. >> >> I am repeating myself far less than the misunderstanding and >> inconsistency around "tuples." To this end, I believe is worthwhile to >> continue pointing out the inconsistency, and only slightly less so than >> those who hold a contrary inconsistent position, who are inadvertently >> pointing out the inconsistency. 0 is not an integer is a statement of >> equal validity, buit more obviously not so. > You keep using “integer”, but didn’t answer my question. What > makes you think that integer is the appropriate set? What do the > negative numbers represent in this context? If the answer is > “nothing”, you are actually talking about natural numbers, and > both the sets ℕ and ℕ⁺ are perfectly respectable. > >> The length of ((,) a) is exactly one. Anything else is >> ridiculous. > So that I can understand this, please give an example of a > programme where this usage is meaningful. > > — Jón > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From tonymorris at gmail.com Thu Apr 6 07:55:41 2017 From: tonymorris at gmail.com (Tony Morris) Date: Thu, 6 Apr 2017 17:55:41 +1000 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <174a8767-2a4f-eb9b-4a9d-c6f38032d334@chalmers.se> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <174a8767-2a4f-eb9b-4a9d-c6f38032d334@chalmers.se> Message-ID: I am not arguing either way on this one. Call it whatever you want, I don't care. I definitely need that function though. Call it pancakes and let's move on. On 06/04/17 17:32, Andreas Abel wrote: > On 06.04.2017 05:15, Tony Morris wrote: >> By "length" here I mean, the function whose name is lima echo november >> golf tango hotel. I truly do not care what it is called. Follow the >> types, and the types of the types. > > In theory you are right. But in practice, even a programming language > is more than grammar. The names make the vocabulary. There is good > names and bad names for a function. Good names are the ones everyone > uses. Programmers use several programming languages, and they want > the names of analogue functions to be the same. They want to come to > a new language and reuse their vocabulary without bad surprises, as > much as possible. > > Here is a classic short story of Swiss writer Peter Bichsel about an > old man, who decides to name a table a "carpet", a bed a "painting" etc. > > A Table is a Table > http://www.barbarafaessler.com/files/BichselAtableisatable.pdf > > The outcome is the expected one... > >> On Thu, Apr 6, 2017 at 12:51 AM, Ben Franksen > > wrote: >> >> Am 01.04.2017 um 03:27 schrieb Tony Morris: >> > The length of ((,) a) is exactly one. Anything else is >> ridiculous. Try >> > arguing against that, >> >> Half true: length for this type makes no sense at all since it is >> not a >> sequence. So there should be no length defined for it. >> >> Just choose a different name. >> >> Cheers >> Ben > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From Henrik.Nilsson at nottingham.ac.uk Thu Apr 6 08:12:55 2017 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Thu, 06 Apr 2017 09:12:55 +0100 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> Message-ID: <58E5F887.7000904@exmail.nottingham.ac.uk> On 04/06/2017 04:15 AM, Tony Morris wrote: > By "length" here I mean, the function whose name is lima echo november > golf tango hotel. I truly do not care what it is called. Follow the > types, and the types of the types. I think the nub of the matter is that the types (and the types of the types) (in a language like Haskell) actually are not enough. There are (literally) infinitely many functions with the same type as "length". One might argue that few of those make "sense", but that is always going to be a precarious argument unless the setting is made clear. More generally, if we were to extrapolate and truly refer to things by their full specification, then that would be very cumbersome indeed. By analogy, mathematical theorems are full specifications, and they usually have names. Names matter, at least to most people (I dare guess), and in particular when we rely on the names to convey missing information, as is the case with "length" given its (Haskell) type. Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From tonymorris at gmail.com Thu Apr 6 08:52:54 2017 From: tonymorris at gmail.com (Tony Morris) Date: Thu, 6 Apr 2017 18:52:54 +1000 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <58E5F887.7000904@exmail.nottingham.ac.uk> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <58E5F887.7000904@exmail.nottingham.ac.uk> Message-ID: <4c4da582-8972-a134-2b7b-241e67e221e4@gmail.com> Right, length is particularly unfortunate in that it is a bad example for the purposes of parametricity. We can express additional properties, as well as types, to make up for this shortcoming. Still better than relying on glyphs, which are notoriously unreliable, misleading, inefficient and impratical to use to convey useful information about the behaviour of a function. I will leave out the expression of these properties, so as not to rob anyone of a fun and useful exercise. Ultimately, I genuinely do not care. I routinely work on teams with people who do not care. We use other tools for reasoning about programs; I argue, they are more efficient and reliable. If anyone wants to disagree, that's fine, call it pineapples or whatever may be chosen, and we can all move on. I simply need that function, whatever it might be called. PS: in a dream land, where hardware efficiencies are of no concern, length = fmap (const ()). On 06/04/17 18:12, Henrik Nilsson wrote: > On 04/06/2017 04:15 AM, Tony Morris wrote: >> By "length" here I mean, the function whose name is lima echo november >> golf tango hotel. I truly do not care what it is called. Follow the >> types, and the types of the types. > > I think the nub of the matter is that the types (and the types of the > types) (in a language like Haskell) actually are not enough. There are > (literally) infinitely many functions with the same type as "length". > One might argue that few of those make "sense", but that is always > going to be a precarious argument unless the setting is made clear. > > More generally, if we were to extrapolate and truly refer to things > by their full specification, then that would be very cumbersome indeed. > By analogy, mathematical theorems are full specifications, and they > usually have names. > > Names matter, at least to most people (I dare guess), and in particular > when we rely on the names to convey missing information, as is the > case with "length" given its (Haskell) type. > > Best, > > /Henrik > > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please send it back to me, and immediately delete it. > Please do not use, copy or disclose the information contained in this > message or in any attachment. Any views or opinions expressed by the > author of this email do not necessarily reflect the views of the > University of Nottingham. > > This message has been checked for viruses but the contents of an > attachment may still contain software viruses which could damage your > computer system, you are advised to perform your own checks. Email > communications with the University of Nottingham may be monitored as > permitted by UK legislation. > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From carter.schonwald at gmail.com Thu Apr 6 10:56:32 2017 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 06 Apr 2017 10:56:32 +0000 Subject: [Haskell-community] Civility notes (was "Traversable instances for (, , ) a b") In-Reply-To: References: <9616319F-1D7E-488F-BEAC-68E9577B96CE@gmail.com> <15DE6EAB-A68B-46CE-B0AF-D8E6F665DFDE@gmail.com> Message-ID: YEAH ld be cool with that one too. Ultimately as long as we give each other constructive feedback it's all good. On Wed, Apr 5, 2017 at 8:26 PM Ivan Lazar Miljenovic < ivan.miljenovic at gmail.com> wrote: > This isn't too bad, but if we must have a CoC I would prefer something > based upon [Wheaton's Law] (admittedly, it's probably more open to > abuse due to lack of defining terms). > > Wheaton's Law: http://www.wheatonslaw.com/ > > On 6 April 2017 at 10:11, Carter Schonwald > wrote: > > https://www.ruby-lang.org/en/conduct/ > > > > looks pretty reasonable. i like how it makes clear intent while not being > > very "rules lawyery", because at the end of the day human judgment and > > feedback is what matters > > > > On Wed, Apr 5, 2017 at 7:46 PM, Tikhon Jelvis wrote: > >> > >> Just had a chance to look at Ruby's CoC, as suggested by Francesco > Ariis. > >> It looks like exactly what I had in mind. > >> > >> I agree with Tom that starting with an existing code would be a good > idea > >> and, if we do decide to do it, my vote is definitely for Ruby's over the > >> alternatives I've seen. > >> > >> On Wed, Apr 5, 2017 at 5:25 PM, wrote: > >>> > >>> > >>> > >>> El 5 abr 2017, a las 13:20, Jakub Daniel > >>> escribió: > >>> > >>> What is the expected effect/role of CoC? Is it expected that people > would > >>> actually exhibit different behaviour because of a document? Is there a > >>> reason to believe good behaviour in other communities come from > existing > >>> CoCs? I honestly doubt people prone to violate such rules tend to read > such > >>> documents and since there is no way to enforce it, what point is there? > >>> > >>> > >>> If you'll forgive a strained metaphor: imagine you arrive in an > >>> unfamiliar land, one which has a reputation for the occasional food > fight. > >>> You're wearing nice clothes and don't want your day ruined by getting > food > >>> on them. Some restaurants have a big sign out front: "Absolutely NO > food > >>> fighting. Anyone caught food fighting will be ejected". Other > restaurants > >>> don't have the sign. When picking a place to eat, aren't you likely to > >>> gravitate to a restaurant which has a sign? > >>> > >>> Isn't the effort to maintain such a document just a waste? > >>> > >>> > >>> Hopefully it'll be very low-maintenance! > >>> > >>> Tom > >>> > >>> > >>> > >>> > >>> On 5 Apr 2017, at 20:54, amindfv at gmail.com wrote: > >>> > >>> I'm also +1 to a CoC, although have less of an opinion on what shape it > >>> should take. CoCs are an effective way of making people who may feel > like > >>> outsiders to a community feel more welcome. The Haskell community is > amazing > >>> and inclusive but not the most diverse, and projects which are doing > better > >>> on that front largely all have CoCs. > >>> > >>> In terms of what shape it takes: there are lots of off-the-shelf ones > for > >>> different needs: I'd suggest picking one of them. > >>> > >>> Tom > >>> > >>> > >>> El 5 abr 2017, a las 11:44, Paolo Giarrusso > >>> escribió: > >>> > >>> Rust's code of conduct (and the conduct of leaders) have been very > >>> successful at creating a welcoming community. However, those rules were > >>> there from the start. > >>> > >>> What's crucial is that a code of conduct is really agreed upon by a > >>> community and its elders. So thanks to Simon Peyton Jones for starting > this > >>> conversation. > >>> In particular, a CoC to address known issues (not just in the present > >>> discussion) would probably be easier to agree on. > >>> > >>> > We should *assume* people set out to be kind and courteous and help > >>> > them do that consistently. > >>> > >>> The guideline I find useful is "assume good faith" (used for instance > in > >>> Wikipedia), as long as you don't have extraordinary evidence. And > that's a > >>> guidelines that needs to be stated. > >>> Opinions on politeness in the wild are much more varied. How polite do > >>> you need to be, if somebody insists on being wrong? And with actual > trolls? > >>> > >>> > Why is the idea that "everything is a tradeoff" enshrined as a rule? > >>> > >>> I don't know if it's a strict rule there, how strict it should be, or > >>> whether it works in a CoC. But I find it a very good guideline for > educated > >>> debate. I learned it (implicitly) in my academic PL training: PL > design is > >>> founded on math but is no science yet. Debate in hard sciences is > different. > >>> > >>> Because this rule is in fact fundamental to establish respect under > >>> disagreement. The Rust CoC says "There is *seldom* a right answer." If > a > >>> question has a right answer, the others become wrong, misguided, > heretics, > >>> .... idiots... OK, you can censor the word "idiot", but that won't help > >>> much. Or you can admit that reasonable people might disagree on > `Foldable > >>> ((,) a)` (as most already agree), and give that as a guideline, just as > >>> "assume good faith". That doesn't make "2 + 2 = 5" legitimate of > course—some > >>> "common sense" is still needed. > >>> > >>> "There is *seldom* a right answer" is an unstated rule in academic > papers > >>> (where it's implied by peer review), and it IMHO works rather well > there, > >>> even on the few academics who will loudly proclaim elsewhere there is a > >>> right answer. > >>> > >>> Indeed, I don't want to misrepresent SPJ, but I feel he is often happy > to > >>> talk about Haskell tradeoffs when they're there, even when others > loudly > >>> proclaim Haskell is strictly and clearly better than X. > >>> > >>> Cheers, > >>> Paolo > >>> > >>> On Apr 3, 2017 10:55, "Tikhon Jelvis" wrote: > >>>> > >>>> Personally, I would not be against a *short and simple* code of > conduct > >>>> that specifically addresses issues we have seen. I'm imagining clear > >>>> guidelines that help people express themselves in a thoughtful and > polite > >>>> way. Something in the style of the Hacker News commenting > guidelines[1] (at > >>>> least the first four; the rest are specific to HN/Reddit-like sites). > >>>> > >>>> One of the best examples I've seen in the wild had a single rule: no > >>>> personal attacks. It's simple to understand and follow with no risk of > >>>> stifling or derailing real discussions, and yet unambiguously rules > out the > >>>> majority of rude comments I see online (ignoring spam and outright > >>>> trolling). > >>>> > >>>> I do *not* like Rust's code of conduct specifically. It does not > provide > >>>> clear guidelines on civility/politeness and covers too many other > things, > >>>> including a lot of (often political) baggage. Why is the idea that > >>>> "everything is a tradeoff" enshrined as a rule? The rule on > politeness is > >>>> clearly deemphasized: "Please be kind and courteous. There’s no need > to be > >>>> mean or rude." is so vague it may as well not be in the code of > conduct. We > >>>> should *assume* people set out to be kind and courteous and help them > do > >>>> that consistently. The "Citizen Code of Conduct" they link to has > even more > >>>> baggage and I believe it should *not* serve as the basis for anything > we > >>>> might adopt as a community. > >>>> > >>>> [1]: https://news.ycombinator.com/newsguidelines.html see section "In > >>>> Comments" > >>>> > >>>> On Mon, Apr 3, 2017 at 1:13 AM, Simon Peyton Jones via > Haskell-community > >>>> wrote: > >>>>> > >>>>> Friends > >>>>> > >>>>> > >>>>> > >>>>> I second what Tom says below. > >>>>> > >>>>> > >>>>> > >>>>> Almost everyone expresses their views with respect, even when > >>>>> disagreeing. The exceptions are (in my guess) mostly unintentional, > at > >>>>> least in the extent of the offence caused. That does not make them > >>>>> unimportant, because a slow slippage in our collective standards is, > over > >>>>> time corrosive. But it does mean that we can draw breath, as Tom has > >>>>> helpfully done here, and without condemning anyone reset our > standards. > >>>>> > >>>>> > >>>>> > >>>>> I’ve been talking to a couple of people about whether it would be > >>>>> useful to have an explicit Haskell Community Code of Conduct. Many > online > >>>>> communities have one (e.g. Rust), and it might be helpful for > everyone to > >>>>> have a concrete baseline rather than an unwritten standard. Any > views on > >>>>> that? > >>>>> > >>>>> > >>>>> > >>>>> Simon > >>>>> > >>>>> > >>>>> > >>>>> From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of > Tom > >>>>> Murphy > >>>>> Sent: 02 April 2017 19:18 > >>>>> To: Fumiaki Kinoshita > >>>>> Cc: libraries > >>>>> Subject: Civility notes (was "Traversable instances for (,,) a b") > >>>>> > >>>>> > >>>>> > >>>>> Hi Fumiaki! > >>>>> > >>>>> I agree with you that some poorly-chosen words by a few people > >>>>> have soured this conversation, but please don't let that turn you > completely > >>>>> off of the productive conversation most of us are attempting to > have! I > >>>>> think it's largely been successful, too: even if many of us haven't > changed > >>>>> our -1/+1 votes, I for one have had my ideas challenged and have a > more > >>>>> nuanced view than before talking with everyone here. > >>>>> > >>>>> Henning and Edward are two examples (one from each side of the > >>>>> +1/-1 chasm) who have been aided by this discussion, in making > important > >>>>> progress to finding a middle ground (each in the form of proposed > compiler > >>>>> changes). > >>>>> > >>>>> To the rest of us: Fumiaki regretting having posted here is a > >>>>> pretty stark example of why speaking politely matters. People being > scared > >>>>> away and feeling unwelcome is a real phenomenon, and we need to do > our part > >>>>> to fix it. I'd propose: > >>>>> > >>>>> - If you haven't read it already, SPJ recently wrote a heartfelt > >>>>> letter on the subject [0]. We've gotten better since then, but > clearly we're > >>>>> not finished. > >>>>> > >>>>> - Civility is a norm, and norms sometimes need to be enforced. > >>>>> From a distance, we all look bad (and unwelcoming!) if anyone is > hostile and > >>>>> we don't make it clear it's not acceptable. Speak up! That said, > everyone > >>>>> makes mistakes - try to give people space to apologize and move on. > >>>>> > >>>>> - If someone says something insulting to you, please take that > as > >>>>> a sign to become more polite, not less so. The downward spiral is > real. > >>>>> > >>>>> > >>>>> > >>>>> If you're called out for saying something regrettable (again, > >>>>> regardless of if you're +1 or -1 on this issue), *please* take our > desire > >>>>> for civil conversation seriously. Responses like (I'm paraphrasing, > and not > >>>>> trying to cite anyone specifically): "It was a joke (mostly)" and > "It's your > >>>>> fault if you didn't get the joke" are worse than not writing > anything at > >>>>> all. Ideal would be a quick "Sorry!" > >>>>> > >>>>> Thanks, all! > >>>>> > >>>>> Tom > >>>>> > >>>>> > >>>>> [0] > >>>>> > https://mail.haskell.org/pipermail/haskell/2016-September/024995.html > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Sun, Apr 2, 2017 at 12:11 PM, Fumiaki Kinoshita > >>>>> wrote: > >>>>> > >>>>> The discussion has diverged to flaming due to a few offensive > people. I > >>>>> guess I shouldn't have posted a proposal here, I should have > submitted a > >>>>> patch instead. > >>>>> > >>>>> > >>>>> > >>>>> 2017-03-23 19:53 GMT+09:00 Fumiaki Kinoshita : > >>>>> > >>>>> It's surprising that they are missing (forgive me, I'm not here to > make > >>>>> people grumpy). > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Libraries mailing list > >>>>> Libraries at haskell.org > >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Haskell-community mailing list > >>>>> Haskell-community at haskell.org > >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Haskell-community mailing list > >>>> Haskell-community at haskell.org > >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > >>>> > >>> _______________________________________________ > >>> Haskell-community mailing list > >>> Haskell-community at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > >>> > >>> _______________________________________________ > >>> Libraries mailing list > >>> Libraries at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >>> > >>> _______________________________________________ > >>> Libraries mailing list > >>> Libraries at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >>> > >>> > >>> _______________________________________________ > >>> Libraries mailing list > >>> Libraries at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >>> > >> > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >> > > > > > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Thu Apr 6 13:56:56 2017 From: amindfv at gmail.com (amindfv at gmail.com) Date: Thu, 6 Apr 2017 08:56:56 -0500 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: <04758EA1-43CE-4EE7-95C3-15E76BD934B5@gmail.com> I don't totally understand this viewpoint. It sounds like what you're saying is it's unfortunate that tuples (and everything else) are biased in Haskell, but because they are we're obligated to make all the legal instances we can for them. E.g. if I define a datatype "data Foo x y z", I'm powerless and sort of obligated to define "instance Functor (Foo x y)" if there's a legal one, regardless of if that's what I want Foo to mean. Tom > El 3 abr 2017, a las 15:29, Nathan Bouscal escribió: > > I expect most people probably agree that it'd be nice to have tuples be an unbiased cartesian product, but the actual fact of the matter is that tuples as they exist in Haskell are biased. We can't just ignore that and pretend they're unbiased. It definitely sucks that the answer people would naively give to "what is a tuple in Haskell" is not the correct answer, but we're stuck in that situation. The question is how to make the best of it. > >> On Mon, Apr 3, 2017 at 12:56 PM, Henning Thielemann wrote: >> >> On Mon, 3 Apr 2017, Sven Panne wrote: >> >>> Of course such an interpretation is possible, but let's remember Abelson's famous quote: >>> >>> "Programs must be written for people to read, and only incidentally for machines to execute." >>> >>> When you show somebody a pair and ask "What is this?", how many people do you *seriously* expect to say "Oh, yeah, I've seen that: It's a value on the right decorated by another one on the left!" compared to people telling you something about e.g. cartesian products (which are totally symmetric with no bias to the right or left)? The point is: Using a pair for a decorated one-element container is completely miscommunicating your intent, even if you find a sensible mathematical interpretation for it. >> >> That's what I am saying all the time. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.abel at ifi.lmu.de Thu Apr 6 13:16:12 2017 From: andreas.abel at ifi.lmu.de (Andreas Abel) Date: Thu, 6 Apr 2017 15:16:12 +0200 Subject: Civility notes (was "Traversable instances for (,,) a b") In-Reply-To: References: Message-ID: On 03.04.2017 10:42, Henning Thielemann wrote: > On Mon, 3 Apr 2017, Simon Peyton Jones via Libraries wrote: > >> I’ve been talking to a couple of people about whether it would be >> useful to have an explicit Haskell Community Code of Conduct. Many >> online communities have one (e.g. Rust), and it might be helpful for >> everyone to have a concrete baseline rather than an unwritten >> standard. Any views on that? > > I think these Code of Conducts make things even worse because then some > people start to check every word against these codes. Instead I suggest > we make more use of humor. E.g. Carter Schonwald's comment about grumpy > people made me think about renaming my prelude-compat package to > grumpy-prelude. :-) I agree with Henning. The discussion gets heated because people are passionate about Haskell; and the latter is a good thing. I rather stomach some insults on a mailing list than having a formal code of conduct. Severe violations of politeness can be pointed out without having such a formal code. We can apply common sense. -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www.cse.chalmers.se/~abela/ From ivan.miljenovic at gmail.com Thu Apr 6 13:52:48 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Thu, 6 Apr 2017 23:52:48 +1000 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: <04758EA1-43CE-4EE7-95C3-15E76BD934B5@gmail.com> References: <04758EA1-43CE-4EE7-95C3-15E76BD934B5@gmail.com> Message-ID: On 6 April 2017 at 23:56, wrote: > I don't totally understand this viewpoint. It sounds like what you're saying > is it's unfortunate that tuples (and everything else) are biased in Haskell, > but because they are we're obligated to make all the legal instances we can > for them. > > E.g. if I define a datatype "data Foo x y z", I'm powerless and sort of > obligated to define "instance Functor (Foo x y)" if there's a legal one, > regardless of if that's what I want Foo to mean. Is Foo going to be widely used or only an internal data type to your own code? > > Tom > > > El 3 abr 2017, a las 15:29, Nathan Bouscal escribió: > > I expect most people probably agree that it'd be nice to have tuples be an > unbiased cartesian product, but the actual fact of the matter is that tuples > as they exist in Haskell are biased. We can't just ignore that and pretend > they're unbiased. It definitely sucks that the answer people would naively > give to "what is a tuple in Haskell" is not the correct answer, but we're > stuck in that situation. The question is how to make the best of it. > > On Mon, Apr 3, 2017 at 12:56 PM, Henning Thielemann > wrote: >> >> >> On Mon, 3 Apr 2017, Sven Panne wrote: >> >>> Of course such an interpretation is possible, but let's remember >>> Abelson's famous quote: >>> >>> "Programs must be written for people to read, and only incidentally >>> for machines to execute." >>> >>> When you show somebody a pair and ask "What is this?", how many people do >>> you *seriously* expect to say "Oh, yeah, I've seen that: It's a value on the >>> right decorated by another one on the left!" compared to people telling you >>> something about e.g. cartesian products (which are totally symmetric with no >>> bias to the right or left)? The point is: Using a pair for a decorated >>> one-element container is completely miscommunicating your intent, even if >>> you find a sensible mathematical interpretation for it. >> >> >> That's what I am saying all the time. >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From amindfv at gmail.com Thu Apr 6 19:18:35 2017 From: amindfv at gmail.com (amindfv at gmail.com) Date: Thu, 6 Apr 2017 14:18:35 -0500 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: <04758EA1-43CE-4EE7-95C3-15E76BD934B5@gmail.com> Message-ID: > El 6 abr 2017, a las 08:52, Ivan Lazar Miljenovic escribió: > >> On 6 April 2017 at 23:56, wrote: >> I don't totally understand this viewpoint. It sounds like what you're saying >> is it's unfortunate that tuples (and everything else) are biased in Haskell, >> but because they are we're obligated to make all the legal instances we can >> for them. >> >> E.g. if I define a datatype "data Foo x y z", I'm powerless and sort of >> obligated to define "instance Functor (Foo x y)" if there's a legal one, >> regardless of if that's what I want Foo to mean. > > Is Foo going to be widely used or only an internal data type to your own code? > For the sake of comparison, let's say it's going to be widely used. It's also a structure which isn't (conceptually) biased. If we're starting from a place of feeling that it's a shame Haskell is unable to have unbiased structures, then probably an "if we knew then what we know now" version of Haskell would have them. So then why knowingly create instances we think a "better Haskell" wouldn't have? Is the argument that if it's public-facing, someone's going to define the instance and so we should do it canonically? If so, this feels to me a little like "you can't fire me, I quit!" - doing what we don't want before someone else has a chance to. Tom >> >> Tom >> >> >> El 3 abr 2017, a las 15:29, Nathan Bouscal escribió: >> >> I expect most people probably agree that it'd be nice to have tuples be an >> unbiased cartesian product, but the actual fact of the matter is that tuples >> as they exist in Haskell are biased. We can't just ignore that and pretend >> they're unbiased. It definitely sucks that the answer people would naively >> give to "what is a tuple in Haskell" is not the correct answer, but we're >> stuck in that situation. The question is how to make the best of it. >> >> On Mon, Apr 3, 2017 at 12:56 PM, Henning Thielemann >> wrote: >>> >>> >>>> On Mon, 3 Apr 2017, Sven Panne wrote: >>>> >>>> Of course such an interpretation is possible, but let's remember >>>> Abelson's famous quote: >>>> >>>> "Programs must be written for people to read, and only incidentally >>>> for machines to execute." >>>> >>>> When you show somebody a pair and ask "What is this?", how many people do >>>> you *seriously* expect to say "Oh, yeah, I've seen that: It's a value on the >>>> right decorated by another one on the left!" compared to people telling you >>>> something about e.g. cartesian products (which are totally symmetric with no >>>> bias to the right or left)? The point is: Using a pair for a decorated >>>> one-element container is completely miscommunicating your intent, even if >>>> you find a sensible mathematical interpretation for it. >>> >>> >>> That's what I am saying all the time. >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com From nbouscal at gmail.com Thu Apr 6 22:48:53 2017 From: nbouscal at gmail.com (Nathan Bouscal) Date: Thu, 06 Apr 2017 22:48:53 +0000 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: <04758EA1-43CE-4EE7-95C3-15E76BD934B5@gmail.com> Message-ID: It *is* actually a useful instance and it is used in practice. It's not that better Haskell wouldn't have an biased pair type with these instances, it's that it would *also* have an unbiased one with the instances that such a type could support. The issue seems to be that people don't like the biased type having special syntax that wrongly gives an unknowing reader the impression that the type is unbiased. This is a reasonable position, but getting rid of the tuple instances isn't a reasonable way to act on that position: 1) they're going to be defined anyway, but also 2) it's not helpful to just pretend the type is unbiased when it isn't. It would be coherent to argue for the removal of the special tuple syntax (though coherent doesn't mean reasonable; this would break everything), but it's not coherent to argue for crippling tuples so we can pretend they're something they aren't. On Thu, Apr 6, 2017 at 11:17 AM wrote: > > > > El 6 abr 2017, a las 08:52, Ivan Lazar Miljenovic < > ivan.miljenovic at gmail.com> escribió: > > > >> On 6 April 2017 at 23:56, wrote: > >> I don't totally understand this viewpoint. It sounds like what you're > saying > >> is it's unfortunate that tuples (and everything else) are biased in > Haskell, > >> but because they are we're obligated to make all the legal instances we > can > >> for them. > >> > >> E.g. if I define a datatype "data Foo x y z", I'm powerless and sort of > >> obligated to define "instance Functor (Foo x y)" if there's a legal one, > >> regardless of if that's what I want Foo to mean. > > > > Is Foo going to be widely used or only an internal data type to your own > code? > > > > For the sake of comparison, let's say it's going to be widely used. It's > also a structure which isn't (conceptually) biased. > > If we're starting from a place of feeling that it's a shame Haskell is > unable to have unbiased structures, then probably an "if we knew then what > we know now" version of Haskell would have them. So then why knowingly > create instances we think a "better Haskell" wouldn't have? > > Is the argument that if it's public-facing, someone's going to define the > instance and so we should do it canonically? If so, this feels to me a > little like "you can't fire me, I quit!" - doing what we don't want before > someone else has a chance to. > > Tom > > > >> > >> Tom > >> > >> > >> El 3 abr 2017, a las 15:29, Nathan Bouscal > escribió: > >> > >> I expect most people probably agree that it'd be nice to have tuples be > an > >> unbiased cartesian product, but the actual fact of the matter is that > tuples > >> as they exist in Haskell are biased. We can't just ignore that and > pretend > >> they're unbiased. It definitely sucks that the answer people would > naively > >> give to "what is a tuple in Haskell" is not the correct answer, but > we're > >> stuck in that situation. The question is how to make the best of it. > >> > >> On Mon, Apr 3, 2017 at 12:56 PM, Henning Thielemann > >> wrote: > >>> > >>> > >>>> On Mon, 3 Apr 2017, Sven Panne wrote: > >>>> > >>>> Of course such an interpretation is possible, but let's remember > >>>> Abelson's famous quote: > >>>> > >>>> "Programs must be written for people to read, and only incidentally > >>>> for machines to execute." > >>>> > >>>> When you show somebody a pair and ask "What is this?", how many > people do > >>>> you *seriously* expect to say "Oh, yeah, I've seen that: It's a value > on the > >>>> right decorated by another one on the left!" compared to people > telling you > >>>> something about e.g. cartesian products (which are totally symmetric > with no > >>>> bias to the right or left)? The point is: Using a pair for a decorated > >>>> one-element container is completely miscommunicating your intent, > even if > >>>> you find a sensible mathematical interpretation for it. > >>> > >>> > >>> That's what I am saying all the time. > >>> _______________________________________________ > >>> Libraries mailing list > >>> Libraries at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >> > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > > > > -- > > Ivan Lazar Miljenovic > > Ivan.Miljenovic at gmail.com > > http://IvanMiljenovic.wordpress.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanuki at gmail.com Fri Apr 7 04:26:20 2017 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Thu, 6 Apr 2017 21:26:20 -0700 Subject: Civility notes (was "Traversable instances for (,,) a b") In-Reply-To: References: Message-ID: I'm also -1 to an explicit code of conduct. Sure, once in a while someone has to step in with Wheaton's Law or what I can't resist calling Simon Says; but all it takes is a gentle reminder. Nobody here is genuinely contemptuous toward anyone else. The barrier of entry is too high -- the trolls are happy enough on reddit. ;) On Apr 6, 2017 6:17 AM, "Andreas Abel" wrote: On 03.04.2017 10:42, Henning Thielemann wrote: > On Mon, 3 Apr 2017, Simon Peyton Jones via Libraries wrote: > > I’ve been talking to a couple of people about whether it would be >> useful to have an explicit Haskell Community Code of Conduct. Many >> online communities have one (e.g. Rust), and it might be helpful for >> everyone to have a concrete baseline rather than an unwritten >> standard. Any views on that? >> > > I think these Code of Conducts make things even worse because then some > people start to check every word against these codes. Instead I suggest > we make more use of humor. E.g. Carter Schonwald's comment about grumpy > people made me think about renaming my prelude-compat package to > grumpy-prelude. :-) > I agree with Henning. The discussion gets heated because people are passionate about Haskell; and the latter is a good thing. I rather stomach some insults on a mailing list than having a formal code of conduct. Severe violations of politeness can be pointed out without having such a formal code. We can apply common sense. -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel at gu.se http://www.cse.chalmers.se/~abela/ _______________________________________________ Libraries mailing list Libraries at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Fri Apr 7 06:51:41 2017 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Fri, 7 Apr 2017 09:51:41 +0300 Subject: Package maintainership takeover: quickcheck-instances Message-ID: The quickcheck-instances provides QuickCheck type-classes' instances for Haskell Platform packages. Unfortunately, author and current maintainer Antoine Latter is quite unresponsive. There is handful of PR open [2], and I had to use Hackage Trustee powers to allow new versions of dependencies (to keep e.g. Stackage nightly going on). I have tried to contact him to offer a co-maintainership help (at 14.12.2016). Cheers, Oleg Grenrus - [1]: http://hackage.haskell.org/package/quickcheck-instances - [2]: https://github.com/aslatter/qc-instances/pulls -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From carter.schonwald at gmail.com Fri Apr 7 12:54:43 2017 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 07 Apr 2017 12:54:43 +0000 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: <04758EA1-43CE-4EE7-95C3-15E76BD934B5@gmail.com> Message-ID: Bifunctor and or new types for Swap / Flip style combinators seem to allow roving parameters for functor. It's not pretty but it works. On Thu, Apr 6, 2017 at 6:49 PM Nathan Bouscal wrote: > It *is* actually a useful instance and it is used in practice. It's not > that better Haskell wouldn't have an biased pair type with these instances, > it's that it would *also* have an unbiased one with the instances that such > a type could support. The issue seems to be that people don't like the > biased type having special syntax that wrongly gives an unknowing reader > the impression that the type is unbiased. This is a reasonable position, > but getting rid of the tuple instances isn't a reasonable way to act on > that position: 1) they're going to be defined anyway, but also 2) it's not > helpful to just pretend the type is unbiased when it isn't. It would be > coherent to argue for the removal of the special tuple syntax (though > coherent doesn't mean reasonable; this would break everything), but it's > not coherent to argue for crippling tuples so we can pretend they're > something they aren't. > > > On Thu, Apr 6, 2017 at 11:17 AM wrote: > > > > > El 6 abr 2017, a las 08:52, Ivan Lazar Miljenovic < > ivan.miljenovic at gmail.com> escribió: > > > >> On 6 April 2017 at 23:56, wrote: > >> I don't totally understand this viewpoint. It sounds like what you're > saying > >> is it's unfortunate that tuples (and everything else) are biased in > Haskell, > >> but because they are we're obligated to make all the legal instances we > can > >> for them. > >> > >> E.g. if I define a datatype "data Foo x y z", I'm powerless and sort of > >> obligated to define "instance Functor (Foo x y)" if there's a legal one, > >> regardless of if that's what I want Foo to mean. > > > > Is Foo going to be widely used or only an internal data type to your own > code? > > > > For the sake of comparison, let's say it's going to be widely used. It's > also a structure which isn't (conceptually) biased. > > If we're starting from a place of feeling that it's a shame Haskell is > unable to have unbiased structures, then probably an "if we knew then what > we know now" version of Haskell would have them. So then why knowingly > create instances we think a "better Haskell" wouldn't have? > > Is the argument that if it's public-facing, someone's going to define the > instance and so we should do it canonically? If so, this feels to me a > little like "you can't fire me, I quit!" - doing what we don't want before > someone else has a chance to. > > Tom > > > >> > >> Tom > >> > >> > >> El 3 abr 2017, a las 15:29, Nathan Bouscal > escribió: > >> > >> I expect most people probably agree that it'd be nice to have tuples be > an > >> unbiased cartesian product, but the actual fact of the matter is that > tuples > >> as they exist in Haskell are biased. We can't just ignore that and > pretend > >> they're unbiased. It definitely sucks that the answer people would > naively > >> give to "what is a tuple in Haskell" is not the correct answer, but > we're > >> stuck in that situation. The question is how to make the best of it. > >> > >> On Mon, Apr 3, 2017 at 12:56 PM, Henning Thielemann > >> wrote: > >>> > >>> > >>>> On Mon, 3 Apr 2017, Sven Panne wrote: > >>>> > >>>> Of course such an interpretation is possible, but let's remember > >>>> Abelson's famous quote: > >>>> > >>>> "Programs must be written for people to read, and only incidentally > >>>> for machines to execute." > >>>> > >>>> When you show somebody a pair and ask "What is this?", how many > people do > >>>> you *seriously* expect to say "Oh, yeah, I've seen that: It's a value > on the > >>>> right decorated by another one on the left!" compared to people > telling you > >>>> something about e.g. cartesian products (which are totally symmetric > with no > >>>> bias to the right or left)? The point is: Using a pair for a decorated > >>>> one-element container is completely miscommunicating your intent, > even if > >>>> you find a sensible mathematical interpretation for it. > >>> > >>> > >>> That's what I am saying all the time. > >>> _______________________________________________ > >>> Libraries mailing list > >>> Libraries at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >> > >> > >> _______________________________________________ > >> Libraries mailing list > >> Libraries at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > > > > > > -- > > Ivan Lazar Miljenovic > > Ivan.Miljenovic at gmail.com > > http://IvanMiljenovic.wordpress.com > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Sat Apr 8 01:36:16 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sat, 08 Apr 2017 13:36:16 +1200 Subject: Constraints on definition of `length` should be strengthened Message-ID: <58e83e90.29b.5c89.4434@clear.net.nz> > On Wed Apr 5 16:15:48 UTC 2017, Paolo Giarrusso wrote: > Thanks for all the mails, but I'm still missing an answer, > so I must have done something wrong. :-) Thanks Paolo, you've done nothing wrong IMHO. You've done the community a service by pointing out an omission in the docos. It's the same failure to communicate clearly that's given rise to the whole FTP kerfuffle. > I guess I didn't explain my question well. > Or nobody thinks it's worth answering (in which case, sorry, but I'd > prefer to be told I'm misguided, over having the question ignored). I think your original question was clear. I think it is very well worth answering. That is: answering what are the 'Laws' for Foldable? I've been waiting patiently for Libraries HQ to: * explain the applicable Laws * acknowledge they're not doco'd * volunteer to fix that > ... I'm really asking a different question: do length docs actually > give a complete specification—it still seems to me they don't. I agree they don't. > ... > But that's very confusing: can really debate on `length (a, b) = 1` > have continued for so long, without noticing that `length = getSum . > foldMap (Sum . const 1)` is a fundamental assumption and is not > mandated by anything written down? I assume I must be missing > something, which is why I asked. The only reply I've seen [from David F, you copied below, apologies if I've missed others] doesn't give any "fundamental assumption". It only says "should be quite well-behaved" and "pretty much everybody agrees on". I'm not 'getting at' David, at least he answered. I agree with your intuition that Foldable length = length . toList But that just pushes the question back to what are the Laws for `toList`? Note that `toList` has been in Foldable 'for ever'. And instance Foldable Maybe 'for ever'. That returns a 0-or-1 length list. Contrast that `instance Foldable ((,) b)` appeared in GHC 7.8 ~2014, along with `instance Foldable Either`. > Of all incomplete docs, this matters more > since `length (a, b)` is so surprising. I'd say the surprising bit is `toList (a, b)`. `length` is just a consequence. Cue another long thread on `toList`. I'm inclined to agree with Edward K, that there's only one possible definition for `toList` -- that is, if we accept `instance Foldable ((,) b). Cue another long thread on tuple instances, and the Either instance. > The unsuspecting looking at docs lacks the facts needed to > infer this wart. Spelling out implications would IMHO be even better, > for the same reason people state theorems even though they can be > proved, but maybe some disagree. A complete spec would be a starting > point. Yes. In particular, the conspicuous lack of docos is now wildly at variance with all the tutorial/intro texts, which explain `length` as for Lists. I plain think that `length` should be Lists-only; there should be some other name for Foldable's size. >>> On 3 April 2017 at 17:59, David Feuer wrote: >>> length should be quite well-behaved relative to foldMap: >>> >>> length = getSum . foldMap (Sum . const 1) >> Thanks, that looks useful to add to docs. I was thinking of `length = >> length . toList`. >>> Another law pretty much everyone agrees on is that *if* f is an instance of >>> Traversable, then >>> >>> foldMap = foldMapDefault AntC From anthony_clayden at clear.net.nz Sat Apr 8 02:03:32 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sat, 08 Apr 2017 14:03:32 +1200 Subject: Constraints on definition of `length` should be strengthened Message-ID: <58e844f4.307.12b8.26783@clear.net.nz> > On Tue Apr 4 06:50:55 UTC 2017, Sven Panne wrote: >> 2017-04-04 8:15 GMT+02:00 Vladislav Zavialov: >>> Tuples are unbiased cartesian products, full stop. >> >> This statement is not correct. > According to probably all the math books in the world, > the statement is correct, > at least if we want to see tuples as cartesian products. .. Sven, I have a lot of sympathy with the digruntlement about Foldable `length` over tuples. But if you're going to start appealing to math, you'd better get your math correct. Whether or not tuples are unbiased, even wikipedia will tell you they're not commutative. So to take your examples from an earlier thread, what do you expect Haskell to do here?: maximum (True,2) => ? minimum ((3, 4),5) => ? -- i.e. :: ((Int, Int), Int) sum (7,3.14) => ? -- i.e. :: (Int, Double) product (Left $ error "Errk") => ? -- i.e. :: Either e Int Do you expect Foldable (a, a) to behave differently vs Foldable (b, a) vs Foldable ((a, a), a) vs ...? Let's get everybody agreed on that. Then we can talk about our currying/kind system. Note that there's been an `instance Foldable Maybe` for ever, and `toList` applied to that returns a 0-or-1 length list. >> Look at their kind: >> >> > :k (,) >> > (,) :: * -> * -> * >> >> The same currying business is going on here. [...] > That's an artifact of our kind system, > not a consequence of the usual definition of cartesian products. AntC From tonymorris at gmail.com Sat Apr 8 02:27:13 2017 From: tonymorris at gmail.com (Tony Morris) Date: Sat, 8 Apr 2017 12:27:13 +1000 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: <58e83e90.29b.5c89.4434@clear.net.nz> References: <58e83e90.29b.5c89.4434@clear.net.nz> Message-ID: <7c63ea57-81a0-e45c-d589-7a55a15314f6@gmail.com> On 08/04/17 11:36, Anthony Clayden wrote: > Contrast that `instance Foldable ((,) b)` > appeared in GHC 7.8 ~2014, > along with `instance Foldable Either`. FWIW, both of these appeared in Functional Java in 2003 and Scalaz, in 2005. I haven't properly followed this thread, so I am unsure what questions were raised. Sorry if it was relevant to our other discussions and I have ignored it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From ben.franksen at online.de Sat Apr 8 22:53:36 2017 From: ben.franksen at online.de (Ben Franksen) Date: Sun, 9 Apr 2017 00:53:36 +0200 Subject: Civility notes (was "Traversable instances for (,,) a b") In-Reply-To: References: Message-ID: Same here, couldn't say it better. Am 07.04.2017 um 06:26 schrieb Theodore Lief Gannon: > I'm also -1 to an explicit code of conduct. Sure, once in a while someone > has to step in with Wheaton's Law or what I can't resist calling Simon > Says; but all it takes is a gentle reminder. Nobody here is genuinely > contemptuous toward anyone else. The barrier of entry is too high -- the > trolls are happy enough on reddit. ;) > > On Apr 6, 2017 6:17 AM, "Andreas Abel" wrote: > > On 03.04.2017 10:42, Henning Thielemann wrote: > >> On Mon, 3 Apr 2017, Simon Peyton Jones via Libraries wrote: >> >> I’ve been talking to a couple of people about whether it would be >>> useful to have an explicit Haskell Community Code of Conduct. Many >>> online communities have one (e.g. Rust), and it might be helpful for >>> everyone to have a concrete baseline rather than an unwritten >>> standard. Any views on that? >>> >> >> I think these Code of Conducts make things even worse because then some >> people start to check every word against these codes. Instead I suggest >> we make more use of humor. E.g. Carter Schonwald's comment about grumpy >> people made me think about renaming my prelude-compat package to >> grumpy-prelude. :-) >> > > I agree with Henning. The discussion gets heated because people are > passionate about Haskell; and the latter is a good thing. > > I rather stomach some insults on a mailing list than having a formal code > of conduct. Severe violations of politeness can be pointed out without > having such a formal code. We can apply common sense. > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From ben.franksen at online.de Sat Apr 8 23:05:58 2017 From: ben.franksen at online.de (Ben Franksen) Date: Sun, 9 Apr 2017 01:05:58 +0200 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: <04758EA1-43CE-4EE7-95C3-15E76BD934B5@gmail.com> Message-ID: Am 06.04.2017 um 21:18 schrieb amindfv at gmail.com: >>> On 6 April 2017 at 23:56, wrote: I don't >>> totally understand this viewpoint. It sounds like what you're >>> saying is it's unfortunate that tuples (and everything else) are >>> biased in Haskell, but because they are we're obligated to make >>> all the legal instances we can for them. >>> >>> E.g. if I define a datatype "data Foo x y z", I'm powerless and >>> sort of obligated to define "instance Functor (Foo x y)" if >>> there's a legal one, regardless of if that's what I want Foo to >>> mean. >> >> Is Foo going to be widely used or only an internal data type to >> your own code? >> > > For the sake of comparison, let's say it's going to be widely used. > It's also a structure which isn't (conceptually) biased. > > If we're starting from a place of feeling that it's a shame Haskell > is unable to have unbiased structures, then probably an "if we knew > then what we know now" version of Haskell would have them. So then > why knowingly create instances we think a "better Haskell" wouldn't > have? > > Is the argument that if it's public-facing, someone's going to define > the instance and so we should do it canonically? If so, this feels to > me a little like "you can't fire me, I quit!" - doing what we don't > want before someone else has a chance to. I think the situation is analogous to honoring class laws. There is no way in Haskell to enforce them. But there is an unwritten code of conduct (sic!) for library writers, to define only (public) instances that adhere to the stated laws. Why can't we not state that a certain data type is intended to by symmetric in its arguments? And expect that others respect that intent and refrain from defining asymmetric Functor, Foldable, etc instances for it? Cheers Ben From ben.franksen at online.de Sat Apr 8 23:28:04 2017 From: ben.franksen at online.de (Ben Franksen) Date: Sun, 9 Apr 2017 01:28:04 +0200 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: <04758EA1-43CE-4EE7-95C3-15E76BD934B5@gmail.com> Message-ID: Am 07.04.2017 um 00:48 schrieb Nathan Bouscal: > It *is* actually a useful instance and it is used in practice. It's not > that better Haskell wouldn't have an biased pair type with these instances, > it's that it would *also* have an unbiased one with the instances that such > a type could support. Nobody (I think) claimed that the biased type isn't useful. We merely discuss whether it would not be more useful to define new types for that with names that convey the intent, and leave (,) and Either unbiased as their name (and special notation) suggests. > The issue seems to be that people don't like the > biased type having special syntax that wrongly gives an unknowing reader > the impression that the type is unbiased. This is not the only reason, see above. > This is a reasonable position, > but getting rid of the tuple instances isn't a reasonable way to act on > that position: 1) they're going to be defined anyway, Would you say the same for non-law-abiding instances for, say, class Monad? > but also 2) it's not > helpful to just pretend the type is unbiased when it isn't. We are used to pretend a lot in Haskell. We cannot capture all properties in types, but we expect them to hold nevertheless. Are you saying that this is bad because, well someone is going to come and define a Monad instance that doesn't obey the laws anyway, so let's not pretend the Monad laws hold? > It would be > coherent to argue for the removal of the special tuple syntax (though > coherent doesn't mean reasonable; this would break everything), but it's > not coherent to argue for crippling tuples so we can pretend they're > something they aren't. Pretending that a thing is actually something other than it really is is the whole idea of high level languages. All data and code are just bits in the end. You can enforce certain re-interpretations of these bits using a type system. But what matters is that we intend a Char to be a character and consciously avoid asking "what it really is" i.e. how it is represented. Cheers Ben From nbouscal at gmail.com Sat Apr 8 23:51:13 2017 From: nbouscal at gmail.com (Nathan Bouscal) Date: Sat, 8 Apr 2017 16:51:13 -0700 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: <04758EA1-43CE-4EE7-95C3-15E76BD934B5@gmail.com> Message-ID: - The message I was directly responding to included the phrases 'instances we think a "better Haskell" wouldn't have' and 'doing what we don't want before someone else has a chance to'. That's what I was responding to when I said that the instances are useful. - You're trying to establish an analogy between these tuple instances and non-law-abiding instances, but that analogy really doesn't work. These are the only law-abiding instances that the types can possibly have. When I claim something is a Monad, I'm saying that if the compiler knew how to take a proof, I'd be able to provide one. When you claim tuples are unbiased, there is no analogous statement. You can't say that you'd be able to provide a proof that tuples are unbiased, because they *aren't* unbiased. - A lot of these arguments are taking the form "let's have unbiased tuples", but the actual impact of just removing the instances wouldn't be unbiased tuples, it would be a crippled biased tuple. Getting rid of the instances wouldn't make tuples any less biased, it would just take away useful functionality. Suggestions like Vladislav's of implementing an actual unbiased tuple are more reasonable (though as pointed out, they'd break *tons* of code, so still not that reasonable). On Sat, Apr 8, 2017 at 4:28 PM, Ben Franksen wrote: > Am 07.04.2017 um 00:48 schrieb Nathan Bouscal: > > It *is* actually a useful instance and it is used in practice. It's not > > that better Haskell wouldn't have an biased pair type with these > instances, > > it's that it would *also* have an unbiased one with the instances that > such > > a type could support. > > Nobody (I think) claimed that the biased type isn't useful. We merely > discuss whether it would not be more useful to define new types for that > with names that convey the intent, and leave (,) and Either unbiased as > their name (and special notation) suggests. > > > The issue seems to be that people don't like the > > biased type having special syntax that wrongly gives an unknowing reader > > the impression that the type is unbiased. > > This is not the only reason, see above. > > > This is a reasonable position, > > but getting rid of the tuple instances isn't a reasonable way to act on > > that position: 1) they're going to be defined anyway, > > Would you say the same for non-law-abiding instances for, say, class Monad? > > > but also 2) it's not > > helpful to just pretend the type is unbiased when it isn't. > > We are used to pretend a lot in Haskell. We cannot capture all > properties in types, but we expect them to hold nevertheless. Are you > saying that this is bad because, well someone is going to come and > define a Monad instance that doesn't obey the laws anyway, so let's not > pretend the Monad laws hold? > > > It would be > > coherent to argue for the removal of the special tuple syntax (though > > coherent doesn't mean reasonable; this would break everything), but it's > > not coherent to argue for crippling tuples so we can pretend they're > > something they aren't. > > Pretending that a thing is actually something other than it really is is > the whole idea of high level languages. All data and code are just bits > in the end. You can enforce certain re-interpretations of these bits > using a type system. But what matters is that we intend a Char to be a > character and consciously avoid asking "what it really is" i.e. how it > is represented. > > Cheers > Ben > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.franksen at online.de Sun Apr 9 00:01:35 2017 From: ben.franksen at online.de (Ben Franksen) Date: Sun, 9 Apr 2017 02:01:35 +0200 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: <58e844f4.307.12b8.26783@clear.net.nz> References: <58e844f4.307.12b8.26783@clear.net.nz> Message-ID: Am 08.04.2017 um 04:03 schrieb Anthony Clayden: >> On Tue Apr 4 06:50:55 UTC 2017, Sven Panne wrote: >>> 2017-04-04 8:15 GMT+02:00 Vladislav Zavialov: >>>> Tuples are unbiased cartesian products, full stop. >>> >>> This statement is not correct. > >> According to probably all the math books in the world, >> the statement is correct, >> at least if we want to see tuples as cartesian products. > .. > > Sven, I have a lot of sympathy with the digruntlement about > Foldable `length` over tuples. > But if you're going to start appealing to math, > you'd better get your math correct. > > Whether or not tuples are unbiased, > even wikipedia will tell you they're not commutative. > > So to take your examples from an earlier thread, > what do you expect Haskell to do here?: > > maximum (True,2) => ? > minimum ((3, 4),5) => ? -- i.e. :: ((Int, Int), Int) > sum (7,3.14) => ? -- i.e. :: (Int, Double) > product (Left $ error "Errk") => ? -- i.e. :: > Either e Int I (and others) think these should be type errors. > Do you expect Foldable (a, a) to behave differently > vs Foldable (b, a) vs Foldable ((a, a), a) vs ...? > > Let's get everybody agreed on that. It would be nice if we could all agree on removing these instances. BTW, I find it remarkable that of those who defend these instances, few seem to be especially interested in clarifying the OP's question: what laws exactly do we expect for Foldable? It has been stated that "obviously" length (1,2) must be 1 ("what else could it be?"). This suggests that there is a law for length that makes this obvious and its ommision in the docs was just an oversight. Cheers Ben From Henrik.Nilsson at nottingham.ac.uk Sun Apr 9 00:29:43 2017 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Sun, 09 Apr 2017 01:29:43 +0100 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: <04758EA1-43CE-4EE7-95C3-15E76BD934B5@gmail.com> Message-ID: <58E98077.8030106@exmail.nottingham.ac.uk> On 04/09/2017 12:51 AM, Nathan Bouscal wrote: > - You're trying to establish an analogy between these tuple instances > and non-law-abiding instances, but that analogy really doesn't work. > These are the only law-abiding instances that the types can possibly have. Yes. But that is, actually, more of a syntactic accident than any deeply mathematical property: mathematically, there are n ways to make an n-tuple a functor, And if we, for "consistency", continue to add functor instances for tuples for n > 2, the situation, in the view of many reasonable people at least, becomes increasingly absurd, or at least it becomes increasingly clear that that the utility we get is a smaller and smaller part of what we really need. Simply because tuples actually are "morally unbiased", as Vladislav Zavialov phrased it; i.e., there are perfectly legitimate uses where the fields are of equal importance: there is no a priori "pay load" field, and no a priori "annotation" fields. And in fact, that is *exactly* what tuples originally were in Haskell, and how many very reasonably people still prefers to think about them. And of course, if, in a hypothetical future version of Haskell where we could make all possible functor instances for tuples, the question becomes: which one do we pick? The answer might well be "none" (in the prelude, at least). (A newtype wrapper approach, e.g. a la numeric Monid instances, would be both unpalatable and ultimately pointless.) So, in summary, I'd find the argument for the present tuple instances much more compelling if it *mathematically* were the case that the only law-abiding instances are those ones. But that is not the case. Best, /Henrik This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From ben.franksen at online.de Sun Apr 9 00:31:44 2017 From: ben.franksen at online.de (Ben Franksen) Date: Sun, 9 Apr 2017 02:31:44 +0200 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: <04758EA1-43CE-4EE7-95C3-15E76BD934B5@gmail.com> Message-ID: Am 09.04.2017 um 01:51 schrieb Nathan Bouscal: > - You're trying to establish an analogy between these tuple instances and > non-law-abiding instances, but that analogy really doesn't work. These are > the only law-abiding instances that the types can possibly have. When I > claim something is a Monad, I'm saying that if the compiler knew how to > take a proof, I'd be able to provide one. When you claim tuples are unbiased, I do not claim tuples *are* unbiased. I have been (espressly) talking about intent. A programming language is a tool designed by humans, not an artefact of nature. Whatever tuples are, factually, is not important. The only important thing is what we *want* them to be. Of course we want our intents to be consistent, but I don't see how ignoring the (unavoidable) bias violates consistency. > there is no analogous statement. You can't say that you'd be able > to provide a proof that tuples are unbiased, because they *aren't* unbiased. You can't prove that instances of Monad adhere to the Monad laws, in general. But you can (informally) express your intent that instances *should* adhere to the laws. Yes, for a single concrete instance you can provide proof that the laws are fulfilled. And for a single concrete program (or library, or module, or function) that uses tuples I can prove that it does not depend on the (existing, but not intended) bias for tuples. > - A lot of these arguments are taking the form "let's have unbiased > tuples", but the actual impact of just removing the instances wouldn't be > unbiased tuples, Again, you argue as if we were talking about a mechanical system. The "impact" in this case depends on people's behavior and expectations. We are talking about *designing* library infrastructure. > it would be a crippled biased tuple. Getting rid of the > instances wouldn't make tuples any less biased, it would just take away > useful functionality. And this is where we differ: IMO it would take away functionality that is confusing and ill-termed. The desired functionality is not bad perse, but would be much better provided by dedicated data types that clearly express the intent of using the bias induces by currying and left to right order of type arguments. The tuples with reduced functionality would be more useful, not less, because one could rely on them not acting in strange and unexpected ways. See the many examples that people provided for refactoring code that uses tuples and where the type error was the intended and expected behavior and the "functionality" provided by Foldable instances was in fact dysfunctional. Cheers Ben From tonymorris at gmail.com Sun Apr 9 00:36:02 2017 From: tonymorris at gmail.com (Tony Morris) Date: Sun, 9 Apr 2017 10:36:02 +1000 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: <58E98077.8030106@exmail.nottingham.ac.uk> References: <04758EA1-43CE-4EE7-95C3-15E76BD934B5@gmail.com> <58E98077.8030106@exmail.nottingham.ac.uk> Message-ID: <17dfc90a-612d-13e2-94cc-bdc7b4429a08@gmail.com> Already done mate. https://hackage.haskell.org/package/hask-0/docs/Hask-Category.html#t:Either https://hackage.haskell.org/package/hask-0/docs/Hask-Category.html#t:Functor Note the multiple Functor instances for Either and Coproduct. e.g. - Functor * (* -> *) Either - Functor * * (Either a) etc etc On 09/04/17 10:29, Henrik Nilsson wrote: > And of course, if, in a hypothetical future version of Haskell > where we could make all possible functor instances for tuples, > the question becomes: which one do we pick? The answer might well > be "none" (in the prelude, at least). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From jon.fairbairn at cl.cam.ac.uk Sun Apr 9 09:48:37 2017 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Sun, 09 Apr 2017 10:48:37 +0100 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> Message-ID: Tony Morris writes: > I don't think it is the "appropriate" set. It's an example. 0 is in the > set of integers. The value 0 is in many sets. OK, so I clearly do not understand your argument. The implication I took from “and 0 is not an integer” is that the foldable instance for ((,) a) should be present because it is the zero case of something that has integers as its domain, and I wanted to know what that something is. If this was not the intention of your argument, what was? -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2014-04-05) From tonymorris at gmail.com Sun Apr 9 12:26:12 2017 From: tonymorris at gmail.com (Tony Morris) Date: Sun, 9 Apr 2017 22:26:12 +1000 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> Message-ID: <4a153c75-79f1-77f8-866d-7459ecb9d61c@gmail.com> These two things are true: * 0 is in the set of integers * ∀ a. ((,) a) is Foldable, and as one of many consequences, the length of all values in the set ∀ a. ((,) a) is 1. There are four possible positions to take on these claims: 1. Both are true. 2. Both are false. 3. The first true and second false. 4. The second true and the first false. I respect arguments 1 and 2. If I chose 1 and you chose 2, I'd say "well rightio then mate and cheers to that", we'd clink glasses and move on. Same if it were vice versa. I do not have the same respect for positions 3 and 4. On 09/04/17 19:48, Jon Fairbairn wrote: > Tony Morris writes: > >> I don't think it is the "appropriate" set. It's an example. 0 is in the >> set of integers. The value 0 is in many sets. > OK, so I clearly do not understand your argument. The > implication I took from “and 0 is not an integer” is that the > foldable instance for ((,) a) should be present because it is > the zero case of something that has integers as its domain, and > I wanted to know what that something is. If this was not the > intention of your argument, what was? > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From benno.fuenfstueck at gmail.com Sun Apr 9 14:29:43 2017 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Sun, 09 Apr 2017 14:29:43 +0000 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <4a153c75-79f1-77f8-866d-7459ecb9d61c@gmail.com> References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <4a153c75-79f1-77f8-866d-7459ecb9d61c@gmail.com> Message-ID: Correct me I I'm wrong but I believe Tony Morris is saying the following: * not every operation defined for the integers "makes sense" for all integers. Example: '/' does not make sense in the case of 'x / 0' * yet, we still include '0' in the integers even though not every operation makes sense for '0' * -> not every operation in Foldable makes sense for `(,) a` * -> but we also include `0` in the integers, so "not every operation makes sense" is not an argument to exclude `(,) a` from being foldable, just as `0` is not excluded from the integers. Kind regards, Benno Tony Morris schrieb am So., 9. Apr. 2017 um 14:26 Uhr: > These two things are true: > > * 0 is in the set of integers > * ∀ a. ((,) a) is Foldable, and as one of many consequences, the length > of all values in the set ∀ a. ((,) a) is 1. > > There are four possible positions to take on these claims: > > 1. Both are true. > 2. Both are false. > 3. The first true and second false. > 4. The second true and the first false. > > I respect arguments 1 and 2. If I chose 1 and you chose 2, I'd say "well > rightio then mate and cheers to that", we'd clink glasses and move on. > Same if it were vice versa. > > I do not have the same respect for positions 3 and 4. > > On 09/04/17 19:48, Jon Fairbairn wrote: > > Tony Morris writes: > > > >> I don't think it is the "appropriate" set. It's an example. 0 is in the > >> set of integers. The value 0 is in many sets. > > OK, so I clearly do not understand your argument. The > > implication I took from “and 0 is not an integer” is that the > > foldable instance for ((,) a) should be present because it is > > the zero case of something that has integers as its domain, and > > I wanted to know what that something is. If this was not the > > intention of your argument, what was? > > > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominic at steinitz.org Sun Apr 9 16:42:57 2017 From: dominic at steinitz.org (dominic at steinitz.org) Date: Sun, 9 Apr 2017 17:42:57 +0100 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: <42915C06-7CBD-4BF0-9DB3-01CF624E692A@steinitz.org> I am not sure what to make of the “documentation” to which you refer. For example, a type Tensor seems to be defined. Now you can tensor lots of things with some algebraic structure but most commonly vector fields and modules (modules in the mathematical sense that is). The type Tensor seems to have no relation to these and there is no prose giving an indication of the author’s intent. Perhaps we should be cautious about adducing other parts of the package as evidence? > Already done mate. > > https://hackage.haskell.org/package/hask-0/docs/Hask-Category.html#t:Either > https://hackage.haskell.org/package/hask-0/docs/Hask-Category.html#t:Functor > > Note the multiple Functor instances for Either and Coproduct. e.g. > > - Functor * (* -> *) Either > - Functor * * (Either a) > etc etc > > On 09/04/17 10:29, Henrik Nilsson wrote: >> And of course, if, in a hypothetical future version of Haskell >> where we could make all possible functor instances for tuples, >> the question becomes: which one do we pick? The answer might well >> be "none" (in the prelude, at least). Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com From svenpanne at gmail.com Sun Apr 9 19:11:00 2017 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 9 Apr 2017 21:11:00 +0200 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: Message-ID: 2017-04-06 9:33 GMT+02:00 Jon Fairbairn : > Sven Panne writes: > [...] Although something like Error/OK would have been better than > > Left/Right, a slight majority preferred to give a bias to Either. The > > reasoning was that using "Right" for a "wrong" outcome (i.e. failure) > would > > be a bit obscure, and there was already quite some code using it in the > way > > we still do today. The bias is even explicitly documented in the Haddock > > docs for Data.Either for ages, so it would not be very wise to change the > > meaning here after roughly 2 decades. > > I guess this means that Haskell has failed to sufficiently avoid > success. If a mistake in library design is bad enough (not > necessarily the case for Either, but arguably so), it should be > corrected even after 20 years. > Just to clarify my POV: I didn't want to criticize anything here, I just wanted to point to some previous discussion. In my POV, Either *is* intended as a biased sum type (there are tons of more or less standard libraries which use it that way), while pairs/tuples are intended as unbiased product types. Of course one can see it in the exact opposite (still consistent) way, but this wasn't the historical intention, at least that's my personal interpretation... > > Of course the question remains: What is the totally unbiased standard sum > > type for 2 alternatives? > > What are you asking? It sounds like an invitation to bikeshed! > In general, though, types such as (,) and Either should be used > very sparingly. In many cases it would be better to define a new > type for the specific purpose. > I think we are in the same boat here, sorry if I didn't make that clear. -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sun Apr 9 19:24:12 2017 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 9 Apr 2017 21:24:12 +0200 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: References: <58e844f4.307.12b8.26783@clear.net.nz> Message-ID: 2017-04-09 2:01 GMT+02:00 Ben Franksen : > Am 08.04.2017 um 04:03 schrieb Anthony Clayden: > > [...] So to take your examples from an earlier thread, > > what do you expect Haskell to do here?: > > > > maximum (True,2) => ? > > minimum ((3, 4),5) => ? -- i.e. :: ((Int, Int), Int) > > sum (7,3.14) => ? -- i.e. :: (Int, Double) > > product (Left $ error "Errk") => ? -- i.e. :: > > Either e Int > > I (and others) think these should be type errors. > Exactly. > > > Do you expect Foldable (a, a) to behave differently > > vs Foldable (b, a) vs Foldable ((a, a), a) vs ...? > > > > Let's get everybody agreed on that. > > It would be nice if we could all agree on removing these instances. > Yep. :-) BTW, I find it remarkable that of those who defend these instances, few > seem to be especially interested in clarifying the OP's question: what > laws exactly do we expect for Foldable? [...] > And even if there are laws which hold for those instances, it doesn't mean that these instances should be defined. Take e.g. Bool: One can define a "Num Bool" instance which respects the usual laws (interpreting Bool basically as a "Word1", just like Word32 etc.), but we do *not* want to have this in the standard language/libraries, and for a good reason: It would make types less useful, removing a part of the usual "If it compiles, it works" safety net... -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Sun Apr 9 20:27:02 2017 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sun, 9 Apr 2017 15:27:02 -0500 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <4a153c75-79f1-77f8-866d-7459ecb9d61c@gmail.com> Message-ID: Genuinely curious: can people point to specific examples in their (or others') code where the ((,) a) instance for Foldable is really helpful and difficult to replace? Tom > El 9 abr 2017, a las 09:29, Benno Fünfstück escribió: > > Correct me I I'm wrong but I believe Tony Morris is saying the following: > > * not every operation defined for the integers "makes sense" for all integers. Example: '/' does not make sense in the case of 'x / 0' > * yet, we still include '0' in the integers even though not every operation makes sense for '0' > * -> not every operation in Foldable makes sense for `(,) a` > * -> but we also include `0` in the integers, so "not every operation makes sense" is not an argument to exclude `(,) a` from being foldable, > just as `0` is not excluded from the integers. > > Kind regards, > Benno > > Tony Morris schrieb am So., 9. Apr. 2017 um 14:26 Uhr: >> These two things are true: >> >> * 0 is in the set of integers >> * ∀ a. ((,) a) is Foldable, and as one of many consequences, the length >> of all values in the set ∀ a. ((,) a) is 1. >> >> There are four possible positions to take on these claims: >> >> 1. Both are true. >> 2. Both are false. >> 3. The first true and second false. >> 4. The second true and the first false. >> >> I respect arguments 1 and 2. If I chose 1 and you chose 2, I'd say "well >> rightio then mate and cheers to that", we'd clink glasses and move on. >> Same if it were vice versa. >> >> I do not have the same respect for positions 3 and 4. >> >> On 09/04/17 19:48, Jon Fairbairn wrote: >> > Tony Morris writes: >> > >> >> I don't think it is the "appropriate" set. It's an example. 0 is in the >> >> set of integers. The value 0 is in many sets. >> > OK, so I clearly do not understand your argument. The >> > implication I took from “and 0 is not an integer” is that the >> > foldable instance for ((,) a) should be present because it is >> > the zero case of something that has integers as its domain, and >> > I wanted to know what that something is. If this was not the >> > intention of your argument, what was? >> > >> >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Sun Apr 9 20:33:44 2017 From: fa-ml at ariis.it (Francesco Ariis) Date: Sun, 9 Apr 2017 22:33:44 +0200 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <4a153c75-79f1-77f8-866d-7459ecb9d61c@gmail.com> Message-ID: <20170409203344.GB13510@casa.casa> On Sun, Apr 09, 2017 at 03:27:02PM -0500, amindfv at gmail.com wrote: > Genuinely curious: can people point to specific examples in their (or > others') code where the ((,) a) instance for Foldable is really helpful > and difficult to replace? I asked in the other thread, these are some of the answers I got: Oliver Charles: > Personally, I think it would be a shame to lose foldMap on EIther. I > frequently foldMap over Maybe values (where mempty is suitable in case of > "failure"), and I can certainly see myself doing the same thing with > Either. Oleg Grenrus: > Anecdotally, today I wrote `foldMap toList`, to use as `Maybe (NonEmpty > a) -> [a]`. > Also I rely heavily in lens-based code on the `folded :: Fold (Maybe a) > a`. There haven't been replies on specific usage of functions length/sum/ maximum/etc. I can't recall where, but someone else was making a point that a {-# Poison something #-} pragma would fracture the ecosystem. I don't think this holds much weight though, as library authors would most likely toggle the flag in development (to avoid calling length Either, etc.) and toggle it back on release. -F From amindfv at gmail.com Mon Apr 10 04:51:53 2017 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sun, 9 Apr 2017 23:51:53 -0500 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: <20170409203344.GB13510@casa.casa> References: <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <4a153c75-79f1-77f8-866d-7459ecb9d61c@gmail.com> <20170409203344.GB13510@casa.casa> Message-ID: I did see those, but was hoping people could provide real code in the context of a library or code solving a particular problem. Real world Haskell, if you will :) Tom > El 9 abr 2017, a las 15:33, Francesco Ariis escribió: > >> On Sun, Apr 09, 2017 at 03:27:02PM -0500, amindfv at gmail.com wrote: >> Genuinely curious: can people point to specific examples in their (or >> others') code where the ((,) a) instance for Foldable is really helpful >> and difficult to replace? > > I asked in the other thread, these are some of the answers I got: > > Oliver Charles: >> Personally, I think it would be a shame to lose foldMap on EIther. I >> frequently foldMap over Maybe values (where mempty is suitable in case of >> "failure"), and I can certainly see myself doing the same thing with >> Either. > > Oleg Grenrus: >> Anecdotally, today I wrote `foldMap toList`, to use as `Maybe (NonEmpty >> a) -> [a]`. >> Also I rely heavily in lens-based code on the `folded :: Fold (Maybe a) >> a`. > > There haven't been replies on specific usage of functions length/sum/ > maximum/etc. > > I can't recall where, but someone else was making a point that a {-# Poison > something #-} pragma would fracture the ecosystem. > I don't think this holds much weight though, as library authors would most > likely toggle the flag in development (to avoid calling length Either, > etc.) and toggle it back on release. > > -F > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From ekmett at gmail.com Mon Apr 10 05:12:50 2017 From: ekmett at gmail.com (Edward Kmett) Date: Mon, 10 Apr 2017 01:12:50 -0400 Subject: Constraints on definition of `length` should be strengthened In-Reply-To: <42915C06-7CBD-4BF0-9DB3-01CF624E692A@steinitz.org> References: <42915C06-7CBD-4BF0-9DB3-01CF624E692A@steinitz.org> Message-ID: In that code, I made a more powerful version of Functor that can handle more interesting categories. In that setting, the fact that we use 'curried' types matters quite a bit. The usual way to think of a bifunctor is as a functor from a product category, which would like like something of kind (*,*) -> *. And you can define such a beast in Haskell. The "truly unbiased" tuple some folks have been hollering for in this thread would ideally have this sort of kind. After all, then it can't be Foldable, Traversable, etc. In http://hackage.haskell.org/package/semigroupoid-extras-5/docs/Data-Semifunctor.html Bi (,) and Bi Either provide these semantics today. But in this more general setting where we can have Functors that go to other categories than just Hask, haskell's "Bifunctor", which has kind * -> * -> * is a functor that to a functor category. We can curry/uncurry the kinds involved to go back and forth between these two representations and that always works in a category that is locally small like what we can define in Haskell. 'Bi' is a form of type level uncurry. In the hask code, Either is a functor from Hask to [Hask,Hask], where the latter is the category of functors from Hask -> Hask. This of course, fundamentally relies on the fact that Either a being a Functor. Mutatis mutandis for (,) a being a functor. Once you have those things you can use runNat from the package in question to move 'backwards' n arguments an:d map over any field you want, be it a bifunctor, trifunctor, whatever. Contravariant becomes a functor from an opposite category, and large numbers of classes we have just collapse away into one thing: Functor. Bifunctor ceases to be a primitive notion and just becomes a derived fact from the existence of those two Functor instances. I find this to be far more enlightening than a arbitrarily adopting an unbiased (,) and making the entire world adopt mutually incompatible data types. YMMV. -Edward On Sun, Apr 9, 2017 at 12:42 PM, wrote: > I am not sure what to make of the “documentation” to which you refer. For > example, a type Tensor seems to be defined. Now you can tensor lots of > things with some algebraic structure but most commonly vector fields and > modules (modules in the mathematical sense that is). The type Tensor seems > to have no relation to these and there is no prose giving an indication of > the author’s intent. Perhaps we should be cautious about adducing other > parts of the package as evidence? > > > Already done mate. > > > > https://hackage.haskell.org/package/hask-0/docs/Hask- > Category.html#t:Either > > https://hackage.haskell.org/package/hask-0/docs/Hask- > Category.html#t:Functor > > > > Note the multiple Functor instances for Either and Coproduct. e.g. > > > > - Functor * (* -> *) Either > > - Functor * * (Either a) > > etc etc > > > > On 09/04/17 10:29, Henrik Nilsson wrote: > >> And of course, if, in a hypothetical future version of Haskell > >> where we could make all possible functor instances for tuples, > >> the question becomes: which one do we pick? The answer might well > >> be "none" (in the prelude, at least). > > Dominic Steinitz > dominic at steinitz.org > http://idontgetoutmuch.wordpress.com > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.fairbairn at cl.cam.ac.uk Mon Apr 10 09:24:42 2017 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Mon, 10 Apr 2017 10:24:42 +0100 Subject: Constraints on definition of `length` should be strengthened References: Message-ID: Sven Panne writes: > 2017-04-06 9:33 GMT+02:00 Jon Fairbairn : > >> Sven Panne writes: >> [...] Although something like Error/OK would have been better than >> > Left/Right, a slight majority preferred to give a bias to Either. The >> > reasoning was that using "Right" for a "wrong" outcome (i.e. failure) >> would >> > be a bit obscure, and there was already quite some code using it in the >> way >> > we still do today. The bias is even explicitly documented in the Haddock >> > docs for Data.Either for ages, so it would not be very wise to change the >> > meaning here after roughly 2 decades. >> >> I guess this means that Haskell has failed to sufficiently avoid >> success. If a mistake in library design is bad enough (not >> necessarily the case for Either, but arguably so), it should be >> corrected even after 20 years. >> > > Just to clarify my POV: I didn't want to criticize anything here, I just > wanted to point to some previous discussion. In my POV, Either *is* > intended as a biased sum type (there are tons of more or less standard > libraries which use it that way), while pairs/tuples are intended as > unbiased product types. I agree with that, although somewhat reluctantly about Either. The original intention (as I remember it, but how reliable is my memory of meetings nearly thirty years ago?) was to pick a name for an unbiased sum type and its constructors. We chose Either and Left and Right (the latter two being names that had been used in prior languages). It was then noticed that Either provided what was needed for results that could either be a success or an error, and Right was the obvious choice for the success. (,) never had that: it was unbiased, apart from the inevitable syntactic and evaluation order biases. I would like to be able to say that (excluding questions of evaluation order) if one systematically replaced (a,b) with (b,a) throughout the source of a programme, it would still be the same programme. I would also like to think that instances provided in base were “the only sensible instance” (for some value of sensible). This is the case for Foldable Maybe, maybe for Either (but not for an unbiased sum) and definitely not for (,). -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk From jon.fairbairn at cl.cam.ac.uk Mon Apr 10 09:28:43 2017 From: jon.fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Mon, 10 Apr 2017 10:28:43 +0100 Subject: Constraints on definition of `length` should be strengthened References: <58e844f4.307.12b8.26783@clear.net.nz> Message-ID: Sven Panne writes: > And even if there are laws which hold for those instances, it doesn't mean > that these instances should be defined. Take e.g. Bool: One can define a > "Num Bool" instance which respects the usual laws (interpreting Bool > basically as a "Word1", just like Word32 etc.), but we do *not* want to > have this in the standard language/libraries, and for a good reason: It > would make types less useful, removing a part of the usual "If it compiles, > it works" safety net... Most heartily agree. Probably the programmer’s most important use of a static type system is to catch errors at compile time. I sit next to someone who is obliged to use scripting languages that automatically convert things to numbers whether you want that or not. This has several times produced hard to find bugs, and so cost real money. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk From david.feuer at gmail.com Mon Apr 10 13:36:59 2017 From: david.feuer at gmail.com (David Feuer) Date: Mon, 10 Apr 2017 09:36:59 -0400 Subject: Giving up boxes package In-Reply-To: References: Message-ID: I've been way too busy with GHC and containers to have time to devote to boxes. If anyone wants to take over, they are welcome. The main priority right now is improving documentation, but someone also needs to make sure it works with 8.2 as soon as its dependencies do. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Mon Apr 10 23:21:15 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Tue, 11 Apr 2017 11:21:15 +1200 Subject: No subject Message-ID: <58ec136b.383.2cca.31281@clear.net.nz> > On Sun Apr 9 19:24:12 UTC 2017, Sven Panne wrote: >> 2017-04-09 2:01 GMT+02:00 Ben Franksen : >>> Am 08.04.2017 um 04:03 schrieb Anthony Clayden: >>> [...] So to take your examples from an earlier thread, >>> what do you expect Haskell to do here?: >>> >>> maximum (True,2) => ? >>> minimum ((3, 4),5) => ? -- i.e. :: ((Int, Int), Int) >>> sum (7,3.14) => ? -- i.e. :: (Int, Double) >>> product (Left $ error "Errk") => ? -- i.e. :: >>> Either e Int >> >> I (and others) think these should be type errors. >> > Exactly. OK. Do y'all think there should be a `toList` method for them? Indeed, should there be a `toList` method available for any data type that doesn't implement `fromList`? Perhaps `toList` should not be a method of Foldable? > >>> Do you expect Foldable (a, a) to behave differently >>> vs Foldable (b, a) vs Foldable ((a, a), a) vs ...? >>> >> It would be nice if we could all agree on removing these instances. >> > Yep. :-) >> BTW, I find it remarkable that of those who defend these instances, few >> seem to be especially interested in clarifying the OP's question: what >> laws exactly do we expect for Foldable? [...] >> One of the Laws appears to be that `length` etc behave as `length . toList`. AntC From anthony_clayden at clear.net.nz Mon Apr 10 23:26:23 2017 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Tue, 11 Apr 2017 11:26:23 +1200 Subject: Constraints on definition of `length` should be strengthened Message-ID: <58ec149f.24.3b78.23297@clear.net.nz> [Errk, somehow posted this with no Subject. Trying again.] > On Sun Apr 9 19:24:12 UTC 2017, Sven Panne wrote: >> 2017-04-09 2:01 GMT+02:00 Ben Franksen : >>> Am 08.04.2017 um 04:03 schrieb Anthony Clayden: >>> [...] So to take your examples from an earlier thread, >>> what do you expect Haskell to do here?: >>> >>> maximum (True,2) => ? >>> minimum ((3, 4),5) => ? -- i.e. :: ((Int, Int), Int) >>> sum (7,3.14) => ? -- i.e. :: (Int, Double) >>> product (Left $ error "Errk") => ? -- i.e. :: >>> Either e Int >> >> I (and others) think these should be type errors. >> > Exactly. OK. Do y'all think there should be a `toList` method for them? Indeed, should there be a `toList` method available for any data type that doesn't implement `fromList`? Perhaps `toList` should not be a method of Foldable? > >>> Do you expect Foldable (a, a) to behave differently >>> vs Foldable (b, a) vs Foldable ((a, a), a) vs ...? >>> >> It would be nice if we could all agree on removing these >> instances. >> > Yep. :-) >> BTW, I find it remarkable that of those who defend these >> instances, few seem to be especially interested >> in clarifying the OP's question: what >> laws exactly do we expect for Foldable? [...] >> One of the Laws appears to be that `length` etc behave as `length . toList`. AntC From dominic at steinitz.org Thu Apr 13 11:41:46 2017 From: dominic at steinitz.org (Dominic Steinitz) Date: Thu, 13 Apr 2017 12:41:46 +0100 Subject: Banded Matrices Message-ID: <709FC8A8-8F15-4E42-B5F4-0CCE072C742A@steinitz.org> Hi Henning, I just noticed https://hackage.haskell.org/package/hmatrix-banded. I have just made a PR to hmatrix to add a tridiagonal solver: https://github.com/albertoruiz/hmatrix/pull/224. I don’t think there is anything to do but I thought it worth sharing. Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com From baldurpet at gmail.com Thu Apr 13 19:22:45 2017 From: baldurpet at gmail.com (=?UTF-8?Q?Baldur_Bl=C3=B6ndal?=) Date: Thu, 13 Apr 2017 20:22:45 +0100 Subject: Add Arg{Min,Max} pattern synonyms to Data.Semigroup In-Reply-To: References: Message-ID: Add (explicitly-bidirectional record) pattern synonyms to Data.Semigroup: pattern ArgMin :: a -> b -> ArgMin a b pattern ArgMin {minArg, minValue} = Min (Arg minArg minValue) pattern ArgMax :: a -> b -> ArgMax a b pattern ArgMax {maxArg, maxValue} = Max (Arg maxArg maxValue) As described in https://ghc.haskell.org/trac/ghc/ticket/13572 -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.thaddeus at gmail.com Sat Apr 15 00:02:11 2017 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Fri, 14 Apr 2017 20:02:11 -0400 Subject: Is mkTrApp unsafe? Message-ID: <20170415000211.GA8564@thadasaurus> I've been playing around with the GHC 8.2 release candidate. In Type.Reflection.Unsafe, there's a really handy function named mkTrApp. Everything else in that module is pretty evidently unsafe, but I'm not so sure about mkTrApp. I'm wondering if it should actually be exported by Type.Reflection instead or if I've missed some way it could be used to create an ill-kinded TypeRep. -Andrew Martin From david.feuer at gmail.com Sat Apr 15 03:51:12 2017 From: david.feuer at gmail.com (David Feuer) Date: Fri, 14 Apr 2017 23:51:12 -0400 Subject: Is mkTrApp unsafe? In-Reply-To: <20170415000211.GA8564@thadasaurus> References: <20170415000211.GA8564@thadasaurus> Message-ID: Yes, I believe you are correct that mkTrApp is safe, and probably should not be exported by Type.Reflection.Unsafe. However, it's not so clear to me that it should be exported by Type.Reflection. You should just be able to use App, both to construct and deconstruct type applications. David On Fri, Apr 14, 2017 at 8:02 PM, Andrew Martin wrote: > I've been playing around with the GHC 8.2 release candidate. In > Type.Reflection.Unsafe, there's a really handy function named mkTrApp. > Everything else in that module is pretty evidently unsafe, but I'm not > so sure about mkTrApp. I'm wondering if it should actually be exported > by Type.Reflection instead or if I've missed some way it could be used > to create an ill-kinded TypeRep. > > -Andrew Martin > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From andrew.thaddeus at gmail.com Sat Apr 15 13:00:09 2017 From: andrew.thaddeus at gmail.com (Andrew Martin) Date: Sat, 15 Apr 2017 09:00:09 -0400 Subject: Is mkTrApp unsafe? In-Reply-To: References: <20170415000211.GA8564@thadasaurus> Message-ID: <55AE2B6B-9110-45D6-9FEE-6822D7F2AF56@gmail.com> Ah, I had never used pattern synonyms before, and I did not really that pattern synonyms could be bidirectional. That's good to know. It seems like mkTrApp should be removed then unless there are any restrictions on partially applying pattern synonyms. Sent from my iPhone > On Apr 14, 2017, at 11:51 PM, David Feuer wrote: > > Yes, I believe you are correct that mkTrApp is safe, and probably > should not be exported by Type.Reflection.Unsafe. However, it's not so > clear to me that it should be exported by Type.Reflection. You should > just be able to use App, both to construct and deconstruct type > applications. > > David > > On Fri, Apr 14, 2017 at 8:02 PM, Andrew Martin > wrote: >> I've been playing around with the GHC 8.2 release candidate. In >> Type.Reflection.Unsafe, there's a really handy function named mkTrApp. >> Everything else in that module is pretty evidently unsafe, but I'm not >> so sure about mkTrApp. I'm wondering if it should actually be exported >> by Type.Reflection instead or if I've missed some way it could be used >> to create an ill-kinded TypeRep. >> >> -Andrew Martin >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From ekmett at gmail.com Tue Apr 18 12:52:46 2017 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 18 Apr 2017 08:52:46 -0400 Subject: Add Arg{Min,Max} pattern synonyms to Data.Semigroup In-Reply-To: References: Message-ID: I'm personally weakly +1 on this. It makes the combination of Arg and Max much more convenient to use and points directly to how to use it without code duplication. The potential downside is using a big scary extension in what will become a fairly mainstream module in 8.4, but I think we can phrase our way around the issue when it comes to the libraries part of Haskell-Prime. This opens the door to possibly being smarter about the existing Data.Monoid.First (and Last), encoding them as pattern synonyms for Maybe (Data.Semigroup.First a) (or Last) as well, but we'd likely need to give that a lot more thought / testing. -Edward On Thu, Apr 13, 2017 at 3:22 PM, Baldur Blöndal wrote: > Add (explicitly-bidirectional record) pattern synonyms to Data.Semigroup: > > pattern ArgMin :: a -> b -> ArgMin a b pattern ArgMin {minArg, minValue} = > Min (Arg minArg minValue) > > pattern ArgMax :: a -> b -> ArgMax a b pattern ArgMax {maxArg, maxValue} = > Max (Arg maxArg maxValue) > > As described in https://ghc.haskell.org/trac/ghc/ticket/13572 > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Tue Apr 18 21:51:16 2017 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Wed, 19 Apr 2017 07:51:16 +1000 Subject: Add Arg{Min,Max} pattern synonyms to Data.Semigroup In-Reply-To: References: Message-ID: On 18 April 2017 at 22:52, Edward Kmett wrote: > I'm personally weakly +1 on this. It makes the combination of Arg and Max > much more convenient to use and points directly to how to use it without > code duplication. The potential downside is using a big scary extension in > what will become a fairly mainstream module in 8.4, but I think we can > phrase our way around the issue when it comes to the libraries part of > Haskell-Prime. > > This opens the door to possibly being smarter about the existing > Data.Monoid.First (and Last), encoding them as pattern synonyms for Maybe > (Data.Semigroup.First a) (or Last) as well, but we'd likely need to give > that a lot more thought / testing. I've actually been considering that recently. I'm weakly +1 on this proposal as well. > > -Edward > > On Thu, Apr 13, 2017 at 3:22 PM, Baldur Blöndal wrote: >> >> Add (explicitly-bidirectional record) pattern synonyms to Data.Semigroup: >> >> pattern ArgMin :: a -> b -> ArgMin a b pattern ArgMin {minArg, minValue} = >> Min (Arg minArg minValue) >> >> pattern ArgMax :: a -> b -> ArgMax a b pattern ArgMax {maxArg, maxValue} = >> Max (Arg maxArg maxValue) >> >> As described in https://ghc.haskell.org/trac/ghc/ticket/13572 >> >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > > > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From baldurpet at gmail.com Tue Apr 18 22:07:09 2017 From: baldurpet at gmail.com (=?UTF-8?Q?Baldur_Bl=C3=B6ndal?=) Date: Tue, 18 Apr 2017 23:07:09 +0100 Subject: Add Arg{Min,Max} pattern synonyms to Data.Semigroup In-Reply-To: References: Message-ID: > This opens the door to possibly being smarter about the existing Data.Monoid.First (and Last), encoding them as pattern synonyms for Maybe (Data.Semigroup.First a) (or Last) as well, but we'd likely need to give that a lot more thought / testing. Yes First/Last is a good use for pattern synonyms > The potential downside is using a big scary extension in what will become a fairly mainstream module in 8.4, but I think we can phrase our way around the issue when it comes to the libraries part of Haskell-Prime. As for this proposal I am in no hurry to see it implemented, I figured pattern synonyms would take time to get adopted to base. What do you mean by "phrase our way" around the issue? (The pattern synonyms could be added to the documentation. . "If you are okay with PatternSynonyms..") -------------- next part -------------- An HTML attachment was scrubbed... URL: From mblazevic at stilo.com Fri Apr 21 21:42:32 2017 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Fri, 21 Apr 2017 17:42:32 -0400 Subject: Add Arg{Min,Max} pattern synonyms to Data.Semigroup In-Reply-To: References: Message-ID: <49ddcbff-d62b-7724-cae8-5824b2eff04f@stilo.com> On 2017-04-18 08:52 AM, Edward Kmett wrote: > I'm personally weakly +1 on this. It makes the combination of Arg and > Max much more convenient to use and points directly to how to use it > without code duplication. The potential downside is using a big scary > extension in what will become a fairly mainstream module in 8.4, but I > think we can phrase our way around the issue when it comes to the > libraries part of Haskell-Prime. I'm (-1) until I'm convinced that the phrasing-around approach works. Can you spell it out? > This opens the door to possibly being smarter about the existing > Data.Monoid.First (and Last), encoding them as pattern synonyms for > Maybe (Data.Semigroup.First a) (or Last) as well, but we'd likely need > to give that a lot more thought / testing. > > -Edward > > On Thu, Apr 13, 2017 at 3:22 PM, Baldur Blöndal > wrote: > > Add (explicitly-bidirectional record) pattern synonyms to > Data.Semigroup: > > pattern ArgMin :: a -> b -> ArgMin a b pattern ArgMin {minArg, > minValue} = Min (Arg minArg minValue) > > pattern ArgMax :: a -> b -> ArgMax a b pattern ArgMax {maxArg, > maxValue} = Max (Arg maxArg maxValue) > > As described in https://ghc.haskell.org/trac/ghc/ticket/13572 > > From wren at community.haskell.org Tue Apr 25 01:39:50 2017 From: wren at community.haskell.org (wren romano) Date: Mon, 24 Apr 2017 18:39:50 -0700 Subject: Civility notes (was "Traversable instances for (,,) a b") In-Reply-To: References: Message-ID: I'm +1 to having a CoC. It doesn't have to be complicated, and indeed CoCs are better when they're uncomplicated (but explicit! vague CoCs help noone). The point of a CoC is not to change people's behavior (if you want that, there are more effective approaches). The point is to serve as a touchstone for community values. Without a touchstone, communities drift over time as people age and come and go. Drifting itself is unavoidable and not necessarily bad, but sometimes that drifting is the slipping that becomes corrosive. Touchstones give communities a way to correct for corrosion: by concretely recording the past they make the past visible, and thus make the present visible as something that has changed from the past. CoCs also, as Tom says, make the community values explicit for outsiders to see. This is especially important for women and minorities, because we are disproportionately affected by breaches of civility. This is why numerous organizations for women in STEM advocate for having CoCs. To pick a few examples: https://www.ashedryden.com/blog/codes-of-conduct-101-faq https://adainitiative.org/2014/02/18/ https://geekfeminism.org/2014/06/30/ The mere existence of a CoC indicates that at least at some point the community cared enough about civility to try to ensure it. That alone indicates that the community has higher standards for civility than the vast bulk of online communities for programming. And it is something we look for. If you want to avoid discouraging women and minorities from joining, it's not enough to play Simon Says, you have to write the rules down too. -- Live well, ~wren From simon at banquise.net Wed Apr 26 20:23:41 2017 From: simon at banquise.net (Simon Marechal) Date: Wed, 26 Apr 2017 22:23:41 +0200 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b In-Reply-To: References: <20170330204644.GA15275@fuzzbomb> <20170330213650.GA24449@fuzzbomb> <0d39aa4e-1361-e252-49e4-89b3542eb48e@gmail.com> <20170401000817.GA11348@casa.casa> <4a153c75-79f1-77f8-866d-7459ecb9d61c@gmail.com> Message-ID: On 04/09/2017 10:27 PM, amindfv at gmail.com wrote: > Genuinely curious: can people point to specific examples in their (or > others') code where the ((,) a) instance for Foldable is really helpful > and difficult to replace? I use it quite often when prototyping stuff. I used it in two distinct instances in the last two weeks. As for the other usual suspects (Either, Maybe, etc.), their instances are *really* useful, especially the Traversable, and especially in the REPL. I write Haskell quite a lot now, and this only caused a bug *once*. I didn't even realize these instances existed. But once I learned about them, I never had a problem again (well, I can't be sure it isn't lying dormant in some code I wrote). On the other hand, I still get <> when I have a typo in my let blocks. There are many other issues that seem more pressing to me. Here is my plea, please step back, and consider the following before getting worked up about these instances: * this is a very minor issue in the Haskell ecosystem * I believe most people are satisfied with the current state of affairs. Every time I saw informal polls, such as [1], about what is annoying about Haskell, this didn't even surface! * that ship has sailed, and another round of repeating the same old argument will only clog the mailing list [1] https://www.reddit.com/r/haskell/comments/4f47ou/why_does_haskell_in_your_opinion_suck/ From voldermort at hotmail.com Thu Apr 27 07:44:16 2017 From: voldermort at hotmail.com (Jonathon Delgado) Date: Thu, 27 Apr 2017 07:44:16 +0000 Subject: Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b Message-ID: Code please? An actual, concrete example? From lsp at informatik.uni-kiel.de Fri Apr 28 09:49:54 2017 From: lsp at informatik.uni-kiel.de (lennart spitzner) Date: Fri, 28 Apr 2017 11:49:54 +0200 Subject: Civility notes (was "Traversable instances for (,,) a b") In-Reply-To: References: Message-ID: A couple weeks earlier there was a discussion on tuple instances on this list that got somewhat out of hand, leading to a meta-discussion on civility. There was the suggestion to create and endorse a CoC for this community. Now both topics have not received much further contribution, an indication that not much more can be gained from these discussions. Yet I have a bad feeling about leaving them in such a manner, because: There is no real conclusion, there is no agreement, and I do not see much advancement of how we, as a community, cope with negative situations. And while I can understand that there is little incentive/motivation to continue due to negative emotions involved, I also fear that ending discussions on such negative emotions will discourage contributions in general not only now, but in the future as well. So I will dare to continue, ask a couple of questions, and make some suggestions: 1. At which point of the particular tuple instance discussion would it have helped to have some CoC, and in what way? Is the hope that the participants had considered this CoC and not said something in the way that they did? Or would it have allowed us to quickly point out the CoC at some specific point in response to some mail? Or something else? I _can_ see a couple of instances where a CoC could have been pointed out, but these don't convince me, because a) in those cases giving clear, respectful negative feedback (for example regarding "joking") (would/should) have worked just as well if not better and b) because simply pointing out the CoC during a discussion is rather non-constructive because it is a vague form of criticism and the receiving party will most likely consider it inappropriate, and so it has the opposite effect. 2. on a related note, I have a hard time pinpointing the moment in the discussion where things transitioned from cool to flaming. I'd perhaps name as important factors the useless rhetoric (go and ask those mathematicians) and the case of hiding behind "it was a dumb joke" followed by what in my eyes reads like a dishonest apology. But I am not certain and perhaps unfair. My subjective estimation is that discussing this a bit further is more constructive than working on a CoC. What parts of the discussion were unfortunate, exactly, and why? The general opinion here seems to be to ask for civility without naming names. I disagree: I have little hope that giving the vague feedback to all participants that some parts of the discussion were non-constructive/disrespectful will improve things in the future. As an example, we might take the following advice from this: "Humour is important and generally welcome, but it is necessary to be especially careful to make it clear when exactly we talk in jest, and to not let slip phrases that can easily interpreted as offensive if not interpreted as a joke. We will not accept retroactively hiding behind 'it was a joke'." (perhaps some people think such a statement belonged in a CoC, but then this is a different/more specific kind of advice than what I can see in existing/proposed CoCs.) 3. And back to first discussion: I refuse to vote -1 or +1, because the topic is more nuanced than that. Instead, I vote for the following: "Additional tuple instances shall be added after such a point in time where either the methods have been renamed as to avoid confusion, or after the generic versions are no longer exposed in the default Prelude. (and whether this point will come is intentionally left open.)" 4. And reflecting on the previous point, I encourage all participants to try to not make pure -1/+1 votes, but to include conditions under which they may switch, especially for controversial subjects. I have hopes that this will help finding a majority-backed compromise. 5. It would help to have the discussion and the arguments made by both sides archived somewhere other than on the mailing list. In one of the last mails I wrote to this list I implicitly complained about the signal-to-noise, and to be clear, I don't mean that any messages consist of noise. But it can easily take a couple of mails back-and-forth to get some point across, and these threads can grow to over a hundred mails quickly. I realize that the main issue here of course is the amount of work it would mean to somewhat objectively summarize an (often heated) debate. But then the alternative is the reiteration of the same topics in an almost predicable frequency. Thoughts? (Sorry, Tony, for somewhat singling out the "joking" as the negative example. This might be unfair. You have a valid point, but conveyed it rather poorly especially to the end of the discussion.) -- lennart From tonymorris at gmail.com Sun Apr 30 13:00:39 2017 From: tonymorris at gmail.com (Tony Morris) Date: Sun, 30 Apr 2017 23:00:39 +1000 Subject: Civility notes (was "Traversable instances for (,,) a b") In-Reply-To: References: Message-ID: On 28/04/17 19:49, lennart spitzner wrote: > the case of hiding behind "it was a dumb joke" followed by what in my > eyes reads like a dishonest apology. But I am not certain and perhaps > unfair. > > We will not accept retroactively hiding behind > 'it was a joke'." > > > (Sorry, Tony, Thank you for your incredibly genuine apology. Please leave me out of this discussion. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From amindfv at gmail.com Sun Apr 30 15:49:54 2017 From: amindfv at gmail.com (Tom Murphy) Date: Sun, 30 Apr 2017 11:49:54 -0400 Subject: Civility notes (was "Traversable instances for (,,) a b") In-Reply-To: References: Message-ID: To address your point about: "My subjective estimation is that discussing this a bit further is more constructive than working on a CoC. What parts of the discussion were unfortunate, exactly, and why?" The problem with just discussing it further here is that: a) Nothing specific needs to get explicitly agreed upon, so we can all leave with our own interpretations and conclusions of what was decided b) We're 20-something emails into an email chain. All of us discussing will have developed more nuanced views, but for example a new person coming to the community will have no idea about what was discussed here. A CoC, on the other hand, is a big neon sign at the front door of the community, summarizing the basic bullet points of what we can agree we want our community to be. (By the way, I agreed with much of what you talked about but I think your points could have been made without calling anyone else out by name. Just my 2c.) Tom On Fri, Apr 28, 2017 at 5:49 AM, lennart spitzner < lsp at informatik.uni-kiel.de> wrote: > A couple weeks earlier there was a discussion on tuple instances on this > list > that got somewhat out of hand, leading to a meta-discussion on civility. > There was the suggestion to create and endorse a CoC for this community. > > Now both topics have not received much further contribution, an indication > that > not much more can be gained from these discussions. Yet I have a bad > feeling about leaving them in such a manner, because: There is no real > conclusion, there is no agreement, and I do not see much advancement of how > we, as a community, cope with negative situations. And while I can > understand > that there is little incentive/motivation to continue due to negative > emotions involved, I also fear that ending discussions on such negative > emotions will discourage contributions in general not only now, but in the > future as well. > > So I will dare to continue, ask a couple of questions, and make some > suggestions: > > 1. At which point of the particular tuple instance discussion would it have > helped to have some CoC, and in what way? Is the hope that the > participants > had considered this CoC and not said something in the way that they did? > Or would it have allowed us to quickly point out the CoC at some > specific > point in response to some mail? Or something else? > > I _can_ see a couple of instances where a CoC could have been pointed > out, > but these don't convince me, because > a) in those cases giving clear, respectful negative feedback (for > example > regarding "joking") (would/should) have worked just as well if not > better > and > b) because simply pointing out the CoC during a discussion is rather > non-constructive because it is a vague form of criticism and the > receiving party will most likely consider it inappropriate, and so > it has > the opposite effect. > > 2. on a related note, I have a hard time pinpointing the moment in the > discussion where things transitioned from cool to flaming. I'd perhaps > name > as important factors the useless rhetoric (go and ask those > mathematicians) > and the case of hiding behind "it was a dumb joke" followed by what in > my > eyes reads like a dishonest apology. But I am not certain and perhaps > unfair. > > My subjective estimation is that discussing this a bit further is more > constructive than working on a CoC. What parts of the discussion were > unfortunate, exactly, and why? The general opinion here seems to be to > ask for civility without naming names. I disagree: I have little hope > that > giving the vague feedback to all participants that some parts of the > discussion were non-constructive/disrespectful will improve things in > the > future. > > As an example, we might take the following advice from this: > "Humour is important and generally welcome, but it is necessary to be > especially careful to make it clear when exactly we talk in jest, and to > not let slip phrases that can easily interpreted as offensive if not > interpreted as a joke. We will not accept retroactively hiding behind > 'it was a joke'." > > (perhaps some people think such a statement belonged in a CoC, but then > this is a different/more specific kind of advice than what I can see in > existing/proposed CoCs.) > > 3. And back to first discussion: I refuse to vote -1 or +1, because the > topic > is more nuanced than that. Instead, I vote for the following: > "Additional tuple instances shall be added after such a point in time > where > either the methods have been renamed as to avoid confusion, or after the > generic versions are no longer exposed in the default Prelude. > (and whether this point will come is intentionally left open.)" > > 4. And reflecting on the previous point, I encourage all participants to > try to > not make pure -1/+1 votes, but to include conditions under which they > may > switch, especially for controversial subjects. I have hopes that this > will > help finding a majority-backed compromise. > > 5. It would help to have the discussion and the arguments made by both > sides > archived somewhere other than on the mailing list. In one of the last > mails I wrote to this list I implicitly complained about the > signal-to-noise, and to be clear, I don't mean that any messages consist > of noise. But it can easily take a couple of mails back-and-forth to get > some point across, and these threads can grow to over a hundred mails > quickly. > I realize that the main issue here of course is the amount of work it > would > mean to somewhat objectively summarize an (often heated) debate. But > then > the alternative is the reiteration of the same topics in an almost > predicable frequency. > Thoughts? > > (Sorry, Tony, for somewhat singling out the "joking" as the negative > example. > This might be unfair. You have a valid point, but conveyed it rather poorly > especially to the end of the discussion.) > > -- lennart > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanuki at gmail.com Sun Apr 30 22:55:41 2017 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Sun, 30 Apr 2017 15:55:41 -0700 Subject: Civility notes (was "Traversable instances for (,,) a b") In-Reply-To: References: Message-ID: On Apr 30, 2017 8:52 AM, "Tom Murphy" wrote: We're 20-something emails into an email chain. All of us discussing will have developed more nuanced views, but for example a new person coming to the community will have no idea about what was discussed here. A CoC, on the other hand, is a big neon sign at the front door of the community, summarizing the basic bullet points of what we can agree we want our community to be. ...okay, that point has tipped me to +1 on at least putting together a set of guidelines. Quote Simon, invoke Wheaton's Law, etc. I'm still -1 on any sort of "code" designed to enable enforcement, but a sign on the door saying "here's what we've learned" sounds like a pretty good idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: