This is the mail archive of the
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))
> -ports are defined in terms of chars, and chars might not be
> fixed in width to 8-bits in the future.
The way I think it should work (at least this is what I'm doing in Kawa):
You need four kinds of (generic) ports:
byte-input-port: Reads a sequence of 8-bit bytes
char-input-port: Reads a sequence of (wide) characters (e.g. Unicode).
byte-output-port: Writes a sequence of 8-bit bytes
char-output-port: Writes a sequence of (wide) characters (e.g. Unicode).
For compatibility and convenience, you want a procedure like read-char
to accept either a byte-input-port or a char-input-port. If the
specified port is a char-input-port, the result should be a character,
as if returns by (char->integer BYTE). Similarly, write-char
works on both byte-output-port and char-output-port.
A char-input-port can be created by taking a byte-input-port with
a character-encoding-specification. Similarly, a char-output-port
can be created from a byte-output-port and a character-encoding-specification.
(These are not the only ways to create a char-input-port or char-output-port,
of course.) When open a file (open-input-file, open-output-file),
the run-time first opens a byte-input-port or a byte-output-port,
and then combines that with a character-encoding-specification (either
a default one or one explicitly specified) to return a char-input-port
or a char-output-port.
I don't know what the Guile maintainers plan to do, but this seems the
cleanest way to do it to me.