Email list hosting service & mailing list manager

Section 3.2. (I/O, file descriptors) nomenclature Lassi Kortela 31 Jul 2020 10:55 UTC

The section 3.2 title is "I/O", perhaps to mirror the scsh manual. I/O
is quite vague and generic: anything that touches the file system is
basically I/O. In practice, section 3.2 only deals with file
descriptors; could it be re-titled "File descriptors"?

The name `open-file` sounds very generic, high-level and convenient. But
SRFI 170 `open-file` is pretty low-level, taking POSIX open() flags and
returning a file descriptor. I suggest renaming it to `open-fdes` for
symmetry with the `close-fdes` procedure that already exists.

The contraction "fdes" is somewhat non-standard, mainly used as a
placeholder name in some manual pages. The common Unix shorthand is
"fd". The generic cross-OS term is "file handle". Could we use either
"fd" or "file-handle"? Here's how things would look:

* open-fdes
* close-fdes
* port-fdes
* fdes->textual-input-port
* fdes->binary-input-port
* fdes->textual-output-port
* fdes->binary-output-port

* open-fd
* close-fd
* port-fd
* fd->textual-input-port
* fd->binary-input-port
* fd->textual-output-port
* fd->binary-output-port

* open-file-handle
* close-file-handle
* port-file-handle
* file-handle->textual-input-port
* file-handle->binary-input-port
* file-handle->textual-output-port
* file-handle->binary-output-port