[Haskell-cafe] Re: ANN: A triple of new packages for talking tothe outside world

[David Roundy]

On Wed, Jan 09, 2008 at 11:43:52PM +0100, Achim Schneider wrote:
> "David Roundy" <daveroundy at gmail.com> wrote:
> 
> > On Jan 9, 2008 10:10 AM, Dominic Steinitz
> > <dominic.steinitz at blueyonder.co.uk> wrote:
> > > Duncan Coutts <duncan.coutts <at> worc.ox.ac.uk> writes:
> > > > The difficulty is in deciding what the api should be. Does it
> > > > give you a real bitstream or only a byte aligned one? If I ask
> > > > for 3 bits then 15 bytes what does it do? Does it assume I meant
> > > > 3 bits, then pad to the next byte boundary and get 15 bytes, or
> > > > does it mean get 15 bytes but at this 3 bit shift offset?
> > >
> > > I'd suggest an aligned and unaligned api.
> > >
> > > So the aligned api would get 3 bits and the 15 bytes would start
> > > from the next byte boundary.
> > >
> > > The unaligned api would get 3 bits and the 15 bytes (=15 x 8 bits)
> > > would finish still with an offset of 3.
> > 
> > Do you mean we'd have an unalignedGetBytes as well as getBytes (which
> > would remain aligned)? That would make sense, but it would seem a bit
> > heavy to duplicate all of the binary API.
> > 
> getBytes per default unaligned and additionally snapToNextByte?

But I can't imagine an implementation in which this change wouldn't slow
down getBytes for the normal case.  Perhaps the slowdown would be small,
but it seems unwise to enforce that slowness at the API level, when we've
already got a perfectly good API for fast binary IO.  Maybe there's some
type hackery you could do to avoid a speed penalty, but that's a lot to add
for a somewhat dubious benefit.

Note that you could get a similar effect with getBytes always aligned, and
an additional function shiftToByte which takes the remainder of the input
and bitshifts everything so that the current read pointer is on a byte
boundary.  Obviously this would be an O(N) operation (where N is the
remainder of the input), which could certainly be a problem.

Another option, I suppose, would be to introduce a type class for
bytewise-reading monads.  That'd be a type hack, but not such a bad one.
Then you could have the efficient implementation, and one that allows
bitwise reading, and there could also be a function that allows bitwise
parsing of a chunk of a byte-aligned data.
-- 
David Roundy
Department of Physics
Oregon State University