Michael Sperber wrote:
> Why isn't `transcode-port' simply an
> imperative operation, the way it is in SRFI 81? (I'm pretty sure
> there's a rationale, but it isn't stated.)
Having transcoded-port return a new object makes sense if text
and binary ports support separate operations. Having an imperative
operation that changes the *type* of the port is awkward. It makes
any extension to add optional type declarations difficult.
> This actually seems a throwback to the (r6rs ports) library in the
> current draft, and it does allow a limited form of interleaving text
> and binary I/O. This the raises the general question of why
> `transcode-port' really needs to close the underlying port at all, or
> why the transcoding cannot be changed once it's set. I suspect this
> is to facilitate the inlining of the inner loop of the encoder or
> decoder, as you've demonstrated the efficiency of that implementation
> model. What you haven't done is demonstrated what the inefficiencies
> of a stateful transcoder would be, or discuss whether those
> inefficiencies would be inacceptable.
It isn't just inefficiencies in the abstract, but the practical desire
to be able to use existing character-transcoding libraries, such as
iconv. These are designed for buffering. An efficient implementation
will "transcode-ahead". If the application then switches to a different
encoding, that may be difficult.
> - The various procedures for reading textual data only remove as much
> binary data from the underlying data stream as necessary. For the
> Unicode encodings, this is trivial. For other, more stateful
> encodings, this may be more complex, and may in effect prohibit
> interleaving textual and binary data, but then we'd be no worse off
> than before in those cases.
If in effect we prohibit interleaving textual and binary data on
non-Unicode encodings, we should really prohibit it, so implementors
don't waste their time on this problem, and (more importantly) users
don't write programs that are "effectively prohibited".
To summarize again:
* We need to have some way of layering textual i/o on top of binary i/o.
* Other general switching between encodings is difficult and not very
useful and so should not be standardized.
* The special case of switching between Unicode and binary
can probably be implemented efficiently. However, requiring this
means that binary and text ports are the same kind of objects,
which complicates any kind of static typing.
--
--Per Bothner
per_at_bothner.com http://per.bothner.com/
Received on Wed Nov 22 2006 - 12:26:57 UTC