It should be possible to define a private namespace such that no external references to variables are possible, and no invocation of namespace-local procs are possible except via namespace exported names.
This would provide a nice degree of encapsulation, perhaps even a cheap and would be easy to implement.
Implementation: I suggest a form of name of namespace which can't be present in a variable or proc invocation. This means an explicit namespace-path can't be constructed for a private namespace. -- CMcC 20 Mar 2005
RS: Sandboxes are for playing - I'd hate a closed box that says "hey, you cannot see or touch my sand" in interactive debugging... Also, with escaping as needed, any string can be the name of a variable or proc. In general, I'm more happy with Tcl's spirit "You can do anything you can think of, and more" as opposed to Bondage & Discipline languages that say "Good girls don't".
CMcC RS, there's a difference between license and freedom. What you seem to be suggesting is that I can do anything I can think of except establish a private namespace, and this in the name of freedom. Sandboxing is a technical term, btw.
PWQ CMC:', What is the point of this?. We have safe interpreters, can redefine every command, what would be achieved by private namespaces?. Don't you trust your own code?
CMcC a private namespace would be cheaper and lighter weight than a safe interpreter and provide some of the same facilities. Simple as that.