4 ms·

Reading this: https://wiki.haskell.org/IO_inside https://wiki.haskell.org/IO_inside did not make me come to that conclusion. The IO monad is noncommutative, an

by theoh 8y ago

Reading this: https://wiki.haskell.org/IO_inside https://wiki.haskell.org/IO_inside did not make me come to that conclusion. The IO monad is noncommutative, and thus controls sequencing of operations, because of data dependencies, more or less hidden. A "Haskell wizard" tried to tell me the ordering of operations was implemented through low-level magic a few weeks ago. The fact is that whatever ultimate form GHC might compile your code to, the sequencing is expressible in the semantics of Haskell code. Getting sequencing into the semantics is one of the problems which monads solve.

Tarean 8y ago
It's worth noting that the IO monad implementation is very much compiler magic and can't be done in library level haskell. Evaluation order without IO/ST is undefined in Haskell. This is similar to write barriers, you need a magic primop to specify external data dependencies. Without that magic the compiler may inline everything, drop the 'uselss' state token and happily move your buffer freeing before the allocation - or drop it entirely. Alternatively you could mark every function as noinline and end up with fantastically slow code.
millstone 8y ago
Data dependencies don't viably smuggle operation sequencing into Haskell. Consider e.g.: fma a b c = (a * b) + c The sum depends on the product but this doesn't sequence anything: it may be compiled into a single fma machine instruction. More generally inlining, CSE, etc. can break apparent data dependencies. It's simpler and cleaner to merely state that the Haskell runtime is written to execute IO actions in sequence.
- solidsnack9000 8y ago
  The data dependencies in how monads desugar does force the evaluation order, because the result of the first one is passed to the following one and so on and so forth. The desugaring turns each monadic action into a lambda with one argument.
  - JadeNB 8y ago
    I think that millstone (https://news.ycombinator.com/item?id=17646166 https://news.ycombinator.com/item?id=17646166 )'s point was that the sense in which desugaring of monads forces evaluation order is the same as the sense in which fma a b c = (a * b) + c forces evaluation order: you need the result of `a * b` in `fma` in order to add `c` to it. One can argue whether both of these, or neither of these, have the evaluation order forced, but I don't think that it is reasonable to argue that one does and the other doesn't. (There is a slight artefact from the fact that addition is commutative, so that it makes no difference whether you compute `c` first and then add `a * b` to it or vice versa, but I think the idea should remain.)
    - theoh 8y ago
      To discuss this properly, you need to consider the evaluation strategy, which is part of the semantics of the language. Strict, lazy, call-by-need: things do get evaluated in a prescribed order, and sequencing using monads (predictably) involves strictness, meaning that a function argument is evaluated before the function. These details of evaluation order are important to know, and they are not something to be argued about: they are well-specified and the compiler doesn't just casually make lazy code into strict code or vice versa. That would cause chaos. And what instruction set Haskell is being compiled to is totally irrelevant to this level of the language's semantics. https://en.wikipedia.org/wiki/Evaluation_strategy https://en.wikipedia.org/wiki/Evaluation_strategy
      - JadeNB 8y ago
        > To discuss this properly, you need to consider the evaluation strategy, which is part of the semantics of the language. Yes, you are certainly right. I misread and thought incorrectly that the discussion was about whether certain constructs forced data dependencies in any theoretical language, not in the particular language Haskell. > These details of evaluation order are important to know, and they are not something to be argued about: they are well-specified …. While I take your meaning, I think that you don't mean literally what you said: they got to be well specified precisely by being argued about, and will hopefully get to be even better specified by continuing argument. They are certainly not for me to argue about, though.

by theoh 8y ago

Tarean 8y ago

It's worth noting that the IO monad implementation is very much compiler magic and can't be done in library level haskell. Evaluation order without IO/ST is undefined in Haskell. This is similar to write barriers, you need a magic primop to specify external data dependencies. Without that magic the compiler may inline everything, drop the 'uselss' state token and happily move your buffer freeing before the allocation - or drop it entirely. Alternatively you could mark every function as noinline and end up with fantastically slow code.

millstone 8y ago

Data dependencies don't viably smuggle operation sequencing into Haskell. Consider e.g.: fma a b c = (a * b) + c The sum depends on the product but this doesn't sequence anything: it may be compiled into a single fma machine instruction. More generally inlining, CSE, etc. can break apparent data dependencies. It's simpler and cleaner to merely state that the Haskell runtime is written to execute IO actions in sequence.

solidsnack9000 8y ago
The data dependencies in how monads desugar does force the evaluation order, because the result of the first one is passed to the following one and so on and so forth. The desugaring turns each monadic action into a lambda with one argument.
- JadeNB 8y ago
  I think that millstone (https://news.ycombinator.com/item?id=17646166 https://news.ycombinator.com/item?id=17646166 )'s point was that the sense in which desugaring of monads forces evaluation order is the same as the sense in which fma a b c = (a * b) + c forces evaluation order: you need the result of `a * b` in `fma` in order to add `c` to it. One can argue whether both of these, or neither of these, have the evaluation order forced, but I don't think that it is reasonable to argue that one does and the other doesn't. (There is a slight artefact from the fact that addition is commutative, so that it makes no difference whether you compute `c` first and then add `a * b` to it or vice versa, but I think the idea should remain.)
  - theoh 8y ago
    To discuss this properly, you need to consider the evaluation strategy, which is part of the semantics of the language. Strict, lazy, call-by-need: things do get evaluated in a prescribed order, and sequencing using monads (predictably) involves strictness, meaning that a function argument is evaluated before the function. These details of evaluation order are important to know, and they are not something to be argued about: they are well-specified and the compiler doesn't just casually make lazy code into strict code or vice versa. That would cause chaos. And what instruction set Haskell is being compiled to is totally irrelevant to this level of the language's semantics. https://en.wikipedia.org/wiki/Evaluation_strategy https://en.wikipedia.org/wiki/Evaluation_strategy
    - JadeNB 8y ago
      > To discuss this properly, you need to consider the evaluation strategy, which is part of the semantics of the language. Yes, you are certainly right. I misread and thought incorrectly that the discussion was about whether certain constructs forced data dependencies in any theoretical language, not in the particular language Haskell. > These details of evaluation order are important to know, and they are not something to be argued about: they are well-specified …. While I take your meaning, I think that you don't mean literally what you said: they got to be well specified precisely by being argued about, and will hopefully get to be even better specified by continuing argument. They are certainly not for me to argue about, though.