getting a Binary module into the standard libs

[Alastair Reid]

> 2) The proposals for flushByte, as I see it, are:

>   a) flushBytes h n aligns the stream to the next 2^n byte (bit?)
> boundary

I think this is the right one to do.  It would probably only be used
with n=8,16,32 but I doubt the extra generality will cost anything.

>   b) flushBytes h m n aligns the stream such that the position p
> satisfies (p = n) mod 2^m

I mentioned this style of interface but I doubt we'd need it in practice.
If we do, it can always be added later as a separate function.


> 3) I think we can all agree that we should buffer BinIOs.  There are
> a few questions, given this:

>   a) Should multiple threads be allowed to write the same BinHandle
> simultaneously?  If not, is an error thrown or is the behiour just
> left "unspecified"?
>   b) Should multiple threads be allowed to read from the same
> BinHandle simultaneously?  If not, ...
>   c) Should one thread be allowed to write and another to read from
> the same BH simultaneously?  If not, ...

I believe GHC has a reader-writer lock on Handles so the answer is
that one thread blocks if another is already using it in a conflicting
way.

Basically, I suggest doing whatever normal file Handles do.

> That said, we probably need a dupBin function as Simon suggests.  I
> must say here that I don't know enough about how Handles are
> implemented in GHC to know where to start on this.  I know that they
> are already MVars of Handle__s which basically hold the file pointer
> and some other stuff, but I don't know what would need to be done to
> accomplish such a dupBin function.

Again, this should do what normal file Handles do - and code can be
stolen/shared to make this work.


--
Alastair