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

[Per Bothner <per at bothner dot com>]

sen_ml@eccosys.com writes:

>   -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.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/