Austin Hastings writes:
>
>
> > -----Original Message-----
> > From: Larry Wall [mailto:[EMAIL PROTECTED]
> > On Thu, Mar 11, 2004 at 06:49:44AM -0800, Gregor N. Purdy wrote:
> > : So, will "mutatingness" be a context we'll be able to inquire on
> > : in the implementation of a called routine?
> >
> > Probably not, but it's vaguely possible you could somehow get a
> > reference to what is being assigned to, if available, and check to see
> > if $dest =:= $src (where =:= tests to see if two refs point to the
> > same object). But in general I think most "want" testing is just a
> > way of making code run slow, because it forces tests to be done at run
> > time that should be done at compile time or dispatch time. It's better
> > for the optimizer if you can give it enough type hints and signature
> > hints to decide things earlier than the body of the sub or method.
> >
> > : Or, could we provide a specialized distinct implementation
> > : for mutating that would get called if .=X() is used?
> >
> > That is much more likely. In general if you don't define both an <op>
> > and an <op>= then Perl can autogenerate or emulate the missing
> > one for you.
> >
> > Now in the specific case of . and .= we don't exactly have a normal
> > binary operator, because the right side is not an expression.
>
> $tis.=ÂÂsad pity pity sad sad pity trueÂ;
>
> $s .= ($useMbcs ? wlength : length);
>
> (Side note: although that expression isn't valid, since the wlength
> and length methods aren't qualified, it *should* be, since a human could
> infer it rather easily.
Well, for a slightly more complex expression, a human would have some
trouble. This is very likely to be laziness, and we can do without it.
There is certainly a way to do this if it is absolutely necessary:
my $method = ($useMbcs ?? 'wlength' :: 'length');
$s.=$method;
> > On the other hand, I'm deeply suspicious of a return signature that
> > mentions a specific variable. What if the body says to return something
> > else? Is that just ignored? Do we check it to see if it's the same
> > item?
>
> No. You might well say:
>
> $string.=length;
>
> And convert from one subtype to another. I think the mutation indicator
> is a hint to the optimizer, and a crutch for the implementor, in cases
> where it's possible to squeeze more performance out of skipping the
> assignment phase. (In particular, where an inefficient assignment operator
> exists.)
The last thing we need is another idiom that gets destroyed for
"efficiency" reasons. Once people hear that that is "fast", they'll
start writing:
$string.=length;
Instead of what they would usually write, the much cleaner:
my $len = $string.length;
Even though the latter is only 0.05% slower.
Speed has corrupted many programmers.
>
> Question: Can all this noise be eliminated by paying more attention to
> the construction of the assignment operator?
>
> That is, do we have an example where $a .= meth is going to perform poorly,
> and that performance is NOT because of the $a = $a.meth assignment? (And
> that cannot be fixed by declaring the invocant 'is rw'.)
The performance issue is never because of the assignment. Assignment is
basically free: it's just copying a pointer.
It's usually because of the construction. Constructing a 10,000 element
array's going to be expensive, so you'd rather sort in place.
Luke
