     This manual is part of ABCL.  ABCL is licensed under the terms of the GPL v2 of June 1991 with the ``classpath-exception'' (see the file COPYING in the source distribution for the license, term 13 in the same file for the classpath exception).  This license broadly means that you must distribute the sources to ABCL, including any changes you make, together with a program that includes ABCL, but that you are not required to distribute the sources of the whole program.  Submitting your changes upstream to the ABCL development team is actively encouraged and very much appreciated, of course.

abcl
****

Introduction
************

Armed Bear Common Lisp (ABCL) is an implementation of Common Lisp that runs on the Java Virtual Machine.  It compiles Common Lisp to Java 5 bytecode, providing the following integration methods for interfacing with Java code and libraries:

  * Lisp code can create Java objects and call their methods.  See Calling from Lisp to Java.

  * Java code can call Lisp functions and generic functions, either directly (see Calling from Java to Lisp) or via JSR-223 (see Java Scripting API (JSR-223)).

  * jinterface-implementation creates Lisp-side implementations of Java interfaces that can be used as listeners for Swing classes and similar.

ABCL is supported by the Lisp library manager QuickLisp (http://quicklisp.org/) and can run many of the programs and libraries provided therein out-of-the-box.

Conformance
===========

ABCL aims to be be a fully conforming ANSI Common Lisp implementation. Any other behavior should be reported as a bug.  ABCL is currently a (non)-conforming ANSI Common Lisp implementation due to the following known issues:

  * The generic function signatures of the DOCUMENTATION symbol do not match the specification.

  * The TIME form does not return a proper VALUES environment to its caller.

  * When merging pathnames and the defaults point to a JAR-PATHNAME, we set the DEVICE of the result to :UNSPECIFIC if the pathname to be be merged does not contain a specified DEVICE, does not contain a specified HOST, does contain a relative DIRECTORY, and we are not running on a MSFT Windows platform. (The intent of this rather arcane sounding deviation from conformance is so that the result of a merge won't fill in a DEVICE with the wrong "default device for the host" in the sense of the fourth paragraph in the CLHS description of MERGE-PATHNAMES (see the paragraph beginning "If the PATHNAME explicitly specifies a host and not a device..."). A future version of the implementation may return to conformance by using the HOST value to reflect the type explicitly.)

Somewhat confusingly, this statement of non-conformance in the accompanying user documentation fulfills the requirements that ABCL is a conforming ANSI Common Lisp implementation according to the Common Lisp HyperSpec.  Clarifications to this point are solicited.

Contemporary Common Lisp
------------------------

In addition to ANSI conformance, ABCL strives to implement features expected of a contemporary Common Lisp, i.e. a Lisp of the post-2005 Renaissance.

The following known problems detract from ABCL being a proper contemporary Common Lisp.

  * An incomplete implementation of interactive debugging mechanisms, namely a no-op version of STEP, no support for inspecting local variables in a given call frame, and no support for resuming a halted computation at an arbitrarily selected call frame.

  * Incomplete streams abstraction, in that ABCL needs suitable abstraction between ANSI and Gray streams.  The streams could be optimized to the JVM NIO abstractions at great profit for binary byte-level manipulations.

  * Incomplete documentation (missing docstrings from exported symbols and the draft status of this user manual).

Contributors
============

  * Philipp Marek (Thanks for the markup)

  * Douglas Miles (Thanks for the whacky IKVM stuff and for keeping the flame alive in the dark years)

  * Alan Ruttenberg (Thanks for JSS)

  * and of course Peter Graves

Running ABCL
************

ABCL is packaged as a single jar file usually named either abcl.jar or possibly something like abcl-1.1.0.jar if using a versioned package on the local filesystem from your system vendor.  This jar file can be executed from the command line to obtain a REPL (Read-Eval Print Loop, a Lisp command-line), viz:

     cmd$ java -jar abcl.jar

N.b. for the proceeding command to work, the java executable needs to be in your path.

To facilitate the use of ABCL in tool chains such as SLIME, the Superior Lisp Interaction Mode for Emacs, we provide both a Bourne shell script and a DOS batch file.  If you or your administrator adjusted the path properly, ABCL may be executed simply as:

     cmd$ abcl

Probably the easiest way of setting up an editing environment using the Emacs editor is to use QuickLisp and follow the instructions at http://www.quicklisp.org/beta/#slime.

Options
=======

ABCL supports the following command line options:

--help
     displays a help message.

--noinform
     Suppresses the printing of startup information and banner.

--noinit
     suppresses the loading of the ~/.abclrc startup file.

--nosystem
     suppresses loading the system.lisp customization file.

--eval FORM
     evaluates FORM before initializing the REPL.

--load FILE
     loads the file FILE before initializing the REPL.

--load-system-file FILE
     loads the system file FILE before initializing the REPL.

--batch
     evaluates forms specified by arguments and in the initialization file ~/.abclrc, and then exits without starting a REPL.

All other command line arguments, as well as all arguments following the occurrence of a double hyphen (--) are passed unprocessed into a list of strings accessible via the variable EXT:*COMMAND-LINE-ARGUMENT-LIST* from within ABCL.

 -- Variable: *command-line-argument-list*
     This variable contains a (possibly empty) list of command-line arguments.  Any arguments that were processed already (e.g., --load FILE) are removed from this list.

Initialization
==============

If the ABCL process is started without the --noinit flag, it attempts to load a file named .abclrc in the user's home directory and then interpret its contents.

The user's home directory is determined by the value of the JVM system property user.home.  This value may or may not correspond to the value of the HOME system environment variable, at the discretion of the JVM implementation that ABCL finds itself hosted upon.

Interaction with Java
*********************

ABCL is a Common Lisp implementation hosted on a Java Virtual Machine. This chapter describes the mechanisms by which the implementation interacts with that hosting mechanism.  This interactions can go in two directions: Lisp-to-Java and Java-to-Lisp.

Calling from Lisp to Java
=========================

ABCL offers a number of mechanisms to interact with Java from its Lisp environment. It allows calling both instance and static methods of Java objects, manipulation of instance and static fields on Java objects, and construction of new Java objects.

When calling Java routines, some values are automatically converted from Lisp values to Java values.  These conversions apply to strings, integers and floats.  Other values need to be converted to their Java equivalents by the programmer before calling the Java object method. Java values returned to Lisp are also converted back to their Lisp counterparts.  If this conversion is not desired, certain Lisp-to-Java functions have ``raw'' counterparts which do not perform any conversion. These are recognizable by their name ending with -RAW.

This section covers the low-level Lisp-to-Java API of ABCL. Functions in this section are available after evaluating (require 'JAVA).  A higher level Java API, developed by Alan Ruttenberg, is available in the contrib/ directory and described later in this document, see JSS.

Creating Java objects
---------------------

Java objects can be created from Lisp by calling a constructor from the class of the object to be created.  The JAVA:JCONSTRUCTOR primitive is used to acquire a constructor reference.

 -- Function: jconstructor (class-ref &rest parameter-class-refs)
     Returns a reference to the Java constructor of CLASS-REF accepting the given PARAMETER-CLASS-REFS.  If PARAMETER-CLASS-REFS is a single integer, the first method with the given number of parameters is returned instead.

The obtained constructor can be passed as an argument to JAVA:JNEW, together with any arguments.  JAVA:JNEW can also be invoked with a string naming the class as its first argument.

 -- Function: jnew (constructor &rest args)
     Creates a new Java object by invoking CONSTRUCTOR with arguments ARGS.  CONSTRUCTOR can be a constructor reference or a string naming a class.

Accessing Java object and class fields
--------------------------------------

Fields in Java objects can be accessed using the getter and setter functions JAVA:JFIELD and (SETF JAVA:JFIELD).  Static (class) fields are accessed the same way, but with a class object or string naming a class as first argument.

Like JAVA:JCALL and friends, values returned from these accessors carry an intended class around, and values which can be converted to Lisp values will be converted.

 -- Function: jfield (class-ref-or-field field-or-instance
     &optional instance value)

     Retrieves or modifies a field in a Java class or instance.

     Supported argument patterns:

     class-ref  field-name
          Retrieve the value of static field FIELD-NAME of class CLASS-REF.

     class-ref  field-name  instance-ref
          Retrieves the value of a class field of the instance.

     class-ref  field-name  primitive-value:
          Stores PRIMITIVE-VALUE in static field FIELD-NAME.

     class-ref  field-name  instance-ref  value
          Stores VALUE in a class field of the instance.

     class-ref  field-name  nil  value
          Stores value in a static field (when value may be confused with an instance-ref).

     field-name  instance
          Retrieves the value of a field of the instance. The class is derived from the instance.

     field-name  instance  value
          Stores value in a field of the instance. The class is derived from the instance.

Calling Java Methods
--------------------

Methods on a java object method in the low-level (basic) API can be called in two ways:

  * Calling a specific method reference (which was previously acquired)

  * Dynamic dispatch using the method name and the call-specific arguments provided by finding the best match (see Parameter matching for FFI dynamic dispatch).

 -- Function: jmethod (class-ref method-name &rest parameter-class-refs)
     Returns a reference to the Java method METHOD-NAME of CLASS-REF accepting the given PARAMETER-CLASS-REFS.  If PARAMETER-CLASS-REFS is a single integer, the first method with the given number of parameters is returned instead.

     The function java:jmethod is used to acquire a specific method reference.  Its first argument is a Java class designator (a java:java-class object returned by java:jclass or a string naming a Java class). The second argument is a string naming the method.

     Any arguments beyond the first two should be strings naming Java classes, with one exception as listed in the next paragraph. These classes specify the types of the arguments for the method.

     When java:jmethod is called with three parameters and the last parameter is an integer, the first method by that name and matching number of parameters is returned.

Once a method reference has been acquired, it can be invoked using java:jcall, which takes the method as the first argument. The second argument is the object instance to call the method on, or NIL in case of a static method.  Any remaining parameters are used as the remaining arguments for the call.

 -- Function: jcall (method instance &rest args)
 -- Function: jcall-raw (method instance &rest args)
     Invokes the Java method METHOD on INSTANCE with arguments ARGS.  METHOD can be a method reference acquired via jmethod or a string naming a method.  The -raw version does not attempt to coerce the arguments or result into a Lisp object.

Calling Java Static Methods
---------------------------

Like non-static methods, references to static (class) methods can be acquired by using the java:jmethod primitive. Static methods are called with java:jstatic instead of java:jcall.

 -- Function: jstatic (method class &rest args)
 -- Function: jstatic-raw (method class &rest args)
     Invoke the static method METHOD on class CLASS with ARGS.  The -raw version does not attempt to coerce the arguments or result into a Lisp object.

Like java:jcall, java:jstatic supports dynamic dispatch by passing the name of the method as a string instead of passing a method reference.  The parameter values should be values to pass in the function call instead of a specification of classes for each parameter.

Parameter matching for FFI dynamic dispatch
-------------------------------------------

The algorithm used to resolve the best matching method given the name and the arguments' types is the same as described in the Java Language Specification. Any deviation should be reported as a bug.

Dynamic dispatch: Caveats
.........................

Dynamic dispatch, i.e., invoking a Java method via method name instead of method reference, is performed by using the Java reflection API. Generally the dispatch works fine, but there are corner cases where the API does not correctly reflect all the details involved in calling a Java method.  An example is the following Java code:

     ZipFile jar = new ZipFile("/path/to/some.jar");
     Object els = jar.entries();
     Method method = els.getClass().getMethod("hasMoreElements");
     method.invoke(els);

Even though the method hasMoreElements() is public in Enumeration, the above code fails with

     java.lang.IllegalAccessException: Class ... can
     not access a member of class java.util.zip.ZipFile\$2 with modifiers
     "public"
            at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
            at java.lang.reflect.Method.invoke(Method.java:583)
            at ...

This is because the method has been overridden by a non-public class and the reflection API, unlike javac, is not able to handle such a case.

While code like that is uncommon in Java, it is typical of ABCL's FFI calls. The code above corresponds to the following Lisp code:

     (let* ((jar (jnew "java.util.zip.ZipFile" "/path/to/some.jar"))
            (els (jcall "entries" jar)))
       (jcall "hasMoreElements" els))

except that the dynamic dispatch part is not shown.

To avoid such pitfalls, all Java objects in ABCL carry an extra field representing the ``intended class'' of the object. That class is used first by JAVA:JCALL and similar to resolve methods; the actual class of the object is only tried if the method is not found in the intended class. Of course, the intended class is always a super-class of the actual class -- in the worst case, they coincide. The intended class is deduced by the return type of the method that originally returned the Java object; in the case above, the intended class of ELS is java.util.Enumeration because that is the return type of the entries method.

While this strategy is generally effective, there are cases where the intended class becomes too broad to be useful. The typical example is the extraction of an element from a collection, since methods in the collection API erase all types to Object. The user can always force a more specific intended class by using the JAVA:JCOERCE operator.

Implementating Java interfaces in Lisp
--------------------------------------

ABCL can use the Java reflection-based proxy feature to implement Java interfaces in Lisp. It has several built-in ways to implement an interface, and supports definition of new ones. The JAVA:JMAKE-PROXY generic function is used to make such proxies.

 -- Generic Function: jmake-proxy interface implementation
     &optional lisp-this

     Returns a proxy Java object implementing the provided interface(s) using methods implemented in Lisp - typically closures, but implementations are free to provide other mechanisms.

     interface is a Java interface metaobject (e.g. obtained by invoking jclass), or a string naming a Java interface. implementation is the object used to implement the interface -- several built-in methods of jmake-proxy exist for various types of implementations.  lisp-this is an object passed as first argument to the functions implementing the Lisp ``methods'' of the interface, and defaults to NIL.

     The IMPLEMENTATION argument can be of type:

     function
          The given function will be called with two or more arguments (method name, LISP-THIS, method arguments if applicable) upon any method invocation on the proxy object.  Useful for interfaces with a single method, or to implement custom interface-implementation strategies.

     hash-table

          The Java interface method names are used as keys in the given hash table to obtain the functions implementing them.  Functions will be called with one or more arguments (LISP-THIS, method arguments if applicable).

     package
          The Java interface method names are mapped to symbols in package. A method called javaMethodName is mapped to a Lisp symbol JAVA-METHOD-NAME. An error is signaled if no such symbol exists in the package, or if the symbol exists but does not name a function.  Functions will be called with one or more arguments (LISP-THIS, method arguments if applicable).

The returned proxy is an instance of the interface, with methods implemented with Lisp functions, and can be passed to Java methods expecting an instance of the given interface.

Implementation of Java classes in Lisp
--------------------------------------

 -- Function: jnew-runtime-class (class-name &rest args
     &key (superclass java.lang.Object) interfaces
     constructors methods fields (access-flags '(public))
     annotations)

     Creates and loads a Java class with methods calling Lisp closures as given in METHODS.  CLASS-NAME and SUPER-NAME are strings, INTERFACES is a list of strings, CONSTRUCTORS, METHODS and FIELDS are lists of constructor, method and field definitions, respectively.

     Constructor definitions - currently NOT supported - are lists of the form (argument-types function &optional super-invocation-arguments) where ARGUMENT-TYPES is a list of strings and FUNCTION is a lisp function of (1+ (length argument-types)) arguments; the instance (this) is passed in as the last argument. The optional SUPER-INVOCATION-ARGUMENTS is a list of numbers between 1 and (length argument-types), where the number K stands for the Kth argument to the just defined constructor.  If present, the constructor of the superclass will be called with the appropriate arguments.  E.g., if the constructor definition is (("java.lang.String" "int") #'(lambda (string i this) ...)  (2 1)) then the constructor of the superclass with argument types (int, java.lang.String) will be called with the second and first arguments.

     Method definitions are lists of the form (method-name return-type argument-types function &key modifiers annotations) where METHOD-NAME is a string, RETURN-TYPE and ARGUMENT-TYPES are strings or keywords for primitive types (:void, :int, etc.), and FUNCTION is a Lisp function of minimum arity (1+ (length argument-types)); the instance (this) is passed in as the first argument.

     Field definitions are lists of the form (field-name type &key modifiers annotations).

Calling from Java to Lisp
=========================

This section describes the various ways that one interacts with Lisp from Java code.  In order to access the Lisp world from Java, one needs to be aware of a few things, the most important ones being listed below:

  * All Lisp values are descendants of LispObject.

  * Lisp symbols are accessible either via static members of the Symbol class, or by dynamically introspecting a Package object.

  * The Lisp dynamic environment may be saved via LispThread.bindSpecial(Binding) and restored via LispThread.resetSpecialBindings(Mark).

  * Functions can be executed by invoking LispObject.execute(args [...])

Acquiring an Interpreter Object
-------------------------------

The entire ABCL Lisp system resides in the org.armedbear.lisp package, but the following code snippets do not show the relevant import statements in the interest of brevity.  An example of the import statement would be

     import org.armedbear.lisp.*;

to potentially import all the JVM symbol from the org.armedbear.lisp namespace.

There can only ever be a single Lisp interpreter per JVM instance.  A reference to this interpreter is obtained by calling the static method Interpreter.createInstance().

     Interpreter interpreter = Interpreter.createInstance();

If this method has already been invoked in the lifetime of the current Java process it will return null, so if you are writing Java whose life-cycle is a bit out of your control (like in a Java servlet), a safer invocation pattern might be:

     Interpreter interpreter = Interpreter.getInstance();
     if (interpreter == null) {
       interpreter = Interpreter.createInstance();
     }

Evaluating Lisp Forms
---------------------

The Lisp eval primitive may simply be passed strings for evaluation:

     String line = "(load \"file.lisp\")";
     LispObject result = interpreter.eval(line);

Notice that all possible return values from an arbitrary Lisp computation are collapsed into a single return value.  Doing useful further computation on the LispObject depends on knowing what the result of the computation might be.  This usually involves some amount of instanceof introspection, and forms a whole topic to itself (see Introspecting a Lisp Object).

Using eval involves the Lisp interpreter.  Lisp functions may also be directly invoked by Java method calls as follows.  One simply locates the package containing the symbol, obtains a reference to the symbol, and then invokes the execute() method with the desired parameters.

     interpreter.eval("(defun foo (msg)" +
       "(format nil \"You told me '~A'~%\" msg))");
     Package pkg = Packages.findPackage("CL-USER");
     Symbol foo = pkg.findAccessibleSymbol("FOO");
     Function fooFunction = (Function)foo.getSymbolFunction();
     JavaObject parameter = new JavaObject("Lisp is fun!");
     LispObject result = fooFunction.execute(parameter);
     // How to get the "naked string value"?
     System.out.println("The result was " + result.writeToString());

Calling Common Lisp Functions Directly
--------------------------------------

If one is calling a function in the CL package, the syntax can become considerably simpler.  If we can locate the instance of definition in the ABCL Java source, we can invoke the symbol directly. For instance, to tell if a LispObject is (Lisp) NIL, we can invoke the CL function NULL in the following way:

     boolean nullp(LispObject object) {
       LispObject result = Primitives.NULL.execute(object);
       if (result == NIL) { // the symbol 'NIL' is explicitly named in the Java
                            // namespace at ``Symbol.NIL''
                            // but is always present in the
                            // local namespace in its unadorned form for
                            // the convenience of the User.
         return false;
       }
       return true;
     }

Introspecting a Lisp Object
---------------------------

We present various patterns for introspecting an arbitrary LispObject which can hold the result of every Lisp evaluation into semantics that Java can meaningfully deal with.

LispObject as boolean
.....................

If the LispObject is to be interpreted as a generalized boolean value, one can use getBooleanValue() to convert to Java:

     LispObject object = Symbol.NIL;
     boolean javaValue = object.getBooleanValue();

Since in Lisp any value other than NIL means "true", Java equality can also be used, which is a bit easier to type and better in terms of information it conveys to the compiler:

     boolean javaValue = (object != Symbol.NIL);

LispObject as a list
....................

If LispObject is a list, it will have the Java type Cons. One can then use the copyToArray method to make things a bit more suitable for Java iteration.

     LispObject result = interpreter.eval("'(1 2 4 5)");
     if (result instanceof Cons) {
       LispObject array[] = ((Cons)result.copyToArray());
       ...
     }

A more Lispy way to iterate down a list is to use the cdr() access function just as like one would traverse a list in Lisp:;

     LispObject result = interpreter.eval("'(1 2 4 5)");
     while (result != Symbol.NIL) {
       doSomething(result.car());
       result = result.cdr();
     }

Java Scripting API (JSR-223)
============================

ABCL can be built with support for JSR-223, which offers a language-agnostic API to invoke other languages from Java. The binary distribution from ABCL's homepage is built with JSR-223 support. If you are building ABCL from source on a pre-1.6 JVM, you need to have a JSR-223 implementation in your classpath (such as Apache Commons BSF 3.x or greater) in order to build ABCL with JSR-223 support; otherwise, this feature will not be built.

This section describes the design decisions behind the ABCL JSR-223 support. It is not a description of what JSR-223 is or a tutorial on how to use it. See http://trac.common-lisp.net/armedbear/browser/trunk/abcl/examples/jsr-223 for example usage.

Conversions
-----------

In general, ABCL's implementation of the JSR-223 API performs implicit conversion from Java objects to Lisp objects when invoking Lisp from Java, and the opposite when returning values from Java to Lisp. This potentially reduces coupling between user code and ABCL. To avoid such conversions, wrap the relevant objects in JavaObject instances.

Implemented JSR-223 interfaces
------------------------------

JSR-223 defines three main interfaces, of which two (Invocable and Compilable) are optional. ABCL implements all three interfaces - ScriptEngine and the two optional ones - almost completely. While the JSR-223 API is not specific to a single scripting language, it was designed with languages with a more or less Java-like object model in mind: languages such as Javascript, Python, Ruby, which have a concept of "class" or "object" with "fields" and "methods". Lisp is a bit different, so certain adaptations were made, and in one case a method has been left unimplemented since it does not map at all to Lisp.

The ScriptEngine object
.......................

The main interface defined by JSR-223, javax.script.ScriptEngine, is implemented by the class org.armedbear.lisp.scripting.AbclScriptEngine. AbclScriptEngine is a singleton, reflecting the fact that ABCL is a singleton as well. You can obtain an instance of AbclScriptEngine using AbclScriptEngineFactory or by using the service provider mechanism through ScriptEngineManager (refer to the javax.script documentation).

Start-up and configuration file
-------------------------------

At start-up (i.e. when its constructor is invoked, as part of the static initialization phase of AbclScriptEngineFactory), the ABCL script engine attempts to load an "init file" from the classpath (/abcl-script-config.lisp). If present, this file can be used to customize the behavior of the engine, by setting a number of variables in the ABCL-SCRIPT package. Here is a list of the available variables:

 -- Variable: *use-throwing-debugger*
     controls whether ABCL uses a non-standard debugging hook function to throw a Java exception instead of dropping into the debugger in case of unhandled error conditions.

     Its default value is T, since it is more convenient for Java programmers using Lisp as a scripting language to have it return exceptions to Java instead of handling them in the Lisp world.

     Known issues: the non-standard debugger hook has been reported to misbehave in certain circumstances, so consider disabling it if it doesn't work for you.

 -- Variable: *launch-swank-at-startup*
     If true, Swank will be launched at startup. See *swank-dir* and *swank-port*.  Default value: NIL.

 -- Variable: *swank-dir*
     The directory where Swank is installed. Must be set if *launch-swank-at-startup* is true.

 -- Variable: *swank-port*
     The port where Swank will listen for connections. Must be set if *launch-swank-at-startup* is true.  Default value: 4005

Additionally, at startup the AbclScriptEngine will execute (require 'asdf) - in fact, it uses asdf to load Swank.

Evaluation
----------

Code is read and evaluated in the package ABCL-SCRIPT-USER. This package uses the COMMON-LISP, JAVA and ABCL-SCRIPT packages. Future versions of the script engine might make thisf default package configurable. The CL:LOAD function is used under the hood for evaluating code, and thus the behavior of LOAD is guaranteed. This allows, among other things, IN-PACKAGE forms to change the package in which the loaded code is read.

It is possible to evaluate code in what JSR-223 calls a ``ScriptContext'' (basically a flat environment of name-to-value pairs). This context is used to establish special bindings for all the variables defined in it; since variable names are strings from Java's point of view, they are first interned using READ-FROM-STRING with, as usual, ABCL-SCRIPT-USER as the default package. Variables are declared special because CL's LOAD, EVAL and COMPILE functions work in a null lexical environment and would ignore non-special bindings.

Contrary to what the function LOAD does, evaluation of a series of forms returns the value of the last form instead of T, so the evaluation of short scripts does the Right Thing.

Compilation
-----------

AbclScriptEngine implements the javax.script.Compilable interface. Currently it only supports compilation using temporary files. Compiled code, returned as an instance of javax.script.CompiledScript, is read, compiled and executed by default in the ABCL-SCRIPT-USER package, just like evaluated code.  In contrast to evaluated code, though, due to the way the ABCL compiler works, compiled code contains no reference to top-level self-evaluating objects (like numbers or strings). Thus, when evaluated, a piece of compiled code will return the value of the last non-self-evaluating form: for example the code (do-something) 42 will return 42 when interpreted, but will return the result of (do-something) when compiled and later executed. To ensure consistency of behavior between interpreted and compiled code, make sure the last form is always a compound form -- at least (identity some-literal-object). Note that this issue should not matter in real code, where it is unlikely a top-level self-evaluating form will appear as the last form in a file (in fact, the Common Lisp load function always returns T upon success; with JSR-223 this policy has been changed to make evaluation of small code snippets work as intended).

Invocation of functions and methods
-----------------------------------

AbclScriptEngine implements the javax.script.Invocable interface, which allows to directly call Lisp functions and methods, and to obtain Lisp implementations of Java interfaces. This is only partially possible with Lisp since it has functions, but not methods -- not in the traditional OO sense, at least, since Lisp methods belong to generic functions. Thus, the method invokeMethod() is not implemented and throws an UnsupportedOperationException when called. The invokeFunction() method is used to call both regular and generic functions.

Creating Lisp interface proxies
-------------------------------

The functionality of jmake-proxy is exposed by the class AbclScriptEngine via the two methods getInterface(Class) and getInterface(Object, Class). The former returns an interface implemented with the current Lisp package, the latter allows the programmer to pass an interface-implementation object which will in turn be passed to the jmake-proxy generic function.

Implementation Dependent Extensions
***********************************

As outlined by the CLHS ANSI conformance guidelines, we document the extensions to the Armed Bear Lisp implementation made accessible to the user by virtue of being an exported symbol in the JAVA, THREADS, or EXTENSIONS packages.

Extensions in the JAVA package
==============================

Extensions in the THREADS package
=================================

The extensions for handling multithreaded execution are collected in the THREADS package.  Most of the abstractions in Doug Lea's excellent java.util.concurrent packages may be manipulated directly via the JSS contrib to great effect.

Extensions in the EXT package
=============================

The symbols in the EXTENSIONS package (nicknamed EXT) constitutes extensions to the ANSI standard that are potentially useful to the user.  They include functions for manipulating network sockets, running external programs, registering object finalizers, constructing reference weakly held by the garbage collector and others.

For a generic function interface to the native JVM contract for java.util.List, see Extensible Sequences.

Beyond ANSI
***********

Naturally, in striving to be a useful contemporary Common Lisp implementation, ABCL endeavors to include extensions beyond the ANSI specification which are either widely adopted or are especially useful in working with the hosting JVM.

Modifying the JVM Classpath
===========================

 -- Generic Function: add-to-classpath jar-or-jars
     &optional classloader

     The add-to-classpath generic functions allows one to add a pathname or list of pathnames to the current classpath used by ABCL, allowing the dynamic loading of JVM objects:

          (add-to-classpath "/path/to/some.jar")

     N.b add-to-classpath only affects the classloader used by ABCL (the value of the special variable java::*classloader*). It has no effect on Java code outside ABCL.

Compiler to Java 5 Bytecode
===========================

The CL:COMPILE-FILE interface emits a packed fasl format whose Pathname has the type abcl.  These fasls are operating system neutral byte archives packaged by the zip compression format which contain artifacts that are understood by CL:LOAD.

Pathnames
=========

We implement an extension to the CL:PATHNAME that allows for the description and retrieval of resources named in a URI (A URI is essentially a superset of what is commonly understood as a URL. We sometimes use the term URL as shorthand in describing the URL Pathnames, even though the corresponding encoding is more akin to a URI as described in RFC3986.) scheme that the JVM ``understands''.  By definition, support is built-in into the JVM to access the http:// and https:// schemes but additional protocol handlers may be installed at runtime by having JVM symbols present in the sun.net.protocol.dynamic package (see http://java.sun.com/developer/onlineTraining/protocolhandlers/ for more details).

ABCL has created specializations of the ANSI PATHNAME object to enable to use of URIs to address dynamically loaded resources for the JVM.  The EXT:URL-PATHNAME specialization has a corresponding URI whose canonical representation is defined to be the NAMESTRING of the Pathname. The EXT:JAR-PATHNAME extension further specializes the the EXT:URL-PATHNAME to provide access to components of zip and jar archives.

     @prefix ext:   <http://abcl.not.org/cl-packages/extensions/> .
     @prefix cl:    <http://abcl.not.org/cl-pacages/common-lisp/> .

     <ext:jar-pathname> a <ext:url-pathname>.
     <ext:url-pathname> a <cl:pathname>.
     <cl:logical-pathname> a <cl:pathname> .

 -- Built-In Class: url-pathname
 -- Built-In Class: jar-pathname

     url-pathname and jar-pathname are subclasses of the pathname built-in class.  Objects of type Ext:url-pathname and ext:jar-pathname may be used anywhere a cl:pathname is accepted with the following caveats:

       * A stream obtained via cl:open on a ext:url-pathname cannot be the target of write operations.

       * Any results of canonicalization procesures performed on the underlying URI are discarded between resolutions (i.e. the implementation does not attempt to cache the results of current name resolution of the representing resource unless it is requested to be resolved).  Upon resolution, any canoicalization procedures followed in resolving the resource (e.g., following redirects) are discarded.  Users may programatically initiate a new, local computation by applying the cl:truename function to a ext:url-pathname object. Depending on the reliablity and properties of your local REST infrastructure, these results may not necessarily be idempotent over time. See http://code.google.com/p/abcl-dynamic-install/source/browse/doc/design/pathnames/pathnames.tex for the draft of the publication of the technical details

The implementation of ext:url-pathname allows the ABCL user to dynamically load code from the network.  For example, Quicklisp may be completely installed from the REPL as the single form:

     CL-USER> (load "http://beta.quicklisp.org/quicklisp.lisp")

The implementation currently breaks ANSI conformance by allowing the types able to be cl:read for the DEVICE to return a possible cons of cl:pathname objects.

In order to ``smooth over'' the bit about types being cl:read from cl:pathname components, we extend the semantics for the usual PATHNAME merge semantics when *default-pathname-defaults* contains a ext:jar-pathname.

Implementation of Pathname Extensions
-------------------------------------

The implementation of these extensions stores all the additional information in the CL:PATHNAME object itself in ways that while strictly speaking are conformant, nonetheless may trip up libraries that don't expect the following:

  * DEVICE can be either a string denoting a drive letter under DOS, or a list of exactly one or two elements.  If DEVICE is a list, it denotes a EXT:JAR-PATHNAME, with the entries containing CL:PATHNAME objects which describe the outer and (possibly inner) locations of the jar archive. (The case of inner and outer EXT:EJAR-PATHNAME arises when zip archives themselves contain zip archives, which is the case when the ABCL fasl is included in the abcl.jar zip archive.)

  * An EXT:URL-PATHNAME always has a HOST component that is a property list.  The values of the HOST property list are always character strings.  The allowed keys have the following meanings:

     :SCHEME
          Scheme of URI ("http", "ftp", "bundle", etc.)

     :AUTHORITY
          Valid authority according to the URI scheme.  For "http" this could be "example.org:8080".

     :QUERY
          The query portion of the URI

     :FRAGMENT
          The fragment portion of the URI

In order to encapsulate the implementation decisions for these meanings, the following functions provide a setf-able API for reading and writing such values.

 -- Accessor: url-pathname-scheme
 -- Accessor: url-pathname-fragment
 -- Accessor: url-pathname-authority
 -- Accessor: url-pathname-query
     These functions and their setf form provide read and write access to the components of a url-pathname object.

The specific subtype of a Pathname may be determined with the predicates pathname-url-p and pathname-jar-p.

 -- Function: pathname-url-p object
 -- Function: pathname-jar-p object
     These predicates return T if OBJECT is a designator for a pathname of the specific type.  E.g.:

          (pathname-url-p "http://google.com/")
          => T

Package-Local Nicknames
=======================

ABCL allows giving packages local nicknames: they allow short and easy-to-use names to be used without fear of name conflict associated with normal nicknames. (Package-local nicknames were originally developed in SBCL.)

A local nickname is valid only when inside the package for which it has been specified. Different packages can use same local nickname for different global names, or different local nickname for same global name.

Symbol :package-local-nicknames in *features* denotes the support for this feature.

 -- Macro: defpackage name [[option]]* => package

     Options are extended to include

       * :local-nicknames (LOCAL-NICKNAME ACTUAL-PACKAGE-NAME)*

          The package has the specified local nicknames for the corresponding actual packages.

     Example:

          (defpackage :bar (:intern "X"))
          (defpackage :foo (:intern "X"))
          (defpackage :quux (:use :cl) (:local-nicknames (:bar :foo) (:foo :bar)))
          (find-symbol "X" :foo) ; => FOO::X
          (find-symbol "X" :bar) ; => BAR::X
          (let ((*package* (find-package :quux)))
            (find-symbol "X" :foo))               ; => BAR::X
          (let ((*package* (find-package :quux)))
            (find-symbol "X" :bar))               ; => FOO::X

 -- Function: package-local-nicknames (package-designator)

     Returns an alist of (local-nickname . actual-package) describing the nicknames local to the designated package.

     When in the designated package, calls to find-package with any of the local-nicknames will return the corresponding actual-package instead. This also affects all implied calls to find-package, including those performed by the reader.

     When printing a package prefix for a symbol with a package local nickname, the local nickname is used instead of the real name in order to preserve print-read consistency.

 -- Function: package-locally-nicknamed-by-list (package-designator)

     Returns a list of packages which have a local nickname for the designated package.

 -- Function: add-package-local-nickname (local-nickname actual-package &optional package-designator)

     Adds local-nickname for actual-package in the designated package, defaulting to current package. local-nickname must be a string designator, and actual-package must be a package designator.

     Returns the designated package.

     Signals an error if local-nickname is already a package local nickname for a different package, or if local-nickname is one of "CL", "COMMON-LISP", or, "KEYWORD", or if local-nickname is a global name or nickname for the package to which the nickname would be added.

     When in the designated package, calls to find-package with the local-nickname will return the package the designated actual-package instead. This also affects all implied calls to find-package, including those performed by the reader.

     When printing a package prefix for a symbol with a package local nickname, local nickname is used instead of the real name in order to preserve print-read consistency.

 -- Function: remove-package-local-nickname (old-nickname &optional package-designator)

     If the designated package had old-nickname as a local nickname for another package, it is removed. Returns true if the nickname existed and was removed, and nil otherwise.

Extensible Sequences
====================

See http://doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pdf for the design.

The SEQUENCE package fully implements Christophe Rhodes' proposal for extensible sequences.  These user extensible sequences are used directly in java-collections.lisp to provide these CLOS abstractions on the standard Java collection classes as defined by the java.util.List contract.

This extension is not automatically loaded by the implementation.   It may be loaded via:

     CL-USER> (require 'java-collections)

if both extensible sequences and their application to Java collections is required, or

     CL-USER> (require 'extensible-sequences)

if only the extensible sequences API is required.

Note that (require 'java-collections) must be issued before java.util.List or any subclass is used as a specializer in a CLOS method definition (see the section below).

Extensions to CLOS
==================

Metaobject Protocol
-------------------

ABCL implements the metaobject protocol for CLOS as specified in AMOP. The symbols are exported from the package MOP.

Contrary to the AMOP specification and following SBCL's lead, the metaclass funcallable-standard-object has funcallable-standard-class as metaclass instead of standard-class.

Specializing on Java classes
----------------------------

There is an additional syntax for specializing the parameter of a generic function on a java class, viz. (java:jclass CLASS-STRING) where CLASS-STRING is a string naming a Java class in dotted package form.

For instance, the following specialization would perhaps allow one to print more information about the contents of a java.util.Collection object:

     (defmethod print-object ((coll (java:jclass "java.util.Collection"))
                              stream)
       ;;; ...
     )

If the class had been loaded via a classloader other than the original the class you wish to specialize on, one needs to specify the classloader as an optional third argument.

     (defparameter *other-classloader*
       (jcall "getBaseLoader" cl-user::*classpath-manager*))

     (defmethod print-object
        ((device-id (java:jclass "dto.nbi.service.hdm.alcatel.com.NBIDeviceID"
                                 *other-classloader*))
         stream)
       ;;; ...
     )

Extensions to the Reader
========================

We implement a special hexadecimal escape sequence for specifying 32-bit characters to the Lisp reader, (This represents a compromise with contemporary in 2011 32bit hosting architecures for which we wish to make text processing efficient.  Should the User require more control over UNICODE processing we recommend Edi Weiz's excellent work with FLEXI-STREAMS which we fully support) namely we allow a sequences of the form #\Uxxxx to be processed by the reader as character whose code is specified by the hexadecimal digits xxxx.  The hexadecimal sequence may be one to four digits long.

Note that this sequence is never output by the implementation.  Instead, the corresponding Unicode character is output for characters whose code is greater than 0x00ff.

Overloading of the CL:REQUIRE Mechanism
=======================================

The CL:REQUIRE mechanism is overloaded by attaching the following semantic to the execution of REQUIRE on the following symbols:

ASDF

     Loads the ASDF implementation shipped with ABCL.  After ASDF has been loaded in this manner, symbols passed to CL:REQUIRE which are otherwise unresolved are passed to ASDF for a chance for resolution. This means, for instance, if CL-PPCRE can be located as a loadable ASDF system, (require 'cl-ppcre) is equivalent to (asdf:load-system 'cl-ppcre).

ABCL-CONTRIB
     Locates and pushes the toplevel contents of abcl-contrib.jar into the ASDF central registry, namely:

     abcl-asdf
          Functions for loading JVM artifacts dynamically, hooking into ASDF objects where possible.  See abcl-asdf.

     asdf-jar
          Package addressable JVM artifacts via abcl-asdf descriptions as a single binary artifact including recursive dependencies.

     mvn

          These systems name common JVM artifacts from the distributed pom.xml graph of Maven Aether, at the moment jna dynamically loads jna.jar version 3.5.1 from the network. (This loading can be inhibited if, at runtime, the Java class corresponding :classname clause of the system definition is present.)

 -- Variable: *module-provider-functions*
     The user may extend the cl:require mechanism by pushing function hooks onto this variable.  Each such hook function must take a single argument containing the symbol passed to cl:require and return a non-NIL value if it successfully resolved the symbol.

JSS optionally extends the Reader
=================================

The JSS contrib consitutes an additional, optional extension to the reader in the definition of the SHARPSIGN-DOUBLE-QUOTE (#") reader macro.  See JSS.

ASDF
====

ASDF is packaged as a core component of ABCL, but not initialized by default as it relies on the CLOS subsystem which can take a bit of time to start. (While this time is ``merely'' on the order of seconds for contemporary 2011 machines, for applications that need to initialize quickly, for example a web server, this time might be unnecessarily long)  The packaged ASDF may be loaded by the ANSI REQUIRE mechanism as follows:

     CL-USER> (require 'asdf)

Contrib
*******

The ABCL contrib is packaged as a separate jar archive usually named abcl-contrib.jar or possibly something like abcl-contrib-1.1.0.jar.  The contrib jar is not loaded by the implementation by default, and must be first intialized by the REQUIRE mechanism before using any specific contrib:

     CL-USER> (require 'abcl-contrib)

abcl-asdf
=========

This contrib enables an additional syntax for ASDF system definition which dynamically loads JVM artifacts such as jar archives via encapsulation of the Maven build tool.  The Maven Aether component can also be directly manipulated by the function associated with the ABCL-ASDF:RESOLVE-DEPENDENCIES symbol.

When loaded, abcl-asdf adds the following objects to ASDF: JAR-FILE, JAR-DIRECTORY, CLASS-FILE-DIRECTORY and MVN, exporting them (and others) as public symbols from the ASDF package.

Referencing Maven Artifacts via ASDF
------------------------------------

Maven artifacts may be referenced within ASDF system definitions.  The following example references the log4j-1.4.9.jar JVM artifact which provides a widely-used abstraction for handling logging systems:

     (in-package :asdf)

     (defsystem :log4j
       :components ((:mvn "log4j/log4j" :version "1.4.9")))

The abcl-asdf API
-----------------

We define an API for abcl-asdf as consisting of the following ASDF classes:

JAR-DIRECTORY, JAR-FILE, and CLASS-FILE-DIRECTORY for JVM artifacts that have a currently valid pathname representation.

Both the MVN and IRI classes descend from ASDF-COMPONENT, but do not directly have a filesystem location.

For use outside of ASDF system definitions, we currently define one method, ABCL-ASDF:RESOLVE-DEPENDENCIES which locates, downloads, caches, and then loads into the currently executing JVM process all recursive dependencies annotated in the Maven pom.xml graph.

Directly Instructing Maven to Download JVM Artifacts
----------------------------------------------------

Bypassing ASDF, one can directly issue requests for the Maven artifacts to be downloaded:

     CL-USER> (abcl-asdf:resolve-dependencies "com.google.gwt" "gwt-user")
     -| WARNING: Using LATEST for unspecified version.
     -| "/Users/evenson/.m2/repository/com/google/gwt/gwt-user/2.4.0-rc1
     -| /gwt-user-2.4.0-rc1.jar:/Users/evenson/.m2/repository/javax/vali
     -| dation/validation-api/1.0.0.GA/validation-api-1.0.0.GA.jar:/User
     -| s/evenson/.m2/repository/javax/validation/validation-api/1.0.0.G
     -| A/validation-api-1.0.0.GA-sources.jar"

To actually load the dependency, use the JAVA:ADD-TO-CLASSPATH generic function:

     CL-USER> (java:add-to-classpath
               (abcl-asdf:resolve-dependencies "com.google.gwt" "gwt-user"))

Notice that all recursive dependencies have been located and installed locally from the network as well.

asdf-jar
========

The asdf-jar contrib provides a system for packaging ASDF systems into jar archives for ABCL.  Given a running ABCL image with loadable ASDF systems the code in this package will recursively package all the required source and fasls in a jar archive.

The documentation for this contrib can be found at http://svn.common-lisp.net/armedbear/trunk/abcl/contrib/asdf-jar/README.markdown.

JSS
===

To one used to the more universal syntax of Lisp pairs upon which the definition of read and compile time macros is quite natural, (See Graham's ``On Lisp'' http://lib.store.yahoo.net/lib/paulgraham/onlisp.pdf.) the Java syntax available to the Java programmer may be said to suck.  To alleviate this situation, the JSS contrib introduces the SHARPSIGN-DOUBLE-QUOTE (#") reader macro, which allows the specification of the name of invoking function as the first element of the relevant s-expr which tends to be more congruent to how Lisp programmers seem to be wired to think.

While quite useful, we don't expect that the JSS contrib will be the last experiment in wrangling Java from Common Lisp.

JSS usage
---------

Example:

     CL-USER> (require 'abcl-contrib)
     => ("ABCL-CONTRIB")
     CL-USER> (require 'jss)
     => ("JSS")
     CL-USER) (#"getProperties" 'java.lang.System)
     => #<java.util.Properties {java.runtime.name=Java.... {2FA21ACF}>
     CL-USER) (#"propertyNames" (#"getProperties" 'java.lang.System))
     => #<java.util.Hashtable$Enumerator java.util.Has.... {36B4361A}>

Some more information on jss can be found in its documentation at http://svn.common-lisp.net/armedbear/trunk/abcl/contrib/jss/README.markdown

jfli
====

This contrib contains a pure-Java version of JFLI.

asdf-install
============

The asdf-install contrib provides an implementation of ASDF-INSTALL. This method of installing Lisp libraries is superseded by Quicklisp, which can be installed via (load "http://beta.quicklisp.org/quicklisp.lisp").

History
*******

ABCL was originally the extension language for the J editor, which was started in 1998 by Peter Graves.  Sometime in 2003, a whole lot of code that had previously not been released publically was suddenly committed that enabled ABCL to be plausibly termed an emergent ANSI Common Lisp implementation candidate.

From 2006 to 2008, Peter manned the development lists, incorporating patches as made sense.  After a suitable search, Peter nominated Erik Hülsmann to take over the project.

In 2008, the implementation was transferred to the current maintainers, who have strived to improve its usability as a contemporary Common Lisp implementation.

On October 22, 2011, with the publication of this Manual explicitly stating the conformance of Armed Bear Common Lisp to ANSI, we released abcl-1.0.0.  We released abcl-1.0.1 as a maintainence release on January 10, 2012.

In December 2012, we revised the implementation by adding (A)MOP with the release of abcl-1.1.0.

Colophon
********

This manual is maintained in Texinfo, and automatically translated into other forms (e.g. HTML or pdf). If you're reading this manual in one of these non-Texinfo translated forms, that's fine, but if you want to modify this manual, you are strongly advised to seek out a Texinfo version and modify that instead of modifying a translated version. Even better might be to seek out the Texinfo version (maintained at the time of this writing as part of the ABCL project at http://common-lisp.net/project/armedbear/) and submit a patch.