Email list hosting service & mailing list manager

(Previous discussion continued)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 15:55 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 15:59 UTC)
open-file and fd->*port Lassi Kortela (10 Sep 2020 16:05 UTC)
Re: open-file and fd->*port Duy Nguyen (10 Sep 2020 16:15 UTC)
Re: open-file and fd->*port Shiro Kawai (10 Sep 2020 17:33 UTC)
Re: open-file and fd->*port Duy Nguyen (10 Sep 2020 17:40 UTC)
Re: open-file and fd->*port John Cowan (10 Sep 2020 18:18 UTC)
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:33 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:08 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:34 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:50 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (10 Sep 2020 18:10 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 18:48 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:01 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:07 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:57 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:19 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (11 Sep 2020 14:03 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:31 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:49 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:30 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 14:47 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:50 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 20:28 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:17 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 20:38 UTC)
Re: Language interop John Cowan (11 Sep 2020 20:50 UTC)
Re: Language interop hga@xxxxxx (11 Sep 2020 18:30 UTC)
Re: Language interop John Cowan (11 Sep 2020 19:45 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:34 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

Will address the other issues and previous emails later if needed, for
John is vetoing a new SRFI, and I don't disagree, scoping of what's in
SRFI 170 is in his remit, and there's a lot to be said for keeping the
fd stuff in it, for example see below:

> From: Duy Nguyen <xxxxxx@gmail.com>
> Date: Thursday, September 10, 2020 12:50 PM
>
> On Fri, Sep 11, 2020 at 12:36 AM <xxxxxx@ancell-ent.com> wrote:
>
> [...]
>
>> As mentioned above, keep the now fully admitted hack of
>> port-terminal-fd in SRFI 170, because it's easy/trivial, is
>> needed by 170 and we don't want to indefinitely further delay
>> 170's finalization.
>
> Easy and trivial does not make a good design. Removal would not
> definitely delay finalization.
>
> It's my bed time now perhaps I'm skimming your mail too fast (in that
> case I apology and will read more carefully tomorrow) but why are fds
> still needed by 170? terminal? is moved out. IF fd->*port are combined
> with open-file then there's no where else fd is used. Or I'm reading
> the wrong version.

And I your's, since I've finished my first and only all but guaranteed
high productivity part of the day.

port-terminal-fd is needed to avoid duplication of implementation code
in future SRFIs.  Under the table, mapping from a port to a fd is
required for SRFI 170 truncate-file and file-info, it's required in
SRFI 205, it would most likely be required in the posited but
currently vetoed New, Improved ports and fds, "expert" or not SRFI(s).

Nailing it down in the earliest SRFI makes implementation for all of
these much more sane.  And provides a clear path to finalization SRFI
170 ASAP, with or without the ports/fd APIs, and terminal?

And given John's current path, keeping terminal? in SRFI 170 is I
think a good idea, again because it's also trivial given
port-internal-fd.

Whereas for example SRFI 205 will be somewhat complex, and aside from
the new grab bag scsh procedures, is currently for a couple of special
use cases, serial port I/O for e.g. embedded programming, and safe use
of raw etc. mode. for terminals including a posited future Terminal
User Interface (TUI) SRFI.

And the reason these two are packaged together is again
implementation, they use the same stty mechanism under the table.
Which we've decided we won't expose in its full glory, much is now
obsolete, we do not plan to support retro-computing, e.g. a Scheme
program that simulates an old machine down to real serial lines.

- Harold