SRFI 181: Custom ports Arthur A. Gleckler (16 Feb 2020 08:03 UTC)
Re: SRFI 181: Custom ports Lassi Kortela (16 Feb 2020 14:01 UTC)
Re: SRFI 181: Custom ports Lassi Kortela (21 Feb 2020 23:24 UTC)
Re: SRFI 181: Custom ports John Cowan (22 Feb 2020 19:19 UTC)
Re: SRFI 181: Custom ports Vincent Manis (17 Feb 2020 23:04 UTC)
Re: SRFI 181: Custom ports John Cowan (18 Feb 2020 17:51 UTC)
Re: SRFI 181: Custom ports Arthur A. Gleckler (18 Feb 2020 18:22 UTC)
Re: SRFI 181: Custom ports John Cowan (19 Feb 2020 12:42 UTC)
Re: SRFI 181: Custom ports Arthur A. Gleckler (19 Feb 2020 18:11 UTC)
Re: SRFI 181: Custom ports Lassi Kortela (19 Feb 2020 18:13 UTC)
Re: SRFI 181: Custom ports Arthur A. Gleckler (19 Feb 2020 18:17 UTC)
Re: SRFI 181: Custom ports Lassi Kortela (19 Feb 2020 18:30 UTC)
Re: SRFI 181: Custom ports Arthur A. Gleckler (19 Feb 2020 18:51 UTC)
Re: SRFI 181: Custom ports Vincent Manis (19 Feb 2020 22:57 UTC)
Re: SRFI 181: Custom ports Jim Rees (04 Mar 2020 12:36 UTC)
u8-ready? and char-ready? Lassi Kortela (04 Mar 2020 12:46 UTC)
Re: u8-ready? and char-ready? Jim Rees (04 Mar 2020 13:09 UTC)
Re: u8-ready? and char-ready? Lassi Kortela (04 Mar 2020 13:30 UTC)
Re: u8-ready? and char-ready? Jim Rees (04 Mar 2020 14:48 UTC)
Re: u8-ready? and char-ready? Marc Feeley (04 Mar 2020 15:07 UTC)
Re: u8-ready? and char-ready? Lassi Kortela (04 Mar 2020 15:13 UTC)
Re: u8-ready? and char-ready? Marc Feeley (04 Mar 2020 15:31 UTC)
Re: u8-ready? and char-ready? Marc Nieper-Wißkirchen (04 Mar 2020 15:39 UTC)
Re: u8-ready? and char-ready? Marc Feeley (04 Mar 2020 15:49 UTC)
SRFI 18 implementation status - R5RS/R7RS Schemes Lassi Kortela (04 Mar 2020 16:08 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Lassi Kortela (04 Mar 2020 16:13 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Marc Feeley (04 Mar 2020 16:18 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Lassi Kortela (04 Mar 2020 16:26 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Lassi Kortela (04 Mar 2020 16:28 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Marc Feeley (04 Mar 2020 16:46 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Lassi Kortela (04 Mar 2020 17:03 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes John Cowan (04 Mar 2020 23:23 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Marc Feeley (05 Mar 2020 13:08 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes John Cowan (05 Mar 2020 20:44 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Göran Weinholt (05 Mar 2020 22:16 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes John Cowan (05 Mar 2020 22:22 UTC)
Re: SRFI 18 implementation status - R5RS/R7RS Schemes Arthur A. Gleckler (04 Mar 2020 19:26 UTC)
Re: u8-ready? and char-ready? Lassi Kortela (04 Mar 2020 15:07 UTC)
Re: u8-ready? and char-ready? Marc Feeley (04 Mar 2020 15:31 UTC)
Re: u8-ready? and char-ready? Jim Rees (04 Mar 2020 15:32 UTC)
Waiting on custom ports / CL Gray Streams Lassi Kortela (04 Mar 2020 15:41 UTC)
Re: u8-ready? and char-ready? John Cowan (04 Mar 2020 17:18 UTC)
Re: u8-ready? and char-ready? Lassi Kortela (04 Mar 2020 17:26 UTC)
Re: u8-ready? and char-ready? Marc Feeley (04 Mar 2020 14:55 UTC)
Re: SRFI 181: Custom ports Jim Rees (04 Mar 2020 19:31 UTC)
Re: SRFI 181: Custom ports John Cowan (05 Mar 2020 00:36 UTC)
Re: SRFI 181: Custom ports Jim Rees (05 Mar 2020 21:53 UTC)
Re: SRFI 181: Custom ports John Cowan (05 Mar 2020 22:08 UTC)

Re: u8-ready? and char-ready? Lassi Kortela 04 Mar 2020 15:07 UTC

> I'm not disagreeing with you here, but your argument is about the
> utility of u8-ready? char-ready? themselves.
>
> Of course, if I'm writing a large program talking to character devices,
> network pipes, and files all at once, I will use an infrastructure
> better suited for polling many channels at once.   And I admit that
> while I have faithfully implemented {u8,char}-ready? in my own
> implementation and tested them, I have written no programs that make
> effective use of them.
>
> If we are to honor R7RS, with u8-ready? and char-ready?  I think we are
> obligated to support their implementation in custom ports as well,
> otherwise, we are declaring those procedures deprecated and useless
> (which /may/ be a valid decision).

Deprecating them may be a valid decision. IMHO, the `port-ready?`
procedures in various programming languages are generally a design
mistake. Often they seem to have put in to serve a particular use case
(waiting for a terminal keystroke, or lookahead in parsers) but are
problematic as general-purpose abstractions.

The language should probably have one central (wait ...) procedure that
waits for one or more things of assorted kinds. That facility could be
extensible somehow to cover user-defined port or data types. It would be
quite complex to specify, and a reliable specification might have to
depend on environmental factors like OS threads vs green threads vs
single-threaded, implementation of continuations, etc. Marc has a ton of
pertinent experience, whereas I shouldn't be allowed to touch a spec on
the topic :)