[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

How important is R5RS compatibility for I/O?

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.



The Imperative I/O layer of SRFI 68 already deviates from R5RS in some
aspects, such as the absence of a distinct EOF object.  Taylor
Campbell has suggested making the naming more regular, which would
rename a number of identifiers from what they are in R5RS.

This raises the general question of how important R5RS compatibility
is in this area.  My own personal sense is that most I/O-bound
programs aren't portable anyway, because R5RS doesn't provide near
enough functionality, so they have to resort to
implementation-specific abstractions.  (Moreover, a R5RS compatibility
layer would be trivial to implement on top of SRFI 68.)  This would
imply that R5RS compatibility shouldn't be a primary concern here.

It'd nice to have some sense of what the community thinks on this
issue---any input would be much appreciated.

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