3 ms·

What were the other options available in Haskell in 1992, besides Lazy IO, which made for a great IO story then? Please point me to code or papers from then bec

What were the other options available in Haskell in 1992, besides Lazy IO, which made for a great IO story then? Please point me to code or papers from then because I am genuinely interested to learn.

tome 6y ago
Reading and writing between handles and buffers, just like any other language. If you object specifically to the adjective "great" then, well, I don't think that was the operative point of the original comment.
- mavelikara 6y ago
  I object to both the use of “great” and the (needless, IMO) mention of Java in mrkeen’s comment.
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.

3 ms·

What were the other options available in Haskell in 1992, besides Lazy IO, which made for a great IO story then? Please point me to code or papers from then bec

by mavelikara 6y ago

tome 6y ago
Reading and writing between handles and buffers, just like any other language. If you object specifically to the adjective "great" then, well, I don't think that was the operative point of the original comment.
- mavelikara 6y ago
  I object to both the use of “great” and the (needless, IMO) mention of Java in mrkeen’s comment.
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.