Last call for comments on SRFI 172: Two Safer Subsets of R7RS Arthur A. Gleckler (02 Sep 2019 04:28 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.