(Consolidated response)

Michael Montague scripsit:

> 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.

I agree, the more so because 'write-stuff-and-close' is essentially a
special case of the R7RS standard routine 'call-with-port'.

Jim Rees scripsit:

> 11 implementations return the expected string.
> 11 implementations throw an exception.

Witnesses should be weighed, not counted.  In addition, this evidence is
particularly weak, because we don't know which of the first set of
implementations returned the value intentionally, and which as a
non-guaranteed side effect of how they implemented output string ports.

> That doesn't look like a "de facto standard" of "is an error" to me.

"Is an error" does not mean that an error is signaled (exception is
raised).  It means the implementation can do whatever it wants, and the
user must take the consequences whatever they are.  It corresponds
to "undefined behavior" in other language standards.

> 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.

I agree with this reasoning.  Closing a port should mean that I/O is no
longer possible on the port, not that there is nothing at allthat can be
done with the port.

> (btw, we're really talking about both get-output-string and
> get-output-bytevector, right?)

Yes, absolutely.

Bear scripsit:

> 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.

You can open an input port on a string whenever you like.  But a
string output port is not a port opened on an existing string
(which would be of little use, since Scheme strings are not
extensible), but a port that generates a newly allocated string.
Until you call get-output-string, there is no string on which
to open a future input port.

--
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
        "You need a change: try Canada"  "You need a change: try China"
                --fortune cookies opened by a couple that I know

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