It should be possible to define a private [namespace] such that no external references to [variable]s are possible, and no invocation of namespace-local [proc]s are possible except via [namespace export]ed names.

This would provide a nice degree of encapsulation, perhaps even a cheap [sandbox] 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.

----