Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`

[Malcolm Wallace]

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