> From: Duy Nguyen <xxxxxx@gmail.com>
> Date: Thursday, September 10, 2020 11:42 AM
>
> 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.

Indeed, but you need something somewhere so that you can eventually
turn it into a port.  Like the posited new SRFI.

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

A compelling argument.  With the exception of file-info, and
set-file-mode, umask, and set-umask! which all take a magic integers
(which I bet a lot of us have wired into our minds) there's nothing
that gets you into the guts of POSIX except for these fd procedures.

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

Except for terminal?, which doesn't axiomatically belong in SRFI 170,
is in fact the sole survivor from that section of scsh, raw fds are
indeed not needed, and terminal? can be moved to one of several other
future SRFIs.

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

For "my" parts of SRFI 205: POSIX Terminal Fundamentals, all the
current procedures already take port arguments, but they all require
port-internal-fd.  Not sure about the scsh functions that per John
don't belong anywhere else that have been tentatively added to it.

> [ Process management, which I'll be staying out of. ]
>
>> 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 ..) ..)?

Point.  As well as (terminal? (port-internal-fd *port*)).

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

Of course; but it would be through the "+11" per Marc moving of this
SRFI 170 functionality into another SRFI (I hope I don't get a
reputation for chopping up SRFIs into smaller and smaller bits... :-).

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

As I mention in an email sent after you made this reply, we also have
truncate-file and file-info which need to convert from a port to a
file-descriptor.  But ... though it would be even more of a hack to
leave just post-internal-fd exposed in SRFI 170, it is as mentioned by
far the simplest thing you can do with a Scheme implementation's port
implementation.  And like Chibi Scheme, I'd expect it already cleanly
exists in a lot of Scheme implementations (my SRFI 170's
port-terminal-fd just does a port? sanity check on top of Chibi's
"port-fileno" primitive).

To restate, what I'm positing is:

Move all of 3.1 I/O but port-terminal-fd into a new SRFI, which
will be immediately worked on after SRFI 170's finalization.

Move terminal? to a different SRFI, probably 205, which is also
scheduled for immediate resumption of work after the finalization
of SRFI 170 (and resolution of 198).

As mentioned above, keep the now fully admitted hack of
port-terminal-fd in SRFI 170, because it's easy/trivial, is
needed by 170 and we don't want to indefinitely further delay
170's finalization.

- Harold