4 ms·

I suspect that it is only after you ‘got it’ that you can find this description nicer than anything else that you can find in the swath of monad tutorials.

jerf 4y ago
Unfortunately, if this is your understanding of monad, that is itself proof that you did not "get it". It is neither required for mutable state, nor required for mutable state in Haskell, nor are all monad implementations about mutability. That is, that understanding is neither a subset of understanding monads, nor is a proper understanding of monads a subset of thinking of them as being about mutability. It's just wrong, unfortunately. I wrote about this extensively in http://www.jerf.org/iri/post/2958 http://www.jerf.org/iri/post/2958, "Functors and Monads For People Who Have Read Too Many 'Tutorials'". If original post is from 2008, then it is the sort of "too many 'tutorials'" that you may have read about them.
- sudosysgen 4y ago
  Sure, the idea that they have to be mutable in practice is incorrect, but Haskell has "do notation" which makes Monads act as if they always introduced mutability, and in the spirit of a simplification it is correct in the essence. The essence of the understanding that Monads act as a wrapper and define lifting and composition of wrapped types is correct in essence and that's the meat of the understanding. Define it a bit more rigorously and it's literally mathematically équivalent to saying "monoid over the category of endofunctors".
  - nightski 4y ago
    No. Do notation has nothing to do with mutability. Do notation is a convenient syntax for monads period. You can use it with the list monad for example and not IO at all.
    - sudosysgen 4y ago
      Do notation gives the syntax and almost the semantics of mutability. I never said it actually means they are mutable, just that it is practically as if they were. Which is what the author says about Monads, they mean that practically it's as if they were mutable. And yes, that goes with the list monad too when using do notation. It's syntactically and in practice almost as if you were mutating a new list and then returning it.
      - nightski 4y ago
        I don't agree. Maybe let's use a different example to illustrate more clearly - the maybe monad. Let's pretend you have a series of functions a, b, and c which take a value of type X and return a value of type Maybe X. With do notation you can chain the functions like this - do r1 <- a 1 r2 <- b r1 r3 <- c r2 r3 This is about composing functions. It has nothing to do with mutability. It is just a convenient way to write the composition rather than using nested bind operators.
        Koshkin 4y ago
        We get it, we do. Still, even in your example r1 etc. do in fact look "as if they were mutable".
        deleted 4y ago
        [deleted]
        nightski 4y ago
        If you were mutating a variable then you'd probably be using the same variable, but in this case you cannot do that. Not trying to be argumentative just saying when you have to store the result in a completely different variable I don't see how that could be considered to look like mutation.
        sudosysgen 4y ago
        Nobody here is saying that they are actually mutable. I am saying that it looks as if you are mutating a new variable and then returning it. It looks like mutation because you are "do-ing" stuff. The mutation that is almost happening is in the monadic state.

jerf 4y ago

Unfortunately, if this is your understanding of monad, that is itself proof that you did not "get it". It is neither required for mutable state, nor required for mutable state in Haskell, nor are all monad implementations about mutability. That is, that understanding is neither a subset of understanding monads, nor is a proper understanding of monads a subset of thinking of them as being about mutability. It's just wrong, unfortunately. I wrote about this extensively in http://www.jerf.org/iri/post/2958 http://www.jerf.org/iri/post/2958, "Functors and Monads For People Who Have Read Too Many 'Tutorials'". If original post is from 2008, then it is the sort of "too many 'tutorials'" that you may have read about them.

sudosysgen 4y ago
Sure, the idea that they have to be mutable in practice is incorrect, but Haskell has "do notation" which makes Monads act as if they always introduced mutability, and in the spirit of a simplification it is correct in the essence. The essence of the understanding that Monads act as a wrapper and define lifting and composition of wrapped types is correct in essence and that's the meat of the understanding. Define it a bit more rigorously and it's literally mathematically équivalent to saying "monoid over the category of endofunctors".
- nightski 4y ago
  No. Do notation has nothing to do with mutability. Do notation is a convenient syntax for monads period. You can use it with the list monad for example and not IO at all.
  - sudosysgen 4y ago
    Do notation gives the syntax and almost the semantics of mutability. I never said it actually means they are mutable, just that it is practically as if they were. Which is what the author says about Monads, they mean that practically it's as if they were mutable. And yes, that goes with the list monad too when using do notation. It's syntactically and in practice almost as if you were mutating a new list and then returning it.
    - nightski 4y ago
      I don't agree. Maybe let's use a different example to illustrate more clearly - the maybe monad. Let's pretend you have a series of functions a, b, and c which take a value of type X and return a value of type Maybe X. With do notation you can chain the functions like this - do r1 <- a 1 r2 <- b r1 r3 <- c r2 r3 This is about composing functions. It has nothing to do with mutability. It is just a convenient way to write the composition rather than using nested bind operators.
      - Koshkin 4y ago
        We get it, we do. Still, even in your example r1 etc. do in fact look "as if they were mutable".
        deleted 4y ago
        [deleted]
        nightski 4y ago
        If you were mutating a variable then you'd probably be using the same variable, but in this case you cannot do that. Not trying to be argumentative just saying when you have to store the result in a completely different variable I don't see how that could be considered to look like mutation.
        sudosysgen 4y ago
        Nobody here is saying that they are actually mutable. I am saying that it looks as if you are mutating a new variable and then returning it. It looks like mutation because you are "do-ing" stuff. The mutation that is almost happening is in the monadic state.