Some comments Duy Nguyen (09 Sep 2020 11:38 UTC)
Re: Some comments hga@xxxxxx (09 Sep 2020 13:14 UTC)
Re: Some comments Duy Nguyen (09 Sep 2020 14:06 UTC)
Re: Some comments John Cowan (10 Sep 2020 02:05 UTC)
Re: Some comments hga@xxxxxx (10 Sep 2020 03:06 UTC)
Re: Some comments hga@xxxxxx (10 Sep 2020 03:21 UTC)
Re: Some comments John Cowan (10 Sep 2020 03:55 UTC)
Re: Some comments Duy Nguyen (10 Sep 2020 09:17 UTC)
Re: Some comments hga@xxxxxx (10 Sep 2020 14:43 UTC)
Re: Some comments Duy Nguyen (10 Sep 2020 15:35 UTC)
Re: Some comments hga@xxxxxx (10 Sep 2020 14:26 UTC)
Re: Some comments John Cowan (10 Sep 2020 15:39 UTC)
Re: Some comments Duy Nguyen (10 Sep 2020 09:29 UTC)
Re: Some comments Alex Shinn (10 Sep 2020 13:01 UTC)
(missing)
Fwd: Some comments John Cowan (10 Sep 2020 16:25 UTC)
Re: Fwd: Some comments hga@xxxxxx (10 Sep 2020 18:16 UTC)
Re: Fwd: Some comments John Cowan (10 Sep 2020 18:21 UTC)

Re: Some comments hga@xxxxxx 09 Sep 2020 13:14 UTC

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