On Wed, 2002-05-15 at 10:36, Dan Sugalski wrote:
> At 10:04 AM -0400 5/15/02, Aaron Sherman wrote:
> >On Fri, 2002-05-10 at 21:42, Damian Conway wrote:
> >
> >> > Wouldn't those be the same?
> >>
> >> Not quite. C<$.bar> is a direct access to the attribute. C<.bar> is a call
> >> to the accessor. There might well be performance issues.
> >
> >I would expect that there won't be, but perhaps I'm optimistically
> >over-hyping Perl6's inlining before it exists.
>
> 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.
That seems like a tragic performance-sink.... Is there some way that the
caller and/or function could indicate that they want to avoid such
over-generalization? Something like an "is const" or "is inline" to
indicate that the subroutine is read-only and cannot be redefined?
When the parser sees:
sub subname(...) is inline { ... }
subname(...);
It could safely just inline the code without any sort of run-time check.
Normal inlining would still take a hit, but I'd hate to see:
$minusone = E ** (PI * I)
go through a run-time check for redefinition.
Of course, we're talking run-time. If you use two modules which both
define a common subroutine as inline (or only one does), there should be
no conflict and the second should override the first. It's only run-time
redefinition of a subroutine which would prevent efficient inlining.
So, in my example above, you could still C<use Math::Pi::Simple> to get
the version of PI that's defined as 3, but you could not have a
subroutine that swapped PI between the two values, based on a
command-line flag.
