> From: Duy Nguyen <xxxxxx@gmail.com>
> Date: Thursday, September 10, 2020 10:48 AM
>
> Besides the procedures to "create" and close file descriptors, they
> are only needed to make a port. Why not combine open-file and
> fd->*port in one? All other procedures either take pathname or a port.

Because we want to allow users to be able to write C code to do other
things to file descriptors we haven't anticipated?  Of course, per
the below I should come up with some concrete examples, but that's
already happened with the change to terminal? you inspired.

> That removes file descriptors completely from the srfi.

That *would* simplify the API....

> Future srfis may need fds again (especially process management)

They will, and also my on hold until SRFI 170 is finalized and 198
is resolved SRFI 205: POSIX Terminal Fundamentals.

> but we could wait until then to introduce necessary procedures to
> either extract/dup fd from a port, or open an fd without going
> through ports. Adding back later is easier than removing or changing
> existing behavior.
>
> That removes port-internal-fd, which looks like a hack to me. And also
> remove (for now) the risk of accidentally closing an fd that belongs
> to some port.

While I won't disagree that it looks like a hack, before making such
a big change to the API I'd like something stronger, e.g. some concrete
examples, than your I grant legitimate intuition (we're all experienced
enough the "my initiation says" argument is good for red flagging etc.)

I'll repeat the strongest argument I know for the fd->*port functions:
they aren't really "POSIX", rather they get into the guts of a Scheme
implementation's port implementation, which I gather tends to be
complicated.  *IF* you can turn an arbitrary fd into a port, with the
various buffering options, you can do a whole lot stuff we haven't
explicitly anticipated.  For the reverse, see how port-internal-fd
simplified the implementation of terminal?

Ah, here's my firm "NO!" to your request, unless all these procedures
are moved from the SRFI, as we for example did with everything having
to do with other processes: what you suggest requires all the hard
work of integrating the SRFI with the Scheme implementation's port
implementation, while hiding the resulting file descriptor needed by
so many POSIX APIs and future SRFIs.  That work would have to be
copied under the hood for the latter.

The exception to "it's hard" is likely port-internal-fd, since that
should be a simple lookup; in the case of Chibi Scheme, I was able
to use without modification an existing core procedure.

Or all could be put into a separate API, with terminal? perhaps
moved to 205, which would ***significantly*** simplify the
implementation of SRFI 170, at the cost of making it even more
simple although not trivial.  That might be a good trade off, it
would still be somewhat monstrous....

- Harold