Hi all,

Marc makes an excellent point about potential sandbox escape via
undefined (or implementation-defined) behavior, but
I'd like to point out another escape route: syntax transformers.

If the R7RS implementation uses an expander similar to
the Chez syntax-case expander, then it is possible to
construct syntax objects without direct access to the
syntax or quasisyntax reader macros. (In that particular
implementation, syntax objects were simply vectors with
a sigil in the first vector slot.) If the implementation
does hygienic renaming as part of expansion, then it would
be relatively straightforward to write an unhygienic macro
that was able to access bindings outside the explicit binding
environment that was passed to 'eval'.

Consequently, a "safe" subset of R7RS must restrict the
implementations of define-syntax, letrec-syntax, etc. to
only accept hygienic syntax transformers. I think some
implementations may have trouble guaranteeing this restriction
in practice.

I also think it might be worth reconsidering the use of the
words "safer" in the title of this SRFI. It's not clear
what "safer" means in this context: what security guarantees
are we actually trying to achieve here? Maybe "sandboxed eval"
would be a better name. But it would still be helpful to iron
out what the threat model is supposed to be here (are side-channel
exploits in scope here? How about local DoS? etc.)

Cheers,
Phil