On Sat, Feb 7, 2015 at 10:37 AM, John Cowan <[email protected]> wrote:
> Alex Shinn scripsit: > > > 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 still don't understand what is meant by leaky, or why this closure is any way preferable to a single object. > 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. > I was talking about the R6RS version. Did you mean the SRFI 6 version? The problem with a single global get-output-string procedure is that it needs a way to get at the underlying buffer associated with the string port, which you can't do portably. The best you can do is, assuming you have weak references, maintain a global weak hash eqv? table mapping string port to buffer. -- Alex
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
