> 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
