This page is part of the web mail archives of SRFI 79 from before July 7th, 2015. The new archives for SRFI 79 contain all messages, not just those from before July 7th, 2015.
I/O is where programs meet the real world, which is not as elegant and consistent as we wish. It is inevitable for the I/O library to bloat if one wants to support any possible situation that may occur in the practical applications. However, I wish I/O srfi to allow implementators to adopt features selectively, and gradually from the infrastructure they already have. Splitting former srfi-68 into several srfis was an important step towards that and I appreciate the author's effort. And I especially like that the port layer no longer assumes the stream layer. At this point, if I were to adopt some of those srfis, I would take only srfi-81 (the Port I/O). For the implementations that already have extended port features such as block I/O, file positions, and customizable I/O routines, srfi-79's readers and writers adds little value. The layering of reader/writer and port/stream is fine for a design of a new I/O subsystem of a certain implementation. If these srfis are to be common API among various implementations, however, they should be designed so that the existing implementations can naturally extend their features towards these srfis. So, as far as the common API is concerned, I'd suggest to make design discussion top-down (from the port layer) instead of bottom-up (from the reader/writer layer). Let's find a port APIs that can be implemented efficiently on various implementations' native ports. I'll comment on srfi-81 later... --shiro