On 23/03/2009, at 12:32 AM, Stéphane Ducasse wrote: > can you illustrate that point?
It might be that Smalltalk and wide-spread immutability and fundamentally incompatible. The problem is that Smalltalk's model has Objects whose state changes in response to messages. Such state change breaks immutability. But if objects are immutable, then the problem is that after any mutation operation within a method, subsequent sends need to be not to self, but to the newly mutated object. This problem cascades, with the effective self needing to change potentially after every send. Maybe the solution is to enable that to happen seamlessly e.g. 'self' changes as the object mutates (because the object isn't actually mutating). Objects do make immutability-based concurrency more 'interesting'. It's important to note that Clojure is a rethinking of Lisp, and the end result is not Common Lisp + concurrency + Java interop. I suspect that a rethinking of Smalltalk would be similarly different than what we now know. This doesn't surprise me - out assumptions about concurrency, or the lack of it, and general inexperience with taming true concurrency, is a significant context the design of most existing languages, with notable exceptions such as CSP/Occam. Maybe the appropriate concurrency model for Smalltalk IS an ultra- lightweight fine-grained copy-on-write multiple image model, with that being the *only* threading abstraction. If you could control the separation e.g. share some objects with well defined concurrency semantics like Clojure such STM/Refs/Agents etc, then that might be the best fit. OTOH a shared-nothing model would give you CSP/Erlang. The implementation challenges are very different, and I must admit I don't know enough about Hydra to know if that project has solved this issue. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 He who would make his own liberty secure, must guard even his enemy from repression. -- Thomas Paine _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
