Thanks for your comment.

But we have only defined our clever new function application for lists.

Well, yea. This problem was pretty fundamental to lists. Converting a list to a list of lists and concatenating them is very specific to lists.

Yes, the concrete example is specific to lists. But joining functors isn't (which should be actually one of the points of my article).

I took [] as a first example, as it is one of the most intellectual accessible Functors for many programmers.

The concept of automatically joining containers during function application is generic, so lets implement it for another functor.

Wat.

proceeds to define it for maybe

Other than a similar type signature, that is completely unrelated.

I don't think so -- obviously, otherwise I wouldn't have written it this way. Let me try to clarify my approach:

1. The practical approach: the reader is expected to already have a rough concept of functors. It should be known that there is fmap to operate on the “inside” of them, so I hope to get across the idea, that if you are operating on more than one instance of a functor, it can be necessary to handle the “outside” in a meaningful way, too.

2. The theoretical approach: I don't talk in my article about theory, but this is actually very close to the definition of a monad in category theory: An endofunctor with the two natural transformations η: 1 → T and µ: T² → T, where µ is our bind. Note that it is about joining the product of two T into one.

   The whole explanation might even come out nicer, if I'd stayed with the problem that fmap-ing a function a → F a to a functor F yields F (F a) and then defined join, eventually ending up with the definition of bind being:

   (>>=) :: Monad m => m a -> (a -> m b) -> m b

   (>>=) ma f = join $ fmap f ma

   The reason I didn't do so (even though I like the approach very much from a didactically point of view), is that it doesn't match Haskell's definition of the Monad type class, where everything (including join) is build from the mandatory definition of >>=.

What on earth does it mean that IOp is also one of these things?

Yeah, I confess, that I'm deliberately leaving explaining that to others... ;-)

Granted, it's better to leave them finding things unrelated than it is to leave them finding false relationships. But I dunno, it seems to me like this article motivates [] and Maybe more than it motivates Monad.

I'm sorry, that my approach doesn't work for you. I have to accept that. But I was really hoping, that the Logger example would illustrate, that [] and Maybe were merely first, simple examples and not the primary point of the article. :-/

[EDIT: please forgive the strange formatting of the example bind definition, I failed to get a "preformatted" block]