Brandon Allbery via RT wrote: >I did not mean "You created something equivalent to a mutable-key Pair". >You *precisely* created a Pair that has a mutable component, in something >that is not intended to be mutable.
That view doesn't work for the situation in [perl #128948]. It's quite intentional there that it's possible to create a Pair with a Scalar container in its value slot: I didn't use .VAR. By the view you're expressing, the situation there is precisely that the Pair is mutable in respect of its value. The .WHICH that is presently generated for that situation, of the "Pair|47804193992464" form, follows that view, attributing the mutability to the Pair itself. But I was able to create two Pairs referencing the same Scalar value container. It's visible that they reference the same mutable storage; the behaviour upon mutation is different from what would be seen if each Pair had its own mutable storage. In that ticket the result was that I had two behaviourally-identical Pairs claiming different identity. We could paper over that by making the .WHICH value take the mutable storage identity from the (internal) Scalar, still returning a "Pair|47804193992464" kind of value, and pretend that the Pairs were actually the same object. But one can just as well create two Pairs *with different keys* referencing the same value Scalar, in which case it's behaviourally visible that the two Pairs are different objects *and* that they share the value storage. So it is untenable to hold that it is the Pair itself that is mutable. The independent identity of a Scalar container is behaviourally detectable, even if the object is not directly visible to the language. > Scalar is >precisely the difference between immutable and mutable values. The rebinding that occurs in Pair.freeze (which I discussed in [perl #128955]) shows that the Pair class actually has some mutability of its own, independent of binding to a Scalar. So Scalar is certainly not the only way the language implements scalar mutability. There's some other form of difference between immutable and mutable. > It is the implementation of a >mutable value that can be used as a value; they are *not* general mutable >containers I'm having difficulty discerning what distinction you're making here. As best I can tell, your view is that the "implementation of a mutable value" is an inherently second-class concept. That would make it pretty much by definition a bad idea to reify it. This reasoning doesn't shed any light on the question of whether the language's main scalar containers should be reified. -zefram
