Dan Sugalski wrote:
> At 02:05 PM 9/6/2001 -0400, Ken Fox wrote:
> >You wrote on perl6-internals:
> >
> > get_lex P1, $x # Find $x
> > get_type I0, P1 # Get $x's type
> >
> > [ loop using P1 and I0 ]
> >
> >That code isn't safe! If %MY is changed at run-time, the
> >type and location of $x will change. You really need to put
> >the code for finding $x *inside the loop*.
>
> Only if $x is active. (i.e. tied) In that case we need to do some other
> things as well. I was assuming the passive case, for which the code was
> valid since there wasn't any way for it to be changed.
Could you compile the following for us with the assumption that
g() does not change its' caller?
sub f {
my $sum = 0;
for (0..9) {
$sum += g()
}
$sum
}
Now what if g() is:
sub g {
my $parent = caller().{MY};
my $zero = 0;
$parent{'$sum'} = \$zero;
1
}
What if g() *appears* to be safe when perl compiles the loop, but
later on somebody replaces its' definition with the scope changing
one? Does perl go back and re-compile the loop?
The compiler could watch for uses of %MY, but I bet that most
modules will eventually use %MY to export symbols. Can the
compiler tell the difference between run-time and compile-time
usage of %MY?
> Now, granted, it might be such that a single "uses string eval" or "uses
> MY" in the program shuts down optimization the same way that $& kills RE
> performance in perl 5, but we are in the position of tracking that.
To quote Timone: "And you're okay with that?"
- Ken
