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"
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@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries