The loss of internal definitions is indeed regrettable. But global definitions aren't going to work anyway, precisely because the result of (environment) is immutable: boh the bound identifiers and the values they are bound to are fixed. In general, code will need some modifications to be sandboxed in any case.

As you point out, internal `define` can be rewritten as `letrec*`. `Define-values` is messier, but still rewritable . There is indeed no replacement for internal `define-record-type`, but I am far from sure that adding new types is a Good Thing in sandboxed code. It is always possible to add identifiers needed for particular cases by supplementing the external call to `environment` with additional libraries or parts of them.

On Mon, Oct 21, 2019 at 2:37 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:

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.