3 ms·

Actually, that is not entirely true. The monad bind operator introduces a data dependency which is responsible for the sequencing itself, not the actual impleme

by 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.

by ekr 8y ago

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.