Per Bothner <per_at_bothner.com> writes:
> 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.
I see where you're going, but binary ports and textual ports aren't
different types, not in Will's proposal, and especially not in mine.
That's not saying that I'm in principle opposed to them being
different types (see below), but I do care about having an I/O system
that lets me interleave textual and binary I/O.
> 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.
As you may remember from the discussion we had over on SRFI 68, I once
shared that position (and you'll find posts of mine on the
r6rs-editors list to the same effect), but Will has since convinced me
that letting one specific implementation strategy dictate the design
is a bad idea. The best way to let a Scheme program make use of iconv
is to provide it as is, and let the program invoke it explicitly. As
to my opinion on how efficiency should influence the design, see the
message you were replying to.
> * We need to have some way of layering textual i/o on top of binary
> i/o.
No, we can, but we don't need to to. Layering is one option in the
design space. (And I'd be happy with a layered design, as long as
layering a textual port on top of a binary one doesn't kill or
otherwise invalidate the binary port.) There are others.
--
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla
Received on Wed Nov 22 2006 - 15:45:36 UTC