Email list hosting service & mailing list manager

Re: Evaluating definitions Marc Nieper-Wißkirchen (21 Oct 2019 06:37 UTC)
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
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: Evaluating definitions Marc Nieper-Wißkirchen 21 Oct 2019 06:37 UTC

Am Mo., 21. Okt. 2019 um 00:12 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
> You're quite right, but the right fix is to remove define, define-record, and define-values; expressions only.  Done and PRed.

This also removes internal definitions. While internal definitions can
be rewritten into letrec* (it's not quite true for `define-values'),
record-type definitions cannot be substituted.

Thus, the power of generative record(-types) is lost for code being
run under SRFI 172 and such code (even if purely functional) may have
to be refactored because it makes use of internal defines.

I'd propose instead that SRFI 172 offers a third library, say `(srfi
172 eval)', that exports a single procedure, namely `safe-eval', which
has the same interface as `eval'. A quick-and-dirty definition could
be:

(define (safe-eval expr env) (eval `(let () ,expr) env)

`safe-eval' requires that either `(srfi 172)' or `(srfi 172
functional)' is in the environment `env' because it needs the binding
of `let' to be present.

The nice thing about a procedure like `safe-eval' is that it can serve
as a hook for a native implementation of SRFI 172, with more safety
precaution. For example, a particular native implementation could
restrict the stack or heap space for code being run under `safe-eval'
(cf. https://www.gnu.org/software/guile/manual/html_node/Sandboxed-Evaluation.html).

--

Marc

>
> On Mon, Sep 2, 2019 at 3:38 AM Lassi Kortela <xxxxxx@lassi.io> wrote:
>>
>> It might be worth clarifying what happens with:
>>
>> (eval '(define foo 1) (environment '(srfi 172)))
>>
>> The SRFI says that it specifies an "*immutable* global environment
>> containing only specified libraries" which hints that trying to define
>> anything in that environment is an error. (From the R7RS definition of
>> eval: "If <expr-or-def> [...] is a definition, the specified
>> identifier(s) are defined in the specified environment, provided the
>> environment is *not immutable*." It'd be good to state this explicitly.