Am Sa., 3. Okt. 2020 um 19:26 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> The only procedures that remain that deal with
>> fds are fd->port and with-port-fd. It could make sense to move them
>> into a separate lower-level SRFI.
>
>
> fd->port is important because fds are part of the external interface of a program.  Normally we only say what use is made of ports 0 and 1, because they are always connected internally.

I understand its importance. If there won't be a SRFI dealing with the
low-level fds, I agree that it should stay in this SRFI.

>> Especially `with-port-fd' is fragile
>> and shouldn't be exposed to the user. If a non-continuable exception
>> is raised, while `proc' is executing, [...]
>
>
> That's quite true, and is a general problem with call/cc: it does not interoperate well with anything resembling try-finally or unwind-protect  The existing call-with-port procedure has exactly the same issues, as do its trivial derivatives call-with-*-file and with-*-from file.

call-with-port isn't at all that problematic because the port object
is known to the garbage collector, which will close the port when
there is no reference to it anymore.

> As an aid to recovery from such situations, I have added back close-fd.  I have also renamed with-port-fd to call-with-port-fd and pointed out the symmetry with call-with-port.

The symmetry seems only superficial.

>> There is
>> no way to sensibly use `with-port-fd' just with SRFI 170 anyway.
>
>
> That's true, and I am still open to getting rid of it altogether.  It is, however, a low-level building block for other SRFIs.

The latter s certainly true but that does not mean at all that it has
to be exposed to the user-visible API.

If we see a few other low-level SRFIs like 170, it may very well be
that they may have to communicate with each other behind the scenes
(meaning that their implementations cannot be totally independent),
but that's absolutely fine. With this low-level stuff, I firmly
believe that any goal to allow implementations to be independent up to
the user-visible API is a misguided one when it forces to expose
fragile things like `with-port-fd' to the user.