Yes, I can disprove. This has nothing to do with Haskell, I'm only going to use the monad laws. The first monad law says:

    bind f (return a) = f a

For all a and f. Therefore, by substituting f = id, and a = return x:

    bind id (return (return x)) = return x

If, as in jQuery, `return (return x) = return x`, then we can simplify to:

    bind id (return x) = return x

Now, applying the first monad law again, we get:

    x = return x

So return must be the identity function. But jQuery's $ is not the identity function. Contradiction. QED.

I like your answer, but I'm going to refuse to concede that it's correct, out of stubbornness.

No wait, I can do better. For some values, $($(x)) is the equivalent to $(x). So, for some values $(y) = y. So for the domain of y where $(y) = y, $() is the identity function, and now it's a monad.

Now it's a monad how? What category is it a monad on, and in what way does it satisfy the monad laws? Are you really saying that sometimes $() is return and other times it's id, and presto magico it's a monad?

Look, if you want to have a discussion with a reasonable person who's going to try to follow your arguments and retort them under the exact same level of rigid discourse that you are using, maybe you should try someone other than me.

But yes, presto magico. I am outwitting your narrow-minded mathematics.

Well, as long as it's all in good fun :-)

In that particular reply I was talking Haskell specifically; I should have been more clear. You are of course right that being a monad does not mean being an instance of the Haskell type class Monad. It means being a monoid in the category of endofunctors. It does not mean "anything that satisfies ... associativity and left/right identity". You have to specify what operation is associative, which in this case is composition of endofunctors. Associativity and identity on binary operations on sets, for example, gives you a monoid, but not a monad.

Monads are more specific, and it is in that specificity that you find the requirement for monads to be "polymorphic": monads are endofunctors, and the monad laws concern the composition of those endofunctors. An endofunctor is a mapping between a category and itself. When we apply this category theory to programming, we talk about a category of types. In Haskell this is the category Hask. This is where the polymorphism requirement comes into play. The monad maps from Hask to itself. That means that it must be able to map over all types, which means polymorphism.

nah, I still don't buy it. Mapping Hask to Hask is an arbitrary choice.

The part that isn't arbitrary is that monads are endofunctors, meaning they must go from a category to itself. That means that the domain and codomain are the same, which means that you must be able to wrap already-wrapped values. There's no way around that.