Am Fr., 2. Okt. 2020 um 22:18 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Thu, Oct 1, 2020 at 8:32 PM <xxxxxx@ancell-ent.com> 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.