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

As I haven't known Gambit's machinery until a few minutes ago, I
couldn't have proposed Gambit-style custom ports. :)

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

Could you explain in what sense it would help the thread scheduler or
the user if ports instead of generators (in the SRFI 158) were used?