Name: Anonymous 2015-02-19 17:13
$("#p1") isn't a unit.The 'a' in the type of unit is important, in both of its positions.
a -> m a.$ isn't a unit for a whole lot of reasons:
First, $ doesn't take an argument of any type "naturally" from a to M a. It takes a string that represents a css selector, or a couple of other things that jQuery has hardcoded like particular dom objects. There is nothing natural about this selection process. When you feed it a string for a css selector it doesn't give you an M String it gives you a jquery-wrapped way to walk a bunch of dom-elements with a fluent interface.
Next, even ignoring that, it fails the very first monad law:
return a >>= f = f aThere is no bind-like operation ??? for which no matter what a you give me,
$(a).???(f) = f(a).It fails the second law. You can't bind to it. That same non-existant ??? operation would have to satisfy:
m.???($) = m$ engages in too much magic for this to hold. Making (???) magic enough to make this work would fail naturality by doubling down on the case-wise ad hoc reasoning that cost us the first law.
Next, The method chaining isn't bind. bind is an operation that takes a value and a function, it isn't that you call a bunch of methods on the resulting 'm'. bind itself is an operation that behaves more like map than every single operation on some object. I should be able to give you any function, not just a particular jquery combinator.
The fluent behavior acts a bit like a list monad/cont-like binding behavior by convention for many particular fluent combinators, but not every one. It is defined with the binding hand-fused into the individual combinator preventing you from abstracting over this behavior.
jQuery is a wonderfully useful combinator library that has almost nothing to do with the notion of a monad.
The third monad law even breaks down because we don't even have a "real" bind that takes a function. You can't even write the "other" association mentioned in the law for much the same reason you can't write the two forms of bind above.
Fluent interfaces are not monads. They are a pragmatic design suitable to chaining together lots of different kinds of selector-like behavior while avoiding naming a bunch of awkward intermediate results.
Monads can sometimes achieve this as well, but while chaining, that combinator can capture whatever information it wants, because it can be any function you wrote, not a handful of things folks envisioned and blessed when writing jquery or some jquery plugin that happen to most of the time allow you to continue with a fluent interface, but only by convention.
jQuery is not a Monad. jQuery is not Applicative. jQuery is not even a Functor, let alone these stronger things.
If you are feeling really generous you might be able to come up with a way to say that it 'feels kinda like' a Monad for dom objects, but given the caveats above, I feel that even saying that brings more bad intuitions than good.