[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Geez...



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