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

Last change on this file since 14617 was 14617, checked in by Mark Evenson, 9 years ago

More documentation refresh for abcl-1.3.0-rc-0.

File size: 58.6 KB
Line 
1% -*- mode: latex; -*-
2% http://en.wikibooks.org/wiki/LaTeX/
3\documentclass[10pt]{book}
4\usepackage{abcl}
5
6\usepackage{hyperref} % Put this one last, it redefines lots of internals
7
8
9\begin{document}
10\title{Armed Bear Common Lisp User Manual}
11\date{Version 1.3.0-rc-0\\
12\smallskip
13January 27, 2014}
14\author{Mark Evenson \and Erik H\"{u}lsmann \and Rudolf Schlatte \and
15  Alessio Stalla \and Ville Voutilainen}
16
17\maketitle
18
19\tableofcontents
20\subsection{Preface to the Fourth Edition}
21
22\textsc{ABCL} 1.3 now implements an optimized implementation of the
23LispStack abstraction thanks to Dmitry Nadezhin.
24
25%%Preface to the Third edition, abcl-1.2.
26\subsection{Preface to the Third Edition}
27The implementation now contains a performant and conformant
28implementation of (A)MOP to the point of inclusion in CLOSER-MOP's
29test suite.
30
31%%Preface to the second edition, abcl-1.1.
32
33\subsection{Preface to the Second Edition}
34
35\textsc{ABCL} 1.1 now contains \textsc{(A)MOP}.  We hope you enjoy!  --The Mgmt.
36
37\chapter{Introduction}
38
39Armed Bear Common Lisp (\textsc{ABCL}) is an implementation of Common
40Lisp that runs on the Java Virtual Machine.  It compiles Common Lisp
41to Java 5 bytecode \footnote{The class file version is ``49.0''.},
42providing the following integration methods for interfacing with Java
43code and libraries:
44\begin{itemize}
45\item Lisp code can create Java objects and call their methods (see
46  Section~\ref{sec:lisp-java}, page~\pageref{sec:lisp-java}).
47\item Java code can call Lisp functions and generic functions, either
48  directly (Section~\ref{sec:calling-lisp-from-java},
49  page~\pageref{sec:calling-lisp-from-java}) or via \texttt{JSR-223}
50  (Section~\ref{sec:java-scripting-api},
51  page~\pageref{sec:java-scripting-api}).
52\item \code{jinterface-implementation} creates Lisp-side implementations
53  of Java interfaces that can be used as listeners for Swing classes and
54  similar.
55\item \code{java:jnew-runtime-class} can inject fully synthetic Java
56  classes--and their objects-- into the current JVM process whose
57  behavior is specified via closures expressed in Common Lisp.. \footnote{Parts of
58    the current implementation are not fully finished, so the status
59    of some interfaces here should be treated with skepticism if you
60    run into problems.}
61
62\end{itemize}
63\textsc{ABCL} is supported by the Lisp library manager
64\textsc{QuickLisp}\footnote{\url{http://quicklisp.org/}} and can run many of the
65programs and libraries provided therein out-of-the-box.
66
67\section{Conformance}
68\label{section:conformance}
69
70\subsection{ANSI Common Lisp}
71\textsc{ABCL} is currently a (non)-conforming \textsc{ANSI} Common Lisp
72implementation due to the following known issues:
73
74\begin{itemize}
75\item The generic function signatures of the \code{CL:DOCUMENTATION} symbol
76  do not match the specification.
77\item The \code{CL:TIME} form does not return a proper \code{CL:VALUES}
78  environment to its caller.
79\item When merging pathnames and the defaults point to a \code{EXT:JAR-PATHNAME},
80  we set the \code{DEVICE} of the result to \code{:UNSPECIFIC} if the pathname to be
81  be merged does not contain a specified \code{DEVICE}, does not contain a
82  specified \code{HOST}, does contain a relative \code{DIRECTORY}, and we are
83  not running on a \textsc{MSFT} Windows platform.\footnote{The intent of this
84    rather arcane sounding deviation from conformance is so that the
85    result of a merge won't fill in a \code{DEVICE} with the wrong "default
86    device for the host" in the sense of the fourth paragraph in the
87    \textsc{CLHS} description of MERGE-PATHNAMES (see in \cite{CLHS} the paragraph beginning
88    "If the PATHNAME explicitly specifies a host and not a device
").
89    A future version of the implementation may return to conformance
90    by using the \code{HOST} value to reflect the type explicitly.
91  }
92
93\end{itemize}
94
95Somewhat confusingly, this statement of non-conformance in the
96accompanying user documentation fulfills the requirements that
97\textsc{ABCL} is a conforming ANSI Common Lisp implementation according
98to the Common Lisp HyperSpec~\cite{CLHS}.  Clarifications to this point
99are solicited.
100
101\textsc{ABCL} aims to be be a fully conforming \textsc{ANSI} Common Lisp implementation.
102Any other behavior should be reported as a bug.
103
104\subsection{Contemporary Common Lisp}
105In addition to \textsc{ANSI} conformance, \textsc{ABCL} strives to implement
106features expected of a contemporary Common Lisp, i.e. a Lisp of the
107post-2005 Renaissance.
108
109The following known problems detract from \textsc{ABCL} being a proper
110contemporary Common Lisp.
111\begin{itemize}
112\item An incomplete implementation of interactive debugging mechanisms,
113  namely a no-op version of \code{STEP} \footnote{Somewhat surprisingly
114    allowed by \textsc{ANSI}}, the inability to inspect local variables
115  in a given call frame, and the inability to resume a halted
116  computation at an arbitrarily selected call frame.
117\item Incomplete streams abstraction, in that \textsc{ABCL} needs
118  suitable abstraction between \textsc{ANSI} and Gray
119  streams.  \footnote{The streams could be optimized to the
120    \textsc{JVM} NIO \cite{nio} abstractions at great profit for
121    binary byte-level manipulations.}
122\item Incomplete documentation (missing docstrings from exported
123  symbols and the draft status of this user manual).
124\end{itemize}
125
126
127
128\section{License}
129
130\textsc{ABCL} is licensed under the terms of the \textsc{GPL} v2 of
131June 1991 with the ``classpath-exception'' (see the file
132\texttt{COPYING} in the source distribution \footnote{See
133  \url{http://abcl.org/svn/trunk/tags/1.3.0/COPYING}} for
134the license, term 13 in the same file for the classpath exception).
135This license broadly means that you must distribute the sources to
136ABCL, including any changes you make, together with a program that
137includes ABCL, but that you are not required to distribute the sources
138of the whole program.  Submitting your changes upstream to the ABCL
139development team is actively encouraged and very much appreciated, of
140course.
141
142\section{Contributors}
143
144\begin{itemize}
145\item Philipp Marek \texttt{Thanks for the markup}
146\item Douglas Miles \texttt{Thanks for the whacky IKVM stuff and keeping the flame alive
147  in the dark years.}
148\item Alan Ruttenberg \texttt{Thanks for JSS.}
149\item and of course
150\emph{Peter Graves}
151\end{itemize}
152
153
154\chapter{Running ABCL}
155
156
157\textsc{ABCL} is packaged as a single jar file usually named either
158\texttt{abcl.jar} or possibly something like \texttt{abcl-1.3.0.jar} if
159using a versioned package on the local filesystem from your system
160vendor.  This jar file can be executed from the command line to obtain a
161\textsc{REPL}\footnote{Read-Eval Print Loop, a Lisp command-line}, viz:
162
163\index{REPL}
164
165\begin{listing-shell}
166  cmd$ java -jar abcl.jar
167\end{listing-shell} %$ unconfuse Emacs syntax highlighting
168
169\emph{N.b.} for the proceeding command to work, the \texttt{java}
170executable needs to be in your path.
171
172To facilitate the use of ABCL in tool chains such as SLIME~\cite{slime}
173(the Superior Lisp Interaction Mode for Emacs), we provide both a Bourne
174shell script and a \textsc{DOS} batch file.  If you or your
175administrator adjusted the path properly, ABCL may be executed simply
176as:
177
178\begin{listing-shell}
179  cmd$ abcl
180\end{listing-shell}%$
181
182Probably the easiest way of setting up an editing environment using the
183\textsc{Emacs} editor is to use \textsc{Quicklisp} and follow the instructions at
184\url{http://www.quicklisp.org/beta/#slime}.
185
186\section{Options}
187
188ABCL supports the following command line options:
189
190\index{Command Line Options}
191
192\begin{description}
193\item[\texttt{  --help}] displays a help message.
194\item[\texttt{  --noinform}] Suppresses the printing of startup information and banner.
195\item[\texttt{  --noinit}] suppresses the loading of the \verb+~/.abclrc+ startup file.
196\item[\texttt{  --nosystem}] suppresses loading the \texttt{system.lisp} customization file.
197\item[\texttt{  --eval FORM}] evaluates FORM before initializing the REPL.
198\item[\texttt{  --load FILE}] loads the file FILE before initializing the REPL.
199\item[\texttt{  --load-system-file FILE}] loads the system file FILE before initializing the REPL.
200\item[\texttt{  --batch}] evaluates forms specified by arguments and in
201  the initialization file \verb+~/.abclrc+, and then exits without
202  starting a \textsc{REPL}.
203\end{description}
204
205All of the command line arguments following the occurrence of \verb+--+
206are passed unprocessed into a list of strings accessible via the
207variable \code{EXT:*COMMAND-LINE-ARGUMENT-LIST*} from within ABCL.
208
209\section{Initialization}
210
211If the \textsc{ABCL} process is started without the \code{--noinit}
212flag, it attempts to load a file named \code{.abclrc} in the user's home
213directory and then interpret its contents.
214
215The user's home directory is determined by the value of the JVM system
216property \texttt{user.home}.  This value may or may not correspond
217to the value of the \texttt{HOME} system environment variable, at the
218discretion of the JVM implementation that \textsc{ABCL} finds itself
219hosted upon.
220
221\chapter{Interaction with the Hosting JVM}
222
223%  Plan of Attack
224%
225% describe calling Java from Lisp, and calling Lisp from Java,
226% probably in two separate sections.  Presumably, we can partition our
227% audience into those who are more comfortable with Java, and those
228% that are more comforable with Lisp
229
230The Armed Bear Common Lisp implementation is hosted on a Java Virtual
231Machine.  This chapter describes the mechanisms by which the
232implementation interacts with that hosting mechanism.
233
234\section{Lisp to Java}
235\label{sec:lisp-java}
236
237\textsc{ABCL} offers a number of mechanisms to interact with Java from its
238Lisp environment. It allows calling both instance and static methods
239of Java objects, manipulation of instance and static fields on Java
240objects, and construction of new Java objects.
241
242When calling Java routines, some values will automatically be
243converted by the FFI\footnote{Foreign Function Interface, is the term
244  of art for the part of a Lisp implementation which implements
245  calling code written in other languages, typically normalized to the
246  local C compiler calling conventions.}  from Lisp values to Java
247values. These conversions typically apply to strings, integers and
248floats. Other values need to be converted to their Java equivalents by
249the programmer before calling the Java object method. Java values
250returned to Lisp are also generally converted back to their Lisp
251counterparts. Some operators make an exception to this rule and do not
252perform any conversion; those are the ``raw'' counterparts of certain
253FFI functions and are recognizable by their name ending with
254\code{-RAW}.
255
256\subsection{Low-level Java API}
257
258This subsection covers the low-level API available after evaluating
259\code{(require 'JAVA)}.  A higher level Java API, developed by Alan
260Ruttenberg, is available in the \code{contrib/} directory and described
261later in this document, see Section~\ref{section:jss} on page
262\pageref{section:jss}.
263
264\subsubsection{Calling Java Object Methods}
265
266There are two ways to call a Java object method in the low-level (basic) API:
267
268\begin{itemize}
269\item Call a specific method reference (which was previously acquired)
270\item Dynamic dispatch using the method name and the call-specific
271  arguments provided by finding the best match (see
272  Section~\ref{sec:param-matching-for-ffi}).
273\end{itemize}
274
275\code{JAVA:JMETHOD} is used to acquire a specific method reference.  The
276function takes two or more arguments. The first is a Java class
277designator (a \code{JAVA:JAVA-CLASS} object returned by
278\code{JAVA:JCLASS} or a string naming a Java class). The second is a
279string naming the method.
280
281Any arguments beyond the first two should be strings naming Java
282classes, with one exception as listed in the next paragraph. These
283classes specify the types of the arguments for the method.
284
285When \code{JAVA:JMETHOD} is called with three parameters and the last
286parameter is an integer, the first method by that name and matching
287number of parameters is returned.
288
289Once a method reference has been acquired, it can be invoked using
290\code{JAVA:JCALL}, which takes the method as the first argument. The
291second argument is the object instance to call the method on, or
292\code{NIL} in case of a static method.  Any remaining parameters are
293used as the remaining arguments for the call.
294
295\subsubsection{Calling Java object methods: dynamic dispatch}
296
297The second way of calling Java object methods is by using dynamic dispatch.
298In this case \code{JAVA:JCALL} is used directly without acquiring a method
299reference first. In this case, the first argument provided to \code{JAVA:JCALL}
300is a string naming the method to be called. The second argument is the instance
301on which the method should be called and any further arguments are used to
302select the best matching method and dispatch the call.
303
304\subsubsection{Dynamic dispatch: Caveats}
305
306Dynamic dispatch is performed by using the Java reflection
307API \footnote{The Java reflection API is found in the
308  \code{java.lang.reflect} package}. Generally the dispatch works
309fine, but there are corner cases where the API does not correctly
310reflect all the details involved in calling a Java method. An example
311is the following Java code:
312
313\begin{listing-java}
314ZipFile jar = new ZipFile("/path/to/some.jar");
315Object els = jar.entries();
316Method method = els.getClass().getMethod("hasMoreElements");
317method.invoke(els);
318\end{listing-java}
319
320Even though the method \code{hasMoreElements()} is public in
321\code{Enumeration}, the above code fails with
322
323\begin{listing-java}
324java.lang.IllegalAccessException: Class ... can
325not access a member of class java.util.zip.ZipFile\$2 with modifiers
326"public"
327       at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
328       at java.lang.reflect.Method.invoke(Method.java:583)
329       at ...
330\end{listing-java}
331
332This is because the method has been overridden by a non-public class and
333the reflection API, unlike \texttt{javac}, is not able to handle such a case.
334
335While code like that is uncommon in Java, it is typical of ABCL's FFI
336calls. The code above corresponds to the following Lisp code:
337
338\begin{listing-lisp}
339(let ((jar (jnew "java.util.zip.ZipFile" "/path/to/some.jar")))
340  (let ((els (jcall "entries" jar)))
341    (jcall "hasMoreElements" els)))
342\end{listing-lisp}
343
344except that the dynamic dispatch part is not shown.
345
346To avoid such pitfalls, all Java objects in \textsc{ABCL} carry an extra
347field representing the ``intended class'' of the object. That class is
348used first by \code{JAVA:JCALL} and similar to resolve methods; the
349actual class of the object is only tried if the method is not found in
350the intended class. Of course, the intended class is always a
351super-class of the actual class -- in the worst case, they coincide. The
352intended class is deduced by the return type of the method that
353originally returned the Java object; in the case above, the intended
354class of \code{ELS} is \code{java.util.Enumeration} because that is the
355return type of the \code{entries} method.
356
357While this strategy is generally effective, there are cases where the
358intended class becomes too broad to be useful. The typical example
359is the extraction of an element from a collection, since methods in
360the collection API erase all types to \code{Object}. The user can
361always force a more specific intended class by using the \code{JAVA:JCOERCE}
362operator.
363
364% \begin{itemize}
365% \item Java values are accessible as objects of type JAVA:JAVA-OBJECT.
366% \item The Java FFI presents a Lisp package (JAVA) with many useful
367%   symbols for manipulating the artifacts of expectation on the JVM,
368%   including creation of new objects \ref{JAVA:JNEW}, \ref{JAVA:JMETHOD}), the
369%   introspection of values \ref{JAVA:JFIELD}, the execution of methods
370%   (\ref{JAVA:JCALL}, \ref{JAVA:JCALL-RAW}, \ref{JAVA:JSTATIC})
371% \item The JSS package (\ref{JSS}) in contrib introduces a convenient macro
372%   syntax \ref{JSS:SHARPSIGN_DOUBLEQUOTE_MACRO} for accessing Java
373%   methods, and additional convenience functions.
374% \item Java classes and libraries may be dynamically added to the
375%   classpath at runtime (JAVA:ADD-TO-CLASSPATH).
376% \end{itemize}
377
378\subsubsection{Calling Java class static methods}
379
380Like non-static methods, references to static methods can be acquired by
381using the \code{JAVA:JMETHOD} primitive. Static methods are called with
382\code{JAVA:JSTATIC} instead of \code{JAVA:JCALL}.
383
384Like \code{JAVA:JCALL}, \code{JAVA:JSTATIC} supports dynamic dispatch by
385passing the name of the method as a string instead of passing a method reference.
386The parameter values should be values to pass in the function call instead of
387a specification of classes for each parameter.
388
389\subsubsection{Parameter matching for FFI dynamic dispatch}
390\label{sec:param-matching-for-ffi}
391
392The algorithm used to resolve the best matching method given the name
393and the arguments' types is the same as described in the Java Language
394Specification. Any deviation should be reported as a bug.
395
396% ###TODO reference to correct JLS section
397
398\subsubsection{Instantiating Java objects}
399
400Java objects can be instantiated (created) from Lisp by calling
401a constructor from the class of the object to be created. The
402\code{JAVA:JCONSTRUCTOR} primitive is used to acquire a constructor
403reference. It's arguments specify the types of arguments of the constructor
404method the same way as with \code{JAVA:JMETHOD}.
405
406The obtained constructor is passed as an argument to \code{JAVA:JNEW},
407together with any arguments.  \code{JAVA:JNEW} can also be invoked with
408a string naming the class as its first argument.
409
410\subsubsection{Accessing Java object and class fields}
411
412Fields in Java objects can be accessed using the getter and setter
413functions \code{JAVA:JFIELD} and \code{(SETF JAVA:JFIELD)}.  Static
414(class) fields are accessed the same way, but with a class object or
415string naming a class as first argument.
416
417Like \code{JAVA:JCALL} and friends, values returned from these accessors carry
418an intended class around, and values which can be converted to Lisp values will
419be converted.
420
421\section{Java to Lisp}
422
423This section describes the various ways that one interacts with Lisp
424from Java code.  In order to access the Lisp world from Java, one needs
425to be aware of a few things, the most important ones being listed below:
426
427\begin{itemize}
428\item All Lisp values are descendants of \code{LispObject}.
429\item Lisp symbols are accessible either via static members of the
430  \code{Symbol} class, or by dynamically introspecting a \code{Package}
431  object.
432\item The Lisp dynamic environment may be saved via
433  \code{LispThread.bindSpecial(Binding)} and restored via
434  \code{LispThread.resetSpecialBindings(Mark)}.
435\item Functions can be executed by invoking \code{LispObject.execute(args
436    [...])}
437\end{itemize}
438
439\subsection{Calling Lisp from Java}
440\label{sec:calling-lisp-from-java}
441
442Note: the entire ABCL Lisp system resides in the
443\texttt{org.armedbear.lisp} package, but the following code snippets do
444not show the relevant import statements in the interest of brevity.  An
445example of the import statement would be
446\begin{listing-java}
447  import org.armedbear.lisp.*;
448\end{listing-java}
449to potentially import all the JVM symbol from the `org.armedbear.lisp'
450namespace.
451
452There can only ever be a single Lisp interpreter per JVM instance.  A
453reference to this interpreter is obtained by calling the static method
454\code{Interpreter.createInstance()}.
455
456\begin{listing-java}
457  Interpreter interpreter = Interpreter.createInstance();
458\end{listing-java}
459
460If this method has already been invoked in the lifetime of the current
461Java process it will return \texttt{null}, so if you are writing Java
462whose life-cycle is a bit out of your control (like in a Java servlet),
463a safer invocation pattern might be:
464
465\begin{listing-java}
466  Interpreter interpreter = Interpreter.getInstance();
467  if (interpreter == null) {
468    interpreter = Interpreter.createInstance();
469  }
470\end{listing-java}
471
472
473The Lisp \code{eval} primitive may simply be passed strings for evaluation:
474
475\begin{listing-java}
476  String line = "(load \"file.lisp\")";
477  LispObject result = interpreter.eval(line);
478\end{listing-java}
479
480Notice that all possible return values from an arbitrary Lisp
481computation are collapsed into a single return value.  Doing useful
482further computation on the \code{LispObject} depends on knowing what the
483result of the computation might be.  This usually involves some amount
484of \code{instanceof} introspection, and forms a whole topic to itself
485(see Section~\ref{topic:Introspecting a LispObject},
486page~\pageref{topic:Introspecting a LispObject}).
487
488Using \code{eval} involves the Lisp interpreter.  Lisp functions may
489also be directly invoked by Java method calls as follows.  One simply
490locates the package containing the symbol, obtains a reference to the
491symbol, and then invokes the \code{execute()} method with the desired
492parameters.
493
494\begin{listing-java}
495  interpreter.eval("(defun foo (msg)" +
496    "(format nil \"You told me '~A'~%\" msg))");
497  Package pkg = Packages.findPackage("CL-USER");
498  Symbol foo = pkg.findAccessibleSymbol("FOO");
499  Function fooFunction = (Function)foo.getSymbolFunction();
500  JavaObject parameter = new JavaObject("Lisp is fun!");
501  LispObject result = fooFunction.execute(parameter);
502  // How to get the "naked string value"?
503  System.out.println("The result was " + result.writeToString());
504\end{listing-java}
505
506If one is calling a function in the CL package, the syntax can become
507considerably simpler.  If we can locate the instance of definition in
508the ABCL Java source, we can invoke the symbol directly.  For instance,
509to tell if a \code{LispObject} is (Lisp) \texttt{NIL}, we can invoke the
510CL function \code{NULL} in the following way:
511
512\begin{listing-java}
513  boolean nullp(LispObject object) {
514    LispObject result = Primitives.NULL.execute(object);
515    if (result == NIL) { // the symbol 'NIL' is explicitly named in the Java
516                         // namespace at ``Symbol.NIL''
517                         // but is always present in the
518                         // local namespace in its unadorned form for
519                         // the convenience of the User.
520      return false;
521    }
522    return true;
523 }
524\end{listing-java}
525
526\subsubsection{Introspecting a LispObject}
527\label{topic:Introspecting a LispObject}
528
529We present various patterns for introspecting an arbitrary
530\code{LispObject} which can hold the result of every Lisp evaluation
531into semantics that Java can meaningfully deal with.
532
533\paragraph{LispObject as \code{boolean}}
534
535If the \code{LispObject} is to be interpreted as a generalized boolean
536value, one can use \code{getBooleanValue()} to convert to Java:
537
538\begin{listing-java}
539   LispObject object = Symbol.NIL;
540   boolean javaValue = object.getBooleanValue();
541\end{listing-java}
542
543Since in Lisp any value other than \code{NIL} means "true", Java
544equality can also be used, which is a bit easier to type and better in
545terms of information it conveys to the compiler:
546
547\begin{listing-java}
548    boolean javaValue = (object != Symbol.NIL);
549\end{listing-java}
550
551\paragraph{LispObject as a list}
552
553If \code{LispObject} is a list, it will have the type \code{Cons}.  One
554can then use the \code{copyToArray} method to make things a bit more
555suitable for Java iteration.
556
557\begin{listing-java}
558  LispObject result = interpreter.eval("'(1 2 4 5)");
559  if (result instanceof Cons) {
560    LispObject array[] = ((Cons)result.copyToArray());
561    ...
562  }
563\end{listing-java}
564
565A more Lispy way to iterate down a list is to use the `cdr()` access
566function just as like one would traverse a list in Lisp:;
567
568\begin{listing-java}
569  LispObject result = interpreter.eval("'(1 2 4 5)");
570  while (result != Symbol.NIL) {
571    doSomething(result.car());
572    result = result.cdr();
573  }
574\end{listing-java}
575
576\section{Java Scripting API (JSR-223)}
577\label{sec:java-scripting-api}
578
579ABCL can be built with support for JSR-223~\cite{jsr-223}, which offers
580a language-agnostic API to invoke other languages from Java. The binary
581distribution download-able from ABCL's homepage is built with JSR-223
582support. If you're building ABCL from source on a pre-1.6 JVM, you need
583to have a JSR-223 implementation in your classpath (such as Apache
584Commons BSF 3.x or greater) in order to build ABCL with JSR-223 support;
585otherwise, this feature will not be built.
586
587This section describes the design decisions behind the ABCL JSR-223
588support. It is not a description of what JSR-223 is or a tutorial on
589how to use it. See
590\url{http://abcl.org/trac/browser/trunk/abcl/examples/jsr-223}
591for example usage.
592
593\subsection{Conversions}
594
595In general, ABCL's implementation of the JSR-223 API performs implicit
596conversion from Java objects to Lisp objects when invoking Lisp from
597Java, and the opposite when returning values from Java to Lisp. This
598potentially reduces coupling between user code and ABCL. To avoid such
599conversions, wrap the relevant objects in \code{JavaObject} instances.
600
601\subsection{Implemented JSR-223 interfaces}
602
603JSR-223 defines three main interfaces, of which two (\code{Invocable}
604and \code{Compilable}) are optional. ABCL implements all the three
605interfaces - \code{ScriptEngine} and the two optional ones - almost
606completely. While the JSR-223 API is not specific to a single scripting
607language, it was designed with languages with a more or less Java-like
608object model in mind: languages such as Javascript, Python, Ruby, which
609have a concept of "class" or "object" with "fields" and "methods". Lisp
610is a bit different, so certain adaptations were made, and in one case a
611method has been left unimplemented since it does not map at all to Lisp.
612
613\subsubsection{The ScriptEngine}
614
615The main interface defined by JSR-223, \code{javax.script.ScriptEngine},
616is implemented by the class
617\code{org.armedbear.lisp.scripting.AbclScriptEngine}. \code{AbclScriptEngine}
618is a singleton, reflecting the fact that ABCL is a singleton as
619well. You can obtain an instance of \code{AbclScriptEngine} using the
620\code{AbclScriptEngineFactory} or by using the service provider
621mechanism through \code{ScriptEngineManager} (refer to the
622\texttt{javax.script} documentation).
623
624\subsection{Start-up and configuration file}
625
626At start-up (i.e. when its constructor is invoked, as part of the
627static initialization phase of \code{AbclScriptEngineFactory}) the ABCL
628script engine attempts to load an "init file" from the classpath
629(\texttt{/abcl-script-config.lisp}). If present, this file can be used to
630customize the behavior of the engine, by setting a number of
631variables in the \code{ABCL-SCRIPT} package. Here is a list of the available
632variables:
633
634\begin{description}
635\item[\texttt{*use-throwing-debugger*}] controls whether ABCL uses a
636  non-standard debugging hook function to throw a Java exception
637  instead of dropping into the debugger in case of unhandled error
638  conditions.
639  \begin{itemize}
640  \item Default value: \texttt{T}
641  \item Rationale: it is more convenient for Java programmers using
642    Lisp as a scripting language to have it return exceptions to Java
643    instead of handling them in the Lisp world.
644  \item Known Issues: the non-standard debugger hook has been reported
645    to misbehave in certain circumstances, so consider disabling it if
646    it doesn't work for you.
647  \end{itemize}
648\item[\texttt{*launch-swank-at-startup*}] If true, Swank will be launched at
649  startup. See \texttt{*swank-dir*} and \texttt{*swank-port*}.
650  \begin{itemize}
651  \item Default value: \texttt{NIL}
652  \end{itemize}
653\item[\texttt{*swank-dir*}] The directory where Swank is installed. Must be set
654  if \texttt{*launch-swank-at-startup*} is true.
655\item[\texttt{*swank-port*}] The port where Swank will listen for
656  connections. Must be set if \texttt{*launch-swank-at-startup*} is
657  true.
658  \begin{itemize}
659  \item Default value: 4005
660  \end{itemize}
661\end{description}
662
663Additionally, at startup the AbclScriptEngine will \code{(require
664  'asdf)} - in fact, it uses asdf to load Swank.
665
666\subsection{Evaluation}
667
668Code is read and evaluated in the package \code{ABCL-SCRIPT-USER}. This
669packages \texttt{USE}s the \code{COMMON-LISP}, \code{JAVA} and
670\code{ABCL-SCRIPT} packages. Future versions of the script engine might
671make this default package configurable. The \code{CL:LOAD} function is
672used under the hood for evaluating code, and thus the behavior of
673\code{LOAD} is guaranteed. This allows, among other things,
674\code{IN-PACKAGE} forms to change the package in which the loaded code
675is read.
676
677It is possible to evaluate code in what JSR-223 calls a
678``ScriptContext'' (basically a flat environment of name$\rightarrow$value
679pairs). This context is used to establish special bindings for all the
680variables defined in it; since variable names are strings from Java's
681point of view, they are first interned using \code{READ-FROM-STRING} with, as
682usual, \code{ABCL-SCRIPT-USER} as the default package. Variables are declared
683special because CL's \code{LOAD}, \code{EVAL} and \code{COMPILE}
684functions work in a null lexical environment and would ignore
685non-special bindings.
686
687Contrary to what the function \code{LOAD} does, evaluation of a series
688of forms returns the value of the last form instead of T, so the
689evaluation of short scripts does the Right Thing.
690
691\subsection{Compilation}
692
693AbclScriptEngine implements the \code{javax.script.Compilable}
694interface. Currently it only supports compilation using temporary
695files. Compiled code, returned as an instance of
696\texttt{javax.script.CompiledScript}, is read, compiled and executed by
697default in the \texttt{ABCL-SCRIPT-USER} package, just like evaluated
698code.  In contrast to evaluated code, though, due to the way the ABCL
699compiler works, compiled code contains no reference to top-level
700self-evaluating objects (like numbers or strings). Thus, when evaluated,
701a piece of compiled code will return the value of the last
702non-self-evaluating form: for example the code ``\code{(do-something)
703  42}'' will return 42 when interpreted, but will return the result of
704(do-something) when compiled and later evaluated. To ensure consistency
705of behavior between interpreted and compiled code, make sure the last
706form is always a compound form - at least \code{(identity
707some-literal-object)}. Note that this issue should not matter in real
708code, where it is unlikely a top-level self-evaluating form will appear
709as the last form in a file (in fact, the Common Lisp load function
710always returns \texttt{T} upon success; with JSR-223 this policy has been changed
711to make evaluation of small code snippets work as intended).
712
713\subsection{Invocation of functions and methods}
714
715AbclScriptEngine implements the \code{javax.script.Invocable}
716interface, which allows to directly call Lisp functions and methods,
717and to obtain Lisp implementations of Java interfaces. This is only
718partially possible with Lisp since it has functions, but not methods -
719not in the traditional OO sense, at least, since Lisp methods are not
720attached to objects but belong to generic functions. Thus, the method
721\code{invokeMethod()} is not implemented and throws an
722\texttt{UnsupportedOperationException} when called. The \code{invokeFunction()}
723method should be used to call both regular and generic functions.
724
725\subsection{Implementation of Java interfaces in Lisp}
726
727ABCL can use the Java reflection-based proxy feature to implement Java
728interfaces in Lisp. It has several built-in ways to implement an
729interface, and supports definition of new ones. The
730\code{JAVA:JMAKE-PROXY} generic function is used to make such
731proxies. It has the following signature:
732
733\code{jmake-proxy interface implementation \&optional lisp-this ==> proxy}
734
735\code{interface} is a Java interface metaobject (e.g. obtained by
736invoking \code{jclass}) or a string naming a Java
737interface. \code{implementation} is the object used to implement the
738interface - several built-in methods of jmake-proxy exist for various
739types of implementations. \code{lisp-this} is an object passed to the
740closures implementing the Lisp "methods" of the interface, and
741defaults to \code{NIL}.
742
743The returned proxy is an instance of the interface, with methods
744implemented with Lisp functions.
745
746Built-in interface-implementation types include:
747
748\begin{itemize}
749\item a single Lisp function which upon invocation of any method in
750  the interface will be passed the method name, the Lisp-this object,
751  and all the parameters. Useful for interfaces with a single method,
752  or to implement custom interface-implementation strategies.
753\item a hash-map of method-name $\rightarrow$ Lisp function mappings. Function
754  signature is \code{(lisp-this \&rest args)}.
755\item a Lisp package. The name of the Java method to invoke is first
756  transformed in an idiomatic Lisp name (\code{javaMethodName} becomes
757  \code{JAVA-METHOD-NAME}) and a symbol with that name is searched in
758  the package. If it exists and is fbound, the corresponding function
759  will be called. Function signature is as the hash-table case.
760\end{itemize}
761
762This functionality is exposed by the class \code{AbclScriptEngine} via
763the two methods \code{getInterface(Class)} and
764\code{getInterface(Object, Class)}. The former returns an interface
765implemented with the current Lisp package, the latter allows the
766programmer to pass an interface-implementation object which will in turn
767be passed to the \code{jmake-proxy} generic function.
768
769\subsection{Implementation of Java classes in Lisp}
770
771See \code{JAVA:JNEW-RUNTIME-CLASS} on \ref{JAVA:JNEW-RUNTIME-CLASS}.
772
773
774\chapter{Implementation Dependent Extensions}
775
776As outlined by the CLHS ANSI conformance guidelines, we document the
777extensions to the Armed Bear Lisp implementation made accessible to
778the user by virtue of being an exported symbol in the JAVA, THREADS,
779or EXTENSIONS packages.
780
781\section{JAVA}
782
783\subsection{Modifying the JVM CLASSPATH}
784
785The JAVA:ADD-TO-CLASSPATH generic functions allows one to add the
786specified pathname or list of pathnames to the current classpath
787used by ABCL, allowing the dynamic loading of JVM objects:
788
789\begin{listing-lisp}
790CL-USER> (add-to-classpath "/path/to/some.jar")
791\end{listing-lisp}
792
793N.b \code{ADD-TO-CLASSPATH} only affects the classloader used by ABCL
794(the value of the special variable \code{JAVA:*CLASSLOADER*}. It has
795no effect on Java code outside ABCL.
796
797\subsection{Creating a synthetic Java Class at Runtime}
798
799See \code{JAVA:JNEW-RUNTIME-CLASS} on \ref{JAVA:JNEW-RUNTIME-CLASS}.
800
801% include autogen docs for the JAVA package.
802\include{java}
803
804\section{THREADS}
805
806The extensions for handling multithreaded execution are collected in
807the \code{THREADS} package.  Most of the abstractions in Doug Lea's
808excellent \code{java.util.concurrent} packages may be manipulated
809directly via the JSS contrib to great effect.
810
811% include autogen docs for the THREADS package.
812\include{threads}
813
814\section{EXTENSIONS}
815
816The symbols in the EXTENSIONS package (nicknamed ``EXT'') constitutes
817extensions to the \textsc{ANSI} standard that are potentially useful to the
818user.  They include functions for manipulating network sockets,
819running external programs, registering object finalizers, constructing
820reference weakly held by the garbage collector and others.
821
822See \cite{RHODES2007} for a generic function interface to the native
823\textsc{JVM} contract for \code{java.util.List}.
824
825% include autogen docs for the EXTENSIONS package.
826\include{extensions}
827
828\chapter{Beyond ANSI}
829
830Naturally, in striving to be a useful contemporary Common Lisp
831implementation, ABCL endeavors to include extensions beyond the ANSI
832specification which are either widely adopted or are especially useful
833in working with the hosting \textsc{JVM}.
834
835\section{Compiler to Java 5 Bytecode}
836
837The \code{CL:COMPILE-FILE} interface emits a packed fasl format whose
838Pathname has the type  ``abcl''.  These fasls are operating system neutral
839byte archives packaged by the zip compression format which contain
840artifacts whose loading \code{CL:LOAD} understands.
841
842\section{Pathname}
843
844We implement an extension to the \code{CL:PATHNAME} that allows for
845the description and retrieval of resources named in a
846\textsc{URI} \footnote{A \textsc{URI} is essentially a superset of
847  what is commonly understood as a \textsc{URL} We sometime suse the
848  term URL as shorthand in describing the URL Pathnames, even though
849  the corresponding encoding is more akin to a URI as described in
850  RFC3986 \cite{rfc3986}.}  scheme that the \textsc{JVM}
851``understands''.  By definition, support is built-in into the JVM to
852access the ``http'' and ``https'' schemes but additional protocol
853handlers may be installed at runtime by having \textsc{JVM} symbols
854present in the \code{sun.net.protocol.dynamic} package. See
855\cite{maso2000} for more details.
856
857\textsc{ABCL} has created specializations of the ANSI
858\code{CL:PATHNAME} object to enable to use of \textsc{URI}s to address
859dynamically loaded resources for the JVM.  The \code{EXT:URL-PATHNAME}
860specialization has a corresponding \textsc{URI} whose canonical
861representation is defined to be the \code{NAMESTRING} of the
862\code{CL:PATHNAME}. The \code{EXT:JAR-PATHNAME} extension further
863specializes the the \code{EXT:URL-PATHNAME} to provide access to
864components of zip archives. 
865
866% RDF description of type hierarchy
867% TODO Render via some LaTeX mode for graphviz?
868\begin{verbatim}
869  @prefix ext:   <http://abcl.not.org/cl-packages/extensions/> .
870  @prefix cl:    <http://abcl.not.org/cl-packages/common-lisp/> .
871 
872  <ext:jar-pathname> a <ext:url-pathname>.
873  <ext:url-pathname> a <cl:pathname>.
874  <cl:logical-pathname> a <cl:pathname> .
875\end{verbatim}
876
877\label{EXTENSIONS:URL-PATHNAME}
878\index{URL-PATHNAME}
879
880\label{EXTENSIONS:JAR-PATHNAME}
881\index{JAR-PATHNAME}
882
883Both the \code{EXT:URL-PATHNAME} and \code{EXT:JAR-PATHNAME} objects
884may be used anywhere a \code{CL:PATHNAME} is accepted with the
885following caveats:
886
887\begin{itemize}
888
889\item A stream obtained via \code{CL:OPEN} on a \code{CL:URL-PATHNAME}
890  cannot be the target of write operations.
891
892\index{URI}
893\item Any results of canonicalization procedures performed on the
894  underlying \textsc{URI} are discarded between resolutions (i.e. the
895  implementation does not attempt to cache the results of current name
896  resolution of the representing resource unless it is requested to be
897  resolved.)  Upon resolution, any canonicalization procedures
898  followed in resolving the resource (e.g. following redirects) are
899  discarded.  Users may programatically initiate a new, local
900  computation of the resolution of the resource by applying the
901  \code{CL:TRUENAME} function to a \code{EXT:URL-PATHNAME} object.
902  Depending on the reliability and properties of your local
903  \textsc{REST} infrastructure, these results may not necessarily be
904  idempotent over time\footnote {See \cite{evenson2011} for the draft
905    of the publication of the technical details}.
906
907\end{itemize}
908
909The implementation of \code{EXT:URL-PATHNAME} allows the \textsc{ABCL}
910user to dynamically load code from the network.  For example,
911\textsc{Quicklisp} (\cite{quicklisp}) may be completely installed from
912the \textsc{REPL} as the single form:
913
914\begin{listing-lisp}
915  CL-USER> (load "http://beta.quicklisp.org/quicklisp.lisp")
916\end{listing-lisp}
917
918will load and execute the Quicklisp setup code.
919
920The implementation currently breaks \textsc{ANSI} conformance by allowing the
921types able to be \code{CL:READ} for the \code{DEVICE} to return a possible \code{CONS} of
922\code{CL:PATHNAME} objects.  %% citation from CLHS needed.
923
924In order to ``smooth over'' the bit about types being \code{CL:READ}
925from \code{CL:PATHNAME} components, we extend the semantics for the
926usual PATHNAME merge semantics when \code{*DEFAULT-PATHNAME-DEFAULTS*}
927contains a \code{EXT:JAR-PATHNAME} with the ``do what I mean''
928algorithm described in \ref{section:conformance} on page
929\pageref{section:conformance}.
930
931%See \ref{_:quicklisp} on page \pageref{_:quicklisp}.
932
933\subsubsection{Implementation}
934
935The implementation of these extensions stores all the additional
936information in the \code{CL:PATHNAME} object itself in ways that while strictly
937speaking are conformant, nonetheless may trip up libraries that don't
938expect the following:
939
940\begin{itemize}
941\item \code{DEVICE} can be either a string denoting a drive letter
942  under \textsc{DOS} or a list of exactly one or two elements.  If
943  \code{DEVICE} is a list, it denotes a \code{EXT:JAR-PATHNAME}, with
944  the entries containing \code{CL:PATHNAME} objects which describe the
945  outer and (possibly inner) locations of the jar
946  archive \footnote{The case of inner and outer
947    \code{EXT:JAR-PATHNAME} \ref{EXT:JAR-PATHNAME} arises when zip
948    archives themselves contain zip archives which is the case when
949    the ABCL fasl is included in the abcl.jar zip archive.}.
950
951\item A \code{EXT:URL-PATHNAME} always has a \code{HOST} component that is a
952  property list.  The values of the \code{HOST} property list are
953  always character strings.  The allowed keys have the following meanings:
954  \begin{description}
955  \item[:SCHEME] Scheme of URI ("http", "ftp", "bundle", etc.)
956  \item[:AUTHORITY] Valid authority according to the URI scheme.  For
957    "http" this could be "example.org:8080".
958  \item[:QUERY] The query of the \textsc{URI} 
959  \item[:FRAGMENT] The fragment portion of the \textsc{URI}
960  \end{description}
961
962\item In order to encapsulate the implementation decisions for these
963  meanings, the following functions provide a SETF-able API for
964  reading and writing such values: \code{URL-PATHNAME-QUERY},
965  \code{URL-PATHNAME-FRAGMENT}, \code{URL-PATHNAME-AUTHORITY}, and
966  \code{URL-PATHNAME-SCHEME}.  The specific subtype of a Pathname may
967  be determined with the predicates \code{PATHNAME-URL-P} and
968  \code{PATHNAME-JAR-P}.
969
970\label{EXTENSIONS:URL-PATHNAME-SCHEME}
971\index{URL-PATHNAME-SCHEME}
972
973\label{EXTENSIONS:URL-PATHNAME-FRAGMENT}
974\index{URL-PATHNAME-FRAGMENT}
975
976\label{EXTENSIONS:URL-PATHNAME-AUTHORITY}
977\index{URL-PATHNAME-AUTHORITY}
978
979\label{EXTENSIONS:PATHNAME-URL-P}
980\index{PATHNAME-URL-P}
981
982\label{EXTENSIONS:URL-PATHNAME-QUERY}
983\index{URL-PATHNAME-QUERY}
984
985\end{itemize}
986
987\section{Package-Local Nicknames}
988\label{sec:pack-local-nickn}
989
990ABCL allows giving packages local nicknames: they allow short and
991easy-to-use names to be used without fear of name conflict associated
992with normal nicknames.\footnote{Package-local nicknames were originally
993developed in SBCL.}
994
995A local nickname is valid only when inside the package for which it
996has been specified. Different packages can use same local nickname for
997different global names, or different local nickname for same global
998name.
999
1000Symbol \code{:package-local-nicknames} in \code{*features*} denotes the
1001support for this feature.
1002
1003\index{DEFPACKAGE}
1004The options to \code{defpackage} are extended with a new option
1005\code{:local-nicknames (local-nickname actual-package-name)*}.
1006
1007The new package has the specified local nicknames for the corresponding
1008actual packages.
1009
1010Example:
1011\begin{listing-lisp}
1012(defpackage :bar (:intern "X"))
1013(defpackage :foo (:intern "X"))
1014(defpackage :quux (:use :cl)
1015  (:local-nicknames (:bar :foo) (:foo :bar)))
1016(find-symbol "X" :foo) ; => FOO::X
1017(find-symbol "X" :bar) ; => BAR::X
1018(let ((*package* (find-package :quux)))
1019  (find-symbol "X" :foo))               ; => BAR::X
1020(let ((*package* (find-package :quux)))
1021  (find-symbol "X" :bar))               ; => FOO::X
1022\end{listing-lisp}
1023
1024\index{PACKAGE-LOCAL-NICKNAMES}
1025--- Function: \textbf{package-local-nicknames} [\textbf{ext}] \textit{package-designator}
1026
1027\begin{adjustwidth}{5em}{5em}
1028  Returns an ALIST of \code{(local-nickname . actual-package)}
1029  describing the nicknames local to the designated package.
1030
1031  When in the designated package, calls to \code{find-package} with any
1032  of the local-nicknames will return the corresponding actual-package
1033  instead. This also affects all implied calls to \code{find-package},
1034  including those performed by the reader.
1035
1036  When printing a package prefix for a symbol with a package local
1037  nickname, the local nickname is used instead of the real name in order
1038  to preserve print-read consistency.
1039\end{adjustwidth}
1040
1041\index{PACKAGE-LOCALLY-NICKNAMED-BY-LIST}
1042--- Function: \textbf{package-locally-nicknamed-by-list} [\textbf{ext}] \textit{package-designator}
1043
1044\begin{adjustwidth}{5em}{5em}
1045Returns a list of packages which have a local nickname for the
1046designated package.
1047\end{adjustwidth}
1048
1049\index{ADD-PACKAGE-LOCAL-NICKNAME}
1050--- Function: \textbf{add-package-local-nickname} [\textbf{ext}] \textit{local-nickname actual-package \&optional package-designator}
1051
1052\begin{adjustwidth}{5em}{5em}
1053  Adds \code{local-nickname} for \code{actual-package} in the designated
1054  package, defaulting to current package. \code{local-nickname} must be
1055  a string designator, and \code{actual-package} must be a package
1056  designator.
1057
1058  Returns the designated package.
1059
1060  Signals an error if \code{local-nickname} is already a package local
1061  nickname for a different package, or if \code{local-nickname} is one
1062  of "CL", "COMMON-LISP", or, "KEYWORD", or if \code{local-nickname} is
1063  a global name or nickname for the package to which the nickname would
1064  be added.
1065
1066  When in the designated package, calls to \code{find-package} with the
1067  \code{local-nickname} will return the package the designated
1068  \code{actual-package} instead. This also affects all implied calls to
1069  \code{find-package}, including those performed by the reader.
1070
1071  When printing a package prefix for a symbol with a package local
1072  nickname, local nickname is used instead of the real name in order to
1073  preserve print-read consistency.
1074\end{adjustwidth}
1075
1076\index{REMOVE-PACKAGE-LOCAL-NICKNAME}
1077--- Function: \textbf{remove-package-local-nickname} [\textbf{ext}] \textit{old-nickname \&optional package-designator}
1078
1079\begin{adjustwidth}{5em}{5em}
1080  If the designated package had \code{old-nickname} as a local nickname
1081  for another package, it is removed. Returns true if the nickname
1082  existed and was removed, and \code{nil} otherwise.
1083\end{adjustwidth}
1084
1085
1086         
1087\section{Extensible Sequences}
1088
1089See Rhodes2007 \cite{RHODES2007} for the design.
1090
1091The SEQUENCE package fully implements Christopher Rhodes' proposal for
1092extensible sequences.  These user extensible sequences are used
1093directly in \code{java-collections.lisp} provide these CLOS
1094abstractions on the standard Java collection classes as defined by the
1095\code{java.util.List} contract.
1096
1097%% an Example of using java.util.Lisp in Lisp would be nice
1098
1099This extension is not automatically loaded by the implementation.   It
1100may be loaded via:
1101
1102\begin{listing-lisp}
1103CL-USER> (require 'java-collections)
1104\end{listing-lisp}
1105
1106if both extensible sequences and their application to Java collections
1107is required, or
1108
1109\begin{listing-lisp}
1110CL-USER> (require 'extensible-sequences)
1111\end{listing-lisp}
1112
1113if only the extensible sequences API as specified in \cite{RHODES2007} is
1114required.
1115
1116Note that \code{(require 'java-collections)} must be issued before
1117\code{java.util.List} or any subclass is used as a specializer in a \textsc{CLOS}
1118method definition (see the section below).
1119
1120\section{Extensions to CLOS}
1121
1122\subsection{Metaobject Protocol}
1123
1124\textsc{ABCL} implements the metaobject protocol for \textsc{CLOS} as
1125specified in \textsc{(A)MOP}.  The symbols are exported from the
1126package \code{MOP}.
1127
1128Contrary to the AMOP specification and following \textsc{SBCL}'s lead,
1129the metaclass \code{funcallable-standard-object} has
1130\code{funcallable-standard-class} as metaclass instead of
1131\code{standard-class}.
1132
1133\subsection{Specializing on Java classes}
1134
1135There is an additional syntax for specializing the parameter of a
1136generic function on a java class, viz. \code{(java:jclass CLASS-STRING)}
1137where \code{CLASS-STRING} is a string naming a Java class in dotted package
1138form.
1139
1140For instance the following specialization would perhaps allow one to
1141print more information about the contents of a java.util.Collection
1142object
1143
1144\begin{listing-lisp}
1145(defmethod print-object ((coll (java:jclass "java.util.Collection"))
1146                         stream)
1147  ;;; ...
1148)
1149\end{listing-lisp}
1150
1151If the class had been loaded via a classloader other than the original
1152the class you wish to specialize on, one needs to specify the
1153classloader as an optional third argument.
1154
1155\begin{listing-lisp}
1156
1157(defparameter *other-classloader*
1158  (jcall "getBaseLoader" cl-user::*classpath-manager*))
1159 
1160(defmethod print-object
1161   ((device-id (java:jclass "dto.nbi.service.hdm.alcatel.com.NBIDeviceID"
1162                            *other-classloader*))
1163    stream)
1164  ;;; ...
1165)
1166\end{listing-lisp}
1167
1168\section{Extensions to the Reader}
1169
1170We implement a special hexadecimal escape sequence for specifying 32
1171bit characters to the Lisp reader\footnote{This represents a
1172  compromise with contemporary in 2011 32bit hosting architecures for
1173  which we wish to make text processing efficient.  Should the User
1174  require more control over \textsc{UNICODE} processing we recommend Edi Weisz'
1175  excellent work with \textsc|{FLEXI-STREAMS}  which we fully support}, namely we
1176allow a sequences of the form \verb~#\U~\emph{\texttt{xxxx}} to be processed
1177by the reader as character whose code is specified by the hexadecimal
1178digits \emph{\texttt{xxxx}}.  The hexadecimal sequence may be one to four digits
1179long.  % Why doesn't ALEXANDRIA work?
1180
1181Note that this sequence is never output by the implementation.  Instead,
1182the corresponding Unicode character is output for characters whose
1183code is greater than 0x00ff.
1184
1185\section{Overloading of the CL:REQUIRE Mechanism}
1186
1187The \code{CL:REQUIRE} mechanism is overloaded by attaching these
1188semantics to the execution of \code{REQUIRE} on the following symbols:
1189
1190\begin{description}
1191
1192  \item{\code{ASDF}} 
1193    Loads the \textsc{ASDF} implementation shipped
1194    with the implementation.  After \textsc{ASDF} has been loaded in
1195    this manner, symbols passed to \code{CL:REQUIRE} which are
1196    otherwise unresolved, are passed to ASDF for a chance for
1197    resolution.  This means, for instance if \code{CL-PPCRE} can be
1198    located as a loadable \textsc{ASDF} system \code{(require
1199      'cl-ppcre)} is equivalent to \code{(asdf:load-system
1200      'cl-ppcre)}.
1201
1202  \item{\code{ABCL-CONTRIB}} 
1203    Locates and pushes the toplevel contents of
1204    ``abcl-contrib.jar'' into the \textsc{ASDF} central registry. 
1205
1206    \begin{enumerate}
1207      \item \code{abcl-asdf} 
1208        Functions for loading JVM artifacts
1209        dynamically, hooking into ASDF 3 objects where possible.
1210      \item \code{asdf-jar} 
1211        Package addressable JVM artifacts via
1212        \code{abcl-asdf} descriptions as a single binary artifact
1213        including recursive dependencies.
1214      \item \code{mvn} 
1215        These systems name common JVM artifacts from
1216        the distributed pom.xml graph of Maven Aether:
1217        \begin{enumerate}
1218          \item \code{jna} 
1219            Dynamically load 'jna.jar' version 4.0.0
1220            from the network \footnote{This loading can be inhibited
1221              if, at runtime, the Java class corresponding
1222              ``:classname'' clause of the system defition is present.}
1223        \end{enumerate}
1224      \item \code{quicklisp-abcl} Boot a local Quicklisp installation
1225        via the ASDF:IRI type introduced bia ABCL-ASDF.
1226
1227\begin{listing-lisp}
1228CL-USER> (asdf:load-system :quicklisp-abcl :force t)
1229\end{listing-lisp}
1230
1231\end{enumerate}
1232
1233\end{description}
1234
1235The user may extend the \code{CL:REQUIRE} mechanism by pushing
1236function hooks into \code{SYSTEM:*MODULE-PROVIDER-FUNCTIONS*}.  Each
1237such hook function takes a single argument containing the symbol
1238passed to \code{CL:REQUIRE} and returns a non-\code{NIL} value if it
1239can successful resolve the symbol.
1240
1241\section{JSS extension of the Reader by SHARPSIGN-DOUBLE-QUOTE}
1242
1243The JSS contrib consitutes an additional, optional extension to the
1244reader in the definition of the \code{SHARPSIGN-DOUBLE-QUOTE}
1245(``\#\"'') reader macro.  See section \ref{section:jss} on page
1246\pageref{section:jss} for more information.
1247
1248\section{ASDF}
1249
1250asdf-3.1.0.49 (see \cite{asdf}) is packaged as core component of \textsc{ABCL},
1251but not initialized by default, as it relies on the \textsc{CLOS} subsystem
1252which can take a bit of time to start \footnote{While this time is
1253  ``merely'' on the order of seconds for contemporary 2011 machines,
1254  for applications that need to initialize quickly, for example a web
1255  server, this time might be unnecessarily long}.  The packaged \textsc{ASDF}
1256may be loaded by the \textsc{ANSI} \code{REQUIRE} mechanism as
1257follows:
1258
1259\begin{listing-lisp}
1260CL-USER> (require 'asdf)
1261\end{listing-lisp}
1262
1263\chapter{Contrib}
1264
1265The \textsc{ABCL} contrib is packaged as a separate jar archive usually named
1266\code{abcl-contrib.jar} or possibly something like
1267\code{abcl-contrib-1.3.0.jar}.  The contrib jar is not loaded by the
1268implementation by default, and must be first intialized by the
1269\code{REQUIRE} mechanism before using any specific contrib:
1270
1271\begin{listing-lisp}
1272CL-USER> (require 'abcl-contrib)
1273\end{listing-lisp}
1274
1275\section{abcl-asdf}
1276
1277This contrib enables an additional syntax for \textsc{ASDF} system
1278definition which dynamically loads \textsc{JVM} artifacts such as jar
1279archives via encapsulation of the Maven build tool.  The Maven Aether
1280component can also be directly manipulated by the function associated
1281with the \code{ABCL-ASDF:RESOLVE-DEPENDENCIES} symbol.
1282
1283%ABCL specific contributions to ASDF system definition mainly
1284%concerned with finding JVM artifacts such as jar archives to be
1285%dynamically loaded.
1286
1287
1288When loaded, abcl-asdf adds the following objects to \textsc{ASDF}:
1289\code{JAR-FILE}, \code{JAR-DIRECTORY}, \code{CLASS-FILE-DIRECTORY} and
1290\code{MVN}, exporting them (and others) as public symbols.
1291
1292\subsection{Referencing Maven Artifacts via ASDF}
1293
1294Maven artifacts may be referenced within \textsc{ASDF} system
1295definitions, as the following example references the
1296\code{log4j-1.4.9.jar} JVM artifact which provides a widely-used
1297abstraction for handling logging systems:
1298
1299\begin{listing-lisp}
1300;;;; -*- Mode: LISP -*-
1301(in-package :asdf)
1302
1303(defsystem :log4j
1304  :components ((:mvn "log4j/log4j" :version "1.4.9")))
1305\end{listing-lisp}
1306
1307\subsection{API}
1308
1309We define an API for \textsc{ABCL-ASDF} as consisting of the following
1310ASDF classes:
1311
1312\code{JAR-DIRECTORY}, \code{JAR-FILE}, and
1313\code{CLASS-FILE-DIRECTORY} for JVM artifacts that have a currently
1314valid pathname representation.
1315
1316Both the MVN and IRI classes descend from ASDF-COMPONENT, but do not
1317directly have a filesystem location.
1318
1319For use outside of ASDF system definitions, we currently define one
1320method, \code{ABCL-ASDF:RESOLVE-DEPENDENCIES} which locates,
1321downloads, caches, and then loads into the currently executing JVM
1322process all recursive dependencies annotated in the Maven pom.xml
1323graph.
1324
1325\subsection{Directly Instructing Maven to Download JVM Artifacts}
1326
1327Bypassing \textsc{ASDF}, one can directly issue requests for the Maven
1328artifacts to be downloaded
1329
1330\begin{listing-lisp}
1331CL-USER> (abcl-asdf:resolve-dependencies "com.google.gwt"
1332                                         "gwt-user")
1333WARNING: Using LATEST for unspecified version.
1334"/Users/evenson/.m2/repository/com/google/gwt/gwt-user/2.4.0-rc1
1335/gwt-user-2.4.0-rc1.jar:/Users/evenson/.m2/repository/javax/vali
1336dation/validation-api/1.0.0.GA/validation-api-1.0.0.GA.jar:/User
1337s/evenson/.m2/repository/javax/validation/validation-api/1.0.0.G
1338A/validation-api-1.0.0.GA-sources.jar"
1339\end{listing-lisp}
1340
1341To actually load the dependency, use the \code{JAVA:ADD-TO-CLASSPATH} generic
1342function:
1343
1344\begin{listing-lisp}
1345CL-USER> (java:add-to-classpath
1346          (abcl-asdf:resolve-dependencies "com.google.gwt"
1347                                          "gwt-user"))
1348\end{listing-lisp}
1349
1350Notice that all recursive dependencies have been located and installed
1351locally from the network as well.
1352
1353More extensive documentations and examples can be found at
1354\url{http://abcl.org/svn/tags/1.3.0/contrib/abcl-asdf/README.markdown}.
1355
1356
1357\section{asdf-jar}
1358
1359The asdf-jar contrib provides a system for packaging \textsc{ASDF}
1360systems into jar archives for \textsc{ABCL}.  Given a running
1361\textsc{ABCL} image with loadable \textsc{ASDF} systems the code in
1362this package will recursively package all the required source and
1363fasls in a jar archive.
1364
1365The documentation for this contrib can be found at
1366\url{http://abcl.org/svn/tags/1.3.0/abcl-contrib/asdf-jar/README.markdown}.
1367
1368
1369\section{jss}
1370\label{section:jss}
1371
1372To one used to the more universal syntax of Lisp pairs upon which the
1373definition of read and compile time macros is quite
1374natural \footnote{See Graham's ``On Lisp''
1375  http://lib.store.yahoo.net/lib/paulgraham/onlisp.pdf.}, the Java
1376syntax available to the Java programmer may be said to suck.  To
1377alleviate this situation, the JSS contrib introduces the
1378\code{SHARPSIGN-DOUBLE-QUOTE} (\code{\#"}) reader macro, which allows
1379the the specification of the name of invoking function as the first
1380element of the relevant s-expr which tends to be more congruent to how
1381Lisp programmers seem to be wired to think.
1382
1383While quite useful, we don't expect that the JSS contrib will be the
1384last experiment in wrangling Java from Common Lisp.
1385
1386\subsection{JSS usage}
1387
1388Example:
1389
1390\begin{listing-lisp}
1391CL-USER> (require 'abcl-contrib)
1392==> ("ABCL-CONTRIB")
1393CL-USER> (require 'jss)
1394==> ("JSS")
1395CL-USER) (#"getProperties" 'java.lang.System)
1396==> #<java.util.Properties {java.runtime.name=Java.... {2FA21ACF}>
1397CL-USER) (#"propertyNames" (#"getProperties" 'java.lang.System))
1398==> #<java.util.Hashtable$Enumerator java.util.Has.... {36B4361A}>
1399\end{listing-lisp} %$ <-- un-confuse Emacs font-lock
1400
1401Some more information on jss can be found in its documentation at
1402\url{http://abcl.org/svn/tags/1.3.0/contrib/jss/README.markdown}
1403
1404\section{jfli}
1405\label{section:jfli}
1406
1407The contrib contains a pure-Java version of JFLI.
1408
1409\url{http://abcl.org/svn/tags/1.3.0/contrib/jfli/README}.
1410
1411
1412\section{asdf-install}
1413
1414The asdf-install contrib provides an implementation of ASDF-INSTALL.
1415Superseded by Quicklisp (see Xach2011 \cite{quicklisp}).
1416
1417The \code{require} of the \code{asdf-install} symbol has the side
1418effect of pushing the directory \verb+~/.asdf-install-dir/systems/+ into
1419the value of the \textsc{ASDF} central registry in
1420\code{asdf:*central-registry*}, providing a convenient mechanism for
1421stashing \textsc{ABCL} specific system definitions for convenient
1422access.
1423
1424\url{http://abcl.org/tags/1.3.0/contrib/asdf-install/README}.
1425
1426
1427\chapter{History}
1428\index{History}
1429
1430\textsc{ABCL} was originally the extension language for the J editor, which was
1431started in 1998 by Peter Graves.  Sometime in 2003, a whole lot of
1432code that had previously not been released publically was suddenly
1433committed that enabled ABCL to be plausibly termed an emergent ANSI
1434Common Lisp implementation candidate.
1435
1436From 2006 to 2008, Peter manned the development lists, incorporating
1437patches as made sense.  After a suitable search, Peter nominated Erik
1438H\"{u}lsmann to take over the project.
1439
1440In 2008, the implementation was transferred to the current
1441maintainers, who have strived to improve its usability as a
1442contemporary Common Lisp implementation.
1443
1444On October 22, 2011, with the publication of this Manual explicitly
1445stating the conformance of Armed Bear Common Lisp to \textsc{ANSI}, we
1446released abcl-1.0.0.  We released abcl-1.0.1 as a maintainence release
1447on January 10, 2012.
1448
1449In December 2012, we revised the implementation by adding
1450\textsc{(A)MOP} with the release of abcl-1.1.0.  We released
1451abcl-1.1.1 as a maintainence release on Feburary 14, 2013.
1452
1453At the beginning of June 2013, we enhanced the stability of the
1454implementation with the release of abcl-1.2.1.
1455
1456In January 2014, we introduced the Fourth Edition of the implementation
1457with abcl-1.3.0.
1458
1459\appendix 
1460
1461\chapter{The MOP Dictionary}
1462
1463\include{mop}
1464
1465\chapter{The SYSTEM Dictionary}
1466
1467The public interfaces in this package are subject to change with
1468\textsc{ABCL} 1.4.
1469
1470\include{system}
1471
1472\chapter{The JSS Dictionary}
1473
1474These public interfaces are provided by the JSS contrib.
1475
1476\include{jss}
1477
1478\bibliography{abcl}
1479\bibliographystyle{alpha}
1480
1481\printindex
1482
1483\end{document}
Note: See TracBrowser for help on using the repository browser.