I would argue that a significant number of people were attracted to Lisp\Scheme variants over the years because of the promise of functional programming and the theoretical advantages of being to design programs using functional principles.<p>The problem with your example is that evaluation of the expression performs a side effect on an internal machine specific to the implementation of Common Lisp, and that it is not a portable and abstract expression defining a return value.<p>Ideally we would be able to define a return value as a variable length sequence of constituent elements through recursive evaluation, where the process of evaluation is guaranteed to compactly allocate all of the constituent elements contiguously on the same location of the stack.<p>This would allow the runtime implementation to directly copy the contents of a value of an arbitrary size to a necessary output device, so long as the runtime had access to a portable and functional definition of the value to be copied.<p>Because the Lisp language family does not provide for this, there has been a need to continually invent new implementation variants which each model different internal machines for performing these tasks.