I couldn't have said better myself.  These I/O libraries are just too
big and awkward for my taste.  I view Scheme as a high-level language
with few well chosen constructs that allow programming complex
applications in few lines of code.

I actually like the R5RS I/O model and think there are more elegant
ways to extend it to support the features that would make it more
practical (binary I/O, Unicode text encoding, devices such as
sockets, processes, etc).  For example, for binary I/O, these are
sufficient

- (read-u8 [port]) reads the next octet from the port
- (read-subu8vector u8vector start end [port]) reads a sequence of
octets into a u8vector
- (write-u8 [port]) writes an octet to the port
- (write-subu8vector u8vector start end [port]) writes a sequence of
octets from a u8vector

For Unicode text encoding and end-of-line encoding, just add some
optional parameters to the port opening procedures to supply the port
settings, and a procedure to change the port settings.  For example,
with named optional parameters (aka keyword parameters):

- (open-input-file "myfile.txt" char-encoding: 'utf8 buffering: #f)
- (open-file "myfile.txt" direction: 'input char-encoding: 'utf8
buffering: #f)
- (port-settings-set! myport buffering: #t eol-encoding: 'cr-lf)

Redesign of R5RS I/O from the ground up is not needed and will break
a lot of old code for no good reason.

Marc

On 25-Nov-05, at 2:13 AM, felix winkelmann wrote:

> Hello!
>
> I have a few meta comments about the general style of this
> particular SRFI and the barrage of IO SRFIs that are following
> this. I won't go too much into technical detail and don't plan
> to annoy people any further (unless forced ;-) with my opinions
> but feel strongly urged to comment:
>
> I think this SRFI shows a dangerous tendency to be "the mother
> of all I/O libraries" (a trap that many SRFI authors seem to fall
> into). I miss the simple elegance, that used to be a property
> of the Scheme language. That R5RS I/O isn't very comprehensive
> is true, but do we really need all this stuff? Does one really has
> to address each and every issue related to I/O and address them
> with an I/O layer that provides an API that is bigger than the
> whole rest of the language? (I haven't counted them, but its big...).
>
> The dependency on those dreadful exception SRFIs is unfortunate
> and unneeded. Once again a SRFI author builds up his own
> library infrastructure of interconnected SRFIs, forcing implementors
> to implement all of it or being non-compliant.
>
> A reference implementation that only runs on an unreleased version
> of one particular Scheme system isn't very helpful, and should
> perhaps not be called _reference_ implementation, IMHO.
>
> And then this silly remark about return values. Oh boy. Can we
> just leave it unspecified please? Why specify, or even propose
> a non-portable solution when simply _not specifiying_ would be
> enough?
>
> Oh, and BTW - If I want SML, I know where to find it.
>
>
> cheers,
> felix