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 <alexshinn@xxxxxxxxx> 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