> I have created a branch of SRFI 170 at <
> https://github.com/johnwcowan/srfi-170/tree/no-io>

Thank you for this. Interesting to hear what Olin has to say.

(Does anyone know of a simple HTML diff program? The git diffs of raw
markup are a bit hard to read.)

> In addition, the other procedures in this branch no longer accept fds, only
> ports and in some cases filenames (which merge things like stat() and
> fstat()).

Can you list the affacted procedures? I can't find them in git diff.

Preliminary comments follow.

Port vs fd:

- (port->fdes port) -- This procedure is good to have but I would rename
it. The arrow is ambiguous: you can't be sure from its name whether it
returns an existing fd or creates a new fd (i.e. what dup->fdes does now).

- (dup->fdes port fd) -- I would perhaps leave this out. It's useful to
provide a direct analog of the Unix (dup2 old-fd new-fd) so it has fds
for both arguments. Some ports also don't have fds associated with them
(i.e. port->fdes return #f) and it's not obvious from the name what this
procedure does in that case. If the user has (dup2 old-fd new-fd) and
(port->fdes port) then they can be combined to do what this does now,
but the result is more explicit (port->fdes is the only gateway from
port-land to fd-land, and you have to call it manually, which I like).

- (fdes->textual/binary-input/output-port fd) -- I presume these
procedures still cause the underlying fd to be closed when the port is
closed. It would most likely be good to have procedures that create
ports that don't close the fd. (If somebody else closes the fd and you
try to read from the port afterwards, the read would simply be an error.
Unix read() probably returns EBADF in that case.)

- Taking the above into account: (fdes->port textual? output? close?).
Of course there could be more options (e.g. character encoding and
newline policy for textual ports) and maybe it's not nice to have so
many nameless boolean arguments in a row.

- "There is no close-fdes procedure" -- What's the rationale?

Spawn:

- The process spawning facility can be expected to spawn
implementation-specific extensions. (For a taste of the possibilities,
see Go and Python, Emacs Lisp start-process function family, and e.g.
CLISP's run-shell-command and run-program at
<https://clisp.sourceforge.io/impnotes/shell.html>. A good interface
would either use keyword arguments, or have the user create a
not-yet-launched-process object on which they can set all the options
before passing it to a launch procedure.

- Allowing the user to set arg0 (i.e. program name) is good.

- Allowing user to set subprocess environment (without clobbering the
parent's environment with setenv) is good.

- on Windows it will have no access to the terminal at all -- might be
clearer to use the Windows term "console" here

- Python has subprocess.check_call() and subprocess.check_output() and
Also the subprocess.CompletedProcess object is good. It has a method
check_returncode(): raise a CalledProcessError if the process didn't
exit with code zero.

Other:

- (abort) -- How do we reconcile this with R7RS emergency-exit and
similar procedures? Unix itself has abort(), _exit() and exit(). I'm not
familiar with simiar Windows functions (other than ExitProcess()). I
would also side with usability expert Bruce Tognazzini (asktog.com) that
emotionally loaded words like "abort" should be avoided in user
interfaces (which APIs are). SIGABRT may be unavoidable; adding an abort
function is not.

- exec-path-list -- Why is this a variable not a function? As you note,
PATH can change in the middle of running the process. If the user wants
to save the old path for some reason after changing it themselves,
shouldn't they make their own variable to save it?