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
