User talk:Backfromquadrangle

Welcome to Wikibooks, Backfromquadrangle!

 First steps tutorial Wikibooks is for collaborative development of free textbooks.

You do not need technical skills to contribute. You can easily change most books. Please introduce yourself, and let us know what interests you.

If you already contribute at other Wikimedia projects, our Wikimedia Orientation should quickly get you started. (Would you like to provide feedback on this message?)

  Getting help   Made a mistake?   Goodies, tips and tricks
 * Read the Using Wikibooks book for a friendly introduction to the project, or our help pages for more information.
 * You can get friendly help from the community in the user assistance room or our IRC channel.
 * Upload freely licensed files to Wikimedia Commons. You may request permission to upload fair use files locally. Please include author and source information and a non-free use rationale for non-free files.
 * You can restore a previously saved version.
 * Pages should follow the  naming convention.
 * Need to rename a page? Use the move tab (is available once your account is 4 days old - until then, ask for help).
 * To request a page be deleted, add to the top of the page.
 * Was a page you made deleted? Please read the deletion policy, and check the deletion log to find out why. Also check the RFD archives if applicable. You can request undeletion at WB:RFU, or ask the administrator who deleted the page.
 * Please fill in the edit summary and preview your edits before saving.
 * Sign your name on discussion pages by typing &#126;&#126;&#126;&#126;
 * User scripts can make many tasks easier. Look at the Gadgets tab of my preferences; check off the boxes for the scripts you want, and hit save!

A bonus welcome from the Haskell Wikibook
Hello and welcome! Thank you for the judicious changes to the early chapters of the Haskell book. Should you feel like sharing opinions and criticism, I will be most pleased to discuss it. Cheers, Duplode (discuss • contribs) 07:17, 19 November 2013 (UTC)

Variables and Functions and source files
Hello,

I have been reading the changes you just did to Getting Set Up and Variables and Functions, and I'm not sure that introducing source files in Getting Set Up is a good idea. I can see how the digression in Variables and Functions might be a little distracting, and that Getting Set Up is quite short right now. Still, I feel it would be best to introduce source files with a concrete example, such as those in Variables and Functions. --Duplode (discuss • contribs) 15:52, 23 April 2014 (UTC)

I agree with your concern here. I was very hesitant to make the change, but I had my wife look over the page and she was confused about the instructions regarding directories and things. I don't think my solution was perfect, but it came across clearly that she didn't understand the stuff with YourFileHere, and so I was trying to address that, and this shift seemed the best compromise. That said, I'm not suggesting the way I did is the best long-term answer. I think there's need to improve from here. I thought about just doing the directory creation on the set up chapter and leaving the file creation stuff on the other page. Mostly I was unsure about the balance between set-up of directories… I agree that we want something concrete to do with the first file. What if we went with putting the first code on the set-up page and then just say "remember that code? let's run it…" on the next chapter? Backfromquadrangle (discuss • contribs) 16:06, 23 April 2014 (UTC)


 * One way that might work would be by writing, in Getting Set Up, something akin to "now, calculators often have a memory function to store partial results", then show  and how to put that in a source file. However, it seems that by doing so we would end up either splitting the discussion arbitrarily between the chapters or merging Getting Set Up and Variables and Functions. That being so, I will tentatively move back the section to Variables and Functions. I will preserve most of your changes to the text, though - you two are certainly right about the earlier version being confusing!


 * P.S.: In an unrelated note, as you went through the first Type Basics chapter you possibly noted it is a bit messy. Reorganizing it to make it leaner and clearer is high in my to-do list (I just need to finish this draft beforehand); so if you have suggestions for improvement I would love to hear, or see, them. --Duplode (discuss • contribs) 02:09, 24 April 2014 (UTC)

A public watchlist of sorts
Here is something you might find useful. Monitoring talk pages of a Wikibook is a pain, as there is no automated way of doing it. To make things a little better, I have been using User:Duplode/Haskell/Public watchlist. It is just a list links to all pages and talk pages within the Haskell namespace, based on the output of Special:PrefixIndex. Through the Related Changes tool, it can be used to monitor all activity in the book within the previous 30 days. I didn't move it to the Haskell namespace yet because I still have some hope of finding an automated solution (it seems possible to do it using Lua modules, though I still haven't tried it). --Duplode (discuss • contribs) 06:19, 28 April 2014 (UTC)

Notes about the monad chapters
Now that you got to the monad chapters, I should tell you about a few quirks they have:


 * Understanding Monads: the terseness of that chapter is a side effect of a decision not to use metaphors or flawed approximations (e.g. "a monad is a container") to introduce monads, and just show them for what they are. Unlike a number of past attempts to make the pace of the chapter gentler, your extra explanations do not break that imperative (heh). The only substantial adjustment I will try to make is to find a compromise that neither assumes the reader is familiar with imperative languages (as it was before your changes) nor takes focus out of the "monads as imperative languages" perspective (which is one of the high-level explanations which is not flawed). The extra discussion about  (starting with "Does that mean we should always use   for everything?") was an interesting idea. I think it would be useful to prepare the discussion by pointing out somewhere earlier, perhaps in More on Datatypes, that whenever you see   in a function signature it indicates optionality (if in an argument) or possibility of failure (if in a result), or something along those lines. Finally, be careful not to say that something "returns a monad"; for clarity and accuracy we should stick to "returns a monadic value".


 * Thanks so much! I certainly was hoping and expecting that my changes would be cleaned up by those who know more than me. I have no real experience with imperative languages so it was hard to tell what was just misleading (bad assumptions about the reader's background) or what was really a valid and important point about monads. As you'll see, I did not do *anything* with the stupid concept of metaphors for monads, I understand that they are just abstractions. I *don't* understand why other people think they are so weird or magical or anything. I'll be careful about the "returns a monad" thing and avoid that. Thanks for the tip.Backfromquadrangle (discuss • contribs) 00:21, 2 May 2014 (UTC)


 * The adjustments are done. On the one hand, I largely restored the old Notions of Computation section, with a few wording adjustments and an extra note on what is meant by semantics. On the other hand, this discussion made me realize it would be good to have a section discussing in more detail the relation between functional and imperative in monadic code, in order to dispel a common misunderstanding about monads (that they are somehow not functional, or that  notation directly involves imperative sequencing of statements). Since it was slightly too digressive for this chapter, I added it to the IO monad chapter instead. As for the note on , I rephrased it and moved it to the Maybe monad chapter. Please do adjust it and/or tell me if you think it became confusing.--Duplode (discuss • contribs) 15:15, 2 May 2014 (UTC)


 * Yeah, I really don't understand the precise imperative aspects of monads. All I knew for certain was that all of the statements were wrong when they said IO or monads are impure or fundamentally imperative or something. So I went for deleting those incorrect things but had no idea what the scope of correct things would be to replace them. Some of what you put back is still confusing to me, so I added a comment on the page's talk page. I very much like your rewrite and moving of the Maybe stuff, by the way. Thanks Backfromquadrangle (discuss • contribs) 18:45, 2 May 2014 (UTC)


 * I believe the key point (and it is a quite subtle one!) is that, given that semantics (what you mean to do) and implementation (how it is done) are separate things, monads can be functional and imperative at the same time, only at different levels. Looking at the issue from the other side of the fence: while some imperative and object-oriented languages can accommodate functional programmers rather well, others lack key features such as lambdas and higher order functions. You can certainly write code with functional semantics in them, but you will have to jump through a lot of hoops. As for Haskell, it allows you to express imperative semantics in functional code through monads, in a way that feels reasonably natural. That said, you don't have to take the imperative perspective ( looks functional enough to me!), but sometimes it can be an useful point of view.


 * I tried to address the confusing sections you mentioned. I wonder if it would be useful to spend a paragraph or two somewhere else to make sure the readers know what we are talking about when we say a language is imperative? Perhaps in Building Vocabulary, next to the discussion about function composition. That chapter has a lot of fluff anyway, so I guess adding a little more would not hurt.--Duplode (discuss • contribs) 04:14, 3 May 2014 (UTC)


 * Go for it. I think everything is better now already, but some explanation of what imperative means would be a positive addition, in my opinion.


 * State: the way the chapter is currently organised (motivation, then full explanation of  and only then working out an example from scratch) leads to a a fair amount of redundancy. Reordering might make it easier to remove some nearly duplicated material.


 * Practical Monads: I believe that, short of a full rewrite, there is little hope of improving that chapter. It consists of an untidy Write Yourself a Scheme import, an example of dubious usefulness that doesn't even match the write-me comment by Kowey (which are about parametricity), and an interesting example which needs a lot of extra context to be understood. If you agree, you might just skip it, or even remove it from the table of contents altogether.

Duplode (discuss • contribs) 00:24, 2 May 2014 (UTC)

Field guide of the Advanced Track
A brief commentary on what you are going to find in the Advanced Track. Duplode (discuss • contribs) 19:34, 13 May 2014 (UTC)
 * Advanced Haskell
 * Monoids: See my comments on the talk page there.
 * Applicative Functors: The current text provides very little insight on what applicative functors are, or what are they good for. I will begin a rewrite ASAP (now I'm able to, as I have just finished the new chapter I was drafting).
 * Arrow Tutorial: A self-contained tutorial written one day by Stephen Blackheath (ergo the peculiar first section title, which I preserved as a hat tip) and then forgotten for years. Replaced the old practical introductory chapter about arrows.
 * Understanding Arrows: Very convoluted; needs some serious cleanup. All the "factory" and "robots" talk refers to the old, metaphor-happy version of Understanding Monads, and should be eliminated (the pretty pictures are probably useful, though).
 * Continuation Passing Style: I rewrote the conceptual first half of the chapter a few months ago, so hopefully it is not too confusing now, even though CPS is an intrinsically confusing subject.
 * MonadFix: The red link was originally under the Monads subtrack. This is more of a niche subject than everything else around it in the subtrack, so writing it is not much of a priority IMO.
 * Zippers: One of the jewels of the book. Perhaps the second half of the chapter (one of the genuinely advanced stretches in Advanced Haskell) would benefit from a few clarifications.
 * Mutable Objects: Currently a stub. Important chapter to write, covering IORefs and the ST monad. I will look into it soon.
 * Concurrency: Another stub, and another important chapter. The topic is rather vast, however, and I will only feel confident to have a go at it with a little more experience with concurrency under my belt.
 * Fun With Types: Useful information scattered throughout, but the only chapter close to completion is the one about GADTs. Adding a chapter, or a section under Advanced Type Classes, covering type families would be highly desirable.
 * Wider Theory: Pretty good material overall, which might do with a little extra polish in some places. Denotational Semantics and Category Theory are probably the two chapters of the book which most often are linked to outside of Wikibooks.
 * Performance: Most useful material currently lies in the Introduction or in the Laziness chapter. The remaining chapters are basically stubs, and the subtrack structure seems rather messy.


 * Thanks for the notes, but I don't think I'm ready to tackle much of this. I'm actually going to BayHac this weekend, so I'll learn some more there, but the stuff is starting to get over my head and/or is not good enough in its current state for me to figure out how to improve it. According to the experienced programmer on the project I'm working on, Arrows may be useful but I probably won't deal with Zippers any time, although maybe I'll read that anyway at some point. I'll try to keep doing more, but this may be where I bow out for a bit. I really appreciate all your work and your fixing up of my edits! I will keep coming back and maybe persist on later. Backfromquadrangle (discuss • contribs) 19:46, 13 May 2014 (UTC)


 * That is fine - in particular, I only mentioned the later three subtracks for the sake of completeness, as getting them up to scratch will be a major endeavour (and I also would need to study a bit more before tackling some parts). Thanks a lot for your reviewing work, it really has made a difference! I feel that the Beginners' Track is now very close to the point at which it can be recommended without hesitation as a learning resource for newbies. Have fun at BayHac!
 * P.S.:Out of curiosity, what is the project you mention (assuming it is open-source)?--Duplode (discuss • contribs) 20:19, 13 May 2014 (UTC)


 * The project is [Snowdrift.coop], and it is beyond open-source — we respect software freedom and cultural freedom to the very highest degree. Not only is the code AGPL, the writings are CC-BY-SA, we use no tracking (no Google analytics etc), and we are built exclusively with Free/Libre/Open tools. We even go so far as to recommend that volunteers who want to learn Haskell should use this Wikibook over any of the many proprietary resources! (We aren't dogmatic though, I did read Learn You A Haskell, it's just that we want to always emphasize Free/Libre/Open resources first and foremost).


 * The purpose of the project is to develop a way for people to have a decent living while doing work like you and I are doing here which adds maximum value to the world while respecting the community's freedoms.


 * Your work in making this Wikibook better is already indirectly helping us (helping me, any future volunteers who are learning, and helping Free/Libre/Open generally), so I'm very thankful to you! I mostly hope you'll continue improving this Wikibook, but if you want to make the biggest difference in what you work on coding otherwise, you could come help us build the site! We have lots of tickets, some of which are reasonably easy and small. Not only is it all in Haskell (with the Yesod framework), but there's a couple decently experienced Haskellers (who are not true experts, but compared to me they are) who are involved and happen to love tutoring new volunteers working on the project. Cheers! Backfromquadrangle (discuss • contribs) 00:25, 14 May 2014 (UTC)


 * That sounds awesome. Furthermore, I could do with learning a bit of Yesod. Right now I have my fingers in too many pies, but I will try to pay a longer visit to the project in the near future. Rock on!--Duplode (discuss • contribs) 16:56, 14 May 2014 (UTC)

Applicatives, Monads and other stuff
Hello again! How are you?

After a long while I have finally managed to return to the book - and it was good to see you around on the watchlist as well! The moment is proper: I sense a nice opportunity in that the Wikibook format allows us to react quickly to big changes such as the Applicative-Monad proposal. With that in mind, I started by doing the rewrite of Haskell/Applicative functors I promised a year ago; and so I invite you to have a look at it. Beyond improvements to the text, it also includes a reasonable number of exercises with solutions, and is GHC 7.10 compliant. It is also quite long, possibly the longest of all chapters up to that point of the book. Interestingly, however, it divides neatly into two parts of nearly the same size at the end of the ZipList section. Up to it there is introductory material, roughly correspondent to the old chapter; after it there are complementary topics at a slightly higher level of difficulty (the exercises get harder as well), including a section meant to unify the discussions about Functor, Applicative and Monad. I can easily see the chapter being divided into "Applicative functors" and "Applicative functors II".

That brings me back to the book sequencing issues we were considering a year ago. I still lean towards not moving Applicative before Monad -- the "wrong" order we currently use is a bit messier but also more accessible; furthermore, if everything else moves to the "right" order we would end up with a possibly useful differential from the other books -- though my opinion about that is not set in stone. Writing the Applicative chapter, however, gave me a crazy idea: what if we moved applicative (or at least the first half of its chapter) to the monads module? The distance between the related discussions would be lowered, and mixing Alternative into the MonadPlus chapter would become painless. I have no clue if that could be made to work, but it sounds like an interesting third option to think about. As of now, the applicative chapter for the most part assumes familiarity with monads, though it would be possible to tone it down in the first half of the text with rather few losses.

Over the next few weeks at least I shall keep working on the book. My next targets include cleaning up the State chapter and writing on Foldable and Traversable (which reminds me of the question about what to do with Monoids...) I would love to hear your thoughts on those issues!

Cheers, Duplode (discuss • contribs) 11:34, 4 July 2015 (UTC)


 * I'm still a beginner in many respects and have been editing mostly to reduce extraneous wordings while reviewing the basics. I look forward to getting to your updates about applicatives. I agree that the "wrong" order is okay when done for useful reasons. I think moving the first part of Applicative into the Monad chapter makes sense, thus splitting it into some sort of intro to Applicative vs later stuff. I'll try to keep pushing through and getting there. Incidentally, I liked some of the approach I saw in this series: http://andrew.gibiansky.com/blog/haskell/haskell-syntax/ (I also asked the author about licensing it freely, but we could consider some of those ideas just for reference anyway). I think I'd like to see a first-principles intro to Haskell that starts at the *very* core of the absolute minimal base of the language with no syntactic sugar and builds out from there, but I don't suggest that for the Wikibook as I like the Wikibook's approach already — it's just something complementary I'd also like to see. --Backfromquadrangle (discuss • contribs) 12:59, 4 July 2015 (UTC)


 * The series you linked to looks good indeed. For an extra data point, it is interesting to note the author goes directly from Functor to Monad, but covers Monoid before either of them. As for the first-principles intro idea, it sounds sensible. It reminds me of, back when I first started contributing here, how Apfelmus wanted to reorganize the early parts of the beginner track so that each thing was done with just one syntax variant (not necessarily the simplest). While the book is not exactly like that, it does tend introduce syntactic sugar slowly and in modest doses. By the way, your comment and link has reminded me of a very different sort of crash course: How to read Haskell like Python, a rather fun blog post by Edward Z. Yang. --Duplode (discuss • contribs) 04:21, 5 July 2015 (UTC)

Renaming chapters in Elementary Haskell
What do you think about simplifying the unwieldy chapter names in Elementary Haskell?

More about lists --> Lists II

List processing --> Lists III

Higher-order functions and currying --> Higher order functions

In the front page, the list chapters might have the subtitles "map" and "folds and comprehensions".--Duplode (discuss • contribs) 19:47, 11 July 2015 (UTC)


 * Sound great Backfromquadrangle (discuss • contribs) 21:20, 11 July 2015 (UTC)


 * Okay, now done.--Duplode (discuss • contribs) 08:25, 12 July 2015 (UTC)

What about splitting Advanced Haskell?
Now that the Foldable and Traversable chapters are, at long last, written, I'm beginning to think Advanced Haskell is becoming too large and covering too disparate topics. Dividing it might be good in the long run. I'm thinking on something along the lines of:


 * {Advanced Haskell 1: Useful type classes} (I have no clue about what the titles of the parts should be)
 * Monoids
 * Applicative functors
 * Applicative functors II (if it is divided)
 * Foldable
 * Traversable
 * {Potpourri of monads} (new chapter: quick overview of Reader, Writer, Except and the MTL classes)
 * Arrow tutorial
 * Understanding arrows


 * {Advanced Haskell 2: Important techniques}
 * {Effectful streaming} (new chapter: Pipes and/or Conduit)
 * Mutable objects (stub)
 * Concurrency (stub)
 * Continuation passing style
 * MonadFix (red link)
 * Zippers
 * Template Haskell (red link)

The division above assumes Monoids and Applicative I would not be moved to the Beginner's Track. That need not be the case, but after writing the new chapters I am leaning further towards leaving them where they are. The chapters from Monoids to Traversable are quite solidly connected to each other: Foldable is basically Monoids II, and Traversable relies heavily on both parts of Applicative and Foldable. Even the section about homomorphisms at the end of Monoids, which I expected to end up deleting at some point, proved useful to prepare discussions in Foldable and Traversable.

If we agree dividing Advanced Haskell is a good idea, it might be better to wait a little before performing the split, as too few chapters in the second part actually exist at the moment (not counting stubs, only CPS and Zippers). On the other hand, it might actually be better to do it right now, so that readers see more clearly which parts of the book are nearing completion.

Finally, the layout of the front page does not seem to be an obstacle, as this mockup of a track with five divisions indicate.

Cheers, Duplode (discuss • contribs) 16:31, 13 July 2015 (UTC)


 * Sounds good to me, I think all sorts of separate chunkings that are sensible make things more approachable to readers. I'd like better titles than "Advanced I" and "Advanced II". I'd like to see a chapter on Lens too and maybe some other advanced things… Another long-term plan: add a web-frameworks section to the Haskell In Practice track covering at least an overview of Hakyll, Snap, and Yesod (clearly the 3 most notable options) with references to others as well. Backfromquadrangle (discuss • contribs) 16:51, 13 July 2015 (UTC)


 * Great. The next thing I am going to do is rewriting Understanding Arrows, and then getting one of the "Part 2" chapters ready (probably either Mutable Objects - the easiest - or Effectful Streaming - the most important). After that, it should be OK to do the split. About the other ideas:
 * Lens: That is a whole world of its own :) but its obvious we need to tackle it at some point. There actually is a passing mention of Lens strategically placed at the very end of the Traversable chapter. Back when I was trying to understand lenses myself I wrote this explanation of van Laarhoven lenses for the layman. I can easily see an abridged version of it as the introduction to a Lens chapter here, and the discussion at the end of Traversable provides a convenient hook.
 * Web frameworks: That's another cool idea. I can picture the Hakyll chapter, for instance, as a tasty little tutorial with comments on the architectural principles of the library gently interspersed. In a short while I will have to do a rather big update on one of my Hakyll sites; it might become an opportunity to attempt it...
 * Duplode (discuss • contribs) 17:23, 13 July 2015 (UTC)

A Lenses chapter
Hello! So I followed your suggestion and started working on a chapter about lenses (I have chosen to delay effectful sttreaming a bit, as I need to study pipes a little more closely before explaining it without being confusing). Here is the draft, as it currently stands. Most of the basic text is already in place (the missing section at the end will just have some commentary on how you don't actually need to import  to define lenses, and some nods to libraries that use lenses in one way or another). I plan to finish the initial version and add it to the book by this weekend (and also make some noise on /r/haskell about it). If you have some time to spare (it is a rather long chapter), I would really appreciate your criticism. The heart of the chapter is the second section, "The scenic route to lenses" section, which approaches the subject in a way I don't recall having seen anywhere: starting from  (which in principle should feel familiar, given the chapter on Traversable), the hierarchy of optics is explored following the differences between the type synonyms until you get to lenses − after reaching them at the end of the process, they hopefully won't look so baffling anymore. Otherwise, the chapter follows the patterns we have been using along the rest of the book: focus on concepts, avoidance of metaphors and handwaving, practical advice sprinkled through the presentation of the core notions. Specific doubts I had and other self-criticism are displayed in the info boxes I left in the draft. Cheers, Duplode (discuss • contribs) 22:02, 3 September 2015 (UTC)
 * Awesome, I'll try to get to it sometime, been super busy. I've never studied lens before, so I'll be seeing how much I can understand as a total beginner. Thanks for all your work on the Wikibook!--Backfromquadrangle (discuss • contribs) 22:26, 3 September 2015 (UTC)

Applicative versus Monad. round two
It has been two months since I last wrote to you about that topic, and I have changed my mind again. It is becoming increasingly clear to me that we can't avoid some discussion of applicative functors before monads. The AMP looms large, of course, but there are several other aggravating factors:


 * In a few months from now, GHC will offer the  extension, which will be one more thing that might confuse newcomers.


 * Further into the future, but far more dramatically, there are the plans to move  out of the   class. That will likely take a few years to happen, but when it does it will become very hard to justify the current order.


 * Talking about  before   means there is no good place to discuss  . That has ripple effects on several chapters. The most alarming is probably that, as type of   was changed to use , there are wrong type signatures in the "MonadPlus" and "Monad Transformers" chapters. Another example is that not covering   is blocking the inclusion of a section about   in "Understanding Arrows", which in turn makes the discussion of the big example in the second half of that chapter incomplete.


 * Having to pretend that  and   do not exist throughout the "State Monad" chapter is very annoying. A similar issue is that it would be replace   with   in the "IO Monad" chapter.


 * The notes about  I tacked onto the end of "Understanding Monads" are quite unsightly.


 * A somewhat related issue is that currently the book only discusses functions as functors from the "Applicative Functors" chapter onward. That makes finding a place to introduce  awkward.

All of that is leading me to think of a way to introduce applicatives before monads without disturbing the chapter sequencing in the fourth and fifth units too much. What do you think about the following plan?


 * Move the recap exercises in "Applicative Functors" to their rightful place, the "Functor" chapter.


 * Add a casual (and very brief) note to the "Functor" chapter mentioning  and how it generalises  . That would make it possible to show signatures that use it (e.g.  ) without worries. (Something similar would be done when introducing   in the "IO Monad" chapter.)


 * Split "Applicative Functors" and make the first part the first chapter of the "Monads" unit (the second part would stay where it is now). The parts to be moved are, roughly, the ones that already existed in some form before the rewrite, minus all references to monads; that is, "Application in functors" (the applicative style demo), "The Applicative class" (including the laws), and "ZipList" (which also shows the standard list instance). A few extra remarks on how  combines contexts might be desirable, but we probably won't want to go too far into that.
 * "Applicative Functors I" would explain the bare minimum needed to go into monads without turbulence. That would make it possible to sprinkle examples of  throughout the chapters about monads, and, later on, to resume the discussion of applicatives at a more sophisticated level in "Applicative Functors II". By the way, it is interesting to compare this sequencing with that of Allen & Moronuki, which does MFAM (Monoid-Functor-Applicative-Monad). That is a very sound order, but I see two reasons for not following it exactly here. Firstly, given the relative terseness of Wikibook chapters, a full treatment of the four typeclasses coming out of the blue during the transition between the third and fourth units might end up disorienting readers. Secondly, there is some interesting interplay between chapters in our MAFTAL (Monoid-Applicative-Foldable-Traversable-Arrow-Lens) sequence, and moving "Monoid" to the third unit would likely compromise some of it.


 * Once  lands in GHC, add a brief note about it in the "do Notation" chapter.


 * Use,  , etc. where appropriate in the monad chapters.


 * Rewrite the "MonadPlus" chapter as "Alternative and MonadPlus", and fix the related problems in other parts of the book.

Cheers, Duplode (discuss • contribs) 04:51, 28 September 2015 (UTC)
 * I have no objections or disagreements here at all. I haven't made it through the advanced stuff myself yet anyway. It seems you've thought things through well. I like the two-stage Applicative idea. Backfromquadrangle (discuss • contribs) 06:03, 3 October 2015 (UTC)