At 09:20 AM 9/5/2001 +1100, Damian Conway wrote:
>The main uses are (surprise):
>
> * introducing lexically scoped subroutines into a caller's scope
I knew there was something bugging me about this.
Allowing lexically scoped subs to spring into existence (and variables, for
that matter) will probably slow down sub and variable access, since we
can't safely resolve at compile time what variable or sub is being
accessed. Take, for example:
my $foo;
my sub bar {print "baz\n"}
{
bang();
$foo = bar();
print $foo;
}
Now, what I want to do is to have bar() resolve to "previous pad, entry 2"
and bar to "previous pad, entry 1". Which they essentially do now. Those
lookups are snappy, at best we need to walk up the pad pointer chain. No
biggie.
However...
If we can inject lexicals into the caller's scope, bang() could add both a
$foo and a bar() inside the block. That means, for this to work right, I
*can't* resolve to a pad#/offset pair--instead I need to look up by name,
potentially every time. For any sort of speed I'd also need to do some sort
of caching scheme with multi-level snooping and cache invalidation, since
if the variables in question resolve in pad N at compile time, and I use
them at pad 0, I need to potentially check that pads 1-N have had changes
to them. I can see this making closures odd too, if I mess with pads at
runtime. (Odd in the "walking down from pad N just got more interesting" sense)
Not that I'm arguing against it, just that I can see some efficiency issues.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
