Re: Re: Namespaces Redux
On Fri, Jun 30, 2006 at 10:50:58PM -0700, Matt Diephouse wrote: > Chip Salzenberg <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
Re: Re: Namespaces Redux
Chip Salzenberg <[EMAIL PROTECTED]> wrote: 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 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. Thanks, -- matt diephouse http://matt.diephouse.com
Re: Namespaces Redux
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 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 <[EMAIL PROTECTED]>
Namespaces Redux
I've started implementing namespace support in Tcl this week (yay!). 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