Re: Remove file descriptors completely from srfi-170? Marc Nieper-WiÃkirchen 11 Sep 2020 13:19 UTC
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