apfelmus: > Duncan Coutts wrote: > > On Wed, 2006-11-29 at 20:27 +0100, [EMAIL PROTECTED] wrote: > > > >> On the implementation level, lazy evaluation is in the way when > >> crunching bytes. > > > > Something I rather enjoyed when hacking on the ByteString lib is finding > > that actually lazy evaluation is great when crunching bytes, though you > > do need to know exactly when to use it. > > > > Lazy ByteStrings rely on lazy evaluation of course. Demanding a lazy > > ByteString alternates between strictly filling in big chunks of data in > > memory with lazily suspending before producing the next chunk. > > > > As many people have observed before, FP optimisation is to a great > > extent about thinking more carefully about a better evaluation order for > > a computation and making some bits stricter and some bits lazier to get > > that better evaluation order. > > I completely agree. My statement was not well formulated, I actually > meant that the overhead implied by lazy evaluation occurring at every > single byte to be crunched is in the way. In this case, the cost is too > high to pay off as the bytes are most likely consumed anyway. The > detailed account keeping about every byte ("is it _|_ or not?") is > unnecessary for a (map) which invariably does look at every byte. The > situation is already different for a (fold), though: > > any p = foldr (\x b -> p x `or` b) False > > Here, the computation may stop at any position in the list. > > In a sense, lazy ByteStrings just reduce the "cost of lazy evaluation" / > byte ratio by grouping bytes strictly. Bookkeeping becomes cheaper > because one doesn't look up so often. Of course, with a stricter fold, > (any) gets more costly. The aim is to make the former ratio smaller > while not raising the latter too much. One may say that ByteString makes > explicit what the "Optimistic Haskell Compiler" aimed to make implicit.
This is a very interesting insight. Indeed, it does act much this way. -- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe