Em Seg, 2009-02-16 às 21:21 -0800, Darren Duncan escreveu:
> marking it as consisting of just immutable values, and in the
> routines case marking it as having no side effects
The problem is that you can't really know wether a value is immutable or
not, we presume a literal 1 to be immutable, but even if you
receive :(Int $i), it doesn't mean $i is immutable, because that
signature only checks if $i ~~ Int, which actually results in
$i.does(Int).
The twisted part is that $i.does(Int) is a regular method call on $i,
which means that $i might be of whatever type, and be accepted by that
signature by simply replying True on "does".
The only exception to that rule are the native types, which are
guaranteed to always be of that actual type, you can't "lie" about a
native int, as you can with Int.
Even then, you would have to check if all the multi-variants for the
operators used in that function are free of side-effects as well,
because no one stops you from writing:
multi infix:<+> (int where { 2 } $i, int where { 2 } $j) {
say "The Big Brother is Watching You!"
return 5;
}
or worse
multi infix:<+> (int where { 2 } $i, int where { 2 } $j) {
return OtherTypeThatHasSideEffectsButDoesInt.new(:initial_value(5));
}
So, while I agree that it would be very cool to make pure functions
optimizeable somehow, you simply can't be sure about it.
OTOH, S06 already propose an optimization hint, which should do what you
want, look for "is cached".
daniel
