Just read his post. Works for me, and with a little luck and possibly a
few tweaks if/as discovered through use to be nice/required, it could win
broader acceptance. (although I suspect that it may be found necessary to
base read-char, read-string, etc. on a flexibly defined "local" encoding
definition, rather than assuming all text/data is encoded any particular
way, on any particular platform.)

where with a: (bytes->value <bytes> <encoding>) -> <value>
and matching: (value->bytes <value> <encoding>) -> <bytes>

then multiple <encoding> procedures may be defined as desired/required,
which could default to "local" definitions if not explicitly specified.

thereby enabling any arbitrary sequence of encoded bytes read/written
from/to a port to be converted to/from a generic internal scheme value
type, using whatever external encoded representations may be required.

Thanks again, -paul-

> From: Robby Findler <xxxxxx@cs.uchicago.edu>
> Date: Fri, 13 Feb 2004 09:01:45 -0600
> To: srfi-52@srfi.schemers.org
> Subject: Re: Encodings.
> Resent-From: srfi-52@srfi.schemers.org
> Resent-Date: Fri, 13 Feb 2004 16:01:57 +0100 (NFT)
>
> At Fri, 13 Feb 2004 03:00:51 -0500, Paul Schlie wrote:
>> Maybe I'm missing the boat, but from the best I can tell, all
>> discussions seem to be leading to the erroneous presumption that it's
>> adequate for scheme to restrict itself to exclusively processing data
>> originating, and destined as Unicode encoded text, which would be
>> most unfortunate.
>
> I don't think that this is the case. PLT Scheme, for instance (you may
> have seen Matthew's recent post on the plt-scheme mailing list), is
> going to have byte ports. If you do read-char on a byte port, the bytes
> coming out of the port will be interpreted as unicode (utf8 I believe,
> unless you specify otherwise) but you can also extract the bytes from
> the port directly.
>
> Robby
>