[Vm-dev] Re: Immutability,
newspeak (was: Vm-dev post from firstname.lastname@example.org
andreas.raab at gmx.de
Wed Jun 9 17:56:54 UTC 2010
On 6/9/2010 9:22 AM, Eliot Miranda wrote:
> It's much more general purpose than OODBs. Immutable literals and
> immutable numerics are very nice to have. Lazy copying in mutable
> structures is useful in general. A number of other dialects have an
> immutability bit and it has carried its weight there.
In what kinds of applications?
I have two major concerns about your arguments. One is that any kind of
"lazy copying" relies on a fast become which we don't have. So this
entire line of applications is probably moot as far as I can tell
(correct me if I'm wrong but I don't see how lazy copying can work
without fast become).
Secondly, for concurrency uses (which is the aspect that interests me
most) the "kind" of immutability proposed here is wrong. What's proposed
here is a one-level immutability which is really more a kind of write
barrier, i.e., it gets turned on, then it gets caught, then it gets
turned off, and is written to anyway. For concurrency, you need
immutability that is a) transitive (i.e., freezes an entire object
graph) and b) irreversible (i.e., sealing the object graph).
In terms of general applicability, I would much prefer the latter (it
matters not for immutable literals which kind is used) but I don't see
how these different forms of immutability can be reconciled without yet
another header bit. But if you're in favor of one, you can hardly be
against the other, no?
So should we add two header bits for immutability instead of one? What
concerns me here is that any use of immutability appears to be requiring
yet another header bit - a sign that we thoroughly do not understand
what immutability is and how it should be implemented. Thus my feeling
that throwing header bits at the problem is the wrong direction.
> In short, scarce resource issues such as header bits are solvable (by
> reimplementing to make more available), immutability is much more
> generally useful than OODB interfaces, so (at least form me) this is
> good use of something lying fallow.
I'm not strongly opposed to it but header bits *are* a scarce resource
so their allocation should be done carefully as well as the choice of
semantics. I can say for sure that I would feel *much* better if there
was a customer who'd say "yes, this is exactly what I need, the
semantics is precisely right for what I need it for" instead of just
"Oooooohhhh, immutability, cooooool" (which is all I'm hearing).
More information about the Vm-dev