> a "I hate parens" Lisp-1
Clojure's minimal syntax is, in my opinion, a gigantic improvement over Common Lisp. And I say this as a person who quite likes parens. I feel similarly about Lisp-1s, but that is well trotted territory: Lisp-1s have won.
Parens are overloaded in traditional Lisps for both invocation and grouping. The introduction of vectors with square brackets makes a lot of code a great deal more readable at virtually zero cost: It's still homoiconic. Similarly, the inclusion of curly braces for maps is wonderful, as it makes maps a lot more common in Clojure than they would otherwise be in CL, which is a good thing for most business logic.
> replicatable in CL as a library
Defaults matter. A lot. Presence in a library is insufficient. The fact that seqs et al are in core means that 100% of Clojure libraries use those abstractions. That's a big deal.
> I don't understand why the libraries and macros to create similarly compelling interop over ABCL weren't developed instead
Rich discussed this on the CL mailing lists long before Clojure or even his first attempt, dotLisp, ever existed. See [1] and [2]. In short, interop needs to be planned for at the lowest levels to make it pleasant to use and efficient to execute. And it's not just JVM interop: Clojure was designed for $SOME_HOST interop, so ClojureScript interops as nicely with JavaScript as Clojure does with the JVM. CL would have two different libraries with two different ideas of interop for two different host platforms.
> I don't know why Clojure was created as a new language
I think you have a different definition of the word "language" than I do. Look at PG's Arc. It's built on a scheme implementation. It's not so much a new language by your definition as it is a set of scheme libraries. But that's what a language is: A common base vocabulary encoded with a well known set of syntax and semantics rules. Clojure could be implemented (quite trivially, thanks to the aforementioned careful hosting design) as a set of libraries to CL, but it would still be a new language.
[1] https://groups.google.com/d/msg/comp.lang.lisp/3-X76dTw8dI/I... [2] https://groups.google.com/d/msg/comp.lang.lisp/3-X76dTw8dI/s...
Snippet from [2]:
If one were starting from scratch,
and supplied a platform like .NET, would one define Lisp the way CL is
defined?
I would hope the answer is 'most definitely not'. For instance, .NET
provides for numbers, characters, strings, arrays, hashtables, exceptions,
namespaces, files, streams, user-defined types, a type hierarchy and
inheritance, I/O, object creation and initialization, reflection etc. Should
a language define its own incompatible versions of these things in such an
environment?