Re: Redesign of 3.2 to eliminate file descriptor objects Marc Nieper-WiÃkirchen 02 Oct 2020 20:39 UTC
Am Fr., 2. Okt. 2020 um 22:18 Uhr schrieb John Cowan <email@example.com>: > > > > On Thu, Oct 1, 2020 at 8:32 PM <firstname.lastname@example.org> wrote: > >> >> Not at all sure about terminal?, I don't remember that discussion, or at least I don't remember it coming to that conclusion, rather the opposite, for the very last thing I did to my Chibi Scheme sample implementation was adding fd back to it.... To repeat the "it's no big deal" implementation point, POSIX isatty() call takes a file descriptor, so if you're handed an exact integer you just don't call the magic procedure that extracts a fd from a port, it's like one extra line of code. But I suppose to justify this a use case is needed, I'll first review the discussion. > > > It's true that it's no big deal as an implementation feature. But I don't think it makes much *sense* any more. > > When you start up, if (current-input) and/or (current-output) are bound to the terminal, you do terminal-specific things like columnar output from `ls`, or displaying a progress bar, or starting up in TUI mode rather than CLI mode. So (terminal? (current-output)) will work and is a lot clearer than (terminal? 1). If your program takes an explicit (non-redirected) file argument, you open it (which always gives you a port now, either using the R7RS-small procedures or using open-file) and then ask if it's a terminal before doing input or output on it. I can see no remaining use cases for passing a fd, because there are very few use cases for *having* a fd. As ports are disjoint from exact integers, an implementation is always free to extend `terminal?` to accept fds without violating SRFI 170. I am very much in favor of John's change but that should come as no surprise because I think that file descriptors should be removed from SRFI 170 altogether. The only procedures that remain that deal with fds are fd->port and with-port-fd. It could make sense to move them into a separate lower-level SRFI. Especially `with-port-fd' is fragile and shouldn't be exposed to the user. If a non-continuable exception is raised, while `proc' is executing, one has to have a caught continuation ready to be able to jump back into `proc' in order to leave `proc' normally so that the fd is given back to the OS. There is no way to sensibly use `with-port-fd' just with SRFI 170 anyway. `fd->port' has use cases but would be the only one fd-related procedure left.