> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Thursday, September 10, 2020 11:35 AM
>
>> There is no well-defined bijection between ports and fds, is there?
>
> String ports will probably never be implemented using fd's.

Given that we're already concerned about our new paradigm of freely
using dup() causing a user to run out of fds, I think that's a pretty
safe statement....

> 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.

I've already felt a need for such, although stderr makes this less
simplifying than I'd like.

>> 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.

I don't see why it wouldn't be compliant.  Crippled, gratuitous
because this is the very simplest part of reaching into the guts of a
port implementation, but tolerable.

>> 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.

Heh, this won't be thrown away or indefinitely postponed; that was
the result for the very messy and hard to do safely separate processes
parts, but not for the terminal ones (SRFI 205).

For one thing, truncate-file and file-info passed the Pareto 80/20
culling test and take ports, thus requiring port-internal-fd.

- Harold