On Thu, Sep 10, 2020 at 11:57 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> > If you can write C code, you can already call open() or close()
> > yourself.
>
> But those don't give you the fd of an existing port.
>
> Fd's are not really about FFI; fd's without FFI can still be useful:

Let's see. Say Scheme X provides access to file descriptors. There is
a chance that X already provides all the procedures that SRFI 170 does
(how else do you use those fds then). So if you stay on X, SRFI 170
does provide any value.

If you want to write portable programs, using an implementation
specific way to get fd is a non-starter. How fds are managed by each
implementation may be different, complicates the problem more if
you're leaning towards cond-expand. Writing such a program based on
SRFI 170 does not make it portable. Providing more SRFIs that cover
those use cases [1] does.

I fail to see the usefulness.

[1] hopefully without involving fd, but that's NOT a requirement

> > Otherwise, I did not say we will not need fds. We may. But perhaps we
> > could find a way to introduce POSIX interfaces without fds.
>
> Opening a port by default is not automatically a good thing. A port is a
> significantly more complex abstraction than a mere file descriptor. If
> you can get a job done using mere fd's without going through a port, the
> code may be faster, more reliable, and edge cases easier to understand.
>
> For example, I've never found that C code is difficult to write because
> of naked fd's. The myriad problems in C are caused by other things.

The opposite may be true in Scheme because ports feel "native" while
fds are actually a strange thing with edge cases (that led to the dup
thingy in srfi 170).

> > I see the possibility that we may not really need file descriptors.
>
> I wouldn't bet on that side.

I wouldn't bet on it either. I'm just delaying betting on it.

> There's a similar problem with GUI toolkits that don't expose the native
> window handle (e.g. HWND on Windows). There tends to be difficult stuff
> that cannot be anticipated in advance and cannot be done without getting
> at the native API.
>
> I'd always err on the side of having an escape hatch to get the native
> handle. What I'm not sure of is which SRFI the API belongs in.

And once you get an native FD you are likely tied to a specific
platform, losing portability that those GUI toolkits provide. You face
a shortcoming of the GUI toolkit. You bring it up to discuss a way
forward. Then you may get a new API that's guaranteed to work in a new
version, without going down to native API.
--
Duy