Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 16:29 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 16:34 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 16:42 UTC)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 16:57 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 17:09 UTC)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 17:21 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 17:35 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 17:37 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 17:36 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 17:51 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (10 Sep 2020 18:11 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 18:49 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (10 Sep 2020 18:52 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 19:02 UTC)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 19:12 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 19:08 UTC)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 19:16 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 19:23 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 19:28 UTC)
Re: Remove file descriptors completely from srfi-170? Shiro Kawai (10 Sep 2020 19:58 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 20:02 UTC)
Re: Remove file descriptors completely from srfi-170? Shiro Kawai (10 Sep 2020 20:13 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (10 Sep 2020 20:19 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 20:49 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (11 Sep 2020 13:20 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (11 Sep 2020 14:04 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (11 Sep 2020 14:56 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (11 Sep 2020 15:32 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (10 Sep 2020 20:18 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (11 Sep 2020 13:50 UTC)
R7RS scope & yearly editions Lassi Kortela (11 Sep 2020 14:10 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 14:22 UTC)
Re: R7RS scope & yearly editions Lassi Kortela (11 Sep 2020 14:26 UTC)
Re: R7RS scope & yearly editions hga@xxxxxx (11 Sep 2020 14:31 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 14:48 UTC)
Re: R7RS scope & yearly editions & language interop Lassi Kortela (11 Sep 2020 15:20 UTC)
Re: R7RS scope & yearly editions & language interop Marc Nieper-Wißkirchen (11 Sep 2020 15:28 UTC)
Re: R7RS scope & yearly editions & language interop John Cowan (11 Sep 2020 17:11 UTC)
Language interop Lassi Kortela (11 Sep 2020 17:55 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 18:04 UTC)
Re: Language interop Lassi Kortela (11 Sep 2020 18:14 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 18:28 UTC)
Re: Language interop hga@xxxxxx (11 Sep 2020 18:51 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 20:29 UTC)
Re: Language interop hga@xxxxxx (11 Sep 2020 21:00 UTC)
Re: Language interop Marc Nieper-Wißkirchen (12 Sep 2020 07:26 UTC)
Re: Language interop Lassi Kortela (11 Sep 2020 19:18 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 20:38 UTC)
Re: Language interop John Cowan (11 Sep 2020 20:51 UTC)
Re: Language interop hga@xxxxxx (11 Sep 2020 18:30 UTC)
Re: Language interop John Cowan (11 Sep 2020 19:46 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 20:15 UTC)
Re: Language interop John Cowan (11 Sep 2020 19:42 UTC)
Re: R7RS scope & yearly editions hga@xxxxxx (11 Sep 2020 15:35 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 15:56 UTC)
Interlisp and structural code editing Lassi Kortela (11 Sep 2020 17:45 UTC)
Re: Interlisp and structural code editing John Cowan (11 Sep 2020 20:16 UTC)
Re: R7RS scope & yearly editions John Cowan (11 Sep 2020 16:57 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 17:23 UTC)
Re: R7RS scope & yearly editions John Cowan (11 Sep 2020 20:31 UTC)
Re: R7RS scope & yearly editions Arthur A. Gleckler (12 Sep 2020 17:39 UTC)
Re: R7RS scope & yearly editions John Cowan (11 Sep 2020 16:39 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 17:01 UTC)
Re: R7RS scope & yearly editions Lassi Kortela (11 Sep 2020 17:15 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 18:40 UTC)

Re: Remove file descriptors completely from srfi-170? Duy Nguyen 10 Sep 2020 17:34 UTC

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