Re: base64.scm version 0.1

["Harvey J. Stein" <hjstein at bfr dot co dot il>]

sen_ml@eccosys.com writes:

 > hjstein>  - port->bitstream
 > hjstein>    - Convert port from a stream of bytes to a stream of bits.
 > hjstein>  - bitstream->integerstream <# of bits>
 > hjstein>    - Convert stream of bits to a stream of integers of given size.
 > hjstein>  - encode-integerstream
 > 
 > hjstein> This might lead to a cleaner solution in that one wouldn't
 > hjstein> have to deal with input byte sizes & output byte sizes at
 > hjstein> the same time.  In fact, I bet this would be much
 > hjstein> simpler...
 > 
 > i am interested in rewriting base64.scm to take advantage of this
 > alternative design.  originally, all i wanted base64.scm for was my
 > nefarious purposes, but it seems like a good opportunity to learn ;-)
 > 
 > i am not clear on a few aspects of your description though.  in
 > particular, i am ignorant of what you mean by "stream".
 > 
 > for port->bitstream, do you have any suggestions on how to
 > store/manage the stream of bits?  does it become another port where
 > each character represents one bit?
 > 
 > or do i implement some kind of general stream which i use for bitstreams
 > and integerstreams?  perhaps there is already something called a stream?

Well, you could either make a soft port which wraps the port & for
which read returns 1 or 0 or eof-object.  It would read-char off the
port (storing the result & an index) and then return the first bit.
Each additional time it's called it would return the next bit
(incrementing the index).  When the byte is consumed it would read
another char, reset the index & continue.  
bitstream->integerstream would take the bitstream soft port & an
integer (n) as arguments and also would return a soft port.  Each read of
this one would do n reads of the bit port, concatenating the results
together into an integer & return that.

Alternatively, one could do this directly in scheme by making a
function which takes the port & returns a function which can be called
to get the bits, etc.

Although this would be an interesting implementation, and would
eliminate the complications of blocking n k byte items into nk/l l
byte items, I'd suspect it'd be too inefficient.  But, it should be
easy enough to code up & compare to other implementations.

You could also consider doing the whole thing in memory, doing
port->list-of-bits, and list-of-bits->list-of-integers.  Again, this
would probably be simple, but inefficient.

Another possibility would be port->block-of-bits, which takes the port
& an integer n & reads (up to) n bytes & returns a list of the bits,
to which block-of-bits->list-of-integers could be applied.  This might
be intermediate between complexity & efficiency.

-- 
Harvey Stein
Bloomberg LP
hjstein@bfr.co.il