[R6RS] I/O

[Michael Sperber]

William D Clinger <will at ccs.neu.edu> writes:

>> > I believe I suggested an alternative some time ago: provide
>> > a procedure that takes an input port and a transcoding, and
>> > returns an input port that uses the transcoding.
>> 
>> I considered that, but it is very difficult to implement efficiently.
>> (At least for me.)  I believe PLT's implementation of these procedures
>> effectively turns off buffering on the underlying port, forcing the
>> decoding to happen character-by-character.
> [...]
> In my opinion, this combination of circumstances will be so
> rare as not to matter.

Later you wrote:

> I object to requiring every port to support a side effect
> that can change its buffering mode at any time. 

OK, but the procedure you suggest implies that a port needs to support
a side effect that can change its buffering mode---at least an
operation that changes it to non-buffering.

> What does matter is whether the R6RS provides convenient ways to
> open ports with all of the standard Unicode encodings, including the
> common (though nonstandard) situation in which the input might begin
> with a byte mark but is not known to do so, and a modest guess is
> required.

Is XML (where a tag somewhere in the first line indicates the
encoding) a common situation by that definition?


-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla