[Vm-dev] Re: Immutability, newspeak (was: Vm-dev post from jbaptiste.arnaud@gmail.com requires approval)

[Andreas Raab]

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).

Cheers,
   - Andreas