That's not really news. Lisp was always trying to support functional programming, but it was not enforcing it - though in some parts of the language non-pure functional programming is slightly difficult to avoid.
What Common Lisp did first in Lisp was that it took the lexical binding first/always idea, explored in Scheme, and integrated it into Lisp. Different from Scheme, Common Lisp kept the support for dynamic binding directly in the language and still made use of it in the language. Closures already existed in the precursors of Common Lisp, but as a separate construct (see for example the support in Lisp Machine Lisp).
Common Lisp also defined that lexical binding had to work both for the interpreter and the compiler - whereas in precursors of Common Lisp the Interpreter usually implemented dynamic binding by default and the compiler implemented lexical binding. Scheme in its standard did not mention compilation/interpretation and their effects - though it was expected that both, interpreters and compilers, use the same semantics.
What Common Lisp does, both in the language and in its library, is to support a form of programming with functions, first class functions, higher-order functions. Implementations also support TCO, which enables a more functional style of control flow. Libraries then explore lazy streams (see for example the chapter on Series in CLtL2 from 1990) and similar concepts.
Common Lisp was always a hybrid language supporting multiple paradigms out-of-the-box: symbolic programming, imperative/procedural programming, meta-syntactic programming, reflective programming, object-oriented programming, non-pure functional programming, meta-object-oriented programming. More complete implementations/applications add various forms of logic programming, rule-based programming, concurrent/parallel programming, visual-programming, ...
The
I know a lot of what you're saying, but you presented it in a contrarian mode. Like you were trying to make something clear. But your post doesn't illuminate anything except perhaps some trivia acquired in our shared history.
My only conclusion is that you were eager to talk about this but not to have a conversation about it. Perhaps in the future, placing it higher up the comment hierarchy will get you want you want.
Lisps in general have always been what now is sometimes called "impure functional programming languages"; until fairly recently, it wasn't really all that common to equate pure functional languages with "real" functional languages, it seems to me that is used to be that a "real functional language" was one that had reasonable ergonomic support for programming in the functional paradigm, not one that supported only the functional paradigm.
What tipped you off? Was it setq, or perhaps nconc or delete?
For me, it was tagbody. I was like, "go ? Okay, this is still a functional language, but now way can I call it truly functional."
I will leave discourse about the degree of purity that grants a "truly" moniker to people with more free time, but I suspect it's counter-productive.
My take is that Common Lisp was never really truly a functional language. It has always been a hybrid language that focused on the unique aspects of Lisp first, and everything else second. Lisp's focus on superior macro facilities, the CLOS, and the MOP really shows in the spec. CL primitives were never as concerned about general composability as they were about offering syntax to cover every conceivable case.
To some extent, I miss this philosophy. Meta-syntactic programming is something important and fundamental to language (as opposed to the monadic style of haskell which is more fundamental to computation).