In Common Lisp, they are. In Scheme, they are not.
Mutable conses are useful because at least because values can be accumulated in a list from the end by retaining and mutating the tail.
However, the presence of mutable conses detracts from a language's ability to support FP, since it must be done by convention and with much copying.
I see Clojure's innovation in this area not in the fact that its lists are immutable (Scheme did this already) but in the fact that its lists are immutable and there's never a need to mutate the tail, because lazy sequences are supported throughout the language. The icing on the top of the story is that concrete lists and lazy sequences both inhabit the "Seq abstraction", and so don't require different APIs most of the time.
Of course, I'm pretty sure lazy sequences existed before CL was standardized (they're in SICP), but I can imagine how the designers would have preferred a simple, well-known tool (mutable conses) over admitting a whole other sequence abstraction. Plus, immutable conses would have been a breaking change.
So, it's not that anything that Clojure does with regard to lists couldn't have been done before, just that it wasn't -- while also being packaged in a vehicle that was wildly compelling for many other unrelated reasons.
Most of the time Lisp implements these data structures themselves - many/most Lisps are largely implemented in itself. As such Lisp exposes and provides very low-level data structures like conses, which are simply two element cells. Basically Lisp here is on the level of assembler - which is reflected that the historical name CAR means something like 'contents of the address register'.
Clojure's persistent immutable sequences are a very different data structure. Clojure does not expose its implementation and the implementation does not easily map to hardware, especially since quite a bit of the language is implemented in terms of the JVM and the Java language.
Example:
https://github.com/clojure/clojure/blob/master/src/jvm/cloju...
1> (take 12 (range 1))
(1 2 3 4 5 6 7 8 9 10 11 12)
2> (let ((r (range 1)))
(inc [r 4] 15)
(take 12 r))
(1 2 3 4 20 6 7 8 9 10 11 12)
Remember, mutate responsibly; if you mutate, don't derive.
Even if someone has been mutating "harmless" local variables, do not jump into the same lexical scope with them.
I'm well aware of the techniques, just not the word.
Interestingly, they were aware of the connection between their work and Lisp:
"The node-copying method of Section 2 can be modified so that it is write-once except for access pointers. The main modification is to handle inverse pointers as discussed in Section 3. The write-once property is important for certain kinds of memory technology. Also, it implies that any data structure of constant bounded in-degree that can be built using the augmented LISP primitives cons, cdr, replaca, and replacd can be simulated in linear time using only the pure LISP primitives cons, car, and cdr. Thus the result sheds light on the power of purely applicative programming languages."
Or, rather, it seems they were made aware by a reviewer:
"We thank Nick Pippenger for noting the connection between write-once data structures and the power of pure LISP."
(Good old Nick didn't go as far as to point out that rplaca and rplacd can introduce cycles, which cannot be constructed with cons over existing structure.)
Sadly, no reviewer similarly piped up about "persistent" being taken already for durable storage.
What language are you referencing here?
>> only abstraction is a linked list
> What language are you referencing here?
They are referring to Lisp.