Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > Okay, okay, I give -- hierarchic namespaces are the way to go. Makes
> > local overrides somewhat interesting, but we'll burn that bridge
when
> > we get to it.
> >
> > find_global P1, ['global', 'namespace', 'hierarchy'], "thingname"
So (excuse the Perl 5), $::thingie would be this:
find_global P1, [], "thingie"
(Or [], "$thingie".)
Makes it odd to actually name a symbol, since it's broken in one + N.
What's the good of separating the symbol name from the namespace name?
> > 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,
>
> What about:
>
> getinterp P2
> set P1, P2['global';'namespace';'hierarchy';'thingname']
>
> That is get_pmc_keyed() on a ParrotInterpreter PMC with a multi-key,
> straight-forward. The set_pmc_keyed() stores a global.
What if global.namespace happens to be autoloaded or otherwise magic?
Will the get_keyed break down and do something equivalent to this?
getinterp P2
set P1, P2['global';'namespace']
set P1, P1['hierarchy';'thingname']
Meaning the construction of an extra multikey? Yech, maybe.
> Constructing a multy-key by hand isn't that simple (or would need
> hacking imcc) (and Key componenent separator is a semicolon).
YECH.
I can see y'all are already leaning away from this direction, but I
thought
I'd still bring them up as ideas:
-> The nameless root namespace is an easy-to-get-to parrot or
interpreter global, so there's no need to have a separate interface
to access the global namespace vs. accessing a namespace in a PMC
register.
(Though interp-is-a-namespace is cute. Maybe too cute, if namespaces
are subclassable.)
-> Namespaces have methods/ops to look up a contained symbol (just
one level), where any string is a valid symbol. (And there's the
option of not recursing into parent namespaces; i.e., looking only
at "declared" members.)
-> Namespaces also have methods to traverse a path of symbols, where
all but the last symbol in the path must itself be a namespace.
Symbol paths are mangled using a DEAD SIMPLE, absolutely canonical
encoding, with debug-friendly printable ASCII escapes. e.g.:
# Example only:
# '.' is path delimiter and '%' is escape char
# Using '\' would induce LTS in IMCC & C.
foreach (@path) {
s/\%/\%\%/g;
s/\./\%\./g;
}
$path = join(".", @path);
So unless you use a '.' or '%' in your symbol, it won't be mangled
at all, and if it started out printable ASCII, it'll stay that way.
And if you do use one of those reserved characters, the mangled form
won't be too terribly surprising.
This does presume that symbols must be in a charset with '.' and
'%'. My heart bleeds for those that aren't.
Bad Thought: If the empty symbol were prohibited (or ignored) in paths,
the delimiter . could be its own escape character, e.g.:
["float";"1.0"] could be float.1..0.
While a strawman symbol path lookup could be implemented in terms of
single-level symbol lookup, smarter namespace implementations might
optimize away the array (multikey) and extra strings. And this doesn't
require any massive restructuring of IMCC or PIR. (Unless you want them
to just do the mangling internally, rather than storing that ["", "",
""]
as an array constant. But why bother? ".." is shorter than ["", "", ""],
and doesn't suggest to a compiler author's mind "keep a struct { char**;
char*; } around for each symbol reference.")
This would make Dan's example into:
find_global P1, "global.namespace.hierarchy.thingname"
shorthand for:
get_globals Py
find_sym P1, Py, "global.namespace.hierarchy.thingname"
and functionally equivalent to the wildly pedantic:
get_globals Py
find_onesym Py, Py, "global"
find_onesym Py, Py, "namespace"
find_onesym Py, Py, "hierarchy"
find_onesym P1, Py, "thingname"
Spelling aside, anyhow. (e.g., where find_onesym yada might be spelled
set yada[].)
--
Gordon Henriksen
IT Manager
ICLUBcentral Inc.
[EMAIL PROTECTED]
