From the table of contents you can see that the language spec prominently describes: CLOS objects, structures (records), condition objects (-> errors), symbols, packages (namespaces for symbols), multi-dimensional arrays, strings, hash tables, files, streams, ...
None of these standard data structures are linked list based.
For example when I write a Lisp form do define a structure, a record-like data structure:
(defstruct packet
sender
receiver
header
payload)
then the SOURCE is an s-expression, a linked list.
DEFSTRUCT is a macro, which defines a record data structure and a bunch of functions for it (accessors, getters, creater, type predicate, ...).
The Lisp compiler will expand the macro form into a much larger s-expression -> again a nested list.
The compiler will then process lists and a lot of other data structures (see above) and create MACHINE CODE for code defined by above record definition.
Structures themselves are by default VECTOR-like objects, with static access into its components. A getter will access the fixed offset into a record and the code for that will usually be inlined in the using code.
So we have two aspects:
* processing with linked lists on current CPUs is several orders of magnitude faster, than on the machines where Lisp was originally defined. It does not matter for most use cases on modern machines. For example any Apple Silicon is great for running Lisp.
* Lisp offers many other data structures, which are widely used in Lisp applications.
For example if I would need a bit vector, I would not use a linked list of numbers, but a real bitvector:
CL-USER 1 > (describe #*0000010010000011000000000)
#*0000010010000011000000000 is a (SIMPLE-ARRAY (UNSIGNED-BYTE 1) (25))
CL-USER 2 > (sbit #*0000010010000011000000000 5)
; get the fifth bit, using zero-based indexing
1
Here the operations are written as lists, but they operate on real vectors of bits.
The result then is that optimizing Common Lisp compilers can generate code, which is fast enough for many applications.
So is in Common Lisp the linked list the "core data abstraction for your entire language"?
That's misleading. The "entire language" has many more data structures, which are not built on top of linked lists. For example arrays (strings, vectors, bitvectors, multidimensional arrays) are a part of the language, are widely used and are not made of linked lists.
You may want to check the Common Lisp standard (a dialect, where its development goes back to 1982).
https://www.lispworks.com/documentation/HyperSpec/Front/Cont...
From the table of contents you can see that the language spec prominently describes: CLOS objects, structures (records), condition objects (-> errors), symbols, packages (namespaces for symbols), multi-dimensional arrays, strings, hash tables, files, streams, ...
None of these standard data structures are linked list based.
For example when I write a Lisp form do define a structure, a record-like data structure:
then the SOURCE is an s-expression, a linked list.DEFSTRUCT is a macro, which defines a record data structure and a bunch of functions for it (accessors, getters, creater, type predicate, ...).
The Lisp compiler will expand the macro form into a much larger s-expression -> again a nested list.
The compiler will then process lists and a lot of other data structures (see above) and create MACHINE CODE for code defined by above record definition.
Structures themselves are by default VECTOR-like objects, with static access into its components. A getter will access the fixed offset into a record and the code for that will usually be inlined in the using code.
So we have two aspects:
* processing with linked lists on current CPUs is several orders of magnitude faster, than on the machines where Lisp was originally defined. It does not matter for most use cases on modern machines. For example any Apple Silicon is great for running Lisp.
* Lisp offers many other data structures, which are widely used in Lisp applications.
For example if I would need a bit vector, I would not use a linked list of numbers, but a real bitvector:
Here the operations are written as lists, but they operate on real vectors of bits.The result then is that optimizing Common Lisp compilers can generate code, which is fast enough for many applications.
So is in Common Lisp the linked list the "core data abstraction for your entire language"?
That's misleading. The "entire language" has many more data structures, which are not built on top of linked lists. For example arrays (strings, vectors, bitvectors, multidimensional arrays) are a part of the language, are widely used and are not made of linked lists.