3 ms·

Well, that's not really covered by correctness guarantees and nor could it — what happens does not lead to undefined behavior and memory corruption but “externa

Well, that's not really covered by correctness guarantees and nor could it — what happens does not lead to undefined behavior and memory corruption but “external correctness” related to writing to files depends on what the outside world does with the file to begin with. There are other strange things in the IO monad, such as the ability to observe evaluation orders by throwing exceptions.

a1369209993 6y ago
> There are other strange things in the IO monad, such as the ability to observe evaluation orders by throwing exceptions. That's not specific to IO; you can more or less always observe evaluation order by throwing exceptions: bar = error "bar" baz = error "baz" foo = (bar,baz) :: (Int,Int) main = print foo -- well, I guess you need IO to run anything at all `bar` is evaluated first (at least on my machine), as evidenced by: $ ./test test: bar CallStack (from HasCallStack): error, called at test.hs:1:7 in main:Main
- gizmo686 6y ago
  > I guess you need IO to run anything at all Its a bit more that that. You need to be in IO in order to catch an exception. That is to say, if you have: bam :: (Int, Int) -> String There is no way to write: bam (x,y) = "bar" if x is called first "baz" if y is called first. However, if you were to instead have: bam :: (Int,Int) -> IO String Such a function is possible to write, as you can now catch the exception and do something with it.
  - a1369209993 6y ago
    Fair enough [edit: distinction to make], but the problem is still the existence of exceptions (at least as something that doesn't always terminate the process, but that's implied by most useful definitions of "exception" anyway), not anything that would be true of a hypothetical alternate version of Haskell that still had IO, but didn't have exceptions.
- Blikkentrekker 6y ago
  The difference is that with IO, one can catch an exception, and thus write a program that branches based on evaluation order. In this case the Haskell program itself does not observe the order, as it crashes, but the order is printed as debug inormation.

a1369209993 6y ago

> There are other strange things in the IO monad, such as the ability to observe evaluation orders by throwing exceptions. That's not specific to IO; you can more or less always observe evaluation order by throwing exceptions: bar = error "bar" baz = error "baz" foo = (bar,baz) :: (Int,Int) main = print foo -- well, I guess you need IO to run anything at all `bar` is evaluated first (at least on my machine), as evidenced by: $ ./test test: bar CallStack (from HasCallStack): error, called at test.hs:1:7 in main:Main

gizmo686 6y ago
> I guess you need IO to run anything at all Its a bit more that that. You need to be in IO in order to catch an exception. That is to say, if you have: bam :: (Int, Int) -> String There is no way to write: bam (x,y) = "bar" if x is called first "baz" if y is called first. However, if you were to instead have: bam :: (Int,Int) -> IO String Such a function is possible to write, as you can now catch the exception and do something with it.
- a1369209993 6y ago
  Fair enough [edit: distinction to make], but the problem is still the existence of exceptions (at least as something that doesn't always terminate the process, but that's implied by most useful definitions of "exception" anyway), not anything that would be true of a hypothetical alternate version of Haskell that still had IO, but didn't have exceptions.
Blikkentrekker 6y ago
The difference is that with IO, one can catch an exception, and thus write a program that branches based on evaluation order. In this case the Haskell program itself does not observe the order, as it crashes, but the order is printed as debug inormation.