output stream API
Sebastian Egner
(20 May 2005 09:40 UTC)
|
Re: output stream API Michael Sperber (20 May 2005 13:13 UTC)
|
Re: output stream API
Michael Sperber
(20 May 2005 13:25 UTC)
|
Re: output stream API Michael Sperber 20 May 2005 13:13 UTC
Sebastian Egner <xxxxxx@philips.com> writes: > Hello Mike, > 1. One specific thing that I just tripped over: The return values of > output-bytes, output-char etc. are unspecified. Did I miss > something, or shouldn't they rather return the new stream, as a > functional interface would? But there is no "new" stream---output streams are imperative. What would be the point? > Without the return code I would be more in favor of returning #f at > EOF for uniformity (breaking with SML Basis Library which is for a > stronly typed language). Yes, I've come to the same conclusion. > 3. Whenever there is a vector-like object (byte-vector, string) one can > combine the two operations with start index and/or count into a single > operation by using optional arguments. This reduces the number of ops > by about 10 to 15. I disagree that it reduces the number of operations in all cases---it just reduces the number of procedures that make them available. Of course, OUTPUT-BYTES-N is a generalization of OUTPUT-BYTES, but the same isn't really true for INPUT-BYTES-N and INPUT-BYTES. I'm reluctant to break the symmetry here. I generally don't feel that having many procedures is as much of a problem as the headaches of dealing with optional arguments, at least not in the presence of a decent namespace management system. Tastes differ, of course. > 4. One source of confusion for me is still the read/write/display legacy > of Scheme that went into this SRFI. Huh? This SRFI *breaks* with that legacy. Could you be more specific? > > 5. There are no constructors for creating ports from streams. Is that > intentional? No, it's an oversight. I'll fix it with the next revision. > 6. It would be great if there were a mechanism specified for passing > additional arguments (options) between the levels. Learning from > other existing I/O libraries, it is a recurring problem that you > need to pass funny little hints (e.g. access permission flags) down > (and sometimes up) the protocol stack to do what you need to do. I > am not talking about arcane IOCTLs, but over simple things like > opening a file for writing with the right attributes to actually be > able to write to it (this is no joke, R5RS open-output-file does not > specify what happens if the file exists.) That's definitely true. At the time of writing, I didn't have a good solution, so I stuck with using separate procedures for the common options. (I really dislike keyword arguments for various reasons.) I have a better idea now, and I'll try to do something about the issue with the next revision. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla