5 ms·
Most jQuery methods are functions that are mapped over a collection of elements. Many verbs return collections themselves, which are concatted together into the
by jes5199 14y ago
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.
- nbouscal 14y ago$(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.
- jes5199 14y agoThere'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.
- nbouscal 14y agoNo, 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.
- jes5199 14y agoNo, 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)). Can you disprove that? (P.S. you are wronger)
- nbouscal 14y agoIn 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.
- jes5199 14y agonah, I still don't buy it. Mapping Hask to Hask is an arbitrary choice.
- nbouscal 14y agoThe 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.
- jules 14y agoYes, 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.
- deleted 14y ago[deleted]