grauzone wrote:
You probably mean that data shared between threads has to be immutable. Then all threads can access that data without synchronization. Immutability will sure be useful here: the type system guarantees, that data can never be modified. But how does this work for complex types like objects? Is there an idup for objects? Does it do a deep copy of an object graph? How is communication between threads supposed to work? Shouldn't all global variables be immutable then? Please, where can I find complete, thought-through concepts?
You cannot find them yet because the thinking-through process is still ongoing.
Does this approach fit D at all? D is a C based system programming language. Does it work to demand from everyone to obey the const rules? Couldn't all this be done manually, instead of bothering the programmer with a complex type system?
C is still having trouble removing those pesky buffer overruns. Writing a large manycore application in C will be anything but casual programming.
Sometimes, you have to leave the more spiffy features to languages like Erlang or Haskell which are suited better for this. For example, Erlang doesn't share any state by default, and in Haskell, everything is immutable. But they use very special mechanisms to make up for the problems caused by this, and that's why you can't just pick the cherries: it won't fit, it will feel unnatural, and everything will be a mess. It's a good idea to copy good features from other languages, but never forget where you come from.
We plan to add the necessary mechanisms.
Regarding pureness: I don't think it has anything do to with locking. A function could just take const arguments, and everything is safe. It can't write to shared data either, because shared data is supposed to be immutable, right? In this context, it doesn't matter if the function writes to anything else, because that data will be thread local.
Not all shared data is immutable. Data marked as "shared" is shared. The cool thing is that D switches the default to the "right" default.
The style of programming in which you create a new thread that joyously sees and can modify *all* of the memory space available to every other thread will go the way of the dinosaur. It's just not tenable anymore, and I predict today's mainstream programming languages abiding to that model are facing major troubles in the near future.
Andrei
