> On Apr 23, 2020, at 10:01 AM, John Cowan <xxxxxx@ccil.org> wrote:
>
> On Thu, Apr 23, 2020 at 9:07 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
> John, in case you are referring to the ideas I have been exchanging
> with Shiro, there may be a fundamental misunderstanding (or I am
> mistaking in this regard). I've never meant that `read' or `write' or
> should be customizable for custom ports.
>
> That is reassuring.  I was interpreting this discussion to propose custom ports that work like Gambit's object ports, where `read` and `write` operations do not necessarily involve S-expression I/O.  For example, Gambit directory ports are a case of object ports in which `read` returns the next filename in the directory as a string; vector-ports are another case that are backed by a vector and an index, and reading and writing do ref and set! operations on the vector.  Such port types do not support {read,write]-{char,u8} operations.
>
> I believe that it is better to support such operations using SRFI 158 machinery rather than port machinery, as in SRFI 170's `make-directory-files-generator` and SRFI 158's `vector->generator` and `vector-accumulator`.

The advantage of port machinery is that you can specify a “timeout” for the operation and this can apply to all types of ports.  The thread scheduler can be made aware of this.  This feature is important when dealing with any form of I/O when the program must ensure timely progress.  Even listing files from a directory requires I/O.  This can’t be done with SRFI 158.  That’s why I think ports are a more general mechanism, and they predate “generators” which are in a sense a different interface to streams of things (bytes, characters, objects, filenames, incoming network connections, etc).  Why have two interfaces for the same concept?

Marc