8 ms·

Here we go again. Monad is a simple ADT. A data structure with constructors and selectors. There is no magic in it. You could write it in Scheme, nothing speci

Here we go again. Monad is a simple ADT. A data structure with constructors and selectors. There is no magic in it. You could write it in Scheme, nothing special. There is a special form in scheme called delay which basically wraps an expression inside a lambda (all you need is lambda). It is a special form, because it has its own evaluation rule, which just passes its argument un-evaluated. What is produces is called a promise, which is basically this: (lambda () e) Because procedures and thunks are first-class "objects" we could cons them together into pairs or any other data-structures. So we could make a list of promises. This list could, then, be folded or mapped or filtered the usual way. Because you want to hide implementation details of how you hook promises together, you must have constructors and selectors. To force a promise we just call it as a function This is what monads really are. http://karma-engineering.com/lab/wiki/Tutorial10 http://karma-engineering.com/lab/wiki/Tutorial10 Again, there is nothing special in "wrapping expressions into ADTs" just because we can, and especially because it is very clever. The situation in which we really need delayed and encapsulated computations are quite rare, so all this monadic stuff must be thought as a special case, not as a general computation strategy. We need no monads or comonads to manipulate elements of a vector. Sometimes we may need a vector of promises, or a vector of partially applied procedures (closures) or any combination of delayed and partially applied procedures, but that is, indeed, a special case and must be justified. In Haskell, where they deliberately separate so-called pure functions from ones which have side-effects (performing I/O) by marking them with an additional type tag and grouping them in a distinct block of code, usage of such ADTs is justified and makes sense. It has nothing to do with JVM which makes no distinction between pure and impure code.

tel 13y ago
Monads are not a need, they are a generalization and a pattern to be recognized. In a similar, if hyperbolic, vein we need no multiplication as it is nothing more than repeated addition.
- dschiptsov 13y ago
  they are a generalization and a pattern to be recognized and used only whenever it is reasonable.)
  - tel 13y ago
    Sure, but one rarely goes out of their way to use a monad. They just crop up. Often you gain expressive power by noticing when all you need is that pattern. Further, recognizing it reduces your cognitive load. Even in Haskell you can write all of your code without ever explicitly using a monad. There will be a lot of repetition and unneeded complexity but no loss of expressivity—just grace.
Peaker 13y ago
> Monad is a simple ADT. A data structure with constructors and selectors Are you talking about the Free monad? Or the reification of the monadic operations as a dictionary? If so, that's a weird way to describe monads, and not very useful. Monads aren't ADTs in general. > You could write it in Scheme, nothing special Sure, though you might need to manually thread around the monad dictionary. > There is a special form in scheme called delay which basically wraps an expression inside a lambda (all you need is lambda). It's supposed to be a memoized lambda, and not just a lambda (i.e: Force it twice, and it'll only be computed once). > Because you want to hide implementation details of how you hook promises together, you must have constructors and selectors. > To force a promise we just call it as a function > This is what monads really are. Hooking promises/thunks together is only one instance of a Monad. Otherwise, Monads have very little to do with thunks or forcing of thunks. This is not what Monads really are. > The situation in which we really need delayed and encapsulated computations are quite rare, so all this monadic stuff must be thought as a special case, not as a general computation strategy. This may be an argument against lazy evaluation, but it isn't an argument against Monads. Monads are a pretty general computation strategy. > We need no monads or comonads to manipulate elements of a vector If we want to view the vector as a set of "possible results" and use a computation strategy that goes through/generates all possible results of all computations, then the list monad (in vector form) would be useful. If we want to work with vectors that are all of the same length, zipping them together, then the "ZipList" monad would be useful. We don't need monads because a generalization is never needed. Generalizations make code applicable in more situations, and may help separating concerns. > In Haskell, where they deliberately separate so-called pure functions from ones which have side-effects (performing I/O) by marking them with an additional type tag and grouping them in a distinct block of code, You don't really have to "group them in a distinct block of code". "do" notation is just optional sugar. Also, IO is just one instance of a Monad, and the usefulness of Monads goes far beyond IO. Having Monads even if you don't have any purity distinction in your language is still very useful.
- dschiptsov 13y ago
  Monads aren't ADTs in general. The authors of haskell-98-tutorial thought otherwise. btw, it is a good idea to reduce almost everything to the very basics - lambdas and special forms - it makes everything clear, concise and compact. In terms of CS (not Math or any theory) Monad is an ADT. Period. "do" notation is just optional sugar. does GHC mix pure and impure code into a single .o?)
tome 13y ago
Ah hello again. Pretty much everything you wrote has a reasonable correct interpretation apart from this > This is what monads really are. which is incorrect.
- dschiptsov 13y ago
  OK. It is a concept from the category theory.)
  - tome 13y ago
    Kind of, though Haskell's monads are much more specific than those of category theory.
    - dschiptsov 13y ago
      A tuple/triple of functions of certain signatures?)
      - tome 13y ago
        No, a Category k a b such that k a b is isomorphic to a -> k () b. A Haskell Category is again more specific than a general category though! http://web.jaguarpaw.co.uk/~tom/blog/posts/2012-09-02-what-is-a-monad-really.html http://web.jaguarpaw.co.uk/~tom/blog/posts/2012-09-02-what-i...

tel 13y ago

Monads are not a need, they are a generalization and a pattern to be recognized. In a similar, if hyperbolic, vein we need no multiplication as it is nothing more than repeated addition.

dschiptsov 13y ago
they are a generalization and a pattern to be recognized and used only whenever it is reasonable.)
- tel 13y ago
  Sure, but one rarely goes out of their way to use a monad. They just crop up. Often you gain expressive power by noticing when all you need is that pattern. Further, recognizing it reduces your cognitive load. Even in Haskell you can write all of your code without ever explicitly using a monad. There will be a lot of repetition and unneeded complexity but no loss of expressivity—just grace.

Peaker 13y ago

> Monad is a simple ADT. A data structure with constructors and selectors Are you talking about the Free monad? Or the reification of the monadic operations as a dictionary? If so, that's a weird way to describe monads, and not very useful. Monads aren't ADTs in general. > You could write it in Scheme, nothing special Sure, though you might need to manually thread around the monad dictionary. > There is a special form in scheme called delay which basically wraps an expression inside a lambda (all you need is lambda). It's supposed to be a memoized lambda, and not just a lambda (i.e: Force it twice, and it'll only be computed once). > Because you want to hide implementation details of how you hook promises together, you must have constructors and selectors. > To force a promise we just call it as a function > This is what monads really are. Hooking promises/thunks together is only one instance of a Monad. Otherwise, Monads have very little to do with thunks or forcing of thunks. This is not what Monads really are. > The situation in which we really need delayed and encapsulated computations are quite rare, so all this monadic stuff must be thought as a special case, not as a general computation strategy. This may be an argument against lazy evaluation, but it isn't an argument against Monads. Monads are a pretty general computation strategy. > We need no monads or comonads to manipulate elements of a vector If we want to view the vector as a set of "possible results" and use a computation strategy that goes through/generates all possible results of all computations, then the list monad (in vector form) would be useful. If we want to work with vectors that are all of the same length, zipping them together, then the "ZipList" monad would be useful. We don't need monads because a generalization is never needed. Generalizations make code applicable in more situations, and may help separating concerns. > In Haskell, where they deliberately separate so-called pure functions from ones which have side-effects (performing I/O) by marking them with an additional type tag and grouping them in a distinct block of code, You don't really have to "group them in a distinct block of code". "do" notation is just optional sugar. Also, IO is just one instance of a Monad, and the usefulness of Monads goes far beyond IO. Having Monads even if you don't have any purity distinction in your language is still very useful.

dschiptsov 13y ago
Monads aren't ADTs in general. The authors of haskell-98-tutorial thought otherwise. btw, it is a good idea to reduce almost everything to the very basics - lambdas and special forms - it makes everything clear, concise and compact. In terms of CS (not Math or any theory) Monad is an ADT. Period. "do" notation is just optional sugar. does GHC mix pure and impure code into a single .o?)

tome 13y ago

Ah hello again. Pretty much everything you wrote has a reasonable correct interpretation apart from this > This is what monads really are. which is incorrect.

dschiptsov 13y ago
OK. It is a concept from the category theory.)
- tome 13y ago
  Kind of, though Haskell's monads are much more specific than those of category theory.
  - dschiptsov 13y ago
    A tuple/triple of functions of certain signatures?)
    - tome 13y ago
      No, a Category k a b such that k a b is isomorphic to a -> k () b. A Haskell Category is again more specific than a general category though! http://web.jaguarpaw.co.uk/~tom/blog/posts/2012-09-02-what-is-a-monad-really.html http://web.jaguarpaw.co.uk/~tom/blog/posts/2012-09-02-what-i...