This page is part of the web mail archives of SRFI 79 from before July 7th, 2015. The new archives for SRFI 79 contain all messages, not just those from before July 7th, 2015.
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