I think the grandparent means it offers a way to bind a function `a -> m b` to an expression of type `m a`, to make an expression of type `m b`, but they left out the important part, which is the types!

After all, a functor is just a way to "bind a continuation to an expression", but this time the function you're binding is of type `a -> b`.

A better way to characterize monads is that they're generic types such that you can compose functions `A -> M[B]` with functions `B -> M[C]`. On first glance, the types don't work for basic function composition. Monads are more-or-less types `M` where a reasonable compose operation exists (for all A,B,C).

Covariant functors in programming are basically producers (I don't know of any counterexamples), so monads are essentially producers where production composes.

Can you explain what you mean by producers?

A covariant functor takes morphisms from object A to object B in some category to morphisms from A to B in some other category. I don’t know what such a functor would produce except some other morphism (or function as would be the common case for programming).

Also, I think, based on the general impression of snark GP’s comment seemed to contain, I am not unwarranted in reading his use of the term continuation in a literal sense and not to stretch it to say he was describing some (particularly odd) general idea of composition or application of functions.

Generally, from what I've seen, for all of the practical programming examples, an `F[A]` (for F covariant) can be considered to be a type that produces zero-or-more `A`s. Thought of properly, F maps types of values to some type of producer of values, and morphisms to postcomposition of the underlying function. F contravariant maps types to some type of consumer for that type and morphisms to precomposition.

I've seen people make analogies for covariant functors as containers (typical programming jargon using "functor" to mean the values of the types F[A]), but that's not quite right because of things like Future and IO. But containers are producers (they can produce the values they contain), so that characterization seems to work.

It's possible that what I mean can be turned into a statement like "all functors used in programming are representable", but I'm not sure.

I don’t know that I agree with the producer of values analogy, but this is really the crux of my problem. I have trouble defining or describing abstract algebraic structures as anything other than what they are and the continual usage in programming discussions just perplexes me.

I absolutely agree with the seeming consensus that Categorical constructions can be used to find and then abstract over common patterns in programming languages and implementations. However, it’s conversations like this one that lead me to believe people have confused the implementation of a specific example of some structure with what that structure is. I doubt the co-opting of Categorical vocabulary is that big of a deal, it’s just early and I haven’t had coffee yet.

> It's possible that what I mean can be turned into a statement like "all functors used in programming are representable", but I'm not sure.

No, this is much stronger and definitely false. Any variable-size data structure is not going to be representable: e.g. `Maybe`, `List`, `BinaryTree`.

Most data structures are sums of representable functors (i.e. are `Traversable`), but not all. Hash sets () are the classic counterexample: you can't walk them in a consistent order because the internal structure depends on the hashes, and you need to recompute hashes when you transform values.

> Monads, even when restricted to programming language usage, do not fundamentally have anything to do with continuations.

This is a little too strong, I think. If your category is sufficiently nice (complete closed symmetric monoidal, I think) then every monad arises as a codensity monad `Codensity_F x = \int_{y} (x -> Fy) => Fy` (with `->` and `=>` as the respective homs), which is clearly continuationy in character.

There are so far as I know no programming languages that correspond to genuinely complete categories, but Haskell at least is close enough that this construction still works. The main obstacle there to "`Monad`s are just continuations" isn't mathematical, it's the lack of language support for talking about categories other than `Hask`.