
OK, so today I tried to write my first program using the Binary library. And I've hit a snag: It appears the library will only handle data that is byte-aligned. So if I try to write three Bool values, it uses three bytes, not three bits. Before I sit down and spend 3 months designing my own library from scratch, does anybody know of an existing library that allows you to do what Binary does, but with single-bit precision? [I presume Binary is byte-aligned for efficiency...] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-strict

dominic.steinitz:
OK, so today I tried to write my first program using the Binary library. And I've hit a snag: It appears the library will only handle data that is byte-aligned. So if I try to write three Bool values, it uses three bytes, not three bits.
Before I sit down and spend 3 months designing my own library from scratch, does anybody know of an existing library that allows you to do what Binary does, but with single-bit precision? [I presume Binary is byte-aligned for efficiency...]
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-strict
The bitsyntax library perhaps? or a StateT over Binary for carrying arround the bit packet to write. -- Don

Don Stewart wrote:
dominic.steinitz:
OK, so today I tried to write my first program using the Binary library. And I've hit a snag: It appears the library will only handle data that is byte-aligned. So if I try to write three Bool values, it uses three bytes, not three bits.
Before I sit down and spend 3 months designing my own library from scratch, does anybody know of an existing library that allows you to do what Binary does, but with single-bit precision? [I presume Binary is byte-aligned for efficiency...]
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-strict
The bitsyntax library perhaps? or a StateT over Binary for carrying arround the bit packet to write.
-- Don
The vagaries of gmane have made it appear that I asked the question. In fact, Andrew Coppin asked the question and I responded with a pointer to the library Adam Langley pulled together. Dominic.

On Wed, Jun 18, 2008 at 12:46 AM, Dominic Steinitz
OK, so today I tried to write my first program using the Binary library. And I've hit a snag: It appears the library will only handle data that is byte-aligned. So if I try to write three Bool values, it uses three bytes, not three bits.
There's a BitGet[1] and BitPut in the Hackage version of binary-strict. However, these versions work on strict ByteStrings. Putting, for one, is pretty inefficient. In the darcs version[2] of binary-strict, there's a fully lazy BitPut[3]. There was a request for a lazy BitGet, but I never wrote it. Most of the time, bit fields are small and you can use the lazy Get from binary to extract a ByteString and parse that with strict BitGet. However, the BitPut should be just fine (including doing things like writing ByteStrings by shifting each byte etc). If it's missing anything obvious, ping me and I'll see what I can do. Cheers, [1] http://darcs.imperialviolet.org/darcsweb.cgi?r=binary-strict;a=headblob;f=/s... [2] http://darcs.imperialviolet.org/binary-strict/ [3] http://darcs.imperialviolet.org/darcsweb.cgi?r=binary-strict;a=headblob;f=/s... -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org

agl:
On Wed, Jun 18, 2008 at 12:46 AM, Dominic Steinitz
wrote: OK, so today I tried to write my first program using the Binary library. And I've hit a snag: It appears the library will only handle data that is byte-aligned. So if I try to write three Bool values, it uses three bytes, not three bits.
There's a BitGet[1] and BitPut in the Hackage version of binary-strict. However, these versions work on strict ByteStrings. Putting, for one, is pretty inefficient. In the darcs version[2] of binary-strict, there's a fully lazy BitPut[3].
There was a request for a lazy BitGet, but I never wrote it. Most of the time, bit fields are small and you can use the lazy Get from binary to extract a ByteString and parse that with strict BitGet. However, the BitPut should be just fine (including doing things like writing ByteStrings by shifting each byte etc).
If it's missing anything obvious, ping me and I'll see what I can do.
Cheers,
[1] http://darcs.imperialviolet.org/darcsweb.cgi?r=binary-strict;a=headblob;f=/s... [2] http://darcs.imperialviolet.org/binary-strict/ [3] http://darcs.imperialviolet.org/darcsweb.cgi?r=binary-strict;a=headblob;f=/s...
Adam, Would you recommend binary-strict over bitsyntax now? Or are none yet entirely satisfactory -- Don

On Wed, Jun 18, 2008 at 10:52 AM, Don Stewart
Would you recommend binary-strict over bitsyntax now? Or are none yet entirely satisfactory
Probably, yes. Bitsyntax was, after all, the first Haskell code I ever wrote :) It works, but I think the monad style of binary-strict is better. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org

On Wed, Jun 18, 2008 at 11:00 AM, Adam Langley
On Wed, Jun 18, 2008 at 10:52 AM, Don Stewart
wrote: Would you recommend binary-strict over bitsyntax now? Or are none yet entirely satisfactory
Probably, yes. Bitsyntax was, after all, the first Haskell code I ever wrote :) It works, but I think the monad style of binary-strict is better.
If you provide Applicative and Alternative instances for your getter monads (perhaps you already do?), that will get us very close to the kind of notational succinctness that Erlang's bit-level pattern matching gives, using entirely general Haskell mechanisms, and without the fuglitude of TH. That, I think, would be just lovely.

On Wed, Jun 18, 2008 at 11:07 AM, Bryan O'Sullivan
If you provide Applicative and Alternative instances for your getter monads (perhaps you already do?)
I have Alternative instances, and they're used a fair bit in my HTTP parser (network-minihttp). You're right that I should add Applicative too; maybe this weekend. AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org

Dominic Steinitz wrote:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-strict
Ooo... looks interesting. Pity I can't look at any documentation for it. (Is that *really* Haddoc failing with a parse error on a pragma? Surely not...) I'll take a look at this. Thanks. Andrew.

On Wed, Jun 18, 2008 at 10:43 AM, Andrew Coppin
Dominic Steinitz wrote:
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/binary-strict
Ooo... looks interesting. Pity I can't look at any documentation for it. (Is that *really* Haddoc failing with a parse error on a pragma? Surely not...) I'll take a look at this.
Yeah, I just ran into that myself, and "solved" it by removing the haddock comments for those types. I think Haddock is a bit oversensitive when it comes to parsing. It would be nice if it would at least try to continue when it failed to parse something. Of course, that might be easier said than done! While I'm on the subject, what is the future for binary-strict? I recently wanted it since I wanted to catch parse errors, but didn't wind up using it because I would have had to rewrite a whole bunch of Binary instances to be separate Binary.Put Binary.Strict.Get instances, and I'm lazy. So I did 'length (show result) `seq` return result" which doesn't win any beauty contests but seems to work. Inclusion in the official Data.Binary would be nice, especially if it could be a drop-in replacement, say by changing the Data.Binary instance definitions to Strict.Binary or something.

On Wed, Jun 18, 2008 at 11:00 AM, Evan Laforge
Inclusion in the official Data.Binary would be nice, especially if it could be a drop-in replacement, say by changing the Data.Binary instance definitions to Strict.Binary or something.
I have a class defined to abstract the various Get monads, i.e. you can write generic code which will work over a strict get, or an incremental (continuation based) get. I don't have the same for put yet. The trick is to make it so that it doesn't end up with any runtime cost. dons would not be happy if I took his highly tuned binary library and made it slow :) AGL -- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org
participants (6)
-
Adam Langley
-
Andrew Coppin
-
Bryan O'Sullivan
-
Dominic Steinitz
-
Don Stewart
-
Evan Laforge