[r6rs-discuss] Behaviour of lookahead-u8 and lookahead-char on custom ports
William D Clinger
will at ccs.neu.edu
Thu Aug 7 11:58:25 EDT 2008
> Given a custom port has get/set-position procedures, it could be done
> easily (I am not entirely sure I can depend other those procedures
> though), but without either, what should the behavior be? What happens
> with the get-xxx prodedures after a lookahead-xxx has been called? Is it
> up to the implementer to provide some 'wrapper/proxy' port to provide
> these indirectly?
Implementors of the R6RS are responsible for making
that work even if the custom port does not support
get-port-position and set-port-position!.
That wouldn't be hard, except there are three distinct
bugs in the design of R6RS custom ports that make the
R6RS impossible to implement (or to implement sensibly)
for certain cases.
As specified by the R6RS, custom implementations of
get-port-position cannot work reliably, because there
is no way for a buffered port to tell the custom
implementation about the current position within a
buffer, and all ports use lookahead buffering at the
very least. (This comes up in the situation leppie
cited, when a lookahead-xxx is followed by a get-xxx.)
Similarly, custom input/output ports cannot work
reliably in general, because there is no way for
the i/o system to tell a custom port to correct for
a lookahead byte or character when switching from
input to output.
Thirdly, and more broadly, all textual input/output
ports whose transcoders use variable-width encodings
(or use end-of-line styles other than none) have
problematic and/or partially undefined semantics.
Output operations that overwrite a character (or
end-of-line) with a character whose encoding is of
a different length have undefined semantics.
All three of these bugs have been documented for some
time in Larceny's list of deprecated R6RS syntax and
More information about the r6rs-discuss