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