On Thu, Sep 10, 2020 at 11:29 PM <xxxxxx@ancell-ent.com> wrote:
>
> > 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.

If you can write C code, you can already call open() or close()
yourself. This is what I meant by FFI in response to Lassi. This is a
portable SRFI, why do we cater to FFI which is very likely
implementation specific and has to deal with implementation quirks
anyway?

> > 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.)

To me it's actually lack of real fd usage (and as I said, I don't
consider fd obtained from a specific implementation). So if we can
obtain fd from one of the existing SRFIs, or from r7rs, then we need
procedures to work with them.

Otherwise, I did not say we will not need fds. We may. But perhaps we
could find a way to introduce POSIX interfaces without fds. For the
terminal srfi, we could very well make it a port. Process management
could specify a list of file descriptors you want to spawn a new
process with, and these file descriptors could take ports. I see the
possibility that we may not really need file descriptors.

> 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?

How is it more complicated or unexpected than calling (fd->*port
(open-file ..) ..)?

> 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.

I don't see how it has to be copied. Doesn't code reuse exist? And
please note that we could introduce fd-based API _then_, when we see
the need. I'm not saying file descriptors can never enter Scheme
world.
--
Duy