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