On Jan 15, 2004, at 9:52 AM, Dan Sugalski wrote:
At 10:13 AM -0800 1/13/04, Jeff Clites wrote:Here are some notes on namespaces, picking up a thread from about a month ago:
On Dec 11, 2003, at 8:57 AM, Dan Sugalski wrote:
That does, though, argue that we need to revisit the global access opcodes. If we're going hierarchic, and we want to separate out the name from the namespace, that would seem to argue that we'd want it to look like:
find_global P1, ['global', 'namespace', 'hierarchy'], "thingname"
That is, split the namespace path from the name of the thing, and make the namespace path a multidimensional key.
I definitely agree that we should have separate slots for namespace and name, as you have above. So I think the discussion boils down to whether a namespace specifier is logically a string or an array of strings.
Short version: I was originally going to argue for fully hierarchical namespaces, identified as above, but after turning this over in my head for a while, I came to the conclusion that namespaces are not conceptually hierarchical (especially as used in languages such as Perl5 and Java, at least), so I'm going to argue for a single string (rather than an array) as a namespace identifier.
Here's my big, and in fact *only*, reason to go hierarchical:
We don't need to mess around with separator character substitution.
Other than that I don't much care and, as you've pointed out, most of the languages don't really do a hierarchical structure as such. Going hierarchical, though, means we don't have to do "::"/":"/"/"/whatever substitutions to present a unified view of the global namespaces.
A key part of my argument (and it's find if you understood this, and disagree--just wanted to make sure that it was clear) is that I think we shouldn't try to do any sort of cross-language unification. That is, if we some day have a Parrot version of Java, and in Perl6 code I want to reference a global created inside of some Java class I've loaded in, it would be clearer to just reference this as "java.lang.String.CASE_INSENSITIVE_ORDER", even inside of Perl6 code--rather than having to do something like "java::lang::String::CASE_INSENSITIVE_ORDER". Parrot itself would be completely ignorant of any concept of a separator character--these would just be uninterpreted strings, and "foo::bar" and "foo.bar" would be separate namespaces, whatever the language. I think it's confusing to try to unify namespaces across languages, and doesn't buy us anything. I think it's much cleaner to say "namespaces have names which are arbitrary strings, and if you want to put colons or periods in the name, so what--parrot doesn't care".
(That said, if the Perl6 creators and the Java-on-Parrot creators decided that it _is_ good to try to unify their namespaces, they could still do this at the compiler level--so maybe Perl6 would substitute "." for "::" in namespace names at compile time. But parrot itself wouldn't know or care. And, if the Python people decide it's better not to try to unify with this mega-namespace, that's up to them.)
So I'm arguing here against a unified view of the global namespaces. But, if we decide that's needed, then I definitely agree that it's best to avoid having some magic separator character--much cleaner to treat it as an array.
JEff
