<div dir="ltr"><br><br><div class="gmail_quote">On Thu, Jan 14, 2010 at 1:58 PM, Alberto G. Corona <span dir="ltr"><<a href="mailto:agocorona@gmail.com">agocorona@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote"><div><div></div><div class="h5">2010/1/14 Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr"><div><div></div><div><br><br><div class="gmail_quote">On Thu, Jan 14, 2010 at 1:20 PM, Alberto G. Corona <span dir="ltr"><<a href="mailto:agocorona@gmail.com" target="_blank">agocorona@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote">2010/1/14 Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>></span><div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr"><br><br><div class="gmail_quote"><div>Well, for one thing, you'd need to use lazy IO to achieve your goal, which has some safety issues. As things get more and more complex, the requirements of lazy IO will continue to grow. This also has implications for number of open file handles and deterministic space usage. Given the fact that a lazy bytestring and easily be converted to an enumerator, I think it makes sense to start a new package using this approach.<br>
<br></div></div></div></blockquote></div><div>These must be issues of base library developers, not application developpers. TIme ago a guy said me that using an standard library like malloc for memory allocation where not the optimum. And he was right. Fortunately things went in the "non-optimum" direction. You can make the application faster by using your own plumbing code instead of standard libraries provided that you have enough time and knowledge. Because I don´t have neither of the two :-) (nor have the people that read my code and maintain the application), I really like the laziness of haskell and the lazy bytestring interface.</div>
</div><br>
</blockquote></div></div></div>Lazy bytestring interface is one thing; lazy IO is another. If you have pure code generating a lazy bytestring, Hack will work fine for you. Try this one however: take a 10MB YAML file, reformat it using something in the IO monad (for example, look up values from a database) and produce HTML output. Hack will *not* allow you to run in constant space without significant usageof unsafe functions.<br>
<br>Michael<br></div></blockquote><div><br></div></div></div><div>So there are memory leaks somewhere in the lazy bytestring IO libraries (not in hack neither is an inherent problem in the lazy bytestring design, the lazy IO concept or laziness as such). </div>
<div><br></div><div>I did''t take a look, but surely a lazy bytestring IO read is composed of an iteration of strict block reads that present a lazy bytestring interface. It must be essentially the same than a iteratee IO, but with a higher level interface (at least higher from my point of view). </div>
<div><br></div><div>I like haskell for Internet applications because streaming is the essence of communications and function call is the building block of programming. Haskell deals with both with zero impedance because its laziness. Don't break this!!</div>
</div><br><div><br></div>
</blockquote></div>No, that's not the way it works. Lazy IO requires the use of unsafeInterleaveIO, which is, well, unsafe. Pure functions in Haskell can safely be lazy, not so with IO. If you don't believe me, you can read more about it here: <a href="http://okmij.org/ftp/Streams.html#iteratee">http://okmij.org/ftp/Streams.html#iteratee</a><br>
<br>Michael<br></div>