Name Space

An imaginary space where names uniquely identify things; two things within that space can't have the same name. In computation language, a set of bindings from names to entities. In mathematical language, a function from a set of names to values. As an interesting side note, certain natural languages have noun classifiers which bear an uncanny similarity to namespaces. One such instance is the Vietnamese noun classifier 'đàn', meaning 'chordophone'. The đàn bầu is the monochord; the đàn tranh is the 36-string zither, etc. A number of languages spoken in East and South East Asia are replete with such noun classifiers. -- TheerasakPhotha

Interesting. I don't know Vietnamese, but is this comparable to hat / top hat / fur hat or cycle / bicycle / motorcycle / tandem bicycle? It seems like in English the pattern is either noun-category or adjective* noun-category, that is, the modifiers prefix the categorical noun. Vietnamese seems to use suffixes instead. In English, the modifiers are considered adjectives, though; do tranh or bầu have noun meanings outside of the đàn namespace? -- ScottVokes

: I'm Vietnamese. đàn is not a suffix but a word. In fact, Vietnamese doesn't have affix. tranh and bầu do have their own meanings outside the đàn namespace (and they are totally different from their counterparts inside đàn namespace). -- DuongNguyen

Huh? It isn't imaginary. It's real.. in a virtual text sense. Since when was a module, text file, unit, or similar organization technique something that was imaginary? A namespace is just a stolen idea from Modula and similar languages.

People are most familiar with namespaces in filesystems. When programmers use the word namespace, they usually mean what a process sees when executing. Of course, this is a completely artificial distinction. A user is a process and, in a decent OS, vice versa. [Further discussion moved to ShouldUsersBeProcesses.]

Namespaces occur in both operating systems and languages. Let's take a look at the qualities namespaces should possess. Then we'll be able to judge, harshly, the typical implementations of namespaces with their many defects.

Principles of namespaces

Globally Consistent
Globally Connected
Local Point of View
Secure Access
Transitive Connections
Symmetric Connections
DirectedAcyclicGraph internally, DirectedGraph overall
Abstract (seemed obvious until encountered SingleAddressSpaceOperatingSystem)
Infinite

This means that

there is a single global namespace
but processes can exist wherever they want on it
so long as they have the appropriate permissions
which are transitive under the #hasOwershipOf: operation

This does not mean that one is stuck with conventional global variables, or must give up having "a new namespace per function"; indeed, one never gets a completely new name space per function.

A function's point of access to a namespace is where it exists. And since processes can exist anywhere, their local point of view can be from anywhere in the namespace; hence, the distinction between Disconnection and Locality principles. This is strictly superior to existing semantics because Plan 9 and Unix processes can have only one pre-defined point of view, starting at the root node.

Again note, to make sure this point is clear: there is no programming language which gives you a brand new namespace per function. Lisp and Smalltalk are both examples of the complete opposite (eg, inheritance).

Oh, and

the namespace can have zero to infinite number of links to any object (eg, a directory)
which are all bidirectional

Unix / Plan 9 do not have this and can never have it. Smalltalk does not have it.

: Why is this forever impossible?
: Because these features are fundamental architectural properties.

: No that is not right, they can - it just requires a UnifiedObjectArchitecture? to marry the underlying O.S. view with Programmer's view to create a DataEcosystem.

which are transitive

How are permissions transitive? If X has permission to Y and Y has permission to Z then X has permission to Z? This doesn't seem to make grammatical sense, even?

There is transitivity under the #hasOwershipOf: operation.
There is symmetry under the #aCapabilityExistsTo: operation.
It is false that every object has a cap to itself. No reflexion.
It is false that a cap from A to B is the same as a cap from B to A. No commutivity.
There is associativity under the #createALinkTo: operation.

Plan 9

PlanNine has two categories of namespaces; public, and private. A public namespace is one exported by a filesystem. A private namespace is one internal to a process. Each process composes its private namespace from public namespaces in an arbitrary manner. And there exists no simple mechanism by which a private namespace can be published or shared (duplication is not sharing). Therefore, a Plan 9 OS has the following limitations:

processes may only exist on root nodes of the namespace
each process' namespace is inconsistent with every others' in principle
it's not possible to conceive of the OS' namespaces without knowing the implementation details of their composition
there exists no mechanism to climb up the namespace; connections are not symmetric

: This is incorrect. It's actually trivial to start a new process in the same namespace as it's parent. The person who wrote this set of bullets didn't experiment enough
: It's not clear what climbing up the namespace even means.
: You do realize that you're contradicting a judgement you admit you don't understand, don't you?
: I think that's forgivable, considering the OP has demonstrated that he doesn't understand what he's talking about either.
: Being able to start a process in its parent's namespace means nothing. It means only that a very arbitrary group of processes can share a namespace in a highly constrained fashion. This is nothing. When Plan 9 allows processes from completely separate users to see each other's namespaces, then we can talk. Until then, you have nothing useful to contribute.

And while Plan 9's namespaces are officially trees, this is a lie since union directories join different branches of the tree. However, they do this at the expense of flattening them.

: It's a tree. You can bind items to anywhere in the hierarchy and you can control the order in which the upper levels [which are the only bits flattened out] are looked up in a union. You also don't have to use unions as it's an option to binding. One can completely mask out other directories in the hierarchy.
: You do realize don't you that you haven't provided any useful information? That your idiotic list of "features" doesn't in any way compensate for the fundamental limitations of trees? That being able to "control" the way unions work in no way compensates for the fact that unions are just plain dumb and practically worthless in comparison to actual graphs? That the "feature" of masking out stuff in the hierarchy is completely retarded and only serves to weaken the trees in comparison to graphs? No, somehow I doubt you realize any of that.
: You've articulated your original point poorly, and responding to people with angry rants and dull insults isn't helping.
: Sharing namespaces with another process (even owned by another user, on a different computer, of a different CPU architecture) is trivial. See srvfs(4). Furthermore calling namespaces either public or private is confusing. The documentation does not use those terms nor have I ever seen them on 9fans. A more sensical way to put it is that a process's namespace can be served via 9p (thereby allowing another process to mount the first process's namespace into its own namespace) or not.

VisualWorksSmalltalk

VWST's programmers have implemented namespaces in order to solve a perceived problem with package collision. They also do not understand namespaces; they have no security at all. At least, their implementation does allow one to share bindings. The problem with their implementation is that:

the importing mechanism flattens the namespace; one can't simply connect to another namespace, and of course
there are no connections back; one can't see which namespaces have imported oneself.

It would be nice if the principles above were motivated somehow. This is how things should be? Ok, but why? Yes, there are zillions of kinds of namespaces that aren't like that, granted, but there's no explanation of why that's bad. For instance, a simple set of names, like Lisp's atom table, is frequently called a name space. What's the harm in calling it that?

At the most abstract level, names are references. So are pointers. So a machine address space can be viewed as a name space. Should it follow the below principles? Why or why not?

Yes! Just because a namespace refers to low-level objects doesn't mean that you're allowed to treat it as anything but a special case of an ideal namespace.

For example, a hard disk driver must represent the address space of blocks it exports as a special case of a general namespace. It must also do this within the semantics of the system, which must be uniform. This is no problem since all it means is that every object in the hard disk driver's namespace (ie, the namespace it implements, not the namespace it runs in - the latter being non-exclusive to it) has create and delete permissions set to OFF. This prevents users from creating or destroying bytes in a disk block (because it is impossible), from creating or destroying blocks (same thing), and from renaming blocks with values outside of the allowed integer interval.

Further, a namespace can't be viewed in isolation because the namespace principles below dictate that you be able to move between namespaces as easily as you do within them. Every functional namespace in the system must be connected to every other namespace (at least transitively), and each link must be bidirectional. So you can't talk about a namespace, but only about individual components of The Namespace.

Uniformity requires you represent everything you expose in the same way, whether it's low-level or abstract. ExoKernel requires you expose low-level objects to sufficiently privileged users. These are fundamental OperatingSystemsDesignPrinciples.

CategoryOperatingSystem, CategoryProgrammingLanguage, CategoryNaming, CategoryInfoPackaging