Front page | perl.perl5.porters |
Postings from July 2011
Re: Mutable constant-expression values
Thread Previous
|
Thread Next
From:
Zefram
Date:
July 22, 2011 06:24
Subject:
Re: Mutable constant-expression values
Message ID:
20110722132424.GL4069@lake.fysh.org
Aristotle Pagaltzis wrote:
>I.e. constants would be copied to a mutable SV at the point in
>time at which someone attempts to mutate them.
>
>Am I missing anything here?
You're missing how awful those semantics would be to use. With a mutable
object, it matters which object references in the program refer to the
same object, because a mutation of the object through one reference
must be visible in all the other places that reference the same object.
Suppose several things get a reference to one of these `constants', then
one of them `mutates' it. Under your semantics, the reference through
which the mutation happened gets changed to refer to the new mutable
object, and all the other refs to the constant still see the constant.
If the various references are now copied to new places, those derived
from the reference used for the mutation see the same mutable object, and
will share further mutations between them. Another pair of references,
resulting from the same kind of copying but without any mutation in
their history, will both see the `constant', but as soon as one of
them performs a mutation the references will diverge, seeing different
sets of mutations. The extent of sharing of a mutable-copy-of-constant
object will depend in a very fragile manner on the details of its early
mutation operations.
Also note that, since object references don't usually reseat themselves,
it's quite normal to mutate (or otherwise manipulate) an object
using a short-lived copy of a reference. Suppose one of these magic
mutation-of-a-constant things is performed via a function that creates
such a ref copy. Now it is the *short-lived copy of the reference*
that will be reseated, and the long-lived ref that you really intend
to reseat will continue to refer to the unmutated constant. Of course,
you can't programmatically tell which ref copies are intending to create
a new, subsequently-shared, mutable object, and which are intending to
refer to exactly the same object to which the original ref referred.
The language around copying refs just doesn't express this sort of
intention information, because the distinction is quite alien to the
operation of copying a ref.
There are two sane ways to go to get semantics a bit like what you're
suggesting. The first is that the program must explicitly indicate when
it wants to create a mutable copy of a constant. You can already do this,
of course, by, er, copying the constant. "my $copy = $constant" suffices.
Actual constants are still distinguished, and attempts to mutate them
can die as they do now. The second option is that the evaluation of a
constant expression implicitly creates a new mutable value immediately.
The extent to which the mutable copies are shared is then well defined:
there is one copy for each occasion on which the constant expression was
evaluated. You can already get this sort of effect by writing "(my $copy
= 10)" in place of "10"; doing that implicitly would be a core change.
Of course, this results in a lot of unnecessary copying that would be
bad for performance.
-zefram
Thread Previous
|
Thread Next