Email list hosting service & mailing list manager

More advocacy for "port-real-fd" hga@xxxxxx (07 Sep 2020 15:52 UTC)
Re: More advocacy for "port-real-fd" Shiro Kawai (07 Sep 2020 20:29 UTC)
Re: More advocacy for "port-real-fd" Lassi Kortela (10 Sep 2020 16:21 UTC)
Re: More advocacy for "port-real-fd" Lassi Kortela (10 Sep 2020 16:29 UTC)
Re: More advocacy for "port-real-fd" Marc Nieper-Wißkirchen (10 Sep 2020 16:30 UTC)
Re: More advocacy for "port-real-fd" Lassi Kortela (10 Sep 2020 16:35 UTC)
Re: More advocacy for "port-real-fd" hga@xxxxxx (10 Sep 2020 16:49 UTC)

Re: More advocacy for "port-real-fd" Lassi Kortela 10 Sep 2020 16:35 UTC

> There is no well-defined bijection between ports and fds, is there?

String ports will probably never be implemented using fd's.

Common Lisp has two-way streams which could have two file descriptors I
think. However, a two-way stream is made by combining two normal streams
and you can retrieve the component streams later. So a port-fd procedure
could be used on those. Maybe port-fd should return #f for a stream with
more than one file descriptor.

> Is an implementation compliant if it just returns #f whenever
> port-internal-fd is invoked?

Good question. The spec isn't fully clear on this.

> To me, it looks like a leak of a low-level implementation detail when
> viewed from the scope of this SRFI.
>
> If bare fds will be needed in the future, doesn't it make sense to put
> them in their own SRFI?

It may make sense. We've lately been getting good results by leaving out
the parts of SRFIs that we don't fully understand, though it can be
disappointing to throw away or indefinitely postpone one's work.