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

[Henrik Nilsson]

Hi all,

Bardur Arantsson wrote:

 > I should also say: I certainly *understand* the
 > textbook argument, [...] but this is not a good
 > *general* argument against change.

Just to be clear, Graham and I were not at all arguing
against change in general. But we are, in general,
urging extreme caution when it comes to non-essential
breaking changes.

Measuring breakage by referring to Hackage is just the
tip of the iceberg. Much breakage, including
proprietary code, books, research papers, what people
have learned, is very difficult or impossible to
measure. Somehow this point seems to have been
forgotten in the present discussion. The reason there
has to be really compelling reasons for adopting
breaking changes is exactly because the full impact of
those breaking changes is very hard to gauge properly. As
to this specific proposal, in our opinion, the reasons
put forward so far for the "monad of no return" are not
very compelling. And therefore it should not be adopted
at this point.

 > Have you surveyed the actual number of books out
 > there which show how to implement Monad instances and
 > how many of them would be affected?

No. we have not. But ought not the burden of proof rest
with those who are proposing a non-essential breaking
change? If not, why not?

 > but if we're going that way, then we're going to end
 > up like C++... before C++11/C++14. [...] (stagnatiation)

We are hardly going to end up like C++ in that sense by
being very careful before adopting non-essential
breaking changes. Or even rule them out. Nor, returning
to this specific proposal, is leaving "return" as a
method of "Monad" going to mean that Haskell ends
up being stagnant.

Further, it is also worth noting that by almost any
measure C++ is an extremely successful language despite
its warts.

 > "Verbose" is the understatement of the year. There's
 > a lot of code where ApplicativeDo makes the
 > difference between "readable" and "unreadable". Like
 > it or not, but programmers are used to *naming
 > things* (even locally) and using those local names to
 > refer to things.

If so, suggesting that programmers necessarily want to
name things is the sweeping generalisation of the year.

For example, I have written quite a bit of applicative
code, way before it was even called applicative, and I
did not find the lack of syntactic support particularly
bothersome. On the other hand, I have also written a
lot of arrowized code, and there, while I do use the
syntactic sugar to allow me to name certain things, the
fact that I then have to name everything is rather
annoying to say the least, and I have often found
myself wishing that I could write arrowized code that
looked a lot more like applicative code (without the
sugar).

For a very different example, function composition,
maps, and folds are all examples of constructs
in common use where programmers opt to not name
intermediate things.

Anyway, a discussion about the pros and cons of
applicative do entitrely tangential to the point being
made. The point is that applicative do is not yet part
of any Haskell standard, and at this point it is not
clear what any future syntactic support for applicative
code will look like exactly. Therefore is premature to
use this as an argument for this particular proposal,
making any such an argument a weak one. Removal of
"return" as a method of Monad can clearly wait until
such time that syntactic support for applicative code
makes it into the language, if it then is found that
that support, whatever it looks like, would be
unworkable without this change.

Further, I reiterate that if people writing applicative
code were to use "pure" instead of "return", which does
not at all seem unreasonable, the stated problem goes
away. And such a change would clearly have far less
impact on legacy code, text books, teaching material,
what many programmers have learned simply by virtue of
the fact that Applicative in its current form is a very
recent addition.

Bottom line: Breaking changes should only be adopted
for very compelling reasons. The reasons put forward
for far for "monad of no return" fails to meet that
standard. Therefore it should not be adopted, at least
not at this time.

/Henrik

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