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