Email list hosting service & mailing list manager

(Previous discussion continued)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 15:55 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 15:59 UTC)
open-file and fd->*port Lassi Kortela (10 Sep 2020 16:05 UTC)
Re: open-file and fd->*port Duy Nguyen (10 Sep 2020 16:15 UTC)
Re: open-file and fd->*port Shiro Kawai (10 Sep 2020 17:33 UTC)
Re: open-file and fd->*port Duy Nguyen (10 Sep 2020 17:40 UTC)
Re: open-file and fd->*port John Cowan (10 Sep 2020 18:18 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 16:29 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 16:33 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 16:42 UTC)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 16:57 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 17:08 UTC)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 17:21 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 17:34 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 17:37 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 17:36 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 17:50 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (10 Sep 2020 18:10 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 18:40 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 18:48 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (10 Sep 2020 18:52 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 19:01 UTC)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 19:12 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 19:07 UTC)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 19:16 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 19:23 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 19:28 UTC)
Re: Remove file descriptors completely from srfi-170? Shiro Kawai (10 Sep 2020 19:57 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 20:02 UTC)
Re: Remove file descriptors completely from srfi-170? Shiro Kawai (10 Sep 2020 20:13 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (10 Sep 2020 20:19 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 20:49 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (11 Sep 2020 13:19 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (11 Sep 2020 14:03 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (11 Sep 2020 14:56 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (11 Sep 2020 15:31 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (10 Sep 2020 20:18 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (11 Sep 2020 13:49 UTC)
R7RS scope & yearly editions Lassi Kortela (11 Sep 2020 14:10 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 14:22 UTC)
Re: R7RS scope & yearly editions Lassi Kortela (11 Sep 2020 14:26 UTC)
Re: R7RS scope & yearly editions hga@xxxxxx (11 Sep 2020 14:30 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 14:47 UTC)
Re: R7RS scope & yearly editions & language interop Lassi Kortela (11 Sep 2020 15:20 UTC)
Re: R7RS scope & yearly editions & language interop Marc Nieper-Wißkirchen (11 Sep 2020 15:28 UTC)
Re: R7RS scope & yearly editions & language interop John Cowan (11 Sep 2020 17:11 UTC)
Language interop Lassi Kortela (11 Sep 2020 17:55 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 18:04 UTC)
Re: Language interop Lassi Kortela (11 Sep 2020 18:14 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 18:28 UTC)
Re: Language interop hga@xxxxxx (11 Sep 2020 18:50 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 20:28 UTC)
Re: Language interop hga@xxxxxx (11 Sep 2020 21:00 UTC)
Re: Language interop Marc Nieper-Wißkirchen (12 Sep 2020 07:26 UTC)
Re: Language interop Lassi Kortela (11 Sep 2020 19:17 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 20:38 UTC)
Re: Language interop John Cowan (11 Sep 2020 20:50 UTC)
Re: Language interop hga@xxxxxx (11 Sep 2020 18:30 UTC)
Re: Language interop John Cowan (11 Sep 2020 19:45 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 20:15 UTC)
Re: Language interop John Cowan (11 Sep 2020 19:42 UTC)
Re: R7RS scope & yearly editions hga@xxxxxx (11 Sep 2020 15:34 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 15:56 UTC)
Interlisp and structural code editing Lassi Kortela (11 Sep 2020 17:45 UTC)
Re: Interlisp and structural code editing John Cowan (11 Sep 2020 20:16 UTC)
Re: R7RS scope & yearly editions John Cowan (11 Sep 2020 16:57 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 17:23 UTC)
Re: R7RS scope & yearly editions John Cowan (11 Sep 2020 20:31 UTC)
Re: R7RS scope & yearly editions Arthur A. Gleckler (12 Sep 2020 17:39 UTC)
Re: R7RS scope & yearly editions John Cowan (11 Sep 2020 16:39 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 17:01 UTC)
Re: R7RS scope & yearly editions Lassi Kortela (11 Sep 2020 17:15 UTC)

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