Indeed, it is possible to gain the guarantee of effective immutability
by considering outside concerns.
In general, though, if I write some code like
(if (instance? Cons x)
(pass-to-another-thread-without-synchronisation x))
I cannot guarantee the result of this because although I know that
the head of x is fixed, I cannot guarantee that for the tail. If I know
how x is constructed, of course, then I can make this guarantee.
You get the a related problem in Java.
List l = Collections.unmodifiedableList(l);
Is l now unmodifiable? Well maybe, depending on what happened to it
before.
The problem is that List does not specify behaviour. It can't, because
it's an interface.
Having said all of that, if any data structures constructed using only
functions from clojure.core are not effectively immutable and not
documented as such, then I guess this is a bug.
Phil
Mike Fikes <mikefi...@me.com> writes:
> Consider (def x (cons (new java.util.Date) ()))
>
> The object identified by x is *mutable*, but if the contained Date will not
> be modified by the program, then the resulting object can be treated as
> *effectively
> immutable, *as you pointed out.
>
> But, it would seem that you could pass x to another thread without
> synchronization, and then safely read the contained Date instance by that
> thread, because it has been safely published by virtue of having been
> conveyed by a final field of the Cons instance. Of course, you would run
> into trouble if you took that Date instance and passed it directly to
> another thread without synchronization.
>
> In other words, you could step outside of the limited profile of the Java
> memory model that JCIP prescribes treating x as something (useful) between
> *effectively
> immutable *and *immutable, *with the end result being that you can treat x as
> being *immutable.*
>
> On Wednesday, May 7, 2014 7:13:31 AM UTC-4, Phillip Lord wrote:
>>
>>
>> Since the data structures and interfaces, they are effectively
>> immutable.
>>
>> Consider this:
>>
>> final public class Cons extends ASeq implements Serializable {
>>
>> private final Object _first;
>> private final ISeq _more;
>>
>> public Cons(Object first, ISeq _more){
>> this._first = first;
>> this._more = _more;
>> }
>> }
>>
>> Although Cons uses final fields and constructor fields, "_more" is an
>> ISeq; given that this could be mutable, so could cons.
>>
>> Phil
>>
>> Mike Fikes <mike...@me.com <javascript:>> writes:
>>
>> > Are the persistent immutable data structures in Clojure "truly"
>> immutable
>> > (using final fields, relying on constructor freezing), or are they mean
>> to
>> > be merely effectively immutable (as defined in JICP)?
>>
>> --
>> Phillip Lord, Phone: +44 (0) 191 222 7827
>> Lecturer in Bioinformatics, Email:
>> philli...@newcastle.ac.uk<javascript:>
>> School of Computing Science,
>> http://homepages.cs.ncl.ac.uk/phillip.lord
>> Room 914 Claremont Tower, skype: russet_apples
>> Newcastle University, twitter: phillord
>> NE1 7RU
>>
--
Phillip Lord, Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,
http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower, skype: russet_apples
Newcastle University, twitter: phillord
NE1 7RU
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
