Alex Shinn scripsit:

> Closing the port should _always_ make further I/O an error.

Sure.  The issue is whether calling get-output-string counts as I/O.

> The way R6RS handles this, prevents one from having to expose a potentially
> > leaky abstraction as in SRFI 6.
> >
>
> I'm not sure what you mean by leaky here.

The point is that in R6RS the procedure which exposes the chars in
the port can be called without having to have the port itself,
because it closes over the port.

> I personally prefer the R6RS API, partly because the question
> of get-output-string on non-string ports becomes  a non-issue,
> and partly because once you introduce custom ports, then
> string ports can just be a library function.

I don't understand why those don't apply to the R6RS version as well.

>
> But that's completely orthogonal to the discussion, and R6RS
> has the same issue: calling the get-output-string procedure on
> a closed port is unspecified.

Agreed.

--
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
"Make a case, man; you're full of naked assertions, just like Nietzsche."
"Oh, i suffer from that, too.  But you know, naked assertions or GTFO."
                        --heard on #scheme, sorta

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