3 ms·

I might be naive, but I just assumed that I was still using lazy IO. I've used conduits before, and understand that pipes fit the same design space. But most

by mrkeen 6y ago

I might be naive, but I just assumed that I was still using lazy IO. I've used conduits before, and understand that pipes fit the same design space. But most of the time I just use read and write operations exposed by Bytestring, etc. My point is that since I like IO today, and I didn't think that laziness had been removed, then I probably would have liked IO back in the day.

dllthomas 6y ago
"Lazy IO" is things like `readFile :: FileName -> IO String`, where that String you get back secretly hides a thunk that will read more from the file when you evaluate it (even in pure code). The operations provided by `Data.ByteString` do not work like this; the ByteString you get back represents a buffer, and it has already been processed by the time the RHS of >>= starts executing. The operations provided by `Data.ByteString.Lazy`, on the other hand, do work like that; the ByteString you get back is a linked sequence of buffers, and some of those links might be thunks to go get the next bits of the ByteString for you. This is why a Data.ByteString.ByteString and a Data.ByteString.Lazy.ByteString are different types, and you can't just pass one where the other is expected (unless you've abstracted over it) - they're actually shaped differently.