Monads are monoids in the category of endofunctors

Isn't it more like, no mutation?

> The precise terminology is vital; it's how we avoid these errors when talking about this very abstract stuff. Given that the OP is very wrong, precisely because of the kind of attitude you've taken here, I hope you'll take this opportunity to reconsider your views.

Your behavior is precisely the behavior that someone new to FP would see and say "Hard pass on that", which goes into the greater problem of FP being unapproachable to beginners because of the unnecessary gatekeeping. If you cannot communicate with a beginner in language they understand, A.) you don't really understand it either, B.) you're just pushing them away from whatever you're advocating.

Just today, Don Syme wrote up thorough explanation on why he won't be adding type classes and more higher-order-types (or whatever the correct term is) to F#. As someone learning F# and starting to use it in production, I love it because it shows that there is a focus on practical FP even at the very top of the community. https://github.com/fsharp/fslang-suggestions/issues/243#issu...

The categorical definition of a monoid is different than the usual algebraic one (although one can be recovered from the other) and usually treats a monoid as a single object (hence "mono-").

In particular, usually a monoid is defined as a single object category (sometimes a "monoid object" is defined inside a category, but that's a different presentation). The usual multiple objects of an algebraic monoid correspond to different arrows/morphisms within a monoid.

So for example, while the usual algebraic presentation of a monoid would say the integers form a monoid with an identity element `zero` and normal integer addition forming the monoidal operator, the categorical definition says instead that the monoid is the category that consists of only one element Unit and the morphisms (x => x + 0), (x => x + 1), (x => x + 2), etc. We have an identity morphism (x => x + 0), which when composed with any other morphism does not change it (x => x + 2 composed with x => x + 0 still is just x => x + 2). This is a common pattern in category theory: everything is reduced to composition.

So that's a categorical monoid, just a single object with a lot of morphisms and an identity morphism. We can back out the usual algebraic definition by associating with each morphism the "element within" (i.e. associating (x => x + c) with c), but it represents a different way of thinking.

We can also talk about a monoid object in a larger category in much the same way.

Hence now that we can talk of a monoid as a single object, we can then say that an endofunctor is a monoid (given the proper mappings on an endofunctor, i.e. natural transformations).

> Wait, a functor is just a pure unary function?

A functor has two pieces: a pure unary function from types to types, and a pure unary function from functions to functions. The article doesn't talk about the function on types; it doesn't even talk about the function on functions. Its first example of a functor is the function `(num) => "" + num`, which isn't a functor. They map values of Integer to values of String, but they do not map any type to some type, nor do they map any function to some function. Neither part of a functor is present nor nearby.

As an example, for every type T, there is a (non-generic!) type of lists with elements of type T. The non-generic part is really, really important, and is probably a big source of confusion. When we define, say, `class List`, we're defining a whole family of independent types, which we might concretely name List__Integer, List__String, and so on. The List notation is a way of getting that specific type without knowing what its name is. By abuse of notation, we (programmers, not category theorists) talk about List as though that were the name of the type. Theorists separate the two notions, and consider `List` to be an actual function from types T to types List__T, whatever that type actually is.

Most languages that let you define a family of types don't let you refer to the type function on its own. Java (say) never lets you refer to the List function on its own; the name List refers to some other shameful and unrelated concrete, non-generic type. When your language does let you speak about the type function itself, and pass it around to other things, we say that it has "higher-order types". (Just as a language that lets you speak of and pass around a function `factorial` without invoking it has "higher-order functions"; notwithstanding closures, that's what "higher-order" means. [0])

Just having a type function is not enough to have a functor. You also need a function that takes transformations between two types, T and S, to transformations between whatever types the type function sends them to. (For List, we said they're called List__T and List__S, but we can always refer to them indirectly by saying "whatever List maps T to", which is generally written F for any type function F.)

Because of the abuse of notation, we collectively "forget" that `List` defines a function from types to types, and pretend that a functor is just defined by what it does to functions from T to S. But most of the point of functors in functional design is that you can pass around the type-function part, `List`, with the knowledge that it describes a mappable type. If you don't pass around type functions, the concept of a functor will be useless to you.

[0] https://stackoverflow.com/a/6427289/159876