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

> To me it's actually lack of real fd usage (and as I said, I don't
> consider fd obtained from a specific implementation). So if we can
> obtain fd from one of the existing SRFIs, or from r7rs, then we need
> procedures to work with them.

Yes.

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

> For the terminal srfi, we could very well make it a port.

That's probably a good idea to make it easier to cover Windows and other
non-Unix OSes. Also to deal with buffering and setting/restoring modes
and other stuff.

> Process management
> could specify a list of file descriptors you want to spawn a new
> process with,

Yes, this is The Right Thing IMHO. As long as we also accept
stdin/stdout/stderr symbols as aliases for 0/1/2 and whatever equivalent
constants they use on Windows.

> and these file descriptors could take ports.

Probably reasonable to have a port as one alternative.

> I see the
> possibility that we may not really need file descriptors.

I wouldn't bet on that side.

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.