% -*- mode: latex; -*- % http://en.wikibooks.org/wiki/LaTeX/ \documentclass[10pt]{book} \usepackage{abcl} \usepackage{hyperref} % Put this one last, it redefines lots of internals \begin{document} \title{Armed Bear Common Lisp User Manual} \date{Version 1.1.0-dev\\ \smallskip May 14, 2012} \author{Mark Evenson \and Erik H\"{u}lsmann \and Rudolf Schlatte \and Alessio Stalla \and Ville Voutilainen} \maketitle \tableofcontents \chapter{Introduction} Armed Bear Common Lisp (ABCL) is an implementation of Common Lisp that runs on the Java Virtual Machine. It compiles to Java bytecode and integrates with Java code and libraries in a seamless way: \begin{itemize} \item Lisp code can create Java objects and call their methods (see Section~\ref{sec:lisp-java}, page~\pageref{sec:lisp-java}). \item Java code can call Lisp functions and generic functions, either directly (Section~\ref{sec:calling-lisp-from-java}, page~\pageref{sec:calling-lisp-from-java}) or via \texttt{JSR-223} (Section~\ref{sec:java-scripting-api}, page~\pageref{sec:java-scripting-api}). \item \code{jinterface-implementation} creates Lisp-side implementations of Java interfaces that can be used as listeners for Swing classes and similar. \end{itemize} ABCL is supported by the Lisp library manager QuickLisp\footnote{\url{http://quicklisp.org/}} and can run many of the programs and libraries provided therein out-of-the-box. \section{Conformance} \label{section:conformance} \subsection{ANSI Common Lisp} \textsc{ABCL} is currently a (non)-conforming ANSI Common Lisp implementation due to the following known issues: \begin{itemize} \item The generic function signatures of the \code{DOCUMENTATION} symbol do not match the specification. \item The \code{TIME} form does not return a proper \code{VALUES} environment to its caller. \end{itemize} Somewhat confusingly, this statement of non-conformance in the accompanying user documentation fulfills the requirements that \textsc{ABCL} is a conforming ANSI Common Lisp implementation according to the Common Lisp HyperSpec~\cite{CLHS}. Clarifications to this point are solicited. ABCL aims to be be a fully conforming ANSI Common Lisp implementation. Any other behavior should be reported as a bug. \subsection{Contemporary Common Lisp} In addition to ANSI conformance, \textsc{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 \textsc{ABCL} being a proper contemporary Common Lisp. \begin{itemize} \item An incomplete implementation of interactive debugging mechanisms, namely a no-op version of \code{STEP} \footnote{Somewhat surprisingly allowed by \textsc{ANSI}}, the inability to inspect local variables in a given call frame, and the inability to resume a halted computation at an arbitrarily selected call frame. \item An incomplete implementation of a proper metaobject protocol (c.f. the (A)MOP specification~\cite{AMOP, AMOPspec}) \item Incomplete streams abstraction, in that \textsc{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. \item Incomplete documentation (missing docstrings from exported symbols and the draft status of this user manual). \end{itemize} \section{License} ABCL is licensed under the terms of the GPL v2 of June 1991 with the ``classpath-exception'' (see the file \texttt{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. \section{Contributors} \begin{itemize} \item Philipp Marek \texttt{Thanks for the markup} \item Douglas Miles \texttt{Thanks for the whacky IKVM stuff and keeping the flame alive in the dark years.} \item Alan Ruttenberg \texttt{Thanks for JSS.} \item and of course \emph{Peter Graves} \end{itemize} \chapter{Running ABCL} \textsc{ABCL} is packaged as a single jar file usually named either \texttt{abcl.jar} or possibly something like \texttt{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\footnote{Read-Eval Print Loop, a Lisp commandline}, viz: \begin{listing-shell} cmd$ java -jar abcl.jar \end{listing-shell} %$ unconfuse Emacs syntax highlighting \emph{N.b.} for the proceeding command to work, the \texttt{java} executable needs to be in your path. To facilitate the use of ABCL in tool chains such as SLIME~\cite{slime} (the Superior Lisp Interaction Mode for Emacs), we provide both a Bourne shell script and a \textsc{DOS} batch file. If you or your administrator adjusted the path properly, ABCL may be executed simply as: \begin{listing-shell} cmd$ abcl \end{listing-shell}%$ Probably the easiest way of setting up an editing environment using the Emacs editor is to use QuickLisp and follow the instructions at \url{http://www.quicklisp.org/beta/#slime}. \section{Options} ABCL supports the following command line options: \begin{description} \item[\texttt{--help}] displays a help message. \item[\texttt{--noinform}] Suppresses the printing of startup information and banner. \item[\texttt{--noinit}] suppresses the loading of the \verb+~/.abclrc+ startup file. \item[\texttt{--nosystem}] suppresses loading the \texttt{system.lisp} customization file. \item[\texttt{--eval FORM}] evaluates FORM before initializing the REPL. \item[\texttt{--load FILE}] loads the file FILE before initializing the REPL. \item[\texttt{--load-system-file FILE}] loads the system file FILE before initializing the REPL. \item[\texttt{--batch}] evaluates forms specified by arguments and in the intialization file \verb+~/.abclrc+, and then exits without starting a REPL. \end{description} All of the command line arguments following the occurrence of \verb+--+ are passed unprocessed into a list of strings accessible via the variable \code{EXT:*COMMAND-LINE-ARGUMENT-LIST*} from within ABCL. \section{Initialization} If the \textsc{ABCL} process is started without the \code{--noinit} flag, it attempts to load a file named \code{.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 \texttt{user.home}. This value may or may not correspond to the value of the \texttt{HOME} system environment variable, at the discretion of the JVM implementation that \textsc{ABCL} finds itself hosted upon. \chapter{Interaction with the Hosting JVM} % Plan of Attack % % describe calling Java from Lisp, and calling Lisp from Java, % probably in two separate sections. Presumably, we can partition our % audience into those who are more comfortable with Java, and those % that are more comforable with Lisp The Armed Bear Common Lisp implementation is hosted on a Java Virtual Machine. This chapter describes the mechanisms by which the implementation interacts with that hosting mechanism. \section{Lisp to Java} \label{sec:lisp-java} \textsc{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 will automatically be converted by the FFI\footnote{Foreign Function Interface, the term for the part of a Lisp implementation that implements calling code written in other languages.} from Lisp values to Java values. These conversions typically 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 generally converted back to their Lisp counterparts. Some operators make an exception to this rule and do not perform any conversion; those are the ``raw'' counterparts of certain FFI functions and are recognizable by their name ending with \code{-RAW}. \subsection{Low-level Java API} This subsection covers the low-level API available after evaluating \code{(require 'JAVA)}. A higher level Java API, developed by Alan Ruttenberg, is available in the \code{contrib/} directory and described later in this document, see Section~\ref{section:jss} on page \pageref{section:jss}. \subsubsection{Calling Java Object Methods} There are two ways to call a Java object method in the low-level (basic) API: \begin{itemize} \item Call a specific method reference (which was previously acquired) \item Dynamic dispatch using the method name and the call-specific arguments provided by finding the best match (see Section~\ref{sec:param-matching-for-ffi}). \end{itemize} \code{JAVA:JMETHOD} is used to acquire a specific method reference. The function takes two or more arguments. The first is a Java class designator (a \code{JAVA:JAVA-CLASS} object returned by \code{JAVA:JCLASS} or a string naming a Java class). The second 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 \code{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 \code{JAVA:JCALL}, which takes the method as the first argument. The second argument is the object instance to call the method on, or \code{NIL} in case of a static method. Any remaining parameters are used as the remaining arguments for the call. \subsubsection{Calling Java object methods: dynamic dispatch} The second way of calling Java object methods is by using dynamic dispatch. In this case \code{JAVA:JCALL} is used directly without acquiring a method reference first. In this case, the first argument provided to \code{JAVA:JCALL} is a string naming the method to be called. The second argument is the instance on which the method should be called and any further arguments are used to select the best matching method and dispatch the call. \subsubsection{Dynamic dispatch: Caveats} Dynamic dispatch is performed by using the Java reflection API \footnote{The Java reflection API is found in the \code{java.lang.reflect} package}. 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: \begin{listing-java} ZipFile jar = new ZipFile("/path/to/some.jar"); Object els = jar.entries(); Method method = els.getClass().getMethod("hasMoreElements"); method.invoke(els); \end{listing-java} Even though the method \code{hasMoreElements()} is public in \code{Enumeration}, the above code fails with \begin{listing-java} 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 ... \end{listing-java} This is because the method has been overridden by a non-public class and the reflection API, unlike \texttt{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: \begin{listing-lisp} (let ((jar (jnew "java.util.zip.ZipFile" "/path/to/some.jar"))) (let ((els (jcall "entries" jar))) (jcall "hasMoreElements" els))) \end{listing-lisp} except that the dynamic dispatch part is not shown. To avoid such pitfalls, all Java objects in \textsc{ABCL} carry an extra field representing the ``intended class'' of the object. That class is used first by \code{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 \code{ELS} is \code{java.util.Enumeration} because that is the return type of the \code{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 \code{Object}. The user can always force a more specific intended class by using the \code{JAVA:JCOERCE} operator. % \begin{itemize} % \item Java values are accessible as objects of type JAVA:JAVA-OBJECT. % \item The Java FFI presents a Lisp package (JAVA) with many useful % symbols for manipulating the artifacts of expectation on the JVM, % including creation of new objects \ref{JAVA:JNEW}, \ref{JAVA:JMETHOD}), the % introspection of values \ref{JAVA:JFIELD}, the execution of methods % (\ref{JAVA:JCALL}, \ref{JAVA:JCALL-RAW}, \ref{JAVA:JSTATIC}) % \item The JSS package (\ref{JSS}) in contrib introduces a convenient macro % syntax \ref{JSS:SHARPSIGN_DOUBLEQUOTE_MACRO} for accessing Java % methods, and additional convenience functions. % \item Java classes and libraries may be dynamically added to the % classpath at runtime (JAVA:ADD-TO-CLASSPATH). % \end{itemize} \subsubsection{Calling Java class static methods} Like non-static methods, references to static methods can be acquired by using the \code{JAVA:JMETHOD} primitive. Static methods are called with \code{JAVA:JSTATIC} instead of \code{JAVA:JCALL}. Like \code{JAVA:JCALL}, \code{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. \subsubsection{Parameter matching for FFI dynamic dispatch} \label{sec:param-matching-for-ffi} 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. % ###TODO reference to correct JLS section \subsubsection{Instantiating Java objects} Java objects can be instantiated (created) from Lisp by calling a constructor from the class of the object to be created. The \code{JAVA:JCONSTRUCTOR} primitive is used to acquire a constructor reference. It's arguments specify the types of arguments of the constructor method the same way as with \code{JAVA:JMETHOD}. The obtained constructor is passed as an argument to \code{JAVA:JNEW}, together with any arguments. \code{JAVA:JNEW} can also be invoked with a string naming the class as its first argument. \subsubsection{Accessing Java object and class fields} Fields in Java objects can be accessed using the getter and setter functions \code{JAVA:JFIELD} and \code{(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 \code{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. \section{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: \begin{itemize} \item All Lisp values are descendants of \code{LispObject}. \item Lisp symbols are accessible either via static members of the \code{Symbol} class, or by dynamically introspecting a \code{Package} object. \item The Lisp dynamic environment may be saved via \code{LispThread.bindSpecial(Binding)} and restored via \code{LispThread.resetSpecialBindings(Mark)}. \item Functions can be executed by invoking \code{LispObject.execute(args [...])} \end{itemize} \subsection{Calling Lisp from Java} \label{sec:calling-lisp-from-java} Note: the entire ABCL Lisp system resides in the \texttt{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 \begin{listing-java} import org.armedbear.lisp.*; \end{listing-java} 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 \code{Interpreter.createInstance()}. \begin{listing-java} Interpreter interpreter = Interpreter.createInstance(); \end{listing-java} If this method has already been invoked in the lifetime of the current Java process it will return \texttt{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: \begin{listing-java} Interpreter interpreter = Interpreter.getInstance(); if (interpreter == null) { interpreter = Interpreter.createInstance(); } \end{listing-java} The Lisp \code{eval} primitive may simply be passed strings for evaluation: \begin{listing-java} String line = "(load \"file.lisp\")"; LispObject result = interpreter.eval(line); \end{listing-java} Notice that all possible return values from an arbitrary Lisp computation are collapsed into a single return value. Doing useful further computation on the \code{LispObject} depends on knowing what the result of the computation might be. This usually involves some amount of \code{instanceof} introspection, and forms a whole topic to itself (see Section~\ref{topic:Introspecting a LispObject}, page~\pageref{topic:Introspecting a LispObject}). Using \code{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 \code{execute()} method with the desired parameters. \begin{listing-java} 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()); \end{listing-java} 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 \code{LispObject} is (Lisp) \texttt{NIL}, we can invoke the CL function \code{NULL} in the following way: \begin{listing-java} 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; } \end{listing-java} \subsubsection{Introspecting a LispObject} \label{topic:Introspecting a LispObject} We present various patterns for introspecting an arbitrary \code{LispObject} which can hold the result of every Lisp evaluation into semantics that Java can meaningfully deal with. \paragraph{LispObject as \code{boolean}} If the \code{LispObject} is to be interpreted as a generalized boolean value, one can use \code{getBooleanValue()} to convert to Java: \begin{listing-java} LispObject object = Symbol.NIL; boolean javaValue = object.getBooleanValue(); \end{listing-java} Since in Lisp any value other than \code{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: \begin{listing-java} boolean javaValue = (object != Symbol.NIL); \end{listing-java} \paragraph{LispObject as a list} If \code{LispObject} is a list, it will have the type \code{Cons}. One can then use the \code{copyToArray} method to make things a bit more suitable for Java iteration. \begin{listing-java} LispObject result = interpreter.eval("'(1 2 4 5)"); if (result instanceof Cons) { LispObject array[] = ((Cons)result.copyToArray()); ... } \end{listing-java} 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:; \begin{listing-java} LispObject result = interpreter.eval("'(1 2 4 5)"); while (result != Symbol.NIL) { doSomething(result.car()); result = result.cdr(); } \end{listing-java} \section{Java Scripting API (JSR-223)} \label{sec:java-scripting-api} ABCL can be built with support for JSR-223~\cite{jsr-223}, which offers a language-agnostic API to invoke other languages from Java. The binary distribution download-able from ABCL's homepage is built with JSR-223 support. If you're 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 \url{http://trac.common-lisp.net/armedbear/browser/trunk/abcl/examples/jsr-223} for example usage. \subsection{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 \code{JavaObject} instances. \subsection{Implemented JSR-223 interfaces} JSR-223 defines three main interfaces, of which two (\code{Invocable} and \code{Compilable}) are optional. ABCL implements all the three interfaces - \code{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. \subsubsection{The ScriptEngine} The main interface defined by JSR-223, \code{javax.script.ScriptEngine}, is implemented by the class \code{org.armedbear.lisp.scripting.AbclScriptEngine}. \code{AbclScriptEngine} is a singleton, reflecting the fact that ABCL is a singleton as well. You can obtain an instance of \code{AbclScriptEngine} using the \code{AbclScriptEngineFactory} or by using the service provider mechanism through \code{ScriptEngineManager} (refer to the \texttt{javax.script} documentation). \subsection{Start-up and configuration file} At start-up (i.e. when its constructor is invoked, as part of the static initialization phase of \code{AbclScriptEngineFactory}) the ABCL script engine attempts to load an "init file" from the classpath (\texttt{/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 \code{ABCL-SCRIPT} package. Here is a list of the available variables: \begin{description} \item[\texttt{*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. \begin{itemize} \item Default value: \texttt{T} \item Rationale: 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. \item 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. \end{itemize} \item[\texttt{*launch-swank-at-startup*}] If true, Swank will be launched at startup. See \texttt{*swank-dir*} and \texttt{*swank-port*}. \begin{itemize} \item Default value: \texttt{NIL} \end{itemize} \item[\texttt{*swank-dir*}] The directory where Swank is installed. Must be set if \texttt{*launch-swank-at-startup*} is true. \item[\texttt{*swank-port*}] The port where Swank will listen for connections. Must be set if \texttt{*launch-swank-at-startup*} is true. \begin{itemize} \item Default value: 4005 \end{itemize} \end{description} Additionally, at startup the AbclScriptEngine will \code{(require 'asdf)} - in fact, it uses asdf to load Swank. \subsection{Evaluation} Code is read and evaluated in the package \code{ABCL-SCRIPT-USER}. This packages \texttt{USE}s the \code{COMMON-LISP}, \code{JAVA} and \code{ABCL-SCRIPT} packages. Future versions of the script engine might make this default package configurable. The \code{CL:LOAD} function is used under the hood for evaluating code, and thus the behavior of \code{LOAD} is guaranteed. This allows, among other things, \code{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$\rightarrow$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 \code{READ-FROM-STRING} with, as usual, \code{ABCL-SCRIPT-USER} as the default package. Variables are declared special because CL's \code{LOAD}, \code{EVAL} and \code{COMPILE} functions work in a null lexical environment and would ignore non-special bindings. Contrary to what the function \code{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. \subsection{Compilation} AbclScriptEngine implements the \code{javax.script.Compilable} interface. Currently it only supports compilation using temporary files. Compiled code, returned as an instance of \texttt{javax.script.CompiledScript}, is read, compiled and executed by default in the \texttt{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 ``\code{(do-something) 42}'' will return 42 when interpreted, but will return the result of (do-something) when compiled and later evaluated. To ensure consistency of behavior between interpreted and compiled code, make sure the last form is always a compound form - at least \code{(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 \texttt{T} upon success; with JSR-223 this policy has been changed to make evaluation of small code snippets work as intended). \subsection{Invocation of functions and methods} AbclScriptEngine implements the \code{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 are not attached to objects but belong to generic functions. Thus, the method \code{invokeMethod()} is not implemented and throws an \texttt{UnsupportedOperationException} when called. The \code{invokeFunction()} method should be used to call both regular and generic functions. \subsection{Implementation of 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 \code{JAVA:JMAKE-PROXY} generic function is used to make such proxies. It has the following signature: \code{jmake-proxy interface implementation \&optional lisp-this ==> proxy} \code{interface} is a Java interface metaobject (e.g. obtained by invoking \code{jclass}) or a string naming a Java interface. \code{implementation} is the object used to implement the interface - several built-in methods of jmake-proxy exist for various types of implementations. \code{lisp-this} is an object passed to the closures implementing the Lisp "methods" of the interface, and defaults to \code{NIL}. The returned proxy is an instance of the interface, with methods implemented with Lisp functions. Built-in interface-implementation types include: \begin{itemize} \item a single Lisp function which upon invocation of any method in the interface will be passed the method name, the Lisp-this object, and all the parameters. Useful for interfaces with a single method, or to implement custom interface-implementation strategies. \item a hash-map of method-name $\rightarrow$ Lisp function mappings. Function signature is \code{(lisp-this \&rest args)}. \item a Lisp package. The name of the Java method to invoke is first transformed in an idiomatic Lisp name (\code{javaMethodName} becomes \code{JAVA-METHOD-NAME}) and a symbol with that name is searched in the package. If it exists and is fbound, the corresponding function will be called. Function signature is as the hash-table case. \end{itemize} This functionality is exposed by the class \code{AbclScriptEngine} via the two methods \code{getInterface(Class)} and \code{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 \code{jmake-proxy} generic function. \chapter{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. \section{JAVA} \subsection{Modifying the JVM CLASSPATH} The JAVA:ADD-TO-CLASSPATH generic functions allows one to add the specified pathname or list of pathnames to the current classpath used by ABCL, allowing the dynamic loading of JVM objects: \begin{listing-lisp} CL-USER> (add-to-classpath "/path/to/some.jar") \end{listing-lisp} N.b \code{ADD-TO-CLASSPATH} only affects the classloader used by ABCL (the value of the special variable \code{JAVA:*CLASSLOADER*}. It has no effect on Java code outside ABCL. % include autogen docs for the JAVA package. \include{java} \section{THREADS} The extensions for handling multithreaded execution are collected in the \code{THREADS} package. Most of the abstractions in Doug Lea's excellent \code{java.util.concurrent} packages may be manipulated directly via the JSS contrib to great effect. % include autogen docs for the THREADS package. \include{threads} \section{EXTENSIONS} The symbols in the EXTENSIONS package (nicknamed ``EXT'') constitutes extensions to the \textsc{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. See \cite{RHODES2007} for a generic function interface to the native \textsc{JVM} contract for \code{java.util.List}. % include autogen docs for the EXTENSIONS package. \include{extensions} \chapter{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 \textsc{JVM}. \section{Compiler to Java 5 Bytecode} The \code{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 whose loading \code{CL:LOAD} understands. \section{Pathname} We implement an extension to the Pathname that allows for the description and retrieval of resources named in a \textsc{URI} \footnote{A \textsc{URI} is essentially a superset of what is commonly understood as a \textsc{URL} We sometimesuse 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 \cite{rfc3986}.} scheme that the \textsc{JVM} ``understands''. Support is built-in to comprehend the ``http'' and ``https'' implementations but additional protocol handlers may be installed at runtime by having \textsc{JVM} symbols present in the sun.net.protocol.dynamic pacakge. See \cite{maso2000} for more details. \textsc{ABCL} has created specializations of the ANSI Pathname object to enable to use of \textsc{URI}s to address dynamically loaded resources for the JVM. A \code{URL-PATHNAME} has a corresponding \textsc{URI} whose canonical representation is defined to be the \code{NAMESTRING} of the Pathname. % \begin{verbatim} # RDF description of type hierarchy % TODO Render via some LaTeX mode for graphviz? a . a . a . \end{verbatim} \label{EXTENSIONS:URL-PATHNAME} \index{URL-PATHNAME} \label{EXTENSIONS:JAR-PATHNAME} \index{JAR-PATHNAME} Both \code{EXT:URL-PATHNAME} and \code{EXT:JAR-PATHNAME} may be used anywhere a \code{CL:PATHNAME} is accepted with the following caveats: \begin{itemize} \item A stream obtained via \code{CL:OPEN} on a \code{CL:URL-PATHNAME} cannot be the target of write operations. \index{URI} \item No canonicalization is performed on the underlying \textsc{URI} (i.e. the implementation does not attempt to compute the current name of the representing resource unless it is requested to be resolved.) Upon resolution, any cannoicalization procedures followed in resolving the resource (e.g. following redirects) are discarded. Users may programatically initiate a new, local computation by applying the \code{CL:TRUENAME} function to a \code{EXT:URL-PATHNAME} object. Depending on the reliablity and properties of your local \textsc{REST} infrastructure, these results may not necessarily be idempotent over time\footnote {See \cite{evenson2011} for the draft of the publication of the technical details}. \end{itemize} The implementation of \code{EXT:URL-PATHNAME} allows the \textsc{ABCL} user to dynamically load code from the network. For example, Quicklisp (\cite{quicklisp}) may be completely installed from the REPL as the single form: \begin{listing-lisp} CL-USER> (load "http://beta.quicklisp.org/quicklisp.lisp") \end{listing-lisp} will load and execute the Quicklisp setup code. %See \ref{_:quicklisp} on page \pageref{_:quicklisp}. \subsubsection{Implementation} The implementation of these extensions stores all the additional information in the PATHNAME object itself in ways that while strictly speaking are conformant, nonetheless may trip up libraries that don't expect the following: \begin{itemize} \item \code{DEVICE} can be either a string denoting a drive letter under DOS or a list of exactly one or two elements. If \code{DEVICE} is a list, it denotes a \code{JAR-PATHNAME}, with the entries containing \code{PATHNAME} objects which describe the outer and (possibley) locations of the jar archive. \item A \code{URL-PATHNAME} always has a \code{HOST} component that is a property list. The values of the \code{HOST} property list are always character strings. The allowed keys have the following meanings: \begin{description} \item[:SCHEME] Scheme of URI ("http", "ftp", "bundle", etc.) \item[:AUTHORITY] Valid authority according to the URI scheme. For "http" this could be "example.org:8080". \item[:QUERY] The query of the \textsc{URI} \item[:FRAGMENT] The fragment portion of the \textsc{URI} \end{description} \item In order to encapsulate the implementation decisions for these meanings, the following functions provide a setf-able API for reading and writing such values: \code{URL-PATHNAME-QUERY}, \code{URL-PATHNAME-FRAGMENT}, \code{URL-PATHNAME-AUTHORITY}, and \code{URL-PATHNAME-SCHEME}. The specific subtype of a Pathname may be determined with the predicates \code{PATHNAME-URL-P} and \code{PATHNAME-JAR-P}. \label{EXTENSIONS:URL-PATHNAME-SCHEME} \index{URL-PATHNAME-SCHEME} \label{EXTENSIONS:URL-PATHNAME-FRAGMENT} \index{URL-PATHNAME-FRAGMENT} \label{EXTENSIONS:URL-PATHNAME-AUTHORITY} \index{URL-PATHNAME-AUTHORITY} \label{EXTENSIONS:PATHNAME-URL-P} \index{PATHNAME-URL-P} \label{EXTENSIONS:URL-PATHNAME-QUERY} \index{URL-PATHNAME-QUERY} \end{itemize} \section{Extensible Sequences} See Rhodes2007 \cite{RHODES2007} for the design. The SEQUENCE package fully implements Christopher Rhodes' proposal for extensible sequences. These user extensible sequences are used directly in \code{java-collections.lisp} provide these CLOS abstractions on the standard Java collection classes as defined by the \code{java.util.List} contract. This extension is not automatically loaded by the implementation. It may be loaded via: \begin{listing-lisp} CL-USER> (require 'java-collections) \end{listing-lisp} if both extensible sequences and their application to Java collections is required, or \begin{listing-lisp} CL-USER> (require 'extensible-sequences) \end{listing-lisp} if only the extensible sequences API as specified in \cite{RHODES2007} is required. Note that \code{(require 'java-collections)} must be issued before \code{java.util.List} or any subclass is used as a specializer in a CLOS method definition (see the section below). \section{Extensions to CLOS} There is an additional syntax for specializing the parameter of a generic function on a java class, viz. \code{(java:jclass CLASS-STRING)} where \code{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 \begin{listing-lisp} (defmethod print-object ((coll (java:jclass "java.util.Collection")) stream) ;;; ... ) \end{listing-lisp} 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. \begin{listing-lisp} (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) ;;; ... ) \end{listing-lisp} \section{Extensions to the Reader} We implement a special hexadecimal escape sequence for specifying characters to the Lisp reader, namely we allow a sequences of the form \# \textbackslash Uxxxx to be processed by the reader as character whose code is specified by the hexadecimal digits ``xxxx''. The hexadecimal sequence must be exactly four digits long \footnote{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 Weisz' excellent work with FLEXI-STREAMS which we fully support}, padded by leading zeros for values less than 0x1000. 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. \section{Overloading of the CL:REQUIRE Mechanism} The \code{CL:REQUIRE} mechanism is overloaded by attaching the following semantic to the execution of \code{REQUIRE} on the following symbols: \begin{description} \item{\code{ASDF}} Loads the \textsc{ASDF} implementation shipped with the implementation. After \textsc{ASDF} has been loaded in this manner, symbols passed to \code{CL:REQUIRE} which are otherwise unresolved, are passed to ASDF for a chance for resolution. This means, for instance if \code{CL-PPCRE} can be located as a loadable \textsc{ASDF} system \code{(require 'cl-ppcre)} is equivalent to \code{(asdf:load-system 'cl-ppcre)}. \item{\code{ABCL-CONTRIB}} Locates and pushes the toplevel contents of ``abcl-contrib.jar'' into the \textsc{ASDF} central registry. \begin{enumerate} \item \code{abcl-asdf} Functions for loading JVM artifacts dynamically, hooking into ASDF 2 objects where possible. \item \code{asdf-jar} Package addressable JVM artifacts via \code{abcl-asdf} descriptions as a single binary artifact including recursive dependencies. \item \code{mvn} These systems name common JVM artifacts from the distributed pom.xml graph of Maven Aether: \begin{enumerate} \item \code{jna} Dynamically load 'jna.jar' version 3.0.9 from the network. \end{enumerate} \item \code{quicklisp-abcl} (Not working) boot a local Quicklisp installation via the ASDF:IRI type introduced bia ABCL-ASDF. \end{enumerate} \end{description} The user may extend the \code{CL:REQUIRE} mechanism by pushing function hooks into \code{SYSTEM:*MODULE-PROVIDER-FUNCTIONS*}. Each such hook function takes a single argument containing the symbol passed to \code{CL:REQUIRE} and returns a non-\code{NIL} value if it can successful resolve the symbol. \section{JSS optionally extends the Reader} The JSS contrib consitutes an additional, optional extension to the reader in the definition of the \#\" reader macro. See section \ref{section:jss} on page \pageref{section:jss} for more information. \section{ASDF} asdf-2.019 (see \cite{asdf}) is packaged as 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 \footnote{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 \textsc{ANSI} \code{REQUIRE} mechanism as follows: \begin{listing-lisp} CL-USER> (require 'asdf) \end{listing-lisp} \chapter{Contrib} The ABCL contrib is packaged as a separate jar archive usually named \code{abcl-contrib.jar} or possibly something like \code{abcl-contrib-1.1.0.jar}. The contrib jar is not loaded by the implementation by default, and must be first intialized by the \code{REQUIRE} mechanism before using any specific contrib: \begin{listing-lisp} CL-USER> (require 'abcl-contrib) \end{listing-lisp} \section{abcl-asdf} This contrib enables an additional syntax for \textsc{ASDF} system definition which dynamically loads \textsc{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 \code{ABCL-ASDF:RESOLVE-DEPENDENCIES} symbol. %ABCL specific contributions to ASDF system definition mainly %concerned with finding JVM artifacts such as jar archives to be %dynamically loaded. The following \textsc{ASDF} components are added: \code{JAR-FILE}, \code{JAR-DIRECTORY}, \code{CLASS-FILE-DIRECTORY} and \code{MVN}. \subsection{Referencing Maven Artifacts via ASDF} Maven artifacts may be referenced within \textsc{ASDF} system definitions, as the following example references the \code{log4j-1.4.9.jar} JVM artifact which provides a widely-used abstraction for handling logging systems: \begin{listing-lisp} ;;;; -*- Mode: LISP -*- (in-package :asdf) (defsystem :log4j :components ((:mvn "log4j/log4j" :version "1.4.9"))) \end{listing-lisp} \subsection{API} We define an API for \textsc{ABCL-ASDF} as consisting of the following ASDF classes: \code{JAR-DIRECTORY}, \code{JAR-FILE}, and \code{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, \code{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. \subsection{Directly Instructing Maven to Download JVM Artifacts} Bypassing \textsc{ASDF}, one can directly issue requests for the Maven artifacts to be downloaded \begin{listing-lisp} 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" \end{listing-lisp} To actually load the dependency, use the \code{JAVA:ADD-TO-CLASSPATH} generic function: \begin{listing-lisp} CL-USER> (java:add-to-classpath (abcl-asdf:resolve-dependencies "com.google.gwt" "gwt-user")) \end{listing-lisp} Notice that all recursive dependencies have been located and installed locally from the network as well. \section{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 \url{http://svn.common-lisp.net/armedbear/trunk/abcl/contrib/asdf-jar/README.markdown}. \section{jss} \label{section: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 \footnote{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 \code{SHARPSIGN-DOUBLE-QUOTE} (\code{\#"}) reader macro, which allows the 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. \subsection{JSS usage} Example: \begin{listing-lisp} CL-USER> (require 'abcl-contrib) ==> ("ABCL-CONTRIB") CL-USER> (require 'jss) ==> ("JSS") CL-USER) (#"getProperties" 'java.lang.System) ==> # CL-USER) (#"propertyNames" (#"getProperties" 'java.lang.System)) ==> # \end{listing-lisp} %$ <-- un-confuse Emacs font-lock Some more information on jss can be found in its documentation at \url{http://svn.common-lisp.net/armedbear/trunk/abcl/contrib/jss/README.markdown} \section{asdf-install} The asdf-install contrib provides an implementation of ASDF-INSTALL. Superseded by Quicklisp (see Xach2011 \cite{quicklisp}). The \code{require} of the \code{asdf-install} symbol has the side effect of pushing the directory \verb+~/.asdf-install-dir/systems/+ into the value of the \textsc{ASDF} central registry in \code{asdf:*central-registry*}, providing a convenient mechanism for stashing \textsc{ABCL} specific system definitions for convenient access. \chapter{History} \textsc{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\"{u}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 \textsc{ANSI}, we released abcl-1.0.0. We released abcl-1.0.1 as a maintainence release on January 10, 2012. \bibliography{abcl} \bibliographystyle{alpha} \printindex \end{document}