PS call-with-fd tries to achieve something which it cannot guarantee,
namely that the fd will be finally closed. So if such a procedure is
provided at all (which I wouldn't), it makes more sense to just call
it, say, "port-dup" and so that it just returns a duplicated fd.

In order to make sure that no resource is claimed forever, we should
rather standardize something like guardians for R7RS-large, which will
be a solution not only for fds to eventually collect resources.

Am Sa., 3. Okt. 2020 um 19:54 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:
>
> 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.