Alex Shinn <xxxxxx@gmail.com> writes:

> 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.  [...]

> 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.

I don't understand why it would be a lot of work---that's what the
reference implementation is for.  Just drop it in.  You mainly have to
adapt the primitive I/O layer, which is usually pretty simple.  (You
could even build it easily on a pre-existing ports layer.)

> 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.

The bottom two layers are there because they're useful.  If all layers
are required, portable code could use whatever layer it wants to.  I
don't see why the lower layers (especially the primitive layer) would
necessarily be extremely slow---maybe you can elaborate why you think
this is the case?

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla