On Fri, Sep 11, 2020 at 12:21 AM Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> > 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.

I'm only familiar with Gauche (and lately how Chibi handles ports).
They manage just that. The problem is the way they do is not the same.

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

You start with "simple" here, then you move on to describing fd
operations dangerous (perhaps in a sibling email) and "expert level"
just below. Those  don't mix.

Personally I think if you stay with ports, as a Scheme user, it will
be simpler. Implementations may get complicated, but fd management is
complicated in Scheme anyway because of the underlying fd<->ports
relation, at least on POSIXy systems.

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

If there is a demand, then perhaps we can have an "expert SRFI". I see
most of SRFI 170 procedures as an extension of (scheme file) which
should not introduce more concepts than necessary.

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

You most often can access native handles. It's provided by (I'm
leaving the analogy at this point) each Scheme implementation.
_Standardizing_ a way to let you shoot in the foot seems a step too
far.
--
Duy