[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Specification vs. Implementation

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.

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/