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