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

[Henrik Nilsson]

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




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.