William D Clinger wrote:
> The real requirements appear to be:
>
> * Support conversion of binary ports into text ports,
> mainly to support use cases such as input from XML
> files, where the transcoder is determined by reading
> a small prefix of the file.
Plus the fact that (expect for string ports) text ports in
general are by nature a wrapper around a binar port. This
includes file ports.
> * The binary transcoder is a special pseudo-transcoder
> that is returned by the binary-transcoder procedure
> (which would be added to the procedures described in
> section 15.3). Every binary transcoder is eqv? to
> every binary transcoder (but not necessarily eq?),
> and is not eqv? to any transcoder that is returned
> by the make-transcoder procedure. The transcoder-codec,
> transcode-eol-style, and transcoder-error-handling-mode
> procedures return #f when given a binary transcoder as
> their argument.
Note sure if the "binary transcoder" is a necessary or useful
concept. See below.
> * The binary lookahead-X, get-X, and put-X operations
> (which have "byte" or "bytes" in their names) operate
> only on binary ports.
> ....
> * The textual lookahead-X, get-X, and put-X operations
> operate only on text ports. They do not accept a
> transcoder as an argument.
So it seems the types text port and binary have largely disjoint
operations. That suggests they should be viewed as distinct types,
and there should be different functions for creating text ports
and binary ports. At which point you don't really need the
concept the "binary transcoder": A binary port is a source/sink
of bytes while a text port is a source/sink of characters.
Some text ports are defined (and implemented) in terms of
a lower-level byte port. Such ports have a transcoder,
but a transcoder is not inherit in the concept of either text
or binary ports.
> * To simplify the process of reading individual characters
> a binary port, the R6RS should provide something like
> get-char-from-binary and lookahead-char-from-binary,
> which would take a binary port and a transcoder as
> arguments. (See [issue:lookahead].)
But that gets us back into the mess of arbitrarily switching
between binary and text input that we were trying to get away
from. For one thing, it can't handle stateful transcorders.
> [issue:readers]
>
> The readers described in section 15.2 of the draft R6RS
> might seem relevant to the problem of providing ports
> with arbitrary lookahead, but they can't solve that
> problem because they aren't ports. It seems as though
> the right thing to do may be to eliminate readers and
> writers from the report, while folding their functions
> into ports that represent arbitrary sources and sinks.
> That might be too radical for R6RS, but dropping readers
> and writers from the R6RS would clear the way for a more
> general solution in R7RS.
Yes, drop readers and writers. But instead allow people
to define ports from a set of functions. I.e. instead of
make-simple-writer define make-text-output-port and
make-binary-output-port. The write procedure for the
former would work on a string rather than a bytes object,
of course. (This is another reason for making binary and
text ports separate types rather than just different states.)
--
--Per Bothner
per_at_bothner.com http://per.bothner.com/
Received on Thu Nov 16 2006 - 02:20:02 UTC