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

Eliot Miranda eliot.miranda at gmail.com
Thu Jun 10 03:16:47 UTC 2010


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100609/904ecab0/attachment.htm


More information about the Vm-dev mailing list