Derek wrote (snipped)
What's wrong with NHC's Binary/BinArray library? There seems to be a GHC port on the GreenCard page.
The home page of the York Binary library seems to be http://www.cs.york.ac.uk/fp/nhc13/libs/Binary.html Malcolm will doubtless have something to say here. However I would say not that there's something "wrong" with the Binary/BinArray library, but that it seems to be addressed towards a different class of problems (specifically data-compression) to those I am interested in (blasting data rapidly in and out). The main differences are (1) the framework I proposed in the original message: http://haskell.org/pipermail/glasgow-haskell-users/2003-May/005166.html is byte-based, while the York Binary framework is bit-based. I would imagine that this means the York Binary framework would be very much less efficient at handling long sequences of bytes, since they will presumably have to be shifted before being written to the destination. (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. (3) the York binary library provides two things you can write bits to (a Handle, and a fixed area in memory) and a large set of operations (seek and co), but it would be difficult for a normal programmer to extend this. (For example, what about someone in GHC wanting to write to a Posix Fd?) On the other hand the framework I propose has only two basic operations for writing, and two for reading, which means it should be much easier to define alternative consumers and sources of binary data.