Applicative WTF?

[mikekchar]

It seems to me that people often overthink applicative. It falls right out of functor. Normally when you call fmap, you pass it a function that takes a single parameter. What happens if you pass it a function that takes more than one parameter (the other parameters being curried)? fmap applies a value from the functor to the function. Since it only passes one parameter, the result is a partially applied function. The result is that you end up with a functor containing partially applied functions.

For example, take a list of number and a function that takes 2 parameters, x and y. Maybe the function adds x to y (it doesn't matter). Pass these to fmap. Your result will be a list of partially applied functions with x being set to the values in the list. Now we want to apply the y parameter. We need something similar to fmap, but rather than taking a function and a functor, it needs to take a functor containing functions and a functor containing data. It will then apply the data to the functions and you will end up with a functor containing the result.

That's all applicative is. It applies the subsequent parameters to the result of having run fmap on functions that have more than one parameter. It shows up in a lot of different places, though and is incredibly handy. When I'm writing FP style code in languages that don't normally curry parameters, I often find myself currying parameters precisely because I want applicative ;-). It's just super convenient.

NB: pure being part of applicative is really interesting. I don't know for sure, but I'm relatively sure that a functor is applicative IFF your can define pure for it, which is really interesting to think about.

Edit: weird wording

[lmm]

> It seems to me that people often overthink applicative. It falls right out of functor. Normally when you call fmap, you pass it a function that takes a single parameter. What happens if you pass it a function that takes more than one parameter (the other parameters being curried)? fmap applies a value from the functor to the function. Since it only passes one parameter, the result is a partially applied function. The result is that you end up with a functor containing partially applied functions.

I blame this on Haskell's overreliance on currying. If applicative was explained in terms of (pure and) liftA2 aka map2, which is completely equivalent to defining it in terms of ap, the analogy with Functor would be much more obvious.

> NB: pure being part of applicative is really interesting. I don't know for sure, but I'm relatively sure that a functor is applicative IFF your can define pure for it, which is really interesting to think about.

Not true. Const b (i.e. f a = b for all a) forms a valid functor and you can define pure as long as there's at least one value of type b (pure a = 1 where 1 is that value), but if b is some type that does not form a monoid (e.g. nonzero octonions) then Const b does not from an applicative.

[cosmic_quanta]

That's a great explanation. This is similar to the post's example with tree of functions <*> tree of values = tree of results.

[platz]

> Last time I used Haskell, Applicative wasn't even a thing. I had read the McBride and Paterson paper that introduced applicative functors, but that was years ago, and I didn't remember any of the details.

In the previous post he learns how to use an Applicative.

In this post, he learns how to define Applicative for a new type he's created.

Yes, Applicative is abstract enough that it takes a few concrete examples to get a feel for it and grok what it's purpose is.

This is the work that's required to learn a new abstraction. All abstractions that are sufficiently different from previous experience require this kind of effort to make it legible to you.

Once you do, it kind of just 'snaps' and you get it.

Then, you get to leverage that knowledge in all the places it is re-used, instead of having to read the library code doing data manipulation in a bespoke way - you can just look at the type can say "yes, this is an Applicative - i know how to manipulate it and it will accord to some laws i can depend on", without having to read the source code.

[nybble41]

Given that he already knew how to define a Monad instance for his type, the Applicative instance could simply be:

    import Control.Monad (ap)
    instance Applicative Tree where
       pure  = return
       (<*>) = ap

Also, given a Traversable instance—which is essentially just "fmap with effects"—one can get Foldable and Functor for free via foldMapDefault and fmapDefault.

The really interesting cases are the ones where you can define an instance for Applicative but not Monad.

[pjmlp]

Yet another reason why learning Algorithms + Data Structures + Paradigms is much more powerful than focusing too much on language specifics.

[jmct]

The reason GHC won't infer the definition of Applicative is because there can be multiple valid `Applicative` instances for a type (unlike `Functor` where there is a unique (non-trivial) instance).

The canonical example of this is lists, with 2 valid instances of `Applicative`.

The author of the post seems to have this realization, but I wanted to call it out, just in case.

[zzo38computer]

Any Applicative can be turned backward, although the backward way will not necessarily be compatible with the Monad instance, and also sometimes the backward one is same as the original way.

[ryani]

That's true, but only one of the instances is 'compatible' with the Monad definition which requires (<*>) = ap (the first 'recipe' he showed for implementing Applicative)

[ryani]

Tree is just the free monad over the Pair functor, what's the problem?

[well1912]

"Digging deeper into why this worked this way was interesting, but it's bed time, so I'm going to cut the scroll here." I can very roughly intuit why this is-- the difference between the two Applicative instances the author noticed was that the shape of the first tree was being fitted into the second tree vs the shape of the second into the first. So if you "bind" the lefthand side of <* > first, its shape will be "fitted" to the righthand side, and if you do the opposite you get the second "fitted" to the first shape.

I believe it's the same as iterating over the righthand side of <* > in its implementation first instead of the lefthand side like in their first, wrong implementation?

But my reasoning feels loose here. I probably just need to look at their implementation of Monad Tree closer. :-)

[Balf]

I find it a little easier to decide what the Applicative instance "should" do by starting with

pair :: f a -> f b -> f (a, b)

from which you can derive the rest using pure and fmap

[zzo38computer]

Yes, and actually I wanted that to be the actual method of Applicative (although I called it "liftPair" instead, but maybe "pair" is better), because it make sense to me, I agree with you.

(Although for optimization purposes it can help to also have the other stuff it already has too, in case you want to use an optimized implementation instead of the default implementation.)

[picduniya]

I relish, lead to I discovered just what I used to be having a look for. You have ended my four day lengthy hunt! God Bless you man. Have a great day. Bye