Michael Sperber scripsit:
> The design of the (r6rs ports) library in the current draft, despite
> its numerous flaws, has the nice property that binary and textual I/O
> can be interleaved arbitrarily on the same port. While some may argue
> that it is not particularly important, I disagree. It is certainly
> useful in a number of circumstances,
Can you mention the circumstances in question?
> While lookahead issues on certain text
> encodings make this difficult,
I claimed earlier that there are no encodings that require general
lookahead (as opposed to state characterizing what has come before).
I now find that this is wrong: some unofficial but widely used Indic
encodings do require full lookahead, because they contain rules of the
form "xx followed by yy means U+xxxx, but when not followed by yy it
means U+yyyy and the next byte is part of a different character."
> This seems a bizarre way to implement what it essentially a
> destructive operation on a port. Why isn't `transcode-port' simply an
> imperative operation, the way it is in SRFI 81?
I'm fine with that.
> - 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.
Au contraire: we would be in a position of providing an interface
to something (interleaved text and binary) which will malfunction
in arbitrary ways depending on the current encoding, which may not
even be known to the program.
--
John Cowan cowan_at_ccil.org http://ccil.org/~cowan
If I have seen farther than others, it is because I was standing on
the shoulders of giants.
--Isaac Newton
Received on Wed Nov 22 2006 - 11:45:15 UTC