> 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
