At 02:19 PM 9/6/2001 +0200, Bart Lateur wrote:
>On Tue, 04 Sep 2001 18:38:20 -0400, Dan Sugalski wrote:
>
> >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.
>
>Eh... isn't the main use for this, in import()? That's still compile
>time, isn't it?
Sure, but the issue isn't compile time, it's runtime. The main use for
source filters was to allow compressed source, but look what Damian's done
with 'em... :)
>So you optimize it for compile time. Once compile time is over, the
>lexical variables table is frozen. If you want to add more stuff at
>runtime, it'll cost you.
Right. But since you have to take into account the possibility that a
variable outside your immediate scope (because it's been defined in an
outer level of scope) might get replaced by a variable in some intermediate
level, things get tricky. (On the other hand, Simon and I were chatting and
I think we have a good solution, but it'll take some time to pan out)
>BTW if you add new variables at the back of the table, I don't see how
>any old references to existing variables would be compromised.
Well, if you have this:
my $foo = 'a';
{
{
%MY[-1]{'$foo'} = 'B';
print $foo;
}
}
(modulo syntax) should the print print a, or B? We bound to a $foo way
outside our scope, then injected a $foo in the middle.
Personally, I'd argue that it should print 'B'. Others may differ. I don't
care much, as long as I know what I should be doing at the internals level.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
