Depending on the implementation of the underlying syntax system, {er,ir,sc,rsc}-macro transformers may still be available. For example, Chibi has always allowed bare lambdas as macro transformers and, say, sc-macro-transformer, is implemented as a procedure returning a base lambda.
If so, I think that's rather unfortunate. I know it is true of syntax-case, and it's one of my many complaints about that system of macros: it is imperialistic and doesn't tolerate the presence of other macro systems that are not (as syntax-rules is) defined in terms of it.
In what sense does syntax-case not tolerate other macro systems? It would only be incompatible with macro systems that also allow bare procedures as macro transformers. Chibi Scheme is the perfect example that the perceived intolerance of syntax-case is not factual. In Chibi, syntax-case and {er,sc,rsc}-macro transformers coexist peacefully.
Anyhow, this is not critical for this discussion about SRFI 172.
But what is the purpose of this SRFI? If the purpose is to be able to eval untrusted code in a sandbox, then it is just dangerous to offer an implementation that is, most likely, not safe on most Schemes. In this context, "safer" still means "unsafe".
In every context without an explicit comparand, "safer" means "still unsafe". Using condoms and other barriers does not reduce the probability of getting a sexually transmitted infection to 0, it only lowers it. That's precisely why the term "safe sex" was replaced by "safer sex", meaning that it lowers the probability, but not to 0. Only abstinence from sex altogether can do that. Siimlarly, I have said in other contexts that the only way to secure a computer is to cut the power and then throw the computer down a deep well, and it's even better if you fill the well with concrete afterwards.
I usually view "eval" as Scheme's built-in JIT-compilation facility. As much as one would never directly run untrusted code on the CPU,
Well, untrusted by whom and for what? Gcc is certainly not verified correct (and verified-correct programs often have bugs due to errors in the specification), yet as a human matter I trust it not to mung my computer and in fact to compile my C programs correctly, if somewha nastily.
"You trust beyond reason." "It's how I get results beyond hope."
I would also repeat that most Lisps don't implement `eval` with a machine-language compiler, AOT or JIT. SBCL, IronScheme, and Kawa do, but I can't think of others offhand. Indeed, I once started on packaging Chibi as a Chicken egg because Chicken's `eval` interpreter (the same used in csi) was too slow for my purposes, but I was daunted by the task and gave up. Of course, a lot of marshaling and unmarshaling code is required to translate between Chicken and Chibi implementations of numbers, strings, etc. Still, the sandboxing is absolute in that situation: Chibi can't alter the Chiicken program hosting it, modulo bugs, except via the (atomic) arguments it is passed.
For another example, Chez Scheme does compile every expression before it evaluates it. In some sense, Chibi does as well (in its bytecode, but this is much faster than a meta-circular implementation of `eval').
What I think what could be helpful is to make sure that there are enough primitves/guarantees that it is in fact possible to compile an arbitrary program into a safe expression.
It will never be completely safe: see above.
(It is immaterial whether the environment, in which this expression is evaluated, is restricted or not because it is the expression, which actually has to be restricted.)
The environment is also crucial, otherwise there is no guarantee that (car x) actually returns the car of x without side effects. If we had mutable environments (and I have a pre-SRFI for them), we could start with a fully empty environment and build it up, but we don't currently.
Sure, the code that has been compiled into a trusted subset needs some guarantees about the environment, in which it is run. What I wanted to say is that it wouldn't be harmful if the environment contained further bindings in addition to that.
-- Marc