| > Common Lisp does an absolutely crap job of making these things actually consistent from the point of view of the user Common Lisp provides a decently designed sequences abstraction which allows the encapsulated vectors and traditional unencapsulated lists, as well as strings, to be manipulated not just similarly, but by exactly the same code. This was developed in recognition of the exactly the issue that you are getting at. Forty years ago, the group of people designing Common Lisp were aware of this desire to have a consistent access method for different kinds of sequences and they did something about it. The charge of "absolutely crap job" can only be fairly leveled at a language that make no effort to provide for uniform treatment of encapsulated vectors and unencapsulated lists. What looks "surprising" depends on your background. I agree that Lisp contains surprises for someone who has programming experience, but that experience is limited to Python or Javascript which provide only encapsulated arrays as the principal sequence aggregation mechanism. I had two decades of programming experience coming to Lisp, and had written C programs which used both unencapsulated lists: list_node *list = NULL;
and I had written code with encapsulated ones: list_block list = LIST_EMPTY_INITIALIZER(list); // eg circular, expanding to { &list, &list }
leveraging the advantages of both.So, I wasn't surprised in any way. From the description of NIL and the cons cell linkage in the book I was reading, I instantly recognized it instantly as the unencapsulated style of lists, like "list_node *list = NULL". In C, it would be obvious that this can't work: list_node *list = NULL;
list_append(list, list_node_new(42));
// wrongly expecting list to have changed from NULL to non-null!
but that, with an encapsulating list block object instead of a raw pointer to a node, this could work: list_block *list = list_new();
list_append(list, list_node_new(42));
(Because C does not provide either of these, you can't blame the language for misunderstanding anything: only yourself, if you wrote that list yourself, or the library author.)I remember that was intriguing to me how Lisp is getting away with the unencapsulated single linkage for everything: like how that is the list structure for the entire language. In the light of the functional programming (you can always just keep consing up new conses to transform lists) together with the garbage collection, it very soon clicked for me. I remember thinking that if we could just keep mallocing new nodes and not worry about freeing, that would be pretty nice to work with in C. |