[r6rs-discuss] [Formal] Implementation-dependent transcoders considered harmful

From: William D Clinger <will>
Date: Sun, 10 Jun 2007 16:49:00 -0400

John Cowan wrote:
> There are three kinds of references to implementation-defined transcoders
> in R5.93RS. One is in the description of native-transcoder,
> which is appropriate: the native transcoder is inherently an
> implementation-specific notion. The other two kinds are respectively
> unnecessary and vague, and should be removed.
>
> The unnecessary ones are those which arise from the false
> assumption that a textual port necessarily has a transcoder.
> In fact, a textual port should have a transcoder if and only if
> it is derived (explicitly or implicitly) from a binary port of
> some sort. These transcoders don't do anything and should simply
> be removed. This involves changing port-transcoder to return #f for
> textual ports without transcoders, and removing the references to
> implementation-defined transcoders in open-string-{input,output}-port
> and make-custom-textual-{input,output,input/output}-port.

I concur. I would, however, warn the editors against
the parallel overspecification that would come of
requiring port-transcoder to return #f when passed
a port created by open-string-{input,output}-port
or make-custom-textual-{input,output,input/output}-port.
The specification of port-transcoder needs to be changed
in recognition of the fact that textual ports may or may
not have transcoders.

For example, the following (untested) implementation of
open-string-input-port should remain legal:

  (define (open-string-input-port s)
    (open-bytevector-input-port (string->utf8 s)
                                (make-transcoder (utf-8-codec) 'none)))

> I suggest at least the minimal change of saying that the
> procedures with-{input,output}-from file, open-{input,output}-file,
> {read,peek,write}-char, read, write, newline and display be specified
> to use the transcoder returned by native-transcoder.

I would recommend against that, because implementations
may have esoteric knowledge that lets them pick different
transcoders based on the file's type or content. That
would be consistent with John's suggestion only if the
native-transcoder were nonstandard (e.g. 'we-pick-em),
but requiring native-transcoder to return nonstandard
values in implementations of unusually high quality
seems like a mistake.

> However, I
> would greatly prefer providing for each of them to accept an optional
> final argument specifying an explicit transcoder. Doing so allows the
> simple procedures to be used with textual files using any reasonable
> representation, a necessity in modern programming environments.

I'm okay with that, but I don't think it's necessary.
The simple procedures are supposed to be simple; if a
programmer needs to supply an optional transcoder,
I think the programmer should open the file using the
io ports library instead.

Will
Received on Sun Jun 10 2007 - 16:49:00 UTC