# -----Original Message-----
# From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
# Of Ken Fox
# Sent: Sunday, September 02, 2001 8:49 AM
# To: Brent Dax
# Cc: [EMAIL PROTECTED]
# Subject: Re: Should MY:: be a real symbol table?
#
# 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.
That's certainly true for C. Actually, I'm not sure the symbol tables
still exist when you execute the program.
Perl, however, is such a dynamic language you can't do a lot of that
resolution at compile-time. What happens when I say:
C:\Documents and Settings\Administrator\Desktop>perl
$x="foo";
$::{"x"}=\"bar";
print $x;
^Z
bar
? If that had been resolved at compile-time, it would have printed
"foo"--but I replaced the SV with "foo" in it. (FWIW, though, I think
it resolves it down to the typeglob.)
However, there are other cases, such as stash manipulations and symbolic
references.
# > 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; ... } }
That's not terribly hard--the two ${x}es are in unrelated scopes. The
more difficult case is:
sub f() { my($x); if(...) {my($x); ...} }
but in that case the inner my($x) could be translated to
temp($MY::x)--the behavior is basically the same. (Actually, if pads
are replaced with stashes, is there any situation where my($x) can't be
translated to temp($MY::x)? Hmmm...)
# 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.
But we've promised to support %MY::. I think we could avoid coding a
special case by using an array of symbol tables instead of an array of
arrays. Besides, who's to say we don't want 'use dominatrix;' to
require my() variables to be fully qualified? :^)
# 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.
No, but I'm planning to help write Perl 6, and I want to make things at
least a bit easier. :^)
Plus, it would help remove many inconsistencies in certain operations,
such as symbolic references:
C:\Documents and Settings\Administrator\Desktop>perl
our($x)="global";
{
my($x)="local";
print join ' ', $x, ${"x"};
}
^Z
local global
(I also seem to remember some weirdness similar to this with eval, but
couldn't reproduce it.)
While this is the documented behavior of Perl 5.6.1, I don't think it's
the right behavior--do you?
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
