<br><br><div class="gmail_quote">On Wed, Jun 9, 2010 at 10:56 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On 6/9/2010 9:22 AM, Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's much more general purpose than OODBs. Immutable literals and<br>
immutable numerics are very nice to have. Lazy copying in mutable<br>
structures is useful in general. A number of other dialects have an<br>
immutability bit and it has carried its weight there.<br>
</blockquote>
<br></div>
In what kinds of applications?<br>
<br>
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).<br>
</blockquote><div><br></div><div>Here's a sketch of how to do this without a fast become. Any client of a lazily copied data structure puts an exception handler at some point around their ruse of the data structure. They catch the immutability exception and coordinate with the data structure to update their reference to the data to a copy So instead of the data structure managing things internally there's some sharing. Something like</div>
<div><br></div><div> [sink store: self data]</div><div> on: NoModificationError</div><div> do: [:ex|</div><div> (sink ownsImmutableIn: ex) ifFalse:</div><div> [ex pass].</div>
<div> sink := sink copyOnWrite ex.</div><div> ex retry]</div><div><br></div><div>THis kind of linkage is clumsy, which is why one constructs a per-object policy scheme where on can attach actions to attempts to update specific objects. In this approach sink (and any necessary substructure) would have been registered with some kind of policy object (an immutability manager) that would take case of sending messages to the client to get it to update its reference to sink and retry the operation. So with prior registration (which could be folded into the instance creation code for sink) the api then becomes</div>
<div><br></div><div> sink store: data</div><div><br></div><div>with the exception handling managed in the background.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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).<br>
</blockquote><div><br></div><div>That's fine and one can build deep immutability above the shallow immutability that the immutable bit provides. All one needs to do is traverse the object graph, setting the immutability bit. You might want to carefully control unsetting the immutability bit so that its hard to inadvertently turn off immutability in substructure to get b). But in any case turning off immutability on something that is immutable is never something that's done lightly.</div>
<div><br></div><div>I have at least discussed using shallow immutability to implement deep immutability with Gilad for Newspeak and he hasn't yet said it can't be done this way.</div><div><br></div><div>Note tat deep immutability is a tricky issue. Is the class of a deeply immutable object immutable or can one still add methods to it? What happens (with both shallow and deep immutability) if one tries to add an instance variable to a class that has immutable instances? What if one wants a mostly deeply immutable data structure that contains e.g. a mutable query cache that memos the most recent N results of some expensive query? Exactly what parts of a data structure should be immutable when is typically application and data structure dependent and some blanket deep immutability scheme in the VM is likely to be too inflexible. A simple per-object bit which has simple semantics and can serve in many different uses is flexible enough, at least if 15 years of experience with VisualAge and 10 years of experience with VW is meaningful.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">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?<br>
</blockquote><div><br></div><div>I don't see that at the VM level two header bits gains you anything. You're talking about a policy issue above the VM. One bit is all the VM needs to implement the necessary mechanism. Policy at the image level can then manage the immutability bit to provide myriad schemes.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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.</blockquote>
<div><br></div><div>Agreed. I'm not proposing throwing bits at the problem. One bit's enough. Its up to the image level to design a good framework around the basic VM facility, and that's been done already.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In short, scarce resource issues such as header bits are solvable (by<br>
reimplementing to make more available), immutability is much more<br>
generally useful than OODB interfaces, so (at least form me) this is<br>
good use of something lying fallow.<br>
</blockquote>
<br></div>
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).<br>
</blockquote><div><br></div><div>While some people might be saying "it's cool" I hear the GemStone folks saying "we much prefer using the immutability bit than rewriting code. the immutability bit has worked much better in practice", and GemStone has plenty of customers who don't have to worry about the issue because GemStone has done all the work for them. I don't hear anyone from VisualAge and VisualWorks saying "It's a bad idea, it's had a deleterious effect on performance". But there's a modicum of FUD here ;) (*)</div>
<div><br></div><div>(*) just joking</div><div><br></div><div>best,</div><div>Eliot</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
</font></blockquote></div><br>