This page is part of the web mail archives of SRFI 68 from before July 7th, 2015. The new archives for SRFI 68 contain all messages, not just those from before July 7th, 2015.
SRFI-68 provides an implementation as its specification. The implementation is fully transparent, in that from a port object you can access the underlying stream, and from a stream you can access the underlying reader or writer primitive. This effectively precludes the use of existing I/O platforms (at least without serious contortions). The advantages of such an API specified down to the lowest level are that in general it is easier to come up with a cleaner, more consistent interface, and have greater flexibility to write portable extensions. SRFI-6 string ports, for instance, could be implemented more easily and efficiently in SRFI-68 than the hack of redefining all port operations as done in the SRFI-6 reference implementation. The disadvantages are many. You require implementations you rewrite their entire I/O subsystem. For implementations using the host platform's I/O you add a whole level of complexity they didn't have to deal with before (mollified slightly by the provision of the reference implementation). Embedded systems may grow to an unacceptable size (the reference implementation alone is over 100k source). Implementations without systems-level access will still be forced to to implement the low-level primitives on top of their platform's high-level facilities, thus forcing double buffering and drastic performance loss. In general you limit people's freedom to experiment with new I/O subsystems. There is an alternative. R5RS comes from a tradition of deliberately underspecifying things to allow different implementations. Schemes could be built on a variety of systems and experiment with their own way of doing things. Once you agree on the API and the results of operations, how those operations are performed is irrelevant. In the area of I/O R5RS is woefully underspecified, lacking even the API for much needed functionality. However we can extend this in a manner compatible with existing implementations without much difficulty. The primary problem is the difference between binary and character ports some implementations have for performance, simplicity and compatibility reasons. There are several ways to standardize this interface, discussion of which is ongoing on the SRFI-56 list. Other extensions are simply a matter of adding new procedures and options to handle things such as character encoding, file modes and permissions, getting and setting the port position, etc. Most Schemes already provide these operations, so all that needs to be done is standardize the interface. Handling future extensions like SRFI-6 and translation/layer ports isn't a problem either if you provide virtual/procedural ports as already used in many implementations. If it so chose, SRFI-68 could still go the route of portability by dropping or making optional the bottom two I/O layers. Full portability would require a binary/character port distinction, however. -- Alex