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 co...@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
