[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: output stream API
Sebastian Egner <sebastian.egner@xxxxxxxxxxx> 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
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