This is the mail archive of the guile@sourceware.cygnus.com 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: binary-io, opposable-thumb, pack/unpack (was Re: binary-io (was Re: rfc 2045 base64 encoding/decoding module))


> From: Per Bothner <per@bothner.com>
> Date: 17 Feb 2000 22:32:40 -0800
> 
> My point is that logically some character ports work by doing
> decoding/encoding of bytes that it gets/puts from/to an underlying
> byte sequence - i.e. byte port.  You want people to be able to plug in
> new byte sequence types, so you *do* have a completely different port
> type.  I.e. you have byte-port objects that are instances of specific
> kinds of byte-port classes, with methods for things like reading a
> byte.  So the question is: Do you want to want to make these
> underlying objects available as Scheme values, and if so do you want
> to overload the existing character-port functions on byte-port
> objects?  You don't have to - it is quite plausible to say the
> underlying byte ports are only accessible from the C api.

I don't think there's any real obstacle to implementing a new
pack/unpack module for Guile, without changes to the I/O system.  The
basic conversions of binary numbers would be most easily written in C
to get bytes directly from the underlying port implementation.

Given a procedure like (read-foobar-16 port), I don't think it would
be too hard to find a way to implement it for other Scheme
implementations (or deal with future modifications to Guile.)  It's
possible to imagine it defined using read-char, even it it turns out
it can only work on ports opened in a particular way, or if the
procedure itself needs to switch the port temporarily to a raw-byte
encoding if it's not already in that state.

R5RS doesn't actually guarantee much about character <-> integer
conversion, e.g., in Scheme48/Scsh the integers start at 1000:

(char->integer #\a) => 1097

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