From andres.loeh at gmail.com Thu Oct 1 12:36:42 2015 From: andres.loeh at gmail.com (=?UTF-8?Q?Andres_L=C3=B6h?=) Date: Thu, 1 Oct 2015 14:36:42 +0200 Subject: Self-nomination Message-ID: Hi. I'd like to nominate myself for membership in the new Haskell Prime committee. About me: * I've been a Haskell user since 1997. * Back then, to learn Haskell, I read the entire Haskell 1.4 language report. * I have experience in programming languages theory and language design, with most of my research focusing on datatype-generic programming in Haskell (e.g. the stuff that is currently available as DeriveGeneric etc in GHC). * I have extensive experience in teaching Haskell, both in an academic and a commercial context. * I was a member of the Haskell 2010 committee. I'd like to contribute to the new standardization effort, and am very grateful to hvr for taking the lead. I believe that the current system of accumulating more and more language extensions is only sustainable in the long term if we shift the baseline from time to time. Even more than just making a decision on what a new "Haskell" could and should look like, I think that a likely benefit of the standardization process will be that we improve the documentation of extensions, reveal dark corners of underspecficiation and strange interactions, and perhaps can help to clean up certain things here and there. Cheers, Andres From johnw at newartisans.com Sun Oct 4 18:46:01 2015 From: johnw at newartisans.com (John Wiegley) Date: Sun, 04 Oct 2015 11:46:01 -0700 Subject: Self-nomination In-Reply-To: ("Andres \=\?utf-8\?Q\?L\=C3\=B6h\=22's\?\= message of "Thu, 1 Oct 2015 14:36:42 +0200") References: Message-ID: I will self-nominate as well, but not due to experience with Haskell; rather, I can offer a pair of fresh eyes, and also the perspective of someone who has worked on language standardization in the C++ world. About me: * Haskell user since 2012, full-time Coq user since 2014. * Worked professionally as a front-end developer on several C and C++ compilers 1995-2006, 2009-2012. * Member of the ANSI/ISO C++ standards body 1997-2014. I'm not at all qualified if knowledge of historical context matters here; but perhaps so, if not having it might be useful at times. John From jmct at jmct.cc Mon Oct 5 01:46:27 2015 From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=) Date: Mon, 5 Oct 2015 02:46:27 +0100 Subject: Self-nomination Message-ID: Hello everyone, I would also like to nominate myself for the Haskell committee reboot. I'm currently finishing my PhD at the University of York, just submitted last week and going to defend in the next few months. I will be starting at Galois later this month but cannot claim to speak for the company. A small group of us at York have considered writing a (new) York Haskell Compiler. One of the issues faced when considering such a project is that many people expect more than what Haskell98 or Haskell2010 offer, but many of those things are underspecified. The fallback of 'just do what GHC does' defeats the purpose in our eyes. Having a modern standard would help pin down the common extensions to Haskell2010 that people rely on while leaving room for experimentation on the 'how'. While most of my work has been on the implementation side of things, I am comfortable with the theoretical aspect of language design. Having just finished my thesis, I'm keen to start on another problem. Having a new, up-to-date, standard is something I feel is important to the wider Haskell community and I would love the opportunity to be involved. Best wishes, Jos? Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolm.wallace at me.com Mon Oct 5 09:30:01 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Mon, 05 Oct 2015 10:30:01 +0100 Subject: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> Message-ID: <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be less well disposed to reviewing papers that use Haskell, and less well disposed to collaborating on writing papers that involve Haskell. Please can the Haskell Prime Committee take into account the views of such "peripheral" users of the language, who after all, form some measure of its recent "success". Haskell is a real-world tool for many people, and breakage of their code, and their sources of information about Haskell, is a powerful disincentive to continue with it. Regards, Malcolm > On 5 Oct 2015, at 10:05, Malcolm Wallace wrote: > >> I am also a strong -1 on small changes that break huge numbers of things for somewhat trivial benefits. >> >> Regards, >> Malcolm >> >> On 2 Oct 2015, at 11:09, Henrik Nilsson wrote: >> >>> Hi all, >>> >>> I have discussed the monad of no return proposal with >>> my colleague Graham Hutton: a long-standing member of >>> the Haskell community, well-known researcher, some 20 >>> years of experience of teaching Haskell to >>> undergraduate students, and author of one of the most >>> successful introductory Haskell textbooks there are. >>> >>> The upshot of this e-mail is a strong collective -2 >>> from us both on particular proposal, and a general call >>> for much more caution when it comes to breaking changes >>> that are not critically important. >>> >>> First, on a general note, there has recently been a >>> flurry of breaking changes to the (de facto) Haskell >>> standards. In many cases for very good reasons, but >>> sometimes it seems more in a quest for perfection >>> without due consideration for the consequences. It used >>> to be the case that breaking changes were very rare >>> indeed. And for good reason. >>> >>> Right now, the main "measure of breakage" in the >>> on-line discussions seems to be how many packages that >>> break in Hackage. Which of course makes sense: the >>> Hackage repository is very important and such a measure >>> is objective, as far as it goes. >>> >>> But we should not forget that breakage can go far >>> beyond Hackage. For starters, there is *lots* of code >>> that is not in Hackage, yet critically important to its >>> users, however many or few they are. There are more >>> than hundreds of thousands of copies of books out there >>> where that may break in that examples may no longer >>> work. And they cannot be changed. There are countless >>> research papers that may break in the same way. Every >>> single institution that use Haskell in their teaching >>> may have to update their teaching materials (slides, >>> code, lab instructions) for every module that teaches >>> or uses Haskell. And last but not the least, what >>> countless of programmers and students have learned >>> about Haskell over decades, most of whom are *not* >>> power users who can take these changes in their stride, >>> may also break. >>> >>> Now, of course a language has to evolve, and sometimes >>> breaking backwards compatibility is more or less >>> essential for the long-term benefit of the language. >>> But we should not let perfection be the enemy of the >>> good. >>> >>> As to this particular proposal, the monad of no return, >>> it does not seem essential to us, but mostly motivated >>> by a quest for "perfection" as defined by a very >>> knowledgeable but in relative terms small group of >>> people. >>> >>> One argument put forward was that applicative code that >>> uses "return" instead of "pure" should get a less >>> constrained type. But such code is relatively new. The >>> methods of the Monad class have been return and bind >>> for some 25 years. So indeed, as Henning Thielemann >>> wrote: why should not the newer code be adapted and use >>> "pure" instead? In fact, the use of "pure" in such code >>> could serve as a quite useful cue that the code is >>> applicative rather than monadic, especially where >>> applicative do is employed. >>> >>> Another reason put forward is support for the >>> applicative do syntax. But that is, in standard terms, >>> only a future possibility at this point. Further, the >>> syntax is arguably rather dubious anyway as it, in >>> particular to someone with an imperative background, >>> suggests a sequential reading which is exactly what >>> applicative is not and why it is useful. So from that >>> perspective, using the applicative operators directly, >>> without any syntactic sugar, actually amounts to a much >>> more transparent and honest syntax, even if a bit more >>> verbose in some cases. >>> >>> The bottom line is that it is premature to put forward >>> support for the applicative do syntax as a rationale >>> for a non-essential breaking change. >>> >>> Best regards, >>> >>> Henrik Nilsson and Graham Hutton >>> >>> -- >>> Henrik Nilsson >>> School of Computer Science >>> The University of Nottingham >>> nhn at cs.nott.ac.uk >> > From mjgajda at gmail.com Mon Oct 5 09:47:21 2015 From: mjgajda at gmail.com (=?UTF-8?Q?Micha=C5=82_J_Gajda?=) Date: Mon, 5 Oct 2015 17:47:21 +0800 Subject: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> Message-ID: Hi, As a person who used Haskell in all three capacities (for scientific research, for commercial purpose, and to introduce others to benefits of pure and strongly typed programming), I must voice an supportive voice for this change: 1. Orthogonal type classes are easier to explain. 2. Gradual improvements helps us to generalize further, and this in turn makes education easier. 3. Gradual change that break only a little help to prevent either stagnation (FORTRAN) and big breakage (py3k). That keeps us excited. That would also call to split TCs into their orthogonal elements: return, ap, bind having the basic TC on their own. So: +1, but only if it is possible to have compatibilty mode. I believe that rebindable syntax should allow us to otherwise make our own prelude, if we want such a split. Then we could test it well before it is used by the base library. That said, I would appreciate Haskell2010 option just like Haskell98 wad, so that we can compile old programs without changes. Even by using some Compat version of standard library. Would that satisfy need for stability? PS And since all experts were beginners some time ago, I beg that we do not call them "peripheral". -- Best regards Micha? On Monday, 5 October 2015, Malcolm Wallace wrote: > On other social media forums, I am seeing educators who use Haskell as a > vehicle for their main work, but would not consider themselves Haskell > researchers, and certainly do not have the time to follow Haskell mailing > lists, who are beginning to say that these kinds of annoying breakages to > the language, affecting their research and teaching materials, are > beginning to disincline them to continue using Haskell. They are feeling > like they would be > (...) -- Pozdrawiam Micha? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonymorris at gmail.com Mon Oct 5 09:49:10 2015 From: tonymorris at gmail.com (Tony Morris) Date: Mon, 5 Oct 2015 19:49:10 +1000 Subject: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> Message-ID: <56124796.1020403@gmail.com> I have used Haskell for teaching for years. Until recently, I taught the hierarchy using a semigroup model. Functor <- Apply <- Applicative Apply <- Bind <- Monad https://github.com/NICTA/course/tree/ee8d1a294137c157c13740ac99a23a5dd5870b4a/src/Course I did this because it means curious students don't need to receive an explanation of the historical accidents of Haskell had I modelled it in accordance with Haskell pre-AMP. Doing so has caused confusion (I tried it, many years ago). Since AMP implementation, I have changed the hierarchy to be the same as Haskell proper, since the benefit has become worth doing. https://github.com/NICTA/course/issues/164 I am in favour of breaking changes as hard as you can, if it achieves a progressive benefit, even a small one, which this does. It also achieves an incidental benefit in the context of teaching. As it stands for industry use, I remove Prelude and model all this properly anyway. It is a significant effort, but way worth it e.g. do not require return to use do-notation. The penalty for having to do this is often under-estimated. "Breaking changes" is over-stated. Patience. I am waiting. On 05/10/15 19:30, Malcolm Wallace wrote: > On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be less well disposed to reviewing papers that use Haskell, and less well disposed to collaborating on writing papers that involve Haskell. > > Please can the Haskell Prime Committee take into account the views of such "peripheral" users of the language, who after all, form some measure of its recent "success". Haskell is a real-world tool for many people, and breakage of their code, and their sources of information about Haskell, is a powerful disincentive to continue with it. > > Regards, > Malcolm > > >> On 5 Oct 2015, at 10:05, Malcolm Wallace wrote: >> >>> I am also a strong -1 on small changes that break huge numbers of things for somewhat trivial benefits. >>> >>> Regards, >>> Malcolm >>> >>> On 2 Oct 2015, at 11:09, Henrik Nilsson wrote: >>> >>>> Hi all, >>>> >>>> I have discussed the monad of no return proposal with >>>> my colleague Graham Hutton: a long-standing member of >>>> the Haskell community, well-known researcher, some 20 >>>> years of experience of teaching Haskell to >>>> undergraduate students, and author of one of the most >>>> successful introductory Haskell textbooks there are. >>>> >>>> The upshot of this e-mail is a strong collective -2 >>>> from us both on particular proposal, and a general call >>>> for much more caution when it comes to breaking changes >>>> that are not critically important. >>>> >>>> First, on a general note, there has recently been a >>>> flurry of breaking changes to the (de facto) Haskell >>>> standards. In many cases for very good reasons, but >>>> sometimes it seems more in a quest for perfection >>>> without due consideration for the consequences. It used >>>> to be the case that breaking changes were very rare >>>> indeed. And for good reason. >>>> >>>> Right now, the main "measure of breakage" in the >>>> on-line discussions seems to be how many packages that >>>> break in Hackage. Which of course makes sense: the >>>> Hackage repository is very important and such a measure >>>> is objective, as far as it goes. >>>> >>>> But we should not forget that breakage can go far >>>> beyond Hackage. For starters, there is *lots* of code >>>> that is not in Hackage, yet critically important to its >>>> users, however many or few they are. There are more >>>> than hundreds of thousands of copies of books out there >>>> where that may break in that examples may no longer >>>> work. And they cannot be changed. There are countless >>>> research papers that may break in the same way. Every >>>> single institution that use Haskell in their teaching >>>> may have to update their teaching materials (slides, >>>> code, lab instructions) for every module that teaches >>>> or uses Haskell. And last but not the least, what >>>> countless of programmers and students have learned >>>> about Haskell over decades, most of whom are *not* >>>> power users who can take these changes in their stride, >>>> may also break. >>>> >>>> Now, of course a language has to evolve, and sometimes >>>> breaking backwards compatibility is more or less >>>> essential for the long-term benefit of the language. >>>> But we should not let perfection be the enemy of the >>>> good. >>>> >>>> As to this particular proposal, the monad of no return, >>>> it does not seem essential to us, but mostly motivated >>>> by a quest for "perfection" as defined by a very >>>> knowledgeable but in relative terms small group of >>>> people. >>>> >>>> One argument put forward was that applicative code that >>>> uses "return" instead of "pure" should get a less >>>> constrained type. But such code is relatively new. The >>>> methods of the Monad class have been return and bind >>>> for some 25 years. So indeed, as Henning Thielemann >>>> wrote: why should not the newer code be adapted and use >>>> "pure" instead? In fact, the use of "pure" in such code >>>> could serve as a quite useful cue that the code is >>>> applicative rather than monadic, especially where >>>> applicative do is employed. >>>> >>>> Another reason put forward is support for the >>>> applicative do syntax. But that is, in standard terms, >>>> only a future possibility at this point. Further, the >>>> syntax is arguably rather dubious anyway as it, in >>>> particular to someone with an imperative background, >>>> suggests a sequential reading which is exactly what >>>> applicative is not and why it is useful. So from that >>>> perspective, using the applicative operators directly, >>>> without any syntactic sugar, actually amounts to a much >>>> more transparent and honest syntax, even if a bit more >>>> verbose in some cases. >>>> >>>> The bottom line is that it is premature to put forward >>>> support for the applicative do syntax as a rationale >>>> for a non-essential breaking change. >>>> >>>> Best regards, >>>> >>>> Henrik Nilsson and Graham Hutton >>>> >>>> -- >>>> Henrik Nilsson >>>> School of Computer Science >>>> The University of Nottingham >>>> nhn at cs.nott.ac.uk >>> >> > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > From s.j.thompson at kent.ac.uk Mon Oct 5 09:59:46 2015 From: s.j.thompson at kent.ac.uk (Simon Thompson) Date: Mon, 5 Oct 2015 10:59:46 +0100 Subject: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> Message-ID: <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Hello all. I write this to be a little provocative, but ? It?s really interesting to have this discussion, which pulls in all sorts of well-made points about orthogonality, teaching, the evolution of the language and so on, but it simply goes to show that the process of evolving Haskell is profoundly broken. Other languages do evolve, but in a managed and reflective way. Simply throwing in changes that would have a profound impact on systems that are commercially and potentially safety critical in an ? la carte, offhand, way seems like a breakdown of the collective responsibility of the Haskell community to its users and, indirectly, to its future. If we make claims - I believe rightly - that Haskell is hitting the mainstream, then we need to think about all changes in terms of the costs and benefits of each of them in the widest possible sense. There?s an old fashioned maxim that sums this up in a pithy way: ?if it ain?t broke, don?t fix it?. Simon Thompson > On 5 Oct 2015, at 10:47, Micha? J Gajda wrote: > > Hi, > > As a person who used Haskell in all three capacities (for scientific research, for commercial purpose, and to introduce others to benefits of pure and strongly typed programming), I must voice an supportive voice for this change: > 1. Orthogonal type classes are easier to explain. > 2. Gradual improvements helps us to generalize further, and this in turn makes education easier. > 3. Gradual change that break only a little help to prevent either stagnation (FORTRAN) and big breakage (py3k). That keeps us excited. > > That would also call to split TCs into their orthogonal elements: return, ap, bind having the basic TC on their own. > > So: > +1, but only if it is possible to have compatibilty mode. I believe that rebindable syntax should allow us to otherwise make our own prelude, if we want such a split. Then we could test it well before it is used by the base library. > > That said, I would appreciate Haskell2010 option just like Haskell98 wad, so that we can compile old programs without changes. Even by using some Compat version of standard library. Would that satisfy need for stability? > > PS And since all experts were beginners some time ago, I beg that we do not call them "peripheral". > -- > Best regards > Micha? > > On Monday, 5 October 2015, Malcolm Wallace > wrote: > On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be > (...) > > > -- > Pozdrawiam > Micha? > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Mon Oct 5 12:16:12 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Mon, 5 Oct 2015 14:16:12 +0200 Subject: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: <56126A0C.5090602@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/10/15 11:59, Simon Thompson wrote: > There?s an old fashioned maxim that sums this up in a pithy way: > ?if it ain?t broke, don?t fix it?. But... it *is* broken. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWEmoJAAoJENQqWdRUGk8BAKUP/iJ6z/E6UK83uArlxgSA/cKJ nOLluw3UZeFPscpAiwqnXw4KuTy6l1wKgqEzLmywHX3JvxxNQQyHA4oSgXqp64IQ lMdPlMAFx9sqGzBIS9rDC/GQRGPePc6a85316Z6ZlwDHkhpm5zgXFb7nbl4mvjFO BY4Bkv7WmiE2FlE2WIGTuw94MXwY8qW7kk/TpG6rG7COGAGNfbR1Jfc5LF1Y88xq oloxHOQJ6rRhwQBan7OBO3zWF6TG1GcopT+W1KmLSQbY15hcDFe+YU7jz2ilryYy gsOwYyvn3LXsJNNtIZWlElrwIppEMquQIfJy4jq715wjcz1ozSHAkPTWSifNDeA+ 8dyrCzqQDjXi9ADsoZDjLv7sJKrDfonBp3gdTiUJnc1pAGBvyeNNl1vlpt8z5vmw 5bNVn6pLSCxQuTVLcxYBNUlBy3K0RgnJU+SFz5dShN0xSp4vG+H/5Vw08a3den4G xShS0oaFlzQhu5Mf9JXNJTblHvs5gp1d0pAQnu5xlNblNBeD3p4yy73BAqwuFflu wlyM1ZvVeq0OY8yBKqdxIXYzmDUJyT77mrH4jbVUVC2cRrTYa11Govnu6WCXbmdL FsvLHxV/xRuGJu+T1tps1uMSe3dZncEQ6vudyyUcnF27JiMJGBY2gjJZ3xmVVdM9 4DFN9td4AgpnaeNo+9j5 =AREs -----END PGP SIGNATURE----- From allbery.b at gmail.com Mon Oct 5 13:16:21 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 5 Oct 2015 09:16:21 -0400 Subject: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <56126A0C.5090602@plaimi.net> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <56126A0C.5090602@plaimi.net> Message-ID: On Mon, Oct 5, 2015 at 8:16 AM, Alexander Berntsen wrote: > On 05/10/15 11:59, Simon Thompson wrote: > > There?s an old fashioned maxim that sums this up in a pithy way: > > ?if it ain?t broke, don?t fix it?. > But... it *is* broken. > Somehow, we managed to use Monad before this. That does not sound "broken". -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Mon Oct 5 13:20:51 2015 From: alexander at plaimi.net (Alexander Berntsen) Date: Mon, 5 Oct 2015 15:20:51 +0200 Subject: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <56126A0C.5090602@plaimi.net> Message-ID: <56127933.2000100@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/10/15 15:16, Brandon Allbery wrote: > On Mon, Oct 5, 2015 at 8:16 AM, Alexander Berntsen wrote: >> But... it *is* broken. > Somehow, we managed to use Monad before this. That does not sound > "broken". Just because something is broken does not mean that it is not possible to use it. We use broken things and are subject to broken systems all day every day. You may of course argue that it is fine for it to be broken. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJWEnkvAAoJENQqWdRUGk8BdM8P/3f66SDBrDSNLajDyTnBkL3o Ip0FuEn2VuSwXtXhIDYPkacgzMsO56cm1OZeU5LoPH1vMmzNx63VQftaxtk00yaR dfbjpkS64JMSOQGSwcj1B31RjIlhFLlGrSx2OlByIQ1agjZmv4eKmTDkc3QAEvYc HpBvcgSCyMO6WXXPtIem5gqZluHONe+UX8I/EUtJwOUaZCndpsvpSF9xAF7TkUbE Co2X45tk1c6OnLtj7YaPPtDgV8KTlFpvTowvvFM67JP6VlDGX1NAtT0Bfm1/KnEA KmWhpy0Kv4r0bbqOUtcS/oGeduio7bBIWDfnmP6S60SsWfM64AnamblLGbyi87E8 ambN0K4sEZT+NA6jEb4L7eqKf0kaVBYpCj+xG1kFX9Zy3Q2dx7++SNdqC3KmLtDZ 3MtEjoCmVdwBl4NpECkz0roxyeoS38gmroPSpk69kOgsHkbn4xriv26DXumRJuzP l+/fsoyQWPVUB03k+qIemxkfIF6bQI7c6XdACkfoRjFU8/S8FRt+1357MlFGxmEp U165NrvFyQFDa+qQpsz2+UO7hqg5ymuFwKZySmr85jRG7bGMJofN2KDf3a8xQzWp Jn3j3p0CaX1PO11kXJILx80GoPV1p5RDTj+6SeOpa8eg5Ba3mvFhbrQ7da0isxYE MhSyoU0ZhaylCkzjM0lm =h9OY -----END PGP SIGNATURE----- From svenpanne at gmail.com Mon Oct 5 13:27:53 2015 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 5 Oct 2015 15:27:53 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: 2015-10-05 11:59 GMT+02:00 Simon Thompson : > [...] It?s really interesting to have this discussion, which pulls in all > sorts of well-made points about orthogonality, teaching, the evolution of > the language and so on, but it simply goes to show that the process of > evolving Haskell is profoundly broken. [...] > I wouldn't necessarily call the process "broken", but it's a bit annoying: Because of the constant flux of minor changes in the language and the libraries, I've reached the stage where I'm totally unable to tell if my code will work for the whole GHC 7.x series. The only way I see is doing heavy testing on Travis CI and littering the code with #ifdefs after compilation failures. (BTW: Fun exercise: Try using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for keeping the #ifdefs centralized. No clue how to do that...) This is less than satisfactory IMHO, and I would really prefer some other mode for introducing such changes: Perhaps these should be bundled and released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way some stuff which belongs together (AMP, FTP, kicking out return, etc.) comes in slightly larger, but more sensible chunks. Don't get me wrong: Most of the proposed changes in itself are OK and should be done, it's only the way they are introduced should be improved... -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonymorris at gmail.com Mon Oct 5 13:32:38 2015 From: tonymorris at gmail.com (Tony Morris) Date: Mon, 5 Oct 2015 23:32:38 +1000 Subject: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <56126A0C.5090602@plaimi.net> Message-ID: <56127BF6.9060804@gmail.com> "Broken" here is hyperbole for "can be significantly improved for very little penalty." On 05/10/15 23:16, Brandon Allbery wrote: > > On Mon, Oct 5, 2015 at 8:16 AM, Alexander Berntsen > wrote: > > On 05/10/15 11:59, Simon Thompson wrote: > > There?s an old fashioned maxim that sums this up in a pithy way: > > ?if it ain?t broke, don?t fix it?. > But... it *is* broken. > > > Somehow, we managed to use Monad before this. That does not sound "broken". > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com > ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > From hvr at gnu.org Mon Oct 5 14:32:40 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Mon, 05 Oct 2015 16:32:40 +0200 Subject: Language Change Management (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: (Sven Panne's message of "Mon, 5 Oct 2015 15:27:53 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: <87lhbhperb.fsf_-_@gnu.org> On 2015-10-05 at 15:27:53 +0200, Sven Panne wrote: > 2015-10-05 11:59 GMT+02:00 Simon Thompson : > >> [...] It?s really interesting to have this discussion, which pulls in all >> sorts of well-made points about orthogonality, teaching, the evolution of >> the language and so on, but it simply goes to show that the process of >> evolving Haskell is profoundly broken. [...] >> > > I wouldn't necessarily call the process "broken", but it's a bit > annoying: Because of the constant flux of minor changes in the > language and the libraries, I've reached the stage where I'm totally > unable to tell if my code will work for the whole GHC 7.x series. The > only way I see is doing heavy testing on Travis CI and littering the > code with #ifdefs after compilation failures. (BTW: Fun exercise: Try > using (<>) and/or (<$>) in conjunction with -Wall. Bonus points for > keeping the #ifdefs centralized. No clue how to do that...) This is > less than satisfactory IMHO, and I would really prefer some other mode > for introducing such changes: Perhaps these should be bundled and > released e.g. every 2 years as Haskell2016, Haskell2018, etc. This way > some stuff which belongs together (AMP, FTP, kicking out return, etc.) > comes in slightly larger, but more sensible chunks. > > Don't get me wrong: Most of the proposed changes in itself are OK and > should be done, it's only the way they are introduced should be > improved... I think that part of the reason we have seen these changes occur in a "constant flux" rather than in bigger coordinated chunks is that faith in the Haskell Report process was (understandably) abandoned. And without the Haskell Report as some kind of "clock generator" with which to align/bundle related changes into logical units, changes occur whenever they're proposed and agreed upon (which may take several attempts as we've seen with the AMP and others). I hope that the current attempt to revive the Haskell Prime process will give us a chance to clean up the unfinished intermediate `base-4.8` situation we're left with now after AMP, FTP et al, as the next Haskell Report revision provides us with a milestone to work towards. That being said, there's also the desire to have changes field-tested by a wide audience on a wide range before integrating them into a Haskell Report. Also I'm not sure if there would be less complaints if AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on all at once in e.g. `base-5.0`, breaking almost *every* single package out there at once. For language changes we have a great way to field-test new extensions before integrating them into the Report via `{-# LANGUAGE #-}` pragmas in a nicely modular and composable way (i.e. a package enabling a certain pragma doesn't require other packages to use it as well) which have proven to be quite popular. However, for the library side we lack a comparable mechanism at this point. The closest we have, for instance, to support an isolated Haskell2010 legacy environment is to use RebindableSyntax which IMO isn't good enough in its current form[1]. And then there's the question whether we want a Haskell2010 legacy environment that's isolated or rather shares the types & typeclasses w/ `base`. If we require sharing types and classes, then we may need some facility to implicitly instanciate new superclasses (e.g. implicitly define Functor and Applicative if only a Monad instance is defined). If we don't want to share types & classes, we run into the problem that we can't easily mix packages which depend on different revisions of the standard-library (e.g. one using `base-4.8` and others which depend on a legacy `haskell2010` base-API). One way to solve this could be to mutually exclude depending on both , `base-4.8` and `haskell2010`, in the same install-plan (assuming `haskell2010` doesn't depend itself on `base-4.8`) In any case, I think we will have to think hard how to address language/library change management in the future, especially if the Haskell code-base continues to grow. Even just migrating the code base between Haskell Report revisions is a problem. An extreme example is the Python 2->3 transition which the Python ecosystem is still suffering from today (afaik). Ideas welcome! [1]: IMO, we need something to be used at the definition site providing desugaring rules, rather than requiring the use-site to enable a generalised desugaring mechanism; I've been told that Agda has an interesting solution to this in its base libraries via {-# LANGUAGE BUILTIN ... #-} pragmas. Regards, H.V.Riedel From gershomb at gmail.com Mon Oct 5 14:32:21 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 5 Oct 2015 10:32:21 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: On October 5, 2015 at 6:00:00 AM, Simon Thompson (s.j.thompson at kent.ac.uk) wrote: > Hello all. I write this to be a little provocative, but ? > > It?s really interesting to have this discussion, which pulls in all sorts of well-made > points about orthogonality, teaching, the evolution of the language and so on, but it > simply goes to show that the process of evolving Haskell is profoundly broken. > > Other languages do evolve, but in a managed and reflective way. Simply throwing in changes > that would have a profound impact on systems that are commercially and potentially safety > critical in an ? la carte, offhand, way seems like a breakdown of the collective responsibility > of the Haskell community to its users and, indirectly, to its future. Hi Simon. I do in fact think this is provocative :-P I want to object here to your characterization of what has been going on as ?simply throwing in changes?. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period. I also want to object to the idea that these changes would have ?a profound impact on systems?. As it stands, and I think this is an important criteria in any change, when ?phase 2? goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior. Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind? ?Gershom P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns. From bos at serpentine.com Mon Oct 5 14:59:32 2015 From: bos at serpentine.com (Bryan O'Sullivan) Date: Mon, 5 Oct 2015 07:59:32 -0700 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: I would like to suggest that the bar for breaking all existing libraries, books, papers, and lecture notes should be very high; and that the benefit associated with such a breaking change should be correspondingly huge. This proposal falls far short of both bars, to the extent that I am astonished and disappointed it is being seriously discussed ? and to general approval, no less ? on a date other than April 1. Surely some design flaws have consequences so small that they are not worth fixing. I'll survive if it goes through, obviously, but it will commit me to a bunch of pointless make-work and compatibility ifdefs. I've previously expressed my sense that cross-version compatibility is a big tax on library maintainers. This proposal does not give me confidence that this cost is being taken seriously. Thanks, Bryan. > On Oct 5, 2015, at 7:32 AM, Gershom B wrote: > >> On October 5, 2015 at 6:00:00 AM, Simon Thompson (s.j.thompson at kent.ac.uk) wrote: >> Hello all. I write this to be a little provocative, but ? >> >> It?s really interesting to have this discussion, which pulls in all sorts of well-made >> points about orthogonality, teaching, the evolution of the language and so on, but it >> simply goes to show that the process of evolving Haskell is profoundly broken. >> >> Other languages do evolve, but in a managed and reflective way. Simply throwing in changes >> that would have a profound impact on systems that are commercially and potentially safety >> critical in an ? la carte, offhand, way seems like a breakdown of the collective responsibility >> of the Haskell community to its users and, indirectly, to its future. > > Hi Simon. I do in fact think this is provocative :-P > > I want to object here to your characterization of what has been going on as ?simply throwing in changes?. The proposal seems very well and carefully worked through to provide a good migration strategy, even planning to alter the source of GHC to ensure that adequate hints are given for the indefinite transition period. > > I also want to object to the idea that these changes would have ?a profound impact on systems?. As it stands, and I think this is an important criteria in any change, when ?phase 2? goes into affect, code that has compiled before may cease to compile until a minor change is made. However, code that continues to compile will continue to compile with the same behavior. > > Now as to process itself, this is a change to core libraries. It has been proposed on the libraries list, which seems appropriate, and a vigorous discussion has ensued. This seems like a pretty decent process to me thus far. Do you have a better one in mind? > > ?Gershom > > P.S. as a general point, I sympathize with concerns about breakage resulting from this, but I also think that the migration strategy proposed is good, and if people are concerned about breakage I think it would be useful if they could explain where they feel the migration strategy is insufficient to allay their concerns. > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime From gershomb at gmail.com Mon Oct 5 15:09:23 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 5 Oct 2015 11:09:23 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com) wrote: > I would like to suggest that the bar for breaking all existing libraries, books, papers, > and lecture notes should be very high; and that the benefit associated with such a breaking > change should be correspondingly huge. > My understanding of the argument here, which seems to make sense to me, is that the AMP already introduced a significant breaking change with regards to monads. Books and lecture notes have already not caught up to this, by and large. Hence, by introducing a further change, which _completes_ the general AMP project, then by the time books and lecture notes are all updated, they will be able to tell a much nicer story than the current one? As for libraries, it has been pointed out, I believe, that without CPP one can write instances compatible with AMP, and also with AMP + MRP. One can also write code, sans CPP, compatible with pre- and post- AMP. So the reason for choosing to not do MRP simultaneous with AMP was precisely to allow a gradual migration path where, sans CPP, people could write code compatible with the last three versions of GHC, as the general criteria has been. So without arguing the necessity or not, I just want to weigh in with a technical opinion that if this goes through, my _estimation_ is that there will be a smooth and relatively painless migration period, the sky will not fall, good teaching material will remain good, those libraries that bitrot will tend to do so for a variety of reasons more significant than this, etc. It is totally reasonable to have a discussion on whether this change is worth it at all. But let?s not overestimate the cost of it just to further tip the scales :-) ?gershom From lennart at augustsson.net Mon Oct 5 16:31:12 2015 From: lennart at augustsson.net (Lennart Augustsson) Date: Mon, 5 Oct 2015 18:31:12 +0200 Subject: Self-nomination Message-ID: I would like to nominate myself to the Haskell Prime committee. About me: * I wrote the first publicly available Haskell compiler, hbc, which was available August 1990. * Subsequently I've written three more Haskell(-ish) compilers. * I've been on the Haskell Committee before. * I like experimentation with language features, but I'm very conservative about using them in production code. -- Lennart Augustsson -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Mon Oct 5 18:58:57 2015 From: svenpanne at gmail.com (Sven Panne) Date: Mon, 5 Oct 2015 20:58:57 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: 2015-10-05 17:09 GMT+02:00 Gershom B : > On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com) > wrote: > [...] As for libraries, it has been pointed out, I believe, that without > CPP one can write instances compatible with AMP, and also with AMP + MRP. > One can also write code, sans CPP, compatible with pre- and post- AMP. [...] > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which is now part of the Prelude, you can't simply import some compatibility module, because GHC might tell you (rightfully) that that import is redundant, because (<$>) is already visible through the Prelude. So you'll have to use CPP to avoid that import on base >= 4.8, be it from it Data.Functor, Control.Applicative or some compat-* module. And you'll have to use CPP in each and every module using <$> then, unless I miss something obvious. AFAICT all transitioning guides ignore -Wall and friends... -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Mon Oct 5 19:01:16 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 5 Oct 2015 21:01:16 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins wrote: > > On Mon, Oct 5, 2015 at 8:09 AM, Gershom B wrote: > >> My understanding of the argument here, which seems to make sense to me, >> is that the AMP already introduced a significant breaking change with >> regards to monads. Books and lecture notes have already not caught up to >> this, by and large. Hence, by introducing a further change, which >> _completes_ the general AMP project, then by the time books and lecture >> notes are all updated, they will be able to tell a much nicer story than >> the current one? > > > This is a multi-year, "boil the ocean"-style project, affecting literally > every Haskell user, and the end result after all of this labor is going to > be... a slightly spiffier bike shed? > > Strongly -1 from me also. My experience over the last couple of years is > that every GHC release breaks my libraries in annoying ways that require > CPP to fix: > > ~/personal/src/snap ? find . -name '*.hs' | xargs egrep > '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l > 64 > > > As a user this is another bikeshedding change that is not going to benefit > me at all. Maintaining a Haskell library can be an exasperating exercise of > running on a treadmill to keep up with busywork caused by changes to the > core language and libraries. My feeling is starting to become that the > libraries committee is doing as much (if not more) to *cause* problems > and work for me than it is doing to improve the common infrastructure. > On the libraries I maintain and have a copy of on my computer right now: 329 -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Mon Oct 5 19:05:40 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Mon, 5 Oct 2015 21:05:40 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: On Mon, Oct 5, 2015 at 9:02 PM, Erik Hesselink wrote: > On 5 October 2015 at 20:58, Sven Panne wrote: > > 2015-10-05 17:09 GMT+02:00 Gershom B : > >> > >> [...] As for libraries, it has been pointed out, I believe, that without > >> CPP one can write instances compatible with AMP, and also with AMP + > MRP. > >> One can also write code, sans CPP, compatible with pre- and post- AMP. > [...] > > > > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which > is > > now part of the Prelude, you can't simply import some compatibility > module, > > because GHC might tell you (rightfully) that that import is redundant, > > because (<$>) is already visible through the Prelude. So you'll have to > use > > CPP to avoid that import on base >= 4.8, be it from it Data.Functor, > > Control.Applicative or some compat-* module. And you'll have to use CPP > in > > each and every module using <$> then, unless I miss something obvious. > > AFAICT all transitioning guides ignore -Wall and friends... > > Does the hack mentioned on the GHC trac [1] work for this? It seems a > bit fragile but that page says it works and it avoids CPP. > No it doesn't, if you also don't want closed import lists (which you should). -------------- next part -------------- An HTML attachment was scrubbed... URL: From simons at cryp.to Mon Oct 5 19:17:25 2015 From: simons at cryp.to (Peter Simons) Date: Mon, 05 Oct 2015 21:17:25 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: <874mi5jfay.fsf@write-only.cryp.to> Sven Panne writes: > If you take e.g. (<$>) which is now part of the Prelude, you can't > simply import some compatibility module, because GHC might tell you > (rightfully) that that import is redundant, because (<$>) is already > visible through the Prelude. Yes, the proper solution is slightly more complicated than just importing Prelude.Compat [1]. You also have to specify "import Prelude ()" -- or compile with NoImplicitPrelude, if you prefer that kind of thing. Best regards Peter [1] http://hackage.haskell.org/package/base-compat-0.8.2/docs/Prelude-Compat.html From wren at community.haskell.org Tue Oct 6 00:49:19 2015 From: wren at community.haskell.org (wren romano) Date: Mon, 5 Oct 2015 20:49:19 -0400 Subject: Language Change Management (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87lhbhperb.fsf_-_@gnu.org> Message-ID: On Mon, Oct 5, 2015 at 5:23 PM, Adam Foltzer wrote: >> Also I'm not sure if there would be less complaints if >> AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on all >> at once in e.g. `base-5.0`, breaking almost *every* single package out there >> at once. > > I doubt the number of complaints-per-change would be fewer, but I'm strongly > in favor of moving away from what feels like a treadmill that doesn't value > the time of developers and that doesn't account for the > more-than-sum-of-parts cost of the "constant flux". Broadly speaking, I'm a "fix it now rather than later" sort of person in Haskell because I've seen how long things can linger before finally getting fixed (even when everyone agrees on what the fix should be and agrees that it should be done). However, as I mentioned in the originating thread, I think that ?at this point? when it comes to AMP/FTP/MFP/MRP/etc we should really aim for the haskell' committee to work out a comprehensive solution (as soon as possible), and then enact all the changes at once when switching to Haskell201X/base-5.0/whatevs. I understand the motivations for wanting things to be field-tested before making it into the report, but I don't think having a series of rapid incremental changes is the correct approach here. Because we're dealing with the Prelude and the core classes, the amount of breakage (and CPP used to paper over it) here is much higher than our usual treadmill of changes; so we should take that into account when planning how to roll the changes out. -- Live well, ~wren From spam at scientician.net Tue Oct 6 07:18:47 2015 From: spam at scientician.net (Bardur Arantsson) Date: Tue, 6 Oct 2015 09:18:47 +0200 Subject: Language Change Management In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87lhbhperb.fsf_-_@gnu.org> Message-ID: On 10/06/2015 02:49 AM, wren romano wrote: > On Mon, Oct 5, 2015 at 5:23 PM, Adam Foltzer wrote: >>> Also I'm not sure if there would be less complaints if >>> AMP/FTP/MFP/MRP/etc as part of a new Haskell Report would be switched on all >>> at once in e.g. `base-5.0`, breaking almost *every* single package out there >>> at once. >> >> I doubt the number of complaints-per-change would be fewer, but I'm strongly >> in favor of moving away from what feels like a treadmill that doesn't value >> the time of developers and that doesn't account for the >> more-than-sum-of-parts cost of the "constant flux". > > Broadly speaking, I'm a "fix it now rather than later" sort of person > in Haskell because I've seen how long things can linger before finally > getting fixed (even when everyone agrees on what the fix should be and > agrees that it should be done). However, as I mentioned in the > originating thread, I think that ?at this point? when it comes to > AMP/FTP/MFP/MRP/etc we should really aim for the haskell' committee to > work out a comprehensive solution (as soon as possible), and then > enact all the changes at once when switching to > Haskell201X/base-5.0/whatevs. In general: Yes, when everybody more or less agrees what the Right Thing then this is probably the way to go. (But it still carries the risk of e.g. C++ "template exports" which seemed a good idea a the time, but was unimplementable.) In this specific case: Isn't the proposal under discussion here more or less the end game for the change to Applicative/Monad? (I mean, I don't think anyone's seriously suggesting *removing* "return" completely any time soon.) If so, then I think the only thing punting this specific proposal to the new Haskell' committe will achieve is to postpone the stream of complaints :). Plus, we still haven't seen that the new committe will actually achieve anything of note. There seem to be be good signs, but we've been here before... > I understand the motivations for wanting > things to be field-tested before making it into the report, but I > don't think having a series of rapid incremental changes is the > correct approach here. Because we're dealing with the Prelude and the > core classes, the amount of breakage (and CPP used to paper over it) > here is much higher than our usual treadmill of changes; so we should > take that into account when planning how to roll the changes out. > This seems to be ignoring the huge amount of planning that actually *did* go into this proposal (and the BPP, etc.). No amount of planning can get around the fact that some people simply *don't want any change*. Regards, From spam at scientician.net Tue Oct 6 07:30:37 2015 From: spam at scientician.net (Bardur Arantsson) Date: Tue, 6 Oct 2015 09:30:37 +0200 Subject: Language Change Management In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87lhbhperb.fsf_-_@gnu.org> Message-ID: On 10/06/2015 09:18 AM, Bardur Arantsson wrote: > On 10/06/2015 02:49 AM, wren romano wrote: [--snip--] > > No amount of planning can get around the fact that some people simply > *don't want any change*. > Forgot a little side note: Bundling more changes may seem like a good idea, but that also carries a risk of a) missing potentially *good* interactions between proposed changes and b) missing potentially *bad/fatal* interactions between proposed changes. (Again, because nobody's actually tried them yet.) Regards, From johan.tibell at gmail.com Tue Oct 6 08:12:13 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 6 Oct 2015 10:12:13 +0200 Subject: MRP, 3-year-support-window, and the non-requirement of CPP (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> Message-ID: (Resending with smaller recipient list to avoid getting stuck in the moderator queue.) On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel wrote: > On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote: > > On the libraries I maintain and have a copy of on my computer right now: > 329 > > > Although this was already pointed out to you in a response to a Tweet of > yours, I'd like to expand on this here to clarify: > > > You say that you stick to the 3-major-ghc-release support-window > convention for your libraries. This is good, because then you don't need > any CPP at all! Here's why: > > [...] > So what do I have to write today to have my Monad instances be: * Warning free - Warnings are useful. Turning them off or having spurious warnings both contribute to bugs. * Use imports that either are qualified or have explicit import lists - Unqualified imports makes code more likely to break when dependencies add exports. * Don't use CPP. Neither AMP or MRP includes a recipe for this in their proposal. AMP got one post-facto on the Wiki. It turns out that the workaround there didn't work (we tried it in Cabal and it conflicted with one of the above requirements.) PS: I'm a bit disappointed you seem to dismiss this proposal right away > categorically without giving us a chance to address your > concerns. The proposal is not a rigid all-or-nothing thing that > can't be tweaked and revised. That's why we're having these > proposal-discussions in the first place (rather than doing blind > +1/-1 polls), so we can hear everyone out and try to maximise the > agreement (even if we will never reach 100% consensus on any > proposal). > > So please, keep on discussing! > The problem by discussions is that they are done between two groups with quite a difference in experience. On one hand you have people like Bryan, who have considerable contributions to the Haskell ecosystem and much experience in large scale software development (e.g. from Facebook). On the other hand you have people who don't. That's okay. We've all been at the latter group at some point of our career. What's frustrating is that people don't take a step bad and realize that they might be in the latter group and should perhaps listen to those in the former. This doesn't happen, instead we get lots of "C++ and Java so bad and we don't want to be like them." Haskell is not at risk of becoming C++ or Java (which are a large improvement compared to the languages came before them). We're at risk of missing our window of opportunity. I think that would be a shame, as I think Haskell is a step forward compared to those languages and I would like to see more software that used be written in Haskell. We've been through this many times before on the libraries list. I'm not going to win an argument on this mailing list. Between maintaining libraries you all use and managing a largish team at Google, I don't have much time for a discussion which approaches a hundred emails and is won by virtue of having lots of time to write emails. -- Johan -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Tue Oct 6 09:11:47 2015 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 6 Oct 2015 11:11:47 +0200 Subject: Reducing the need for CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: <87k2r0z8r6.fsf@smart-cactus.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87k2r0z8r6.fsf@smart-cactus.org> Message-ID: It might be enough to just add a NOWARN pragma that acts on a single line/expression. I've seen it in both C++ and Python linters and it works reasonably well and it's quite general. On Tue, Oct 6, 2015 at 10:44 AM, Ben Gamari wrote: > Sven Panne writes: > > > 2015-10-05 17:09 GMT+02:00 Gershom B : > > > >> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com > ) > >> wrote: > >> [...] As for libraries, it has been pointed out, I believe, that without > >> CPP one can write instances compatible with AMP, and also with AMP + > MRP. > >> One can also write code, sans CPP, compatible with pre- and post- AMP. > [...] > >> > > > > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which > is > > now part of the Prelude, you can't simply import some compatibility > module, > > because GHC might tell you (rightfully) that that import is redundant, > > because (<$>) is already visible through the Prelude. So you'll have to > use > > CPP to avoid that import on base >= 4.8, be it from it Data.Functor, > > Control.Applicative or some compat-* module. And you'll have to use CPP > in > > each and every module using <$> then, unless I miss something obvious. > > AFAICT all transitioning guides ignore -Wall and friends... > > > This is a fair point that comes up fairly often. The fact that CPP is > required to silence redundant import warnings is quite unfortunate. > Others languages have better stories in this area. One example is Rust, > which has a quite flexible `#[allow(...)]` pragma which can be used to > acknowledge and silence a wide variety of warnings and lints [1]. > > I can think of a few ways (some better than others) how we might > introduce a similar idea for import redundancy checks in Haskell, > > 1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition, > > -- in Control.Applicative > {-# ALLOW redundant_import (<$>) #-} > (<$>) :: (a -> b) -> f a -> f b > (<$>) = fmap > > asking the compiler to pretend that any import of the symbol did not > exist when looking for redundant imports. This would allow library > authors to appropriately mark definitions when they are moved, > saving downstream users from having to make any change whatsoever. > > 2. Or alternatively we could make this a idea a bit more precise, > > -- in Control.Applicative > {-# ALLOW redundant_import Prelude.(<$>) #-} > (<$>) :: (a -> b) -> f a -> f b > (<$>) = fmap > > Which would ignore imports of `Control.Applicative.(<$>)` only if > `Prelude.(<$>)` were also in scope. > > 3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import, > > import {-# ALLOW redundant_import #-} Control.Applicative > > -- or perhaps > import Control.Applicative > {-# ALLOW redundant_import Control.Applicative #-} > > allowing the user to explicitly state that they are aware that this > import may be redundant. > > 4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an > import list, > > import Control.Applicative ((<$>) {-# ALLOW redundant_import #-}) > > allowing the user to explicitly state that they are aware that this > imported function may be redundant. > > In general I'd like to reiterate that many of the comments in this > thread describe genuine sharp edges in our language which have presented > a real cost in developer time during the AMP and and FTP transitions. I > think it is worth thinking of ways to soften these edges; we may be > surprised how easy it is to fix some of them. > > - Ben > > > [1] https://doc.rust-lang.org/stable/reference.html#lint-check-attributes > > _______________________________________________ > 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 _deepfire at feelingofgreen.ru Tue Oct 6 09:30:12 2015 From: _deepfire at feelingofgreen.ru (Kosyrev Serge) Date: Tue, 06 Oct 2015 12:30:12 +0300 Subject: [Haskell-cafe] Reducing the need for CPP In-Reply-To: <87k2r0z8r6.fsf@smart-cactus.org> (sfid-20151006_130812_301207_6B09ABEE) (Ben Gamari's message of "Tue, 06 Oct 2015 10:44:29 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87k2r0z8r6.fsf@smart-cactus.org> Message-ID: <87h9m4l4yj.fsf@feelingofgreen.ru> Ben Gamari writes: > This is a fair point that comes up fairly often. The fact that CPP is > required to silence redundant import warnings is quite unfortunate. > Others languages have better stories in this area. One example is Rust, > which has a quite flexible `#[allow(...)]` pragma which can be used to > acknowledge and silence a wide variety of warnings and lints [1]. > > I can think of a few ways (some better than others) how we might > introduce a similar idea for import redundancy checks in Haskell, > > 1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition, ... > 2. Or alternatively we could make this a idea a bit more precise, > {-# ALLOW redundant_import Prelude.(<$>) #-} ... > 3. Attach a `{-# ALLOW redundancy_import #-}` pragma to an import, > import {-# ALLOW redundant_import #-} Control.Applicative ... > 4. Attach a `{-# ALLOW redundancy_import #-}` pragma to a name in an > import list, > import Control.Applicative ((<$>) {-# ALLOW redundant_import #-}) What I don't like about this solution is how specific it is -- the gut instinct that it can't be the last such extension, if we were to start replacing CPP piecemeal. And after a while, we'd accomodate a number of such extensions.. and they would keep coming.. until it converges to a trainwreck. I think that what instead needs to be done, is this: 1. a concerted effort to summarize *all* uses of CPP in Haskell code 2. a bit of forward thinking, to include desirables that would be easy to get with a more generic solution Personally, I think that any such effort, approached with generality that would be truly satisfying, should inevitably converge to an AST-level mechanism. ..but then I remember how CPP can be used to paper over incompatible syntax changes.. Hmm.. -- ? ???????e? / respectfully, ??????? ?????? From Henrik.Nilsson at nottingham.ac.uk Tue Oct 6 11:32:31 2015 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Tue, 06 Oct 2015 12:32:31 +0100 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: <5613B14F.9070107@nottingham.ac.uk> Dear all, Executive Summary: Please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee While we can discuss the extent of additional breakage MRP would cause, the fact remains it is a further breaking change. A survey of breakage to books as Herbert did is certainly valuable (thanks!), but much breakage will (effectively) remain unquantifiable. It is also clear from the discussions over the last couple of weeks, on the Haskell libraries list as well as various other forums and social media, that MRP is highly contentions. This begs two questions: 1. Is the Haskell Libraries list and informal voting process really an appropriate, or even acceptable, way to adopt such far-reaching changes to what effectively amounts to Haskell itself? 2. Why the hurry to push MRP through? As to question 1, to Graham Hutton's and my knowledge, the libraries list and its voting process was originally set up for 3rd-party libraries in fptools. It seems to have experienced some form of "mission creep" since. Maybe that is understandable given that there was no obvious alternative as HaskellPrime has been defunct for a fair few years. But, as has been pointed out in a number of postings, a lot of people with very valuable perspectives are also very busy, and thus likely to miss a short discussion period (as has happened in the past in relation to the Burning the Bridges proposal) and also have very little time for engaging in long and complicated e-mail discussions that, from their perspective, happen at a completely random point in time and for which they thus have not had a chance to set aside time even if they wanted to participate. Just as one data point, AMP etc. mostly passed Graham and me by simply because a) we were too busy to notice and b) we simply didn't think there was a mandate for such massive overhauls outside of a process like HaskellPrime. And we are demonstrably not alone. This brings us to question 2. Now that HaskellPrime is being resurrected, why the hurry to push MRP through? Surely HaskellPrime is the forum where breaking changes like MRP should be discussed, allowing as much time as is necessary and allowing for an as wide range of perspectives as possible to properly be taken into account? The need to "field test" MRP prior to discussing it in HaskellPrime has been mentioned. Graham and I are very sceptical. In the past, at least in the past leading up to Haskell 2010 or so, the community at large was not roped in as involuntary field testers. If MRP is pushed through now, with a resurrection of HaskellPrime being imminent, Graham and I strongly believe that risks coming across to a very large part of the Haskell community as preempting proper process by facing the new HaskellPrime committee with (yet another) fait accompli. Therefore, please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee, which is where it properly belongs. Otherwise, the Haskell community itself might be one of the things that MRP breaks. Best regards, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn at cs.nott.ac.uk 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 hvr at gnu.org Tue Oct 6 07:10:12 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 06 Oct 2015 09:10:12 +0200 Subject: MRP, 3-year-support-window, and the non-requirement of CPP (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: (Johan Tibell's message of "Mon, 5 Oct 2015 21:01:16 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> Message-ID: <87zizw8obv.fsf_-_@gnu.org> On 2015-10-05 at 21:01:16 +0200, Johan Tibell wrote: > On Mon, Oct 5, 2015 at 8:34 PM, Gregory Collins [...] >> Strongly -1 from me also. My experience over the last couple of years is >> that every GHC release breaks my libraries in annoying ways that require >> CPP to fix: >> >> ~/personal/src/snap ? find . -name '*.hs' | xargs egrep >> '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l >> 64 [...] > On the libraries I maintain and have a copy of on my computer right now: 329 Although this was already pointed out to you in a response to a Tweet of yours, I'd like to expand on this here to clarify: You say that you stick to the 3-major-ghc-release support-window convention for your libraries. This is good, because then you don't need any CPP at all! Here's why: So when GHC 8.2 is released, your support-window requires you to support GHC 7.10 and GHC 8.0 in addition to GHC 8.2. At this point you'll be happy that you can start dropping those #ifdefs you added for GHC 7.10 in your code in order to adapt to FTP & AMP. And when you do *that*, you can also drop all your `return = pure` methods overrides. (Because we prepared for MRP already in GHC 7.10 by introducing the default implementation for `return`!) This way, you don't need to introduce any CPP whatsoever due to MRP! Finally, since we're not gonna remove `return` in GHC 8.2 anyway, as GHC 8.2 was just the *earliest theoretical* possible GHC in which this *could* have happened. Realistically, this would happen at a much later point, say GHC 8.6 or even later! Therefore, the scheme above would actually work for 5-year time-windows! And there's even an idea on the table to have a lawful `return = pure` method override be tolerated by GHC even when `return` has already moved out of `Monad`! PS: I'm a bit disappointed you seem to dismiss this proposal right away categorically without giving us a chance to address your concerns. The proposal is not a rigid all-or-nothing thing that can't be tweaked and revised. That's why we're having these proposal-discussions in the first place (rather than doing blind +1/-1 polls), so we can hear everyone out and try to maximise the agreement (even if we will never reach 100% consensus on any proposal). So please, keep on discussing! From Lennart.Augustsson at sc.com Tue Oct 6 11:57:23 2015 From: Lennart.Augustsson at sc.com (Augustsson, Lennart) Date: Tue, 6 Oct 2015 11:57:23 +0000 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5613B14F.9070107@nottingham.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5613B14F.9070107@nottingham.ac.uk> Message-ID: <22B950C955F8AB4196E72698FBD00002D0290B59@UKWPISXMB01D.zone1.scb.net> To question 1 my answer is NO! I think voting to decide these kind of issues a terrible idea; we might as well throw dice. -----Original Message----- From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Henrik Nilsson Sent: 06 October 2015 12:33 To: haskell-prime at haskell.org List; Haskell Libraries; haskell cafe Subject: Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` Dear all, Executive Summary: Please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee While we can discuss the extent of additional breakage MRP would cause, the fact remains it is a further breaking change. A survey of breakage to books as Herbert did is certainly valuable (thanks!), but much breakage will (effectively) remain unquantifiable. It is also clear from the discussions over the last couple of weeks, on the Haskell libraries list as well as various other forums and social media, that MRP is highly contentions. This begs two questions: 1. Is the Haskell Libraries list and informal voting process really an appropriate, or even acceptable, way to adopt such far-reaching changes to what effectively amounts to Haskell itself? 2. Why the hurry to push MRP through? As to question 1, to Graham Hutton's and my knowledge, the libraries list and its voting process was originally set up for 3rd-party libraries in fptools. It seems to have experienced some form of "mission creep" since. Maybe that is understandable given that there was no obvious alternative as HaskellPrime has been defunct for a fair few years. But, as has been pointed out in a number of postings, a lot of people with very valuable perspectives are also very busy, and thus likely to miss a short discussion period (as has happened in the past in relation to the Burning the Bridges proposal) and also have very little time for engaging in long and complicated e-mail discussions that, from their perspective, happen at a completely random point in time and for which they thus have not had a chance to set aside time even if they wanted to participate. Just as one data point, AMP etc. mostly passed Graham and me by simply because a) we were too busy to notice and b) we simply didn't think there was a mandate for such massive overhauls outside of a process like HaskellPrime. And we are demonstrably not alone. This brings us to question 2. Now that HaskellPrime is being resurrected, why the hurry to push MRP through? Surely HaskellPrime is the forum where breaking changes like MRP should be discussed, allowing as much time as is necessary and allowing for an as wide range of perspectives as possible to properly be taken into account? The need to "field test" MRP prior to discussing it in HaskellPrime has been mentioned. Graham and I are very sceptical. In the past, at least in the past leading up to Haskell 2010 or so, the community at large was not roped in as involuntary field testers. If MRP is pushed through now, with a resurrection of HaskellPrime being imminent, Graham and I strongly believe that risks coming across to a very large part of the Haskell community as preempting proper process by facing the new HaskellPrime committee with (yet another) fait accompli. Therefore, please let us defer further discussion and ultimate decision on MRP to the resurrected HaskellPrime committee, which is where it properly belongs. Otherwise, the Haskell community itself might be one of the things that MRP breaks. Best regards, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn at cs.nott.ac.uk 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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same. Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products. From jmaessen at alum.mit.edu Tue Oct 6 12:25:34 2015 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Tue, 6 Oct 2015 08:25:34 -0400 Subject: Reducing the need for CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: <87k2r0z8r6.fsf@smart-cactus.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87k2r0z8r6.fsf@smart-cactus.org> Message-ID: On Tue, Oct 6, 2015 at 4:44 AM, Ben Gamari wrote: > Sven Panne writes: > > > 2015-10-05 17:09 GMT+02:00 Gershom B : > > > >> On October 5, 2015 at 10:59:35 AM, Bryan O'Sullivan (bos at serpentine.com > ) > >> wrote: > >> [...] As for libraries, it has been pointed out, I believe, that without > >> CPP one can write instances compatible with AMP, and also with AMP + > MRP. > >> One can also write code, sans CPP, compatible with pre- and post- AMP. > [...] > >> > > > > Nope, at least not if you care about -Wall: If you take e.g. (<$>) which > is > > now part of the Prelude, you can't simply import some compatibility > module, > > because GHC might tell you (rightfully) that that import is redundant, > > because (<$>) is already visible through the Prelude. So you'll have to > use > > CPP to avoid that import on base >= 4.8, be it from it Data.Functor, > > Control.Applicative or some compat-* module. And you'll have to use CPP > in > > each and every module using <$> then, unless I miss something obvious. > > AFAICT all transitioning guides ignore -Wall and friends... > > > This is a fair point that comes up fairly often. The fact that CPP is > required to silence redundant import warnings is quite unfortunate. > Others languages have better stories in this area. One example is Rust, > which has a quite flexible `#[allow(...)]` pragma which can be used to > acknowledge and silence a wide variety of warnings and lints [1]. > > I can think of a few ways (some better than others) how we might > introduce a similar idea for import redundancy checks in Haskell, > > 1. Attach a `{-# ALLOW redundant_import #-}` pragma to a definition, > > -- in Control.Applicative > {-# ALLOW redundant_import (<$>) #-} > (<$>) :: (a -> b) -> f a -> f b > (<$>) = fmap > > asking the compiler to pretend that any import of the symbol did not > exist when looking for redundant imports. This would allow library > authors to appropriately mark definitions when they are moved, > saving downstream users from having to make any change whatsoever. > > 2. Or alternatively we could make this a idea a bit more precise, > > -- in Control.Applicative > {-# ALLOW redundant_import Prelude.(<$>) #-} > (<$>) :: (a -> b) -> f a -> f b > (<$>) = fmap > > Which would ignore imports of `Control.Applicative.(<$>)` only if > `Prelude.(<$>)` were also in scope. > One obvious solution I haven't seen mentioned is the ability to add nonexistent identifier to a hiding clause (these identifiers might presumably exist in some other version of the import): import Prelude hiding ((<$>)) I can see the argument for marking such imports with a pragma, though it gets a bit ugly. -Jan-Willem Maessen -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Tue Oct 6 13:00:41 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 06 Oct 2015 15:00:41 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: (Erik Hesselink's message of "Tue, 6 Oct 2015 14:06:11 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5613B14F.9070107@nottingham.ac.uk> Message-ID: <87si5o6tja.fsf@gnu.org> On 2015-10-06 at 14:06:11 +0200, Erik Hesselink wrote: > I was always under the impression that +1/-1 was just a quick > indicator of opinion, not a vote, and that it was the core libraries > committee that would make the final call if enough consensus was > reached to enact the change. I'd like to point out, that the core libraries committee ought to continue to do so (as hinted at in [1]) in its function as a Haskell Prime sub-Committee (c.f. sub-teams in the Rust community[2]). While there will be surely overlap of interests, contributions, cross-reviewing and discussion, the principal task and responsibility of the new sought members is to concentrate on the language part of the Haskell Report where quite a bit of work is awaiting them. Cheers, hvr [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html [2]: https://www.rust-lang.org/team.html From spam at scientician.net Tue Oct 6 15:53:18 2015 From: spam at scientician.net (Bardur Arantsson) Date: Tue, 6 Oct 2015 17:53:18 +0200 Subject: MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> Message-ID: On 10/06/2015 10:12 AM, Johan Tibell wrote: > (Resending with smaller recipient list to avoid getting stuck in the > moderator queue.) > > On Tue, Oct 6, 2015 at 9:10 AM, Herbert Valerio Riedel wrote: > >> PS: I'm a bit disappointed you seem to dismiss this proposal right away >> categorically without giving us a chance to address your >> concerns. The proposal is not a rigid all-or-nothing thing that >> can't be tweaked and revised. That's why we're having these >> proposal-discussions in the first place (rather than doing blind >> +1/-1 polls), so we can hear everyone out and try to maximise the >> agreement (even if we will never reach 100% consensus on any >> proposal). >> >> So please, keep on discussing! >> > > The problem by discussions is that they are done between two groups with > quite a difference in experience. On one hand you have people like Bryan, > who have considerable contributions to the Haskell ecosystem and much > experience in large scale software development (e.g. from Facebook). On the > other hand you have people who don't. That's okay. We've all been at the > latter group at some point of our career. > Given that Facebook's motto is "move fast and break things", I'm not sure what to make of this appeal to authority. Ignoring the condescension... > What's frustrating is that people don't take a step bad and realize that > they might be in the latter group and should perhaps listen to those in the > former. Have you considered that people might actually have done that and just come to a different conclusion from yours? Have you also considered that people *you've* put in the latter group might actually be in the former in terms of general experience on large language ecosystems/projects/etc.? (Certainly contributing to the Haskell ecosystem does signify a certain level of understanding/insight and shouldn't be *discounted*, but nor should it be used to just outright discount the opinions of others without good reason.) > This doesn't happen, instead we get lots of "C++ and Java so bad > and we don't want to be like them." Haskell is not at risk of becoming C++ > or Java (which are a large improvement compared to the languages came > before them). We're at risk of missing our window of opportunity. I think > that would be a shame, as I think Haskell is a step forward compared to > those languages and I would like to see more software that used be written > in Haskell. If Haskell is not appealing enough to overcome these obstacles, then it's not very appealing, period. That is: if *this* is the deciding factor, then perhaps one *shouldn't* be using Haskell. (That would be a perfectly legitimate business decision.) > > We've been through this many times before on the libraries list. I'm not > going to win an argument on this mailing list. Between maintaining > libraries you all use and managing a largish team at Google, I don't have > much time for a discussion which approaches a hundred emails and is won by > virtue of having lots of time to write emails. > I'm sure nobody other than you has any drains on their time outside of posting to this list. (And no, if you're going to argue like you did in this post, then you *aren't* going to win any arguments. That's pretty much a self-fulfilling prophesy.) Regards, From spam at scientician.net Tue Oct 6 16:16:52 2015 From: spam at scientician.net (Bardur Arantsson) Date: Tue, 6 Oct 2015 18:16:52 +0200 Subject: Reducing the need for CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87k2r0z8r6.fsf@smart-cactus.org> Message-ID: On 10/06/2015 11:11 AM, Johan Tibell wrote: > It might be enough to just add a NOWARN pragma that acts on > a single line/expression. I've seen it in both C++ and Python linters and > it works reasonably well and it's quite general. +1. Simple is good and can hopefully also be backported to older GHC releases. (Provided someone's willing to do said releases, obviously.) From hvr at gnu.org Tue Oct 6 16:47:08 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 06 Oct 2015 18:47:08 +0200 Subject: MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: (Johan Tibell's message of "Tue, 6 Oct 2015 10:10:01 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> Message-ID: <87612k6j1v.fsf@gnu.org> On 2015-10-06 at 10:10:01 +0200, Johan Tibell wrote: [...] >> You say that you stick to the 3-major-ghc-release support-window >> convention for your libraries. This is good, because then you don't need >> any CPP at all! Here's why: >> >> [...] >> > > So what do I have to write today to have my Monad instances be: > > * Warning free - Warnings are useful. Turning them off or having spurious > warnings both contribute to bugs. Depends on the warnings. Some warnings are more of an advisory kind (hlint-ish). I wouldn't consider redundant imports a source of bugs. Leaving off a top-level signature shouldn't be a source of correctness bugs either. Also, warnings about upcoming changes (i.e. deprecation warnings) also are not necessarily a bug, but rather a way to raise awareness of API changes. At the other end of the spectrum are more serious warnings I'd almost consider errors, such as failing to define a non-defaulting method or violating a MINIMAL pragma specification, as that can lead to bottoms either in the form of runtime errors or even worse, hanging computations (in case of cyclic definitions). IMO, GHC should classify its warnings into severities/categories or introduce some compromise between -Wall and not-Wall. > * Use imports that either are qualified or have explicit import lists - > Unqualified imports makes code more likely to break when dependencies add > exports. > * Don't use CPP. That being said, as how to write your Monad instances today with GHC 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This *does* work (admittedly for an easy example, but this can be generalised): --8<---------------cut here---------------start------------->8--- module MyMaybe where import Control.Applicative (Applicative(..)) import Prelude (Functor(..), Monad(..), (.)) -- or alternatively: `import qualified Prelude as P` data Maybe' a = Nothing' | Just' a instance Functor Maybe' where fmap f (Just' v) = Just' (f v) fmap _ Nothing' = Nothing' instance Applicative Maybe' where pure = Just' f1 <*> f2 = f1 >>= \v1 -> f2 >>= (pure . v1) instance Monad Maybe' where Nothing' >>= _ = Nothing' Just' x >>= f = f x return = pure -- "deprecated" since GHC 7.10 --8<---------------cut here---------------end--------------->8--- This example above compiles -Wall-clean and satisfies all your 3 stated requirements afaics. I do admit this probably not what you had in mind. But to be consistent, if you want to avoid unqualified imports at all costs in order to have full control of what gets imported into your namespace, you shouldn't tolerate an implicit unqualified wildcard `Prelude` import either. As `Prelude` can, even if seldom, gain new exports as well (or even loose them -- `interact` *could* be a candidate for removal at some point). > Neither AMP or MRP includes a recipe for this in their proposal. That's because -Wall-hygiene (w/o opting out of harmless) warnings across multiple GHC versions is not considered a show-stopper. In the specific case of MRP, I can offer you a Wall-perfect transition scheme by either using `ghc-options: -fno-mrp-warnings` in your cabal-file, or if that doesn't satisfy you, we can delay phase1 (i.e. redundant return-def warnings) to GHC 8.2: Now you can continue to write `return = pure` w/o GHC warning bothering you until GHC 8.2, at which point the 3-year-window will reach to GHC 7.10. Then starting with GHC 8.2 you can drop the `return` definition, and keep your More generally though, we need more language-features and/or modifications to the way GHC triggers warnings to make such refactorings/changes to the libraries -Wall-perfect as well. Beyond what Ben already suggested in another post, there was also the more general suggestion to implicitly suppress warnings when you explicitly name an import. E.g. import Control.Applicative (Applicative(..)) would suppress the redundant-import warning for Applicative via Prelude, because we specifically requested Applicative, so we don't mind that Prelude re-exports the same symbol. > AMP got one post-facto on the Wiki. It turns out that the workaround > there didn't work (we tried it in Cabal and it conflicted with one of > the above requirements.) Yes, that unqualified `import Prelude`-last trick mentioned on the Wiki breaks down for more complex imports with (redundant) explicit import lists. However, the Maybe-example above works at the cost of a wordy Prelude-import, but it's more robust, as you pin down exactly which symbol you expect to get from each module. > The problem by discussions is that they are done between two groups with > quite a difference in experience. On one hand you have people like Bryan, > who have considerable contributions to the Haskell ecosystem and much > experience in large scale software development (e.g. from Facebook). On the > other hand you have people who don't. That's okay. We've all been at the > latter group at some point of our career. [...] At the risk of stating the obvious: I don't think it matters from which group a given argument comes from as its validity doesn't depend on the messenger. Neither does it matter whether an argument is repeated several times or stated only once. Also, every argument deserves to be considered regardless of its origin or frequency. -- hvr From hvr at gnu.org Tue Oct 6 17:26:06 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 06 Oct 2015 19:26:06 +0200 Subject: MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87612k6j1v.fsf@gnu.org> (Herbert Valerio Riedel's message of "Tue, 06 Oct 2015 18:47:08 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: <87oagb6h8x.fsf@gnu.org> I hit "send" too early, so here's the incomplete section completed: On 2015-10-06 at 18:47:08 +0200, Herbert Valerio Riedel wrote: [...] > In the specific case of MRP, I can offer you a Wall-perfect transition > scheme by either using `ghc-options: -fno-mrp-warnings` in your > cabal-file, or if that doesn't satisfy you, we can delay phase1 > (i.e. redundant return-def warnings) to GHC 8.2: > > Now you can continue to write `return = pure` w/o GHC warning bothering > you until GHC 8.2, at which point the 3-year-window will reach to GHC > 7.10. > > Then starting with GHC 8.2 you can drop the `return` definition, and ...keep supporting a 3-year-window back till GHC 7.10 (which incorporates AMP and doesn't need `return` explicitly defined anymore) without CPP. And since you don't define `return` anymore, you don't get hit by the MRP warning either, which would start with GHC 8.2. GHC can keep providing as long as we want it to, and consider `return` being an extra method of `Monad` simply a GHC-ism. Future Haskell books and learning materials will hopefully be based on the next Haskell Report incorporating the AMP and stop referring to the historical `return` accident (which I consider badly named anyway from a pedagogically perspective). Code written unaware of `return` being a method of Monad will work anyway just fine. Do you see any problems with this scheme? From svenpanne at gmail.com Tue Oct 6 17:41:51 2015 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 6 Oct 2015 19:41:51 +0200 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87612k6j1v.fsf@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: 2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel : > [...] That being said, as how to write your Monad instances today with GHC > 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This > *does* work (admittedly for an easy example, but this can be > generalised): > > > --8<---------------cut here---------------start------------->8--- > module MyMaybe where > > import Control.Applicative (Applicative(..)) > import Prelude (Functor(..), Monad(..), (.)) > -- or alternatively: `import qualified Prelude as P` > [...] > --8<---------------cut here---------------end--------------->8--- > > This example above compiles -Wall-clean and satisfies all your 3 stated > requirements afaics. I do admit this probably not what you had in mind. > OK, so the trick is that you're effectively hiding Applicative from the Prelude (which might be a no-op). This "works" somehow, but is not satisfactory IMHO for several reasons: * If you explicitly import all entities from Prelude, your import list will typically get *very* long and unreadable. Furthermore, if that's the suggested technique, what's the point of having a Prelude at all? * Some people see qualified imports as the holy grail, but having to prefix tons of things with "P." is IMHO very ugly. Things are even worse for operators: The whole notion of operators in itself is totally useless and superfluous *except* for a single reason: Readability. And exactly that gets destroyed when you have to qualify them, so I would (sadly) prefer some #ifdef hell, if that gives me readable code elsewhere. * With the current trend of moving things to the Prelude, I can envision a not-so-distant future where the whole Control.Applicative module will be deprecated. As it is now, it's mostly superfluous and/or contains only stuff which might better live somewhere else. > [...] That's because -Wall-hygiene (w/o opting out of harmless) warnings > across multiple GHC versions is not considered a show-stopper. > That's your personal POV, I'm more leaning towards "-Wall -Werror". I've seen too many projects where neglecting warning over an extended period of time made fixing them basically impossible at the end. Anyway, I think that a sane ecosystem should allow *both* POVs, the sloppy one and the strict one. > [...] Beyond what Ben already suggested in another post, there was also the > more general suggestion to implicitly suppress warnings when you > explicitly name an import. E.g. > > import Control.Applicative (Applicative(..)) > > would suppress the redundant-import warning for Applicative via Prelude, > because we specifically requested Applicative, so we don't mind that > Prelude re-exports the same symbol. [...] > Uh, oh... That would be bad, because one normally wants to see redundant imports. Without the compiler telling me, how should I find out which are redundant? Manually trying to remove them step by step? :-/ Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolm.wallace at me.com Tue Oct 6 19:02:12 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Tue, 06 Oct 2015 20:02:12 +0100 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87612k6j1v.fsf@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote: > >> The problem by discussions is that they are done between two groups with >> quite a difference in experience. On one hand you have people like Bryan, >> who have considerable contributions to the Haskell ecosystem and much >> experience in large scale software development (e.g. from Facebook). On the >> other hand you have people who don't. That's okay. We've all been at the >> latter group at some point of our career. > [...] > > At the risk of stating the obvious: I don't think it matters from which > group a given argument comes from as its validity doesn't depend on the > messenger. In that case, I think you are misunderstanding the relevance of Johan's argument here. Let me try to phrase it differently. Some people who can reasonably claim to have experience with million-line plus codebases are warning that this change is too disruptive, and makes maintenance harder than it ought to be. On the other hand, of the people who say the change is not really disruptive, none of them have (yet?) made claims to have experience of the maintenance of extremely large-scale codebases. The authority of the speaker does matter in technical arguments of this nature: people without the relevant experience are simply unqualified to make guesses about the impact. Regards, Malcolm From hvr at gnu.org Tue Oct 6 17:03:44 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 06 Oct 2015 19:03:44 +0200 Subject: MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87612k6j1v.fsf@gnu.org> (Herbert Valerio Riedel's message of "Tue, 06 Oct 2015 18:47:08 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: <871td86ia7.fsf@gnu.org> I hit "send" too early, so here's the incomplete section completed: On 2015-10-06 at 18:47:08 +0200, Herbert Valerio Riedel wrote: [...] > In the specific case of MRP, I can offer you a Wall-perfect transition > scheme by either using `ghc-options: -fno-mrp-warnings` in your > cabal-file, or if that doesn't satisfy you, we can delay phase1 > (i.e. redundant return-def warnings) to GHC 8.2: > > Now you can continue to write `return = pure` w/o GHC warning bothering > you until GHC 8.2, at which point the 3-year-window will reach to GHC > 7.10. > > Then starting with GHC 8.2 you can drop the `return` definition, and ...keep supporting a 3-year-window back till GHC 7.10 (which incorporates AMP and doesn't need `return` explicitly defined anymore) without CPP. And since you don't define `return` anymore, you don't get hit by the MRP warning either, which would start with GHC 8.2. GHC can keep providing as long as we want it to, and consider `return` being an extra method of `Monad` simply a GHC-ism. Future Haskell books and learning materials will hopefully be based on the next Haskell Report incorporating the AMP and stop referring to the historical `return` accident (which I consider badly named anyway from a pedagogically perspective). Code written unaware of `return` being a method of Monad will work anyway just fine. Do you see any problems with this scheme? From hvr at gnu.org Tue Oct 6 20:16:22 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Tue, 06 Oct 2015 22:16:22 +0200 Subject: MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: (Mikhail Glushenkov's message of "Tue, 6 Oct 2015 21:32:19 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> <871td86ia7.fsf@gnu.org> Message-ID: <87d1wrycq1.fsf@gnu.org> Hi, On 2015-10-06 at 21:32:19 +0200, Mikhail Glushenkov wrote: > On 6 October 2015 at 19:03, Herbert Valerio Riedel wrote: >>> In the specific case of MRP, I can offer you a Wall-perfect transition >>> scheme by either using `ghc-options: -fno-mrp-warnings` in your >>> cabal-file, [...] > > Apropos, is there a similar option for AMP warnings? I would rather > use that than CPP. Sure, added in GHC 7.8: | In GHC 7.10, Applicative will become a superclass of Monad, | potentially breaking a lot of user code. To ease this transition, GHC | now generates warnings when definitions conflict with the | Applicative-Monad Proposal (AMP). | | A warning is emitted if a type is an instance of Monad but not of | Applicative, MonadPlus but not Alternative, and when a local function | named join, <*> or pure is defined. | | The warnings are enabled by default, and can be controlled using the | new flag -f[no-]warn-amp. However, if you use that now with GHC 7.10 you get a warning: | $ ghc-7.10.2 -fno-warn-amp | | on the commandline: Warning: | -fno-warn-amp is deprecated: it has no effect, and will be removed in GHC 7.12 so you you'll need to guard that with something like if impl(ghc == 7.8.*) ghc-options: -fno-warn-amp From jmct at jmct.cc Tue Oct 6 22:56:47 2015 From: jmct at jmct.cc (=?UTF-8?Q?Jos=C3=A9_Manuel_Calder=C3=B3n_Trilla?=) Date: Tue, 6 Oct 2015 15:56:47 -0700 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> Message-ID: Hello all, I agree with Henrik, I'm very keen on giving the new Haskell committee a shot. While some may not think that Haskell2010 was a success, I think it would be difficult to argue that Haskell98 was anything but a resounding success (even if you don't think the language was what it could have been!). Haskell98 stabilized the constant changes of the proceeding 7 years. The stability brought with it books and courses, and the agreed-upon base of the language allowed _research_ to flourish as well. Having an agreed base allowed the multiple implementations to experiment with different methods of implementing what the standard laid out. Many of us here learned from those texts or those courses. It's easy online to say that materials being out of date isn't a big deal, but it can turn people off the language when the code they paste into ghci doesn't work. We use Haskell for the compilers course at York; Haskell is the means, not the end, so having to update the materials frequently is a significant cost. It can be difficult to defend the choice of using Haskell when so much time is spent on something that 'isn't the point' of the course. Does that mean that we should never change the language? Of course not, but this constant flux within Haskell is very frustrating. Maybe Haskell2010 wasn't what everyone wanted it to be, but that does not mean the _idea_ of a committee is without merit. Having controlled, periodic changes that are grouped together and thought through as a coherent whole is a very useful thing. One of the insights of the original committee was that there would always be one chair at any point in time. The chair of the committee had final say on any issue. This helped keep the revisions coherent and ensured that Haskell made sense as a whole. Lastly, I'd like to quote Prof. Runciman from almost exactly 22 years ago when the issue of incompatible changes came up. His thoughts were similar to Johan's: On 1993-10-19 at 14:12:30 +0100, Colin Runciman wrote: > As a practical suggestion, if any changes for version 1.3 could make > some revision of a 1.2 programs necessary, let's have a precise > stand-alone specification of these revisions and how to make them. > It had better be short and simple. Many would prefer it to be empty. > Perhaps it should be implemented in Haskell compilers? Overall I don't see the rush for these changes, let's try putting our faith in a new Haskell committee, whomever it is comprised of. Best wishes, Jos? Manuel P.S. A year ago Prof. Hinze sent me some Miranda code of his from 1995 as I was studying his thesis. I was able to run the code without issue, allowing me to be more productive in my research ;-) On Tue, Oct 6, 2015 at 2:29 PM, Gregory Collins wrote: > > On Tue, Oct 6, 2015 at 1:39 PM, Tom Ellis < > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > >> In fact I think all of these apart from the FFI one could be solved with a >> -compat package, could they not? >> > > Who cares? In practice, the programs break and I have to fix them. Most of > the time, CPP is the lowest-friction solution -- if I rely on a -compat > package, first I have to know it exists and that I should use it to fix my > compile error, and then I've added an additional non-platform dependency > that I'm going to have to go back and clean up in 18 months. Usually, to be > honest, *actually* the procedure is that the new RC comes out and I get > github pull requests from hvr@ :-) :-) > > In response to the other person who asked "why do you want to support so > many GHC versions anyways?" --- because I don't hate my users, and don't > want to force them to run on the upgrade treadmill if they don't have to? > Our policy is to support the last 4 major GHC versions (or 2 years, > whichever is shorter). And if we support a version of GHC, I want our > libraries to compile on it without warnings, I don't think that should > mystify anyone. > > -- > Gregory Collins > > _______________________________________________ > 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 gershomb at gmail.com Wed Oct 7 01:18:03 2015 From: gershomb at gmail.com (Gershom B) Date: Tue, 6 Oct 2015 21:18:03 -0400 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87612k6j1v.fsf@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: Dear all, I think this discussion has gotten quite heated for reasons not related to the concrete MRP proposal, which, to be honest, I considered quite modest in terms of both scope and impact. Instead, I think it is a proxy for lots of remaining frustration and anxiety over the poor handling over the Foldable Traversable Proposal. I would like to remind everyone that due to the broad discussions and concerns over the proposal, a very rare, careful poll of Haskell users was taken, announced broadly in many channels. [1] The poll, overwhelmingly, revealed a mandate for the FTP. The breakdown of that mandate was 87% in favor among hobbyists and 79% in favor among non-hobbyists (who constituted a majority of those polled).? I. Generalities That said, even the _best_ poll was not a substitute for a better earlier discussion. The handling of the AMP and FTP, which I think was heroic in terms of minimizing breakage while accomplishing long-desired change also still could have been better. As a whole, the work accomplished the mandate of allowing code to be written backwards-compatible without requiring CPP. However, it did not also seek to prevent warnings. This in itself was an enormous step forward from changes in the past which have _not_ even managed to prevent the need for CPP. At the time, I think it was not recognized how much desire there would be for things that were _both_ CPP free and _also_ warning-free for 3 releases. I think one of the great elements of progress in the current discussion is that there is now a proposal on the table which recognizes this, and seeks to accomplish this change in accordance with this desire. It is not the world?s most important change, but the recognition that change should seek to be both CPP _and_ warning free is a good recognition, and I?m sure it will be taken into account in future proposals as well. I don?t think it is useful to continue to have abstract discussions on the conflict between desire for incremental improvement versus the need to minimize pain on maintainers. We might as well continue to argue about the need for purely functional programming versus the need to print ?hello world? to the console. Rather, we should put our collective minds together as collaborators and colleagues to accomplish _both_, and to come up with solutions that should work for everyone. To the extent this discussion has been about that, I think it has been useful and positive. However, to the extent this discussion insists, on either side, on the shallow idea that we must treat ?improvement? versus ?stability? as irreconcilable factions in necessary conflict, then I fear it will be a missed opportunity. II. Particulars With that in mind, I think the _concrete_ voices of concern have been the most useful. Gregory Collins? list of issues requiring CPP should be very sobering. Of note, I think they point to areas where the core libraries committee has not paid _enough_ attention (or perhaps has not been sufficiently empowered: recall that not all core libraries fall under its maintenance [2]). Things like the newtype FFI issue, the changes to prim functions, the splitup of old-time and the changes to exception code were _not_ vetted as closely as the AMP and FTP were, or as the MRP is currently being. I don?t know all the reasons for this, but I suspect they just somewhat slipped under the radar. In any case, if all those changes were as carefully engineered as the MRP proposal has been, then imho things would have been much smoother. So, while this discussion may be frustrating, it nonetheless in some ways provides a model of how people have sought to do better and be more proactive with careful discussion of changes. This is much appreciated. Personally, since the big switch to extensible exceptions back prior in 6.10, and since the split-base nonsense prior to that, very few changes to the core libraries have really caused too much disruption in my code. Since then, the old-time cleanup was the worst, and the big sin there was that time-locale-compat was only written some time after the fact by a helpful third-party contributor and not engineered from the start. (I will note that the time library is one of the core libraries that is _not_ maintained by the core libraries committee).? Outside of that, the most disruptive changes to my code that I can recall have been from changes to the aeson library over the years ? particularly but not only regarding its handling of doubles. I don?t begrudge these changes ? they iteratively arrived at a _much_ better library than had they not been made. [3] After than, I made a few changes regarding Happstack and Snap API changes if I recall. Additionally, the addition of ?die? to System.Exit caused a few name clashes. My point is simply that there are many packages outside of base that also move, and ?real? users with ?real? code will these days often have quite a chain of dependencies, and will encounter movement and change from across many of them. So if we say ?base never changes? that does not mean ?packages will never break? ? it just means that base will not have the same opportunity to improve that other packages do, which will eventually lead to frustration, just as it did in the past and in the leadup to the BBP. III. Discussions Further, since there has been much discussion of a window of opportunity, I would like to offer a counterpoint to the (sound) advice that we take into consideration voices with long experience in Haskell. The window of opportunity is, by definition, regarding takeup of Haskell by new users. And so if newer users favor certain changes, then it is good evidence that those changes will help with uptake among other new users. So, if they are good changes on their own, then the fact that they are appealing to newer users should be seen as a point in their favor, rather than a reason to dismiss those opinions. But if we are in a situation where we see generations of adopters pitted against one another, then we already have deeper problems that need to be sorted out. Regarding where and how to have these discussions ? the decision was made some time ago (I believe at the start of the initial Haskell Prime process if not sooner, so circa 2009?) that the prime committee would focus on language extensions and not library changes, and that those changes would be delegated to the libraries@ list. The lack of structure to the libraries@ list is what prompted the creation of the libraries committee, whose ultimately responsibility it is to decide on and shepherd through these changes, in consultation with others and ideally driven by broad consensus. Prior to this structure, things broke even more, imho, and simultaneously the things that were widely desired were still not implemented. So I thank the libraries committee for their good work so far. So, it may be that the process of community discussion on core libraries changes is not best suited for the libraries@ list. But if not there, Where? I worry that the proliferation of lists will not improve things here. Those involved with Haskell have multiplied (this is good). The voices to take into account have multiplied (this is good). Necessarily, this means that there will just be _more_ stuff, and making sure that everyone can filter to just that part they want to is difficult. Here, perhaps, occasional libraries-related summary addenda to the ghc newsletter could be appropriate? Or is there another venue we should look towards???Chair?s reports? to the Haskell Weekly News maybe? IV. Summing up We should bear in mind after all that this is just about cleaning up a redundant typeclass method (albeit one in a very prominent place) and hardly the hill anyone would want to die on [4]. Nonetheless,?I think it would be?a good sign of progress and collaboration if we can find a way to implement a modest change like this in a way that everyone finds acceptable vis a vis a sufficiently slow pace, the lack of a need for CPP and the lack of any induced warnings. On the other hand, other opportunities will doubtless present themselves in the future. Best, Gershom [1] https://mail.haskell.org/pipermail/libraries/2015-February/025009.html [2]?https://wiki.haskell.org/Library_submissions#The_Core_Libraries [3] and in any case I am sure Bryan would be the last to want us to treat him as some sort of ?guru? on these matters.? [4] for those in search of better hills to die on, this is a list of some good ones: http://www.theawl.com/2015/07/hills-to-die-on-ranked? P.S. In case there is any question, this email, as all emails I write that do not state otherwise, is not being written in any particular capacity regarding the various infra-related hats I wear, but is just an expression of my own personal views. From hvr at gnu.org Wed Oct 7 07:35:21 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Wed, 07 Oct 2015 09:35:21 +0200 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: (Sven Panne's message of "Tue, 6 Oct 2015 19:41:51 +0200") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: <87lhbfm8qu.fsf@gnu.org> On 2015-10-06 at 19:41:51 +0200, Sven Panne wrote: > 2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel : > >> [...] That being said, as how to write your Monad instances today with GHC >> 7.10 w/o CPP, while supporting at least GHC 7.4/7.6/7.8/7.10: This >> *does* work (admittedly for an easy example, but this can be >> generalised): >> >> >> --8<---------------cut here---------------start------------->8--- >> module MyMaybe where >> >> import Control.Applicative (Applicative(..)) >> import Prelude (Functor(..), Monad(..), (.)) >> -- or alternatively: `import qualified Prelude as P` >> [...] >> --8<---------------cut here---------------end--------------->8--- >> >> This example above compiles -Wall-clean and satisfies all your 3 stated >> requirements afaics. I do admit this probably not what you had in mind. >> > > OK, so the trick is that you're effectively hiding Applicative from the > Prelude (which might be a no-op). This "works" somehow, but is not > satisfactory IMHO for several reasons: [...] Btw, I've also seen the trick below, in which you use the aliased `A.` prefix just once so GHC considers the import non-redundant, and don't have to suffer from prefixed operators in the style of `A.<*>`. Is this any better? --8<---------------cut here---------------start------------->8--- import Control.Applicative as A (Applicative(..)) data Maybe' a = Nothing' | Just' a instance Functor Maybe' where fmap f (Just' v) = Just' (f v) fmap _ Nothing' = Nothing' instance A.Applicative Maybe' where pure = Just' f1 <*> f2 = f1 >>= \v1 -> f2 >>= (pure . v1) instance Monad Maybe' where Nothing' >>= _ = Nothing' Just' x >>= f = f x return = pure -- "deprecated" since GHC 7.10 --8<---------------cut here---------------end--------------->8--- -- hvr From svenpanne at gmail.com Wed Oct 7 08:07:38 2015 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 7 Oct 2015 10:07:38 +0200 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87lhbfm8qu.fsf@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> <87lhbfm8qu.fsf@gnu.org> Message-ID: 2015-10-07 9:35 GMT+02:00 Herbert Valerio Riedel : > Btw, I've also seen the trick below, in which you use the aliased `A.` > prefix just once so GHC considers the import non-redundant, and don't > have to suffer from prefixed operators in the style of `A.<*>`. > > Is this any better? [...] > While not perfect, it's much better than having to fiddle around with Prelude imports. Although there's the slight danger that somebody else (or the author 1 year later) looks at the code and has a WTF-moment... ;-) To be honest, while it's somehow obvious how it works when you read it, I've never seen that trick. Perhaps stuff like this belongs into some general "Porting Guide", along with its alternatives. It's general enough that it should not be buried in some AMP/FTP/return/... transitioning guide. Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Oct 7 15:36:41 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 7 Oct 2015 15:36:41 +0000 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> Message-ID: <3d672fd5db1546b189f16d2a890a953d@DB4PR30MB030.064d.mgd.msft.net> I think there are several different conversations going on at once in this thread. I think it?s worth keeping them separate. ? Haskell Prime. The intention there is to take a set of language features that are already in wide use in GHC (i.e. have demonstrably proved valuable), work out any dark corners, formalise them, and embody the result in a new Haskell Report. That puts a useful stake in the ground, empowers alternative implementations of Haskell, gives confidence all round. I think it?d be unusual for the Haskell Prime committee to specify a new feature of the language, one that had not been field tested. ? Libraries. AMP, BBP, and Monad(return) are small but fundamental changes to the core libraries. I think there was a consensus (not universal in the case of BBP) that the change was good. Yet AMP and BBP (esp) were controversial. The issues were mostly around how to make the transition; and, given that the transition is expensive, whether the cost/benefit tradeoff justifies the change. The question of moving ?return? out of Monad is in this category. The Core Libraries Committee was formed explicitly to handle this stuff. So my prior assumption was that the CLC would handle the Monad(return) question, not Haskell Prime. Mark?s suggestion of a ?stable? GHC 7.10 and a new GHC 8.0 is a reasonable one. But I for one would find it hard to promise to back-port every bug fix, especially as the two code bases diverge (which they will). Here is another idea. GHC knows very little about Monad. It would take work, but it probably wouldn?t be impossible to make the same GHC work with two different ?base? libraries, each with a different definitions of the Monad class. That would not solve the problem: you still could not use one library that used old Monad with another library that used new Monad. But at least it?d decouple it from which version of GHC you were using. I stress: it would take some work to make this go, and I?d prefer not to do this. Returning to ?return?, my instinct is that when these pervasive breaking library changes come up, we should batch them into larger clumps. The ?treadmill? complaint is real: small change A made me re-release my library; then small change B came along; and so on. Perhaps if we saved them up this would be less of an issue, for two reasons. First, the work happens once rather than many times. Second, the benefits of the change is the sum of the benefits of the little component changes, and so is more attractive to library authors and library clients. That line of thinking would suggest that the Core Libraries Committee might want to maintain a list of well-worked out agreed changes that are being ?saved up? for execution at some later date. Simon From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Mike Meyer Sent: 07 October 2015 00:24 To: Mark Lentczner; Johan Tibell Cc: Haskell Libraries; haskell cafe; haskell-prime at haskell.org List Subject: Re: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP (was: Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) On Tue, Oct 6, 2015 at 4:15 PM Mark Lentczner > wrote: On Thu, Sep 24, 2015 at 2:43 PM, Herbert Valerio Riedel > wrote: TLDR: To complete the AMP, turn `Monad(return)` method into a top-level binding aliasing `Applicative(pure)`. Sure... if we had a language that no one uses and could keep reforming like putty until it is perfect. But we don't. A modest proposal: We can't keep tinkering with a language and it's libraries like this AND have a growing ecosystem that serves an ever widening base, including the range from newcomer to commercial deployment. SO - Why let's do all the language tinkering in GHC 8 there can be as many prereleases of that as needed until it is just right. ...and leave GHC 7 (7.10? roll back to 7.8.4?) for all of us doing essential and dependable libraries, commercial work, projects on Haskell that we don't want to have to go back and #ifdefs to twice a year just to keep running, educators, people writing books. We can keep improving GHC 7 as needed, and focus on bugs, security issues, patches, cross compatibility, etc. I'm just curious how much you think this would help, assuming that your solution would imply not upgrading to 8 until you're ready to. After all, you can already simply not upgrade now, and create (and distribute) fixes for bugs, security issues, cross-compatibility for 7 as you see fit. While that's a popular thing to do in lots of systems (but if we don't it. for gnus sake let's not adopt the inane parity implies stability numbering convention), it leaves two major issues unaddressed. #1, developer time. You need to get the people doing the work now to divide their efforts into the two branches.I don't know what percentage of that work is volunteer time, but I expect the answer is "most of it". If they aren't interested doing that now, what do you expect to change their mind? #2, everything else in the ecosystem. If you need updates to a library that require the branch you're not using, where does that leave you? -------------- next part -------------- An HTML attachment was scrubbed... URL: From J.Hage at uu.nl Wed Oct 7 19:22:59 2015 From: J.Hage at uu.nl (Jurriaan Hage) Date: Wed, 7 Oct 2015 21:22:59 +0200 Subject: Self nomination Message-ID: <4AF9207F-5960-4EEA-914C-D4318820BFF3@uu.nl> Dear all, I?d like to nominate myself for the Haskell Prime committee. I have been programming in Haskell since 2000 or so. Currently I teach a course on Functional Programming that discusses many of the essentials of Haskell to groups of over 240 or up. To be fair: I do not use Haskell a whole lot myself, but that is also because my work does not demand much in terms of any kind of programming, and much of other things. Master and PhD students that I supervise do typically implement their ideas in Haskell. Research-wise I have been working on Haskell too: with Bastiaan Heeren I have looked at type error diagnosis for Haskell, have contributed to the Helium compiler for novice programmers, and are currently lead maintainer of that compiler (available on Hackage). I am also involved in the Utrecht Haskell Compiler (UHC) with Atze Dijkstra, co-supervising master students working on it. I currently supervise a PhD student, Alejandro Serrano Mena, who continues the work I did with Bastiaan: domain specific type error diagnosis for Haskell 2010, with an eye to implementing this in UHC or GHC. My research interest lies in making Haskell the best vehicle for embedded domain-specific languages in the world. Incidently, I gave a talk on this at Curry On! in Prague (https://www.youtube.com/watch?v=bPrM1gONdII). Shortly, I want to extend my focus to optimisation, in a way that is transparent to the programmer. My paper on heap recycling at PEPM 2008 with Stefan Holdermans provides a sample of this. I am also much interested in the tensions that arise from combining Haskell the research-vehicle with Haskell the vehicle for the professional, and Haskell the vehicle for teaching how to program in a single specification. My website is at http://foswiki.cs.uu.nl/foswiki/Hage/WebHome where you can also find a list of publications, many of which involve Haskell one way or another. best, Jurriaan Hage Utrecht University From spam at scientician.net Wed Oct 7 20:54:37 2015 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 7 Oct 2015 22:54:37 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> Message-ID: On 10/07/2015 12:56 AM, Jos? Manuel Calder?n Trilla wrote: > Hello all, > > I agree with Henrik, I'm very keen on giving the new Haskell committee a > shot. > > While some may not think that Haskell2010 was a success, I think it would > be difficult to argue that Haskell98 was anything but a resounding success > (even if you don't think the language was what it could have been!). > Haskell98 stabilized the constant changes of the proceeding 7 years. The > stability brought with it books and courses, and the agreed-upon base of > the language allowed _research_ to flourish as well. Having an agreed base > allowed the multiple implementations to experiment with different methods > of implementing what the standard laid out. > I didn't mean to be too negative about Haskell2010 -- I think Haskell2010 *was* a success, albeit a *limited* one, but I'm doubtful that these things can be designed by committee, especially without prototypes. The C++ community has realized this since C++11 was finalized and are pursuing a much more aggresive evolution of both the language and standard libraries as a consequence -- it has practically become a requirement to have a working prototype in at least one compiler before a language extension/change is even considered. C++ had been completely stagnant since 1998 and there were some disasterous decisions as a result of design-by-committee. "template export", nuff said. That the new Haskell' committee is being spearheaded by the apparently-untiring HVR does inspire some confidence, but as I say... we'll see :). I'm actually an optimist, but I've just been disappointed soooo many times... Regarding the textbook/course argument: Look, I think(!) I understand what you're saying, but any serious developer these days is going to be *used* to adapting to change. *Everything* in practical (full-stack) development these days changes so fast that it doesn't matter whether Monad loses "return" or not. Do you have any idea how fast frontend (JavaScript, mainly) developers have to (and are!) adapting to change? I'm not saying it's necessarily a good thing, but it's happening and people are used to it. There are backwards-incompatible changes in e.g. React almost tri-monthly[1] and yet people adapt even though this is in a *dynamically type-checked* language! (Besides, I didn't expect university to teach me anything practical as in "trade school". I wanted to learn *principles* and *ideas*.) I can also sympathize with *educators* having to adapt their course materials and such, but I think that should be par for the course...? Please consider that the the way practical development really happens[2] has changed and that the argument for stability has shifted somewhat. Regards, B?r?ur [1] A rough guesstimation of the pace. They have a deprecation period of 1 release. I have to say that Facebook are also dogfooding, I think the 0.14 release post says that they have something like 15000(!) React components at this point. [2] I guess I should qualify that with "... in code bases <1 MLOC", but would that might be a bit snarky? :) From spam at scientician.net Wed Oct 7 21:04:54 2015 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 7 Oct 2015 23:04:54 +0200 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> Message-ID: On 10/07/2015 10:54 PM, Bardur Arantsson wrote: > That the new Haskell' committee is being spearheaded by the > apparently-untiring HVR [...] Sorry, I should have continued: ... and hopefully joined by some motivated, skilled and experienced individuals if the self-nominations are anything to go by[1]. I'm a bit unclear on who gets to vote for the nominees, but maybe I missed something. Maybe we're working towards representative democracy here :) Still... I remain skeptical of committees unless they delegate to sub-committees (like "new C++" is doing). Regards, [1] I'm not sure who was on the old Haskell' committe, but I'm absolutely sure the same could have been said of them. From allbery.b at gmail.com Wed Oct 7 23:05:44 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 7 Oct 2015 19:05:44 -0400 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: References: <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <20151005134359.5476430.61182.12631@gsd.uwaterloo.ca> <20151006203900.GT11050@weber> Message-ID: On Wed, Oct 7, 2015 at 4:54 PM, Bardur Arantsson wrote: > Please consider that the the way practical development really happens[2] ...among web developers, who of course are the only real developers? Have you considered that there are developers who are not web developers? The past day has convinced me that the web devs have relegated everyone else to fake-non-programmer status and actively want them out of the community because fake programmers don't benefit you real programmers. I had heard that the financial users generally refused to have anything to do with the Haskell community. Now I know why. I wonder how many of them, if any indeed are left after past breaking changes, are in the process of switching to OCaml. I'm sure you consider that a good thing, because they're obviously just holding back "real programmers". -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Thu Oct 8 12:24:40 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Thu, 8 Oct 2015 08:24:40 -0400 Subject: Self Nomination Message-ID: <56BC6F4E-9565-4007-98FD-EB2F5957690C@cis.upenn.edu> I would like to nominate myself for the Haskell Prime committee. I have been studying Haskell intensively as I'm working toward my PhD at the University of Pennsylvania, though I started programming in Haskell only in 2011. Qualifications: * I have designed and implemented several new features in GHC: - Closed type families - Coercible/roles - Several Template Haskell improvements * I am currently putting the final touches on a large patch to GHC, merging the type and kind language and allowing reasoning about kind equalities. * My dissertation is about dependent types in Haskell/GHC. * I am currently serving as the Template Haskell czar for GHC. * I am an avid user of lots of GHC extensions, particularly those concerning types. Two of my packages -- singletons and units -- make very heavy use of type system features. Relevant opinion: * Despite my pushing the envelope in GHC, my approach toward a language standard is conservative. Specifically, I would advocate against any of GHC's growing dependent-type features to end up in the standard: we simply don't have enough experience with these! My website is at www.cis.upenn.edu/~eir if you wish to learn more about me. Thanks, Richard From ekmett at gmail.com Sat Oct 10 19:13:26 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 10 Oct 2015 15:13:26 -0400 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: On Tue, Oct 6, 2015 at 3:02 PM, Malcolm Wallace wrote: > > On 6 Oct 2015, at 17:47, Herbert Valerio Riedel wrote: > > At the risk of stating the obvious: I don't think it matters from which > > group a given argument comes from as its validity doesn't depend on the > > messenger. > > In that case, I think you are misunderstanding the relevance of Johan's > argument here. Let me try to phrase it differently. Some people who can > reasonably claim to have experience with million-line plus codebases are > warning that this change is too disruptive, and makes maintenance harder > than it ought to be. On the other hand, of the people who say the change > is not really disruptive, none of them have (yet?) made claims to have > experience of the maintenance of extremely large-scale codebases. Very well. Let me offer a view from the "other side of the fence." I personally maintain about 1.3 million lines of Haskell, and over 120 packages on hackage. It took me less than a half a day to get everything running with 7.10, and about two days to build -Wall clean. In that first day I actually had to spend vastly more time fixing things related to changes in Typeable, template-haskell and a tweaked corner case in the typechecker than anything AMP/FTP related. In the end I had to add two type signatures. Most of the patches to go -Wall clean looked like +#if __GLASGOW_HASKELL__ < 710 import Control.Applicative import Data.Monoid +#endif Maybe 10% were more complicated. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Sat Oct 10 19:16:10 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 10 Oct 2015 15:16:10 -0400 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <87lhbfm8qu.fsf@gnu.org> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> <87lhbfm8qu.fsf@gnu.org> Message-ID: On Wed, Oct 7, 2015 at 3:35 AM, Herbert Valerio Riedel wrote: > --8<---------------cut here---------------start------------->8--- > import Control.Applicative as A (Applicative(..)) > > data Maybe' a = Nothing' | Just' a > > instance Functor Maybe' where > fmap f (Just' v) = Just' (f v) > fmap _ Nothing' = Nothing' > > instance A.Applicative Maybe' where > pure = Just' > f1 <*> f2 = f1 >>= \v1 -> f2 >>= (pure . v1) > > instance Monad Maybe' where > Nothing' >>= _ = Nothing' > Just' x >>= f = f x > > return = pure -- "deprecated" since GHC 7.10 > --8<---------------cut here---------------end--------------->8--- > > Alternately, import Control.Applicative import Prelude data Maybe' a = Nothing' | Just' a instance Functor Maybe' where fmap f (Just' v) = Just' (f v) fmap _ Nothing' = Nothing' instance Applicative Maybe' where > -- hvr > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Sat Oct 10 19:25:37 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 10 Oct 2015 15:25:37 -0400 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: The part of the MRP proposal that I actively care about because it fixes a situation that *actually causes harm* is moving (>>) to the top level. Why? Right now (*>) and (>>) have different default definitions. This means that code runs often with different asymptotics depending on which one you pick. Folks often define one but not the other. This means that the performance of mapM_ and traverse_ needlessly differ. It means that we can't simply weaken the type constraint on mapM_ and sequence_ to Applicative, it as a knock-on consequence it means we can't migrate mapM and sequence out of Traversable to top level definitions and thereby simply provide folks with more efficient parallelizable mapping when they reach for the 'obvious tool'. return itself lurking in the class doesn't matter to me all that much as it doesn't break anybody's asymptotics and it already has a sensible definition in terms of pure as a default, so effectively you can write code as if MRP was already in effect today. It is a wart, but one that could be burned off on however long a time table we want if we choose to proceed. -Edward On Wed, Oct 7, 2015 at 5:13 PM, Mark Lentczner wrote: > > On Wed, Oct 7, 2015 at 9:38 AM, Erik Hesselink > wrote: > >> While I don't think it detracts from your argument, it seems you >> misread the original proposal. At no point will it remove `return` >> completely. It would be moved out of the `Monad` class and be made >> into a top-level definition instead, so you would still be able to use >> it. >> > > Then why bother? > If you don't intend to regard code that uses "return" as old, out-dated, > in need of updating, etc.... > If you don't intend to correct people on #haskell to use pure instead of > return... > If you don't tsk tsk all mentions of it in books.... > If you don't intend to actually deprecate it. > Why bother? > > But seriously, why do you think that "you would still be able to use it"? > That is true for only the simplest of code - and untrue for anyone who has > a library that defines a Monad - or anyone who has a library that they want > to keep "up to date". Do you really want to have a library where all your > "how to use this" code has return in the examples? Shouldn't now be pure? > Do I now need -XCPP just for Haddock? and my wiki page? And what gets shown > in Hackage? This is just a nightmare for a huge number of libraries, and > especially many commonly used ones. > > Why bother! > > > _______________________________________________ > 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 ekmett at gmail.com Sat Oct 10 19:33:37 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 10 Oct 2015 15:33:37 -0400 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: On Tue, Oct 6, 2015 at 1:41 PM, Sven Panne wrote: > 2015-10-06 18:47 GMT+02:00 Herbert Valerio Riedel : > >> [...] That's because -Wall-hygiene (w/o opting out of harmless) warnings >> > across multiple GHC versions is not considered a show-stopper. >> > > That's your personal POV, I'm more leaning towards "-Wall -Werror". I've > seen too many projects where neglecting warning over an extended period of > time made fixing them basically impossible at the end. Anyway, I think that > a sane ecosystem should allow *both* POVs, the sloppy one and the strict > one. > Note: You haven't been able to upload a package that has -Werror turned on in the cabal file for a couple of years now -- even if it is only turned on on the test suite, so any -Werror discipline you choose to enforce is purely local. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Sat Oct 10 20:12:11 2015 From: shumovichy at gmail.com (Yuras Shumovich) Date: Sat, 10 Oct 2015 23:12:11 +0300 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: <1444507931.2047.14.camel@gmail.com> On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote: > The part of the MRP proposal that I actively care about because it > fixes a > situation that *actually causes harm* is moving (>>) to the top > level. Sorry if I'm missing something, but moving (>>) is not part of the proposal. At least it is not mentioned on the wiki page: https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn Is the wiki outdated? > return itself lurking in the class doesn't matter to me all that much > as it > doesn't break anybody's asymptotics and it already has a sensible > definition in terms of pure as a default, so effectively you can > write code > as if MRP was already in effect today. It is a wart, but one that > could be > burned off on however long a time table we want if we choose to > proceed. So the cost of not moving `return` to the top level is zero? For me the cost of moving it is pretty small, just an hour or two. Probably recompiling all the dependencies when switching to newer version of GHC will take longer. (Actually I'm still using 7.8 at work.) But the cost is definitely nonzero. The proposal (as written on the wiki page) provides two arguments for the change: There is no reason to include `return` into the next standard. That is true. But we can leave `return` is `GHC` as a compiler specific extension for backward compatibility, can't we? The second argument is `ApplicativeDo`, but I don't see the point. Breaking existing code "in order to benefit existing code" looks a bit strange. Could someone please clarify what is the cost of not moving `return` out of `Monad`? Sorry if it is already answered somewhere else, it is hard to find anything in such the huge email thread. Thanks, Yuras. From ekmett at gmail.com Sat Oct 10 20:39:10 2015 From: ekmett at gmail.com (Edward Kmett) Date: Sat, 10 Oct 2015 16:39:10 -0400 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: <1444507931.2047.14.camel@gmail.com> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> <1444507931.2047.14.camel@gmail.com> Message-ID: On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich wrote: > On Sat, 2015-10-10 at 15:25 -0400, Edward Kmett wrote: > > The part of the MRP proposal that I actively care about because it > > fixes a > > situation that *actually causes harm* is moving (>>) to the top > > level. > > Sorry if I'm missing something, but moving (>>) is not part of the > proposal. At least it is not mentioned on the wiki page: > > https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn > > Is the wiki outdated? > It arose during the original thread discussing the MRP but wasn't included in the 'proposal as written' that was sent out. https://mail.haskell.org/pipermail/libraries/2015-September/026129.html In many ways that proposal would do better 'on its own' than as part of the MRP. > return itself lurking in the class doesn't matter to me all that much > > as it > > doesn't break anybody's asymptotics and it already has a sensible > > definition in terms of pure as a default, so effectively you can > > write code > > as if MRP was already in effect today. It is a wart, but one that > > could be > > burned off on however long a time table we want if we choose to > > proceed. > > So the cost of not moving `return` to the top level is zero? > > For me the cost of moving it is pretty small, just an hour or two. > Probably recompiling all the dependencies when switching to newer > version of GHC will take longer. (Actually I'm still using 7.8 at > work.) But the cost is definitely nonzero. > > The proposal (as written on the wiki page) provides two arguments for > the change: > > There is no reason to include `return` into the next standard. That is > true. Nobody is saying that we should remove return from the language. The proposal was to move it out of the class -- eventually. Potentially on a very very long time line. But we can leave `return` is `GHC` as a compiler specific extension for > backward compatibility, can't we? > This is effectively the status quo. There is a default definition of return in terms of pure today. The longer we wait the more tenable this proposal gets in many ways as fewer and fewer people start trying to support compilers versions below 7.10. Today isn't that day. There are some niggling corner cases around viewing its continued existence as a compiler "extension" though, even just around the behavior when you import the class with Monad(..) you get more or less than you'd expect. Could someone please clarify what is the cost of not moving `return` out of > `Monad`? > The cost of doing nothing is maintaining a completely redundant member inside the class for all time and an ever-so-slightly more expensive dictionaries for Monad, so retaining return in the class does no real harm operationally. While I'm personally somewhat in favor of its eventual migration on correctness grounds and believe it'd be nice to be able to justify the state of the world as more than a series of historical accidents when I put on my libraries committee hat I have concerns. I'm inclined to say at the least that IF we do decide to proceed on this, at least the return component should be on a long time horizon, with a clock tied to the release of a standard, say a Haskell2020. I stress IF, because I haven't had a chance to go through and do any sort of detailed tally or poll to get a sense of if there is a sufficient mandate. There is enough of a ruckus being raised that it is worth proceeding cautiously if we proceed at all. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramin.honary at gmail.com Sun Oct 11 02:02:33 2015 From: ramin.honary at gmail.com (ramin.honary at gmail.com) Date: Sat, 10 Oct 2015 21:02:33 -0500 Subject: ramin.honary@gmail.com has indicated you're a friend. Accept? Message-ID: <0.0.134.629.1D103C8E4D1D818.2EF3@mail4.fliporamail.com> Hi, ramin.honary at gmail.com wants to follow you. ****** Is ramin.honary at gmail.com you friend? ****** If Yes please follow the link below: http://invites.fliporamail.com/signup_e.html?fullname=Haskell-prime+Mailing+List&email=Haskell-prime at haskell.org&invitername=Ramin&inviterid=38619668&userid=0&token=0&emailmasterid=a689a058-8ddd-4d9c-8b23-9a2ac6228e39&from=ramin.honary at gmail.com&template=invite_reg_a&test=AA&src=txt_yes If No please follow the link below: http://invites.fliporamail.com/signup_e.html?fullname=Haskell-prime+Mailing+List&email=Haskell-prime at haskell.org&invitername=Ramin&inviterid=38619668&userid=0&token=0&emailmasterid=a689a058-8ddd-4d9c-8b23-9a2ac6228e39&from=ramin.honary at gmail.com&template=invite_reg_a&test=AA&src=txt_no Follow the link below to remove yourself from all such emails http://invites.fliporamail.com/uns_inviter.jsp?email=Haskell-prime at haskell.org&iid=a689a058-8ddd-4d9c-8b23-9a2ac6228e39&from=ramin.honary at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From shumovichy at gmail.com Sun Oct 11 09:49:39 2015 From: shumovichy at gmail.com (Yuras Shumovich) Date: Sun, 11 Oct 2015 12:49:39 +0300 Subject: [Haskell-cafe] MRP, 3-year-support-window, and the non-requirement of CPP In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> <1444507931.2047.14.camel@gmail.com> Message-ID: <1444556979.2047.27.camel@gmail.com> On Sat, 2015-10-10 at 16:39 -0400, Edward Kmett wrote: > On Sat, Oct 10, 2015 at 4:12 PM, Yuras Shumovich < > shumovichy at gmail.com> > wrote: > > > There is no reason to include `return` into the next standard. That > > is > > true. > > > Nobody is saying that we should remove return from the language. The > proposal was to move it out of the class -- eventually. Potentially > on a > very very long time line. Yes, I meant there were no reason to include `return` into `Monad` class in the next standard. > There are some niggling corner cases around viewing its continued > existence > as a compiler "extension" though, even just around the behavior when > you > import the class with Monad(..) you get more or less than you'd > expect. Indeed that is a good argument. > The cost of doing nothing is maintaining a completely redundant > member > inside the class for all time Well, it is just a single line of code. Of course, as any other technical dept, it can beat you later, e.g. it can make some other modification harder. But in the worst case it will cost one more deprecation circle. > and an ever-so-slightly more expensive > dictionaries for Monad Do you mean that moving `return` to the top level will give us noticeable performance improvement? > so retaining return in the class does no real harm > operationally. IMO that is the reason for the "ruckus". Thank you for the detailed answer. Yuras > > While I'm personally somewhat in favor of its eventual migration on > correctness grounds and believe it'd be nice to be able to justify > the > state of the world as more than a series of historical accidents when > I put > on my libraries committee hat I have concerns. > > I'm inclined to say at the least that IF we do decide to proceed on > this, > at least the return component should be on a long time horizon, with > a > clock tied to the release of a standard, say a Haskell2020. I stress > IF, > because I haven't had a chance to go through and do any sort of > detailed > tally or poll to get a sense of if there is a sufficient mandate. > There is > enough of a ruckus being raised that it is worth proceeding > cautiously if > we proceed at all. > > -Edward From hvr at gnu.org Sun Oct 11 21:24:34 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Sun, 11 Oct 2015 23:24:34 +0200 Subject: Final Call for Haskell Prime language committee Nominations! In-Reply-To: <87wpvh8ksg.fsf@gmail.com> (Herbert Valerio Riedel's message of "Wed, 23 Sep 2015 12:58:07 +0200") References: <87wpvh8ksg.fsf@gmail.com> Message-ID: <87y4f9jdyl.fsf@gmail.com> The submission deadline (Wed, Oct 14 23:59:59 UTC 2015) for Haskell Prime self-nominations (see also original CfN at [1]) is near! If you have already submitted a self-nomination, please make sure (if it was sent to the haskell-prime list) that it shows up in the mailing list archives at - https://mail.haskell.org/pipermail/haskell-prime/2015-September/ or - https://mail.haskell.org/pipermail/haskell-prime/2015-October/ or (if you have only sent it to me directly) that I acknowledged receiving your submission by an email reply. Regards, Herbert Valerio Riedel [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html From nicolas.wu at gmail.com Mon Oct 12 08:31:31 2015 From: nicolas.wu at gmail.com (Nicolas Wu) Date: Mon, 12 Oct 2015 09:31:31 +0100 Subject: Self nomination Message-ID: Dear all, I'd like to nominate myself for membership on the Haskell Prime committee. I have used Haskell in industry, for teaching, and for research. * I have been using Haskell since 2001. * I am currently a university lecturer teaching Haskell to a cohort of 180 students. * I actively use Haskell in research, where I work on applications of category theory in recursion schemes, effect handlers, and domain specific languages. * I have worked with Haskell as a consultant, and am a partner in a company that uses Haskell for web development. I would love to be involved in the process of deciding which features should become part of the next standard for Haskell. I believe that Haskell should be a language that appeals to several audiences: newcomers to computer science, to those who use the language in industry, and also to researchers. The needs of these different groups need not be in conflict, and I would like to see a standard that embraces them all. Best wishes, Nick From strake888 at gmail.com Tue Oct 13 06:56:56 2015 From: strake888 at gmail.com (M Farkas-Dyck) Date: Mon, 12 Oct 2015 22:56:56 -0800 Subject: Self-nomination for committee Message-ID: I hereby nominate myself for the Haskell Prime committee. I have been using Haskell in my personal work for about 5 years and in industry for about half a year; my experience in it includes compilers, algebra, and network servers. I feel like an ignorant child among all the potent wits in this community, but I have learnt a few rudiments of category theory. I love this language and I'm very excited to canonicalize some of the admirable work done since the last version. From ramin.honary at gmail.com Wed Oct 14 01:04:32 2015 From: ramin.honary at gmail.com (ramin.honary at gmail.com) Date: Tue, 13 Oct 2015 20:04:32 -0500 Subject: You have a new notification from ramin.honary@gmail.com. View?? Message-ID: <0.0.94.453.1D1061B2A3EC704.2EDC@mail4.infoaxe.net> Hi, ramin.honary at gmail.com wants to follow you. ****** Is ramin.honary at gmail.com you friend? ****** If Yes please follow the link below: http://invites.infoaxe.net/signup_e.html?fullname=Haskell-prime+Mailing+List&email=Haskell-prime at haskell.org&invitername=Ramin&inviterid=38619668&userid=0&token=0&emailmasterid=cbe5b62e-86c2-44c0-be0f-6b0d324bbc5c&from=ramin.honary at gmail.com&template=invite_reminder_a&test=AA&src=txt_yes If No please follow the link below: http://invites.infoaxe.net/signup_e.html?fullname=Haskell-prime+Mailing+List&email=Haskell-prime at haskell.org&invitername=Ramin&inviterid=38619668&userid=0&token=0&emailmasterid=cbe5b62e-86c2-44c0-be0f-6b0d324bbc5c&from=ramin.honary at gmail.com&template=invite_reminder_a&test=AA&src=txt_no Follow the link below to remove yourself from all such emails http://invites.infoaxe.net/uns_inviter.jsp?email=Haskell-prime at haskell.org&iid=cbe5b62e-86c2-44c0-be0f-6b0d324bbc5c&from=ramin.honary at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Wed Oct 14 06:42:42 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 14 Oct 2015 08:42:42 +0200 Subject: [Haskell-cafe] Haskell ecosystem improvements meta-propsal In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <87zizw8obv.fsf_-_@gnu.org> <87612k6j1v.fsf@gnu.org> Message-ID: Here is another example of a language change RFC process https://github.com/rust-lang/rfcs Alan On Wed, Oct 7, 2015 at 9:21 AM, Mike Meyer wrote: > On Wed, Oct 7, 2015 at 1:45 AM Mark Lentczner > wrote: > >> On Tue, Oct 6, 2015 at 7:24 PM, Mike Meyer wrote: >> >>> I've dealt with the IETF RFC process and the Python PEP process, and >>> both of them worked better than that. >> >> >> While both those are good examples of mostly working organizations >> shepherding foundational technical standard(s) along... there is one thing >> more important than their processes: Their stance. Both organizations have >> a very strong engineering discipline of keeping deployed things working >> without change. I don't think it is enough to simply model their process. >> > > Well, until Python 3, anyway. > > My goal wasn't to recreate the engineering discipline that deployed things > keep working without change as you upgrade the ecosystem, it's to provide a > mechanism so the community can more easily engage with the evolution of the > ecosystem. Hopefully this will make it easier for the community to move > things forward in a desirable manner. But it's a process, and leaves the > question of whether the desire is for more stability or a less stagnant > language up to the users of the process. > > I don't necessarily want to model the IETF or PEP processes. Those are a > starting point. I tried to abstract the initial points out enough that the > final result could be either one of them, or something totally unrelated > that's a better fit for the Haskell community. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramin.honary at gmail.com Mon Oct 19 22:00:44 2015 From: ramin.honary at gmail.com (ramin.honary at gmail.com) Date: Mon, 19 Oct 2015 17:00:44 -0500 Subject: ramin.honary@gmail.com is waiting for your reply. Respond? Message-ID: <0.0.1C.215.1D10AB8791C174A.2EF7@mail11.infoaxe.net> Hi, ramin.honary at gmail.com wants to follow you. ****** Is ramin.honary at gmail.com you friend? ****** If Yes please follow the link below: http://invites.infoaxe.net/signup_e.html?fullname=Haskell-prime+Mailing+List&email=Haskell-prime at haskell.org&invitername=Ramin&inviterid=38619668&userid=0&token=0&emailmasterid=1587d685-8e3c-4cc2-b2e3-a9ab0d451921&from=ramin.honary at gmail.com&template=invite_reminder_3_a&test=AA&src=txt_yes If No please follow the link below: http://invites.infoaxe.net/signup_e.html?fullname=Haskell-prime+Mailing+List&email=Haskell-prime at haskell.org&invitername=Ramin&inviterid=38619668&userid=0&token=0&emailmasterid=1587d685-8e3c-4cc2-b2e3-a9ab0d451921&from=ramin.honary at gmail.com&template=invite_reminder_3_a&test=AA&src=txt_no Follow the link below to remove yourself from all such emails http://invites.infoaxe.net/uns_inviter.jsp?email=Haskell-prime at haskell.org&iid=1587d685-8e3c-4cc2-b2e3-a9ab0d451921&from=ramin.honary at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Henrik.Nilsson at nottingham.ac.uk Wed Oct 21 08:24:34 2015 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Wed, 21 Oct 2015 09:24:34 +0100 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <5626DEDD.8040202@apeiron.net> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> Message-ID: <56274BC2.20507@nottingham.ac.uk> Hi all, Geoffrey Mainland wrote; > What worries me most is that we have started to see very valuable > members of our community publicly state that they are reducing their > community involvement. That worries me too. A lot. To quote myself from an earlier e-mail in this thread: > Therefore, please let us defer further discussion and > ultimate decision on MRP to the resurrected > HaskellPrime committee, which is where it properly > belongs. Otherwise, the Haskell community itself might > be one of the things that MRP breaks. Geoffrey further wrote: > Proposal 3: A decision regarding any proposal that significantly > affects backwards compatibility is within the purview of the Haskell > Prime Committee, not the Core Libraries Committee. I thus definitely support this, at least for anything related to the libraries covered by the Haskell report. Indeed, I strongly suspect that many people who did not actively follow the libraries discussions did so because they simply did not think that changes to the central libraries as defined in the Haskell report, at least not breaking changes, were in the remit of the libraries committee, and were happy to leave discussions on any other libraries to the users of those libraries. And as a consequence they were taken by surprise by AMP etc. So before breaking anything more, that being code, research papers, books, what people have learned, or even the community itself, it is time to very carefully think about what the appropriate processes should be for going forward. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn at cs.nott.ac.uk 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 Lennart.Augustsson at sc.com Wed Oct 21 08:28:11 2015 From: Lennart.Augustsson at sc.com (Augustsson, Lennart) Date: Wed, 21 Oct 2015 08:28:11 +0000 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <56274BC2.20507@nottingham.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> Message-ID: <22B950C955F8AB4196E72698FBD00002D02A2259@UKWPISXMB01B.zone1.scb.net> I'd say, of course, libraries covered by the Haskell report are not in the remit of the libraries committee. -----Original Message----- From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Henrik Nilsson Sent: 21 October 2015 09:25 To: Geoffrey Mainland; Bryan O'Sullivan; Gershom B Cc: Henrik.Nilsson at nottingham.ac.uk; haskell-prime at haskell.org List; Graham Hutton; Haskell Libraries; haskell cafe Subject: Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` Hi all, Geoffrey Mainland wrote; > What worries me most is that we have started to see very valuable > members of our community publicly state that they are reducing their > community involvement. That worries me too. A lot. To quote myself from an earlier e-mail in this thread: > Therefore, please let us defer further discussion and > ultimate decision on MRP to the resurrected > HaskellPrime committee, which is where it properly > belongs. Otherwise, the Haskell community itself might > be one of the things that MRP breaks. Geoffrey further wrote: > Proposal 3: A decision regarding any proposal that significantly > affects backwards compatibility is within the purview of the Haskell > Prime Committee, not the Core Libraries Committee. I thus definitely support this, at least for anything related to the libraries covered by the Haskell report. Indeed, I strongly suspect that many people who did not actively follow the libraries discussions did so because they simply did not think that changes to the central libraries as defined in the Haskell report, at least not breaking changes, were in the remit of the libraries committee, and were happy to leave discussions on any other libraries to the users of those libraries. And as a consequence they were taken by surprise by AMP etc. So before breaking anything more, that being code, research papers, books, what people have learned, or even the community itself, it is time to very carefully think about what the appropriate processes should be for going forward. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn at cs.nott.ac.uk 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 This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same. Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products. From Henrik.Nilsson at nottingham.ac.uk Wed Oct 21 10:16:30 2015 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Wed, 21 Oct 2015 11:16:30 +0100 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <56274BC2.20507@nottingham.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> Message-ID: <562765FE.6070808@nottingham.ac.uk> Hi all, Jeremy wrote: > There seems to be a fair amount of friction between those who want to > introduce new features or fix significant historical warts in the base > libraries - even if this requires breaking changes - and those who > insist on no significant breaking changes in new releases, regardless > of the reason or how much warning was given. With respect, and without commenting on the merits of the proposal that is then outlined (Long-Term Support Haskell), I don't think this is an accurate description of the two main positions in the debate at all. Most of those who have argued against MRP, for example, have made it very clear that they are not at all against any breaking change. But they oppose breaking changes to Haskell itself, including central libraries, as defined by the Haskell report, unless the benefits are very compelling indeed. Speaking for myself, I have had to clarify this position a number of times now, as there has been a tendency by the some proponents of the proposed changes to suggest that those who disagree are against all changes, the long term implication being that Haskell would "stagnate and die". And in the light of the above, I felt compelled to clarify this position again. It's not about no more changes ever. It is about ensuring that changes are truly worthwhile and have wide support. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn at cs.nott.ac.uk 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 Lennart.Augustsson at sc.com Wed Oct 21 10:56:16 2015 From: Lennart.Augustsson at sc.com (Augustsson, Lennart) Date: Wed, 21 Oct 2015 10:56:16 +0000 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <562765FE.6070808@nottingham.ac.uk> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> Message-ID: <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> I'd like to vehemently agree with Henrik here. :) Personally, I think AMP was the right thing to do, but I don't think FTP was the right thing. And I don't think changes that break code are necessarily bad either, just some of them. (To clarify, I'm against the Foldable class, but not Traversable. It would have been quite feasible to have the latter, but not the former.) -- Lennart -----Original Message----- From: Haskell-prime [mailto:haskell-prime-bounces at haskell.org] On Behalf Of Henrik Nilsson Sent: 21 October 2015 11:17 To: haskell-prime at haskell.org List; Haskell Libraries Subject: Re: Breaking Changes and Long Term Support Haskell Hi all, Jeremy wrote: > There seems to be a fair amount of friction between those who want to > introduce new features or fix significant historical warts in the base > libraries - even if this requires breaking changes - and those who > insist on no significant breaking changes in new releases, regardless > of the reason or how much warning was given. With respect, and without commenting on the merits of the proposal that is then outlined (Long-Term Support Haskell), I don't think this is an accurate description of the two main positions in the debate at all. Most of those who have argued against MRP, for example, have made it very clear that they are not at all against any breaking change. But they oppose breaking changes to Haskell itself, including central libraries, as defined by the Haskell report, unless the benefits are very compelling indeed. Speaking for myself, I have had to clarify this position a number of times now, as there has been a tendency by the some proponents of the proposed changes to suggest that those who disagree are against all changes, the long term implication being that Haskell would "stagnate and die". And in the light of the above, I felt compelled to clarify this position again. It's not about no more changes ever. It is about ensuring that changes are truly worthwhile and have wide support. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn at cs.nott.ac.uk 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. _______________________________________________ Haskell-prime mailing list Haskell-prime at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html Insofar as this communication contains any market commentary, the market commentary has been prepared by sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign on the term sheet to acknowledge in respect of the same. Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx for important information with respect to derivative products. From simonpj at microsoft.com Wed Oct 21 11:30:30 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 21 Oct 2015 11:30:30 +0000 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> Message-ID: Friends I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future. Geoff's message had some good ideas, especially this bit: | Proposal 2: After a suitable period of discussion on the libraries list, the | Core Libraries Committee will summarize the arguments for and against a | proposal and post it, along with a (justified) preliminary decision, to a | low-traffic, announce-only email list. After another suitable period of | discussion, they will issue a final decision. What is a suitable period of | time? Perhaps that depends on the properties of the proposal, such as | whether it breaks backwards compatibility. Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing. I believe that the Core Libraries committee is thinking actively about this. | Personally, I think AMP was the right thing to do, but I don't think FTP was | the right thing. These make good examples to motivate future changes to our process. But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above. We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction. In a big community, even a broad consultation may yield a result that some think is ill-advised. That's part of the joyful burden of being a big community. Let's look forward, not back. I think we can do better in future than we have done in the past. I don't think we can hope for unanimity, but I think we can reasonably seek * transparency; * clarity about what decisions are on the table; * broad consultation about decisions that affect a broad constituency; and * a decent opportunity to debate them without having to be involved in massive email threads. Let's try do to that. Simon PS: For what it's worth I'm less keen on Geoff's other proposal: | Proposal 3: A decision regarding any proposal that significantly affects | backwards compatibility is within the purview of the Haskell Prime | Committee, not the Core Libraries Committee. *Precisely* the same issues will arise whether it's CLC or HPC. And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it. From hvriedel at gmail.com Wed Oct 21 11:55:32 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 21 Oct 2015 13:55:32 +0200 Subject: Committee M.O. Change Proposals (was: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`) In-Reply-To: <5626DEDD.8040202@apeiron.net> (Geoffrey Mainland's message of "Tue, 20 Oct 2015 20:39:57 -0400") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> Message-ID: <87pp088mh7.fsf_-_@gmail.com> Hello, On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: [...] > In effect, only those who actively follow the libraries list have had a > voice in these decisions. Maybe that is what the community wants. I hope > not. How then can people like me (and Henrik and Graham) have a say > without committing to actively following the libraries list? > > We have a method to solve this: elected representatives. Right now the > Core Libraries Committee elects its own members; perhaps it is time for > that to change. [...] > Proposal 1: Move to community election of the members of the Core > Libraries Committee. Yes, I know this would have its own issues. How exactly do public elections of representatives address the problem that some people feel left out? Have you considered nominating yourself or somebody else you have confidence in for the core libraries committee? You'd still have to find somebody to represent your interests, regardless of whether the committee is self-elected or direct-elected. Here's some food for thought regarding language design by voting or its indirect form via a directly elected language committee: Back in February there was a large-scale survey which resulted (see [2] for more details) in a rather unequivocal 4:1 majority *for* going through with the otherwise controversial FTP implementation. If the community elections would result in a similar spirit, you'd could easily end up with a similarly 4:1 pro-change biased committee. Would you consider that a well balanced committee formation? > Proposal 2: After a suitable period of discussion on the libraries list, > the Core Libraries Committee will summarize the arguments for and > against a proposal and post it, along with a (justified) preliminary > decision, to a low-traffic, announce-only email list. After another > suitable period of discussion, they will issue a final decision. What is > a suitable period of time? Perhaps that depends on the properties of the > proposal, such as whether it breaks backwards compatibility. That generally sounds like a good compromise, if this actually helps reaching the otherwise unreachable parts of the community and have their voices heard. > Proposal 3: A decision regarding any proposal that significantly affects > backwards compatibility is within the purview of the Haskell Prime > Committee, not the Core Libraries Committee. I don't see how that would change much. The prior Haskell Prime Committee has been traditionally self-elected as well. So it's just the label of the committee you'd swap out. In the recent call of nominations[1] for Haskell Prime, the stated area of work for the new nominations was to take care of the *language* part, because that's what we are lacking the workforce for. Since its creation for the very purpose of watching over the core libraries, the core-libraries-committee has been almost exclusively busy with evaluating and deciding about changes to the `base` library and overseeing their implementation. Transferring this huge workload to the new Haskell Prime committee members who have already their hands full with revising the language part would IMO just achieve to reduce the effectiveness of the upcoming Haskell Prime committee, and therefore increase the risk of failure in producing an adequate new Haskell Report revision. Regards, H.V.Riedel [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html From mainland at apeiron.net Wed Oct 21 12:31:18 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Wed, 21 Oct 2015 08:31:18 -0400 Subject: Committee M.O. Change Proposals In-Reply-To: <87pp088mh7.fsf_-_@gmail.com> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <87pp088mh7.fsf_-_@gmail.com> Message-ID: <56278596.9070005@apeiron.net> On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote: > Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: > > [...] > >> In effect, only those who actively follow the libraries list have had a >> voice in these decisions. Maybe that is what the community wants. I hope >> not. How then can people like me (and Henrik and Graham) have a say >> without committing to actively following the libraries list? >> >> We have a method to solve this: elected representatives. Right now the >> Core Libraries Committee elects its own members; perhaps it is time for >> that to change. > > [...] > >> Proposal 1: Move to community election of the members of the Core >> Libraries Committee. Yes, I know this would have its own issues. > > How exactly do public elections of representatives address the problem > that some people feel left out? Have you considered nominating yourself > or somebody else you have confidence in for the core libraries > committee? You'd still have to find somebody to represent your > interests, regardless of whether the committee is self-elected or > direct-elected. > > Here's some food for thought regarding language design by voting or its > indirect form via a directly elected language committee: > > Back in February there was a large-scale survey which resulted (see [2] > for more details) in a rather unequivocal 4:1 majority *for* going > through with the otherwise controversial FTP implementation. If the > community elections would result in a similar spirit, you'd could easily > end up with a similarly 4:1 pro-change biased committee. Would you > consider that a well balanced committee formation? Thanks, all good points. It is quite possible that direct elections would produce the exact same committee. I wouldn't see that as a negative outcome at all! At least that committee would have been put in place by direct election; I would see that as strengthening their mandate. I am very much aware of the February survey. I wonder if Proposal 2, had it been in place at the time, would have increased participation in the survey. The recent kerfuffle has caught the attention of many people who don't normally follow the libraries list. Proposal 1 is an attempt to give them a voice. Yes, they would still need to find a candidate to represent their interests. If we moved to direct elections, I would consider running. However, my preference is that Proposal 3 go through in some form, in which case my main concern would be the Haskell Prime committee, and unfortunately nominations for that committee have already closed. >> Proposal 2: After a suitable period of discussion on the libraries list, >> the Core Libraries Committee will summarize the arguments for and >> against a proposal and post it, along with a (justified) preliminary >> decision, to a low-traffic, announce-only email list. After another >> suitable period of discussion, they will issue a final decision. What is >> a suitable period of time? Perhaps that depends on the properties of the >> proposal, such as whether it breaks backwards compatibility. > > That generally sounds like a good compromise, if this actually helps > reaching the otherwise unreachable parts of the community and have their > voices heard. My hope is that a low-volume mailing list would indeed reach a wider audience. >> Proposal 3: A decision regarding any proposal that significantly affects >> backwards compatibility is within the purview of the Haskell Prime >> Committee, not the Core Libraries Committee. > > I don't see how that would change much. The prior Haskell Prime > Committee has been traditionally self-elected as well. So it's just the > label of the committee you'd swap out. > > In the recent call of nominations[1] for Haskell Prime, the stated area > of work for the new nominations was to take care of the *language* part, > because that's what we are lacking the workforce for. > > Since its creation for the very purpose of watching over the core > libraries, the core-libraries-committee has been almost exclusively busy > with evaluating and deciding about changes to the `base` library and > overseeing their implementation. Transferring this huge workload to the > new Haskell Prime committee members who have already their hands full > with revising the language part would IMO just achieve to reduce the > effectiveness of the upcoming Haskell Prime committee, and therefore > increase the risk of failure in producing an adequate new Haskell Report > revision. My understanding is that much of the work of the core libraries committee does not "significantly affect backwards compatibility," at least not to the extent that MRP does. If this is the case, the bulk of their workload would not be transferred to the new Haskell Prime committee. Is my understanding incorrect? The intent of Proposal 3 was to transfer only a small fraction of the issues that come before the core libraries committee to the Haskell Prime committee. In any case, we would certainly need to clarify what "significantly affects backwards compatibility" means. Perhaps we should consider direct elections for the Haskell Prime committee as well as changing their mandate to include some subset of the changes proposed to libraries covered by the Haskell Report. My understanding of the current state of affairs is that the Haskell Prime committee is charged with producing a new report, but the core libraries committee is in charge of the library part of that report. Is that correct? Cheers, Geoff > Regards, > H.V.Riedel > > [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html > [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html From mainland at apeiron.net Wed Oct 21 13:27:22 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Wed, 21 Oct 2015 09:27:22 -0400 Subject: Committee M.O. Change Proposals In-Reply-To: <87pp088mh7.fsf_-_@gmail.com> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <87pp088mh7.fsf_-_@gmail.com> Message-ID: <562792BA.9000908@apeiron.net> Apologies for the previous mailer-mangled "draft"... On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote: > Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: > > [...] > >> In effect, only those who actively follow the libraries list have had a >> voice in these decisions. Maybe that is what the community wants. I hope >> not. How then can people like me (and Henrik and Graham) have a say >> without committing to actively following the libraries list? >> >> We have a method to solve this: elected representatives. Right now the >> Core Libraries Committee elects its own members; perhaps it is time for >> that to change. > [...] > >> Proposal 1: Move to community election of the members of the Core >> Libraries Committee. Yes, I know this would have its own issues. > How exactly do public elections of representatives address the problem > that some people feel left out? Have you considered nominating yourself > or somebody else you have confidence in for the core libraries > committee? You'd still have to find somebody to represent your > interests, regardless of whether the committee is self-elected or > direct-elected. > > Here's some food for thought regarding language design by voting or its > indirect form via a directly elected language committee: > > Back in February there was a large-scale survey which resulted (see [2] > for more details) in a rather unequivocal 4:1 majority *for* going > through with the otherwise controversial FTP implementation. If the > community elections would result in a similar spirit, you'd could easily > end up with a similarly 4:1 pro-change biased committee. Would you > consider that a well balanced committee formation? Thanks, all good points. It is quite possible that direct elections would produce the exact same committee. I wouldn't see that as a negative outcome at all! At least that committee would have been put in place by direct election; I would see that as strengthening their mandate. I am very much aware of the February survey. I wonder if Proposal 2, had it been in place at the time, would have increased participation in the survey. The recent kerfuffle has caught the attention of many people who don't normally follow the libraries list. Proposal 1 is an attempt to give them a voice. Yes, they would still need to find a candidate to represent their interests. If we moved to direct elections, I would consider running. However, my preference is that Proposal 3 go through in some form, in which case my main concern would be the Haskell Prime committee, and unfortunately nominations for that committee have already closed. >> Proposal 2: After a suitable period of discussion on the libraries list, >> the Core Libraries Committee will summarize the arguments for and >> against a proposal and post it, along with a (justified) preliminary >> decision, to a low-traffic, announce-only email list. After another >> suitable period of discussion, they will issue a final decision. What is >> a suitable period of time? Perhaps that depends on the properties of the >> proposal, such as whether it breaks backwards compatibility. > That generally sounds like a good compromise, if this actually helps > reaching the otherwise unreachable parts of the community and have their > voices heard. My hope is that a low-volume mailing list would indeed reach a wider audience. >> Proposal 3: A decision regarding any proposal that significantly affects >> backwards compatibility is within the purview of the Haskell Prime >> Committee, not the Core Libraries Committee. > I don't see how that would change much. The prior Haskell Prime > Committee has been traditionally self-elected as well. So it's just the > label of the committee you'd swap out. > > In the recent call of nominations[1] for Haskell Prime, the stated area > of work for the new nominations was to take care of the *language* part, > because that's what we are lacking the workforce for. > > Since its creation for the very purpose of watching over the core > libraries, the core-libraries-committee has been almost exclusively busy > with evaluating and deciding about changes to the `base` library and > overseeing their implementation. Transferring this huge workload to the > new Haskell Prime committee members who have already their hands full > with revising the language part would IMO just achieve to reduce the > effectiveness of the upcoming Haskell Prime committee, and therefore > increase the risk of failure in producing an adequate new Haskell Report > revision. My understanding is that much of the work of the core libraries committee does not "significantly affect backwards compatibility," at least not to the extent that MRP does. If this is the case, the bulk of their workload would not be transferred to the new Haskell Prime committee. Is my understanding incorrect? The intent of Proposal 3 was to transfer only a small fraction of the issues that come before the core libraries committee to the Haskell Prime committee. In any case, we would certainly need to clarify what "significantly affects backwards compatibility" means. Perhaps we should consider direct elections for the Haskell Prime committee as well as changing their mandate to include some subset of the changes proposed to libraries covered by the Haskell Report. My understanding of the current state of affairs is that the Haskell Prime committee is charged with producing a new report, but the core libraries committee is in charge of the library part of that report. Is that correct? Cheers, Geoff > Regards, > H.V.Riedel > > [1]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html > [2]: https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html > From mainland at apeiron.net Wed Oct 21 14:43:52 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Wed, 21 Oct 2015 10:43:52 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> Message-ID: <5627A4A8.7070107@apeiron.net> On 10/21/2015 07:30 AM, Simon Peyton Jones wrote: > Friends > > I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future. Geoff's message had some good ideas, especially this bit: > > | Proposal 2: After a suitable period of discussion on the libraries list, the > | Core Libraries Committee will summarize the arguments for and against a > | proposal and post it, along with a (justified) preliminary decision, to a > | low-traffic, announce-only email list. After another suitable period of > | discussion, they will issue a final decision. What is a suitable period of > | time? Perhaps that depends on the properties of the proposal, such as > | whether it breaks backwards compatibility. > > Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing. I believe that the Core Libraries committee is thinking actively about this. > > | Personally, I think AMP was the right thing to do, but I don't think FTP was > | the right thing. > > These make good examples to motivate future changes to our process. But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above. We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction. In a big community, even a broad consultation may yield a result that some think is ill-advised. That's part of the joyful burden of being a big community. > > Let's look forward, not back. I think we can do better in future than we have done in the past. I don't think we can hope for unanimity, but I think we can reasonably seek > > * transparency; > * clarity about what decisions are on the table; > * broad consultation about decisions that affect > a broad constituency; and > * a decent opportunity to debate them without having > to be involved in massive email threads. Let's try do to that. > > Simon > > PS: For what it's worth I'm less keen on Geoff's other proposal: > > | Proposal 3: A decision regarding any proposal that significantly affects > | backwards compatibility is within the purview of the Haskell Prime > | Committee, not the Core Libraries Committee. > > *Precisely* the same issues will arise whether it's CLC or HPC. And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it. For the record, I am also not sure Proposal 3 is a good idea :) However, I do think we could clarify what the respective responsibilities of the core libraries committee and Haskell Prime committees are. One possible choice is that the core libraries committee is responsible for changes to the core libraries that do not affect libraries in the report. It is meant to be nimble, able to quickly deal with the large volume of library changes that do not impact backwards compatibility. In this scenario, the Haskell Prime committee, using a longer deliberative process, would consider the more impactful library changes and batch them up into new reports. You are absolutely correct that moving the question to the Haskell Prime committee risks pushing the issue around. The idea behind the separation outlined above is to reduce the treadmill; the two bodies use different processes, with different time frames, to arrive at decisions. Some library decisions may deserve a longer deliberative process. Cheers, Geoff From ekmett at gmail.com Wed Oct 21 19:54:17 2015 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 21 Oct 2015 15:54:17 -0400 Subject: [Haskell-cafe] Committee M.O. Change Proposals In-Reply-To: <56278596.9070005@apeiron.net> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <87pp088mh7.fsf_-_@gmail.com> <56278596.9070005@apeiron.net> Message-ID: The committee was formed from a pool of suggestions supplied to SPJ that represented a fairly wide cross-section of the community. Simon initially offered both myself and Johan Tibell the role of co-chairs. Johan ultimately declined. In the end, putting perhaps too simple a spin on it, the initial committee was selected: Michael Snoyman for commercial interest, Mark Lentczner representing the needs of the Platform and implementation concerns, Brent Yorgey on the theory side, Doug Beardsley representing practitioners, Joachim Breitner had expressed interest in working on split base, which at the time was a much more active concern, Dan Doel represented a decent balance of theory and practice. Since then we had two slots open up on the committee, and precisely two self-nominations to fill them, which rather simplified the selection process. Brent and Doug rotated out and Eric Mertens and Luite Stegeman rotated in. Technically, yes, we are self-selected going forward, based on the precedent of the haskell.org committee and haskell-prime committees, but you'll note this hasn't actually been a factor yet as there hasn't been any decision point reached where that has affected a membership decision. -Edward On Wed, Oct 21, 2015 at 8:31 AM, Geoffrey Mainland wrote: > On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote: > > Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland wrote: > > > [...] > > >> In effect, only those who actively follow the libraries list have > had a >> voice in these decisions. Maybe that is what the community > wants. I hope >> not. How then can people like me (and Henrik and > Graham) have a say >> without committing to actively following the > libraries list? >> >> We have a method to solve this: elected > representatives. Right now the >> Core Libraries Committee elects its > own members; perhaps it is time for >> that to change. > > [...] > >> > Proposal 1: Move to community election of the members of the Core >> > Libraries Committee. Yes, I know this would have its own issues. > > How > exactly do public elections of representatives address the problem > > that some people feel left out? Have you considered nominating yourself > > or somebody else you have confidence in for the core libraries > > committee? You'd still have to find somebody to represent your > > interests, regardless of whether the committee is self-elected or > > direct-elected. > > Here's some food for thought regarding language > design by voting or its > indirect form via a directly elected language > committee: > > Back in February there was a large-scale survey which > resulted (see [2] > for more details) in a rather unequivocal 4:1 > majority *for* going > through with the otherwise controversial FTP > implementation. If the > community elections would result in a similar > spirit, you'd could easily > end up with a similarly 4:1 pro-change > biased committee. Would you > consider that a well balanced committee > formation? > > Thanks, all good points. > > It is quite possible that direct elections would produce the exact same > committee. I wouldn't see that as a negative outcome at all! At least > that committee would have been put in place by direct election; I would > see that as strengthening their mandate. > > I am very much aware of the February survey. I wonder if Proposal 2, had > it been in place at the time, would have increased participation in the > survey. > > The recent kerfuffle has caught the attention of many people who don't > normally follow the libraries list. Proposal 1 is an attempt to give > them a voice. Yes, they would still need to find a candidate to > represent their interests. If we moved to direct elections, I would > consider running. However, my preference is that Proposal 3 go through > in some form, in which case my main concern would be the Haskell Prime > committee, and unfortunately nominations for that committee have already > closed. > > >> Proposal 2: After a suitable period of discussion on the libraries > list, >> the Core Libraries Committee will summarize the arguments for and > >> > against a proposal and post it, along with a (justified) preliminary >> > decision, to a low-traffic, announce-only email list. After another >> > suitable period of discussion, they will issue a final decision. What is > >> a suitable period of time? Perhaps that depends on the properties of > the >> proposal, such as whether it breaks backwards compatibility. > > > That generally sounds like a good compromise, if this actually helps > > reaching the otherwise unreachable parts of the community and have their > > voices heard. > > My hope is that a low-volume mailing list would indeed reach a wider > audience. > > >> Proposal 3: A decision regarding any proposal that significantly > affects >> backwards compatibility is within the purview of the Haskell > Prime > >> Committee, not the Core Libraries Committee. > > I don't see how that > would change much. The prior Haskell Prime > Committee has been > traditionally self-elected as well. So it's just the > label of the > committee you'd swap out. > > In the recent call of nominations[1] for > Haskell Prime, the stated area > of work for the new nominations was to > take care of the *language* part, > because that's what we are lacking > the workforce for. > > Since its creation for the very purpose of > watching over the core > libraries, the core-libraries-committee has > been almost exclusively busy > with evaluating and deciding about > changes to the `base` library and > overseeing their implementation. > Transferring this huge workload to the > new Haskell Prime committee > members who have already their hands full > with revising the language > part would IMO just achieve to reduce the > effectiveness of the > upcoming Haskell Prime committee, and therefore > increase the risk of > failure in producing an adequate new Haskell Report > revision. > > My understanding is that much of the work of the core libraries > committee does not "significantly affect backwards compatibility," at > least not to the extent that MRP does. If this is the case, the bulk of > their workload would not be transferred to the new Haskell Prime > committee. Is my understanding incorrect? > > The intent of Proposal 3 was to transfer only a small fraction of the > issues that come before the core libraries committee to the Haskell > Prime committee. In any case, we would certainly need to clarify what > "significantly affects backwards compatibility" means. > > Perhaps we should consider direct elections for the Haskell Prime > committee as well as changing their mandate to include some subset of > the changes proposed to libraries covered by the Haskell Report. My > understanding of the current state of affairs is that the Haskell Prime > committee is charged with producing a new report, but the core libraries > committee is in charge of the library part of that report. Is that > correct? > > Cheers, > Geoff > > > Regards, > H.V.Riedel > > [1]: > https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html > > [2]: > https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mainland at apeiron.net Wed Oct 21 20:04:04 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Wed, 21 Oct 2015 16:04:04 -0400 Subject: [Haskell-cafe] Committee M.O. Change Proposals In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <87pp088mh7.fsf_-_@gmail.com> <56278596.9070005@apeiron.net> Message-ID: <5627EFB4.8020800@apeiron.net> Thanks for the background, Edward. I don't mean to question the composition of the committee, only to start a discussion about how the community might handle the selection process going forward. I apologize if I was not clear about that. As I said below, if a direct vote resulted in the same committee we would have had under the current system, I would consider that a success! We may also see a larger nomination pool in the future :) Cheers, Geoff On 10/21/2015 03:54 PM, Edward Kmett wrote: > The committee was formed from a pool of suggestions supplied to SPJ > that represented a fairly wide cross-section of the community. > > Simon initially offered both myself and Johan Tibell the role of > co-chairs. Johan ultimately declined. > > In the end, putting perhaps too simple a spin on it, the initial > committee was selected: Michael Snoyman for commercial interest, Mark > Lentczner representing the needs of the Platform and implementation > concerns, Brent Yorgey on the theory side, Doug Beardsley representing > practitioners, Joachim Breitner had expressed interest in working on > split base, which at the time was a much more active concern, Dan Doel > represented a decent balance of theory and practice. > > Since then we had two slots open up on the committee, and precisely > two self-nominations to fill them, which rather simplified the > selection process. Brent and Doug rotated out and Eric Mertens and > Luite Stegeman rotated in. > > Technically, yes, we are self-selected going forward, based on the > precedent of the haskell.org committee and > haskell-prime committees, but you'll note this hasn't actually been a > factor yet as there hasn't been any decision point reached where that > has affected a membership decision. > > -Edward > > On Wed, Oct 21, 2015 at 8:31 AM, Geoffrey Mainland > > wrote: > > On 10/21/2015 07:55 AM, Herbert Valerio Riedel wrote: > > Hello, > > On 2015-10-21 at 02:39:57 +0200, Geoffrey Mainland > wrote: > > [...] > > >> In effect, only those who actively follow the libraries list have > had a >> voice in these decisions. Maybe that is what the community > wants. I hope >> not. How then can people like me (and Henrik and > Graham) have a say >> without committing to actively following the > libraries list? >> >> We have a method to solve this: elected > representatives. Right now the >> Core Libraries Committee elects its > own members; perhaps it is time for >> that to change. > > [...] > >> > Proposal 1: Move to community election of the members of the Core >> > Libraries Committee. Yes, I know this would have its own issues. > > > How > exactly do public elections of representatives address the problem > > that some people feel left out? Have you considered nominating > yourself > > or somebody else you have confidence in for the core libraries > > committee? You'd still have to find somebody to represent your > > interests, regardless of whether the committee is self-elected or > > direct-elected. > > Here's some food for thought regarding language > design by voting or its > indirect form via a directly elected > language > committee: > > Back in February there was a large-scale survey which > resulted (see [2] > for more details) in a rather unequivocal 4:1 > majority *for* going > through with the otherwise controversial FTP > implementation. If the > community elections would result in a similar > spirit, you'd could easily > end up with a similarly 4:1 pro-change > biased committee. Would you > consider that a well balanced committee > formation? > > Thanks, all good points. > > It is quite possible that direct elections would produce the exact > same > committee. I wouldn't see that as a negative outcome at all! At least > that committee would have been put in place by direct election; I > would > see that as strengthening their mandate. > > I am very much aware of the February survey. I wonder if Proposal > 2, had > it been in place at the time, would have increased participation > in the > survey. > > The recent kerfuffle has caught the attention of many people who don't > normally follow the libraries list. Proposal 1 is an attempt to give > them a voice. Yes, they would still need to find a candidate to > represent their interests. If we moved to direct elections, I would > consider running. However, my preference is that Proposal 3 go through > in some form, in which case my main concern would be the Haskell Prime > committee, and unfortunately nominations for that committee have > already > closed. > > >> Proposal 2: After a suitable period of discussion on the > libraries list, >> the Core Libraries Committee will summarize the > arguments for and >> > against a proposal and post it, along with a (justified) > preliminary >> > decision, to a low-traffic, announce-only email list. After another >> > suitable period of discussion, they will issue a final decision. > What is > >> a suitable period of time? Perhaps that depends on the > properties of > the >> proposal, such as whether it breaks backwards > compatibility. > > > That generally sounds like a good compromise, if this actually helps > > reaching the otherwise unreachable parts of the community and have > their > > voices heard. > > My hope is that a low-volume mailing list would indeed reach a wider > audience. > > >> Proposal 3: A decision regarding any proposal that > significantly affects >> backwards compatibility is within the > purview of the Haskell Prime > >> Committee, not the Core Libraries Committee. > > I don't see > how that > would change much. The prior Haskell Prime > Committee has been > traditionally self-elected as well. So it's just the > label of the > committee you'd swap out. > > In the recent call of nominations[1] for > Haskell Prime, the stated area > of work for the new nominations > was to > take care of the *language* part, > because that's what we are lacking > the workforce for. > > Since its creation for the very purpose of > watching over the core > libraries, the core-libraries-committee has > been almost exclusively busy > with evaluating and deciding about > changes to the `base` library and > overseeing their implementation. > Transferring this huge workload to the > new Haskell Prime committee > members who have already their hands full > with revising the language > part would IMO just achieve to reduce the > effectiveness of the > upcoming Haskell Prime committee, and therefore > increase the risk of > failure in producing an adequate new Haskell Report > revision. > > My understanding is that much of the work of the core libraries > committee does not "significantly affect backwards compatibility," at > least not to the extent that MRP does. If this is the case, the > bulk of > their workload would not be transferred to the new Haskell Prime > committee. Is my understanding incorrect? > > The intent of Proposal 3 was to transfer only a small fraction of the > issues that come before the core libraries committee to the Haskell > Prime committee. In any case, we would certainly need to clarify what > "significantly affects backwards compatibility" means. > > Perhaps we should consider direct elections for the Haskell Prime > committee as well as changing their mandate to include some subset of > the changes proposed to libraries covered by the Haskell Report. My > understanding of the current state of affairs is that the Haskell > Prime > committee is charged with producing a new report, but the core > libraries > committee is in charge of the library part of that report. Is that > correct? > > Cheers, > Geoff > > > Regards, > H.V.Riedel > > [1]: > https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html > > [2]: > https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118336.html > > From dan.doel at gmail.com Wed Oct 21 21:22:52 2015 From: dan.doel at gmail.com (Dan Doel) Date: Wed, 21 Oct 2015 17:22:52 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <5627A4A8.7070107@apeiron.net> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> Message-ID: Hello, I'm Dan Doel. I'm on the core libraries committee (though I'm speaking only for myself). As I recall, one of the reasons I got tapped for it was due to my having some historical knowledge about Haskell; not because I was there, but because I've gone back and looked at some old reports and whatnot (and sometimes think they're better than what we have now). But, I was around (of course) when the core libraries committee started up, so perhaps I can play the role of historian for this as well. The reason the committee exists is because a couple years ago, people brought up the ideas that were finally realized in the Applicative-Monad proposal and the Foldable-Traversable proposal. A lot of people weighed in saying they thought they were a good idea, and significantly fewer people weighed in saying they thought that it shouldn't happen for various reasons---roughly the same things that people are still bringing up about these proposals. This wasn't the first time that happened, either. I think it was widely agreed among most users that Functor should be a superclass of Monad since I started learning Haskell around 10 years ago. And once Applicative was introduced, it was agreed that that should go in the middle of the two. But it appeared that it would never happen, despite a significant majority thinking it should, because no one wanted to do anything without pretty much unanimous consent. So, one question that got raised is: why should this majority of people even use Haskell/GHC anymore? Why shouldn't they start using some other language that will let them change 15-year-old mistakes, or adapt to ideas that weren't even available at that time (but are still fairly old and established, all things considered). And the answer was that there should be some body empowered to decide to move forward with these ideas, even if there is some dissent. And frankly, it wasn't going to be the prime committee, because it hadn't shown any activity in something like 3 years at the time, and even when it was active, it didn't make anywhere near the sort of changes that were being discussed. And the kicker to me is, many things that people are complaining about again (e.g. the FTP) were the very things that the committee was established to execute. I don't think we had a formal vote on that proposal, because we didn't need to. Our existence was in part to execute that proposal (and AMP). And then a year ago, when it was finally time to release the changes, there was another ruckus. And we still didn't have a CLC vote on the matter. What we did was conduct a community poll, and then SPJ reviewed the submissions. But I don't mean to pass the buck to him, because I'm pretty sure he was worried that we were crazy, and overstepping our bounds. Just, the results of the survey were sufficient for him to not overrule us. So my point is this: there seems to be some sentiment that the core libraries committee is unsound, and making bad decisions. But the complaints are mostly not even about actual decisions we made (aside from maybe Lennart Augustsson's, where he is unhappy with details of the FTP that you can blame on us, but were designed to break the least code, instead of being the most elegant; if we had pleased him more, we would have pleased others less). They are about the reasons for founding the committee in the first place. You can blame us, if you like, because I think it's certain that we would have approved them if we had formally voted. We just didn't even need to do so. Forgive me if I'm wrong, but suggestions that these decisions should have been deferred to a Haskell Prime committee mean, to me, that the hope is that they would have been rejected. That the Haskell Prime committee should have just vetoed these proposals that something like 80% or more of practicing Haskell users (as far as we can tell) wanted for years before they finally happened. That the Haskell Prime committee should be responsible for enforcing the very status quo that led to the CLC in the first place, where proposals with broad support but minority dissent never pass for various core modules. If this is the case, then one could simply repose the earlier question: why should most of these people stick around to obey by the Haskell Prime committee's pronouncements, instead of getting to work on a language that incorporates their input? And if it isn't, then I don't ultimately understand what the complaints are. We try to accomplish the (large) changes in a manner that allows transition via refactoring over multiple versions (and as I mentioned earlier, some complaints are that we compromised _too much_ for this). And in light of the more recent complaints, it's even been decided that our time frames should be longer. Rolling up changes into a report just seems like it makes transitions less smooth. Unless the idea is to make GHC capable of switching out entire base library sets; but someone has to implement that, and once you have it, it makes the report specifications _less_ essential. Anyhow, that's my history lesson. Take it as you (all) will. Cheers, -- Dan On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland wrote: > On 10/21/2015 07:30 AM, Simon Peyton Jones wrote: >> Friends >> >> I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future. Geoff's message had some good ideas, especially this bit: >> >> | Proposal 2: After a suitable period of discussion on the libraries list, the >> | Core Libraries Committee will summarize the arguments for and against a >> | proposal and post it, along with a (justified) preliminary decision, to a >> | low-traffic, announce-only email list. After another suitable period of >> | discussion, they will issue a final decision. What is a suitable period of >> | time? Perhaps that depends on the properties of the proposal, such as >> | whether it breaks backwards compatibility. >> >> Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing. I believe that the Core Libraries committee is thinking actively about this. >> >> | Personally, I think AMP was the right thing to do, but I don't think FTP was >> | the right thing. >> >> These make good examples to motivate future changes to our process. But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above. We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction. In a big community, even a broad consultation may yield a result that some think is ill-advised. That's part of the joyful burden of being a big community. >> >> Let's look forward, not back. I think we can do better in future than we have done in the past. I don't think we can hope for unanimity, but I think we can reasonably seek >> >> * transparency; >> * clarity about what decisions are on the table; >> * broad consultation about decisions that affect >> a broad constituency; and >> * a decent opportunity to debate them without having >> to be involved in massive email threads. Let's try do to that. >> >> Simon >> >> PS: For what it's worth I'm less keen on Geoff's other proposal: >> >> | Proposal 3: A decision regarding any proposal that significantly affects >> | backwards compatibility is within the purview of the Haskell Prime >> | Committee, not the Core Libraries Committee. >> >> *Precisely* the same issues will arise whether it's CLC or HPC. And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it. > > For the record, I am also not sure Proposal 3 is a good idea :) > > However, I do think we could clarify what the respective > responsibilities of the core libraries committee and Haskell Prime > committees are. > > One possible choice is that the core libraries committee is responsible > for changes to the core libraries that do not affect libraries in the > report. It is meant to be nimble, able to quickly deal with the large > volume of library changes that do not impact backwards compatibility. > > In this scenario, the Haskell Prime committee, using a longer > deliberative process, would consider the more impactful library changes > and batch them up into new reports. > > You are absolutely correct that moving the question to the Haskell Prime > committee risks pushing the issue around. The idea behind the separation > outlined above is to reduce the treadmill; the two bodies use different > processes, with different time frames, to arrive at decisions. Some > library decisions may deserve a longer deliberative process. > > Cheers, > Geoff > _______________________________________________ > Libraries mailing list > Libraries at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From carter.schonwald at gmail.com Wed Oct 21 21:48:23 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 21 Oct 2015 17:48:23 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> Message-ID: Well said! I do have a small worry that the longer roll out window will be harder to manage given that every thing is done by (outstanding) volunteers. But maybe the answer there is that ghc should do major version releases more frequently :), eg every 9 months instead of every 12! ? On Wednesday, October 21, 2015, Dan Doel wrote: > Hello, > > I'm Dan Doel. I'm on the core libraries committee (though I'm speaking > only for myself). As I recall, one of the reasons I got tapped for it > was due to my having some historical knowledge about Haskell; not > because I was there, but because I've gone back and looked at some old > reports and whatnot (and sometimes think they're better than what we > have now). > > But, I was around (of course) when the core libraries committee > started up, so perhaps I can play the role of historian for this as > well. > > The reason the committee exists is because a couple years ago, people > brought up the ideas that were finally realized in the > Applicative-Monad proposal and the Foldable-Traversable proposal. A > lot of people weighed in saying they thought they were a good idea, > and significantly fewer people weighed in saying they thought that it > shouldn't happen for various reasons---roughly the same things that > people are still bringing up about these proposals. > > This wasn't the first time that happened, either. I think it was > widely agreed among most users that Functor should be a superclass of > Monad since I started learning Haskell around 10 years ago. And once > Applicative was introduced, it was agreed that that should go in the > middle of the two. But it appeared that it would never happen, despite > a significant majority thinking it should, because no one wanted to do > anything without pretty much unanimous consent. > > So, one question that got raised is: why should this majority of > people even use Haskell/GHC anymore? Why shouldn't they start using > some other language that will let them change 15-year-old mistakes, or > adapt to ideas that weren't even available at that time (but are still > fairly old and established, all things considered). And the answer was > that there should be some body empowered to decide to move forward > with these ideas, even if there is some dissent. And frankly, it > wasn't going to be the prime committee, because it hadn't shown any > activity in something like 3 years at the time, and even when it was > active, it didn't make anywhere near the sort of changes that were > being discussed. > > And the kicker to me is, many things that people are complaining about > again (e.g. the FTP) were the very things that the committee was > established to execute. I don't think we had a formal vote on that > proposal, because we didn't need to. Our existence was in part to > execute that proposal (and AMP). And then a year ago, when it was > finally time to release the changes, there was another ruckus. And we > still didn't have a CLC vote on the matter. What we did was conduct a > community poll, and then SPJ reviewed the submissions. But I don't > mean to pass the buck to him, because I'm pretty sure he was worried > that we were crazy, and overstepping our bounds. Just, the results of > the survey were sufficient for him to not overrule us. > > So my point is this: there seems to be some sentiment that the core > libraries committee is unsound, and making bad decisions. But the > complaints are mostly not even about actual decisions we made (aside > from maybe Lennart Augustsson's, where he is unhappy with details of > the FTP that you can blame on us, but were designed to break the least > code, instead of being the most elegant; if we had pleased him more, > we would have pleased others less). They are about the reasons for > founding the committee in the first place. You can blame us, if you > like, because I think it's certain that we would have approved them if > we had formally voted. We just didn't even need to do so. > > Forgive me if I'm wrong, but suggestions that these decisions should > have been deferred to a Haskell Prime committee mean, to me, that the > hope is that they would have been rejected. That the Haskell Prime > committee should have just vetoed these proposals that something like > 80% or more of practicing Haskell users (as far as we can tell) wanted > for years before they finally happened. That the Haskell Prime > committee should be responsible for enforcing the very status quo that > led to the CLC in the first place, where proposals with broad support > but minority dissent never pass for various core modules. > > If this is the case, then one could simply repose the earlier > question: why should most of these people stick around to obey by the > Haskell Prime committee's pronouncements, instead of getting to work > on a language that incorporates their input? > > And if it isn't, then I don't ultimately understand what the > complaints are. We try to accomplish the (large) changes in a manner > that allows transition via refactoring over multiple versions (and as > I mentioned earlier, some complaints are that we compromised _too > much_ for this). And in light of the more recent complaints, it's even > been decided that our time frames should be longer. Rolling up changes > into a report just seems like it makes transitions less smooth. Unless > the idea is to make GHC capable of switching out entire base library > sets; but someone has to implement that, and once you have it, it > makes the report specifications _less_ essential. > > Anyhow, that's my history lesson. Take it as you (all) will. > > Cheers, > -- Dan > > On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland > > wrote: > > On 10/21/2015 07:30 AM, Simon Peyton Jones wrote: > >> Friends > >> > >> I think it's good for us to debate the question of how we should > balance innovation against change; and how we should make those decisions > in future. Geoff's message had some good ideas, especially this bit: > >> > >> | Proposal 2: After a suitable period of discussion on the libraries > list, the > >> | Core Libraries Committee will summarize the arguments for and > against a > >> | proposal and post it, along with a (justified) preliminary decision, > to a > >> | low-traffic, announce-only email list. After another suitable period > of > >> | discussion, they will issue a final decision. What is a suitable > period of > >> | time? Perhaps that depends on the properties of the proposal, such as > >> | whether it breaks backwards compatibility. > >> > >> Identifying major changes to the libraries, and having a better > publicised, more RFC-like process for deliberating them, would be a good > thing. I believe that the Core Libraries committee is thinking actively > about this. > >> > >> | Personally, I think AMP was the right thing to do, but I don't think > FTP was > >> | the right thing. > >> > >> These make good examples to motivate future changes to our process. > But in the end FTP was subject to a pretty broad deliberative process, > precisely along the lines that Geoff suggests above. We had two > clearly-articulated alternatives, a discrete call for opinions broadcast to > every Haskell channel we could find, a decent interval for people to > respond, and (as it turned out) a very clear preponderance of opinion in > one direction. In a big community, even a broad consultation may yield a > result that some think is ill-advised. That's part of the joyful burden of > being a big community. > >> > >> Let's look forward, not back. I think we can do better in future than > we have done in the past. I don't think we can hope for unanimity, but I > think we can reasonably seek > >> > >> * transparency; > >> * clarity about what decisions are on the table; > >> * broad consultation about decisions that affect > >> a broad constituency; and > >> * a decent opportunity to debate them without having > >> to be involved in massive email threads. Let's try do to that. > >> > >> Simon > >> > >> PS: For what it's worth I'm less keen on Geoff's other proposal: > >> > >> | Proposal 3: A decision regarding any proposal that significantly > affects > >> | backwards compatibility is within the purview of the Haskell Prime > >> | Committee, not the Core Libraries Committee. > >> > >> *Precisely* the same issues will arise whether it's CLC or HPC. And > the HPC is going to be jolly busy with language issues. Moving the question > from one group to another risks avoiding the issue rather than addressing > it. > > > > For the record, I am also not sure Proposal 3 is a good idea :) > > > > However, I do think we could clarify what the respective > > responsibilities of the core libraries committee and Haskell Prime > > committees are. > > > > One possible choice is that the core libraries committee is responsible > > for changes to the core libraries that do not affect libraries in the > > report. It is meant to be nimble, able to quickly deal with the large > > volume of library changes that do not impact backwards compatibility. > > > > In this scenario, the Haskell Prime committee, using a longer > > deliberative process, would consider the more impactful library changes > > and batch them up into new reports. > > > > You are absolutely correct that moving the question to the Haskell Prime > > committee risks pushing the issue around. The idea behind the separation > > outlined above is to reduce the treadmill; the two bodies use different > > processes, with different time frames, to arrive at decisions. Some > > library decisions may deserve a longer deliberative process. > > > > Cheers, > > Geoff > > _______________________________________________ > > Libraries mailing list > > Libraries at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Oct 21 21:48:59 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 21 Oct 2015 21:48:59 +0000 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> Message-ID: <0b12e5e1ed6349cc8c63d5783fefae29@DB4PR30MB030.064d.mgd.msft.net> While we are here, let me say A BIG THANK YOU TO THE CORE LIBRARIES COMMITTEE Library design has a lot of detail, and a lot of competing priorities. I am personally very grateful to the CLC for the work they put into this. Like many crucial tasks it's one that often seems to attract more complaints than thanks, but they are doing us all a huge service, and at significant cost in terms of their most precious and inelastic commodity: their personal time. Remember, as Dan says, before the CLC we no process whatsoever for library evolution... various people made various patches, and there was no way of getting anything substantial done. So we are far far further on than before. Still not perfect, as my last post said. But still: THANK YOU. Simon | -----Original Message----- | From: Dan Doel [mailto:dan.doel at gmail.com] | Sent: 21 October 2015 22:23 | To: Geoffrey Mainland | Cc: Simon Peyton Jones; Augustsson, Lennart; Henrik Nilsson; haskell- | prime at haskell.org List; Haskell Libraries | Subject: Re: Breaking Changes and Long Term Support Haskell | | Hello, | | I'm Dan Doel. I'm on the core libraries committee (though I'm speaking | only for myself). As I recall, one of the reasons I got tapped for it | was due to my having some historical knowledge about Haskell; not | because I was there, but because I've gone back and looked at some old | reports and whatnot (and sometimes think they're better than what we | have now). | | But, I was around (of course) when the core libraries committee | started up, so perhaps I can play the role of historian for this as | well. | | The reason the committee exists is because a couple years ago, people | brought up the ideas that were finally realized in the | Applicative-Monad proposal and the Foldable-Traversable proposal. A | lot of people weighed in saying they thought they were a good idea, | and significantly fewer people weighed in saying they thought that it | shouldn't happen for various reasons---roughly the same things that | people are still bringing up about these proposals. | | This wasn't the first time that happened, either. I think it was | widely agreed among most users that Functor should be a superclass of | Monad since I started learning Haskell around 10 years ago. And once | Applicative was introduced, it was agreed that that should go in the | middle of the two. But it appeared that it would never happen, despite | a significant majority thinking it should, because no one wanted to do | anything without pretty much unanimous consent. | | So, one question that got raised is: why should this majority of | people even use Haskell/GHC anymore? Why shouldn't they start using | some other language that will let them change 15-year-old mistakes, or | adapt to ideas that weren't even available at that time (but are still | fairly old and established, all things considered). And the answer was | that there should be some body empowered to decide to move forward | with these ideas, even if there is some dissent. And frankly, it | wasn't going to be the prime committee, because it hadn't shown any | activity in something like 3 years at the time, and even when it was | active, it didn't make anywhere near the sort of changes that were | being discussed. | | And the kicker to me is, many things that people are complaining about | again (e.g. the FTP) were the very things that the committee was | established to execute. I don't think we had a formal vote on that | proposal, because we didn't need to. Our existence was in part to | execute that proposal (and AMP). And then a year ago, when it was | finally time to release the changes, there was another ruckus. And we | still didn't have a CLC vote on the matter. What we did was conduct a | community poll, and then SPJ reviewed the submissions. But I don't | mean to pass the buck to him, because I'm pretty sure he was worried | that we were crazy, and overstepping our bounds. Just, the results of | the survey were sufficient for him to not overrule us. | | So my point is this: there seems to be some sentiment that the core | libraries committee is unsound, and making bad decisions. But the | complaints are mostly not even about actual decisions we made (aside | from maybe Lennart Augustsson's, where he is unhappy with details of | the FTP that you can blame on us, but were designed to break the least | code, instead of being the most elegant; if we had pleased him more, | we would have pleased others less). They are about the reasons for | founding the committee in the first place. You can blame us, if you | like, because I think it's certain that we would have approved them if | we had formally voted. We just didn't even need to do so. | | Forgive me if I'm wrong, but suggestions that these decisions should | have been deferred to a Haskell Prime committee mean, to me, that the | hope is that they would have been rejected. That the Haskell Prime | committee should have just vetoed these proposals that something like | 80% or more of practicing Haskell users (as far as we can tell) wanted | for years before they finally happened. That the Haskell Prime | committee should be responsible for enforcing the very status quo that | led to the CLC in the first place, where proposals with broad support | but minority dissent never pass for various core modules. | | If this is the case, then one could simply repose the earlier | question: why should most of these people stick around to obey by the | Haskell Prime committee's pronouncements, instead of getting to work | on a language that incorporates their input? | | And if it isn't, then I don't ultimately understand what the | complaints are. We try to accomplish the (large) changes in a manner | that allows transition via refactoring over multiple versions (and as | I mentioned earlier, some complaints are that we compromised _too | much_ for this). And in light of the more recent complaints, it's even | been decided that our time frames should be longer. Rolling up changes | into a report just seems like it makes transitions less smooth. Unless | the idea is to make GHC capable of switching out entire base library | sets; but someone has to implement that, and once you have it, it | makes the report specifications _less_ essential. | | Anyhow, that's my history lesson. Take it as you (all) will. | | Cheers, | -- Dan | | On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland | wrote: | > On 10/21/2015 07:30 AM, Simon Peyton Jones wrote: | >> Friends | >> | >> I think it's good for us to debate the question of how we should | balance innovation against change; and how we should make those decisions | in future. Geoff's message had some good ideas, especially this bit: | >> | >> | Proposal 2: After a suitable period of discussion on the libraries | list, the | >> | Core Libraries Committee will summarize the arguments for and | against a | >> | proposal and post it, along with a (justified) preliminary decision, | to a | >> | low-traffic, announce-only email list. After another suitable period | of | >> | discussion, they will issue a final decision. What is a suitable | period of | >> | time? Perhaps that depends on the properties of the proposal, such | as | >> | whether it breaks backwards compatibility. | >> | >> Identifying major changes to the libraries, and having a better | publicised, more RFC-like process for deliberating them, would be a good | thing. I believe that the Core Libraries committee is thinking actively | about this. | >> | >> | Personally, I think AMP was the right thing to do, but I don't think | FTP was | >> | the right thing. | >> | >> These make good examples to motivate future changes to our process. | But in the end FTP was subject to a pretty broad deliberative process, | precisely along the lines that Geoff suggests above. We had two clearly- | articulated alternatives, a discrete call for opinions broadcast to every | Haskell channel we could find, a decent interval for people to respond, | and (as it turned out) a very clear preponderance of opinion in one | direction. In a big community, even a broad consultation may yield a | result that some think is ill-advised. That's part of the joyful burden | of being a big community. | >> | >> Let's look forward, not back. I think we can do better in future than | we have done in the past. I don't think we can hope for unanimity, but I | think we can reasonably seek | >> | >> * transparency; | >> * clarity about what decisions are on the table; | >> * broad consultation about decisions that affect | >> a broad constituency; and | >> * a decent opportunity to debate them without having | >> to be involved in massive email threads. Let's try do to that. | >> | >> Simon | >> | >> PS: For what it's worth I'm less keen on Geoff's other proposal: | >> | >> | Proposal 3: A decision regarding any proposal that significantly | affects | >> | backwards compatibility is within the purview of the Haskell Prime | >> | Committee, not the Core Libraries Committee. | >> | >> *Precisely* the same issues will arise whether it's CLC or HPC. And | the HPC is going to be jolly busy with language issues. Moving the | question from one group to another risks avoiding the issue rather than | addressing it. | > | > For the record, I am also not sure Proposal 3 is a good idea :) | > | > However, I do think we could clarify what the respective | > responsibilities of the core libraries committee and Haskell Prime | > committees are. | > | > One possible choice is that the core libraries committee is responsible | > for changes to the core libraries that do not affect libraries in the | > report. It is meant to be nimble, able to quickly deal with the large | > volume of library changes that do not impact backwards compatibility. | > | > In this scenario, the Haskell Prime committee, using a longer | > deliberative process, would consider the more impactful library changes | > and batch them up into new reports. | > | > You are absolutely correct that moving the question to the Haskell Prime | > committee risks pushing the issue around. The idea behind the separation | > outlined above is to reduce the treadmill; the two bodies use different | > processes, with different time frames, to arrive at decisions. Some | > library decisions may deserve a longer deliberative process. | > | > Cheers, | > Geoff | > _______________________________________________ | > Libraries mailing list | > Libraries at haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske | ll.org%2fcgi- | bin%2fmailman%2flistinfo%2flibraries&data=01%7c01%7csimonpj%40064d.mgd.mic | rosoft.com%7c6e0a5cbb4f5541caf14108d2da5dc7f8%7c72f988bf86f141af91ab2d7cd0 | 11db47%7c1&sdata=zL3zfXigvfpvdXL%2bhWuGoQzUUhGp%2bg8ofO1tGaFzlvE%3d From simonpj at microsoft.com Wed Oct 21 22:17:12 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 21 Oct 2015 22:17:12 +0000 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <5627A4A8.7070107@apeiron.net> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> Message-ID: | For the record, I am also not sure Proposal 3 is a good idea :) | | However, I do think we could clarify what the respective | responsibilities of the core libraries committee and Haskell Prime | committees are. My instinct is this: Haskell Prime: language Core Libraries Committee: libraries That seems simple. If we try to move the largest and most challenging library design tasks from CLC to HP, I fear that we will overload the latter and devalue the former. | You are absolutely correct that moving the question to the Haskell Prime | committee risks pushing the issue around. The idea behind the separation | outlined above is to reduce the treadmill; the two bodies use different | processes, with different time frames, to arrive at decisions. Some | library decisions may deserve a longer deliberative process. I do agree that some library changes are far-reaching, and need a more deliberative process. I think the CLC is in the process of developing such a process. Moreover, I trust them to be able to tell the difference between low-impact and high-impact changes. That said, as HP moves towards a new language Report, it would be good if CLC similarly moved towards a new libraries Report, so that there was a single unified document, just as we have had to date. Simon From mainland at apeiron.net Wed Oct 21 22:18:34 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Wed, 21 Oct 2015 18:18:34 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> Message-ID: <56280F3A.7070902@apeiron.net> Hi Dan, Thank you for the historical perspective. I was careful not to criticize the committee. Instead, I made three concrete proposals with the hope that they would help orient a conversation. It sounds like you are not for proposal 3. How about the other two? My original email stated my underlying concern: we are losing valuable members of the community not because of the technical decisions that are being made, but because of the process by which they are being made. That concern is what drove my proposals. It is perfectly valid to think that that loss was the inevitable price of progress, but that is not my view. Cheers, Geoff On 10/21/15 5:22 PM, Dan Doel wrote: > Hello, > > I'm Dan Doel. I'm on the core libraries committee (though I'm speaking > only for myself). As I recall, one of the reasons I got tapped for it > was due to my having some historical knowledge about Haskell; not > because I was there, but because I've gone back and looked at some old > reports and whatnot (and sometimes think they're better than what we > have now). > > But, I was around (of course) when the core libraries committee > started up, so perhaps I can play the role of historian for this as > well. > > The reason the committee exists is because a couple years ago, people > brought up the ideas that were finally realized in the > Applicative-Monad proposal and the Foldable-Traversable proposal. A > lot of people weighed in saying they thought they were a good idea, > and significantly fewer people weighed in saying they thought that it > shouldn't happen for various reasons---roughly the same things that > people are still bringing up about these proposals. > > This wasn't the first time that happened, either. I think it was > widely agreed among most users that Functor should be a superclass of > Monad since I started learning Haskell around 10 years ago. And once > Applicative was introduced, it was agreed that that should go in the > middle of the two. But it appeared that it would never happen, despite > a significant majority thinking it should, because no one wanted to do > anything without pretty much unanimous consent. > > So, one question that got raised is: why should this majority of > people even use Haskell/GHC anymore? Why shouldn't they start using > some other language that will let them change 15-year-old mistakes, or > adapt to ideas that weren't even available at that time (but are still > fairly old and established, all things considered). And the answer was > that there should be some body empowered to decide to move forward > with these ideas, even if there is some dissent. And frankly, it > wasn't going to be the prime committee, because it hadn't shown any > activity in something like 3 years at the time, and even when it was > active, it didn't make anywhere near the sort of changes that were > being discussed. > > And the kicker to me is, many things that people are complaining about > again (e.g. the FTP) were the very things that the committee was > established to execute. I don't think we had a formal vote on that > proposal, because we didn't need to. Our existence was in part to > execute that proposal (and AMP). And then a year ago, when it was > finally time to release the changes, there was another ruckus. And we > still didn't have a CLC vote on the matter. What we did was conduct a > community poll, and then SPJ reviewed the submissions. But I don't > mean to pass the buck to him, because I'm pretty sure he was worried > that we were crazy, and overstepping our bounds. Just, the results of > the survey were sufficient for him to not overrule us. > > So my point is this: there seems to be some sentiment that the core > libraries committee is unsound, and making bad decisions. But the > complaints are mostly not even about actual decisions we made (aside > from maybe Lennart Augustsson's, where he is unhappy with details of > the FTP that you can blame on us, but were designed to break the least > code, instead of being the most elegant; if we had pleased him more, > we would have pleased others less). They are about the reasons for > founding the committee in the first place. You can blame us, if you > like, because I think it's certain that we would have approved them if > we had formally voted. We just didn't even need to do so. > > Forgive me if I'm wrong, but suggestions that these decisions should > have been deferred to a Haskell Prime committee mean, to me, that the > hope is that they would have been rejected. That the Haskell Prime > committee should have just vetoed these proposals that something like > 80% or more of practicing Haskell users (as far as we can tell) wanted > for years before they finally happened. That the Haskell Prime > committee should be responsible for enforcing the very status quo that > led to the CLC in the first place, where proposals with broad support > but minority dissent never pass for various core modules. > > If this is the case, then one could simply repose the earlier > question: why should most of these people stick around to obey by the > Haskell Prime committee's pronouncements, instead of getting to work > on a language that incorporates their input? > > And if it isn't, then I don't ultimately understand what the > complaints are. We try to accomplish the (large) changes in a manner > that allows transition via refactoring over multiple versions (and as > I mentioned earlier, some complaints are that we compromised _too > much_ for this). And in light of the more recent complaints, it's even > been decided that our time frames should be longer. Rolling up changes > into a report just seems like it makes transitions less smooth. Unless > the idea is to make GHC capable of switching out entire base library > sets; but someone has to implement that, and once you have it, it > makes the report specifications _less_ essential. > > Anyhow, that's my history lesson. Take it as you (all) will. > > Cheers, > -- Dan > > On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland > wrote: >> On 10/21/2015 07:30 AM, Simon Peyton Jones wrote: >>> Friends >>> >>> I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future. Geoff's message had some good ideas, especially this bit: >>> >>> | Proposal 2: After a suitable period of discussion on the libraries list, the >>> | Core Libraries Committee will summarize the arguments for and against a >>> | proposal and post it, along with a (justified) preliminary decision, to a >>> | low-traffic, announce-only email list. After another suitable period of >>> | discussion, they will issue a final decision. What is a suitable period of >>> | time? Perhaps that depends on the properties of the proposal, such as >>> | whether it breaks backwards compatibility. >>> >>> Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing. I believe that the Core Libraries committee is thinking actively about this. >>> >>> | Personally, I think AMP was the right thing to do, but I don't think FTP was >>> | the right thing. >>> >>> These make good examples to motivate future changes to our process. But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above. We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction. In a big community, even a broad consultation may yield a result that some think is ill-advised. That's part of the joyful burden of being a big community. >>> >>> Let's look forward, not back. I think we can do better in future than we have done in the past. I don't think we can hope for unanimity, but I think we can reasonably seek >>> >>> * transparency; >>> * clarity about what decisions are on the table; >>> * broad consultation about decisions that affect >>> a broad constituency; and >>> * a decent opportunity to debate them without having >>> to be involved in massive email threads. Let's try do to that. >>> >>> Simon >>> >>> PS: For what it's worth I'm less keen on Geoff's other proposal: >>> >>> | Proposal 3: A decision regarding any proposal that significantly affects >>> | backwards compatibility is within the purview of the Haskell Prime >>> | Committee, not the Core Libraries Committee. >>> >>> *Precisely* the same issues will arise whether it's CLC or HPC. And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it. >> For the record, I am also not sure Proposal 3 is a good idea :) >> >> However, I do think we could clarify what the respective >> responsibilities of the core libraries committee and Haskell Prime >> committees are. >> >> One possible choice is that the core libraries committee is responsible >> for changes to the core libraries that do not affect libraries in the >> report. It is meant to be nimble, able to quickly deal with the large >> volume of library changes that do not impact backwards compatibility. >> >> In this scenario, the Haskell Prime committee, using a longer >> deliberative process, would consider the more impactful library changes >> and batch them up into new reports. >> >> You are absolutely correct that moving the question to the Haskell Prime >> committee risks pushing the issue around. The idea behind the separation >> outlined above is to reduce the treadmill; the two bodies use different >> processes, with different time frames, to arrive at decisions. Some >> library decisions may deserve a longer deliberative process. >> >> Cheers, >> Geoff >> _______________________________________________ >> Libraries mailing list >> Libraries at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries From Henrik.Nilsson at nottingham.ac.uk Wed Oct 21 23:09:57 2015 From: Henrik.Nilsson at nottingham.ac.uk (Henrik Nilsson) Date: Thu, 22 Oct 2015 00:09:57 +0100 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> Message-ID: <56281B45.8030708@nottingham.ac.uk> Hi Dan, Thanks for the history lesson. You do make many valid points. And I also want to say thank you for the hard work that CLC has put in. Let me nevertheless react to a handful of things: > And the answer was that there should be some body empowered to decide > to move forward with these ideas, even if there is some dissent. And > frankly, it wasn't going to be the prime committee, because it hadn't > shown any activity in something like 3 years at the time, and even > when it was active, it didn't make anywhere near the sort of changes > that were being discussed. I have seen criticism of the Haskell committee along similar lines before, but I think it is overly simplistic, and arguably unfair, for two reasons. First, squarely measuring accomplishment in terms of number or scope of changes, which seems to be the gist (apologies if I misunderstand), is, frankly, naive. In many ways, what didn't change, for example, can be at least as important as what did for establishing a language as a viable and attractive proposition for large scale work. And the value of that for a language community as a whole is hard to overstate. Now, I have no real data to back up that the committee achieved that. But it is clear that Haskell has grown a lot over the past 5 to 10 years, i.e. well before AMP, FTP, etc. So maybe the last instance of the Haskell committee actually achieved a great deal more than some seem willing to give it credit for. Secondly, let us not forget that at least one highly controversial and very breaking change was adopted for Haskell 2010: dropping n + k patterns. The reason that went through was that there were very compelling technical reasons and ultimately a clear case for the advantages outweighing the disadvantages by a wide margin. So it is not as if a committee cannot make controversial decisions. That does presuppose that the majority of its members fundamentally have the interest of the community at large at the fore, and are willing to take good arguments aboard, rather than being prone to take stances mainly for "political" reasons. Fortunately, I strongly believe the Haskell community by and large is rational in this sense. > Forgive me if I'm wrong, but suggestions that these decisions should > have been deferred to a Haskell Prime committee mean, to me, that the > hope is that they would have been rejected. OK, you are forgiven! I can of course only speak for myself, but I have followed this discussion very carefully, and discussed with many people in person. And as far as I can tell, there is absolutely nothing to suggest that the reason that those who are unhappy with the process by which AMP, FTP etc. happened (or by some of the details of those proposals) raise the possibility that the Haskell committee in one way or another should have been (or in the future be) involved at least as a vetting instance when it comes to the most far-reaching library changes, is a secret hope of "death by committee". Anyway, whether there are one or two committees ultimately does not really matter, as long as both are widely seen to have a wide mandate for whatever they are entrusted with, and as long as the process for far-reaching changes is sufficiently robust and long. > That the Haskell Prime > committee should have just vetoed these proposals that something like > 80% or more of practicing Haskell users (as far as we can tell) wanted > for years before they finally happened. Now, I have no desire to diminish the significance of the outcome of that poll. Nor have I any desire to be branded as an "anti-democrat". But if I am, so be it: I am bracing myself. However, I have to point out that there is a lot more to well-functioning democracies than simple majority votes. Look at any developed democracy and there are lots of checks and balances in place to safe-guard the interests of an as broad part of the population as possible. In a federated state, just to give one example, there is often a bicameral parliament where the states (broadly) have equal say in one of the chambers irrespective of their size. And yes, the workings of democracies are slow, sometimes painfully so, but fundamentally that is for good reason. To return to the case of a programming language community, it is pretty much by definition going to be the case that a small part of that community will be hit disproportionately hard by changes to the language and/or its core libraries. Their interests need to be adequately safeguarded too, or they will surely jump ship in search of high and dry ground rather than run the risk of drowning in the next wave of changes. This, to the best of my understanding, is where I and others who are suggesting that far-reaching changes should go past a committee with a clear mandate and a sufficiently robust and long process are coming from. And I believe this is also what underlies Lennart's sentiment: > I think voting to decide these kind of issues a terrible idea; we > might as well throw dice. Best, /Henrik -- Henrik Nilsson School of Computer Science The University of Nottingham nhn at cs.nott.ac.uk 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 Wed Oct 21 23:26:59 2015 From: tonymorris at gmail.com (Tony Morris) Date: Thu, 22 Oct 2015 09:26:59 +1000 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <0b12e5e1ed6349cc8c63d5783fefae29@DB4PR30MB030.064d.mgd.msft.net> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <0b12e5e1ed6349cc8c63d5783fefae29@DB4PR30MB030.064d.mgd.msft.net> Message-ID: <56281F43.2030308@gmail.com> Thanks Dan and others on CLC for your hard work and endurance. On 22/10/15 07:48, Simon Peyton Jones wrote: > While we are here, let me say > > A BIG THANK YOU TO THE CORE LIBRARIES COMMITTEE > > Library design has a lot of detail, and a lot of competing priorities. I am personally very grateful to the CLC for the work they put into this. Like many crucial tasks it's one that often seems to attract more complaints than thanks, but they are doing us all a huge service, and at significant cost in terms of their most precious and inelastic commodity: their personal time. > > Remember, as Dan says, before the CLC we no process whatsoever for library evolution... various people made various patches, and there was no way of getting anything substantial done. So we are far far further on than before. > > Still not perfect, as my last post said. But still: THANK YOU. > > Simon > > | -----Original Message----- > | From: Dan Doel [mailto:dan.doel at gmail.com] > | Sent: 21 October 2015 22:23 > | To: Geoffrey Mainland > | Cc: Simon Peyton Jones; Augustsson, Lennart; Henrik Nilsson; haskell- > | prime at haskell.org List; Haskell Libraries > | Subject: Re: Breaking Changes and Long Term Support Haskell > | > | Hello, > | > | I'm Dan Doel. I'm on the core libraries committee (though I'm speaking > | only for myself). As I recall, one of the reasons I got tapped for it > | was due to my having some historical knowledge about Haskell; not > | because I was there, but because I've gone back and looked at some old > | reports and whatnot (and sometimes think they're better than what we > | have now). > | > | But, I was around (of course) when the core libraries committee > | started up, so perhaps I can play the role of historian for this as > | well. > | > | The reason the committee exists is because a couple years ago, people > | brought up the ideas that were finally realized in the > | Applicative-Monad proposal and the Foldable-Traversable proposal. A > | lot of people weighed in saying they thought they were a good idea, > | and significantly fewer people weighed in saying they thought that it > | shouldn't happen for various reasons---roughly the same things that > | people are still bringing up about these proposals. > | > | This wasn't the first time that happened, either. I think it was > | widely agreed among most users that Functor should be a superclass of > | Monad since I started learning Haskell around 10 years ago. And once > | Applicative was introduced, it was agreed that that should go in the > | middle of the two. But it appeared that it would never happen, despite > | a significant majority thinking it should, because no one wanted to do > | anything without pretty much unanimous consent. > | > | So, one question that got raised is: why should this majority of > | people even use Haskell/GHC anymore? Why shouldn't they start using > | some other language that will let them change 15-year-old mistakes, or > | adapt to ideas that weren't even available at that time (but are still > | fairly old and established, all things considered). And the answer was > | that there should be some body empowered to decide to move forward > | with these ideas, even if there is some dissent. And frankly, it > | wasn't going to be the prime committee, because it hadn't shown any > | activity in something like 3 years at the time, and even when it was > | active, it didn't make anywhere near the sort of changes that were > | being discussed. > | > | And the kicker to me is, many things that people are complaining about > | again (e.g. the FTP) were the very things that the committee was > | established to execute. I don't think we had a formal vote on that > | proposal, because we didn't need to. Our existence was in part to > | execute that proposal (and AMP). And then a year ago, when it was > | finally time to release the changes, there was another ruckus. And we > | still didn't have a CLC vote on the matter. What we did was conduct a > | community poll, and then SPJ reviewed the submissions. But I don't > | mean to pass the buck to him, because I'm pretty sure he was worried > | that we were crazy, and overstepping our bounds. Just, the results of > | the survey were sufficient for him to not overrule us. > | > | So my point is this: there seems to be some sentiment that the core > | libraries committee is unsound, and making bad decisions. But the > | complaints are mostly not even about actual decisions we made (aside > | from maybe Lennart Augustsson's, where he is unhappy with details of > | the FTP that you can blame on us, but were designed to break the least > | code, instead of being the most elegant; if we had pleased him more, > | we would have pleased others less). They are about the reasons for > | founding the committee in the first place. You can blame us, if you > | like, because I think it's certain that we would have approved them if > | we had formally voted. We just didn't even need to do so. > | > | Forgive me if I'm wrong, but suggestions that these decisions should > | have been deferred to a Haskell Prime committee mean, to me, that the > | hope is that they would have been rejected. That the Haskell Prime > | committee should have just vetoed these proposals that something like > | 80% or more of practicing Haskell users (as far as we can tell) wanted > | for years before they finally happened. That the Haskell Prime > | committee should be responsible for enforcing the very status quo that > | led to the CLC in the first place, where proposals with broad support > | but minority dissent never pass for various core modules. > | > | If this is the case, then one could simply repose the earlier > | question: why should most of these people stick around to obey by the > | Haskell Prime committee's pronouncements, instead of getting to work > | on a language that incorporates their input? > | > | And if it isn't, then I don't ultimately understand what the > | complaints are. We try to accomplish the (large) changes in a manner > | that allows transition via refactoring over multiple versions (and as > | I mentioned earlier, some complaints are that we compromised _too > | much_ for this). And in light of the more recent complaints, it's even > | been decided that our time frames should be longer. Rolling up changes > | into a report just seems like it makes transitions less smooth. Unless > | the idea is to make GHC capable of switching out entire base library > | sets; but someone has to implement that, and once you have it, it > | makes the report specifications _less_ essential. > | > | Anyhow, that's my history lesson. Take it as you (all) will. > | > | Cheers, > | -- Dan > | > | On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland > | wrote: > | > On 10/21/2015 07:30 AM, Simon Peyton Jones wrote: > | >> Friends > | >> > | >> I think it's good for us to debate the question of how we should > | balance innovation against change; and how we should make those decisions > | in future. Geoff's message had some good ideas, especially this bit: > | >> > | >> | Proposal 2: After a suitable period of discussion on the libraries > | list, the > | >> | Core Libraries Committee will summarize the arguments for and > | against a > | >> | proposal and post it, along with a (justified) preliminary decision, > | to a > | >> | low-traffic, announce-only email list. After another suitable period > | of > | >> | discussion, they will issue a final decision. What is a suitable > | period of > | >> | time? Perhaps that depends on the properties of the proposal, such > | as > | >> | whether it breaks backwards compatibility. > | >> > | >> Identifying major changes to the libraries, and having a better > | publicised, more RFC-like process for deliberating them, would be a good > | thing. I believe that the Core Libraries committee is thinking actively > | about this. > | >> > | >> | Personally, I think AMP was the right thing to do, but I don't think > | FTP was > | >> | the right thing. > | >> > | >> These make good examples to motivate future changes to our process. > | But in the end FTP was subject to a pretty broad deliberative process, > | precisely along the lines that Geoff suggests above. We had two clearly- > | articulated alternatives, a discrete call for opinions broadcast to every > | Haskell channel we could find, a decent interval for people to respond, > | and (as it turned out) a very clear preponderance of opinion in one > | direction. In a big community, even a broad consultation may yield a > | result that some think is ill-advised. That's part of the joyful burden > | of being a big community. > | >> > | >> Let's look forward, not back. I think we can do better in future than > | we have done in the past. I don't think we can hope for unanimity, but I > | think we can reasonably seek > | >> > | >> * transparency; > | >> * clarity about what decisions are on the table; > | >> * broad consultation about decisions that affect > | >> a broad constituency; and > | >> * a decent opportunity to debate them without having > | >> to be involved in massive email threads. Let's try do to that. > | >> > | >> Simon > | >> > | >> PS: For what it's worth I'm less keen on Geoff's other proposal: > | >> > | >> | Proposal 3: A decision regarding any proposal that significantly > | affects > | >> | backwards compatibility is within the purview of the Haskell Prime > | >> | Committee, not the Core Libraries Committee. > | >> > | >> *Precisely* the same issues will arise whether it's CLC or HPC. And > | the HPC is going to be jolly busy with language issues. Moving the > | question from one group to another risks avoiding the issue rather than > | addressing it. > | > > | > For the record, I am also not sure Proposal 3 is a good idea :) > | > > | > However, I do think we could clarify what the respective > | > responsibilities of the core libraries committee and Haskell Prime > | > committees are. > | > > | > One possible choice is that the core libraries committee is responsible > | > for changes to the core libraries that do not affect libraries in the > | > report. It is meant to be nimble, able to quickly deal with the large > | > volume of library changes that do not impact backwards compatibility. > | > > | > In this scenario, the Haskell Prime committee, using a longer > | > deliberative process, would consider the more impactful library changes > | > and batch them up into new reports. > | > > | > You are absolutely correct that moving the question to the Haskell Prime > | > committee risks pushing the issue around. The idea behind the separation > | > outlined above is to reduce the treadmill; the two bodies use different > | > processes, with different time frames, to arrive at decisions. Some > | > library decisions may deserve a longer deliberative process. > | > > | > Cheers, > | > Geoff > | > _______________________________________________ > | > Libraries mailing list > | > Libraries at haskell.org > | > > | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske > | ll.org%2fcgi- > | bin%2fmailman%2flistinfo%2flibraries&data=01%7c01%7csimonpj%40064d.mgd.mic > | rosoft.com%7c6e0a5cbb4f5541caf14108d2da5dc7f8%7c72f988bf86f141af91ab2d7cd0 > | 11db47%7c1&sdata=zL3zfXigvfpvdXL%2bhWuGoQzUUhGp%2bg8ofO1tGaFzlvE%3d > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > From johnw at newartisans.com Wed Oct 21 23:37:44 2015 From: johnw at newartisans.com (John Wiegley) Date: Wed, 21 Oct 2015 16:37:44 -0700 Subject: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad` In-Reply-To: <56274BC2.20507@nottingham.ac.uk> (Henrik Nilsson's message of "Wed, 21 Oct 2015 09:24:34 +0100") References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> Message-ID: >>>>> Henrik Nilsson writes: > So before breaking anything more, that being code, research papers, books, > what people have learned, or even the community itself, it is time to very > carefully think about what the appropriate processes should be for going > forward. Hi Henrik, I'd really like to understand your position better, since I'm pretty sure it's not just a juxtaposition between "change" or "no change". How would you like to see Haskell grow in the future? What does a successful process to evolve the language look like to you? Is it the change causing you difficulty, or the way we arrive at the change? John From dan.doel at gmail.com Thu Oct 22 05:09:48 2015 From: dan.doel at gmail.com (Dan Doel) Date: Thu, 22 Oct 2015 01:09:48 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <56280F3A.7070902@apeiron.net> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> Message-ID: For proposal 3, I don't see what difference it makes whether a refreshed Haskell committee or a new libraries committee makes decisions that affect backwards compatibility. A name doesn't ensure good decision making. The only difference I can see is that the Haskell committee might only publish final decisions every couple years. But the Haskell report also isn't designed to describe migration plans between feature revisions; unless the plan is to start incorporating library deprecation and whatnot into the report (which would be odd to me). But that would just be doing the same thing slower, so it'd be little different than making library changes over 6 to 9 GHC versions instead of 3. For proposal 2, I don't know how effective it will be in practice. I believe it is already the job of a proposal submitter to summarize the arguments made about it, according to the library proposal guidelines. We could post those summaries to another list. But unless more people promise they will be diligent about reading that list, I'm not sure that one factor in these dust ups (surprise) will actually be any different. Also, if amount of discussion is at issue, I'm not sure I agree. For AMP, I was waiting a decade, more or less. I thought we should do it, other people thought we shouldn't because it would break things. I don't know what more there was to discuss, except there was more stuff to break the longer we waited. As for FTP, some aspects only became known as the proposal was implemented, and I don't know that they would have been realized regardless of how long the proposal were discussed. And then we still had a month or so of discussion after the implementation was finalized, on the cusp of GHC 7.10 being released. So how much more _was_ needed, that people are now discussing it again? If it's just about documenting more things, there's certainly no harm in that. For 1, I don't have a very strong opinion. If pressed, I would probably express some similar sentiments to Henrik. I certainly don't think Haskell would be nearly as good as it is if it were a simple majority vote by all users (and I probably wouldn't use it if that's how things were decided). Would a community vote for libraries committee be better than appointment by people who previously held the power (but have more to do than any human can accomplish)? I don't know. I should say, though, that things are not now run by simple majority vote. What we conducted a year ago was a survey, where people submitted their thoughts. I didn't get to read them, because they were private, and it wasn't my decision to make. But it was not just +80 -20. With regard to your last paragraph, unless I've missed something (and I confess that I haven't read every comment in these threads), the recent resignations didn't express disagreement with the decision making process. They expressed disagreement with the (technical) decisions (and their effects). I don't see how a different process could have solved that unless it is expected that it would have made different decisions. -- Dan On Wed, Oct 21, 2015 at 6:18 PM, Geoffrey Mainland wrote: > Hi Dan, > > Thank you for the historical perspective. > > I was careful not to criticize the committee. Instead, I made three > concrete proposals with the hope that they would help orient a conversation. > > It sounds like you are not for proposal 3. How about the other two? > > My original email stated my underlying concern: we are losing valuable > members of the community not because of the technical decisions that are > being made, but because of the process by which they are being made. > That concern is what drove my proposals. It is perfectly valid to think > that that loss was the inevitable price of progress, but that is not my > view. > > Cheers, > Geoff > > On 10/21/15 5:22 PM, Dan Doel wrote: >> Hello, >> >> I'm Dan Doel. I'm on the core libraries committee (though I'm speaking >> only for myself). As I recall, one of the reasons I got tapped for it >> was due to my having some historical knowledge about Haskell; not >> because I was there, but because I've gone back and looked at some old >> reports and whatnot (and sometimes think they're better than what we >> have now). >> >> But, I was around (of course) when the core libraries committee >> started up, so perhaps I can play the role of historian for this as >> well. >> >> The reason the committee exists is because a couple years ago, people >> brought up the ideas that were finally realized in the >> Applicative-Monad proposal and the Foldable-Traversable proposal. A >> lot of people weighed in saying they thought they were a good idea, >> and significantly fewer people weighed in saying they thought that it >> shouldn't happen for various reasons---roughly the same things that >> people are still bringing up about these proposals. >> >> This wasn't the first time that happened, either. I think it was >> widely agreed among most users that Functor should be a superclass of >> Monad since I started learning Haskell around 10 years ago. And once >> Applicative was introduced, it was agreed that that should go in the >> middle of the two. But it appeared that it would never happen, despite >> a significant majority thinking it should, because no one wanted to do >> anything without pretty much unanimous consent. >> >> So, one question that got raised is: why should this majority of >> people even use Haskell/GHC anymore? Why shouldn't they start using >> some other language that will let them change 15-year-old mistakes, or >> adapt to ideas that weren't even available at that time (but are still >> fairly old and established, all things considered). And the answer was >> that there should be some body empowered to decide to move forward >> with these ideas, even if there is some dissent. And frankly, it >> wasn't going to be the prime committee, because it hadn't shown any >> activity in something like 3 years at the time, and even when it was >> active, it didn't make anywhere near the sort of changes that were >> being discussed. >> >> And the kicker to me is, many things that people are complaining about >> again (e.g. the FTP) were the very things that the committee was >> established to execute. I don't think we had a formal vote on that >> proposal, because we didn't need to. Our existence was in part to >> execute that proposal (and AMP). And then a year ago, when it was >> finally time to release the changes, there was another ruckus. And we >> still didn't have a CLC vote on the matter. What we did was conduct a >> community poll, and then SPJ reviewed the submissions. But I don't >> mean to pass the buck to him, because I'm pretty sure he was worried >> that we were crazy, and overstepping our bounds. Just, the results of >> the survey were sufficient for him to not overrule us. >> >> So my point is this: there seems to be some sentiment that the core >> libraries committee is unsound, and making bad decisions. But the >> complaints are mostly not even about actual decisions we made (aside >> from maybe Lennart Augustsson's, where he is unhappy with details of >> the FTP that you can blame on us, but were designed to break the least >> code, instead of being the most elegant; if we had pleased him more, >> we would have pleased others less). They are about the reasons for >> founding the committee in the first place. You can blame us, if you >> like, because I think it's certain that we would have approved them if >> we had formally voted. We just didn't even need to do so. >> >> Forgive me if I'm wrong, but suggestions that these decisions should >> have been deferred to a Haskell Prime committee mean, to me, that the >> hope is that they would have been rejected. That the Haskell Prime >> committee should have just vetoed these proposals that something like >> 80% or more of practicing Haskell users (as far as we can tell) wanted >> for years before they finally happened. That the Haskell Prime >> committee should be responsible for enforcing the very status quo that >> led to the CLC in the first place, where proposals with broad support >> but minority dissent never pass for various core modules. >> >> If this is the case, then one could simply repose the earlier >> question: why should most of these people stick around to obey by the >> Haskell Prime committee's pronouncements, instead of getting to work >> on a language that incorporates their input? >> >> And if it isn't, then I don't ultimately understand what the >> complaints are. We try to accomplish the (large) changes in a manner >> that allows transition via refactoring over multiple versions (and as >> I mentioned earlier, some complaints are that we compromised _too >> much_ for this). And in light of the more recent complaints, it's even >> been decided that our time frames should be longer. Rolling up changes >> into a report just seems like it makes transitions less smooth. Unless >> the idea is to make GHC capable of switching out entire base library >> sets; but someone has to implement that, and once you have it, it >> makes the report specifications _less_ essential. >> >> Anyhow, that's my history lesson. Take it as you (all) will. >> >> Cheers, >> -- Dan >> >> On Wed, Oct 21, 2015 at 10:43 AM, Geoffrey Mainland >> wrote: >>> On 10/21/2015 07:30 AM, Simon Peyton Jones wrote: >>>> Friends >>>> >>>> I think it's good for us to debate the question of how we should balance innovation against change; and how we should make those decisions in future. Geoff's message had some good ideas, especially this bit: >>>> >>>> | Proposal 2: After a suitable period of discussion on the libraries list, the >>>> | Core Libraries Committee will summarize the arguments for and against a >>>> | proposal and post it, along with a (justified) preliminary decision, to a >>>> | low-traffic, announce-only email list. After another suitable period of >>>> | discussion, they will issue a final decision. What is a suitable period of >>>> | time? Perhaps that depends on the properties of the proposal, such as >>>> | whether it breaks backwards compatibility. >>>> >>>> Identifying major changes to the libraries, and having a better publicised, more RFC-like process for deliberating them, would be a good thing. I believe that the Core Libraries committee is thinking actively about this. >>>> >>>> | Personally, I think AMP was the right thing to do, but I don't think FTP was >>>> | the right thing. >>>> >>>> These make good examples to motivate future changes to our process. But in the end FTP was subject to a pretty broad deliberative process, precisely along the lines that Geoff suggests above. We had two clearly-articulated alternatives, a discrete call for opinions broadcast to every Haskell channel we could find, a decent interval for people to respond, and (as it turned out) a very clear preponderance of opinion in one direction. In a big community, even a broad consultation may yield a result that some think is ill-advised. That's part of the joyful burden of being a big community. >>>> >>>> Let's look forward, not back. I think we can do better in future than we have done in the past. I don't think we can hope for unanimity, but I think we can reasonably seek >>>> >>>> * transparency; >>>> * clarity about what decisions are on the table; >>>> * broad consultation about decisions that affect >>>> a broad constituency; and >>>> * a decent opportunity to debate them without having >>>> to be involved in massive email threads. Let's try do to that. >>>> >>>> Simon >>>> >>>> PS: For what it's worth I'm less keen on Geoff's other proposal: >>>> >>>> | Proposal 3: A decision regarding any proposal that significantly affects >>>> | backwards compatibility is within the purview of the Haskell Prime >>>> | Committee, not the Core Libraries Committee. >>>> >>>> *Precisely* the same issues will arise whether it's CLC or HPC. And the HPC is going to be jolly busy with language issues. Moving the question from one group to another risks avoiding the issue rather than addressing it. >>> For the record, I am also not sure Proposal 3 is a good idea :) >>> >>> However, I do think we could clarify what the respective >>> responsibilities of the core libraries committee and Haskell Prime >>> committees are. >>> >>> One possible choice is that the core libraries committee is responsible >>> for changes to the core libraries that do not affect libraries in the >>> report. It is meant to be nimble, able to quickly deal with the large >>> volume of library changes that do not impact backwards compatibility. >>> >>> In this scenario, the Haskell Prime committee, using a longer >>> deliberative process, would consider the more impactful library changes >>> and batch them up into new reports. >>> >>> You are absolutely correct that moving the question to the Haskell Prime >>> committee risks pushing the issue around. The idea behind the separation >>> outlined above is to reduce the treadmill; the two bodies use different >>> processes, with different time frames, to arrive at decisions. Some >>> library decisions may deserve a longer deliberative process. >>> >>> Cheers, >>> Geoff >>> _______________________________________________ >>> Libraries mailing list >>> Libraries at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > From taruti at taruti.net Thu Oct 22 06:04:10 2015 From: taruti at taruti.net (Taru Karttunen) Date: Thu, 22 Oct 2015 09:04:10 +0300 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: References: <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> Message-ID: On 21.10 17:42, Gregory Collins wrote: > All I'm saying is that if we want to appeal to or cater to working software > engineers, we have to be a lot less cavalier about causing more work for > them, and we need to prize stability of the core infrastructure more > highly. That'd be a broader cultural change, and that goes beyond process: > it's policy. I think that how the changes are handled can make a large difference. E.g. if A) Most of Hackage (including dependencies) compiles with new GHC. (stack & stackage helps somewhat) B) There is an automated tool that can be used to fix most code to compile with new versions of GHC without warnings or CPP. C) Hackage displays vocally what works with which versions of GHC (Status reports do help somewhat) Then I think much of the complaints would go away. - Taru Karttunen From ekmett at gmail.com Thu Oct 22 06:18:29 2015 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 22 Oct 2015 02:18:29 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: References: <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> Message-ID: On Thu, Oct 22, 2015 at 2:04 AM, Taru Karttunen wrote: > E.g. if > > A) Most of Hackage (including dependencies) compiles with new GHC. > (stack & stackage helps somewhat) > > B) There is an automated tool that can be used to fix most code > to compile with new versions of GHC without warnings or CPP. > > C) Hackage displays vocally what works with which versions of > GHC (Status reports do help somewhat) > > Then I think much of the complaints would go away. If we had those things, indeed they would! However, beyond A (GHC 7.10 was tested more extensively against hackage/stackage than any previous release of Haskell by far!), the others require various degrees of engineering effort, including some way to deal with refactoring code that already has CPP in it, more extensive build-bot services, etc. and those sort of non-trivial artifacts just haven't been forthcoming. =/ I would be very happy if those things showed up, however. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Oct 22 06:40:06 2015 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 22 Oct 2015 02:40:06 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> Message-ID: On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins wrote: > > On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland > wrote: > >> My original email stated my underlying concern: we are losing valuable >> members of the community not because of the technical decisions that are >> being made, but because of the process by which they are being made. >> > [If] you're doing research you're on the treadmill, almost by definition, > and you're delighted that we're finally making some rapid progress on > fixing up some of the longstanding warts. > > If you're a practitioner, you are interested in using Haskell for, y'know, > writing programs. You're probably in one of two camps: you're in "green > field" mode writing a lot of new code (early stage startups, prototype > work, etc), or you're maintaining/extending programs you've already written > that are out "in the field" for you doing useful work. Laura Wingerd calls > this the "annealing temperature" of software, and I think this is a nice > metaphor to describe it. How tolerant you are of ecosystem churn depends on > what your temperature is: and I think it should be obvious to everyone that > Haskell having "success" for programming work would mean that lots of > useful and correct programs get written, so everyone who is in the former > camp will cool over time to join the latter. > I've made the point before and I don't really want to belabor it: our de > facto collective posture towards breaking stuff, especially in the past few > years, has been extremely permissive, and this alienates people who are > maintaining working programs. > Even among people who purported to be teaching Haskell or using Haskell today in industry the margin of preference for the concrete FTP proposal was ~79%. This was considerably higher than I expected in two senses. One: there were a lot more people who claimed to be in one of those two roles than I expected by far, and two: their appetite for change was higher than I expected. I initially expected to see a stronger "academic vs. industry" split in the poll, but the groups were only distinguishable by a few percentage point delta, so while I expected roughly the end percentage of the poll, based on the year prior I'd spent running around the planet to user group meetings and the like, I expected it mostly because I expected more hobbyists and less support among industrialists. > I'm actually firmly of the belief that the existing committee doesn't > really have process issues, and in fact, that often it's been pretty > careful to minimize the impact of the changes it wants to make. As others > have pointed out, lots of the churn actually comes from platform libraries, > which are out of the purview of this group. > Historically we've had a bit of a split personality on this front. Nothing that touches the Prelude had changed in 17 years. On the other hand the platform libraries had maintained a pretty heavy rolling wave of breakage the entire time I've been around in the community. On a more experimental feature front, I've lost count of the number of different things we've done to Typeable or template-haskell. > All I'm saying is that if we want to appeal to or cater to working > software engineers, we have to be a lot less cavalier about causing more > work for them, and we need to prize stability of the core infrastructure > more highly. That'd be a broader cultural change, and that goes beyond > process: it's policy. > The way things are shaping up, we've had 17 years of rock solid stability, 1 release that incorporated changes that were designed to minimize impact, to the point that the majority of the objections against them are of the form where people would prefer that we broke _more_ code, to get a more sensible state. Going forward, it looks like the next 2 GHC releases will have basically nothing affecting the Prelude, and there will be another punctuation in the equilibrium around 8.4 as the next set of changes kicks in over 8.4 and 8.6 That gives 2 years worth of advance notice of pending changes, and a pretty strong guarantee from the committee that you should be able to maintain code with a 3 release window without running afoul of warnings or needing CPP. So, out of curiosity, what additional stability policy is it that you seek? -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvr at gnu.org Thu Oct 22 07:04:29 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 22 Oct 2015 09:04:29 +0200 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: (Taru Karttunen's message of "Thu, 22 Oct 2015 09:04:10 +0300") References: <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> Message-ID: <878u6v9yf6.fsf@gnu.org> On 2015-10-22 at 08:04:10 +0200, Taru Karttunen wrote: [...] > B) There is an automated tool that can be used to fix most code > to compile with new versions of GHC without warnings or CPP. Fyi, Alan is currently working on levaraging HaRe[1] in https://github.com/alanz/Hs2010To201x (the `parsing-only` branch) and it's already showing great promise. However, tools like this will only be able to handle the no-brainer cases, as in general it's a NP hard problem. But luckily, those boring mechanical refactorings usually represent the vast majority, and that's the tedious work we want tooling to assist us most with. > C) Hackage displays vocally what works with which versions of > GHC (Status reports do help somewhat) I.e. something like http://matrix.hackage.haskell.org/package/text ? :-) [1]: Btw, here's a recent talk which also mentions the use-case of using HaRe to update between Haskell Report revisions or `base` versions: https://skillsmatter.com/skillscasts/6539-a-new-foundation-for-refactoring-ghc-exactprint From taruti at taruti.net Thu Oct 22 10:52:17 2015 From: taruti at taruti.net (Taru Karttunen) Date: Thu, 22 Oct 2015 13:52:17 +0300 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <878u6v9yf6.fsf@gnu.org> References: <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> <878u6v9yf6.fsf@gnu.org> Message-ID: <0068D6BB4E7EC3FCA343D9CB91AF56@mail.local> On 22.10 09:04, Herbert Valerio Riedel wrote: > Fyi, Alan is currently working on levaraging HaRe[1] in > > https://github.com/alanz/Hs2010To201x (the `parsing-only` branch) > > and it's already showing great promise. However, tools like this will > only be able to handle the no-brainer cases, as in general it's a NP > hard problem. But luckily, those boring mechanical refactorings usually > represent the vast majority, and that's the tedious work we want > tooling to assist us most with. Yes, getting it 99% there as an automated tool would be enough for most cases. > > C) Hackage displays vocally what works with which versions of > > GHC (Status reports do help somewhat) > > > I.e. something like > > http://matrix.hackage.haskell.org/package/text Yes! Is there a reason that it is not displayed on http://hackage.haskell.org/package/text which only displays a link to Status of a 7.8.3 build? How many percent of Hackage is built with matrix.h.h.o and is there a plan to integrate it into Hackage pages? - Taru Karttunen From mainland at apeiron.net Thu Oct 22 13:29:54 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Thu, 22 Oct 2015 09:29:54 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> Message-ID: <5628E4D2.5040904@apeiron.net> On 10/22/2015 02:40 AM, Edward Kmett wrote: > On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins > > wrote: > > > On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland > > wrote: > > My original email stated my underlying concern: we are losing > valuable > members of the community not because of the technical > decisions that are > being made, but because of the process by which they are being > made. > > [If] you're doing research you're on the treadmill, almost by > definition, and you're delighted that we're finally making some > rapid progress on fixing up some of the longstanding warts. > > If you're a practitioner, you are interested in using Haskell for, > y'know, writing programs. You're probably in one of two camps: > you're in "green field" mode writing a lot of new code (early > stage startups, prototype work, etc), or you're > maintaining/extending programs you've already written that are out > "in the field" for you doing useful work. Laura Wingerd calls this > the "annealing temperature" of software, and I think this is a > nice metaphor to describe it. How tolerant you are of ecosystem > churn depends on what your temperature is: and I think it should > be obvious to everyone that Haskell having "success" for > programming work would mean that lots of useful and correct > programs get written, so everyone who is in the former camp will > cool over time to join the latter. > > > I've made the point before and I don't really want to belabor it: > our de facto collective posture towards breaking stuff, especially > in the past few years, has been extremely permissive, and this > alienates people who are maintaining working programs. > > > Even among people who purported to be teaching Haskell or using > Haskell today in industry the margin of preference for the concrete > FTP proposal was ~79%. This was considerably higher than I expected in > two senses. One: there were a lot more people who claimed to be in one > of those two roles than I expected by far, and two: their appetite for > change was higher than I expected. I initially expected to see a > stronger "academic vs. industry" split in the poll, but the groups > were only distinguishable by a few percentage point delta, so while I > expected roughly the end percentage of the poll, based on the year > prior I'd spent running around the planet to user group meetings and > the like, I expected it mostly because I expected more hobbyists and > less support among industrialists. > > I'm actually firmly of the belief that the existing committee > doesn't really have process issues, and in fact, that often it's > been pretty careful to minimize the impact of the changes it wants > to make. As others have pointed out, lots of the churn actually > comes from platform libraries, which are out of the purview of > this group. > > > Historically we've had a bit of a split personality on this front. > Nothing that touches the Prelude had changed in 17 years. On the other > hand the platform libraries had maintained a pretty heavy rolling wave > of breakage the entire time I've been around in the community. On a > more experimental feature front, I've lost count of the number of > different things we've done to Typeable or template-haskell. > > > All I'm saying is that if we want to appeal to or cater to working > software engineers, we have to be a lot less cavalier about > causing more work for them, and we need to prize stability of the > core infrastructure more highly. That'd be a broader cultural > change, and that goes beyond process: it's policy. > > > The way things are shaping up, we've had 17 years of rock solid > stability, 1 release that incorporated changes that were designed to > minimize impact, to the point that the majority of the objections > against them are of the form where people would prefer that we broke > _more_ code, to get a more sensible state. Going forward, it looks > like the next 2 GHC releases will have basically nothing affecting the > Prelude, and there will be another punctuation in the equilibrium > around 8.4 as the next set of changes kicks in over 8.4 and 8.6 That > gives 2 years worth of advance notice of pending changes, and a pretty > strong guarantee from the committee that you should be able to > maintain code with a 3 release window without running afoul of > warnings or needing CPP. > > So, out of curiosity, what additional stability policy is it that you > seek? Thanks to you and Dan [1], I now have a greater understanding and appreciation for where the committee has been coming from. My new understanding is that the changes that were formalized in AMP, FTP, and MRP were the basis for the committee's creation. It also seems that there are more changes in the pipeline that have not yet been made into proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of "stability" is signaling change as far ahead as possible. The committee has put a lot of effort into this, which I appreciate! However, as each of these proposal has come down the pipeline, I never realized that they were part of a larger master plan. 1) What is the master plan, and where is it documented, even if this document is not up to the standard of a proposal? What is the final target, and when might we expect it to be reached? What is in the pipeline after MRP? Relatedly, guidance on how to write code now so that it will be compatible with future changes helps mitigate the stability issue. 2) How can I write code that makes use of the Prelude so that it will work with every new GHC release over the next 3 years? 5 years? For example, how can I write a Monad instance now, knowing the changes that are coming, so that the instance will work with every new GHC release for the next 3 years? 5 years? If the answer is "you can't," then when might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to say I don't know the answer! Finally, if none of these changes broke Prelude backwards compatibility, far fewer people would be complaining :) Of course, we can't always make progress without breaking things, but a more deliberative process might offer an opportunity to make progress while still preserving backwards compatibility. Take AMP for example. There were at least two [3] [4] proposals for preserving backwards compatibility. Investigating them would have taken time and delayed AMP, yes, but why the rush? 3) Can we have a process that allows more deliberation over, and wider publicity for, changes that break backwards compatibility? The goal of such a process would not be to prevent change, but to allow more time to find possible solution to the issue of backwards compatibility. My proposal for a low-traffic mailing list where all proposals were announced was meant to provide wider publicity. Personally, I think these proposals do indeed fix a lot of warts in the language. As a researcher who uses actively uses Haskell every day, these warts have had approximately zero impact on me for the past (almost) decade, and I would be perfectly content if they were never fixed. The only pain I can recall enduring is having to occasionally write an orphan Applicative instance. I have been importing Prelude hiding mapM for years. I have been importing Control.Applicative for years. Neither has been painful. Dealing with AMP? I'm working on a collaborative research project that is stuck on 7.8 because of AMP. I agree, that seems silly, but whether or not it is silly, it is an impact I feel. One way to look at these proposals is to ask the question "Wouldn't the language be nicer if all these changes were made?" Another is to ask the question "Does the fact that these changes have not been made make your life as a Haskell programmer more difficult in any significant way?" I answer "yes" to the former and "no" to the latter. Is our stance that answering "yes" to the former question is enough to motivate braking change? Shouldn't a answer "no" to the latter question cause some hesitation? Maybe there are a lot of people who answer "yes" to both questions. I would like to know! But does having return in the Monad class really cause anyone anything other than existential pain? Cheers, Geoff [1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html [2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html [3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates [4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses From mainland at apeiron.net Thu Oct 22 15:36:31 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Thu, 22 Oct 2015 11:36:31 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> <5628E4D2.5040904@apeiron.net> Message-ID: <5629027F.2070607@apeiron.net> On 10/22/2015 11:02 AM, Matthias H?rmann wrote: > I would say that the need to import Control.Applicative in virtually > every module manually > definitely caused some pain before AMP. In this particular case, there is a trade off between breaking code on the one hand and having to write some import statements on the other. I find writing some extra imports less painful than breaking (other people's and my) code, but the other position is defensible as well. I sense that I am in the minority, at least on the libraries list. > I would also argue that a > non-negligible amount > of effort goes into teaching the warts, the reasons for the warts and > how to work around them. Which wart(s) in particular? All of them? Does having return (and (>>)) in Monad make teaching more difficult? I teach Haskell beginners, and I found that AMP made explaining monads slightly more difficult because it served as a source of confusion for my students. On the other hand, the warts provide a teachable moment once students understand all this stuff :) >> Dealing with AMP? I'm working on a collaborative research project that is stuck on 7.8 because of AMP. > I am curious what exactly about AMP causes your research project to be > "stuck" on GHC 7.8 > considering we have had multiple people mention how little effort it > took to update even large codebases. > I think it would be useful information to have to plan future changes > in a way that might avoid > your issues. I was hoping that mentioning this wouldn't distract from the three main (numbered) questions I posed below. Alas. If I were working alone, AMP wouldn't be a huge deal. I could fix the code for 7.10 compatibility, but then unless everyone switches to 7.10, changes to the codebase made by someone using 7.8, e.g., defining a new Monad instance, could break things on 7.10 again. It's easier to stick with 7.8. Any time spent dealing with compatibility issues is time not spent writing actual code. I outlined one possible path to avoid this kind of issue: spend more time thinking about ways to maintain compatibility. We had proposals for doing this with AMP. Cheers, Geoff > > On Thu, Oct 22, 2015 at 3:29 PM, Geoffrey Mainland wrote: >> On 10/22/2015 02:40 AM, Edward Kmett wrote: >>> On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins >>> > wrote: >>> >>> >>> On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland >>> > wrote: >>> >>> My original email stated my underlying concern: we are losing >>> valuable >>> members of the community not because of the technical >>> decisions that are >>> being made, but because of the process by which they are being >>> made. >>> >>> [If] you're doing research you're on the treadmill, almost by >>> definition, and you're delighted that we're finally making some >>> rapid progress on fixing up some of the longstanding warts. >>> >>> If you're a practitioner, you are interested in using Haskell for, >>> y'know, writing programs. You're probably in one of two camps: >>> you're in "green field" mode writing a lot of new code (early >>> stage startups, prototype work, etc), or you're >>> maintaining/extending programs you've already written that are out >>> "in the field" for you doing useful work. Laura Wingerd calls this >>> the "annealing temperature" of software, and I think this is a >>> nice metaphor to describe it. How tolerant you are of ecosystem >>> churn depends on what your temperature is: and I think it should >>> be obvious to everyone that Haskell having "success" for >>> programming work would mean that lots of useful and correct >>> programs get written, so everyone who is in the former camp will >>> cool over time to join the latter. >>> >>> >>> I've made the point before and I don't really want to belabor it: >>> our de facto collective posture towards breaking stuff, especially >>> in the past few years, has been extremely permissive, and this >>> alienates people who are maintaining working programs. >>> >>> >>> Even among people who purported to be teaching Haskell or using >>> Haskell today in industry the margin of preference for the concrete >>> FTP proposal was ~79%. This was considerably higher than I expected in >>> two senses. One: there were a lot more people who claimed to be in one >>> of those two roles than I expected by far, and two: their appetite for >>> change was higher than I expected. I initially expected to see a >>> stronger "academic vs. industry" split in the poll, but the groups >>> were only distinguishable by a few percentage point delta, so while I >>> expected roughly the end percentage of the poll, based on the year >>> prior I'd spent running around the planet to user group meetings and >>> the like, I expected it mostly because I expected more hobbyists and >>> less support among industrialists. >>> >>> I'm actually firmly of the belief that the existing committee >>> doesn't really have process issues, and in fact, that often it's >>> been pretty careful to minimize the impact of the changes it wants >>> to make. As others have pointed out, lots of the churn actually >>> comes from platform libraries, which are out of the purview of >>> this group. >>> >>> >>> Historically we've had a bit of a split personality on this front. >>> Nothing that touches the Prelude had changed in 17 years. On the other >>> hand the platform libraries had maintained a pretty heavy rolling wave >>> of breakage the entire time I've been around in the community. On a >>> more experimental feature front, I've lost count of the number of >>> different things we've done to Typeable or template-haskell. >>> >>> >>> All I'm saying is that if we want to appeal to or cater to working >>> software engineers, we have to be a lot less cavalier about >>> causing more work for them, and we need to prize stability of the >>> core infrastructure more highly. That'd be a broader cultural >>> change, and that goes beyond process: it's policy. >>> >>> >>> The way things are shaping up, we've had 17 years of rock solid >>> stability, 1 release that incorporated changes that were designed to >>> minimize impact, to the point that the majority of the objections >>> against them are of the form where people would prefer that we broke >>> _more_ code, to get a more sensible state. Going forward, it looks >>> like the next 2 GHC releases will have basically nothing affecting the >>> Prelude, and there will be another punctuation in the equilibrium >>> around 8.4 as the next set of changes kicks in over 8.4 and 8.6 That >>> gives 2 years worth of advance notice of pending changes, and a pretty >>> strong guarantee from the committee that you should be able to >>> maintain code with a 3 release window without running afoul of >>> warnings or needing CPP. >>> >>> So, out of curiosity, what additional stability policy is it that you >>> seek? >> Thanks to you and Dan [1], I now have a greater understanding and >> appreciation for where the committee has been coming from. My new >> understanding is that the changes that were formalized in AMP, FTP, and >> MRP were the basis for the committee's creation. It also seems that >> there are more changes in the pipeline that have not yet been made into >> proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of >> "stability" is signaling change as far ahead as possible. The committee >> has put a lot of effort into this, which I appreciate! However, as each >> of these proposal has come down the pipeline, I never realized that they >> were part of a larger master plan. >> >> 1) What is the master plan, and where is it documented, even if this >> document is not up to the standard of a proposal? What is the final >> target, and when might we expect it to be reached? What is in the >> pipeline after MRP? >> >> Relatedly, guidance on how to write code now so that it will be >> compatible with future changes helps mitigate the stability issue. >> >> 2) How can I write code that makes use of the Prelude so that it will >> work with every new GHC release over the next 3 years? 5 years? For >> example, how can I write a Monad instance now, knowing the changes that >> are coming, so that the instance will work with every new GHC release >> for the next 3 years? 5 years? If the answer is "you can't," then when >> might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to >> say I don't know the answer! >> >> Finally, if none of these changes broke Prelude backwards compatibility, >> far fewer people would be complaining :) Of course, we can't always make >> progress without breaking things, but a more deliberative process might >> offer an opportunity to make progress while still preserving backwards >> compatibility. Take AMP for example. There were at least two [3] [4] >> proposals for preserving backwards compatibility. Investigating them >> would have taken time and delayed AMP, yes, but why the rush? >> >> 3) Can we have a process that allows more deliberation over, and wider >> publicity for, changes that break backwards compatibility? The goal of >> such a process would not be to prevent change, but to allow more time to >> find possible solution to the issue of backwards compatibility. >> >> My proposal for a low-traffic mailing list where all proposals were >> announced was meant to provide wider publicity. >> >> Personally, I think these proposals do indeed fix a lot of warts in the >> language. As a researcher who uses actively uses Haskell every day, >> these warts have had approximately zero impact on me for the past >> (almost) decade, and I would be perfectly content if they were never >> fixed. The only pain I can recall enduring is having to occasionally >> write an orphan Applicative instance. I have been importing Prelude >> hiding mapM for years. I have been importing Control.Applicative for >> years. Neither has been painful. Dealing with AMP? I'm working on a >> collaborative research project that is stuck on 7.8 because of AMP. I >> agree, that seems silly, but whether or not it is silly, it is an impact >> I feel. >> >> One way to look at these proposals is to ask the question "Wouldn't the >> language be nicer if all these changes were made?" Another is to ask the >> question "Does the fact that these changes have not been made make your >> life as a Haskell programmer more difficult in any significant way?" I >> answer "yes" to the former and "no" to the latter. Is our stance that >> answering "yes" to the former question is enough to motivate braking >> change? Shouldn't a answer "no" to the latter question cause some >> hesitation? >> >> Maybe there are a lot of people who answer "yes" to both questions. I >> would like to know! But does having return in the Monad class really >> cause anyone anything other than existential pain? >> >> Cheers, >> Geoff >> >> [1] https://mail.haskell.org/pipermail/libraries/2015-October/026390.html >> [2] https://mail.haskell.org/pipermail/libraries/2015-September/026158.html >> [3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates >> [4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses From mblazevic at stilo.com Thu Oct 22 16:20:55 2015 From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=) Date: Thu, 22 Oct 2015 12:20:55 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <5628E4D2.5040904@apeiron.net> References: <87io6zmr2x.fsf@gnu.org> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> <5628E4D2.5040904@apeiron.net> Message-ID: <56290CE7.8050408@stilo.com> On 15-10-22 09:29 AM, Geoffrey Mainland wrote: > ... > > 1) What is the master plan, and where is it documented, even if this > document is not up to the standard of a proposal? What is the final > target, and when might we expect it to be reached? What is in the > pipeline after MRP? > > Relatedly, guidance on how to write code now so that it will be > compatible with future changes helps mitigate the stability issue. I have been fully in favour of all the proposals implemented so far, and I think that having an explicit master plan would be a great idea. It would address some of the process-related objections that have been raised, and it would provide a fixed long-term target that would be much easier to make the whole community aware of and contribute to. For that purpose, the master plan should be advertised directly on the front page of haskell.org. Once we have it settled and agreed, the purpose of the base-library commitee would essentially become to figure out the details like the timeline and code migration path. One thing they wouldn't need to worry about is whether anybody disagrees with their goals. > 2) How can I write code that makes use of the Prelude so that it will > work with every new GHC release over the next 3 years? 5 years? For > example, how can I write a Monad instance now, knowing the changes that > are coming, so that the instance will work with every new GHC release > for the next 3 years? 5 years? If the answer is "you can't," then when > might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to > say I don't know the answer! From the discussions so far it appears that the answer for 3 years (or at least the next 3 GHC releases) would be to write the code that works with the current GHC and base, but this policy has not been codified anywhere yet. Knowing the upcoming changes doesn't help with making your code any more robust, and I think that's a shame. We could have a two-pronged policy: - code that works and compiles with the latest GHC with no *warnings* will continue to work and compile with no *errors* with the following 2 releases, and - code that also follows the forward-compatibility recommendations current for that version of GHC will continue to work and compile with no *errors* with the following 4 releases. The forward-compatibility recommendations would become a part of the online GHC documentation so nobody complains they didn't know about them. Personally, I'd prefer if the recommendations were built into the compiler itself as a new class of warnings, but then (a) some people would insist on turning them on together with -Werror and then complain when their builds break and (b) this would increase the pressure on GHC implementors. > Finally, if none of these changes broke Prelude backwards compatibility, > far fewer people would be complaining :) Of course, we can't always make > progress without breaking things, but a more deliberative process might > offer an opportunity to make progress while still preserving backwards > compatibility. Take AMP for example. There were at least two [3] [4] > proposals for preserving backwards compatibility. Investigating them > would have taken time and delayed AMP, yes, but why the rush? Because they have been investigated for years with no effect. > 3) Can we have a process that allows more deliberation over, and wider > publicity for, changes that break backwards compatibility? The goal of > such a process would not be to prevent change, but to allow more time to > find possible solution to the issue of backwards compatibility. I doubt we can, but this question has already been answered by others. From ekmett at gmail.com Thu Oct 22 16:32:08 2015 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 22 Oct 2015 12:32:08 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <5628E4D2.5040904@apeiron.net> References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> <5628E4D2.5040904@apeiron.net> Message-ID: On Thu, Oct 22, 2015 at 9:29 AM, Geoffrey Mainland wrote: > Thanks to you and Dan [1], I now have a greater understanding and > appreciation for where the committee has been coming from. My new > understanding is that the changes that were formalized in AMP, FTP, and > MRP were the basis for the committee's creation. It also seems that > there are more changes in the pipeline that have not yet been made into > proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of > "stability" is signaling change as far ahead as possible. The committee > has put a lot of effort into this, which I appreciate! However, as each > of these proposal has come down the pipeline, I never realized that they > were part of a larger master plan. > The "master plan" where (>>) is concerned is that it'd be nice to get Traversable down to a minimal state and to eliminate unnecessary distinctions in the Prelude between things like mapM and traverse. Right now they have different type constraints, but this is entirely a historical artifact. But it causes problems, we have a situation where folks have commonly optimized (>>) but left (*>) unfixed. This yields different performance for mapM_ and traverse_. A consequence of the AMP is that the neither one of those could be defined in terms of the other (*>) has a default definition in terms of (<*>). (>>) has a default definition in terms of (>>=). With two places where optimizations can happen and two different definitions for operations that are logically required to be the same thing we can and do see rather radically different performance between these two things. This proposal is something that was put out as a sort of addendum to the Monad of No Return proposal for discussion, but unlike MRP has no particular impact on a sacred cow like return. We have yet to put together a timeline that incorporates the (>>) changes from MRP. 1) What is the master plan, and where is it documented, even if this > document is not up to the standard of a proposal? What is the final > target, and when might we expect it to be reached? What is in the > pipeline after MRP? > > Relatedly, guidance on how to write code now so that it will be > compatible with future changes helps mitigate the stability issue. > The current plans more or less stop with finishing the MonadFail proposal, getting Semigroup in as a superclass of Monoid, and incorporating some additional members into Floating. The working document for the timeline going forward is available here: https://ghc.haskell.org/trac/ghc/wiki/Status/BaseLibrary > > 2) How can I write code that makes use of the Prelude so that it will > work with every new GHC release over the next 3 years? 5 years? For > example, how can I write a Monad instance now, knowing the changes that > are coming, so that the instance will work with every new GHC release > for the next 3 years? 5 years? If the answer is "you can't," then when > might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to > say I don't know the answer! > We have a backwards facing "3 release policy" that says it should always be possible to write code that works backwards for 3 releases. This means that changes like moving fail out of Monad will take 5 years. However, maintaining both that and a _forward facing_ 3 release policy would mean that any change that introduced a superclass would take something like 9 years of intermediate states that make no sense to complete. *9 years to move one method.* Now looking forward. You can write code today with 7.10 that will work without warnings until 8.2. That happens to be 3 releases. In 8.4 you'll start to get warnings about Semigroup and MonadFail changes, but looking at it as 3 releases going forward in 8.0 you can just write the instances and your code would be warning free forward for 3 releases. In 8.6 those changes go into effect, but you will have been able to make the code changes that you need to accomodate 8.6 since 8.0. The current roadmap happens to give you a 3 year sliding window. Finally, if none of these changes broke Prelude backwards compatibility, > far fewer people would be complaining :) If none of our changes were ever able to break Prelude backwards compatibility the same people who have been complaining about the utter lack of progress for the previous 17 years and that nearly exploded the community 2 years ago would be complaining, and based on polling and discusssions that is actually a much larger group. The AMP passed nearly unanimously. > Of course, we can't always make > progress without breaking things, but a more deliberative process might > offer an opportunity to make progress while still preserving backwards > compatibility. Take AMP for example. There were at least two [3] [4] > proposals for preserving backwards compatibility. Investigating them > would have taken time and delayed AMP, yes, but why the rush? > We've been talking about various superclass defaulting proposals for the better part of a decade and no progress has been made. The rush was that we'd been letting them block every previous discussion, and that the concrete plan with an actual implementation that was on hand was a very popular proposal even without that mitigation strategy. 3) Can we have a process that allows more deliberation over, and wider > publicity for, changes that break backwards compatibility? The goal of > such a process would not be to prevent change, but to allow more time to > find possible solution to the issue of backwards compatibility. > > My proposal for a low-traffic mailing list where all proposals were > announced was meant to provide wider publicity. > I don't think anybody has an objection to wider visibility of proposals that affect things mentioned in the Haskell Report. > Personally, I think these proposals do indeed fix a lot of warts in the > language. As a researcher who uses actively uses Haskell every day, > these warts have had approximately zero impact on me for the past > (almost) decade, and I would be perfectly content if they were never > fixed. The only pain I can recall enduring is having to occasionally > write an orphan Applicative instance. I have been importing Prelude > hiding mapM for years. I have been importing Control.Applicative for > years. Neither has been painful. And yet the vast preponderance of public opinion lies in the other camp. The "change nothing" policy had an iron grip on the state of affairs for 17 years and there were serious cracks starting to form from the appearance that nothing could ever be fixed if the Prelude was affected in any way. The only thing that broke with that was when Ian Lynagh unilaterally removed Eq and Show as superclasses of Num. That was more or less the first glimmer that the world wouldn't end if deliberated changes were made to the Prelude. Dealing with AMP? I'm working on a > collaborative research project that is stuck on 7.8 because of AMP. I > agree, that seems silly, but whether or not it is silly, it is an impact > I feel. > What changes did you face beyond writing instance Functor Foo where fmap = liftM instance Applicative Foo where pure = return (<*>) = ap that is AMP related? Maybe there are a lot of people who answer "yes" to both questions. I > would like to know! But does having return in the Monad class really > cause anyone anything other than existential pain? > The MRP is by far the most marginal proposal on the table. This is why it remains *just a proposal* and not part of the roadmap. That said, moving return to a top level definition will mean that more code that is compiled will be able to infer an Applicative constraint. The other proposals that are on the roadmap on the other hand defend a lot better. The (>>) fragment of MRP fixes rampant performance regressions, however. We went to generalize the implementation of mapM_ to use (*>) internally and found performance regressions within base itself due to instances that are optimized inconsistently. This informed the design here. More code will infer with weaker Applicative constraints, Traversable can eventually be simplified, and folks like Simon Marlow who have folks internally at Facebook use mapM will just have their code "work" in Haxl. I can answer "yes" to both of your questions here. The continued existence of fail in Monad on the other hand has caused a great deal of pain in instances for things like `Either a` for years. To supply `fail`, we used to incur a needless Error a constraint. We can be more precise and remove a potential source of partiality from a lot of code. I can answer "yes" to both of your questions here. The lack of Semigroup as a superclass of Monoid has meant that the Monoid instance for Maybe adds a unit to something that already has a unit. It means that First and Last, etc. all useless tack an extra case that everyone has to handle in. It has dozens of knock-on consequences. Much code that currently only needs a semigroup falls back on a monoid because of the lack of a proper class relationship or gets duplicated. I can answer "yes" to both of your questions here. The numerics changes to Floating mean that Haskell numerics just have awful precision. Adding expm1, etc. to Floating means that people will be able to write decent numerical code without having to choose between generality (using exp from Floating that works everywhere) and accuracy. I can answer "yes" to both of your questions here. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Oct 22 16:38:10 2015 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 22 Oct 2015 12:38:10 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <5629027F.2070607@apeiron.net> References: <87io6zmr2x.fsf@gnu.org> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> <5628E4D2.5040904@apeiron.net> <5629027F.2070607@apeiron.net> Message-ID: On Thu, Oct 22, 2015 at 11:36 AM, Geoffrey Mainland wrote: > On 10/22/2015 11:02 AM, Matthias H?rmann wrote: > > I would say that the need to import Control.Applicative in virtually > > every module manually > > definitely caused some pain before AMP. > > In this particular case, there is a trade off between breaking code on > the one hand and having to write some import statements on the other. I > find writing some extra imports less painful than breaking (other > people's and my) code, but the other position is defensible as well. I > sense that I am in the minority, at least on the libraries list. > > > I would also argue that a > > non-negligible amount > > of effort goes into teaching the warts, the reasons for the warts and > > how to work around them. > > Which wart(s) in particular? All of them? Does having return (and (>>)) > in Monad make teaching more difficult? > Having (>>) means that we have hundreds of monads out there where (>>) has been optimized, but (*>) has not. If I were working alone, AMP wouldn't be a huge deal. I could fix the > code for 7.10 compatibility, but then unless everyone switches to 7.10, > changes to the codebase made by someone using 7.8, e.g., defining a new > Monad instance, could break things on 7.10 again. It's easier to stick > with 7.8. Any time spent dealing with compatibility issues is time not > spent writing actual code. > In the open source world many of us just fire off our code to travis-ci and get it to build with a dozen different compiler versions. I maintain a lot of code that supports things back to 7.0 and forward to HEAD this way. > I outlined one possible path to avoid this kind of issue: spend more > time thinking about ways to maintain compatibility. We had proposals for > doing this with AMP. > And on the other hand we also had a concrete proposal that didn't require language changes that was ridiculously popular. People had been talking about Applicative as a superclass of Monad for a decade before we finally acted upon the AMP. People had been talking about superclass defaulting for a decade. When do you cut off discussion and ship the proposal that has overwhelming support? If there is no process that enables this you can stall the process indefinitely by raising objections of this form. Such a situation is not without costs all its own. -Edward > Cheers, > Geoff > > > > > On Thu, Oct 22, 2015 at 3:29 PM, Geoffrey Mainland > wrote: > >> On 10/22/2015 02:40 AM, Edward Kmett wrote: > >>> On Wed, Oct 21, 2015 at 8:42 PM, Gregory Collins > >>> > wrote: > >>> > >>> > >>> On Wed, Oct 21, 2015 at 3:18 PM, Geoffrey Mainland > >>> > wrote: > >>> > >>> My original email stated my underlying concern: we are losing > >>> valuable > >>> members of the community not because of the technical > >>> decisions that are > >>> being made, but because of the process by which they are being > >>> made. > >>> > >>> [If] you're doing research you're on the treadmill, almost by > >>> definition, and you're delighted that we're finally making some > >>> rapid progress on fixing up some of the longstanding warts. > >>> > >>> If you're a practitioner, you are interested in using Haskell for, > >>> y'know, writing programs. You're probably in one of two camps: > >>> you're in "green field" mode writing a lot of new code (early > >>> stage startups, prototype work, etc), or you're > >>> maintaining/extending programs you've already written that are out > >>> "in the field" for you doing useful work. Laura Wingerd calls this > >>> the "annealing temperature" of software, and I think this is a > >>> nice metaphor to describe it. How tolerant you are of ecosystem > >>> churn depends on what your temperature is: and I think it should > >>> be obvious to everyone that Haskell having "success" for > >>> programming work would mean that lots of useful and correct > >>> programs get written, so everyone who is in the former camp will > >>> cool over time to join the latter. > >>> > >>> > >>> I've made the point before and I don't really want to belabor it: > >>> our de facto collective posture towards breaking stuff, especially > >>> in the past few years, has been extremely permissive, and this > >>> alienates people who are maintaining working programs. > >>> > >>> > >>> Even among people who purported to be teaching Haskell or using > >>> Haskell today in industry the margin of preference for the concrete > >>> FTP proposal was ~79%. This was considerably higher than I expected in > >>> two senses. One: there were a lot more people who claimed to be in one > >>> of those two roles than I expected by far, and two: their appetite for > >>> change was higher than I expected. I initially expected to see a > >>> stronger "academic vs. industry" split in the poll, but the groups > >>> were only distinguishable by a few percentage point delta, so while I > >>> expected roughly the end percentage of the poll, based on the year > >>> prior I'd spent running around the planet to user group meetings and > >>> the like, I expected it mostly because I expected more hobbyists and > >>> less support among industrialists. > >>> > >>> I'm actually firmly of the belief that the existing committee > >>> doesn't really have process issues, and in fact, that often it's > >>> been pretty careful to minimize the impact of the changes it wants > >>> to make. As others have pointed out, lots of the churn actually > >>> comes from platform libraries, which are out of the purview of > >>> this group. > >>> > >>> > >>> Historically we've had a bit of a split personality on this front. > >>> Nothing that touches the Prelude had changed in 17 years. On the other > >>> hand the platform libraries had maintained a pretty heavy rolling wave > >>> of breakage the entire time I've been around in the community. On a > >>> more experimental feature front, I've lost count of the number of > >>> different things we've done to Typeable or template-haskell. > >>> > >>> > >>> All I'm saying is that if we want to appeal to or cater to working > >>> software engineers, we have to be a lot less cavalier about > >>> causing more work for them, and we need to prize stability of the > >>> core infrastructure more highly. That'd be a broader cultural > >>> change, and that goes beyond process: it's policy. > >>> > >>> > >>> The way things are shaping up, we've had 17 years of rock solid > >>> stability, 1 release that incorporated changes that were designed to > >>> minimize impact, to the point that the majority of the objections > >>> against them are of the form where people would prefer that we broke > >>> _more_ code, to get a more sensible state. Going forward, it looks > >>> like the next 2 GHC releases will have basically nothing affecting the > >>> Prelude, and there will be another punctuation in the equilibrium > >>> around 8.4 as the next set of changes kicks in over 8.4 and 8.6 That > >>> gives 2 years worth of advance notice of pending changes, and a pretty > >>> strong guarantee from the committee that you should be able to > >>> maintain code with a 3 release window without running afoul of > >>> warnings or needing CPP. > >>> > >>> So, out of curiosity, what additional stability policy is it that you > >>> seek? > >> Thanks to you and Dan [1], I now have a greater understanding and > >> appreciation for where the committee has been coming from. My new > >> understanding is that the changes that were formalized in AMP, FTP, and > >> MRP were the basis for the committee's creation. It also seems that > >> there are more changes in the pipeline that have not yet been made into > >> proposals, e.g., pulling (>>) out of Control.Monad [2]. Part of > >> "stability" is signaling change as far ahead as possible. The committee > >> has put a lot of effort into this, which I appreciate! However, as each > >> of these proposal has come down the pipeline, I never realized that they > >> were part of a larger master plan. > >> > >> 1) What is the master plan, and where is it documented, even if this > >> document is not up to the standard of a proposal? What is the final > >> target, and when might we expect it to be reached? What is in the > >> pipeline after MRP? > >> > >> Relatedly, guidance on how to write code now so that it will be > >> compatible with future changes helps mitigate the stability issue. > >> > >> 2) How can I write code that makes use of the Prelude so that it will > >> work with every new GHC release over the next 3 years? 5 years? For > >> example, how can I write a Monad instance now, knowing the changes that > >> are coming, so that the instance will work with every new GHC release > >> for the next 3 years? 5 years? If the answer is "you can't," then when > >> might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to > >> say I don't know the answer! > >> > >> Finally, if none of these changes broke Prelude backwards compatibility, > >> far fewer people would be complaining :) Of course, we can't always make > >> progress without breaking things, but a more deliberative process might > >> offer an opportunity to make progress while still preserving backwards > >> compatibility. Take AMP for example. There were at least two [3] [4] > >> proposals for preserving backwards compatibility. Investigating them > >> would have taken time and delayed AMP, yes, but why the rush? > >> > >> 3) Can we have a process that allows more deliberation over, and wider > >> publicity for, changes that break backwards compatibility? The goal of > >> such a process would not be to prevent change, but to allow more time to > >> find possible solution to the issue of backwards compatibility. > >> > >> My proposal for a low-traffic mailing list where all proposals were > >> announced was meant to provide wider publicity. > >> > >> Personally, I think these proposals do indeed fix a lot of warts in the > >> language. As a researcher who uses actively uses Haskell every day, > >> these warts have had approximately zero impact on me for the past > >> (almost) decade, and I would be perfectly content if they were never > >> fixed. The only pain I can recall enduring is having to occasionally > >> write an orphan Applicative instance. I have been importing Prelude > >> hiding mapM for years. I have been importing Control.Applicative for > >> years. Neither has been painful. Dealing with AMP? I'm working on a > >> collaborative research project that is stuck on 7.8 because of AMP. I > >> agree, that seems silly, but whether or not it is silly, it is an impact > >> I feel. > >> > >> One way to look at these proposals is to ask the question "Wouldn't the > >> language be nicer if all these changes were made?" Another is to ask the > >> question "Does the fact that these changes have not been made make your > >> life as a Haskell programmer more difficult in any significant way?" I > >> answer "yes" to the former and "no" to the latter. Is our stance that > >> answering "yes" to the former question is enough to motivate braking > >> change? Shouldn't a answer "no" to the latter question cause some > >> hesitation? > >> > >> Maybe there are a lot of people who answer "yes" to both questions. I > >> would like to know! But does having return in the Monad class really > >> cause anyone anything other than existential pain? > >> > >> Cheers, > >> Geoff > >> > >> [1] > https://mail.haskell.org/pipermail/libraries/2015-October/026390.html > >> [2] > https://mail.haskell.org/pipermail/libraries/2015-September/026158.html > >> [3] https://ghc.haskell.org/trac/ghc/wiki/InstanceTemplates > >> [4] https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Oct 22 16:48:45 2015 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 22 Oct 2015 12:48:45 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <56290CE7.8050408@stilo.com> References: <87io6zmr2x.fsf@gnu.org> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> <5628E4D2.5040904@apeiron.net> <56290CE7.8050408@stilo.com> Message-ID: On Thu, Oct 22, 2015 at 12:20 PM, Mario Bla?evi? wrote: > On 15-10-22 09:29 AM, Geoffrey Mainland wrote: > >> ... >> >> 1) What is the master plan, and where is it documented, even if this >> document is not up to the standard of a proposal? What is the final >> target, and when might we expect it to be reached? What is in the >> pipeline after MRP? >> >> Relatedly, guidance on how to write code now so that it will be >> compatible with future changes helps mitigate the stability issue. >> > > I have been fully in favour of all the proposals implemented so > far, and I think that having an explicit master plan would be a great idea. > It would address some of the process-related objections that have been > raised, and it would provide a fixed long-term target that would be much > easier to make the whole community aware of and contribute to. > > For that purpose, the master plan should be advertised directly on > the front page of haskell.org. Once we have it settled and agreed, the > purpose of the base-library commitee would essentially become to figure out > the details like the timeline and code migration path. One thing they > wouldn't need to worry about is whether anybody disagrees with their goals. > > > 2) How can I write code that makes use of the Prelude so that it will >> work with every new GHC release over the next 3 years? 5 years? For >> example, how can I write a Monad instance now, knowing the changes that >> are coming, so that the instance will work with every new GHC release >> for the next 3 years? 5 years? If the answer is "you can't," then when >> might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to >> say I don't know the answer! >> > > From the discussions so far it appears that the answer for 3 years > (or at least the next 3 GHC releases) would be to write the code that works > with the current GHC and base, but this policy has not been codified > anywhere yet. Knowing the upcoming changes doesn't help with making your > code any more robust, and I think that's a shame. We could have a > two-pronged policy: > > - code that works and compiles with the latest GHC with no *warnings* will > continue to work and compile with no *errors* with the following 2 > releases, and > - code that also follows the forward-compatibility recommendations current > for that version of GHC will continue to work and compile with no *errors* > with the following 4 releases. > We have adopted a "3 release policy" facing backwards, not forwards. However, all proposals currently under discussion actually meet a stronger condition, a 3 release policy that you can slide both forward and backwards to pick the 3 releases you want to be compatible with without using CPP. It also appears that all of the changes that we happen to have in the wings https://ghc.haskell.org/trac/ghc/wiki/Status/BaseLibrary comply with both of your goals here. However, I hesitate to say that we can simultaneously meet this goal and the 3 release policy facing backwards _and_ sufficient notification in all situations even ones we can't foresee today. As a guideline? Sure. If we have two plans that can reach the same end-goal and one complies and the other doesn't, I'd say we should favor the plan that gives more notice and assurance. However, this also needs to be tempered against the number of years folks suffer the pain of having in an inconsistent intermediate state. (e.g. having generalized combinators in Data.List today) The forward-compatibility recommendations would become a part of > the online GHC documentation so nobody complains they didn't know about > them. Personally, I'd prefer if the recommendations were built into the > compiler itself as a new class of warnings, but then (a) some people would > insist on turning them on together with -Werror and then complain when > their builds break and (b) this would increase the pressure on GHC > implementors. The current discussion is centering around adding a -Wcompat flag that warns of changes that you maybe can't yet implement in a way that would be backwards compatible with a 3 release backwards-facing window, but which will eventually cause issues. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From mainland at apeiron.net Thu Oct 22 16:59:31 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Thu, 22 Oct 2015 12:59:31 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> <5628E4D2.5040904@apeiron.net> <5629027F.2070607@apeiron.net> Message-ID: <562915F3.5000505@apeiron.net> > I outlined one possible path to avoid this kind of issue: spend more > time thinking about ways to maintain compatibility. We had > proposals for > doing this with AMP. > > > And on the other hand we also had a concrete proposal that didn't > require language changes that was ridiculously popular. People had > been talking about Applicative as a superclass of Monad for a decade > before we finally acted upon the AMP. People had been talking about > superclass defaulting for a decade. When do you cut off discussion and > ship the proposal that has overwhelming support? If there is no > process that enables this you can stall the process indefinitely by > raising objections of this form. Such a situation is not without costs > all its own. > I agree. It was certainly within the power of the committee to start a clock and say something like "if we don't have a patch to GHC that provides backwards compatibility for AMP within 1 year, we will push out AMP as-is." Had I understand the implications of AMP at the time, or even been aware that AMP was happening (I was actually actively working on the GHC code base during that period), that certainly would have been motivation for me to do something about it! *That* would be how one could cut off discussion and ship a proposal. I am not against changing the Prelude! But it sure would be nice if -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a Haskell 2010 Prelude, both of which could be used with external packages that themselves used the more modern Prelude. Maybe that's impossible. Setting a firm deadline to finding a solution to the compatibility issue would have been a way to compromise. Ideally, changing the Prelude wouldn't require breaking code written to use an older version of the Prelude. Yes, attaining that goal would require more work. Evolving the Prelude and maintaining compatibility are not necessarily mutually exclusive options. Cheers, Geoff From ekmett at gmail.com Thu Oct 22 17:29:34 2015 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 22 Oct 2015 13:29:34 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <562915F3.5000505@apeiron.net> References: <87io6zmr2x.fsf@gnu.org> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> <5628E4D2.5040904@apeiron.net> <5629027F.2070607@apeiron.net> <562915F3.5000505@apeiron.net> Message-ID: On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland wrote: > > > I outlined one possible path to avoid this kind of issue: spend more > > time thinking about ways to maintain compatibility. We had > > proposals for > > doing this with AMP. > > > > > > And on the other hand we also had a concrete proposal that didn't > > require language changes that was ridiculously popular. People had > > been talking about Applicative as a superclass of Monad for a decade > > before we finally acted upon the AMP. People had been talking about > > superclass defaulting for a decade. When do you cut off discussion and > > ship the proposal that has overwhelming support? If there is no > > process that enables this you can stall the process indefinitely by > > raising objections of this form. Such a situation is not without costs > > all its own. > > > > I agree. It was certainly within the power of the committee to start a > clock and say something like "if we don't have a patch to GHC that > provides backwards compatibility for AMP within 1 year, we will push out > AMP as-is." Had I understand the implications of AMP at the time, or > even been aware that AMP was happening (I was actually actively working > on the GHC code base during that period), that certainly would have been > motivation for me to do something about it! *That* would be how one > could cut off discussion and ship a proposal. > I freely admit that there is room for improvement in the process. We're all learning here. The current Semigroup-Monoid proposal more or less fits the bill you are looking for here. We have a roadmap today that migrates an existing package with several years worth of back support into base more or less unmodified, and then in 3 releases starts requiring instances. You can think of that 3 release clock as precisely what you are looking for here. If we get an implementation of superclass defaulting or some other mechanism that can mitigate the extra couple of lines of code that this proposal will tax users with, within that timeline, we'd gladly incorporate it into the proposal. > I am not against changing the Prelude! But it sure would be nice if > -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a > Haskell 2010 Prelude, both of which could be used with external packages > that themselves used the more modern Prelude. It would definitely be a preferable state of affairs. Unfortunately, at least with the tools available to us today, such a plan is incompatible with any plan that introduces a new superclass. It also cuts off plans that ever factors an existing class into two, such as the MonadFail proposals. We simply do not at this time have the technical capabilities that would support such a system. If they showed up in GHC we can adapt plans to fit. > Maybe that's impossible. > Setting a firm deadline to finding a solution to the compatibility issue > would have been a way to compromise. Ideally, changing the Prelude > wouldn't require breaking code written to use an older version of the > Prelude. Yes, attaining that goal would require more work. > We looked around for a year for a roadmap that would get us there. None presented itself. In the end we wound up shedding the core libraries status of the haskell98 and haskell2010 packages as the 3-4 different ways in which one could write a Haskell2010 package all have different trade-offs and can be maintained in user-land. Examples: * A hardline version of haskell2010 with a Monad and Num that fully complies with the report, but which doesn't work with Monad and Num instances supplied by other libraries. This needs RebindableSyntax, so it doesn't quite work right. With compiler support for rebinding syntax to a particular library instead of to whatever is in scope, such a thing might be suitable for teaching a Haskell class. * A pragmatic haskell2010 where the Monad has an Applicative superclass and Num has the current semantic. This works with everything but doesn't faithfully follow the report. * A middle-ground package that tries to use a superclass defaulting mechanism that we don't have to supply missing Applicative superclasses might resolve the Applicative-Monad issue in theory, but does nothing for report compliance of our existing Num. Each one of these solutions has flaws. Two of them require innovations in the compiler that we don't have. > Evolving the Prelude and maintaining compatibility are not necessarily > mutually exclusive options. > Agreed, but as you can see above, maintaining compatibility isn't necessarily always a viable option either. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From mainland at apeiron.net Thu Oct 22 17:41:14 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Thu, 22 Oct 2015 13:41:14 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> <5628E4D2.5040904@apeiron.net> <5629027F.2070607@apeiron.net> <562915F3.5000505@apeiron.net> Message-ID: <56291FBA.1000604@apeiron.net> On 10/22/2015 01:29 PM, Edward Kmett wrote: > On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland > > wrote: > > > I am not against changing the Prelude! But it sure would be nice if > -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a > Haskell 2010 Prelude, both of which could be used with external > packages > that themselves used the more modern Prelude. > > > It would definitely be a preferable state of affairs. Unfortunately, > at least with the tools available to us today, such a plan is > incompatible with any plan that introduces a new superclass. It also > cuts off plans that ever factors an existing class into two, such as > the MonadFail proposals. We simply do not at this time have the > technical capabilities that would support such a system. If they > showed up in GHC we can adapt plans to fit. Great! Could we work to characterize what technical capabilities we would need to support full backwards Prelude compatibility? Here is my rough understanding of what we would need: 1) Some method for "default superclasses." This would solve the AMP issue. 2) A method for factoring existing classes into two (or more) parts. This would solve the MonadFail problem. 3) A method for imposing extra superclass constraints on a class. This would be needed for full Num compatibility. Seems much less important that 1 and 2. The most thought has gone into 1. Are these three technical capabilities *all* that we would need? Perhaps we also need a way to tie the current language (-XHaskell98, -XHaskell2010) to a particular implementation of the Prelude. Geoff From spam at scientician.net Thu Oct 22 17:59:35 2015 From: spam at scientician.net (Bardur Arantsson) Date: Thu, 22 Oct 2015 19:59:35 +0200 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <56291FBA.1000604@apeiron.net> References: <87io6zmr2x.fsf@gnu.org> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> <5628E4D2.5040904@apeiron.net> <5629027F.2070607@apeiron.net> <562915F3.5000505@apeiron.net> <56291FBA.1000604@apeiron.net> Message-ID: On 10/22/2015 07:41 PM, Geoffrey Mainland wrote: > On 10/22/2015 01:29 PM, Edward Kmett wrote: >> On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland >> > wrote: >> >> >> I am not against changing the Prelude! But it sure would be nice if >> -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a >> Haskell 2010 Prelude, both of which could be used with external >> packages >> that themselves used the more modern Prelude. >> >> >> It would definitely be a preferable state of affairs. Unfortunately, >> at least with the tools available to us today, such a plan is >> incompatible with any plan that introduces a new superclass. It also >> cuts off plans that ever factors an existing class into two, such as >> the MonadFail proposals. We simply do not at this time have the >> technical capabilities that would support such a system. If they >> showed up in GHC we can adapt plans to fit. > > Great! > > Could we work to characterize what technical capabilities we would need > to support full backwards Prelude compatibility? > It's basically the stuff that never materialized in 10 years until people got fed up with the situation and voted AMP through even though it would cause (limited) breakage. > Here is my rough understanding of what we would need: > > 1) Some method for "default superclasses." This would solve the AMP issue. > > 2) A method for factoring existing classes into two (or more) parts. > This would solve the MonadFail problem. > > 3) A method for imposing extra superclass constraints on a class. This > would be needed for full Num compatibility. Seems much less important > that 1 and 2. > > The most thought has gone into 1. > > Are these three technical capabilities *all* that we would need? Perhaps > we also need a way to tie the current language (-XHaskell98, > -XHaskell2010) to a particular implementation of the Prelude. > You say "all" as if a) it's easy (hint: it's all highly non-trivial), b) anybody's actually going to do the work. Look, we'd all like unicorns and rainbows, but clearly nobody's done the required work[1], and a lot of people were getting fed up with the status quo. Just wishing that this will happen won't make it so, and frankly, downplaying the difficulty seems like an attempt to veto any change. Regards, [1] Understandable, given the highly non-trivial nature of it. From ekmett at gmail.com Thu Oct 22 18:25:31 2015 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 22 Oct 2015 14:25:31 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <56291FBA.1000604@apeiron.net> References: <87io6zmr2x.fsf@gnu.org> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> <5628E4D2.5040904@apeiron.net> <5629027F.2070607@apeiron.net> <562915F3.5000505@apeiron.net> <56291FBA.1000604@apeiron.net> Message-ID: On Thu, Oct 22, 2015 at 1:41 PM, Geoffrey Mainland wrote: > On 10/22/2015 01:29 PM, Edward Kmett wrote: > > On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland > > > wrote: > > > > > > I am not against changing the Prelude! But it sure would be nice if > > -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 gave me a > > Haskell 2010 Prelude, both of which could be used with external > > packages > > that themselves used the more modern Prelude. > > > > > > It would definitely be a preferable state of affairs. Unfortunately, > > at least with the tools available to us today, such a plan is > > incompatible with any plan that introduces a new superclass. It also > > cuts off plans that ever factors an existing class into two, such as > > the MonadFail proposals. We simply do not at this time have the > > technical capabilities that would support such a system. If they > > showed up in GHC we can adapt plans to fit. > > Great! > > Could we work to characterize what technical capabilities we would need > to support full backwards Prelude compatibility? > > Here is my rough understanding of what we would need: > > 1) Some method for "default superclasses." This would solve the AMP issue. > > 2) A method for factoring existing classes into two (or more) parts. > This would solve the MonadFail problem. > > 3) A method for imposing extra superclass constraints on a class. This > would be needed for full Num compatibility. Seems much less important > that 1 and 2. > > The most thought has gone into 1. > > Are these three technical capabilities *all* that we would need? Perhaps > we also need a way to tie the current language (-XHaskell98, > -XHaskell2010) to a particular implementation of the Prelude. > I don't have a concrete plan here. I'm not even sure one can be achieved that works. I'd say that the burden of figuring out such a thing falls on the party that can create a plan, pitch it to the community and potentially implement it. If I enumerate a set of conditions here I'm basically implying that I'd agree to any plan that incorporated them. I'm just not prepared to make that commitment sight-unseen to something with unknown warts and implications. I can, however, say that it is plausible that what you have enumerated above could potentially address the outstanding issues, but I don't know how good of a compromise the result would be. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekmett at gmail.com Thu Oct 22 18:44:54 2015 From: ekmett at gmail.com (Edward Kmett) Date: Thu, 22 Oct 2015 14:44:54 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <560D8DA4.2080706@gmail.com> <560E57D1.9060302@nottingham.ac.uk> <6C299172-B95C-44C0-A664-F92AD11218B6@me.com> <51D97467-87F0-410C-A3BB-DA569E8C370E@me.com> <1298EBE6-BA40-424D-8CF6-D7FBF4D91D12@kent.ac.uk> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> Message-ID: On Thu, Oct 22, 2015 at 1:37 PM, Gregory Collins wrote: > > On Wed, Oct 21, 2015 at 11:40 PM, Edward Kmett wrote: > >> All I'm saying is that if we want to appeal to or cater to working >>> software engineers, we have to be a lot less cavalier about causing more >>> work for them, and we need to prize stability of the core infrastructure >>> more highly. That'd be a broader cultural change, and that goes beyond >>> process: it's policy. >>> >> >> The way things are shaping up, we've had 17 years of rock solid stability >> > > I have >95% confidence that all of the C++ programs I wrote 15 years ago > would build and work if I dusted them off and typed "make" today. I have > Haskell programs I wrote last year that I probably couldn't say that about. > > So I don't buy that, at all, at least if we're discussing the topic of the > stability of the core infrastructure in general rather than changes being > made to the Prelude. It's been possible to write to Haskell 98 without too > much breakage, yes, but almost nobody actually does that; they write to > Haskell as defined by GHC + the boot libraries + Haskell platform + > Hackage, IMO with decreasing expectations of stability for each. The core > set breaks a lot. > I definitely agree here. We have a lot of libraries in the Haskell Platform that have fairly liberal change policies. On the other hand, we have a policy of "maintainer decides" around issues. This yields a fairly decentralized change management process, with different maintainers who have different views. The Platform gives us a central pool of packages that are generally the "best of breed" in their respective spaces, but gives us few stability guarantees. Heck, every release I wind up having to change whatever code I have that uses template-haskell or Typeable. On the other hand, it isn't clear with a larger "core" platform with harder stability guarantees that we have a volunteer force that can and would sign up for the long slog of maintenance without that level of autonomy. > We definitely shouldn't adopt a posture to breaking changes as > conservative as the C++ committee's, and literally nobody in the Haskell > community is arguing against breaking changes in general, but as I've > pointed out, most of these breakages could have been avoided with more > careful engineering, and indeed, on many occasions the argument has been > made and it's fallen on deaf ears. > I would argue that there are individual maintainers that give lie to that statement. In many ways Johan himself has served as a counter-example there. The libraries he has maintained have acted as a form of bedrock with long maintenance windows. On the other hand, the burden of maintaining that stability seems to have ultimately burned him out. They can speak for themselves but I think for Mark and Johan, this is a > "straw that broke the camel's back" issue rather than anything to do with > the merits of removing return from Monad. I think the blowback just happens > to be so much stronger on MRP because the breaking change is so close to > the core of the language, and the benefits are so nebulous. fixing an > aesthetic problem has almost zero practical value > I personally don't care about the return side of the equation. Herbert's MRP proposal was an attempt by him to finish out the changes started by AMP so that a future Haskell Report can read cleanly. Past reports have been remarkably free of historical baggage. I'd personally readily sacrifice "progress" there in the interest of harmony. Herbert as haskell-prime chair possibly feels differently. > and ">> could be slightly more efficient for some monads" is pretty weak > sauce. > The issue right now around (>>) is that it has knock-on effects that run pretty far and wide. "Weak sauce" or not, it means through second order consequences that we can't move the useless mapM and sequence to the top level from their current status as memberrs of Traversable and that users have to care about which of two provably equivalent things that they are using, at all times. It means that code that calls mapM will be less efficient and that mapM_ behaves in a manner with rather radically different space and time behavior than mapM today and not in a consistently good way. -Edward -------------- next part -------------- An HTML attachment was scrubbed... URL: From mainland at apeiron.net Thu Oct 22 19:06:32 2015 From: mainland at apeiron.net (Geoffrey Mainland) Date: Thu, 22 Oct 2015 15:06:32 -0400 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: References: <87io6zmr2x.fsf@gnu.org> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> <5628E4D2.5040904@apeiron.net> <5629027F.2070607@apeiron.net> <562915F3.5000505@apeiron.net> <56291FBA.1000604@apeiron.net> Message-ID: <562933B8.3020207@apeiron.net> On 10/22/2015 02:25 PM, Edward Kmett wrote: > > On Thu, Oct 22, 2015 at 1:41 PM, Geoffrey Mainland > > wrote: > > On 10/22/2015 01:29 PM, Edward Kmett wrote: > > On Thu, Oct 22, 2015 at 12:59 PM, Geoffrey Mainland > > > >> wrote: > > > > > > I am not against changing the Prelude! But it sure would be > nice if > > -XHaskell98 gave me a Haskell 98 Prelude and -XHaskell2010 > gave me a > > Haskell 2010 Prelude, both of which could be used with external > > packages > > that themselves used the more modern Prelude. > > > > > > It would definitely be a preferable state of affairs. Unfortunately, > > at least with the tools available to us today, such a plan is > > incompatible with any plan that introduces a new superclass. It also > > cuts off plans that ever factors an existing class into two, such as > > the MonadFail proposals. We simply do not at this time have the > > technical capabilities that would support such a system. If they > > showed up in GHC we can adapt plans to fit. > > Great! > > Could we work to characterize what technical capabilities we would > need > to support full backwards Prelude compatibility? > > Here is my rough understanding of what we would need: > > 1) Some method for "default superclasses." This would solve the > AMP issue. > > 2) A method for factoring existing classes into two (or more) parts. > This would solve the MonadFail problem. > > 3) A method for imposing extra superclass constraints on a class. This > would be needed for full Num compatibility. Seems much less important > that 1 and 2. > > The most thought has gone into 1. > > > Are these three technical capabilities *all* that we would need? > Perhaps > we also need a way to tie the current language (-XHaskell98, > -XHaskell2010) to a particular implementation of the Prelude. > > > I don't have a concrete plan here. I'm not even sure one can be > achieved that works. I'd say that the burden of figuring out such a > thing falls on the party that can create a plan, pitch it to the > community and potentially implement it. > > If I enumerate a set of conditions here I'm basically implying that > I'd agree to any plan that incorporated them. I'm just not prepared to > make that commitment sight-unseen to something with unknown warts and > implications. > > I can, however, say that it is plausible that what you have enumerated > above could potentially address the outstanding issues, but I don't > know how good of a compromise the result would be. > > -Edward I don't have a concrete plan either, not am I sure that one is possible. But I don't see how having a conversation about how one might achieve backwards compatibility would commit anyone to anything. Any eventual proposal would have to go through the same approval process as every other proposal. And even if we did have a hypothetical draft proposal that you had at some point stated you approved of in some way, you would always be free to change your mind! Isn't the libraries list exactly where this sort of conversation should happen? Cheers, Geoff From simonpj at microsoft.com Thu Oct 22 19:14:18 2015 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 22 Oct 2015 19:14:18 +0000 Subject: Breaking Changes and Long Term Support Haskell In-Reply-To: <562933B8.3020207@apeiron.net> References: <87io6zmr2x.fsf@gnu.org> <5626DEDD.8040202@apeiron.net> <56274BC2.20507@nottingham.ac.uk> <562765FE.6070808@nottingham.ac.uk> <22B950C955F8AB4196E72698FBD00002D02A23AF@UKWPISXMB01B.zone1.scb.net> <5627A4A8.7070107@apeiron.net> <56280F3A.7070902@apeiron.net> <5628E4D2.5040904@apeiron.net> <5629027F.2070607@apeiron.net> <562915F3.5000505@apeiron.net> <56291FBA.1000604@apeiron.net> <562933B8.3020207@apeiron.net> Message-ID: <299e396754324ef298bbd711a19aa636@DB4PR30MB030.064d.mgd.msft.net> | > Are these three technical capabilities *all* that we would need? | > Perhaps | > we also need a way to tie the current language (-XHaskell98, | > -XHaskell2010) to a particular implementation of the Prelude. | > | > | > I don't have a concrete plan here. I'm not even sure one can be | > achieved that works. I'd say that the burden of figuring out such a | > thing falls on the party that can create a plan, pitch it to the | > community and potentially implement it. In fact there is more than one concrete plan: https://ghc.haskell.org/trac/ghc/wiki/IntrinsicSuperclasses All are complex, only partially designed, entirely unimplemented (and the implementation will be non-trivial), and lacking an active champion. The one I link to above is probably the leading contender, but it feels too complicated to me. Simon