> Languages like perl can't easily be inlined, since subs may be
> redefined at any time. If a sub's a leaf sub you can detect changes
> before calling safely, but if it's not a leaf sub you run into the
> potential issue of having the sub potentially redefined while you're
> in it.
If I'm in middle of executing function A, and I redefine function A, then
it doesn't matter for the execution of the function. Even un-inlined, the
execution continues as it did before. Perhaps this should be an argument
to appease the callee-save proponents. Their main argument was leaf subs.
If we can guarantee that these are inlined, then their only argument goes
away. :)
As such, I think we should be able to inline a call to A() with:
if( value A == value of A when we inlined it )
contents of sub
} else {
A()
}
Alternately, I think we should be able to mark subs as 'final' or 'inline'
to indicate our guarantee that they won't be modified. Of course, it'll
conflict with auto memoizing or auto currying modules that'd want to
override it, but that's their fault. :)
And even though distributed .pbc files and seperate compilation are some
goals of perl6, I still think we're okay. If we inline a function in
module A, and module A changes, Perl6 should ensure that the original
version is still loaded for our code, and thus our inlining should still
be valid.
Another avenue is that of self-modifying code. I know it would break
threads, or cause code duplication between threads, but when A changes, we
can either re-inline the new subroutine, or eliminate the 'if-else' check
to avoid the branch we know will be false from then on. Creating code
which optimizes itself as it's run based upon internal profiling would be
cool. But that's the topic of a different thread. :)
Of course, this is all starting to impose on p6i territory. I don't like
to start cross-posting unnecessarily, so someone please do that if it's
appropriate.
Thanks,
Mike Lambert
