> From: "Marc Nieper-Wißkirchen" <xxxxxx@nieper-wisskirchen.de>
> Date: Friday, September 11, 2020 8:19 AM
>
> Am Do., 10. Sept. 2020 um 22:49 Uhr schrieb <xxxxxx@ancell-ent.com>:
>
>>> But if the Scheme implementation does not export any FDOs,
>>> port-internal-fd won't help.
>>
>> In that case, you should have \words/ with your SRFI 170 implementor,
>> as long as you're using a POSIX system where this should be literally
>> trivial.  Obviously if you're not on top of a POSIX system, like
>> you're using raw Windows, you can only expect a best effort, perhaps
>> including an imperfect or unimplemented post-internal-fd and/or
>> terminal?  That's build into the pie when an implementor attempts such
>> a mapping to system with alien paradigms (and it's not entirely bad
>> we don't live in a POSIX monoculture ... for an all too short period
>> in the mid-1990s, it was an absolute pleasure to us NT instead of
>> UNIX(TM)).
>
> I would love to see a higher-level abstraction of this SRFI before we
> talk about voting any of them into R7RS (large). For a language
> standard that should be appliable to general (hosted) systems, SRFI
> 170 looks too much tied to POSIX in some regards. And even on a POSIX
> system, a 1:1 mapping is hard to realize as the discussions have shown
> (threads are not 1:1, the errno is unreliable, the current umask and
> the current path can only be used with caveats).

Quibble, errno can be made reliable, you just have to do the work
"under the table" at the C level, for example always immediately save
a copy after making a POSIX call, then make it available to your error
handling code if in fact an error occurred.

> [ C++17's filesystem API ]
>
>>> I may have missed it earlier, but why doesn't terminal? also work on
>>> a port?
>>
>> Because it  duplicates code, including sanity checking, and SRFI
>> 170 is already enough of a monster as it is; we weren't exactly
>> enthusiastic in going through every procedure that could take a
>> port (fd) and cutting that for *every* one except truncate-file
>> and file-info.  And using simple procedures as building blocks is
>> the Lisp way, after all.
>
> One can argue that It goes the wrong way on the Lisp pathway. Because
> if one follows the direction you sketched, just a FFI to call C
> libraries would seem like an improvement to SRFI 170.

That might well make sense in addition to SRFI 170....

> The Scheme application programmer is interested in whether a Scheme
> port is a terminal or not. Whether the underlying OS layer realizes
> this with fds or whatever mechanism is an implementation detail. Of
> course, one can expose that detail, but not by leaving out the
> abstract interface that works on ports, please.

OK, you've sold me on this point.  terminal? should indeed take a port
or a FDO/fd, the small amount of extra work required for the implementor
is not enough to outweigh the burden on many application programmers, "A
moment of convenience, a lifetime of regret" (first as far as I know
said about TECO).

- Harold