[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
- (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
- (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.
On 25-Nov-05, at 2:13 AM, felix winkelmann wrote:
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
Oh, and BTW - If I want SML, I know where to find it.