namespace bug 2?
Will Coleda
affected by the .namespace directive: it's my understanding it should
only be affected by the .HLL directive. If you comment out the
second .namespace in this code, it prints "ok".
.$ cat foo.pir
.HLL 'bork', ''
.namespace [ '' ]
.sub a :immediate
$P1 = new .String
$P1 = "ok\n"
store_global "eek", $P1
.end
.namespace [ 'sub_namespace' ]
.sub whee :main
$P1 = find_global 'eek'
print $P1
.end
CokeZero:~/research/parrot/languages/tcl wcoleda$ ../../parrot foo.pir
Global 'eek' not found
current instr.: 'bork;sub_namespace;whee' pc 12 (foo.pir:14)
Leopold Toetsch
> Here's another potential NS issue. It looks like find_global is being
> affected by the .namespace directive:
Yes. It sets the current namespace below the HLL namespace.
I think, this is the specced and correct behavior.
leo
Will Coleda
From the PDD:
-----
=item $P0 = find_global $P1, $S0
=item $P0 = find_global $S0
Find $P0 as the variable $S0 in the current namespace. or in $P1,
relative
to the HLL root namespace.
-----
I'm using the first version, but it's relative to the namespace set
in .namespace, not relative to the HLL root namespace (derived from
the .HLL directive)
Tcl is currently avoiding the problem by going back to NAMESPACE_ROOT
and drilling down to get to the parent namespace. On a side note, is
there a way to get at the parent namespace if you have a namespace? I
don't see anything in the PDD about it. (Seems you can only walk
*down* the hierarchy, not up.)
Chip Salzenberg
I think it's correct, though I don't remember speccing it. :-)
By analogy: Suppose your Unix working directory is "/tmp". The reason that
it's a feature (rather than a bug) that open("foo") opens "/tmp/foo" is a
that you can easily defeat the default directory with a full absolute path.
I think Leo's default root and Will's overriding it for his current code are
both the right thing. All we need is to consider which root overrides are
going to be needed and provide convenient ways to do them, rather than the
current awkward work-up-from-namespace-root thing.
How about:
find_global ['name'; 'space'], '$var' # from HLL root
find_global [], '$var' # *at* HLL root
Or a two step version -- more flexible but a bit less convenient:
$P0 = get_namespace ['name'; 'space'] # from HLL root
find_global $P0, '$var'
$P1 = get_namespace [] # *at* HLL root
find_global $P1, '$var'
--
Chip Salzenberg <ch...@pobox.com>
Chip Salzenberg
> From the PDD:
> =item $P0 = find_global $P1, $S0
> =item $P0 = find_global $S0
> Find $P0 as the variable $S0 in the current namespace. or in $P1, relative
> to the HLL root namespace.
Heh, I'm sleepy so I forgot that the C<find_global $P0, $S0> form proposed
in my previous message is already spec'd.
Tada, done! :-)
> I'm using the first version, but it's relative to the namespace set
> in .namespace, not relative to the HLL root namespace (derived from
> the .HLL directive)
That's definitely a bug.
> On a side note, is there a way to get at the parent namespace if you have
> a namespace? I don't see anything in the PDD about it. (Seems you can only
> walk *down* the hierarchy, not up.)
That's true. Given aliasing there may not be just one parent, but I don't
suppose the distant chance of that will keep you from wanting this feature...?
--
Chip Salzenberg <ch...@pobox.com>
Will Coleda
Well, for the tcl interpreter/compiler, there's not a huge need.
Either I keep doing it the way I'm doing it now (and I'm *only* doing
it for getting at the internals at the moment); or you say bug and I
go back to doing it with find_global. Either works, I just want the
docs and the code to line up, and I don't want to have to jump
through too many hoops. I asked about getting the parent because in
this particular case, I know it's just one up, and having to go all
the way back to the top offended my sensibilities. =-)
As for the language itself, I'm fairly certain that you can't have a
parent/child relationship for namespaces in tcl that doesn't
correspond directly to the naming of those namespaces.
So, 'Foo::Bar' *has* to be the parent namespace of 'Foo::Bar::Baz'.
So I don't really *need* parrot to provide a way to do this,
presuming I know the name of the namespace, which I think I have to.
So, for now, don't consider this an RFE on my behalf. (Though I
reserve the right to come back in six months and demand it! =-)
Chip Salzenberg
> On Apr 18, 2006, at 12:19 PM, Chip Salzenberg wrote:
> >On Tue, Apr 18, 2006 at 11:34:49AM -0400, Will Coleda wrote:
> >>On a side note, is there a way to get at the parent namespace if you have
> >>a namespace? I don't see anything in the PDD about it. (Seems you can only
> >>walk *down* the hierarchy, not up.)
> >
> >That's true. Given aliasing there may not be just one parent, but I don't
> >suppose the distant chance of that will keep you from wanting this feature...?
>
> Well, for the tcl interpreter/compiler, there's not a huge need.
> Either I keep doing it the way I'm doing it now (and I'm *only* doing
> it for getting at the internals at the moment); or you say bug and I
> go back to doing it with find_global.
I think we should hold off this until we have a non-diagnostic use case.
I think it's a good idea to add this, as long as we name it in a way that
aliasing doesn't confuse the users. How about
PMC *get_original_parent()
?
It does occur to me that we might want a weak reference there, so that
namespaces can evaporate.
It also occurs to me more strongly that we don't want to have a get_name()
but rather
PMC *get_original_name()
because aliasing may make the original and actual names differ.
--
Chip Salzenberg <ch...@pobox.com>
Leopold Toetsch
> > On a side note, is there a way to get at the parent namespace if you have
> > a namespace? I don't see anything in the PDD about it. (Seems you can
> > only walk *down* the hierarchy, not up.)
>
> That's true. Given aliasing there may not be just one parent, but I don't
> suppose the distant chance of that will keep you from wanting this
> feature...?
NameSpace.parent() is now implemented. I don't see, how we could get multiple
parents, though.
leo
Chip Salzenberg
> Am Dienstag, 18. April 2006 18:19 schrieb Chip Salzenberg:
> > > On a side note, is there a way to get at the parent namespace if you have
> > > a namespace? I don't see anything in the PDD about it. (Seems you can
> > > only walk *down* the hierarchy, not up.)
> >
> > That's true. Given aliasing there may not be just one parent, but I don't
> > suppose the distant chance of that will keep you from wanting this
> > feature...?
>
> NameSpace.parent() is now implemented.
Cool. I'm afraid it needs to be set_parent() and get_parent(), though, for
when someone wants to transplant a namespace into a (new?) location.
> I don't see, how we could get multiple parents, though.
If a namespace is imported, so that it has multiple names, that implies
there are two parent namespaces from which it can be reached. But I'm not
interested in fully modeling that situation. One parent is plenty.
--
Chip Salzenberg <ch...@pobox.com>
Leopold Toetsch
On Jun 6, 2006, at 20:11, Chip Salzenberg wrote:
>> NameSpace.parent() is now implemented.
>
> Cool. I'm afraid it needs to be set_parent() and get_parent(),
It is now get_parent().
leo