Let's try this again, starting from the Tcl side of things. Tcl code
can exist outside of subroutines. This, for example, is a valid Tcl
program:
set number 5
puts $number
In order to compile this to PIR, we have to put it into a subroutine.
The only problem with putting it into a subroutine is that we don't
want to pollute our namespace. So, naturally, we make it an :anon sub.
Here is an extremely simplified version (that represents the ideal,
but probably unattainable, emitted PIR):
.HLL 'tcl', 'tcl_group'
.namespace
.sub 'main' :anon :main
.local pmc number
number = new .TclInt
number = 5
set_global 'number', number
say number
.end
That doesn't look too bad. This actually works and correctly stores
the "number" variable in the root HLL namespace. But things get a
little hairier when we start using namespaces in Tcl:
namespace eval test {
set number 5
puts $number
}
This is the equivalent of running the first example in a different
namespace. So, again, the simplified, ideal PIR is:
.HLL 'tcl', 'tcl_group'
.namespace ['test']
.sub 'main' :anon :main
.local pmc number
number = new .TclInt
number = 5
set_global 'number', number
say number
.end
But here we run across the behavior that led me to file RT#40955: I
have an anon namespace that uses the notion of the current namespace.
The code is the same, but the PIR example doesn't work because the
"current namespace" inside the :anon sub is the root HLL namespace. So
while
set_global 'number', number
would normally be equivalent to
set_hll_global ['test'], 'number', number
in this case, it's actually equivalent to
set_hll_global 'number', number.
All this because when Parrot sees an :anon sub it attaches the root
HLL namespace to it (or did, before I applied my "fix"). It's not that
it doesn't attach any namespace to it, it's that always attaches the
root HLL namespace regardless of the namespace it's declared in.
That, at least, ought to change. If there is no notion of a current
namespace in an :anon sub outside of a closure, then trying to use one
ought to make things blow up so I can see the error in my ways. :-)
Still, I'm curious to see what reasons there are for not attaching a
namespace to an :anon sub when (1) it seems convenient and (2) all of
Parrot's tests still pass. Does this break anything? Or did this just
signal to you that there may a problem here that needs its own
solution?
--
Matt Diephouse
http://matt.diephouse.com
