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