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