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@haskell.org] On Behalf Of Henrik Nilsson Sent: 06 October 2015 12:33 To: haskell-prime@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@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@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/financialmarke... for important information with respect to derivative products.