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

Re: 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.

On Thu, 16 Jun 2005, Michael Sperber wrote:

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

...as well, now, as making argument conventions more consistent
compared to those specified 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.

I fully agree here.