Brent Dax wrote:
> Is there any real reason my() variables are stored in a pad instead
> of a symbol table?
Simon already told you why a pad is used.
But I think you misunderstand what a symbol table is. Variables
aren't *stored* in the symbol table. Only the definitions and storage
locations of variables are stored there. During execution of a program
symbol tables usually aren't needed -- the generated code embeds the
necessary information from the symbol table. For example, if you have
void f() { int x; x = 1; ... }
then "x" in the symbol table may be defined as "4 byte integer at stack
pointer - 4". The code for getting/setting "x" doesn't use the symbol
table because it has instructions like "mov sp[-4], 1" or something.
> Once again, why isn't MY:: stored in some sort of anonymous symbol
> table? This would allow us to do all the things we can normally do
> with a global, without the hassles of writing a magical pseudo-package.
You can't store lexical variable definitions in a global symbol
table. What happens when you try to access a local variable that
doesn't exist because it isn't in scope? Also, many of the scopes
that contain variables aren't named. How would you differentiate
between the following two "$x" variables?
sub f() { if (...) { my $x; ... } else { my $x; ... } }
If you want to grab a lexical, you *must* be in scope. If you're
already in scope there's no reason for "MY::" -- just use the
variable's real name.
It sounds like you just want a simple way of getting the variables
in scope -- are you writing a debugger? I agree with you that it would
be very nice to have a low-level debugging API that doesn't treat
lexicals differently than globals.
- Ken
