I have used Haskell for teaching for years. Until recently, I taught the hierarchy using a semigroup model. Functor <- Apply <- Applicative Apply <- Bind <- Monad https://github.com/NICTA/course/tree/ee8d1a294137c157c13740ac99a23a5dd5870b4... I did this because it means curious students don't need to receive an explanation of the historical accidents of Haskell had I modelled it in accordance with Haskell pre-AMP. Doing so has caused confusion (I tried it, many years ago). Since AMP implementation, I have changed the hierarchy to be the same as Haskell proper, since the benefit has become worth doing. https://github.com/NICTA/course/issues/164 I am in favour of breaking changes as hard as you can, if it achieves a progressive benefit, even a small one, which this does. It also achieves an incidental benefit in the context of teaching. As it stands for industry use, I remove Prelude and model all this properly anyway. It is a significant effort, but way worth it e.g. do not require return to use do-notation. The penalty for having to do this is often under-estimated. "Breaking changes" is over-stated. Patience. I am waiting. On 05/10/15 19:30, Malcolm Wallace wrote:
On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be less well disposed to reviewing papers that use Haskell, and less well disposed to collaborating on writing papers that involve Haskell.
Please can the Haskell Prime Committee take into account the views of such "peripheral" users of the language, who after all, form some measure of its recent "success". Haskell is a real-world tool for many people, and breakage of their code, and their sources of information about Haskell, is a powerful disincentive to continue with it.
Regards, Malcolm
On 5 Oct 2015, at 10:05, Malcolm Wallace wrote:
I am also a strong -1 on small changes that break huge numbers of things for somewhat trivial benefits.
Regards, Malcolm
On 2 Oct 2015, at 11:09, Henrik Nilsson wrote:
Hi all,
I have discussed the monad of no return proposal with my colleague Graham Hutton: a long-standing member of the Haskell community, well-known researcher, some 20 years of experience of teaching Haskell to undergraduate students, and author of one of the most successful introductory Haskell textbooks there are.
The upshot of this e-mail is a strong collective -2 from us both on particular proposal, and a general call for much more caution when it comes to breaking changes that are not critically important.
First, on a general note, there has recently been a flurry of breaking changes to the (de facto) Haskell standards. In many cases for very good reasons, but sometimes it seems more in a quest for perfection without due consideration for the consequences. It used to be the case that breaking changes were very rare indeed. And for good reason.
Right now, the main "measure of breakage" in the on-line discussions seems to be how many packages that break in Hackage. Which of course makes sense: the Hackage repository is very important and such a measure is objective, as far as it goes.
But we should not forget that breakage can go far beyond Hackage. For starters, there is *lots* of code that is not in Hackage, yet critically important to its users, however many or few they are. There are more than hundreds of thousands of copies of books out there where that may break in that examples may no longer work. And they cannot be changed. There are countless research papers that may break in the same way. Every single institution that use Haskell in their teaching may have to update their teaching materials (slides, code, lab instructions) for every module that teaches or uses Haskell. And last but not the least, what countless of programmers and students have learned about Haskell over decades, most of whom are *not* power users who can take these changes in their stride, may also break.
Now, of course a language has to evolve, and sometimes breaking backwards compatibility is more or less essential for the long-term benefit of the language. But we should not let perfection be the enemy of the good.
As to this particular proposal, the monad of no return, it does not seem essential to us, but mostly motivated by a quest for "perfection" as defined by a very knowledgeable but in relative terms small group of people.
One argument put forward was that applicative code that uses "return" instead of "pure" should get a less constrained type. But such code is relatively new. The methods of the Monad class have been return and bind for some 25 years. So indeed, as Henning Thielemann wrote: why should not the newer code be adapted and use "pure" instead? In fact, the use of "pure" in such code could serve as a quite useful cue that the code is applicative rather than monadic, especially where applicative do is employed.
Another reason put forward is support for the applicative do syntax. But that is, in standard terms, only a future possibility at this point. Further, the syntax is arguably rather dubious anyway as it, in particular to someone with an imperative background, suggests a sequential reading which is exactly what applicative is not and why it is useful. So from that perspective, using the applicative operators directly, without any syntactic sugar, actually amounts to a much more transparent and honest syntax, even if a bit more verbose in some cases.
The bottom line is that it is premature to put forward support for the applicative do syntax as a rationale for a non-essential breaking change.
Best regards,
Henrik Nilsson and Graham Hutton
-- Henrik Nilsson School of Computer Science The University of Nottingham nhn@cs.nott.ac.uk
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime