This page is part of the web mail archives of SRFI 68 from before July 7th, 2015. The new archives for SRFI 68 are here. Eventually, the entire history will be moved there, including any new messages.
Alex Shinn wrote:
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.
I agree. I think they're a separate feature/library, and should be a separate srfi. I think it may be reasonable for R6RS to define and require support for binary ports, but not the primitive I/O or the stream layer. The current draft says: Streams and ports from the upper layers of the I/O system always perform access through the abstractions provided by [the primitive I/O] layer. Hopefully that's not intentional - I certainly don't intend to go through the primitive I/O layer to do I/O! I think the Primitive I/O layer has very limited usefulness. It is somewhat similar to JAVA 1.4's 'java.nio' (New I/O) package, which I think very few people are using directly, and even fewer are using without also using non-blocking I/O. Input streams might be useful, but I don't understand what output streams are for. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/