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).

I haven't taken a deeper look at C++17's filesystem API, but it
provides some abstraction on top of the usual hierarchical file
systems that may include a number of good ideas.
(https://en.cppreference.com/w/cpp/filesystem)

> > 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.

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.

Marc