On Thu, Jan 14, 2010 at 1:20 PM, Alberto G. Corona <agocor...@gmail.com>wrote:
> > > 2010/1/14 Michael Snoyman <mich...@snoyman.com> > > >> >> 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. >> >> 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. > > 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. Michael
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe