Email list hosting service & mailing list manager

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 17:26 UTC

> If I add non-trivial features to this SRFI, the set of available
> implementations drops from "all R6RS systems" to "none".  I am not eager
> for that to happen.

+1

> I will add flush as an optional argument to the
> make-custom-port procedures with a warning that it may not be called on
> all systems.

The most problematic functions in specs tend to follow this pattern :)

> I am considering adding the MIT Scheme feature of custom operations: a
> custom port is defined with an optional alist mapping operation names
> (arbitrary symbols) to procedures, and then there is a user-level
> (port-operation port name) that pulls procedures out of the alist.  But
> even that may not provide enough bang for the buck, as it has to be
> specified in such a way that it may return #f, just like flush.

Likewise. These effectively become optional features that look to the
user as if they are fully implemented everywhere (since they fail
silently if not). Please, let's take some more time to think about
whether this is a good idea.