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.
Or I suppose we could just punt and toss the special global access entirely and make the global namespace a hash 'o hashes hanging off the interpreter and access it like any other variable, but that makes local obscuration of the namespace somewhat difficult and I'd rather not for right now.
This'd be the time to weigh in on it, folks...
I expect we need multiple options and let compiler writers figure out which ones
they need. (see **)
1) Lookup a fully qualified name in the top level namespace (true globals, Foo::Baz::i)
2) Lookup a fully qualified name in a specific namespace (namespace handle in PMC or string)
3) Upward lookup of a fully qualified name starting at a specific namespace
(I'm in Baz, resolve j = lookup in Baz, lookup in Baz->parent, lookup in Baz->parent->parent)
Difference between 2 and 3 is that 2 does not recurse upwards to resolve the name.
**We may also want variations of non-qualified name lookups (optimized not to worry about tokenizing
the identifier).
That's off the top of my head from having written a couple of toy compilers. Keyword = toy
Of course we'll need forms tailored to object instances that will also have to deal with the
semantics of inheritance.
-Melvin
