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
xxxxxx@bothner.com   http://per.bothner.com/