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/ee8d1a294137c157c13740ac99a23a5dd5870b4a/src/Course 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 >>>> n...@cs.nott.ac.uk >>> >> > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
