You seem to be very confused. This is referring to #'eq (which is why #'eql exists). What lack of compound values are you lamenting? Lisp has built in classes, structs, arrays, lists, and maps. What is missing?
> An implementation is permitted to make ``copies'' of characters and numbers at any time. The effect is that Common Lisp makes no guarantee that eq is true even when both its arguments are ``the same thing'' if that thing is a character or number.
Objects aren't compound values. Objects are compound, well, objects. And pointers to objects are primitive, indivisible values - not compound!
> lists
Racket and ML have lists. Lisp has mutable linked data structures, built out of `cons` cells, whose value at any given point in time may be a list. But the value itself isn't first-class, because you can only bind the identity of the cons cell to a variable.
I wasn't talking about the memory representation of anything. A first-class value is something that a variable may denote. In ML, if the variable `xs` denotes the list `[1,2,3]` within a given environment, it will always do so. In Lisp, I can mutate the cons cells out of which `(list 1 2 3)` is built, so what is actually bound to the variable is the object identity of the first `cons` cell. Not a list value!
I wanted to formulate my observation in very general terms, rather than mention specific facilities of other programming languages. I also wanted to avoid suggesting a connection with static types or effect segregation. The main benefit of values over objects is that using values leads to designs that have less moving parts, and thus are easier to understand, modify, extend and test.
> An implementation is permitted to make ``copies'' of characters and numbers at any time. The effect is that Common Lisp makes no guarantee that eq is true even when both its arguments are ``the same thing'' if that thing is a character or number.
http://www.lispworks.com/documentation/HyperSpec/Body/f_eq.h...