5 ms·

I’m not sure I follow, since the implementation details of any given monad have very little to do with monads. It’s the fact that IO/Continuations/Etc can be ju

I’m not sure I follow, since the implementation details of any given monad have very little to do with monads. It’s the fact that IO/Continuations/Etc can be just another monad that was interesting when it was discovered. It’s cleaner to have 1 pattern/framework for N domains than to have N for N.

foldr 8y ago
>since the implementation details of any given monad have very little to do with monads Well, yes, that's the point. You don't need to understand anything about monads to understand how the implementation of >>= for IO forces the correct order of side effects.
- ekr 8y ago
  Actually, that is not entirely true. The monad bind operator introduces a data dependency which is responsible for the sequencing itself, not the actual implementation of the bind (i.e. it is a result of the type of the bind). But I do agree with the general idea that Haskell as a language is still a leaky abstraction, you still need to understand a lot of behind-the-scenes stuff, like how the RTS interacts with the OS ABI, how concurrency is implemented, the consequences of laziness and so on. Just knowing the denotational semantics of the language is not enough.
  - nine_k 8y ago
    I suppose that knowing only denotational semantics would be sufficient only for programs consisting of pure functions. E.g. a batch job that receives input parameters and returns the result via the minimal runtime-provided means would be an example.
  - foldr 8y ago
    >The monad bind operator introduces a data dependency which is responsible for the sequencing itself, not the actual implementation of the bind (i.e. it is a result of the type of the bind) No, there is nothing in the type of >>= which guarantees sequencing of side effects. So for example: a >>= (\b -> c) There is nothing in the type of >>= that guarantees that a will be completely evaluated before c is evaluated. I suspect this misconception is what makes many people think that Haskell's way of handling IO has something crucially to do with monads.
  - marcosdumay 8y ago
    Ordering of operations is done by the non-associativity and non-commutativity of the bind operation. Data dependency is not sufficient for ordering IO¹². Well, that's in theory at least. In GHC Haskell the ordering is not denoted by neither data dependency ot the operator semantics, but by a complex set of rules that change from one version of the compiler to the other. 1 - Although it is sufficient for any monad that lacks real-world effects. 2 - Well, technically nothing is enough for really ordering IO operations, but those two properties give single-threaded semantics to IO.
- nine_k 8y ago
  It's still useful to understand it a bit deeper to see the similarity between e.g. lists, optionals, and IO.
  - foldr 8y ago
    Well, YMMV, but I don't have any trouble understanding the concept of one thing happening after another without reference to all that other stuff.
  - marcosdumay 8y ago
    I find that kind of comment incredibly misleading. The concepts that most people attach to lists and optionals don't touch functor semantics and thus are miles away from monads. Saying that lists are an instance of Monad in Haskell says much more about novel ways you can use a list in Haskell than about properties of a monad.
    - nine_k 8y ago
      Still, questions like "how do I flatten a list of lists" are common on stackoverflow.
- richard_todd 8y ago
  I guess it looked to me like you were singling out IO as a special case, when what you are saying is true of all abstractions. You can just as easily say "you don't have to understand algebraic groups to do integer addition."
  - foldr 8y ago
    As far as I can see, explaining IO in Haskell in terms of monads is unhelpful. It would be like using monads to explain how list concatenation works. The fact that e.g (\x -> [x]) and concatMap form a monad is not really very helpful in understanding what concatMap does.

foldr 8y ago

>since the implementation details of any given monad have very little to do with monads Well, yes, that's the point. You don't need to understand anything about monads to understand how the implementation of >>= for IO forces the correct order of side effects.

ekr 8y ago
Actually, that is not entirely true. The monad bind operator introduces a data dependency which is responsible for the sequencing itself, not the actual implementation of the bind (i.e. it is a result of the type of the bind). But I do agree with the general idea that Haskell as a language is still a leaky abstraction, you still need to understand a lot of behind-the-scenes stuff, like how the RTS interacts with the OS ABI, how concurrency is implemented, the consequences of laziness and so on. Just knowing the denotational semantics of the language is not enough.
- nine_k 8y ago
  I suppose that knowing only denotational semantics would be sufficient only for programs consisting of pure functions. E.g. a batch job that receives input parameters and returns the result via the minimal runtime-provided means would be an example.
- foldr 8y ago
  >The monad bind operator introduces a data dependency which is responsible for the sequencing itself, not the actual implementation of the bind (i.e. it is a result of the type of the bind) No, there is nothing in the type of >>= which guarantees sequencing of side effects. So for example: a >>= (\b -> c) There is nothing in the type of >>= that guarantees that a will be completely evaluated before c is evaluated. I suspect this misconception is what makes many people think that Haskell's way of handling IO has something crucially to do with monads.
- marcosdumay 8y ago
  Ordering of operations is done by the non-associativity and non-commutativity of the bind operation. Data dependency is not sufficient for ordering IO¹². Well, that's in theory at least. In GHC Haskell the ordering is not denoted by neither data dependency ot the operator semantics, but by a complex set of rules that change from one version of the compiler to the other. 1 - Although it is sufficient for any monad that lacks real-world effects. 2 - Well, technically nothing is enough for really ordering IO operations, but those two properties give single-threaded semantics to IO.
nine_k 8y ago
It's still useful to understand it a bit deeper to see the similarity between e.g. lists, optionals, and IO.
- foldr 8y ago
  Well, YMMV, but I don't have any trouble understanding the concept of one thing happening after another without reference to all that other stuff.
- marcosdumay 8y ago
  I find that kind of comment incredibly misleading. The concepts that most people attach to lists and optionals don't touch functor semantics and thus are miles away from monads. Saying that lists are an instance of Monad in Haskell says much more about novel ways you can use a list in Haskell than about properties of a monad.
  - nine_k 8y ago
    Still, questions like "how do I flatten a list of lists" are common on stackoverflow.
richard_todd 8y ago
I guess it looked to me like you were singling out IO as a special case, when what you are saying is true of all abstractions. You can just as easily say "you don't have to understand algebraic groups to do integer addition."
- foldr 8y ago
  As far as I can see, explaining IO in Haskell in terms of monads is unhelpful. It would be like using monads to explain how list concatenation works. The fact that e.g (\x -> [x]) and concatMap form a monad is not really very helpful in understanding what concatMap does.