Email list hosting service & mailing list manager

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 Marc Nieper-Wißkirchen (02 Sep 2019 09:09 UTC)

Re: Last call for comments on SRFI 172: Two Safer Subsets of R7RS Marc Nieper-Wißkirchen 02 Sep 2019 08:46 UTC

1) As R7RS implementations are allowed to extend the domain of the
R7RS procedures, which may make them unsafe in the sense of SRFI 172,
SRFI 172 should permit that the identifiers exported by (srfi 172) and
(srfi 172 functional) do not have the same bindings as the identifiers
exported by the standard libraries. Thus, an implementation of SRFI
172 would be allowed to export restricted procedures in (srfi 172) and
(srfi 172 functional).

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

3) In a Scheme system, in which immutable data is shared and which
doesn't protect against writing to immutable data structures (e.g.
string literals or strings returned by `symbol->string'), (srfi 172)
does not fulfill its promises.

Marc

Am Mo., 2. Sept. 2019 um 06:28 Uhr schrieb Arthur A. Gleckler
<xxxxxx@speechcode.com>:
>
> John Cowan, author of SRFI 172, Two
> Safer Subsets of R7RS, has asked me to
> announce "last call" for this SRFI.  He
> believes that it is ready for
> finalization, but would like to give
> reviewers one last chance to submit
> corrections and feedback before we
> finalize it.
>
>   <https://srfi.schemers.org/srfi-172>
>
> In particular, I appeal to anyone
> reading this to try the sample
> implementation, run the tests, and send
> feedback about your results.
>
> If you're interested in this SRFI,
> please give your feedback via the SRFI
> 172 mailing list before 2019/9/10.
> After that, assuming that no major
> revisions are required, we will declare
> it final.
>
> Regards,
>
>
> SRFI Editor