Geez...
felix winkelmann
(25 Nov 2005 07:13 UTC)
|
Re: Geez... Marc Feeley (25 Nov 2005 12:48 UTC)
|
Re: Geez...
Shiro Kawai
(25 Nov 2005 23:51 UTC)
|
Re: Geez... Marc Feeley 25 Nov 2005 12:48 UTC
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