Talk:Haskell/Applicative functors

Adding more operators
I am still at a loss regarding  and. They are defined by Control.Applicative. I'm hoping for someone to add an explanation for those two operators.

-- MarkHumm (discuss • contribs) 15:41, 1 June 2015 (UTC)
 * Suggestion noted. This page is due to be rewritten (hopefully soon); we'll see to they being mentioned. (Very briefly, those operators are similar to monadic  and  in that they combine effects but retain values from only one of the arguments - the one the operator "points to".) Duplode (discuss • contribs) 01:31, 29 June 2015 (UTC)
 * Now done - the rewritten text mentions both in passing. By the way, note that there is no  operator - what was I thinking when I wrote the reply above? :-D Duplode (discuss • contribs) 09:30, 4 July 2015 (UTC)

Context and background required
This article was not help. I would go on but perhaps it was not meant for someone learning Haskell and not just terminology. I leave this comment just because I may be wrong and this Wiki also wants to be a terminology dictionary in keeping with the grand ideals of Haskell itself.


 * You are right in that this chapter does not provide enough context. It is in my shortlist of chapters needing a rewrite, and I intend to begin working on it soon.--Duplode (discuss • contribs) 01:27, 9 May 2014 (UTC)

2015-07-04 rewrite
I have finally rewritten this chapter. The first half (up to "ZipList") follows roughly the program of the old chapter but at a greater level o detail; the second half covers additional topics at a slightly higher level of difficulty. There are several new exercises, and a complete solutions page for them. Note that this is the first chapter compliant with GHC 7.10+ and the Applicative-Monad proposal; adjustments elsewhere will follow soon. Duplode (discuss • contribs) 09:40, 4 July 2015 (UTC)

Improving Indentation
I'd like to change some of the source code examples in the article to horizontally align similar concepts on different lines so that they match up vertically. e.g. `::`, `=`, `->`, `=>`, etc. But as some of my changes have been completely reverted I'd like figure out here, what kind of changes I am allowed to make to the article. Maybe Duplode can help with that? 84.113.13.1 (discuss) 12:18, 11 May 2017 (UTC)


 * Hello, Duplode here. Thank you for getting in touch. On your wider question, you are allowed and encouraged to do any changes you believe that will improve the book (this principle applies everywhere in Wikibooks). As for me, I watch changes to the book pages and, to the best of my ability, review them, taking into account how well they fit in with the surrounding text and the book as a whole. There is no particular reason why it is specifically me to do that, other than that I'm currently the only contributor doing such reviews regularly. If there is a difference of opinion about an edit or a review, a discussion should be started (as you rightly did) with the goal of reaching a solution that satisfies everyone. That being so, I now should explain why I reverted your changes.


 * First, a few general remarks. There is no consensus in the Haskell community over whether to align code in places where whitespace isn't syntactically significant. Though it can improve readability sometimes, it not always does so, and there are a few minor downsides to aligning things (longer lines; some extra noise on diffs; some extra busywork when writing code if one isn't using a formatter -- which is likely to be the case for beginners reading the book). That being so, when writing code samples for the book I tend to err on the side of simplicity by not aligning things systematically. That said, I wouldn't mind if e.g. someone were to use brittany, a formatter that by default does extra aligning, in all places where it made sense to do so across a chapter or the whole book. (For the record, HIndent, a formatter that doesn't do extra aligning, would be just as fine).


 * Now, on to your edits, beginning with the one in the "sliding scale" section, which is more clearly problematic than the others. Adding extra whitespace between a class name and the corresponding type variable in a context (e.g. ) is not usually done in actual code, and only makes the individual signatures harder to read; the same goes for the other changes in the first block, which impose alignment on signatures that are too dissimilar to each other for it to work well. In addition, the lack of alignment in the first block is in this case intentional, to enhance the contrast with the second block, which is aligned in a very specific way in order to highlight the similarities between the rearranged signatures.


 * The issues with the other two edits I reverted are smaller. Though I don't think they improved readability -- aligning class laws that happen to be next to each other doesn't make things easier to spot unless the laws are explicitly being compared to each other -- the difference is small enough that I can picture myself, under different circumstances, not reverting them. As it happened, in the case of the one involving the functor laws the justification you gave in the edit summary affected my choice (the Haskell Wiki isn't a reference when it comes to style guidelines); while the one involving the monoidal presentation laws was done immediately before the "sliding scale" edit, which led me to review (and revert) them both at the same time.


 * (You also did a fourth edit, in the Understanding Arrows chapter. I didn't revert that one because it is perfectly fine -- it almost always makes sense to align end-of-line comments like that.)


 * I hope that clears things up. If you believe a better compromise might be reached, I will be happy to hear from you. (By the way, it would possibly be worth it to add a code sample style guide for the book, to make this sort of decision easier -- even though making style consistent across the whole book would take a long while.)


 * Cheers, Duplode (discuss • contribs) 06:11, 12 May 2017 (UTC)

What is needed to get to 100%?
This page was the clearest explanation I ever read of functor/applicative/monad!

So I wonder what would be missing to get to stage 100%… (I would be happy to help) Nowhere man (discuss • contribs) 22:04, 26 July 2018 (UTC)


 * Glad it was helpful! As for what is missing, that is a good question... IIRC, when I added the 75% marker I was mainly concerned with covering, but that was largely dealt with by expanding the   chapter in the unit about monads (which, in turn, was made possible by the introduction of the "Applicative prologue" chapter). I'm trying to think of something else, but even after looking at my TODO list I'm drawing a blank. That being so, I guess I will just remove the 75% marker :) Naturally, the Wikibook is always open to improvements; so you'll be most welcome in case you feel like having a go at some issue or another that you happen to notice. Cheers, Duplode (discuss • contribs) 06:21, 6 August 2018 (UTC)

Bonus Law about fmap and (<*>)
Does anybody know how to prove "fmap f x = pure f <*> x" from the Applicative and Functor laws? --130.149.208.221 (discuss) 18:10, 19 February 2019 (UTC)


 * In a nutshell:  instances are unique, in the sense that if   is a   and there is some   function that follows the first functor law (that is,  ), then   (on why that is the case, see the links in [this Stack Overflow answer](https://stackoverflow.com/a/19775139/2751851), which include a proof and some background reading). Now consider  . The type of   is , and   (because of the identity law of applicatives). Therefore,  , or, equivalently,  . --Duplode (discuss • contribs) 02:17, 6 May 2019 (UTC)
 * Alternatively, assuming  and   are natural (which follows from parametricity), this follows again from the identity law:
 * Ncfavier (discuss • contribs) 17:06, 17 June 2023 (UTC)

Background on
This is not the first time it appears, but this chapter is the worst case (up until now): nowhere in the previous chapters is the  monad explained, but it keeps being used as if it had already been discussed. Some explainer needs to be added somewhere, since especially here a number of exercises can't be done without an understanding of what the  monad does.Trainman261 (discuss • contribs) 09:08, 14 April 2024 (UTC)