I don't consider it an extended Lisp, rather I just consider it a "batteries included", bundled library distribution of Lisp.
Common Lisp is still Common Lisp.
And I know it's a slippery slope.
Someone posted (here?) a list of the language changes to Java over the years.
And for something like Java, you "have" to "change the language" to get the results they wanted. Much of these changes could not have been done with just more classes in the JRE distributions. Whereas with CL, most of those things could have been done natively with just macros and functions, rather than having to update the core.
Of course, this is the Scheme story from day one, just with a much smaller core. But CL, due to the happenstance of the time of uniting several commercial efforts under one banner, has a larger core, but also, by definition, more opportunity for the actual compiler to be "better" with the higher level constructs it works with.
Contrived example being that Lisp "knows" about Structs and CLOS, whereas while you can add Structs (records) to Scheme, at a Scheme level you can only reduce them to the given Scheme primitives (vectors or lists), when the compiler finally sees the result, all it will see is a vector or list, with no knowledge of it actually being a struct (and thus can't potentially optimized for it).
If you want "native" structs, you need to actually extend the particular Scheme compiler.
So, anyway, the point being this is a nice package of libraries (it is, really, quite nice), all bundled into a single image. Batteries included.
But it's still CL at its core, there's nothing necessarily new there.
> Contrived example being that Lisp "knows" about Structs and CLOS, whereas while you can add Structs (records) to Scheme, at a Scheme level you can only reduce them to the given Scheme primitives (vectors or lists), when the compiler finally sees the result, all it will see is a vector or list, with no knowledge of it actually being a struct (and thus can't potentially optimized for it).
I don't know every single implementation of Scheme, but at least the Chez Scheme compiler has a lot of special code for records. The compiler sees them as records, tries to inline as many getters and setters as possible, and has low level support for the tree of subrecords and I may be missing a few more tricks. You can go to https://github.com/cisco/ChezScheme/blob/main/s/cp0.ss and Ctr+F record . For example https://github.com/cisco/ChezScheme/blob/main/s/cp0.ss#L3816...
The old implementation of Racket also had some tricks, but now the structs are transformed to Chez Scheme records.
Maybe that's why Chez is the most performant scheme.
I've heard people suggest that a more expanded scheme would become a ~lisp. "Common" lisp was formed as a moderately expansive standard for lisps of its time.
Common Lisp is still Common Lisp.
And I know it's a slippery slope.
Someone posted (here?) a list of the language changes to Java over the years.
And for something like Java, you "have" to "change the language" to get the results they wanted. Much of these changes could not have been done with just more classes in the JRE distributions. Whereas with CL, most of those things could have been done natively with just macros and functions, rather than having to update the core.
Of course, this is the Scheme story from day one, just with a much smaller core. But CL, due to the happenstance of the time of uniting several commercial efforts under one banner, has a larger core, but also, by definition, more opportunity for the actual compiler to be "better" with the higher level constructs it works with.
Contrived example being that Lisp "knows" about Structs and CLOS, whereas while you can add Structs (records) to Scheme, at a Scheme level you can only reduce them to the given Scheme primitives (vectors or lists), when the compiler finally sees the result, all it will see is a vector or list, with no knowledge of it actually being a struct (and thus can't potentially optimized for it).
If you want "native" structs, you need to actually extend the particular Scheme compiler.
So, anyway, the point being this is a nice package of libraries (it is, really, quite nice), all bundled into a single image. Batteries included.
But it's still CL at its core, there's nothing necessarily new there.