This page is part of the web mail archives of SRFI 6 from before July 7th, 2015. The new archives for SRFI 6 contain all messages, not just those from before July 7th, 2015.
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 . "forcer@xxxxxxxxxxxx") (www . "http://webserver.de/forcer/";) (irc . "forcer@#StarWars (IRCnet)") (pgp . "key available on my website"))