Namespaces Redux
Matt Diephouse
But I've run into a bit of trouble, so I have a couple questions:
The get_namespace opcode gets namespaces from the root namespace.
Should it get namespaces from the HLL namespace instead? The PDD isn't
explicit either way, but the usage I had in mind works better if it
works from the HLL namespace. I've added a failing test that tries to
get a namespace from the HLL.
Is there any reason that [...; ''] and [...] couldn't refer to the
same namespace? Tcl uses C< .namespace [''] > to refer to the root
namespace (correctly, I think) and I can't think of any language that
would want to differentiate between the two. It would simplify code
generation for Tcl to have '' act like this.
Here's some Perl that models what I'm trying to write for Tcl in PIR:
my $command = "...";
my @namespace = split /::+/, $command;
$name = pop @namespace;
my $namespace = get_namespace(@namespace);
my $sub = find_global($namespace, $name);
$sub->();
Without the changes, I'll have to unshift 'tcl' to the front of every
array I use to lookup namespaces, as well as check for empty strings
(consider the input "::puts", which should refer to the "puts" global
in the '' namespace). It's a lot of code that's not really necessary.
Also, is there any reason we can't/shouldn't add find_global variants
that lookup globals in HLL's? Right now we have find_global_p_p_s.
Adding find_global_p_s_p_s would let me reach into Tcl's private very
easily instead of having to crawl the namespaces myself.
$P0 = find_global '_tcl', ['Foo'; 'Bar'], "baz"
Thanks,
--
matt diephouse
http://matt.diephouse.com
Chip Salzenberg
> The get_namespace opcode gets namespaces from the root namespace.
> Should it get namespaces from the HLL namespace instead? The PDD isn't
It is, actually:
=head2 Namespace Opcodes
Note that all namespace opcodes operate from the local HLL root namespace.
Navigating outside one's own HLL namespace requires either the C<interpinfo
.INTERPINFO_NAMESPACE_ROOT> opcode or the get_namespace() compiler PMC method.
"All namespace opcodes".
> Is there any reason that [...; ''] and [...] couldn't refer to the
> same namespace?
The design as it stands avoids any special meaning for *any* string. Any
string whatsoever is a valid key; any valid key is a valid namespace name.
This is a design goal that would be compromised by the '' special case.
> Tcl uses C< .namespace [''] > to refer to the root namespace (correctly, I
> think) and I can't think of any language that would want to differentiate
> between the two.
All you need to disprove this speculation is one counterexample, and the
counterexample doesn't even have to exist yet.
> Also, is there any reason we can't/shouldn't add find_global variants
> that lookup globals in HLL's? Right now we have find_global_p_p_s.
> Adding find_global_p_s_p_s would let me reach into Tcl's private very
> easily instead of having to crawl the namespaces myself.
It's three steps rather than one, but it's not crawling, and it's already in
the pdd, mostly:
.local pmc tcl
tcl = compreg "tcl"
.local pmc ns
ns = tcl.'get_namespace'(['Foo';'Bar'])
I'm cheating a little here because I'm showing you an example with a key
(which the docs don't specifically allow) rather than an array (which they
do allow), but the point is to demonstrate compiler.get_namespace().
--
Chip Salzenberg <ch...@pobox.com>
Matt Diephouse
> On Wed, Jun 28, 2006 at 11:40:28PM -0700, Matt Diephouse wrote:
> > The get_namespace opcode gets namespaces from the root namespace.
> > Should it get namespaces from the HLL namespace instead? The PDD isn't
> > explicit either way [...]
>
> It is, actually:
>
> =head2 Namespace Opcodes
>
> Note that all namespace opcodes operate from the local HLL root namespace.
> Navigating outside one's own HLL namespace requires either the C<interpinfo
> .INTERPINFO_NAMESPACE_ROOT> opcode or the get_namespace() compiler PMC method.
>
> "All namespace opcodes".
Dunno how I missed that. But that is very good news.
> > Is there any reason that [...; ''] and [...] couldn't refer to the
> > same namespace?
>
> The design as it stands avoids any special meaning for *any* string. Any
> string whatsoever is a valid key; any valid key is a valid namespace name.
> This is a design goal that would be compromised by the '' special case.
>
> > Tcl uses C< .namespace [''] > to refer to the root namespace (correctly, I
> > think) and I can't think of any language that would want to differentiate
> > between the two.
>
> All you need to disprove this speculation is one counterexample, and the
> counterexample doesn't even have to exist yet.
Fair enough. But one question remains: how do you tell IMCC that you
want to be in the root HLL namespace? C< .namespace [] > is a parse
error.
> > Also, is there any reason we can't/shouldn't add find_global variants
> > that lookup globals in HLL's? Right now we have find_global_p_p_s.
> > Adding find_global_p_s_p_s would let me reach into Tcl's private very
> > easily instead of having to crawl the namespaces myself.
>
> It's three steps rather than one, but it's not crawling, and it's already in
> the pdd, mostly:
>
> .local pmc tcl
> tcl = compreg "tcl"
>
> .local pmc ns
> ns = tcl.'get_namespace'(['Foo';'Bar'])
>
> I'm cheating a little here because I'm showing you an example with a key
> (which the docs don't specifically allow) rather than an array (which they
> do allow), but the point is to demonstrate compiler.get_namespace().
This doesn't work for *private* namespaces -- only public ones. ParTcl
currently uses a macro to crawl its private namespaces, which AFAIK is
the *only* way to access the helper subs it has in private namespaces.
Chip Salzenberg
> Chip Salzenberg <ch...@pobox.com> wrote:
> >On Wed, Jun 28, 2006 at 11:40:28PM -0700, Matt Diephouse wrote:
> >> Tcl uses C< .namespace [''] > to refer to the root namespace (correctly,
> >> I think) and I can't think of any language that would want to differentiate
> >> between the two.
> >
> >All you need to disprove this speculation is one counterexample, and the
> >counterexample doesn't even have to exist yet.
>
> Fair enough. But one question remains: how do you tell IMCC that you
> want to be in the root HLL namespace? C< .namespace [] > is a parse
> error.
No answer for you yet. Bug report on that one, please; at first blush I
think the solution is that ".namespace" without parameters should be the
root, or that some pseudo-HLL, perhaps the default "parrot" one, should have
the root namespace as its HLL namespace.
> >> Also, is there any reason we can't/shouldn't add find_global variants
> >> that lookup globals in HLL's? Right now we have find_global_p_p_s.
> >> Adding find_global_p_s_p_s would let me reach into Tcl's private very
> >> easily instead of having to crawl the namespaces myself.
> >
> >It's three steps rather than one, but it's not crawling, and it's already
> >in the pdd, mostly:
> >
> > .local pmc tcl
> > tcl = compreg "tcl"
> >
> > .local pmc ns
> > ns = tcl.'get_namespace'(['Foo';'Bar'])
> >
> >I'm cheating a little here because I'm showing you an example with a key
> >(which the docs don't specifically allow) rather than an array (which they
> >do allow), but the point is to demonstrate compiler.get_namespace().
>
> This doesn't work for *private* namespaces -- only public ones. ParTcl
> currently uses a macro to crawl its private namespaces, which AFAIK is
> the *only* way to access the helper subs it has in private namespaces.
Oh. Well, if tcl is looking up its _own_ private namespace, and if I
understand what you mean by "private namespace" (that's not a standard
Parrot term of art), and (IIRC) Tcl namespaces are untyped, then you can
take advantage of the untyped interface which accepts (or should accept!) a
multi-dimensional key:
.local pmc private_ns
private_ns = get_namespace '_tcl'
...
.local private_foo_bar
private_foo_bar = private_ns['Foo';'Bar']
--
Chip Salzenberg <ch...@pobox.com>