Rewrite Applicative Functor definition #97
Conversation
|
I'm iffy about mentioning the laws, at least without further elucidation. Fine line between comprehensiveness and succinctness (or killing it and overkill) |
|
It is definitely too long. Any specific suggestions for cutting it down? The thing is, you can't understand Applicative easily without first understanding monoid and functor. Can I assume that at the outset? Because then I could delete that material. I suppose this is one reason not to alphabetize things, though we might consider grouping. Or maybe just cross-linking and explaining "you should read monoid, etc." first. I could also delete the laws applicatives must follow. |
| *This is a [WIP](https://github.com/hemanth/functional-programming-jargon/issues/20); please feel free to send a PR ;)* | ||
|
|
||
| Where applicable, this document uses terms defined in the [Fantasy Land spec](https://github.com/fantasyland/fantasy-land) | ||
|
|
||
| __Translations:__ | ||
| * [Portuguese](https://github.com/alexmoreno/jargoes-programacao-funcional) | ||
|
|
||
| __Functional programming libraries and projects for JavaScript:__ |
|
Is it really necessary to explain monoid here? What is really needed to teach the basic usage of the interface? |
|
When I'm working on this document I keep asking myself what can be cut, if simpler words will work, and if an example can take the place of some hard to describe concept |
|
Teaching how to use is different from teaching to understand. You can say that applicatives apply functions within a context to values within a context, or something like that, or what we have now: an object with an 'ap' function, but that won't help anyone understand the principles it's based on, why it exists, how it's useful. So what I'm saying is not to explain monoid here but to state that an understanding of monoid and functor are necessary before moving on to applicative |
|
That makes sense. Me too. Hence the editorial bull session we have going here :-) |
|
A laudable goal, but I think it's one that's best served by an external On Thu, Aug 4, 2016, 9:57 AM Steven Syrek notifications@github.com wrote:
|
|
Same goes for monad. If we're to try defining that so that users would get On Thu, Aug 4, 2016, 10:01 AM Jethro Larson jethrolarson@gmail.com wrote:
|
|
I'll take a crack at something more succinct, but I do think something ought to be said about what these things actually are. Otherwise, why would anyone want to use them? We aren't likely anyone's first or last port of call for these definitions. That said I like the wiki idea too |
|
I just want this to be like a taste of these concepts with some examples. On Thu, Aug 4, 2016, 10:29 AM Steven Syrek notifications@github.com wrote:
|
|
So it's like going out on a first date with a monad? |
|
Coffee date On Thu, Aug 4, 2016, 11:13 AM Steven Syrek notifications@github.com wrote:
|
|
I believe I made it more concise without sacrificing too much of the explanation. |
|
And...? |
|
Is this comment directed at me? I updated my pull request almost a week ago..? |
| @@ -499,26 +499,9 @@ CoIdentity(1).extend((co) => co.extract() + 1) // CoIdentity(2) | |||
|
|
|||
| ## Applicative Functor | |||
|
|
|||
| An applicative is a monoidal [functor](#functor). That is, applicative structures represent [monoids](#monoid) for which function application itself is an identity. This sounds complicated, but it really just requires abstract thinking and a few specific examples: | |||
| An applicative functor is technically a [functor](#functor) that also has the properties of a [monoid](#monoid). More practically, it is a structure that allows for the application of functions within a context (for example, an array or list) to values within the same type of context. By implementing an applicative functor, you are in essence overloading the function operator `()` itself. Such an implementation will typically define an `ap` method on applicative functor objects that specifies what function application _means_ for the context that object represents. To offer a simple analogy, the plus operator `+` defines what addition _means_ for numbers. Similarly, the `concat()` function defines what addition _means_ for arrays. With an applicative functor, you can essentially generalize what addition means for any kind of structure or value. If you think of numbers as sharing the context of "numeric arithmetic" with addition and arrays as sharing the context of "array arithmetic" with `concat()`, then an applicative functor expresses how it shares the context of "arithmetic for this kind of thing" with function application in general, as defined by the `ap` method. | |||
There was a problem hiding this comment.
Giant wall of text. Also still confusing.
I'm still not convinced that describing the monoid relationship of applicative is illuminating for newcomers.
We could also describe monad as a monoid in the catagory of endofunctors but getting that abstract scares people away fast.
|
I think the "giant wall of text" issue could be resolved with a strategic newline. Also, if you think it's confusing, can you at least clarify what exactly is confusing? Writing concise definitions for these things is not easy, and I'm sure there are things that are going to be confusing, but specifics would help with shaping the language. As far as the monoid thing is concerned, what's illuminating for newcomers certainly has a subjective element to it. I think that any newcomer to FP is going to have to understand basics first. You wouldn't go straight to monad, for example. Likewise, you should know functor before applicative and knowing both functor and monoid does help in understanding applicative. Otherwise, your definition is either going to be too technical (in its terseness) or misleading, like the current definition. I think it pays to be honest about these concepts and tell people "you need to understand x before you will understand y". That's how I learned them, myself, to the extent that I have learned them. Also, I doubt we're going to be anyone's first port of call for this information. So I agree about brevity, but I don't agree that we should treat these concepts in isolation from one another, because they aren't actually isolated and it's just going to be worse for any beginner down the line to think that they are. Your remark about monoids in the category of endofunctors implies that my definition is equally abstruse and abstract. Do you really think so? Or are you just being sarcastic? |
|
Finally? |
| __Functional programming libraries and projects for JavaScript:__ | ||
|
|
||
| * [ramda](https://github.com/ramda/ramda) | ||
| * [lodash](https://github.com/lodash/lodash) |
There was a problem hiding this comment.
shouldnt lodash/fp be mentioned here instead?
|
|
||
| ```js | ||
| [(a) => a + 1].ap([1]) // [2] | ||
| Array.prototype.ap = function(xs) { |
There was a problem hiding this comment.
wouldnt such definition be better?
Array.prototype.ap = function(xs) {
return [].concat.apply([], this.map(f => xs.map(x => f(x))));
}
|
What was the final decision on this? |
This could, perhaps, use some work, but it’s a difficult concept, and I wanted to take a crack at something more comprehensive and a little more specific than “an object with an ‘ap’ method” just because that doesn’t help people understand the relationship of this structure to other FP structures (and also implies that functions in our world are just another kind of OOP-style method omg).