Dan Sugalski wrote:
> $foo = 12;
> $bar = something();
> $bar = $foo;
>
> could work out to:
>
> $foo = $bar = 12;
> something();
If $foo is a lexical variable and it hasn't been aliased then
you might be able to do that optimization. The following is just
as good and safer:
$foo = 12;
scalar(something());
$bar = $foo;
> Where if you tie, we have *no* idea what you're doing. This:
>
> tie $foo, SomeModule;
> $foo = 12;
>
> could well reboot some server in outer mongolia for all we know. Tied
> variable access counts as a function call, which smacks optimization all by
> itself.
Do we have to worry about pass-by-ref semantics and @_ assignments
too? This is a weird edge case that I've never ran into. That's going
to put a big damper on optimization with subs.
Actually, we have this problem without tie if we allow external
code to register new primitive types. For example, we assume that +
is commutative so that we can re-order expressions and fold constants.
That would break a module that implemented some weird + that wasn't
commutative.
Anybody that does this has to define a new operator, i.e. if they
use the standard operators, they have to live with the standard
semantics. (This is why string concatentation should never use +!)
I really need to start playing with a parser and dataflow analysis
before thinking too much more about this. It might be that we need
something *way* more strict than use strict before aggresive
optimization is possible.
- Ken
