source: trunk/abcl/doc/manual/abcl.tex @ 15196

% -*- mode: latex; -*-
% http://en.wikibooks.org/wiki/LaTeX/
\documentclass[10pt]{book}
% also need to have cm-super installed for high quality rendering
\usepackage[T1]{fontenc}
\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.6.0\\
\smallskip
November 2019}
\author{Mark Evenson \and Erik H\"{u}lsmann \and Rudolf Schlatte \and
  Alessio Stalla \and Ville Voutilainen}

\maketitle

\tableofcontents
%%Preface to the Seventh edition, abcl-1.6.0
\subsection{Preface to the Seventh Edition}

Long overdue, we turn our Java to 11.

Reflecting the management's best estimates as to implementation most
easily available to the potential \textsc{ABCL} 1.6 User, the
implementation for this edition works best with Java 8 or Java 11
runtimes.  Since freely available implementations of jdk6 and jdk7
exist, we still strive to maintain compatibility with the Java 6 and
Java 7 runtime environments but those environments are less tested.
The User may need to use the facilities of the ABCL-BUILD contrib to
recompile the implementation locally in more exotic runtimes.

%%Preface to the Sixth edition, abcl-1.5.0
\subsection{Preface to the Sixth Edition}

With the sixth major release of the implementation, we make the
following explicit revision of our compatibility to the underlying
JVM.  Since we are an open source implementation, we insist on
possible open access to the sources from with an JDK may both be built
and run upon.  This requirement is no longer met by Java 5, so
henceforth with the release of \textsc{ABCL} 1.5, we will support
Java 6, Java 7 and Java 8 runtimes.

%% We should probably not release a 1.5.0, go straight for abcl-1.6.0?
%% Not worth the effort: Java 9 is the current abcl-1.6.0 release driver.

%%Preface to the Fifth edition, abcl-1.4.0
\subsection{Preface to the Fifth Edition}

\textsc{ABCL} 1.4 consolidates eighteen months of production bug-fixes,
and substantially improves the support for invoking external
processes via \code{SYS:RUN-PROGRAM}.

%%Preface to the Fourth edition, abcl-1.3.
\subsection{Preface to the Fourth Edition}

\textsc{ABCL} 1.3 now implements an optimized implementation of the
\code{org.armedbear.lisp.LispStack} abstraction thanks to Dmitry
Nadezhin which runs on ORCL JVMs from 1.[5-8] conformantly.

%%Preface to the Third edition, abcl-1.2.
\subsection{Preface to the Third Edition}
The implementation now contains a performant and conformant
implementation of (A)MOP to the point of inclusion in CLOSER-MOP's
test suite.

%%Preface to the second edition, abcl-1.1.

\subsection{Preface to the Second Edition}

\textsc{ABCL} 1.1 now contains \textsc{(A)MOP}.  We hope you enjoy!  --The Mgmt.

\chapter{Introduction}

Armed Bear Common Lisp (\textsc{ABCL}) is an implementation of
\textsc{Common Lisp} that runs on the Java Virtual Machine
(\textsc{JVM}).  \textsc{ABCL} compiles \textsc{Common Lisp} to
\textsc{Java} byte-code\footnote{The class file version is ``49.0''.},
with an efficiency that varies upon the hosting JVM implementation.
\textsc{ABCL} supports running on the Java 6, Java 7, Java 8, and Java
11 \textsc{JVM} implementations.

Armed Bear provides the following integration methods for interfacing
with Java code and libraries:
\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.
\item \code{java:jnew-runtime-class} can inject fully synthetic Java
  classes--and their objects-- into the current JVM process whose
  behavior is specified via closures expressed in \textsc{Common
    Lisp}. \footnote{Parts of the current implementation are not fully
    finished, so the status of some interfaces here should be treated
    with skepticism if you run into problems.}

\end{itemize}
\textsc{ABCL} is supported by the Lisp library manager
\textsc{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 \textsc{ANSI} Common Lisp
implementation due to the following known issues:

\begin{itemize}
\item The generic function signatures of the \code{CL:DOCUMENTATION} symbol
  do not match the specification.
\item The \code{CL:TIME} form does not return a proper \code{CL:VALUES}
  environment to its caller.
\item When merging pathnames and the defaults point to a \code{EXT:JAR-PATHNAME},
  we set the \code{DEVICE} of the result to \code{:UNSPECIFIC} if the pathname to be
  be merged does not contain a specified \code{DEVICE}, does not contain a
  specified \code{HOST}, does contain a relative \code{DIRECTORY}, and we are
  not running on a \textsc{MSFT} Windows platform.\footnote{The intent of this
    rather arcane sounding deviation from conformance is so that the
    result of a merge won't fill in a \code{DEVICE} with the wrong "default
    device for the host" in the sense of the fourth paragraph in the
    \textsc{CLHS} description of MERGE-PATHNAMES (see in \cite{CLHS} 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 \code{HOST} value to reflect the type explicitly.
  }

\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.

\textsc{ABCL} aims to be be a fully conforming \textsc{ANSI} Common Lisp implementation.
Any other behavior should be reported as a bug.

\subsection{Contemporary Common Lisp}
In addition to \textsc{ANSI} conformance, \textsc{ABCL} strives to implement
features expected of a contemporary \textsc{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 Incomplete streams abstraction, in that \textsc{ABCL} needs a
  suitable abstraction between \textsc{ANSI} and \textsc{Gray streams}
  with a runtime switch for the beyond conforming
  behavior\footnote{The streams could be optimized to the
    \textsc{JVM} NIO \cite{nio} abstractions at great profit for
    binary byte-level manipulations.}.
\item Incomplete documentation: source code is missing docstrings from
  all exported symbols from the \code{EXTENSIONS}, \code{SYSTEM},
  \code{JAVA}, \code{MOP}, and \code{THREADS} packages.  This user
  manual is currently in draft status.
\end{itemize}



\section{License}

\textsc{ABCL} is licensed under the terms of the \textsc{GPL} v2 of
June 1991 with an added ``classpath-exception'' clause (see the file
\texttt{COPYING} in the source distribution\footnote{See
  \url{http://abcl.org/svn/trunk/tags/1.6.0/COPYING}} for the license,
term 13 in the same file for the classpath exception).  This license
broadly means that you must distribute the sources to \textsc{ABCL},
including any changes you make, together with a program that includes
\textsc{ABCL}, but that you are not required to distribute the sources
of the whole program.  Submitting your changes upstream to the \textsc{ABCL}
development team is actively encouraged and very much appreciated, of
course.

\section{Contributors}

\begin{itemize}
\item Philipp Marek \texttt{Thanks for the markup, and review of the Manual}
\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 Olof-Joachim Frahm  
\item piso
\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.6.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
\textsc{REPL}\footnote{Read-Eval Print Loop, a Lisp command-line}, viz:

\index{REPL}

\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
\textsc{Emacs} editor is to use \textsc{Quicklisp} and follow the instructions at
\url{http://www.quicklisp.org/beta/#slime}.

\section{Options}

ABCL supports the following command line options:

\index{Command Line Options}

\begin{description}
  % FIXME move this fuggliness to our macros.  sigh. 
\item \code{\textendash\textendash help} displays a help message.
\item \code{\textendash\textendash noinform} Suppresses the printing of startup information and banner.
\item \code{\textendash\textendash noinit} suppresses the loading of the \verb+~/.abclrc+ startup file.
\item \code{\textendash\textendash nosystem} suppresses loading the \texttt{system.lisp} customization file. 
\item \code{\textendash\textendash eval FORM} evaluates FORM before initializing the REPL.
\item \code{\textendash\textendash load FILE} loads the file FILE before initializing the REPL.
\item \code{\textendash\textendash load-system-file FILE} loads the system file FILE before initializing the REPL.
\item \code{\textendash\textendash batch} evaluates forms specified by arguments and in
  the initialization file \verb+~/.abclrc+, and then exits without
  starting a \textsc{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{\textendash\textendash 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 is the term
  of art for the part of a \textsc{Lisp} implementation which implements
  calling code written in other languages, typically normalized to the
  local C compiler calling conventions.}  from \textsc{Lisp} values to Java
values. These conversions typically apply to strings, integers and
floats. Other values need to be converted to their \textsc{Java} equivalents by
the programmer before calling the Java object method. Java values
returned to \textsc{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 \textsc{Java} API, developed by Alan
Ruttenberg, is available in the \code{contrib/jss} 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 parameters 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}

\textsc{Java} objects can be instantiated (created) from \textsc{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. Its 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 \textsc{Lisp}
from \textsc{Java} code.  In order to access the \textsc{Lisp} world from \textsc{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 \textsc{ABCL} \textsc{Lisp} system implementation in
\textsc{Java} is resident 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 \code{org.armedbear.lisp}
namespace.

There can only ever be a single Lisp interpreter per \textsc{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 \textsc{Java}
whose life-cycle is a bit out of your control (like in a \textsc{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) { 
      return false;
    }
    return true;
 }
\end{listing-java}

Note, that the symbol \code{nil} is explicitly named in the
\textsc{Java} namespace as \code{Symbol.NIL} but is always present in
the local namespace in its unadorned form for the convenience of the
User.

\subsubsection{Multiple Values}

After a call to a function that returns Lisp multiple values, the
values are associated with the executing \code{LispThread} until the
next call into Lisp.  One may access the values object as a list of
\code{LispObject} instances via a call to \code{getValues()} on that
thread reference
as evidenced by the following code:

\begin{listing-java}

  org.armedbear.lisp.Package cl = Packages.findPackage("CL");
  Symbol valuesSymbol = cl.findAccessibleSymbol("VALUES");
  LispObject[] valuesArgs = {
    LispInteger.getInstance(1), LispInteger.getInstance(2)
  };
  // equivalent to ``(values 1 2)''
  LispObject result = valuesSymbol.execute(valuesArgs); 
  LispObject[] values = LispThread.currentThread().getValues();
  for (LispObject value: values) {
    System.out.println("value ==> " + value.printObject());
  }
\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://abcl.org/trac/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}

\code{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 \code{abcl-script-user} package, just like evaluated
code.  In contrast to evaluated code, though, due to the way the
\textsc{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 that a top-level
self-evaluating form will appear as the last form in a file (in fact,
the Common Lisp load function always returns \code{t} upon success;
with \textsc{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.

\subsection{Implementation of Java classes in Lisp}

See \code{JAVA:JNEW-RUNTIME-CLASS} in \ref{JAVA:JNEW-RUNTIME-CLASS}.


\chapter{Implementation Dependent Extensions}

As outlined by the \textsc{CLHS} \textsc{ANSI} conformance guidelines,
we document the extensions to the Armed Bear Common Lisp implementation made
accessible to the user by virtue of being an exported symbol in the
\code{java}, \code{threads}, or \code{extensions} packages.

\section{JAVA}

\subsection{Modifying the JVM CLASSPATH}

The \code{JAVA:ADD-TO-CLASSPATH} generic functions allows one to add the
specified pathname or list of pathnames to the current classpath
used by \textsc{ABCL}, allowing the dynamic loading of \textsc{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 \textsc{ABCL}
(the value of the special variable \code{JAVA:*CLASSLOADER*}. It has
no effect on \textsc{Java} code outside \textsc{ABCL}.

\subsection{Creating a synthetic Java Class at Runtime}

See \code{JAVA:JNEW-RUNTIME-CLASS} on \ref{JAVA:JNEW-RUNTIME-CLASS}.

% 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 \cite{lea-1998}

% include autogen docs for the THREADS package.
\include{threads}

\section{EXTENSIONS}

The symbols in the \code{extensions} package (often referenced by its
shorter nickname \code{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 \textsc{Common Lisp}
implementation, \textsc{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.

\subsection{Compiler Diagnostics}

By default, the interface to the compiler does not signal warnings
that result in its invocation, outputing diagnostics to the standard
reporting stream.  The generalized boolean
\code{JVM:*RESIGNAL-COMPILER-WARNINGS*} provides the interface to
enabling the compiler to signal all warnings.


\section{Pathname}

We implement an extension to the \code{CL: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 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 \cite{rfc3986}.}  scheme that the \textsc{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 \textsc{JVM} symbols
present in the \code{sun.net.protocol.dynamic} package. See
\cite{maso2000} for more details.

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

% RDF description of type hierarchy 
% TODO Render via some LaTeX mode for graphviz?
\begin{verbatim}
  @prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#> .
  @prefix ext:   <http://abcl.org/cl/package/extensions/> .
  @prefix cl:    <http://abcl.org/cl/package/common-lisp/> .
  
  <ext:jar-pathname>    rdfs:subClassOf <ext:url-pathname> .
  <ext:url-pathname>    rdfs:subClassOf <cl:pathname> .
  <cl:logical-pathname> rdfs:subClassOf <cl:pathname> .
\end{verbatim}

\label{EXTENSIONS:URL-PATHNAME}
\index{URL-PATHNAME}

\label{EXTENSIONS:JAR-PATHNAME}
\index{JAR-PATHNAME}

Both the \code{EXT:URL-PATHNAME} and \code{EXT:JAR-PATHNAME} objects
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 Any results of canonicalization procedures performed on the
  \textsc{URI} via local or network resolutions are discarded between
  attempts (i.e. the implementation does not attempt to cache the
  results of current name resolution of the URI for underlying
  resource unless it is requested to be resolved.)  Upon resolution,
  any canonicalization procedures followed in resolving the resource
  (e.g. following redirects) are discarded.  Users may programatically
  initiate a new, local computation of the resolution of the resource
  by applying the \code{CL:TRUENAME} function to a
  \code{EXT:URL-PATHNAME} object.  Depending on the reliability and
  properties of your local \textsc{REST} infrastructure, these results
  may not necessarily be idempotent over time\footnote {See
    \cite{uri-pathname} for the design and implementation notes for
    the technical details}.  A future implementation may attempt to
  expose an API to observer/customize the content negotiation
  initiated during retrieval of the representation of a given
  resource, which is currently handled at the application level.

\end{itemize}

The implementation of \code{EXT:URL-PATHNAME} allows the \textsc{ABCL}
user to dynamically load code from the network.  For example,
\textsc{Quicklisp} (\cite{quicklisp}) may be completely installed from
the \textsc{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.

The implementation currently breaks \textsc{ANSI} conformance by allowing the
types able to be \code{CL:READ} for the \code{DEVICE} to return a possible \code{CONS} of
\code{CL:PATHNAME} objects.  %% citation from CLHS needed.

In order to ``smooth over'' the bit about types being \code{CL:READ}
from \code{CL:PATHNAME} components, we extend the semantics for the
usual PATHNAME merge semantics when \code{*DEFAULT-PATHNAME-DEFAULTS*}
contains a \code{EXT:JAR-PATHNAME} with the ``do what I mean''
algorithm described in \ref{section:conformance} on page
\pageref{section:conformance}.

%See \ref{_:quicklisp} on page \pageref{_:quicklisp}.

\subsubsection{Implementation}

The implementation of these extensions stores all the additional
information in the \code{CL: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 \textsc{DOS} or a list of exactly one or two elements.  If
  \code{DEVICE} is a list, it denotes a \code{EXT:JAR-PATHNAME}, with
  the entries containing \code{CL:PATHNAME} objects which describe the
  outer and (possibly inner) locations of the jar
  archive \footnote{The case of inner and outer
    \code{EXT:JAR-PATHNAME} \ref{EXT:JAR-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.}.

\item A \code{EXT: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{Package-Local Nicknames}
\label{sec:pack-local-nickn}

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.\footnote{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 \code{:package-local-nicknames} in \code{*features*} denotes the
support for this feature.

\index{DEFPACKAGE}
The options to \code{defpackage} are extended with a new option
\code{:local-nicknames (local-nickname actual-package-name)*}.

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

Example:
\begin{listing-lisp}
(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
\end{listing-lisp}

\index{PACKAGE-LOCAL-NICKNAMES}
--- Function: \textbf{package-local-nicknames} [\textbf{ext}] \textit{package-designator}

\begin{adjustwidth}{5em}{5em}
  Returns an ALIST of \code{(local-nickname . actual-package)}
  describing the nicknames local to the designated package.

  When in the designated package, calls to \code{find-package} with any
  of the local-nicknames will return the corresponding actual-package
  instead. This also affects all implied calls to \code{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.
\end{adjustwidth}

\index{PACKAGE-LOCALLY-NICKNAMED-BY-LIST}
--- Function: \textbf{package-locally-nicknamed-by-list} [\textbf{ext}] \textit{package-designator}

\begin{adjustwidth}{5em}{5em}
Returns a list of packages which have a local nickname for the
designated package.
\end{adjustwidth}

\index{ADD-PACKAGE-LOCAL-NICKNAME}
--- Function: \textbf{add-package-local-nickname} [\textbf{ext}] \textit{local-nickname actual-package \&optional package-designator}

\begin{adjustwidth}{5em}{5em}
  Adds \code{local-nickname} for \code{actual-package} in the designated
  package, defaulting to current package. \code{local-nickname} must be
  a string designator, and \code{actual-package} must be a package
  designator.

  Returns the designated package.

  Signals an error if \code{local-nickname} is already a package local
  nickname for a different package, or if \code{local-nickname} is one
  of "CL", "COMMON-LISP", or, "KEYWORD", or if \code{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 \code{find-package} with the
  \code{local-nickname} will return the package the designated
  \code{actual-package} instead. This also affects all implied calls to
  \code{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.
\end{adjustwidth}

\index{REMOVE-PACKAGE-LOCAL-NICKNAME}
--- Function: \textbf{remove-package-local-nickname} [\textbf{ext}] \textit{old-nickname \&optional package-designator}

\begin{adjustwidth}{5em}{5em}
  If the designated package had \code{old-nickname} as a local nickname
  for another package, it is removed. Returns true if the nickname
  existed and was removed, and \code{nil} otherwise.
\end{adjustwidth}


         
\section{Extensible Sequences}

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.


%% an Example of using java.util.Lisp in Lisp would be nice

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 \textsc{CLOS}
method definition (see the section below).

See Rhodes2007 \cite{RHODES2007} for the an overview of the
abstractions of the \code{java.util.collection} package afforded by
\code{JAVA-COLLECTIONS}.

\section{Extensions to CLOS}

\subsection{Metaobject Protocol}

\textsc{ABCL} implements the metaobject protocol for \textsc{CLOS} as
specified in \textsc{(A)MOP}.  The symbols are exported from the
package \code{MOP}.

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

\textsc{ABCL}'s fidelity to the AMOP specification is codified as part
of Pascal Costanza's \code{closer-mop} \ref{closer-mop} \cite{closer-mop}.

\subsection{Specializing on Java classes}

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 \code{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 32
bit characters to the Lisp reader\footnote{This represents a
  compromise with contemporary in 2011 32bit hosting architectures for
  which we wish to make text processing efficient.  Should the User
  require more control over \textsc{UNICODE} processing we recommend Edi Weisz'
  excellent work with \textsc|{FLEXI-STREAMS}  which we fully support}, namely we
allow a sequences of the form \verb~#\U~\emph{\texttt{xxxx}} to be processed
by the reader as character whose code is specified by the hexadecimal
digits \emph{\texttt{xxxx}}.  The hexadecimal sequence may be one to four digits
long.

% Why doesn't ALEXANDRIA work?  Good question: Alexandria from
% Quicklisp 2010-10-07 fails a number of tests:
%% Form: (ALEXANDRIA.0.DEV:TYPE= 'LIST '(OR NULL CONS))
%% Expected values: T
%%                  T
%% Actual values: NIL
%%                T.
%% Test ALEXANDRIA-TESTS::TYPE=.3 failed
%% Form: (ALEXANDRIA.0.DEV:TYPE= 'NULL '(AND SYMBOL LIST))
%% Expected values: T
%%                  T
%% Actual values: NIL
%%                NIL.


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 these
semantics 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 top-level 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 3 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 5.5.0
            from the network \footnote{This loading can be inhibited
              if, at runtime, the Java class corresponding
              ``:classname'' clause of the system definition is present.}
        \end{enumerate}
      \item \code{quicklisp-abcl} Boot a local Quicklisp installation
        via the ASDF:IRI type introduced via ABCL-ASDF.

      \item \code{jfli} A descendant of Rich Hickey's pre-Clojure work
        on the JVM.
      \item \code{jss} Introduces dynamic inspection of present
        symbols via the \code{SHARPSIGN-QUOTATION\_MARK} macros as Java Syntax
        Sucks
      \item \code{abcl-introspect} Provides a framework for
        introspecting runtime Java and Lisp object values.
      \item \code{abcl-build} Provides a toolkit for building ABCL
        from source, as well as installing the necessary tools for
        such builds.
        
\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 extension of the Reader by SHARPSIGN-DOUBLE-QUOTE}

The JSS contrib constitutes an additional, optional extension to the
reader in the definition of the \code{SHARPSIGN-DOUBLE-QUOTE}
(``\#\"'') reader macro.  See section \ref{section:jss} on page
\pageref{section:jss} for more information.

\section{ASDF}

asdf-3.3.3 (see \cite{asdf}) is packaged as core component of \textsc{ABCL},
but not initialized by default, as it relies on the \textsc{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 \textsc{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 \textsc{ABCL} contrib is packaged as a separate jar archive usually named
\code{abcl-contrib.jar} or possibly something like
\code{abcl-contrib-1.6.0.jar}.  The contrib jar is not loaded by the
implementation by default, and must be first initialized 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.


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

\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 -*-
  (require :asdf)
  (in-package :cl-user)

  (asdf:defsystem :log4j
     :defsystem-depends-on (abcl-asdf)
     :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 \code{MVN} and \code{IRI} classes descend from
\code{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.

More extensive documentations and examples can be found at
\url{http://abcl.org/svn/tags/1.6.0/contrib/abcl-asdf/README.markdown}.

\section{asdf-jar}

The asdf-jar contrib provides a system for packaging \textsc{ASDF}
systems into jar archives for \textsc{ABCL}.  Given a running
\textsc{ABCL} image with loadable \textsc{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://abcl.org/svn/tags/1.6.0/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)
==> #<java.util.Properties {java.runtime.name=Java.... {2FA21ACF}>
CL-USER) (#"propertyNames" (#"getProperties" 'java.lang.System))
==> #<java.util.Hashtable$Enumerator java.util.Has.... {36B4361A}>
\end{listing-lisp} %$ <-- un-confuse Emacs font-lock

Some more information on jss can be found in its documentation at
\url{http://abcl.org/svn/tags/1.6.0/contrib/jss/README.markdown}

\section{jfli}
\label{section:jfli}

The contrib contains a pure-Java version of JFLI. 

\url{http://abcl.org/svn/tags/1.6.0/contrib/jfli/README}.

\section{abcl-introspect}

\textsc{ABCL-INTROSPECT} offers more extensive systems for inspecting the state
of the implementation, most notably in integration with SLIME, where
the backtrace mechanism is augmented to the point that local
variables are inspectable.

A compiled function is an instance of a class - This class has
multiple instances if it represents a closure, or a single instance if
it represents a non-closed-over function.

The \textsc{ABCL} compiler stores constants that are used in function
execution as private java fields. This includes symbols used to invoke
function, locally-defined functions (such as via \code{LABEL} or
\code{flet}) and string and other literal objects.
\textsc{ABCL-INTROSPECT} implements a ``do what I mean'' API for
introspecting these constants.

ABCL-INTROSPECT provides access to those internal values, and
uses them in at least two ways. First, to annotate locally defined
functions with the top-level function they are defined within, and
second to search for callers of a give function \footnote{ Since java
  functions are strings, local fields also have these strings. In the
  context of looking for callers of a function you can also give a
  string that names a java method. Same caveat re: false positives.}
. This may yield some false positives, such as when a symbol that
names a function is also used for some other purpose. It can also have
false negatives, as when a function is inlined. Still, it's pretty
useful. The second use to to find source locations for frames in the
debugger. If the source location for a local function is asked for the
location of its 'owner' is instead returns.

In order to record information about local functions, ABCL defines a
function-plist, which is for the most part unused, but is used here
with set of keys indicating where the local function was defined and
in what manner, i.e. as normal local function, as a method function,
or as an initarg function. There may be other places functions are
stashed away (defstructs come to mind) and this file should be added
to to take them into account as they are discovered.

ABCL-INTROSPECT does not depend on jss, but provides a bit of
jss-specific functionality if jss *is* loaded.

\url{http://abcl.org/svn/tags/1.6.0/contrib/abcl-introspect/}.

\section{abcl-build}

\textsc{ABCL-BUILD} constitutes a new implementation for the original
Lisp-hosted ABCL build system API in the package \code{ABCL-BUILD}
that uses the same build artifacts as all of the other current builds.

\subsection{Utilities}

\textsc{ABCL-BUILD} consolidates various utilities that are useful
for system construction, namely
\begin{itemize}

\item The ability to introspect the invocation of given executable in
  the current implementation process PATH.

\item Downloading and unpackaging selected JVM artifacts, namely the
  Ant and Maven build tools.  The \code{ABCL-BUILD:WITH-ANT} and
  \code{ABCL-BUILD:WITH-MVN} macros abstracts this installation
  procedure conveniently away from the User.

\item The beginnings of a generic framework to download arbitrary
    archives from the network.
\end{itemize}

\url{http://abcl.org/svn/tags/1.6.0/contrib/abcl-build/}.

\section{named-readtables}

\code{NAMED-READTABLES} is a library that provides a namespace for
readtables akin to the already-existing namespace of packages.

\url{https://github.com/melisgl/named-readtables/}.
\url{http://abcl.org/svn/tags/1.6.0/contrib/named-readtables/}.

\chapter{History}
\index{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 publicly 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 maintenance release
on January 10, 2012.

In December 2012, we revised the implementation by adding
\textsc{(A)MOP} with the release of abcl-1.1.0.  We released
abcl-1.1.1 as a maintenance release on February 14, 2013.

At the beginning of June 2013, we enhanced the stability of the
implementation with the release of abcl-1.2.1.

In March 2014, we introduced the Fourth Edition of the implementation
with abcl-1.3.0.  At the end of April 2014, we released abcl-1.3.1 as
a maintenance release.

In October 2016 we blessed the current \textsc{svn} trunk
\url{http://abcl.org/svn/trunk/} as 1.4.0, which includes the
community contributions from Vihbu, Olof, Pipping, and Cyrus.  We
gingerly stepped into current century by establishing \textsc{git}
bridges to the source repository at
\url{https://github.com/easye/abcl/} and
\url{https://gitlab.common-lisp.net/abcl/abcl/} so that pull
requests for enhancements to the implementation many be more easily
facilitated.

In June 2017, we released ABCL 1.6.0 which dropped support for running
upon Java 5.

Against the falling canvas of 2019 we released ABCL 1.6.0 which
provided compatibility with Java 11 while skipping Java 9 and 10.

\appendix 

\chapter{The MOP Dictionary}

\include{mop}

\chapter{The SYSTEM Dictionary}

The public interfaces in this package are subject to change with
\textsc{ABCL} 1.7.

\include{system}

\chapter{The JSS Dictionary}

These public interfaces are provided by the JSS contrib.

\include{jss}

\bibliography{abcl}
\bibliographystyle{alpha}

\printindex

\end{document}