50 ms·
> As long as the function performing the I/O doesn't affect the outcome of the computation, everything is safe. except it's not! Your IO action may not affect
by ghostwriter 7y ago
> As long as the function performing the I/O doesn't affect the outcome of the computation, everything is safe.
except it's not! Your IO action may not affect the outcome of the computation but it may launch the missiles in background, which changes everything. The less contrived example would be - "computation is fine and is not affected, yet we have our [production cluster deleted / disk space run out / money sent to wrong recepients] by the IO action".
- gowld 7y agoDebug.Trace doesn't launch missiles or delete clusters or send money. It might run you out of disk space, but so can safe IO.
- nybble41 7y agoDespite the name, unsafePerformIO isn't automatically akin to undefined behavior in C. It can cause undefined behavior if misused, the most obvious example being the creation of polymorphic I/O reference objects which act like unsafeCoerce—but that would be affecting the outcome of the computation. If the value returned from unsafePerformIO is a pure function of the inputs then the only remaining risk is that any side effects may occur more than once or not at all depending on how the pure code is evaluated. As long as you're okay with that there isn't really any issue with using something like Debug.Trace for its intended purpose, debugging. There are better ways to handle logging, of course—you generally want your log entries to be deterministic, and the ability to produce log entries (as opposed to arbitrary I/O actions) should be reflected in the types.