4 ms·

It's (just) one of the usages of monads, but it's not what monads 'are'.

• d0mine 18y ago
  As presented in the post they are. Monads are abstract data types that satisfy three conditions: 1) They wrap themselves around other data types 2) They have an operation, confusingly called return, that actually performs the aforementioned wrapping 3) They have an operation called bind that allows to feed the value wrapped inside the monad into another function, as long as the function returns a monad. </quote> What condition is not satisfied by decorators with method chaining?
  • jerf 18y ago
    You've got eelco's point backwards... eelco is saying that there are things that are not "decorators with method chaining" that are monads.
    • olavk 18y ago
      Additionally, decorators with method chaing are not necessarily monads. AFAIK a monad has to be able to wrap any type, while a decorator is usually constrained to wrap some specific type (e.g. DOM nodes in the case of jQuery).
    • d0mine 18y ago
      You've got my point backwards.. I'm saying that iff "decorators with method chaining" satisfy all conditions presented in the paper then any monad (as they defined in the paper) can be expressed as a "decorators with method chaining". A single counter-example (a monad in the above sense that can't be expressed as a decorator) would suffice.
      • jerf 18y ago
        Monads don't need to be methods. In fact every Haskell monad is not a "decorator with method chaining" because there are no methods in Haskell in the traditional sense, and even if you count classes, there's no constraint that a monadic value has to be involved with a class. If you squint at Haskell to the point that you start seeing methods in all monad uses, you're squinting so hard that the word "method" has lost all meaning and become a synonym for "function". That is to say, I can see how that argument goes, but it comes at the cost of totally devaluing the distinction between "method" and "function", something I'm not willing to do.