binary-io, opposable-thumb, pack/unpack (was Re: binary-io (wasRe: rfc 2045 base64 encoding/decoding module))

[sen_ml at eccosys dot com]

  not being more than a scheme programmer wannabe, i don't think i can
address the lack of certain low-level features w/in guile itself (at
least not yet).

  in the opinions of those of the list, is it possible to make useful
progress on something like binary-io at only the scheme level?

  if not, is there anyone who will take up the task of adding any
necessary low-level features?  i'd offer my help, but i don't know how
much use i would be at this point.

  my understanding of the discussion surrounding binary-io so far is:

  -chars are currently 8-bit in guile, but that is an accident of
   history -- someday they may have a different size.  so in the
   future, will chars not have a fixed size?  btw, is anyone working
   on multibyte character support?

  -ports are defined in terms of chars, and chars might not be
   fixed in width to 8-bits in the future.

  -if a port-centric interface is ok to use for binary-io, what happens 
   when one can no longer depend on the size of a char being 8 bits
   in guile?  would one create and manipulate a soft-port that returns 8-bit 
   quantities for its version of read-char?

  -if a port-centric interface is not ok, what should i use instead?

  concerning non-serial access to data, i thought i saw reference to
work someone was doing on a data structure that acts a bit like an
emacs buffer.  for some applications, couldn't that be used?  i guess
it might depend on the implementation of "buffers".

  also, i still don't see how at a scheme level, how one can detect
what the native format is for an int or a long.  the original design
of binary-io mentioned being able to manipulate native quantities...