Lets say I have an existing routine 'write-stuff-and-close' which works just fine with file ports and seems like a reasonable thing to do. If get-output-string on a closed port is an error, then I can use a string output port with the routine, but I can't get at the output. This seems like an arbitrary restriction.
On Sun, Jan 25, 2015 at 7:17 PM, Alex Shinn <[email protected]> wrote: > None of SRFI 6, R6RS or R7RS specify what happens when you > call get-output-string on a string port which has been closed. > > 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). > > The pros to allowing access to an already closed port are: > 1. the reference and many other implementations allow it > 2. it can be useful in some idioms > > The cons are: > 1. it's already an error in many implementations > 2. close-output-port is expected to free resources > 3. arguably relying on it is poor coding style > > Thoughts? > > -- > Alex > > > _______________________________________________ > Scheme-reports mailing list > [email protected] > http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports > >
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
