On Sun, Jan 25, 2015 at 10:17 PM, Alex Shinn <alexsh...@gmail.com> wrote:
> > John took a survey ( > http://trac.sacrideo.us/wg/wiki/GetFromClosedStringPort) > and it looks like the de facto standard is that this "is an error." > I'm inclined to add an errata to that effect (similarly for > get-output-bytevector). > 11 implementations return the expected string. 11 implementations throw an exception. That doesn't look like a "de facto standard" of "is an error" to me. The string is not logically part of the "port" per se -- it represents the backing store the port writes to, as the file on disk is to an output file port. A string-port is not merely a derived class of output-port, it's a composite of a port and an interface to retrieve that backing store. So, closing the port should only "free resources" of the port part, but leave the backing store available. (btw, we're really talking about both get-output-string and get-output-bytevector, right?) I can imagine using ports for byte-stream transformations (like compression/decompression or other types of encodings) where finalization of the stream is required when you know the stream is to be terminated. flush-output-port might not be an adequate means of termination if you prefer a single delimited dataset in the backing store rather than a sequence of them. So, an explicit close might be required before retrieving the finalized data. +1 to Michael Montague's argument as well.
_______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
