[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: output stream API

This page is part of the web mail archives of SRFI 68 from before July 7th, 2015. The new archives for SRFI 68 contain all messages, not just those from before July 7th, 2015.



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