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? Duy Nguyen 10 Sep 2020 16:42 UTC

On Thu, Sep 10, 2020 at 11:29 PM <xxxxxx@ancell-ent.com> wrote:
>
> > From: Duy Nguyen <xxxxxx@gmail.com>
> > Date: Thursday, September 10, 2020 10:48 AM
> >
> > Besides the procedures to "create" and close file descriptors, they
> > are only needed to make a port. Why not combine open-file and
> > fd->*port in one? All other procedures either take pathname or a port.
>
> Because we want to allow users to be able to write C code to do other
> things to file descriptors we haven't anticipated?  Of course, per
> the below I should come up with some concrete examples, but that's
> already happened with the change to terminal? you inspired.

If you can write C code, you can already call open() or close()
yourself. This is what I meant by FFI in response to Lassi. This is a
portable SRFI, why do we cater to FFI which is very likely
implementation specific and has to deal with implementation quirks
anyway?

> > but we could wait until then to introduce necessary procedures to
> > either extract/dup fd from a port, or open an fd without going
> > through ports. Adding back later is easier than removing or changing
> > existing behavior.
> >
> > That removes port-internal-fd, which looks like a hack to me. And also
> > remove (for now) the risk of accidentally closing an fd that belongs
> > to some port.
>
> While I won't disagree that it looks like a hack, before making such
> a big change to the API I'd like something stronger, e.g. some concrete
> examples, than your I grant legitimate intuition (we're all experienced
> enough the "my initiation says" argument is good for red flagging etc.)

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.

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. For the
terminal srfi, we could very well make it a port. Process management
could specify a list of file descriptors you want to spawn a new
process with, and these file descriptors could take ports. I see the
possibility that we may not really need file descriptors.

> I'll repeat the strongest argument I know for the fd->*port functions:
> they aren't really "POSIX", rather they get into the guts of a Scheme
> implementation's port implementation, which I gather tends to be
> complicated.  *IF* you can turn an arbitrary fd into a port, with the
> various buffering options, you can do a whole lot stuff we haven't
> explicitly anticipated.  For the reverse, see how port-internal-fd
> simplified the implementation of terminal?

How is it more complicated or unexpected than calling (fd->*port
(open-file ..) ..)?

> Ah, here's my firm "NO!" to your request, unless all these procedures
> are moved from the SRFI, as we for example did with everything having
> to do with other processes: what you suggest requires all the hard
> work of integrating the SRFI with the Scheme implementation's port
> implementation, while hiding the resulting file descriptor needed by
> so many POSIX APIs and future SRFIs.  That work would have to be
> copied under the hood for the latter.

I don't see how it has to be copied. Doesn't code reuse exist? And
please note that we could introduce fd-based API _then_, when we see
the need. I'm not saying file descriptors can never enter Scheme
world.
--
Duy