I imagine he means that pure programming can only address concurrency in some of the many areas of programming where we may wish to leverage some kind of concurrency. I personally see immutable state as an important fundamental building block to better concurrency support in languages, but certainly not the only building block.
One example of something which I would like to see is a linear type system for pointers to mutable data so that you can reference mutable shared state, but only one task/thread/function may access it at any one time and assigning or copying the pointer causes ownership to be transferred. I think this would be useful in a pipeline or dataflow system where the pipeline stages operate on a blob of memory directly, but its guaranteed that only one stage can ever access it at any one time. I guess its more or less an optimization on message passing immutable memory from stage to stage, so not exactly necessary, but still another building block I would like to see.
I'd also like to hear what Shapiro has in mind though.
so that you can reference mutable shared state, but only one task/thread/function may access it at any one time and assigning or copying the pointer causes ownership to be transferred
That sounds kind of like Rust's "unique pointers".
Yes, I think this is exactly Rust's unique pointers. Rust has a lot of interesting language features and is one of the up-and-coming languages I'm watching with interest.
Almost, but not quite. I'll quote a few key phrases from [1] to distinguish between what I want and transients, though I imagine in real life transients probably capture most use cases fairly well.
The second feature of transients is that creating one does not modify the source, and the source cannot be modified via use of the transient. Your source data is immutable and persistent as always.
Note in particular that transients are not designed to be bashed in-place.
The unique linear pointer would allow direct in-place mutation of the source. As it is guaranteed to be unique, no synchronization is needed. Transients do not modify in-place and do not allow you to mutate the source type directly, but allow you to add to the source and the added data is mutated directly for performance. There is a lot of overlap in use cases and transients are an excellent middle ground for Clojure, since it allows you to code against immutable types but with the performance benefits of partial mutation. The pointers I described would be less flexible in that you cannot have references to an immutable portion as you can in Clojure, but at the same time the owning code has completely mutable access.
In general, I love Clojures concurrency model and I don't think unique pointers would really mesh well with the rest of Clojure.
One example of something which I would like to see is a linear type system for pointers to mutable data so that you can reference mutable shared state, but only one task/thread/function may access it at any one time and assigning or copying the pointer causes ownership to be transferred. I think this would be useful in a pipeline or dataflow system where the pipeline stages operate on a blob of memory directly, but its guaranteed that only one stage can ever access it at any one time. I guess its more or less an optimization on message passing immutable memory from stage to stage, so not exactly necessary, but still another building block I would like to see.
I'd also like to hear what Shapiro has in mind though.