Converting things to and from binary
Hal Daume III
Tue, 20 May 2003 07:32:40 -0700 (PDT)
I'm going to chime in here for the first time.
There was a *long* discussion of this on the libraries list a few months
and the discussion that followed.
I think that we should
(a) move this discussion to the libraries list and
(b) work from the point reached by those discussions
Hal Daume III | email@example.com
"Arrest this man, he talks in maths." | www.isi.edu/~hdaume
On Tue, 20 May 2003, George Russell wrote:
> 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
> 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:
> 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.
> Glasgow-haskell-users mailing list