MzScheme's namespaces (http://download.plt-scheme.org/doc/mzscheme/mzscheme-Z-H-8.h...) may help you with this, since you can have a separate namespace for each "sandbox", and the variables won't collide.

I guess you could also do this with a macro that replaces all the symbols by gensyms, so inside no-side-effects, foo is really a unique variable. But that seems like a pain to implement.

This seems like such a simple request - I can express it in a few sentences - that it should be at least not extremely difficult to implement in the ideal programming language. So I hope it can be done in Arc, and if not, hopefully this is a use case that can be taken into account while figuring out how to handle arc modules/namespaces/whatever.

Anyways. I thought about replacing symbols by gensyms, but at what point would I do that? If I just check all symbols in the code I will miss things like

(eval `(= ,(sym "foo") 2))

Awesome. I want to time travel. That's just one sentence. :)

"it should be at least not extremely difficult to implement in the ideal programming language"

Cue the asbestos! No one said Arc was intended to be some abstract ideal satisfying all few-sentence specifications, and as per the Java crack, who says that the ideal language is idiot-proof or attack-proof? To the contrary, the Design Imperatives I have seen trust the programmer to be good and are not hoping to be able to run virus attacks imperviously.

I don't want to make the language idiot-proof. I acknowledge this is a hard, rather "meta" thing and I was hoping Arc would be powerful enough to do this.

So, regardless of whether "the ideal language would have it", you agree this would be very useful; it would let us have an Arc plug-in for browsers for example. Or make a site where you could make your own Arc site by entering code and the main servers would run it restrictedly. Arc is trying to be native to the web, and allowing restricted execution is a very webby thing to do.

OK, asbestos did not work, try the foam!

What you might be missing is that power makes attacks easier, not harder. As I suggested, part of that power is reflection so you have a fighting chance, my concern is that once you have blocked all the exits there will be no way to get in. Whatever that means.

"you agree this would be very useful"

I do? Wow. Actually, I do not know much about security,tho I might have to learn soon. My guess is that probably the best way to go is not to cripple the plugin, rather to allow only registered, vetted, digitally signed code to run. ie, the plugin looks for a digital certificate before launching.

Well, we have JavaScript, and it is not really safer by design than Lisp (they are quite close, too). But JavaScript has a security manager, quite restrictive sometimes. And look at rebol : that's also a close relative to Lisp and it's got a cool security manager.

Well, they mainly prevent you from reading/writing the host filesystem or from connecting to undesired remote servers.

  http://bc.tech.coop/blog/030920.html

1. Write mock versions of all the Arc primitives that are dangerous.

2. Write a function that calls macex on an expression and then scans it for all instances of (set <symbol> ...).

3. Write a macro that takes an expression or a file, and wraps the whole thing in a with form that locally defines/shadows all the mock functions and the symbols detected with the above function.

4. Create a mock version of eval that wraps its argument in the above macro. This should obviously be shadowed in the macro too.

There are still some parts that are stumping me. It seems like I need to either (a) mock annotate to use a different mechanism, or (b) prevent the code from annotating pre-existing variables. The same goes for accessing sig.

It seems like the most plausible way to keep scar/scdr/sref from mutating variables outside the no-side-effects scope is to keep a table of the variables they are allowed to operate on, which is basically anything the user created with cons or table inside the no-side-effects scope. This should invalidate code like

(= a (table))

(no-side-effects (= b a) (= (b "key") "value"))

Assuming

  (= a (table 'foo 'bar))

  (no-side-effects (= a!foo 'baz) a)

  (let a (copy a)
    (= a!foo 'baz)
    a)

You would still have to think about constructs like def and mac, but at least this deals with shared structure of lists and tables.

  arc> (= a 3)
  3
  arc> (= b 5)
  5
  arc> (let a (+ a 4)
         (+ a b))
  12
  arc> (with (a 2 b (+ b 2))
         (+ a b))
  9
  arc> (with (a 6 b 2)
         (prn a) (prn b)
         (= b a) (= a 'foo)
         (prn a) b)
  6
  2
  'foo
  6
  arc> a
  3
  arc> b
  5

I don't know a priori what variables this code will try to access. I could possibly figure that out with a macro, but some of the details are still unclear to me. I also don't want side effects if annotate, def, mac, or anything like that was run from the no-side-effect'd code.

At any rate, I think just wrapping in a let is insufficient, even if you do know all the variable names. E.g. you can break out of the sandbox with scdr:

> (= a '(1 2))

(1 2)

> (let a a (scdr a '(3)))

(3)

> a

  (mac w/nondestructive (names . body)
    (if (acons names)
        (cons `(fn ,names ,@body)
              (map [list 'deepcopy _] names))
        `(let ,names (deepcopy ,names) ,@body)))