On 01/30/2015 10:32 AM, Michael Montague wrote:
> On Fri, Jan 30, 2015 at 10:24 AM, Ray Dillinger <bear@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

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports