source: branches/1.1.x/doc/manual/abcl.tex @ 14282

Last change on this file since 14282 was 14282, checked in by Mark Evenson, 8 years ago

manual: Updates to manual for ABCL 1.1.

Preface to the second addition. TODO TeX.

Added Appendix for SYSTEM and JSS packages. TODO Need to fix LaTex?.

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