Henning Thielemann wrote:
On Sun, 15 Nov 2009, Isaac Dupree wrote:
hmm, I looked at the code. I don't quite understand lazy ST, but I don't think that version you made is correct. The writes (and reads) really may not be re-ordered based on which data is demanded when. I think the distinctive thing about lazy ST is that the whole computation doesn't have to be executed before returning a result (so you can return an infinite list/computation, like, do{ a <- something; as <- recur; return (a:as) } ). But I can't figure out how to implement the correct behavior... (or if I'm just confused)...
Thank you for spotting the problem so quickly. I have pushed a patch that hopefully solves the problem.
Hopefully. I'm afraid that might still be too much interleaving; consider for example the definition of (>>) and (writeSTRef r a >> writeSTRef r b); probably neither write will even happen, because the result () won't be demanded! or (writeSTRef r a >> readSTRef r) (Also don't forget interleaving in instance Applicative Lazy.ST, if the instances ultimately end up being involved)
That is, maximum laziness would be achieved, if there would be a state-thread for every reference.
indeed. Do you know if even GHC achieves this maximum laziness? I am undecided whether it is possible and/or practical. -Isaac