Am Montag, 16. März 2009 00:47 schrieb Jonathan Cast:
On Mon, 2009-03-16 at 00:14 +0100, Daniel Fischer wrote:
However, I understand "unsafeInterleaveIO allows IO computation to be deferred lazily. When passed a value of type IO a, the IO will only be performed when the value of the a is demanded."
Where is this taken from? If GHC's library docs try to imply that the
From the documentation of System.IO.Unsafe.
This version of those docs:
http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO-Unsafe.htm l
leaves unsafeInterleaveIO completely un-documented. So I'm still not sure what you're quoting from.
The documentation haddock-0.9 built when I compiled ghc-6.8.3 last year.
programmer can predict when an unsafeInterleaveIO'd operation takes place --- well, then they shouldn't. I'm starting to suspect that not starting from a proper denotational theory of IO was a major mistake for GHC's IO system (which Haskell 1.3 in part adopted).
Maybe.
as explicitly allowing the programmer to say "do it if and when the result is needed, not before".
Haskell's order of evaluation is undefined, so this doesn't really allow the programmer to constrain when the effects are performed much.
The full paragraph from the report:
" The I/O monad used by Haskell mediates between the values natural to a functional language and the actions that characterize I/O operations and imperative programming in general. The order of evaluation of expressions in Haskell is constrained only by data dependencies; an implementation has a great deal of freedom in choosing this order. Actions, however, must be ordered in a well-defined manner for program execution -- and I/O in particular -- to be meaningful. Haskell 's I/O monad provides the user with a way to specify the sequential chaining of actions, and an implementation is obliged to preserve this order."
I read it as saying that IO *does* allow the programmer to control when the effects are performed.
Right. But by using forkIO or unsafeInterleaveIO you waive that ability.
That depends on the specification of unsafeInterleaveIO. If it is "unspecified order of evaluation", then yes, if it is "do when needed, not before", as my local documentation can be interpreted, then unsafeInterleaveIO reduces that ability, but doesn't completely remove it.