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

Right, I forgot that some Schemes do some magic to try to maintain 1:1
correspondence between open ports and fd's. IMHO that's an impossible
goal. The abstraction is going to be hugely complex and leak like a sieve.

It should be understood that any code turning ports into fd numbers or
vice versa is operating on an "I know what I'm doing, and if it breaks I
get to keep both pieces" basis.

Most of SRFI 170 is less treacherous than that, but it's already
low-level-ish in parts. For example, SRFI 170 uses the OS
current-directory instead of the Scheme thread's current-directory
parameter (against repeated cautions from a few of us, but maybe that
ship has sailed). Using the OS CWD in Scheme is low-level business.

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

Ports definitely feel native, but they are not at all simple. They are
one of the most complex abstractions in Scheme. How is buffering done?
Has the port been flushed? Is another port using the same underlying fd?
When will the port be garbage-collected, and what happens when it is?
Does the port have separate read and write ends, and are those closed
separately or at the same time?

In C, stdio FILE* handles feel comfortable to newbies, but experts feel
more comfortable with raw file descriptors. The latter make it easier to
answer questions like "what kind of buffering am I using?" and "how much
memory is this port taking".

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

Waiting for a new design of a library API is not practical when writing
applications. You solve the immediate problem in a way that works only
for your application and then move on.

Inability to access the native handle can result in things like having
to rewrite an entire GUI widget from scratch when the library provides a
widget that almost does what you want but you can't customize it since
you can't reach the handle. I imagine there are similar scenarios having
to do with file descriptors.