I don't think this article is very useful. It doesn't adequately provide an introduction to OCaml code (or adequately explain what a given code snipped is doing) and yet frequently defers to just code to explain a concept.
It's an unrealistic expectation to expect an unfamiliar reader to simultaneously infer what a particular code snippet is doing then also go a level deeper and understand the concept that is trying to be presented.<p>This article is most readable to those who already understand OCaml code, and if you can already read OCaml code you already understand these concepts.
An important realization that I had was that monads/functors/applicatives aren't patterns in the sense of design patterns. You don't solve a singular problem with a monad. With something like a strategy pattern you have a concrete problem: how do I select different potential algorithms? Monads don't have a specific problem that they solve. Any attempt to motivate monads in such a manner falls flat because the problem is either too general to be motivating or too specific to apply to monads as a whole.<p>Instead, functors/monads/applicatives are more like a technique that can be used to solve a wide variety of problems that all coincidentally use the same function signature. And therefore, it's perfectly acceptable to say "I know how monads work with Maybe and List, but not Reader" Because fundamentally, how a Reader implements bind is in no way related to how Maybe or List implement bind.
Even better <a href="http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html" rel="nofollow">http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...</a>
there's an equivalent definition of Applicative that may be a bit less intimidating:<p><pre><code> class Functor f => Applicative f where
unit :: f ()
(**) :: f a -> f b -> f (a,b)
</code></pre>
[source - a bit CT heavy](<a href="https://stackoverflow.com/a/35013667/5534735" rel="nofollow">https://stackoverflow.com/a/35013667/5534735</a>)<p>(i'll be writing the second operation as `××` in some places because of HN asterisk weirdness)<p>this gives us:<p>- `unit`, a "template" container with a hole we can fill (by doing `fmap (const myValue) unit`, equivalent to `pure myValue`)<p>- `fa ×× fb`, to "compose" two Applicative values. this shows how, unlike with Monads, the two computations must be "independent". for example, if IO were only an Applicative, you could do<p><pre><code> print "hello" ** print "world"
</code></pre>
but not<p><pre><code> getLine >>= \s ->
print ("hello, " ++ s)
</code></pre>
(where the second computation depends on the string we got in the first one)<p>it also nicely shows the two ways lists can be an Applicative - `fa ×× fb` can be either the Cartesian product `[(a,b) | a <- fa, b <- fb]` or `zip a b` (ZipList).<p>(also, it's kind of like a Monoid, which is neat!)
Nice explanation of monads!<p>My two cents: personally, I would've started with the fact that a monad is exactly the stringing together of functions (a -> m b), and the similarity between monoids, monads, strings / lists and functions under composition. You mentioned that<p>• (a -> [b]) is the type of non-deterministic computations<p>• (a -> Maybe b) is the type of fallible computations<p>• (a -> IO b) is the type of effectful computations<p>• (a -> (s, b)) is the type of computations with state s<p>• that the Monad instance merely specifies how to compose them<p>• all such composable constructs can be expressed as a monad<p>• do notation and list comprehensions automatically work across all of them<p>and, in my opinion, these are all much more powerful motivation than beginning with a comparison to functors.
It's just mind boggling how universal these concepts are and how they show up in surprising ways. As a recent example, I've been learning the basics of composing music in Haskell with Euterpea[1] and wanted to make a function which played several notes over a list of octaves to make chords. It turns out the applicative operator was exactly the function I need to do this! It would be hard to go into the details in just a little blurb here... but here is a piece I made with with it[2]. And here's the line of code with the applicative operator:<p>notePlayer notes octs dur = musicSeq $ (uncurry <$> notes) <*> ((, dur) <$> octs)<p>Won't make much sense without context, but it's there!<p>[1]: <a href="http://www.euterpea.com/" rel="nofollow">http://www.euterpea.com/</a><p>[2]: <a href="https://soundcloud.com/a-mathematical-way/not-enough-time-to-read-the-manual" rel="nofollow">https://soundcloud.com/a-mathematical-way/not-enough-time-to...</a>
I always go back to “Learn you a Haskell for Great good”.<p><a href="http://learnyouahaskell.com/functors-applicative-functors-and-monoids" rel="nofollow">http://learnyouahaskell.com/functors-applicative-functors-an...</a>
Being someone who is still struggling with these concepts, I like this tutorial because at least it doesn't use the common list/maybe/state to illustrate the concepts. Somehow I feel these concepts are so abstract - unless one is well versed in category theory, maybe only a data approach can prevent people from overfitting these concepts to specific examples.<p>I would really hope to see a tutorial that have a diverse set of examples and just fmap each example with a light explanation of say, what is a monad in this code and what is not, and because it's a monad we can do this.<p>Essentially the tutorial can just train a classifier in one's head, and with a nice set of examples maybe the brain can learn a general representation of concepts for the classifier ...
After learning Elm for a few
months I picked up a Haskell book. When I got to the Functor, Applicative and Monad chapters I discovered that I’d actually been using them for months without knowing it. Having had practical experience with them the theory came as a revelation. I found that I’d developed an intuition for them from all the concrete scenarios where I’d used them.<p>The Elm community goes out of it’s way to avoid talking about them because they make learning functional programming seem far more intimidating. It’s a very simple language though - Evan had always had beginners in mind when desiging the language and tools. If you’re looking to improve your functional programming skills it’s got a great learning curve.
I still find Philip Wadler’s original paper on Monads to be the clearest explanation of the pattern and concept. It remains scoped to the usefulness of the concept in programming, lays out very clear motivating examples, and proceeds to implement the pattern to solve each case in a lucid and explocit manner. I’d say the only downside is that it assumes at least some familiarity with FP and writing more “theoretical” or academic tools like evaluators, but all in all it’s still much clearer than the majority of garbled explanations of monads, even those that attempt to explain the concept through its dependencies/priors (functor/applicative).<p>here’s the paper: <a href="https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf" rel="nofollow">https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/b...</a>
<p><pre><code> It turns out that every generic type t has a corresponding map function map : ('a -> 'b) -> 'a t -> 'b t.
</code></pre>
So how about x : 'w -> Bool?
> According to currying, 'a -> 'b -> 'c is interchangeable with 'a * 'b -> 'c. (The fancy math word for this interchangeability is "isomorphism.")<p>I thought isomorphism was when a function was reversible. I didn't think it had anything to do with currying.
I've always understood intuitively the existence of .map(), .reduce(), and .flat() in JavaScript, but .flatMap() felt like a weirdly arbitrary combination of two of them. Now it makes sense!
Pretty weird that a comment linking a chapter from an oft referred to haskell text is a dead comment here. Surely if the alternate explantion in "Learn You a haskell for great good" is somehow sub-optimal it would be better to explain how rather than kill the comment inside 10 minutes?<p>You see this sort of thing from language warriors fighting silly wars but, yeah, what's wrong with Learn You a Haskell? Why must it be fought and suppressed immediately? Crazy...