Re: Remove file descriptors completely from srfi-170? Duy Nguyen 10 Sep 2020 17:50 UTC
On Fri, Sep 11, 2020 at 12:36 AM <xxxxxx@ancell-ent.com> wrote: > > > 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. See my "Scheme X" reply to Lassi. Yes we new SRFI, no we don't necessarily need to turn an fd to a port. > > 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. That's more POSIX than Scheme implementations. The only good thing is those magic numbers do not come with the resource management complication caused by fd<->port relationship. > 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. Easy and trivial does not make a good design. Removal would not definitely delay finalization. It's my bed time now perhaps I'm skimming your mail too fast (in that case I apology and will read more carefully tomorrow) but why are fds still needed by 170? terminal? is moved out. IF fd->*port are combined with open-file then there's no where else fd is used. Or I'm reading the wrong version. -- Duy