<div class="gmail_quote">On Thu, Feb 12, 2009 at 10:48 AM, Svein Ove Aas <span dir="ltr"><<a href="mailto:svein.ove@aas.no">svein.ove@aas.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="Wj3C7c">Using this as a guide, I tested these two programs:<br></div></div>
<br>
====<br>
str = concat $ repeat "foo "<br>
<br>
main1 = print foo<br>
main2 = print foo >> print foo<br>
=====<br>
<br>
As I'm sure you realize, the first ran in constant memory; the second,<br>
not so much. Very interesting.<br>
</blockquote></div><br><div>That seems logical to me. The first one prints the str once, and str is never needed anymore. The second one prints str, and after it is printed, it prints it again, so the full str is needed again. So the "life data" analyzer is not clever enough to realize that the second print will never occur. Solving the latter might require solving the halting problem? I don't know</div>
<div><br></div><div>It is funny that recently I had a strange problem in C# (I tried to write parts of Reactive in C#) where the garbage collector freed data that was actually needed by my program! I had to fix that by putting a local variable on the stack, passing the constructed data to a function did not work. I think .NET and Java the garbage collector traverses from data (the stack, globals, etc). If I understood Simon correctly, GHC traverse the code blocks instead, which feels correct as it would have fixed the bug I had in C#. So yet again an extreme difference between Haskell and .NET/Java even when it comes to garbage collection, Haskell wins :)</div>
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>