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@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.