Michael Sperber wrote:
Alex Shinn <alexshinn@xxxxxxxxx> 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 per@xxxxxxxxxxx http://per.bothner.com/