Changeset 13660
- Timestamp:
- 10/21/11 21:28:49 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/abcl/doc/manual/abcl.tex
r13657 r13660 6 6 \begin{document} 7 7 \title{A Manual for Armed Bear Common Lisp} 8 \date{October 2 0, 2011}8 \date{October 21, 2011} 9 9 \author{Mark~Evenson, Erik~Huelsmann, Alessio~Stalla, Ville~Voutilainen} 10 10 … … 13 13 \chapter{Introduction} 14 14 15 Armed Bear is a mostlyconforming implementation of the ANSI Common15 Armed Bear is a (mostly) conforming implementation of the ANSI Common 16 16 Lisp standard. This manual documents the Armed Bear Common Lisp 17 17 implementation for users of the system. 18 18 19 19 \subsection{Version} 20 This manual corresponds to abcl-0.28.0, as yet unreleased. 20 This manual corresponds to abcl-1.0.0, released on October 22, 2011. 21 22 \subsection{License} 23 24 The implementation is licensed under the terms of the GPL v2 of June 25 1991 with the ``classpath-exception'' that makes its deployment in 26 commercial settings quite reasonable. The license is viral in the 27 sense that if you change the implementation, and redistribute those 28 changes, you are required to provide the source to those changes back 29 to be merged with the public trunk. 30 31 \subsection{Contributors} 32 33 % TODO format this better, optionally link to URI 34 35 % Thanks for the markup 36 Philipp Marek 37 38 % Thanks for the whacky IKVM stuff and keeping the flame alive 39 Douglas Miles 40 41 % Thanks for JSS 42 Alan Ruttenberg 43 44 and of course 45 46 Peter Graves 21 47 22 48 \chapter{Running} 23 49 24 50 \textsc{ABCL} is packaged as a single jar file usually named either 25 ``abcl.jar'' or possibly``abcl- 0.28.0.jar'' if you are using a26 versioned package from your system vendor. This byte archive can be 27 executed under the control of a suitable JVM by using the ``-jar'' 28 option toparse the manifest, and select the named class29 (\code{org.armedbear.lisp.Main}) for execution :51 ``abcl.jar'' or possibly``abcl-1.0.0.jar'' if one is using a versioned 52 package from your system vendor. This byte archive can be executed 53 under the control of a suitable JVM by using the ``-jar'' option to 54 parse the manifest, and select the named class 55 (\code{org.armedbear.lisp.Main}) for execution, viz: 30 56 31 57 \begin{listing-shell} … … 36 62 to be in your path. 37 63 38 To make it easier to facilitate the use of ABCL in tool chains (such as 39 SLIME) the invocation is wrapped in a Bourne shell script under UNIX 40 or a DOS command script under Windows so that ABCL may be executed 41 simply as: 64 To make it easier to facilitate the use of ABCL in tool chains (such 65 as SLIME \footnote{SLIME is the Superior Lisp Mode for Interaction 66 under Emacs}) the invocation is wrapped in a Bourne shell script 67 under UNIX or a DOS command script under Windows so that ABCL may be 68 executed simply as: 42 69 43 70 \begin{listing-shell} … … 72 99 \end{verbatim} 73 100 74 All of the command line arguments which follow the occurrence of ``-- ''101 All of the command line arguments which follow the occurrence of ``----'' 75 102 are passed into a list bound to the EXT:*COMMAND-LINE-ARGUMENT-LIST* 76 103 variable. … … 83 110 84 111 The user's home directory is determined by the value of the JVM system 85 property ``user.home''. 112 property ``user.home''. This value may--or may not--correspond to the 113 value of the HOME system environment variable at the discretion of the 114 JVM implementation that \textsc{ABCL} finds itself hosted upon. 86 115 87 116 \chapter{Conformance} 88 117 89 118 \section{ANSI Common Lisp} 90 \textsc{ABCL} is currently a non-conforming ANSI Common Lisp implementation due91 to the followingissues:119 \textsc{ABCL} is currently a (non)-conforming ANSI Common Lisp 120 implementation due to the following known issues: 92 121 93 122 \begin{itemize} 94 123 \item The generic function signatures of the DOCUMENTATION symbol do 95 124 not match the CLHS. 96 \item The TIME form does not return a proper VALUES to its caller. 125 \item The TIME form does not return a proper VALUES environment to 126 its caller. 97 127 \end{itemize} 98 128 99 ABCL aims to be be a fully conforming ANSI Common Lisp 100 implementation. Any other behavior should be reported as a bug. 129 Somewhat confusingly, this statement of non-conformance in the 130 accompanying user documentation fullfills the requirements that 131 \textsc{ABCL} is a conforming ANSI Common Lisp implementation 132 according to the CLHS \footnote{Common Lisp Hyperspec language 133 reference document.}. Clarifications to this point are solicited. 134 135 ABCL aims to be be a fully conforming ANSI Common Lisp implementation. 136 Any other behavior should be reported as a bug. 101 137 102 138 \section{Contemporary Common Lisp} 103 139 In addition to ANSI conformance, \textsc{ABCL} strives to implement features 104 expected of a contemporary Common Lisp. 140 expected of a contemporary Common Lisp \footnote{i.e. a Lisp of the 141 post 2005 Renaissance} 142 143 \subsection{Deficiencies} 144 The following known problems detract from \textsc{ABCL} being a proper 145 contemporary Comon Lisp. 105 146 \begin{itemize} 106 \item Incomplete (A)MOP 107 % N.B. 147 \item An incomplete implementation of a properly named metaobject 148 protocol (viz. (A)MOP \footnote{Another Metaobject Protocol} ) 149 150 % N.b. 108 151 % TODO go through AMOP with symbols, starting by looking for 109 152 % matching function signature. 110 153 % XXX is this really blocking ANSI conformance? Answer: we have 111 154 % to start with such a ``census'' to determine what we have. 112 \item Incomplete Streams: need suitable abstraction between ANSI 113 and Gray streams. 155 156 \item Incomplete streams abstraction, in that \textsc{ABCL} needs suitable 157 abstraction between ANSI and Gray streams. The streams could be 158 optimized to the JVM NIO abstractions at great profit for binary 159 byte-level manipulations. 114 160 161 \item Incomplete documentation (missing docstrings from exported 162 symbols. 163 115 164 \end{itemize} 116 165 117 \chapter{Interaction with host JVM} 118 166 \chapter{Interaction with Hosting JVM} 167 168 % Plan of Attack 169 % 119 170 % describe calling Java from Lisp, and calling Lisp from Java, 120 171 % probably in two separate sections. Presumably, we can partition our 121 172 % audience into those who are more comfortable with Java, and those 122 173 % that are more comforable with Lisp 174 175 The Armed Bear Common Lisp implementation is hosted on a Java Virtual 176 Machine. This chapter describes the mechanisms by which the 177 implementation interacts with that hosting mechanism. 123 178 124 179 \section{Lisp to Java} … … 144 199 \subsection{Low-level Java API} 145 200 146 There's a higher level Java API defined in the 147 \ref{topic:Higher level Java API: JSS}(JSS package) which is available 148 in the \code{contrib/} directory. This package is described later in this149 document. This section covers the lower level API directly available 150 after evaluating\code{(require 'JAVA)}.151 152 \subsubsection{Calling Java object methods}153 154 There are two ways to call a Java object method in the basicAPI:201 We define a higher level Java API in the \ref{topic:Higher level Java 202 API: JSS}(JSS package) which is available in the \code{contrib/} \ref{topic:contrib} 203 directory. This package is described later in this document. This 204 section covers the lower level API directly available after evaluating 205 \code{(require 'JAVA)}. 206 207 \subsubsection{Calling Java Object Methods} 208 209 There are two ways to call a Java object method in the low-level (basic) API: 155 210 156 211 \begin{itemize} … … 177 232 returned. 178 233 179 Once you have a reference to the method, you can call it using \code{JAVA:JCALL}, 180 which takes the method as the first argument. The second argument is the 181 object instance to call the method on, or \code{NIL} in case of a static method. 182 Any remaining parameters are used as the remaining arguments for the call. 234 Once one has a reference to the method, one may invoke it using 235 \code{JAVA:JCALL}, which takes the method as the first argument. The 236 second argument is the object instance to call the method on, or 237 \code{NIL} in case of a static method. Any remaining parameters are 238 used as the remaining arguments for the call. 183 239 184 240 \subsubsection{Calling Java object methods: dynamic dispatch} … … 191 247 select the best matching method and dispatch the call. 192 248 193 \subsubsection{Dynamic dispatch: caveats}249 \subsubsection{Dynamic dispatch: Caveats} 194 250 195 251 Dynamic dispatch is performed by using the Java reflection … … 212 268 \begin{listing-java} 213 269 java.lang.IllegalAccessException: Class ... can 214 not access a member of class java.util.zip.ZipFile $2 with modifiers270 not access a member of class java.util.zip.ZipFile\$2 with modifiers 215 271 "public" 216 272 at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65) … … 318 374 an intended class around and values which can be converted to Lisp values will 319 375 be converted. 320 321 376 322 377 \section{Lisp from Java} … … 596 651 \subsubsection{Compilation} 597 652 598 AbclScriptEngine implements the javax.script.Compilable653 AbclScriptEngine implements the \code{javax.script.Compilable} 599 654 interface. Currently it only supports compilation using temporary 600 655 files. Compiled code, returned as an instance of … … 691 746 \end{listing-lisp} 692 747 693 N B\code{add-to-classpath} only affects the classloader used by ABCL748 N.b \code{add-to-classpath} only affects the classloader used by ABCL 694 749 (the value of the special variable \code{JAVA:*CLASSLOADER*}. It has 695 750 no effect on Java code outside ABCL. … … 702 757 \section{THREADS} 703 758 704 Multithreading 759 The extensions for handling multithreaded execution are collected in 760 the \code{THREADS} package. Most of the abstractions in Doug Lea's 761 excellent \code{java.util.concurrent} packages may be manipulated 762 directly via the JSS contrib to great effect. 705 763 706 764 \subsection{API} … … 740 798 \section{Pathname} 741 799 742 We impl ment an extension to the Pathname that allows for the800 We implement an extension to the Pathname that allows for the 743 801 description and retrieval of resources named in a URI scheme that the 744 802 JVM ``understands''. Support is built-in to the ``http'' and … … 752 810 representation is defined to be the NAMESTRING of the Pathname. 753 811 754 PATHNAME : URL-PATHNAME : JAR-PATHNAME 755 756 Both URL-PATHNAME and JAR-PATHNAME may be used anu where will a 757 PATHNAME is accepted witht the following caveats 758 759 A stream obtained via OPEN on a URL-PATHNAME cannot be the target of 760 write operations. 761 762 No canonicalization is performed on the underlying URI (i.e. the 812 \begin{verbatim} 813 JAR-PATHNAME isa URL-PATHNAME isa PATHNAME 814 \end{verbatim} 815 816 Both URL-PATHNAME and JAR-PATHNAME may be used anywhere a PATHNAME is 817 accepted with the following caveats: 818 819 \begin{itemize} 820 821 \item A stream obtained via OPEN on a URL-PATHNAME cannot be the 822 target of write operations. 823 824 \item No canonicalization is performed on the underlying URI (i.e. the 763 825 implementation does not attempt to compute the current name of the 764 826 representing resource unless it is requested to be resolved.) Upon … … 766 828 resource (e.g. following redirects) are discarded. 767 829 830 \end{itemize} 831 768 832 The implementation of URL-PATHNAME allows the ABCL user to laod dynamically 769 833 code from the network. For example, for Quicklisp. … … 776 840 777 841 \ref{XACH2011} 842 843 \subsubsection{Implementation} 844 845 \textsc{DEVICE} either a string denoting a drive letter under DOS or a cons 846 specifying a \textsc{URL-PATHNAME}. 778 847 779 848 \section{Extensible Sequences} … … 845 914 We implement a special hexadecimal escape sequence for specifying 846 915 characters to the Lisp reader, namely we allow a sequences of the form 847 \# \textbackslash Uxxxx to be processed by the reader as character whose code is 848 specified by the hexadecimal digits ``xxxx''. The hexadecimal sequence 849 must be exactly four digits long, padded by leading zeros for values 850 less than 0x1000. 916 \# \textbackslash Uxxxx to be processed by the reader as character 917 whose code is specified by the hexadecimal digits ``xxxx''. The 918 hexadecimal sequence must be exactly four digits long \footnote{This 919 represents a compromise with contemporary in 2011 32bit hosting 920 architecures for which we wish to make text processing efficient. 921 Should the User require more control over UNICODE processing we 922 recommend Edi Weisz' excellent work with FLEXI-STREAMS which we 923 fully support}, padded by leading zeros for values less than 0x1000. 851 924 852 925 Note that this sequence is never output by the implementation. Instead, … … 857 930 858 931 The JSS contrib consitutes an additional, optional extension to the 859 reader in the definition of the #\" reader macro.932 reader in the definition of the \#\" reader macro. 860 933 861 934 \section{ASDF} 862 935 863 asdf-2.017 is packaged as core component of ABCL, but not intialized864 by default, as it relies on the CLOS subsystem which can take a bit of 865 t ime to initialize. It may be initialized by the ANSI936 asdf-2.017.22 is packaged as core component of ABCL, but not 937 intialized by default, as it relies on the CLOS subsystem which can 938 take a bit of time to initialize. It may be initialized by the ANSI 866 939 \textsc{REQUIRE} mechanism as follows: 867 940 … … 876 949 This contrib to ABCL enables an additional syntax for ASDF system 877 950 definition which dynamically loads JVM artifacts such as jar archives 878 via a Maven encapsulation. 879 880 The following ASDF components are added: JAR-FILE, JAR-DIRECTORY, CLASS-FILE-DIRECTORY 881 and MVN. 951 via a Maven encapsulation. The Maven Aether can also be directly 952 manipulated by the function associated with the RESOLVE-DEPENDENCIES symbol. 953 954 %ABCL specific contributions to ASDF system definition mainly concerned 955 %with finding JVM artifacts such as jar archives to be dynamically loaded. 956 957 958 The following ASDF components are added: \textsc{JAR-FILE}, \textsc{JAR-DIRECTORY}, 959 \textsc{CLASS-FILE-DIRECTORY} and \textsc{MVN}. 960 961 962 963 \subsection{ABCL-ASDF Examples} 964 965 \begin{listing-lisp} 966 ;;;; -*- Mode: LISP -*- 967 (in-package :asdf) 968 969 (defsystem :log4j 970 :components ((:mvn "log4j/log4j" 971 :version "1.4.9"))) 972 \end{listing-lisp} 973 974 \subsection{abcl-asdf API} 975 976 We define an API as consisting of the following ASDF classes: 977 978 \textsc{JAR-DIRECTORY}, \textsc{JAR-FILE}, and 979 \textsc{CLASS-FILE-DIRECTORY} for JVM artifacts that have a currently 980 valid pathname representation 981 982 And the MVN and IRI classes descend from ASDF-COMPONENT, but do not 983 directly have a filesystem location. 984 985 For use outside of ASDF, we currently define one method, 986 \textsc{RESOLVE-DEPENDENCIES} which locates, downloads, caches, and then loads 987 into the currently executing JVM process all recursive dependencies 988 annotated in the Maven pom.xml graph. 989 990 \subsection{ABCL-ASDF Example 2} 991 992 Bypassing ASDF, one can directly issue requests for the Maven 993 artifacts to be downloaded 994 995 \begin{listing-lisp} 996 CL-USER> (abcl-asdf:resolve-dependencies "com.google.gwt" "gwt-user") 997 WARNING: Using LATEST for unspecified version. 998 "/Users/evenson/.m2/repository/com/google/gwt/gwt-user/2.4.0-rc1/gwt-user-2.4.0-rc1.jar:/Users/evenson/.m2/repository/javax/validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA.jar:/Users/evenson/.m2/repository/javax/validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA-sources.jar" 999 \end{listing-lisp} 1000 1001 To actually load the dependency, use the JAVA:ADD-TO-CLASSPATH generic 1002 function: 1003 1004 \begin{listing-lisp} 1005 CL-USER> (java:add-to-classpath (abcl-asdf:resolve-dependencies "com.google.gwt" "gwt-user")) 1006 \end{listing-lisp} 1007 1008 Notice that all recursive dependencies have been located and installed 1009 locally from the network as well. 1010 882 1011 883 1012 \section{asdf-jar} … … 888 1017 required source and fasls in a jar archive. 889 1018 890 \section{abcl-asdf}891 892 ABCL specific contributions to ASDF system definition mainly concerned893 with finding JVM artifacts such as jar archives to be dynamically loaded.894 895 \subsection{ABCL-ASDF Examples}896 897 \begin{listing-lisp}898 ;;;; -*- Mode: LISP -*-899 (in-package :asdf)900 901 (defsystem :log4j902 :components ((:mvn "log4j/log4j"903 :version "1.4.9")))904 \end{listing-lisp}905 906 \subsection{abcl-asdf API}907 908 We define an API as consisting of the following ASDF classes:909 910 \textsc[JAR-DIRECTORY}, \textsc{JAR-FILE}, and911 \textsc{CLASS-FILE-DIRECTORY} for JVM artifacts that have a currently912 valid pathname representation913 914 And the MVN and IRI classes descend from ASDF-COMPONENT, but do not915 directly have a filesystem location.916 917 For use outside of ASDF, we currently define one method,918 \textsc{RESOLVE-DEPENDENCIES} which locates, downloads, caches, and then loads919 into the currently executing JVM process all recursive dependencies920 annotated in the Maven pom.xml graph.921 922 \subsection{ABCL-ASDF Example 2}923 924 Bypassing ASDF, one can directly issue requests for the Maven925 artifacts to be downloaded926 927 \begin{listing-lisp}928 CL-USER> (abcl-asdf:resolve-dependencies "com.google.gwt" "gwt-user")929 WARNING: Using LATEST for unspecified version.930 "/Users/evenson/.m2/repository/com/google/gwt/gwt-user/2.4.0-rc1/gwt-user-2.4.0-rc1.jar:/Users/evenson/.m2/repository/javax/validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA.jar:/Users/evenson/.m2/repository/javax/validation/validation-api/1.0.0.GA/validation-api-1.0.0.GA-sources.jar"931 \end{listing-lisp}932 933 Notice that all recursive dependencies have been located and installed934 as well.935 936 937 1019 \section{jss} 938 1020 … … 959 1041 960 1042 ABCL was originally the extension language for the J editor, which was 961 started in 1998 by Peter Graves. Sometime in 2003, it seems that a 962 lot of code that had previously not been released publically was 963 suddenly committed that enabled ABCL to be plausibly termed an ANSI 964 Common Lisp implementation. 1043 started in 1998 by Peter Graves. Sometime in 2003, a whole lot of 1044 code that had previously not been released publically was suddenly 1045 committed that enabled ABCL to be plausibly termed an emergent ANSI 1046 Common Lisp implementation canidate. 1047 1048 From 2006 to 2008, Peter manned the development lists, incorporating 1049 patches as made sense. After a suitable search, Peter nominated Erik 1050 Huelsmann to take over the project. 965 1051 966 1052 In 2008, the implementation was transferred to the current … … 968 1054 contemporary Common Lisp implementation. 969 1055 970 In 201x, with the publication of this Manual explicitly stating the 971 conformance of Armed Bear Common Lisp to ANSI, we release abcl-1.0. 1056 On October 22, 2011, with the publication of this Manual explicitly 1057 stating the conformance of Armed Bear Common Lisp to ANSI, we released 1058 abcl-1.0.0. 972 1059 973 1060 … … 982 1069 libraries. \url{http://www.quicklisp.org/} 983 1070 1071 [RHODES2007]: Christopher Rhodes 1072 984 1073 985 1074 \end{document} … … 987 1076 % TODO 988 1077 % 1. Create mechanism for swigging DocString and Lisp docs into 989 % sections .990 1078 % sections ('grovel.lisp') 1079
Note: See TracChangeset
for help on using the changeset viewer.