HaloO,
Daniel Ruoso wrote:
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).
I fully agree that immutability is not a property of types in a
signature. But a signature should have a purity lock :(Int $i is pure)
that snapshots an object state and puts that into $i and also instructs
the underlying object system to check for purity violation in the scope
of the signature. The presence of this trait in methods called on $i and
parameters $i is given to can be checked by the compiler. A save mode
would be to allow only calls that have the trait. This is far from a
halting problem. Simple coverage analysis suffices.
Note that this purity lock doesn't lock the outer object. It is only
affecting the inner scope controlled by the signature. So there have
to be extra means of snapshot generation if a mutable object shall be
given e.g. to multiple invocations with the same snapshot state. This
is no problem for code downstream of a purity lock because snapshotting
a pure object is a no-op.
With these purity locks by means of traits the aforementioned pure
sandbox can be build. E.g. a module can be internally pure and receive
impure objects in its interface converting them on the fly. Note that
a signature must allow the pure trait also in the return type to allow
for purity to spread. So the signature of Int addition might read
multi infix:<+> (Int $x is pure, Int $y is pure --> Int is pure)
which might be abbreviated with purity on the sub as such as a short-cut
to purity in all slots. Also the dispatcher has to make impure
candidates fail in the applicability stage.
An altogether different question is the transition back from a purified
object. Should that always create a new impure object or revert back to
the original the snapshot was taken from? The latter would imply the
original object piggybacked onto the pure snapshot.
The snapshot mechanism has to be efficient to not loose the gains
from purity in a heavily mixed setting. As such it has to be some
copy on write scheme on the object level.
multi infix:<+> (int where { 2 } $i, int where { 2 } $j) {
say "The Big Brother is Watching You!"
return 5;
}
Does a printout already constitute a side-effect? If so, it is at
least not a dangerous one because it doesn't feed changed state
back into the stream of a computation. The only danger is that a
user wonders about the sequence of prints in the course of an optimized
flow. IOW, say could have the 'is pure' trait on its parameters and
on itself.
OTOH, S06 already propose an optimization hint, which should do what you
want, look for "is cached".
But that is for a completely orthogonal kind of optimization.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
