<p dir="ltr">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.</p>
<p dir="ltr">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</p>
<p dir="ltr">Applicative f => Applicative (t f)</p>
<p dir="ltr">when in fact they need</p>
<p dir="ltr">Monad f => Applicative (t f)</p>
<p dir="ltr">to obey pure = return in that particular case.</p>
<div class="gmail_quote">On Oct 2, 2015 9:01 PM, "Henrik Nilsson" <<a href="mailto:Henrik.Nilsson@nottingham.ac.uk">Henrik.Nilsson@nottingham.ac.uk</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Bardur Arantsson wrote:<br>
<br>
> I should also say: I certainly *understand* the<br>
> textbook argument, [...] but this is not a good<br>
> *general* argument against change.<br>
<br>
Just to be clear, Graham and I were not at all arguing<br>
against change in general. But we are, in general,<br>
urging extreme caution when it comes to non-essential<br>
breaking changes.<br>
<br>
Measuring breakage by referring to Hackage is just the<br>
tip of the iceberg. Much breakage, including<br>
proprietary code, books, research papers, what people<br>
have learned, is very difficult or impossible to<br>
measure. Somehow this point seems to have been<br>
forgotten in the present discussion. The reason there<br>
has to be really compelling reasons for adopting<br>
breaking changes is exactly because the full impact of<br>
those breaking changes is very hard to gauge properly. As<br>
to this specific proposal, in our opinion, the reasons<br>
put forward so far for the "monad of no return" are not<br>
very compelling. And therefore it should not be adopted<br>
at this point.<br>
<br>
> Have you surveyed the actual number of books out<br>
> there which show how to implement Monad instances and<br>
> how many of them would be affected?<br>
<br>
No. we have not. But ought not the burden of proof rest<br>
with those who are proposing a non-essential breaking<br>
change? If not, why not?<br>
<br>
> but if we're going that way, then we're going to end<br>
> up like C++... before C++11/C++14. [...] (stagnatiation)<br>
<br>
We are hardly going to end up like C++ in that sense by<br>
being very careful before adopting non-essential<br>
breaking changes. Or even rule them out. Nor, returning<br>
to this specific proposal, is leaving "return" as a<br>
method of "Monad" going to mean that Haskell ends<br>
up being stagnant.<br>
<br>
Further, it is also worth noting that by almost any<br>
measure C++ is an extremely successful language despite<br>
its warts.<br>
<br>
> "Verbose" is the understatement of the year. There's<br>
> a lot of code where ApplicativeDo makes the<br>
> difference between "readable" and "unreadable". Like<br>
> it or not, but programmers are used to *naming<br>
> things* (even locally) and using those local names to<br>
> refer to things.<br>
<br>
If so, suggesting that programmers necessarily want to<br>
name things is the sweeping generalisation of the year.<br>
<br>
For example, I have written quite a bit of applicative<br>
code, way before it was even called applicative, and I<br>
did not find the lack of syntactic support particularly<br>
bothersome. On the other hand, I have also written a<br>
lot of arrowized code, and there, while I do use the<br>
syntactic sugar to allow me to name certain things, the<br>
fact that I then have to name everything is rather<br>
annoying to say the least, and I have often found<br>
myself wishing that I could write arrowized code that<br>
looked a lot more like applicative code (without the<br>
sugar).<br>
<br>
For a very different example, function composition,<br>
maps, and folds are all examples of constructs<br>
in common use where programmers opt to not name<br>
intermediate things.<br>
<br>
Anyway, a discussion about the pros and cons of<br>
applicative do entitrely tangential to the point being<br>
made. The point is that applicative do is not yet part<br>
of any Haskell standard, and at this point it is not<br>
clear what any future syntactic support for applicative<br>
code will look like exactly. Therefore is premature to<br>
use this as an argument for this particular proposal,<br>
making any such an argument a weak one. Removal of<br>
"return" as a method of Monad can clearly wait until<br>
such time that syntactic support for applicative code<br>
makes it into the language, if it then is found that<br>
that support, whatever it looks like, would be<br>
unworkable without this change.<br>
<br>
Further, I reiterate that if people writing applicative<br>
code were to use "pure" instead of "return", which does<br>
not at all seem unreasonable, the stated problem goes<br>
away. And such a change would clearly have far less<br>
impact on legacy code, text books, teaching material,<br>
what many programmers have learned simply by virtue of<br>
the fact that Applicative in its current form is a very<br>
recent addition.<br>
<br>
Bottom line: Breaking changes should only be adopted<br>
for very compelling reasons. The reasons put forward<br>
for far for "monad of no return" fails to meet that<br>
standard. Therefore it should not be adopted, at least<br>
not at this time.<br>
<br>
/Henrik<br>
<br>
-- <br>
Henrik Nilsson<br>
School of Computer Science<br>
The University of Nottingham<br>
<a href="mailto:nhn@cs.nott.ac.uk" target="_blank">nhn@cs.nott.ac.uk</a><br>
<br>
<br>
<br>
<br>
This message and any attachment are intended solely for the addressee<br>
and may contain confidential information. If you have received this<br>
message in error, please send it back to me, and immediately delete it. <br>
Please do not use, copy or disclose the information contained in this<br>
message or in any attachment.  Any views or opinions expressed by the<br>
author of this email do not necessarily reflect the views of the<br>
University of Nottingham.<br>
<br>
This message has been checked for viruses but the contents of an<br>
attachment may still contain software viruses which could damage your<br>
computer system, you are advised to perform your own checks. Email<br>
communications with the University of Nottingham may be monitored as<br>
permitted by UK legislation.<br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>