On Fri, Oct 2, 2015 at 8:31 PM, Henrik Nilsson
Further, it is also worth noting that by almost any measure C++ is an extremely successful language despite its warts.
Ah, success at the cost of warts. I see our priorities as a community have changed.
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.
…
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.
`return` should have never been a part of the `Monad` type class. It does not belong there any more than `fail` does. We could discuss (in a separate thread) whether `pure` should be named `return`. We could likewise discuss whether it should be in some separate class like the often-suggested `Point` with whatever name. We could likewise discuss where that class should lie in the hierarchy. In a post-AMP Haskell, however, retaining `return` in `Monad` does not serve any purpose: any `Monad` instance requires an `Applicative` instance, wherein `pure` must be defined, and it is a law required by all instances that they behave identically. The only expressive purpose of `return` being in the `Monad` type class is providing an opportunity to break the laws the community expects for all instances of `Monad`. This community rightly values statically eliminating opportunities for errors, and the removal of `return` as a method of `Monad` serves this purpose. This is reason alone to implement this proposal, even in the absence of `ApplicativeDo`.