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

[Malcolm Wallace]

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