|
|
|
|
|
|
by DSrcl
3287 days ago
|
|
|
It's unsafe for a compiler to do this in general (i.e. without annotations) because it can't determine dependencies that are external to the program -- e.g. `one=get(); two=get()`.
The dependency between one and two is not obvious to a compiler when IO is involved, so it has to assume the two `gets' has to be executed sequentially. |
|
|
As I understood the talk, Haxl doesn't address this either. It depends on you describing an IO operation as a type with set of functionality that can be used to identify those dependencies.
> e.g. `one=get(); two=get()`. The dependency between one and two is not obvious to a compiler when IO is involved, so it has to assume the two `gets' has to be executed sequentially.
A "pure" language will address a lot of this due to referential transparency. Which is to say that if `get` takes no arguments, its instructions for where and how to perform an IO operation are entirely static. Given your literal example, the only way the result could be different is if there were some side effect or if a source of data required by `get` could change during execution time.
Haxl's takes this a bit further by suggesting that if you are performing the same IO request twice "at the same time", you expect to get the same result both times, so it memoizes the request for the duration of your set of IO operations.
Within a `do`, as far as I could grok from the talk and glancing at documentation; it's worth noting I don't know Haskell and have never heard of Haxl before today.