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

stephane ducasse stephane.ducasse at gmail.com
Thu Jun 10 05:54:39 UTC 2010


+ 1 
I think that having immutability can let people experiment for real.

Stef
On Jun 10, 2010, at 5:16 AM, Eliot Miranda wrote:

> 
> 
> On Wed, Jun 9, 2010 at 7:15 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
> 
> On 6/9/2010 5:15 PM, Eliot Miranda wrote:
>    The issue isn't "implementing" deep immutability, the issue is
>    "proving" that something is deeply immutable.
> 
> 
> The issue is of course both.  How one implements deep immutability /is/
> a worthy topic of discussion (as this thread demonstrates) and not
> something that can be condescended away by shifting levels.
> 
> Obviously. But what I was trying to point out is that the problem doesn't arise when it comes to constructing an immutable object graph (i.e., "implementing" deep immutability) but that the issues arise when you need to ensure that what you're passing along is in fact deep-frozen. Might have been bad terminology on my part.
> 
>    2) Traverse the object graph to prove deep immutability.
> 
> Option 2 can be written in Smalltalk without a data structure to record
> the visited set by provisionally setting the immutability bit to
> terminate the recursion, unsetting it if the attempt to freeze
> substructure failed.
> 
> Further, option 2 can be implemented at instance creation time so a root
> object is only instantiated if all its parts are immutable and an
> attempt to do otherwise fails.  If one has to prove that an object is
> immutable after instantiation something is wrong.  The framework should
> support maintaining immutability throughout an object's lifetime.
> 
> So trivially shallow immutability can implement deep immutability if a
> system provides no way to turn-off shallow immutability once on and if
> an object is created shallowly immutable but having only immutable
> substructure.  The issue then becomes when to allow immutability to be
> temporarily rescinded, e.g. for instance mutation on class redefinition.
> 
> All of this is exactly right, but now you're making my point ;-)
> I'm *asking* for that level of support of immutability. Are we perhaps a little confused as to what "policy" means in this context? To me it means what I can build in the image with the semantics that are provided by the VMs implementation and primitives. And I can currently *not* reliably build what you describe above with the means provided (simply due to the fact that one can nilly-willy change the immutability bit on any object one likes). However, if you consider primitives part of the policy then indeed one could do that by ripping out the existing set of prims and replacing them with others.
> 
> The primitive to turn-off immutability is a problem and needs a proper control mechanism (handwaving towards mirrors).  This is problematic and I just accept it because that's the status quo in current Smalltalk implementations. Its exactly like instVarAt:put:, which allows one to do dreadful damage willy-nilly to almost every object, but in practice doesn't because we use it very carefully.  Likewise turning immutability off.  Until we work out a good way of doing this handling the primitive using asbestos gloves is the only way I know.
> 
> Now with that limitation acknowledged and accepted is what we van built out of the immutability facilities useful?  I think so.  There are still other limitations; we've no way to safely pass immutable objects out to foreign code (although we could presumably check validity, at some expense, by taking a copy or for byte objects, a hash before passing the object); we're reliying on plugins to be written correctly to respect immutability.  But in the "do 95% of the job" "don't let the perfect be the enemy of the good" house style I'd rather have something imperfect than nothing.
> 
> 
> 
> BTW, for the records, I think I do see your point here. I think what you're saying is that regardless of how/when immutability is turned on for objects, the VM (plugin) support is useful to have since it provides a basic layer which makes utilizing immutability in various contexts possible. Thus, even though we might argue a couple of years about whether there should be a prim for turning immutability off or not, it shouldn't stop us from allowing the VM to trip over an object that has in fact been marked immutable. I do agree with that reasoning.
> 
> Good.  That's always my perspective as a VM engineer.  I don't pretend to be a language designer.  I believe more in (ok, am more able at) getting one's hands dirty playing and exploring than in preconceiving a perfect solution.  When someone does conceive of the perfect solution I'll happily do my best to implement it efficiently :)  As soon as there's a model of mirror use that provides a secure VM I'll adopt it, etc, etc.  I think this is also house style.  Look at the absence of unwind-protect and the complete lack of safety in Semaphore>>critical: in Smalltalk-80 V2.  Thankfully no one put designing the language above getting useful things done.
> 
> 
>    But in what applications? I suspect that the answer is "object
>    databases, object databases, and ... err ... object databases" ;-)
> 
>    (not that I'm saying that object databases aren't useful or
>    important but I suspect this particular use of immutability is not
>    remotely as general in practice as people seem to imply - and if I'm
>    wrong, I'm looking forward to learning something new here)
> 
> 
> You've already discussed a broad use category in introducing concurrency
> above.  Another broad category is being able to pass by value in a
> distributed system.  Another is providing immutable literals.  None of
> these are to do with OODBs.
> 
> Well we're hypothesizing about some uses here. They haven't been implemented. What I've been wondering is how immutability in those systems has been *actually* used and in particular whether (m)any non-db apps or uses were amongst them.
> 
> 
> In VW there's a Modification Management framework that supports
> attaching modification behaviours to specific objects.  By default an
> attempt to modify an object is an error (except by the class builder).
> Managers attached to specific objects can handle modification errors
> in various ways depending on the application.  Above that you implement
> what you want, including GemStone's persistence framework.
> 
> Thanks. Any other known uses for this outside persistence (which is the "database" category) and immutable literals?
> 
> Not to my knowledge, but I've been away from VW for a while now.  I hope someone's used it for more.  I think the distributed object scenario is a good one and might conceivably fit well with Croquet.
>  
> 
> Cheers,
>  - Andreas
> 
> cheers,
> Eliot 
> 



More information about the Vm-dev mailing list