Functors and Monads for People Who Have Read Too Many “Tutorials”

I’ve used functors and monads to solve tons of issues and have literally no clue about the theory behind them.

> ...too often act like ivory towers...

I 100% agree with this. The Haskell community as a whole and various tutorials etc., aren't optimised for a new comer.

For instance, you don't see a "stand up a web app in Haskell in 10 minutes" tutorials. Historically it may have worked in Haskell's favour to slowly induct learners, but in this age where languages are fighting for mind space I don't agree that's a good approach anymore.

Simon Peyton Jones (SPJ), an earliest and a famous champion of Haskell coined the phrase "avoid success at all cost" in a certain context which may have had some role in making Haskell seem Ivory Towerish.

A language, like any living being, needs to adopt to survive and thrive. It's unfortunate to see Haskell remain a niche language even after close to 3 decades.

> and that simply is not how my brain is wired.

This, however, I disagree with. I mean in a general sense, not specific to how your brain is wired. It all depends on the first couple of language that one learns and how they are learnt and taught. 10-15 years ago people would find it hard to grok Python's functional concepts. But as it began to be taught as the first language in universities and those graduates join the working population you see how it's super natural for them to grok Python.

For balance, here's another common opinion about tutorials: http://dev.stephendiehl.com/hask/#eightfold-path-to-monad-sa...

> [...]

> Read the monad definitions.

> Use monads in real code.

> Don’t write monad-analogy tutorials.

In the end, the two opinions about learning monads coexist, and people have done fine following either way.

First of all, I completely understand where you're coming from.

But the fact that Haskell embraces computer science, unlike most other programming language communities, is what attracts me to it the most. I can geek out about the mathematics that leads to simpler, safer software with like-minded people. I am always learning from Haskellers more than from any other programmers.

But it does take a lot of learning and unlearning to become a fluent functional programmer. This isn't because functional programming is more complicated than other paradigms (au contraire), it's because schools and universities have been mostly teaching OOP for the past 2-3 decades—unfortunately. As a result, most programmers have such a big gap in their knowledge that it can feel too daunting to dive in.

We could definitely do a better job teaching the theory and explaining how it's useful. That would be better for everyone: better for curious minds who want to expand their programming skills, and better for me because I'd have more company to discuss it with.

With a ‘theoretical’ description, like a BNF grammar or a Unix man page listing every possible option the program accepts, this is immediately obvious. Haskell’s focus on ‘theory’ follows the same philosophy.

In any case, all knowledge needs to be elevated to some level of theory because a correct theory guarantees the repetition of correct application.

I think this is how a lot of people learn math and programming anyway. Build theory out of intuition.

I agree with you entirely that the Haskell syntax is probably one of the biggest issues with monads being approachable.

It probably won’t be very helpful. The definition of a monad is 90% in the types.

People use Haskell to talk about monads for two reasons:

1. Its type system is expressive enough to represent them (parametric polymorphism and higher-kinded types)

2. It’s one of a very small number of languages that doesn’t let users wiggle their way around needing some kind of principled effect system, so you really can’t get away without monads. Only in such an environment can the social pressure to take shortcuts be overcome, forcing people to structure their code carefully enough that the rich concept of monads isn’t reduced to a few occasionally used and probably incorrectly implemented corner cases like optional values and maybe futures.

for example, if "f" is "list of" and a is "integer" and b is "string", then flip fmap would take as input a list of integer, and a function from integer to string, and produce a list of string.

If you've done some topology: [or, maybe a is a particular topological space and b is another topological space, and f is "the fundamental group of", then given an element of the fundamental group of a, and a function from the topological space a to the topological space b, it will give you a corresponding element of the fundamental group of b.]

a and b are both types of things, f takes in a type, and outputs another type. so, a and f a are both types (usually different types). the thing is that f doesn't just let you make a type from another type, it also lets you translate a function from the type a to the type b, to a function from the type f a to the type f b.

It's easy if you first learn about Haskell notation and type classes, which pretty much every online tutorial covers. What you quoted isn't arcane, you're just unfamiliar with it (just like my granma would find C-like syntax illegible: she just wouldn't know anything about it).

  # milk_cows :: Person -> Tired Person
  def milk_cows(person):
    ...
    person["tired"] = True
    return person

  # feed_pigs :: Person -> Tired Person
  def feed_pigs(person):
    ...
    person["tired"] = True
    return person

  # birthday :: Person -> Person
  def birthday(person):
    person["age"] += 1
    return person

  # willy :: Person
  willy = {"age": 32, "tired": False}

  # fmap and >>=
  print(milk_cows(birthday(feed_pigs(willy))))

Haskell folks love arrows and one letter variable names.

I don't know why, I guess it's the algebra background of most Haskell folks.

When I wrote some things in Haskell, I tried to use full words for function names and variable names, but it felt I am the only one. People just love to name stuff `a` `b` `m` `f` `k`

A definition like:

    bind f (x:xs) = f(x)

What makes a monad a monad is that it is a functor (so a special parametrized type of sorts) with

- a function to wrap a single value (wrap :: a -> M a)

- a function that can flatten nested versions (flatten :: M M a -> M a)

- such that wrapping twice and flattening is the same as wrapping once

- such that when flattening a triply nested structure it doesn't matter which level you flatten first.

And of course it also needs to satisfy the functor axioms, which are also frequently overlooked, though they're not too difficult they just mean that 'fmap' needs to play nice with identity functions and function composition.

And Haskell in particular suffers quite a bit from the fact that currying is a first class concept, while in category theory this is reserved for a rather special class of categories. This means that using functors in combination with functions of multiple arguments suddenly requires you to think about how to evaluate a tree of functions on a tree of values, where in most other languages you'd end up with a tree of tuples at worst. Granted you can do more if you solve those problems, but it requires you to think about concepts that even category theorists consider pretty 'out there'.

Would you agree that introducing particular interface is gonna show interface definition in question?

What should follow (just like in Java) is few examples of actual implementations and how they fit into that interface.

The paragraph starting with "I am aware of the notorious effect" directly addresses this, do you disagree with it?

Also calling it an interface isn't an analogy.

(This isn’t an entirely new kind of concept in programming, either; see “patterns”.)

Divergence and partiality can easily be modeled by the category of complete partial orders and Scott-continuous maps. This is what you learn in, e.g., a course on domain theory and/or denotational semantics.

Andrej Bauer is mainly arguing that Hask isn't a category because no one has formally specified it. For example, we would need to come up with a policy on when two arrows are considered equal, and it's not clear what that notion of equality should be.

> A function is a relation for which each value from the set the first components of the ordered pairs is associated with exactly one value from the set of second components of the ordered pair.

Cool, I have no idea what the fuck this means and how it is useful to me.

Oh wait, I use them every day.

Upon hearing this, the islanders think that functions must be some magical panacea, and so you backtrack on that and try to talk about functions as being like animals, they take input and produce output (good luck with function composition).

The situation is like that with monads. They are far removed from the world of programming (the fact that there were connections at all to effects was remarkable!), but as such, you have to learn the ambient theory in which monads reside to really grok it.

IME, category theory was much more valuable in differential topology in helping solidify why the structures and their compositional properties make sense. You get to work with several, honest-to-god categories and functors between them, especially when tangent bundles come into the mix.

Now go to programming, there's really only one category at play, and I'm not sure how worthwhile it is to apply a (more contrived) version of CT that only has endofunctors and being cartesian closed.

This puzzles me. It turns out it's very useful in the context of programming in practice (i.e. Haskell programmers use it and find it useful), so what do you mean? I don't know CT so I wouldn't know how well it maps (pun intended) with the Math concept, but regardless, whatever abstraction is there in Haskell that programmers call "functors" is tremendously useful.

I think it's a small convenience to have the programming language automatically derive `map` instances for you, but I think you're right for pretty much the same reason group theory's huge but monoid theory barely exists: the `Functor` typeclass is too simple to do anything interesting with it.

I label this my opinion quite on purpose, because I see the alternative viewpoint. I think you'll be more successful taking about lawfulness once someone gets the mechanics, given how much that has been a stopper over the years!

For all the functor tutorials, it really is nothing more than the interface and rules that define map. And Monad is essentially flatmap.

That's was so absurd about all of this.

flatMap doesn't let you implement the audit log example, or work on a binary tree, let alone try to implement something like IO.

Functors let you chain together unary (non-branching, straight line) processing pipelines. If your processing pipeline works over any functor, then it can be applied to any structure that acts as a source of values, and it will leave that structure unchanged around the processed data.

An "applicative" is a functor that also lets you take two values, one structuring some `a`s and one structuring some `b`s, and cross them together to produce a result that structures some tuples `(a, b)`. If I have two lists, I can cross them together to get a list of all pairs of elements between the two lists (like a CROSS JOIN in SQL).

Applicatives let you merge two separate processing pipelines together, combining data from both sides together into a single stream. If you can combine two pipelines into one, you can combine any number of them; this is what makes them strictly more powerful than general functors, which cannot support multiple parallel data sources.

A "monad" is a functor that also lets you take a value with two layers of nested structure, `f (f a)`, and meld/flatten/unify those two layers into a single layer of the same kind (`f a`). If I have a list of lists, I can unwrap the inner list structures, lifting all of their elements to the top level. Or, more viscerally (for me), if I have a binary tree whose leaves contain binary trees, I can graft the inner tree at each leaf onto the outer tree, producing a deeper single tree.

Monads let you accumulate some inner structure produced by a stage of your pipeline into the outer structure your values came from. In turn, this reveals the values under the inner structure to downstream pipeline elements.

The community is very much focused on learning, by teaching the little one knows.

I prefer to just write down the type and stare at it and think about what sort of functions could have that type. Later you can look at the rules. And this mostly means one needs to have written a little (eg) Haskell so that the one can read simple types. The signature of fmap looks like:

  fmap :: (a -> b) -> functor a -> functor b

  fmap (\x -> f (g x)) a == fmap f (fmap g a)

I dont want to discourage you from learning math, but I think this isnt a good place spend too much thought at first.

- a parametrized type, like for instance List: you can have lists of integers, floats, functions, or any other type

- a way of mapping (in the sense of List.map) between instances of the parametrized type, given regular functions. This mapping should behave nicely with respect to regular function composition.

If your parametrized type is F, then the mapping operation turns ("lifts") regular functions A -> B into functions (F A) -> (F B) in a reasonable way: "if you give me a function then I can transform any list using it".

Functors can be used to "decorate" values: you can model exceptions (some value or an error), promises (some value not yet computed), state (some value + side effects) and many other kinds of effects using functors.

So in general an effectful computation will have type A -> (F B) for some functor F modeling the effect. And now you have a problem: how to compose effectful computations in order to build larger programs out of smaller ones? You cannot simply compose A -> (F B) with B -> (F C) since the types don't match.

What you need is a way of transforming an effectful computation B -> (F C) into a lifted function (F B) -> (F C) so that you can compose A -> (F B) with (F B) -> (F C) in order to get A -> (F C).

That device should satisfy some properties to make effectful composition work the way you expect (in particular there should exist identity effectful computations), and is called a monad.

A monad is a functor + some extra operations (bind/return) satisfying properties that will make effectful computations (using this functor) composable.

The type of bind is generally written (F A) -> (A -> F B) -> (F B) but really it is the same as (A -> F B) -> (F A -> F B) above (takes an effectful computation, gives back a lifted function).

In practice it's not too much of a problem, but it does mean that if you use some FP library, you cannot trivially wrap a promise to make it a monadic type that will work with the library's monad utilities.

Monad is a typeclass, not a type. m is a variable, whose value is a type constructor.

> But m is an instance of a function, not a variable.

On the type level, m is a variable representing a type constructor; a concrete value it might have is List. It is an instance of a typeclass, not a function.

> But m, a, and b all look like variables.

m, a, and b are all type-level variables; the value of m is a type constructor (which is essentially a type-level function), while the values of a and b are types.

I think it’s better to at least try to make a name that transmits partial meaning or a general gist of the idea.

  fmap :: (a -> b) -> f a -> f b

Sounds like LINQ in C#. I wonder if there's any correlation.

It's like having someone run hello world in java and declaring they know what 'static' means.

Also, JS promises are not really monads. They lack denotational equality, so they can’t be said to obey the monad laws.