Re: Redesign of 3.2 to eliminate file descriptor objects Marc Nieper-WiÃkirchen 03 Oct 2020 17:54 UTC
Am Sa., 3. Okt. 2020 um 19:26 Uhr schrieb John Cowan <firstname.lastname@example.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.