At 10:41 AM 9/6/2001 +0200, Bart Lateur wrote:
>Firs of all, currently, you can localize an element from a hash or an
>array, even if the variable is lexically scoped.
This doesn't actually have anything to do with lexicals, globals, or pads.
And the reason the keyword local works on elements of lexical aggregates is
actually a bug.
Perl has a generic "save stack". The interpreter can push a structure
containing an address, type, and value on the stack. It can also push
'marks' on the stack.
When control flow hits the start of a scope, perl pushes a mark. Then,
every time you do something that requires remembering, perl pushes one of
these memory structures on the stack. When perl leaves a scope, it then
walks up the save stack and finds all the memory structures on it up to the
topmost mark. It removes those structures and, more importantly, puts all
the values in those structures back at the addresses in the structures.
So what's happening when you localise an array element is perl is pushing a
structure on the stack that looks like:
where: address of $array[18]
what: SV
contents: SV * pointing to the scalar containing "12"
then sticks an empty new sv in $array[18]. When you leave the scope, perl
sees that structure and puts the pointer back where it got it. Perl knows
there are SVs involved so the restore handles refcounts right. (You can
also put plain addresses, IVs and NVs on the stack)
You can, in XS code, actually use this to dynamically and temporarily
modify pieces of a C structure. That's kinda nasty, though. (But clever...)
The reason you can localize an element in a lexical array or hash is
because perl doesn't check the lexicalness of the container when you
localize an element. It should, but doesn't.
>Unfortunately, this doesn't work with plain lexical scalars. I wonder
>why. Really.
Well, now you know! :)
>Typeglobs are on the verge of extinction. Perhaps the current concept of
>symbol tables may well follow the same route?
It probably will. The big issue is that lexicals can be resolved to pad
entry numbers at compile time, so they're all accessed like "get variable 3
from pad 4". The global table isn't all known at compile time so we can't
know that, so we have to look up by name. Given the extra certainty with
lexicals, it makes sense to choose a different data structure, one we can
access more quickly because we have more certainty.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
