[Kessler83]

First of all, there are plenty of different data structures in Common Lisp. I don't know any Lisp resource that will tell you or encourage you to use lists for everything. For example, I think all the major Common Lisp books encourage you, explicitly, to use the advantages of different data structures.

Secondly, there is no contradiction between the usefulness of structs and the usefulness of nested lists and the ability to reach directly into them. But structs are no more a universal solution than lists are, so I don't know why you would be so hung up on them---in particular since we aren't discussing a particular use case.

I think the "unreadable monstrosity" thing in its various forms boils down to non-lispers not being used to car/cdr. That may be a fact, but it isn't an argument (and it takes about 5 mins to remedy).

[betterunix2]

Where are the search trees, heaps/priority queues, deques, and so forth in the Common Lisp standard? There are arrays, lists, associative lists, and hash tables, and a few scattered functions for manipulating trees of cons cells. Beyond that you are on your own, stuck either implementing textbook data structures and algorithms yourself or relying on third party libraries. Considering how well-developed the loop syntax and CLOS are, and even how many string manipulation functions are in the standard, I consider the lack of standardized data structures a pretty significant oversight.

I never said structs are a universal solution. It would make no sense to define lists using structs because lists already exist and are already useful as lists (and as stacks, which lists immediately give you). Sometimes a tree of cons cells works well and requires no further clarification. On the other hand, there are many cases where relying just on cons, car, cdr, and related functions results in hard-to-read, hard-to-change code. You are speaking of "usefulness" but I never doubted that you could get a working solution based on car/cdr, I said it is unreadable and I stand by that. You say that we are not talking about a specific use-case, but a function that accesses structured data in a very specific way without regard to any specific context or use-case screams "readability hazard."

Why should you dismiss someone who sees cdaddr and calls it an "unreadable monstrosity" as simply not knowing the language well enough? There is no need to get religious about a programming language. Common Lisp is a great language that I have been using for many years, both professionally and as my preferred language for personal projects. That does not mean that I should think everything in the language or everything that people commonly use are good ideas.

[kazinator]

A simple deque in the spirit of unencapsulated lists can be made in Common Lisp using two back-to back lists. So that is to say, each end of the deque is a Lisp list, where we chase cdr going toward the middle of the deque.

Only the pop operation has to know about the arrangement. We make it a macro which cleverly transfers nodes from one list to the other to keep the amortized cost low.

https://www.kylheku.com/cgit/lisp-snippets/tree/deque.lisp [oops, where are the test cases?]

> That does not mean that I should think everything in the language or everything that people commonly use are good ideas.

I, however, provide the "cadavers" down to one level deeper in TXR Lisp than Common Lisp, from caar to cdddddr. Therefore, I'm not in a position to turn around and disown them as a bad idea.

There are people genuinely invested in various aspects of this stuff.

[lispm]

you don't need them in the language standard. Common Lisp is an extensible language and you would use one of the libraries available.

> On the other hand, there are many cases where relying just on cons, car, cdr, and related functions results in hard-to-read, hard-to-change code.

That's why Common Lisp has structures and CLOS. One builds on top of those.