Re: Remove file descriptors completely from srfi-170? hga@xxxxxx 10 Sep 2020 18:40 UTC
Will address the other issues and previous emails later if needed, for John is vetoing a new SRFI, and I don't disagree, scoping of what's in SRFI 170 is in his remit, and there's a lot to be said for keeping the fd stuff in it, for example see below: > From: Duy Nguyen <xxxxxx@gmail.com> > Date: Thursday, September 10, 2020 12:50 PM > > On Fri, Sep 11, 2020 at 12:36 AM <xxxxxx@ancell-ent.com> wrote: > > [...] > >> 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. And I your's, since I've finished my first and only all but guaranteed high productivity part of the day. port-terminal-fd is needed to avoid duplication of implementation code in future SRFIs. Under the table, mapping from a port to a fd is required for SRFI 170 truncate-file and file-info, it's required in SRFI 205, it would most likely be required in the posited but currently vetoed New, Improved ports and fds, "expert" or not SRFI(s). Nailing it down in the earliest SRFI makes implementation for all of these much more sane. And provides a clear path to finalization SRFI 170 ASAP, with or without the ports/fd APIs, and terminal? And given John's current path, keeping terminal? in SRFI 170 is I think a good idea, again because it's also trivial given port-internal-fd. Whereas for example SRFI 205 will be somewhat complex, and aside from the new grab bag scsh procedures, is currently for a couple of special use cases, serial port I/O for e.g. embedded programming, and safe use of raw etc. mode. for terminals including a posited future Terminal User Interface (TUI) SRFI. And the reason these two are packaged together is again implementation, they use the same stty mechanism under the table. Which we've decided we won't expose in its full glory, much is now obsolete, we do not plan to support retro-computing, e.g. a Scheme program that simulates an old machine down to real serial lines. - Harold