Email list hosting service & mailing list manager

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:34 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:09 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:35 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:51 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (10 Sep 2020 18:11 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 18:49 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:02 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:08 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:58 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:20 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (11 Sep 2020 14:04 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:32 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:50 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:31 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 14:48 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:51 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 20:29 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:18 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 20:38 UTC)
Re: Language interop John Cowan (11 Sep 2020 20:51 UTC)
Re: Language interop hga@xxxxxx (11 Sep 2020 18:30 UTC)
Re: Language interop John Cowan (11 Sep 2020 19:46 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:35 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? hga@xxxxxx (10 Sep 2020 18:40 UTC)

Re: Remove file descriptors completely from srfi-170? Lassi Kortela 10 Sep 2020 16:57 UTC

> If you can write C code, you can already call open() or close()
> yourself.

But those don't give you the fd of an existing port.

Fd's are not really about FFI; fd's without FFI can still be useful:

> To me it's actually lack of real fd usage (and as I said, I don't
> consider fd obtained from a specific implementation). So if we can
> obtain fd from one of the existing SRFIs, or from r7rs, then we need
> procedures to work with them.

Yes.

> Otherwise, I did not say we will not need fds. We may. But perhaps we
> could find a way to introduce POSIX interfaces without fds.

Opening a port by default is not automatically a good thing. A port is a
significantly more complex abstraction than a mere file descriptor. If
you can get a job done using mere fd's without going through a port, the
code may be faster, more reliable, and edge cases easier to understand.

For example, I've never found that C code is difficult to write because
of naked fd's. The myriad problems in C are caused by other things.

> For the terminal srfi, we could very well make it a port.

That's probably a good idea to make it easier to cover Windows and other
non-Unix OSes. Also to deal with buffering and setting/restoring modes
and other stuff.

> Process management
> could specify a list of file descriptors you want to spawn a new
> process with,

Yes, this is The Right Thing IMHO. As long as we also accept
stdin/stdout/stderr symbols as aliases for 0/1/2 and whatever equivalent
constants they use on Windows.

> and these file descriptors could take ports.

Probably reasonable to have a port as one alternative.

> I see the
> possibility that we may not really need file descriptors.

I wouldn't bet on that side.

There's a similar problem with GUI toolkits that don't expose the native
window handle (e.g. HWND on Windows). There tends to be difficult stuff
that cannot be anticipated in advance and cannot be done without getting
at the native API.

I'd always err on the side of having an escape hatch to get the native
handle. What I'm not sure of is which SRFI the API belongs in.