3 ms·

You're technically right: a doesn't necessarily run before b, but that's pretty irrelevant. The only case in which it matters which one runs first are if one of

You're technically right: a doesn't necessarily run before b, but that's pretty irrelevant. The only case in which it matters which one runs first are if one of the two results in an exception, which is rare especially in idiomatic Haskell code. The effect described by (a x) certainly runs before the effect described by (b x).

deleted 4y ago
[deleted]
nightski 4y ago
Does it though? If I have the following - do f <- openFile "test.txt" putStrLn "Hello World" contents <- hGetContents handle In this case the file is most likely not opened before Hello World is printed to the console. However it would be opened before contents is read. This is what I mean in that the ordering is not top-down. It is dependency driven. This really tripped me up at first.
- pxeger1 4y ago
  I am unable to reproduce your claim. My exact code is: import System.IO main = do file <- openFile "hello.txt" ReadMode putStrLn "opened hello.txt" contents <- hGetContents file print contents I ran it with: ghc main.hs strace -fo strace.log ./main The strace log confirms the file is opened before putStrLn writes its output: ... 96748 openat(AT_FDCWD, "hello.txt", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3 ... 96748 write(1, "opened hello.txt\n", 17) = 17 96748 read(3, "this is a file\n", 8192) = 15 96748 read(3, "", 8192) = 0 96748 close(3) = 0 ... 96748 write(1, "\"this is a file\\n\"\n", 19) = 19 ... Do you have an example that demonstrates IO not happening in the order of the monad? I really don't think what you say can possibly be right, but I'd like to see it if it is.
  - nightski 4y ago
    https://wiki.haskell.org/Do_notation_considered_harmful https://wiki.haskell.org/Do_notation_considered_harmful This article discusses it further, down around where it says "Newcomers might think that the order of statements determines the order of execution." and then proceeds to give examples further down. I have experienced this in the wild. I was working with a lot of data/csv parsing code along with some heavy computer vision work in haskell (3d reconstruction from point clouds using OpenGL and Repa, and custom algos) about a decade ago. It's been a while but I remember this happening quite well.
    - edflsafoiewq 4y ago
      That's not what they mean there. You're confusing the evaluation of an expression to its value, with the execution of that value when the value is an IO a. In x >> y, you can evaluate x and y in whatever order, but the program x >> y denotes always runs the program x denotes before the program y denotes. Similar to how in [x,y], x always comes before y in the list order, even if you evaluate y first.
- pxeger1 4y ago
  Evaluation order is somewhat "dependency driven" in Haskell for pure functions, because it uses lazy evaluation. But in this case the code here is basically generating a list of "instructions" for the Haskell runtime, like saying "first open the file, then say hello, then read the file". The generation of the instructions may be in an undefined order, but that doesn't matter, because writing the instructions doesn't in itself produce any side effects. The resulting list of instructions ends up listed in the order you wrote, and so the actual IO effects are executed in that order.

deleted 4y ago

[deleted]

nightski 4y ago

Does it though? If I have the following - do f <- openFile "test.txt" putStrLn "Hello World" contents <- hGetContents handle In this case the file is most likely not opened before Hello World is printed to the console. However it would be opened before contents is read. This is what I mean in that the ordering is not top-down. It is dependency driven. This really tripped me up at first.

pxeger1 4y ago
I am unable to reproduce your claim. My exact code is: import System.IO main = do file <- openFile "hello.txt" ReadMode putStrLn "opened hello.txt" contents <- hGetContents file print contents I ran it with: ghc main.hs strace -fo strace.log ./main The strace log confirms the file is opened before putStrLn writes its output: ... 96748 openat(AT_FDCWD, "hello.txt", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3 ... 96748 write(1, "opened hello.txt\n", 17) = 17 96748 read(3, "this is a file\n", 8192) = 15 96748 read(3, "", 8192) = 0 96748 close(3) = 0 ... 96748 write(1, "\"this is a file\\n\"\n", 19) = 19 ... Do you have an example that demonstrates IO not happening in the order of the monad? I really don't think what you say can possibly be right, but I'd like to see it if it is.
- nightski 4y ago
  https://wiki.haskell.org/Do_notation_considered_harmful https://wiki.haskell.org/Do_notation_considered_harmful This article discusses it further, down around where it says "Newcomers might think that the order of statements determines the order of execution." and then proceeds to give examples further down. I have experienced this in the wild. I was working with a lot of data/csv parsing code along with some heavy computer vision work in haskell (3d reconstruction from point clouds using OpenGL and Repa, and custom algos) about a decade ago. It's been a while but I remember this happening quite well.
  - edflsafoiewq 4y ago
    That's not what they mean there. You're confusing the evaluation of an expression to its value, with the execution of that value when the value is an IO a. In x >> y, you can evaluate x and y in whatever order, but the program x >> y denotes always runs the program x denotes before the program y denotes. Similar to how in [x,y], x always comes before y in the list order, even if you evaluate y first.
pxeger1 4y ago
Evaluation order is somewhat "dependency driven" in Haskell for pure functions, because it uses lazy evaluation. But in this case the code here is basically generating a list of "instructions" for the Haskell runtime, like saying "first open the file, then say hello, then read the file". The generation of the instructions may be in an undefined order, but that doesn't matter, because writing the instructions doesn't in itself produce any side effects. The resulting list of instructions ends up listed in the order you wrote, and so the actual IO effects are executed in that order.