On Sat, Jan 31, 2015 at 3:24 AM, Jim Rees <[email protected]> wrote:
> On Sun, Jan 25, 2015 at 10:17 PM, Alex Shinn <[email protected]> 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. > That's exactly what it looks like to me. Or rather, there is no de facto standard, so it becomes "an error." If we were to say otherwise we would be forcing authors to reimplement string ports, and misleading users who would expect something to be portable when it isn't. 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. > >From the user perspective there is no separation between the port and any backing store, and they otherwise have no way to free the resources. You should be able to reliably accumulate a very large port and free it, or alternately maintain many medium ports and not worry about them hogging memory after closing. 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. > This is interesting, but I'm not sure that implicit final output on closing a port is a good idea. Regardless, this is purely hypothetical. +1 to Michael Montague's argument as well. > That's what I acknowledged as an idiom taking advantage of this. I've personally never seen a write-and-close API though - usually it's call-proc-and-close, where you have a callback before the final close. Bear writes: This also brings up the interesting possibility that get-output-string > ought to be defined on files as well, converting the contents of the > whole file into a string. > You mean get-output-string on file-backed ports? (Please don't conflate ports, strings and files, they are all different things for good reason.) One could imagine this extension but I'm not sure it's useful, and introduces a whole host of issues. Overall, I haven't seen any arguments nearly strong enough to force authors to change their implementations. -- Alex
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
