Allison Randal <[EMAIL PROTECTED]> wrote:
Okay, so we're basically solving the same problem as Perl 5's "main" routine, which it stuffs in an obscure C variable internal to the interpreter, not accessible from the symbol table. (Talk about less-than-transparent introspection.)
Huh. I don't know anything about Perl 5's internals, but that's interesting and it makes a lot of sense.
I don't fully grok Tcl, so a few questions (which may or may not be relevant): Where do mainstream implementations of Tcl store that executable "main" block of code? Or, more importantly, where do they store 'number' in the case without the namespace and the case with the namespace?
The official Tcl implementation is an interpreter, not a compiler. So I suspect the answer to your question is "it doesn't". But without a namespace, 'number' is stored in the root HLL namespace; it could also be accessed absolutely (C< $::number >).
One common use of anonymous subs in a dynamic language is for later exporting them into another package (or multiple different packages). In that case, you really don't want the sub to retain a link to its defining namespace, you want it to fully adopt the namespace it's pushed into. Which has everything to do with the earlier Perl example of creating anonymous subroutines, but little to do with creating "main" routines, since they don't change packages. (Code examples are helpful.)
I'm struggling to understand what you're saying here. You noted before that Perl 5's anonymous subroutines are full dynamic closures. As such, they don't ever fully adopt the namespace they're pushed into. Are you thinking of a different language? or am I missing a case?
Let's see... for :main, :load, :method, and :vtable compilation units it makes sense to default lookups to the namespace where they were defined, even if they're anonymous. For an ordinary :anon .sub (with no :vtable, :method, :load, :main, etc) I could argue it either way, but with the other uses remaining tied to the namespace where they were defined, let's default to your fix (consistency is good).
I was hoping you'd say that. :-)
Then for exporting (and other dynamic tricks), let's look into a feature that allows you to change the namespace a compilation unit uses for default lookups, after it's compiled.
That seems like a good idea. -- Matt Diephouse http://matt.diephouse.com
