Re: unsafeInterleaveIO ordering
[snip] If you're using an eager haskell implementation which does some speculative evaluation of things that look cheap and that you might want to evaluate, the answer is probably no. (Because, having decided to do some speculative work in the absence of a demand, it might decide it has done enough work after the first action, and then later it would finish the job when the result is actually demanded.) Actually speculative/optimistic evaluation should be fine. Optimistic Evaluation refuses to speculate IO for exactly this reason. If a speculative computation attempts to call unsafePerformIO or evaluate the IO from an unsafeInterleaveIO then the speculation is immediately aborted. IO is never speculated. Anyone wanting to find out more about optimistic evaluation is encouraged to download the paper from here: http://www.cl.cam.ac.uk/users/rje33/publications.html Threads are still an issue, but that can be dealt with using locking. -Rob ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Subject: Re: unsafeInterleaveIO ordering
[resending this mail from a different address as it didn't seem to get through the first time. I apologise if you see multiple copies.] [snip] If you're using an eager haskell implementation which does some speculative evaluation of things that look cheap and that you might want to evaluate, the answer is probably no. (Because, having decided to do some speculative work in the absence of a demand, it might decide it has done enough work after the first action, and then later it would finish the job when the result is actually demanded.) Actually speculative/optimistic evaluation should be fine. Optimistic Evaluation refuses to speculate IO for exactly this reason. If a speculative computation attempts to call unsafePerformIO or evaluate the IO from an unsafeInterleaveIO then the speculation is immediately aborted. IO is never speculated. Anyone wanting to find out more about optimistic evaluation is encouraged to download the ICFP'03 paper from here: http://www.cl.cam.ac.uk/users/rje33/publications.html Threads are still an issue, but that can be dealt with using locking. -Rob ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
unsafeInterleaveIO ordering
if i say: foo = do putStrLn a unsafeInterleaveIO (putStrLn b putStrLn c) putStrLn d is it guarenteed that nothing will happen between putting b and c? that is, while the place/time at which the (putStrLn b putStrLn c) is unspecified, is it the case that the whole thing will be done at once? -- Hal Daume III | [EMAIL PROTECTED] Arrest this man, he talks in maths. | www.isi.edu/~hdaume ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: unsafeInterleaveIO ordering
On Friday 29 August 2003 7:23 pm, Hal Daume wrote: if i say: foo = do putStrLn a unsafeInterleaveIO (putStrLn b putStrLn c) putStrLn d is it guarenteed that nothing will happen between putting b and c? that is, while the place/time at which the (putStrLn b putStrLn c) is unspecified, is it the case that the whole thing will be done at once? If you're asking if it is atomic wrt other concurrent haskell threads, the answer is no. If you're using an eager haskell implementation which does some speculative evaluation of things that look cheap and that you might want to evaluate, the answer is probably no. (Because, having decided to do some speculative work in the absence of a demand, it might decide it has done enough work after the first action, and then later it would finish the job when the result is actually demanded.) But, ff you're using current versions of Hugs or NHC or (using GHC but not using threads or turning on speculative evaluation), I'll bet the answer is 'yes'. -- Alastair Reid ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: unsafeInterleaveIO ordering
Hi, if i say: foo = do putStrLn a unsafeInterleaveIO (putStrLn b putStrLn c) putStrLn d is it guarenteed that nothing will happen between putting b and c? that is, while the place/time at which the (putStrLn b putStrLn c) is unspecified, is it the case that the whole thing will be done at once? In your example it's more or less guaranteed that putting b and c will never happen, because the result of the combinated IO action isn't demanded. I think, a better example would be: foo = do putStrLn a res - unsafeInterleaveIO (getLine = \c - getLine = \d - return (c++d)) putStrLn d putStrLn res Here the result 'res' is demanded after printing d, and the IO action (getLine = \c - getLine = \d - return (c++d)) is performed after printing d, when the result is demanded. I don't know the answer to your main question, but if you translate the combined monadic action down to core language you'll get some nested case-expressions, and I don't think that a correct program transformation could destroy the order of them (which would be necessary to put another IO action between the others). David Sabel --- JWGU Frankfurt ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: unsafeInterleaveIO ordering
In your example it's more or less guaranteed that putting b and c will never happen, because the result of the combinated IO action isn't demanded. well yes, it was a bad example. i got another answer basically saying that threading could screw it up (i'm not using thread) as could, perhaps, speculative evaluation, which is somewhat unfortunate, but i can live with it. - hal ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
