[armedbear-devel] Seamless ABCL / Java integration proposal

[Mark Evenson]

On Feb 16, 2013, at 1622 , Blake McBride <blake at 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."