The majority of the 'proofs' I've seen that jQuery isn't a monad seem to either be probabalistic, or use the "Burden of Proof" argument to show that since nobody has proved that jQuery is a monad, we should assume that it isn't. I agree that jQuery probably isn't a monad, but it rubs me the wrong way that people aren't willing to say "It has yet to be determined if jQuery is a monad".
Obviously it is trivial to show that it isn't a monad by the fact that javascript permits any action in pure code, but by the same token, unsafePerformIO proves that Haskell has no monads. I think it's fair to operate under a reasonable subset of jQuery functionality when asking the question.
The point is that the concept of monad is a very concrete thing. Monad is not "chaining operations". Monad is not "returning actions instead of values". Monad is not some vague concept.
If JQuery is a monad, what are the monadic operations that make it a monad? What are its equivalents of return and bind (or any other equivalent definitions of a monad)? It's not a tricky question.
Saying that JQuery is a monad without saying what its return and bind are is equivalent to saying that whistling is Turing complete without saying how you can compute stuff with whistling. The problem here is not whether whistling is Turing complete or not, the problem is what it would even mean for whistling to be Turing complete.
This means that as of now, as long as you don't tell us what are the monadic operations of JQuery, it cannot be determined whether JQuery is a monad, because this question does not make sense yet.
JQuery is an enormous API, so it is implausible that it is an implementation of the list monad. Some aspect of it might be the list monad. If so, which?
Most jQuery methods are functions that are mapped over a collection of elements. Many verbs return collections themselves, which are concatted together into the resulting collection. That's analogous to how List works.
So $(element) implements return as a -> [a]
And bind is mapcat, which is called by most of the jQuery methods.
Yes, that's a subset of the API, but it's the subset that distinguishes jQuery from any other collection of helper functions.
$(element) does not implement return. $($(element)) gives $(element), which means that it does not work on an arbitrary datatype, which means that it does not implement return.
jQuery may be analogous to a monad. That doesn't make it a monad.
There's a lot of stuff in jQuery that's not monadic, but that doesn't disqualify it. There's no law that return(return(x)) has to be defined - a Haskell List of Integers is still monadic, even though return(return(1)) would be a type violation. And undefined code can do whatever you want and not be a problem for the definition.
No, I'm sorry, you're wrong. return(return(1))::[[Int]] gives you [[1]]. For something to be a monad, it must be a polymorphic type of kind * -> * . That means it must be a type constructor which takes any type as a parameter. Any type, including a concrete type constructed from the type constructor you are declaring an instance of Monad.
No, a monad is not something that implements the Haskell typeclass Monad. A monad is anything that satisfies the monadic laws - and they don't say anything about polymorphism, only associativity and left/right identity.
I assert that you can implement a structure that satisfies those laws without having return(return(x)).
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.
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.
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.
A monad must have a `return` function that works on an arbitrary datatype. That includes a datatype that is already 'wrapped' in the monad. For example, `return $ Just 5` yielding `Just (Just 5)`. jQuery does not have such a function. The `jQuery` function can 'wrap' strings, but it cannot wrap, for example, other jQuery objects. If you try, you simply get the original jQuery object back. Accordingly jQuery does not satisfy the monad laws, and is therefore not a monad.
I deny that the return function is required to act on arbitrary data types. In Haskell, is the type [Integer] no longer a monad because it only can contain integers?
Yes, in Haskell the type [Integer] is not a monad. For a type to be an instance of the Monad type class, it must be of kind * -> * . As [Integer] is of kind * , it cannot possibly be an instance of Monad.
I didn't mean to suggest that [Integer] was of type Monad, I meant that when you write code in terms of the List monad, that code still works and is still valid and is still "monadic" even when the input to that code is a list of a non-polymorphic type.
I really don't follow what you're trying to say here. >>= has signature m a -> (a -> m b) -> m b, so clearly you are working with a concrete type m a. The point is that the concrete type isn't what instantiates the Monad type class, the constructor m is.
css "color" "blue" (filter someSelector (css "color "red" (jQuery "selector")))
class Selector a where
instance Selector Text where
instance Selector HtmlElement where
jQuery :: Selector a -> JQuery
css :: Text -> Text -> JQuery -> JQuery
filter :: Selector a -> JQuery -> JQuery
Obviously it is trivial to show that it isn't a monad by the fact that javascript permits any action in pure code, but by the same token, unsafePerformIO proves that Haskell has no monads. I think it's fair to operate under a reasonable subset of jQuery functionality when asking the question.