On 23/03/2009, at 12:32 AM, Stéphane Ducasse wrote: >> Green threads make some underlying implementation details easier, but >> at the language level the difference they make is determined by the >> interleaving guarantees they provide, and the extent to which the >> user >> can take advantage of those guarantees e.g. the yield-point model. >> >> IMO the solution to concurrency is not to simply add native threads - >> it also requires a more functional type of programming, and that can >> be largely provided by immutable data structures and more powerful >> abstractions, such as those provided in Clojure. > > can you illustrate that point?
Immutable data makes concurrency easier because you avoid concurrent modification and eliminate synchronisation issues. Clojure adds data types with specific concurrency semantics. Here's some exposition: http://clojure.org/concurrent_programming > Another question I would love to have immutability bit for pharo. > Now if you have immutable collection then I imagine that > - you should copy them when you want to modify them (functional) That happens automatically. Modification operations are functional e.g. f(data) -> data' data' is a different object than data, which remains unchanged. Efficiently implementing this is the key, but it's been done. > - I was wondering if the object that you put such immutable data > structure should > also be immutable Not necessarily - in the case of Clojure you might put a Ref/Var/Atom/ Agent into an immutable structure, and those objects have their own concurrency semantics as described in the link above. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Borrow money from pessimists - they don't expect it back. -- Steven Wright _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
