From hdaume@ISI.EDU Tue Dec 3 09:11:32 2002 Date: Wed, 13 Nov 2002 10:24:26 -0800 (PST) From: Hal Daume III To: Simon Marlow , Dean Herington , Alastair Reid , Malcolm Wallace , Marcin 'Qrczak' Kowalczyk Cc: libraries@haskell.org Subject: RE: getting a Binary module into the standard libs I was waiting a while before replying, hoping to get other comments from people who know more about this stuff than I do, but that doesn't seem to be happening. As I see it, there are three things left on the table: 1) Should putBits support >8 bit operations 2) How should we support flushByte 3) How should we buffer BinIO I'll address each of these in turn. 1) I vote in favor of "no". I fear my opinion on this is influenced by the fact that I offered to implement it. Of course you could always define putGT8Bits in terms of putLEQ8Bits, but would probably be less efficient than defining putGT8Bits "natively." I don't see a real need for it, as Simon said, most of the use for this will be for constructors and Booleans. I could probably be persuaded otherwise, but I'd like to hear a good, strong example of why more than 8 bit puts are essential. 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 b) flushBytes h m n aligns the stream such that the position p satisfies (p = n) mod 2^m c) encoding (b) as a single integer (as per Dean's suggestion) This is something I don't really know enough about to comment. Clearly (a) is the simplest, implementation wise, and probably the fastest. (b) would be a bit more work and I don't understand what it would gain you, but since it seems to be well known I'll admit that I just know too little to say. (c) wouldn't be much more work than (b), but I wonder if it's getting too complicated. My vote is probably for (a), but my vote should only count epsilon in this context. Perhaps (b) is the right thing to do (I don't need too much convincing here). 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 would probably say: a) No & left unspecified b) Yes c) Yes 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. That said, I put it out to the rest of you for comments/persuasions. - Hal _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries