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.
On 8/23/05, Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Alex Shinn <alexshinn@xxxxxxxxx> writes: > > > 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. > > That was the case in the beginning, but I dropped transparency two > revisions ago, precisely because of what you argue. Please check > again. Is it better now? I've checked, and believe your referring to the change from A port is essentially just a reference cell to a stream. to It is possible to construct ports from streams. Such a stream port is just a reference cell to a stream. The various procedures constructing ports described in this section are allowed but not required to return stream ports [BTW, I love what Aubrey Jaffer did with SRFI-70, using strike-outs for deleted text and additions marked in red. I hope future SRFIs take up this practice.] This means the standard procedures for creating ports are allowed to return ports based on the underlying I/O libraries with no relation to the SRFI-68 streams or readers/writers. There are still some ambiguities though, since we have both STANDARD-INPUT-PORT and STANDARD-INPUT-STREAM, and it's not clear what the relation between them is and what happens if you use both. Standard streams aside, an implementation that wanted to support SRFI-68 while still using its host platform's I/O libraries would still need to add the SRFI-68 reference implementation in it's entirety, basing the lowest reader/writer level on it's own high-level ports, and modify the native port operations to distinguish between native ports and SRFI-68 ports. This is a lot of redundancy and a lot of work. For portable code it would always be advisable to only use the port layer directly, since in many implementations the lower layers and ports built on them would be extremely slow, so the net result is that the bottom two layers become dead weight. It doesn't seem worthwhile requiring them. -- Alex