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

[David Feuer]

I take your concerns about unnecessary breaking changes seriously. And it
is certainly true that a large amount of existing code will break. However,
I am not at all convinced that the "mental weight" of this change is nearly
as great as that of the now-accomplished AMP, in the presence of good error
messages. Someone reading a classic article on Haskell who writes out their
Monad instance will already be informed that they need to first cough up an
instance of a class that article has no information about. An additional
error message telling them to please delete a single binding hardly seems
onerous in comparison.

I think removing error-prone redundancy is a good thing. While I expect
there are few return/pure mismatches, they are certainly possible. The most
likely scenario, I imagine, involves a difference in strictness when
someone erroneously thinks they can get away with

Applicative f => Applicative (t f)

when in fact they need

Monad f => Applicative (t f)

to obey pure = return in that particular case.
On Oct 2, 2015 9:01 PM, "Henrik Nilsson" <Henrik.Nilsson at nottingham.ac.uk>
wrote:

> 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.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20151002/8be53461/attachment.html>