RE: Converting things to and from binary
(2) the York Binary library uses the IO monad, and presumably various variables within a BinHandle, to keep track of state. I think this is unnecessary, for example I don't think the process of converting a value to a byte array should really have to go through IO. We are supposed to be functional programmers after all.
When writing to a BinMem it would be possible to avoid the IO monad, and use something like the ST monad instead. However, I'm not sure it's worth making this generalisation, since it would necessarily complicate the library quite a bit. Do you have an application where being in the IO monad to do this stuff isn't possible, or is inconvenient? Cheers, Simon
On Wed, May 21, 2003 at 11:52:00AM +0100, Simon Marlow wrote:
When writing to a BinMem it would be possible to avoid the IO monad, and use something like the ST monad instead. However, I'm not sure it's worth making this generalisation, since it would necessarily complicate the library quite a bit.
Do you have an application where being in the IO monad to do this stuff isn't possible, or is inconvenient?
Since unboxed arrays have no outgoing edges in the heap graph, I can think of using such library to reduce the heap graph (thus reducing GC time) by storing some data in memory in binary form. Limiting library's interface to IO monad would make it hard to use such technique in purely functional code. Maybe GHC could itself compress live but rarely accessed data in the heap? Regards, Tom -- .signature: Too many levels of symbolic links
Simon Marlow wrote:
Do you have an application where being in the IO monad to do this stuff isn't possible, or is inconvenient? No. But it is inelegant, since IO is the *only* way the bit consumer has of preserving state. So if for example the target is a list of arrays and bytes, it would be necessary to hold the list inside an IORef or something similar.
participants (3)
-
George Russell -
Simon Marlow -
Tomasz Zielonka