William D Clinger <will_at_ccs.neu.edu> writes:
> To prevent programmers from rewriting that mess hundreds of
> times, I think the R6RS should provide something like
> get-char-from-binary and lookahead-char-from-binary.
My design does that by leting buffered ports support arbitrarily far
lookahead, and providing a kind of port based on a buffered port which
allows to read data without consuming them from the underlying port,
i.e. reading is implemented in terms of lookahead of the underlying
port. Then a transcoder can be put on top of that peeking port, and
thus characters it produces can be examined without disturbing the
original port (only some data is moved from the external source to
internal buffers).
The basic building blocks of some I/O code in my design are extensible
byte arrays and character arrays. Extensible in the sense of
supporting efficient adding or removing of subsequences at both ends.
Such arrays are used as internal buffers, and as arguments for block
I/O functions which move data between the port and such array or vice
versa. The internal interface of a transcoder moves data between two
such arrays. This allows the layers to compose nicely. I think this
is easier to use than managing indices and vectors separately.
Unfortunately Scheme doesn't support extensible arrays out of the box,
which makes porting my design to Scheme harder. Bringing a whole new
sequence type would depart from the Scheme tradition of using
fixed-size vectors, which makes the whole design less pretty in this
context. But without such arrays my design would have to be redesigned.
Java NIO uses buffers designed especially for I/O. They are backed by
a fixed-size array, and thus they have a maximal size. They are more
complicated conceptually than my arrays: a Java buffer contains 3
indices pointing inside its data, while my array is just an extensible
sequence, where managing the overallocation needed for good amortized
cost is an internal implementation detail. I haven't investigated
whether the Java interface allows for some better efficiency than my
design (perhaps avoiding some copying?).
--
__("< Marcin Kowalczyk
\__/ qrczak_at_knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Received on Tue Nov 07 2006 - 18:58:11 UTC