Speaking for myself, as John has resumed editorial control of the SRFI.

> From: Duy Nguyen <xxxxxx@gmail.com>
> Date: Wednesday, September 09, 2020 6:37 AM
>
> First-time read (or not, but even so I can't recall anything specific
> from previous reads). Sorry if some of these have been debated before.
>
> [...]
>
> 3.3 I/O
> -------
>
> [ Something we agree on. ]
>
> Should we say anything about making a port from a _directory_ fd?
> There are some use for that in POSIX, but it's definitely not readable
> (and absolutely not writable).

In general the approach has been to mention the gotchas in using
POSIX.  This issue doesn't sound like that, people who try to read or
write from it will quickly find out that doesn't work, and we
implicitly state that by having open/read/close-dir. And as you note,
there are useful POSIX things to do with a directory, like use
set-file-times on it.

> 3.3 Filesystem
> --------------
>
> [...]
>
> Also should set-file-owner take a port? There's fchown for that.
> There's also fchmod.

That option and many other possibilities fell to our applying the
80/20 Pareto principle to strictly limit the procedures that take more
than a filename.  That was done to limit the burden on an implementor,
it's a monster of an SRFI.

> [...]
>
> 3.5 Process State
> -----------------
>
> [...]
>
> 3.11  Environment variables
> ---------------------------
>
> The concurrency note is interesting. Can we just state that all
> procedures in this srfi are thread safe on implementations that
> support threads?

Requires more work for the implementor, and a user could limit his
use of the SRFI to one thread, or otherwise in the Worse is Better
philosophy of POSIX take due care.

> 3.12  Terminal device control
> -----------------------------
>
> I wonder if the procedure name should be terminal-port? instead of
> terminal? It's clearer and I doubt people would need to type this a
> lot to matter.

Good point.  But I note that it would be trivial for it to dispatch on
port? and fixnum?, since currently it does three things (well, in my
Chibi Scheme sample implementation): sanity check confirm the argument
is a port, grab the fd from the port, and call the POSIX function on
the result.

And adding fds as arguments will be handy for my SRFI 205: POSIX Terminal
Fundamentals; I recommend making this nearly trivial change.

- Harold