This is the mail archive of the mailing list for the Guile project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: base64.scm version 0.1

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
hjstein> that.

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> eqv?.


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
example code.  

thanks again for your comments.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]