On Mon, Apr 26, 1999 at 03:59:58PM -0400, William D Clinger wrote:
>In particular, it [the SLIB interface] is easily
>implemented using either the SRFI-6 or the Gambit interface.  As a
>simple, useful, and highly portable interface, I think the SLIB
>interface is especially deserving of an SRFI.

Since it's only a 4-line implementation, i don't think it
warrants an own SRFI, but that's a matter of taste i guess..

>Although the SRFI-6 and Gambit interfaces are compatible, in the
>sense that an implementation can easily support both at the same
>time, they are not interchangeable:  Neither interface suffices
>to implement the other in a straightforward way.  The SRFI-6
>interface does not provide any way to distinguish string ports
>from other ports

So... why not add a (string-port? port) procedure?

>Most programs do not need either of these features, however.  Most
>programs that use string ports can get along just fine with either
>the SLIB or the SRFI-6 or the Gambit interface, using SRFI-0 to
>determine which one is available.

This will end up in that every program has a routine to determine
whichever interface is awailable, and add wrapper functions
around them so the rest of the program doesn't see any
differences. That's what i see as the problem of multiple
exchangeable SRFI's..

>In the long run, I would hope that implementations would support
>the union of these interfaces.  I would also encourage implementors
>to support GET-OUTPUT-STRING-AND-RESET, which returns the string of
>characters that have been sent to an output string port since it
>was opened or last reset, and also resets the output string port
>so it no longer remembers the characters that have been sent to it
>so far.  For example, GET-OUTPUT-STRING-AND-RESET makes it easy to
>use an output string port as a buffer to connect concurrent threads.
>Input-output ports, as Marc described, would make this even easier.

In the long run, we need a better port interface :]
We at least are missing "soft-ports" (or however you want to call
them), that is, ports who get their characters from procedures
(or write to them). This is also a quite frequently implemented
feature.

I was working on a more general Ports SRFI, which included the
latter and a few extensions to the R5RS ports procedures.
Rethinking about it, i'd say that we should do the following:
- one SRFI to have a general port procedures, e.g.
	call-with-input-from-port call-with-output-to-port
	port? port-eof? port-closed?
	input-output-port?
- one SRFI for soft ports
- one SRFI for string ports

Notice that i say *one*
All (specialized) port SRFI's should contain a <type>-port?
procedure to distinguish those ports from the others.

And as a final comment, you should add
GET-OUTPUT-STRING-AND-RESET to SRFI-6 instead of encouraging
implementors in the discussion about it to implement it.

HTH,
	-forcer

--
((email . "xxxxxx@mindless.com")       (www . "http://webserver.de/forcer/")
 (irc   . "xxxxxx@#StarWars (IRCnet)") (pgp . "key available on my website"))