This is the mail archive of the
mailing list for the Guile project.
Re: base64.scm version 0.1
- To: guile at sourceware dot cygnus dot com
- Subject: Re: base64.scm version 0.1
- From: sen_ml at eccosys dot com
- Date: Wed, 02 Feb 2000 18:41:18 +0900
- References: <200002011602.SAA18373@blinky.bfr.co.il>
thank you very much for your comments!
hjstein> (begin (sleep 0)) isn't such a good idea. You could just make it #f,
hjstein> or, better yet, switch the sense of the if:
hjstein> BTW, when I find myself doing (if test (begin ...)), I typically
hjstein> switch it to (cond (test ...)). I don't know how others feel about
now that i think about it, reading (cond (test ...)) is probably
easier on my brain when trying to read -- there is less indentation
too, so that is helpful when writing code too, i believe.
hjstein> I guess you're using a case instead of the big cond now, but in the
hjstein> old code, since current-state is an integer, you can use = instead of
hjstein> Also, since you need to work with the bytes as integers (as opposed to
hjstein> characters), why use a hash table?
my ignorance ;-)
hjstein> You might as well make the encode table a vector.
hjstein> More generally, I'd think of this as:
hjstein> - Blocking the input stream into blocks of 3 8 bit bytes each.
hjstein> - Reblocking the blocks using 6 bit bytes.
hjstein> - Encoding the bits.
[ code snipped ]
hjstein> Alternatively, one could think of it as a combination of:
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 have to
hjstein> deal with input byte sizes & output byte sizes at the same time. In
hjstein> fact, I bet this would be much 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?
i noticed mentioning of "stream" in r5rs, but only in the context of
thanks again for your comments.