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.