Last call for comments on SRFI 172: Two Safer Subsets of R7RS
Arthur A. Gleckler
(02 Sep 2019 04:28 UTC)
|
Re: Last call for comments on SRFI 172: Two Safer Subsets of R7RS
Lassi Kortela
(02 Sep 2019 07:37 UTC)
|
Evaluating definitions
Lassi Kortela
(02 Sep 2019 07:38 UTC)
|
Re: Evaluating definitions
John Cowan
(20 Oct 2019 22:11 UTC)
|
Re: Evaluating definitions
Marc Nieper-Wißkirchen
(21 Oct 2019 06:37 UTC)
|
Re: Evaluating definitions
John Cowan
(21 Oct 2019 16:51 UTC)
|
Re: Last call for comments on SRFI 172: Two Safer Subsets of R7RS
Marc Nieper-Wißkirchen
(02 Sep 2019 08:46 UTC)
|
Re: Last call for comments on SRFI 172: Two Safer Subsets of R7RS Lassi Kortela (02 Sep 2019 08:56 UTC)
|
Re: Last call for comments on SRFI 172: Two Safer Subsets of R7RS
Marc Nieper-Wißkirchen
(02 Sep 2019 09:09 UTC)
|
Re: Last call for comments on SRFI 172: Two Safer Subsets of R7RS Lassi Kortela 02 Sep 2019 08:56 UTC
> 2) If a Scheme system supports reader macros (e.g. Racket), the `read' > procedure should be considered unsafe; thus, it may be best to remove > it from (srfi 172) and (srfi 172 functional). Would it be possible to mandate that the SRFI 172 environment provide a version of `read` using standard syntax with no extensions? What about custom writers for user-defined data types? Common Lisp lets users specialize the `print-object` method for their own types; some Scheme probably has something similar, or will eventually. Is `read` useful in the environment? `write` probably is, but could we make do with just `write-char`, `write-string`, `write-u8` and `write-bytevector`? There's `number->string` and `symbol->string` for the most frequently needed conversions.