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.