Michael Sperber wrote:
> Alex Shinn <xxxxxx@gmail.com> writes:
>
>
>>Yes, exactly.  But R5RS ports built on native ports can offer high performance.
>
>
> Not as high as the primitive I/O layer.

That is because the primitive I/O layer supports:
(1) reading/writing into blobs;
(2) better control over buffering.

Your extended version of ports supports reading/writing
blobs.  I see no reason you can't add buffering control
to ports.

That seems to remove the point of readers/writers as a
separate data type.  I.e. I suggest combining read (resp. writer)
and input-port (rep. output-port) into one type.

If ports are required to support byte operations, then there
is little point in a separate primitive byte i/o layer.  Having
separate layers may be elegant for specification, but I don't
think it helps implementation, and it just inconvenieces users.
Why should they have to learn two sets of very similar APIs?
What does that give them?
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/