| So, changing the translation in GHC might actually introduce | a very nasty space leak in existing programs! It might, conceivably. But the H98 report doesn't seem the right place to try to tweak full laziness. So I'm going to leave the report as it is. Hugs and GHC have changed to match. Simon
"Simon Peyton-Jones" <simonpj@microsoft.com> writes:
| So, changing the translation in GHC might actually introduce | a very nasty space leak in existing programs!
It might, conceivably. But the H98 report doesn't seem the right place to try to tweak full laziness. So I'm going to leave the report as it is. Hugs and GHC have changed to match.
And just to note: nhc98 matches the Report too (as it always did). Regards, Malcolm
I wrote: | So, changing the translation in GHC might actually introduce | a very nasty space leak in existing programs! Simon Peyton-Jones answered: | It might, conceivably. But the H98 report doesn't | seem the right place to try to tweak full laziness. | So I'm going to leave the report as it is. Hugs and | GHC have changed to match. I do not understand what full laziness has to do with all this! The big question is, in the following: f = do <expr1> <expr2> Should <expr2> be shared among different calls to f? It is clear that <expr1> will, but <expr2> will not be shared, using the current translation used by GHC and Hugs. Maybe I should be a bit more concrete; Here is a little example program:
main = do print "start" writeFile "apa" (show [1..]) <<<
When translating the do-notation using >>, we blow out of heap space (in both Hugs and GHC (*)). The code then looks as follows:
main1 = print "start" >> writeFile "apa" (show [1..]) <<<
When translating the do-notation using >>=, we do not blow out of heap. The code then looks as follows:
main2 = print "start" >>= \_ -> writeFile "apa" (show [1..]) <<<
The reason for this difference is that the computation "writeFile "apa" (show [1..])" is kept in memory in "main1" and not in "main2". So, concretely, the fix in Hugs and GHC will possibly break a number of programs. Specifically programs that for example produce a lot of output which does not depend on any run-time information. Regards, /Koen. (*) Since GHC garbage collects CAFs, we have to add an extra reference to "main", for example: main = do print "start" writeFile "apa" (show [1..]) main -- Koen Claessen http://www.cs.chalmers.se/~koen Chalmers University, Gothenburg, Sweden.
I do not understand what full laziness has to do with all this! The big question is, in the following:
f = do <expr1> <expr2>
Should <expr2> be shared among different calls to f? It is clear that <expr1> will, but <expr2> will not be shared, using the current translation used by GHC and Hugs.
Well, if a compiler implemented full lazyiness, then both translations (with >>= and with >>) would share <expr2>... I think that it is worth warning Haskell users about the potential space leak you noticed, but I don't think that it should influence the decision on "do" and ">>". I don't believe that it will break many programs. How many programs produce large *input independent* output, that is not already literally in the source, in a caf with a long life-time? Unfortunately I'm not even sure that your warning should be added to the Haskell report, because the report says hardly anything about sharing and space usage. I believe even a call-by-name implementation or a full laziness implementation would be fully Haskell 98 compliant. (I'm not happy about that either). Ciao, Olaf -- OLAF CHITIL, Dept. of Computer Science, The University of York, York YO10 5DD, UK. URL: http://www.cs.york.ac.uk/~olaf/ Tel: +44 1904 434756; Fax: +44 1904 432767
I don't believe that it will break many programs. How many programs produce large *input independent* output, that is not already literally in the source, in a caf with a long life-time?
That sounds like a description of all the animation programs in Paul Hudak's School of Expression book and there's plenty more examples like that. [I haven't tested whether these programs do leak space with the modified compiler - my point is that there is a large class of programs with exactly the characteristics you describe.] -- Alastair Reid ps I think your CAF restriction is a bit of a red herring - Koen's modification to make his example leak in GHC (which GCs CAFs) shows that the leak happens as long as the relevant thunk isn't collected.
participants (5)
-
Alastair Reid -
Koen Claessen -
Malcolm Wallace -
Olaf Chitil -
Simon Peyton-Jones