[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: alternative SRFIs for string ports
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
>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
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.
port? port-eof? port-closed?
- 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.
((email . "forcer@xxxxxxxxxxxx") (www . "http://webserver.de/forcer/")
(irc . "forcer@#StarWars (IRCnet)") (pgp . "key available on my website"))