Yup, same basic page; with a few asides:

- still don't suspect it's a good idea to specify any particular encoding
  for scheme's required character-set.

- still don¹t suspect it's a good idea to allow potentially non-portable
  characters to be used in identifier or comments.

- still suspect it would be nice to be able to extend the concept of being
  able to specify hierarchical format/encoding port procedures.

- and lastly, actually rather like your "titled:" argument syntax, makes
  reading and likely writing most code much easier and less error prone.

> From: Per Bothner <xxxxxx@bothner.com>
> Date: Fri, 13 Feb 2004 10:34:47 -0800
> To: bear <xxxxxx@sonic.net>
> Cc: Paul Schlie <xxxxxx@comcast.net>, xxxxxx@srfi.schemers.org
> Subject: Re: Encodings.
> Resent-From: xxxxxx@srfi.schemers.org
> Resent-Date: Fri, 13 Feb 2004 19:34:54 +0100 (NFT)
>
> bear wrote:
>
>> If there are multiple encodings/canonicalizations/etc in use
>> on a system, let schemes on those systems implement multiple kinds of
>> character ports.
>
> I don't think that's a good idea.
>
>> But it follows that there is NO WAY we should rely on I/O of
>> characters through character ports to read or write a particular
>> binary representation for "raw" data such as sound and image files.
>
> Does not follow.
>
> May I suggest the Kawa solution:
>
> You want to be able to specify character encoding when you open a
> file, even if people mostly use a system dependent port.  However
> that encoding is specified is orthogoal to my suggestion:  It can
> be a parameter object or a option parameter:
>
> (define p (open-input-port "foo.txt" encoding: "ebcdic"))
>
> Add a special encoding for binary files:
>
> (define b (open-input-port "foo.bin" encoding: "binary"))
>
> A "binary" encoding maps the byte n to (integer->char b),
> with no translations.
>
> Notice that a Windows or MacOS 8-bit system may do line-end
> munging for the default encoding, but is not allowed to do
> so for "binary".
>
>> The only reason programmers want to write characters that aren't in
>> the "normal" encoding/canonicalization/etc, is when they need really
>> close control of the exact format of I/O.  But when you need control
>> *that* close, you're not talking about a "character" port at all any
>> more; you're talking about binary I/O.  Rather than breaking the
>> abstraction barrier on character ports, you need a different kind of
>> port.  We need binary ports that support operations like (read-bytes)
>> and (write-bytes).
>
> Perhaps if you started from scratch, but my solution is more
> compatible with existing Scheme code.
> --
> --Per Bothner
> xxxxxx@bothner.com   http://per.bothner.com/
>