On Feb 16, 2013, at 1622 , Blake McBride blake@arahant.com wrote:
I'd like to add that there are many high quality and free lisp systems available. The thing that makes ABCL uniquely interesting is its close association to Java. It gives ABCL a much better ability to leverage off of the existing technology (libraries) built in Java. While focusing on ABCL's reliability and conformance to standards is very important, I wouldn't loose sight of where the attraction really is. If the main attraction to ABCL for lisp programmers is its tight integration to Java, than the degree of ABCL's appeal will be directly related to the ease and power of its integration to Java.
Just to clarify the aims of Armed Bear Common Lisp from my standpoint:
We aim to make ABCL a conforming, performant ANSI Common Lisp implementation as the platform upon we experiment, developing easier Java integration as we iterate through usage and feedback. This goal is currently (mostly[^1]) reflected in how ABCL is packaged: abcl.jar contains the core conforming ANSI implementation, whereas abcl-contrib.jar contains the goodies which make working with Java quite a bit easier. With features that are specific to the hosting JVM, such as allowing CL:PATHNAME to refer to URIs or treating java.util.List descendants as a user extensible sequence, we have striven to use existing extension methods as much as possible to follow the "principle of least surprise".
As such, we believe we offer the best of both worlds. As a first-class Common Lisp implementation which runs on the JVM, ABCL benefits from the contemporary Lisp ecosystem of cross-implementation libraries exemplified as those distributed via Quicklisp. In addition to contemporary advances, by stressing core conformance, we allow applications and research developed decades ago, such as MACSYMA, to be able to be run in new environments, for new purposes.
As our community contributes new ideas to making working with Java easier such as JSS and JFLI, we will attempt to include them in ABCL-CONTRIB.
And, as always, implementation is the sincerest form of flattery.
[^1]: "mostly" because the system obviously needs to have some hooks into Java as its implementation language, which form the basis of the symbols in the JAVA package, and to some extent SYSTEM and EXTENSIONS. The user-extensible collections for java sequences in JAVA-COLLECTIONS are sort of a historical exception to this "rule" as well.
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."