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.
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