On 01/30/2015 10:32 AM, Michael Montague wrote: > On Fri, Jan 30, 2015 at 10:24 AM, Ray Dillinger <b...@sonic.net> wrote: > >> >> >> On 01/30/2015 09:52 AM, Michael Montague wrote: >>> 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. >>> >> >> And what, exactly, does it mean to "close" a string port? >> Is there any reason why you cannot or should not immediately >> reopen the string port you just passed 'write-stuff-and-close' >> when it returns if you want to read from it? After all, >> you'd have to do the same with any file port if you wanted >> to read from it after passing it to that routine. >> >> > If there was a way to reopen an output string port and read from it that > would work and there would be no issue. But the only want to get the > contents of an output string port is via get-output-string. >
Ah! I see, there is no place in the standard where it says you have to
be able to use ports with strings in all the same ways you use ports
with files. I don't know how I missed that, I should have objected to
its absence before now!
If we have string ports in the first place, the inability to use
them like files - ie, open ports on them for reading at need - is
more likely to be the standardization problem that needs to be
addressed than any idea that reading from a closed port is other
than an error.
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.
Bear
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
