Re: [Scheme-reports] Question about R6RS standard-{input, output, error}-port

[Per Bothner <per@x>]

On 11/25/2013 07:51 AM, John Cowan wrote:
> It has to do with the peculiar behavior of R6RS ports when a textual
> port is created from a binary port.  The binary port remains open, but
> it is unusable.  In R5.92RS, stadard-input et al. just gave you access
> to the existing port, but you could never be sure just what you'd get.

Java has a similar problem: You typically create a pipeline of ports
(OutputStreams/Writers or InputStreams/Readers), to handle buffering,
conversions, and perhaps other filtering.  Flushing or closing one
of these objects will implicitly flush or close all of the objects
"lower" in the pipeline.  This is convenient when an entire pipeline
is created in one place.  However it is awkward when you have an
existing pineline and want to create a wrapper with extra pipeline stages.
If you then want to flush or close the added pipeline stages you can't
do that without flushing/closes the older stages.

However, explicitly closing the standard ports is not a normal thing to
do.  If you wrap a standard port with a transcoder, you probably would
not want to close it; even if you did want to close the textual port,
you probably wouldn't want to close the underlying binary port.  Still,
the specification of transcoded-port does make that difficult.

These problems are irrelevant to the (latest) Kawa, since the
initial values of the current-{input,output,error}-ports are both
textual and binary ports, so you don't need to wrap a transcoder.
It would be nice to have a way to access "the initial values of
(current-{input,output,error}-port)", but it may be the case that
using (standard-{input, output, error}-port) would be too much of
incompatibility, unfortuantely.

(FWIW, I used to think that the concept of a port that was both
binary and textual was dubious, but that is what I've now
implemented, and it seems to make sense.)
-- 
	--Per Bothner
per@x   http://per.bothner.com/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports