373 lines
20 KiB
HTML
373 lines
20 KiB
HTML
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>CLHS: Issue CONSTANT-COMPILABLE-TYPES Writeup</TITLE>
|
|
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
|
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
|
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
|
<LINK REL=TOP HREF="../Front/index.htm">
|
|
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
|
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
|
<LINK REL=PREV HREF="../Issues/iss080_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss081.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss082_w.htm">
|
|
</HEAD>
|
|
<BODY>
|
|
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss080_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss081.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss082_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue CONSTANT-COMPILABLE-TYPES Writeup</H2>
|
|
|
|
<PRE><B>Forum:</B> Compiler<P>
|
|
<B>Issue:</B> <A HREF="iss081.htm">CONSTANT-COMPILABLE-TYPES</A><P>
|
|
<B>References:</B> CLtL pp. 56, 77-80, 324<P>
|
|
Issue <A HREF="iss083.htm">CONSTANT-MODIFICATION</A><P>
|
|
Issue <A HREF="iss079.htm">CONSTANT-CIRCULAR-COMPILATION</A><P>
|
|
Issue <A HREF="iss080.htm">CONSTANT-COLLAPSING</A><P>
|
|
Issue <A HREF="iss282.htm">QUOTE-SEMANTICS</A><P>
|
|
Issue <A HREF="iss215.htm">LOAD-OBJECTS</A><P>
|
|
Issue <A HREF="iss082.htm">CONSTANT-FUNCTION-COMPILATION</A><P>
|
|
<B>Category:</B> CLARIFICATION, ADDITION<P>
|
|
<B>Edit history:</B> 11/07/88, V1 by Cris Perdue<P>
|
|
11/14/88, V2 by Cris Perdue<P>
|
|
11/22/88, V3 by Cris Perdue<P>
|
|
12/20/88, V4 by Cris Perdue<P>
|
|
01/06/89, V5 by Sandra Loosemore (minor editorial<P>
|
|
clarifications, expand discussion)<P>
|
|
03/05/89, V6 by Cris Perdue (more response to comments,<P>
|
|
especially from Moon and and from Loosemore)<P>
|
|
03/05/89, V7 by Loosemore (more editorial tweaks)<P>
|
|
03/13/89, V8 by Loosemore (discussion)<P>
|
|
03/22/89, V9 by Loosemore (restructure)<P>
|
|
04/03/89, V10 by Loosemore (amendment)<P>
|
|
<B>Status:</B> Proposal SPECIFY passed March 1989.<P>
|
|
<P>
|
|
<B>Problem description:<P>
|
|
</B><P>
|
|
CLtL does not specify what objects can be in compiled constants and it<P>
|
|
does not say what relationship there is to be between the constant<P>
|
|
passed to the compiler and the one that is established by compiling<P>
|
|
and then loading its file. Relevant remarks in CLtL concerning file<P>
|
|
compilation and the definition of <A REL=DEFINITION HREF="../Body/s_quote.htm#quote"><B>QUOTE</B></A> suggest that the compiler<P>
|
|
handles constants in ways that are not actually possible.<P>
|
|
<P>
|
|
<P>
|
|
<B>Introduction to the proposal:<P>
|
|
</B><P>
|
|
The proposal <A HREF="iss081.htm">CONSTANT-COMPILABLE-TYPES:SPECIFY</A> attempts to spell out<P>
|
|
what types can appear in compiled constants, and what it means when<P>
|
|
they appear.<P>
|
|
<P>
|
|
The key is a definition of an equivalence relationship between Lisp<P>
|
|
objects, "similarity as constants". Code passed through the file<P>
|
|
compiler and then loaded must behave as though quoted constants in it<P>
|
|
are "similar" to quoted constants in the corresponding source code.<P>
|
|
<P>
|
|
Issue <A HREF="iss080.htm">CONSTANT-COLLAPSING</A> addresses the issue of whether, for two<P>
|
|
objects that are not <A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A> in the source code (but which are similar as<P>
|
|
constants), the corresponding objects in the compiled code may be<P>
|
|
<A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A>.<P>
|
|
<P>
|
|
Issue <A HREF="iss079.htm">CONSTANT-CIRCULAR-COMPILATION</A> addresses the issue of whether,<P>
|
|
for two objects that are <A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A> in the source code, the corresponding<P>
|
|
objects in the compiled code must also be <A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A>.<P>
|
|
<P>
|
|
Comments within the text of the proposal are enclosed in double angle<P>
|
|
brackets, <<like this>>.<P>
|
|
<P>
|
|
<P>
|
|
Proposal: <A HREF="iss081.htm">CONSTANT-COMPILABLE-TYPES:SPECIFY</A><P>
|
|
<P>
|
|
An object may be used as a quoted constant processed by <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A><P>
|
|
if the compiler can guarantee that the resulting constant established<P>
|
|
by loading the compiled file is "similar as a constant" to the<P>
|
|
original.<P>
|
|
<P>
|
|
Some types of objects, such as streams, are not supported in constants<P>
|
|
processed by the file compiler. Such objects may not portably appear<P>
|
|
as constants in code processed with <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>. Conforming<P>
|
|
implementations are required to handle such objects either by having<P>
|
|
the compiler and/or loader reconstruct an equivalent copy of the<P>
|
|
object in some implementation-specific manner; or by having the<P>
|
|
compiler signal an error.<P>
|
|
<P>
|
|
Of the types supported in constants, some are treated as aggregate<P>
|
|
objects. For these types, being similar as constants is defined<P>
|
|
recursively. We say that an object of these types has certain "basic<P>
|
|
attributes", and to be similar as a constant to another object, the<P>
|
|
values of the corresponding attributes of the two objects must also be<P>
|
|
similar as constants.<P>
|
|
<P>
|
|
This kind of definition has problems with any circular or "infinitely<P>
|
|
recursive" object such as a list that is an element of itself. We use<P>
|
|
the idea of depth-limited comparison, and say that two objects are<P>
|
|
similar as constants if they are similar at all finite levels. This<P>
|
|
idea is implicit in the definitions below, and applies in all the<P>
|
|
places where attributes of two objects are required to be similar as<P>
|
|
constants.<P>
|
|
<P>
|
|
The following terms are used throughout this proposal:<P>
|
|
<P>
|
|
The term "constant" refers to a quoted or self-evaluating constant,<P>
|
|
not a named (<A REL=DEFINITION HREF="../Body/m_defcon.htm#defconstant"><B>defconstant</B></A>) constant.<P>
|
|
<P>
|
|
The term "source code" is used to refer to the objects constructed<P>
|
|
when <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> calls <A REL=DEFINITION HREF="../Body/f_rd_rd.htm#read"><B>READ</B></A>, and additional objects constructed by<P>
|
|
macroexpansion during <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>.<P>
|
|
<P>
|
|
The term "compiled code" is used to refer to objects constructed by <P>
|
|
<A REL=DEFINITION HREF="../Body/f_load.htm#load"><B>LOAD</B></A>.<P>
|
|
<P>
|
|
Two objects are defined to be "similar as a constant" if and only if<P>
|
|
they are both of one of the types listed below and satisfy the<P>
|
|
additional requirements listed for that type.<P>
|
|
<P>
|
|
Number<P>
|
|
<P>
|
|
Two numbers are similar as constants if they are of the same type<P>
|
|
and represent the same mathematical value.<P>
|
|
<P>
|
|
Character<P>
|
|
<P>
|
|
Two characters are similar as constants if they both represent<P>
|
|
the same character.<P>
|
|
<P>
|
|
<<Note that this definition has to depend on the results of the<P>
|
|
Character Set proposals. The intent is that this be compatible with<P>
|
|
how <A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A> is defined on characters.>><P>
|
|
<P>
|
|
Symbol<P>
|
|
<P>
|
|
Issue <A HREF="iss063.htm">COMPILE-FILE-SYMBOL-HANDLING</A> defines how the file compiler<P>
|
|
and loader handle interned symbols.<P>
|
|
<P>
|
|
An uninterned symbol in the source code is similar as a constant<P>
|
|
to an uninterned symbol in the compiled code if their print names<P>
|
|
are similar as constants.<P>
|
|
<P>
|
|
Package<P>
|
|
<P>
|
|
A package in the source code is similar as a constant to a package in<P>
|
|
the compiled code if their names are similar as constants. Note that<P>
|
|
the loader finds the corresponding package object as if by calling<P>
|
|
<A REL=DEFINITION HREF="../Body/f_find_p.htm#find-package"><B>FIND-PACKAGE</B></A> with the package name as an argument. An error is<P>
|
|
signalled if no package of that name exists at load time.<P>
|
|
<P>
|
|
Random-state<P>
|
|
<P>
|
|
Let us say that two random-states are functionally equivalent if <P>
|
|
applying <A REL=DEFINITION HREF="../Body/f_random.htm#random"><B>RANDOM</B></A> to them repeatedly always produces the same <P>
|
|
pseudo-random numbers in the same order. <P>
|
|
<P>
|
|
Two random-states are similar as constants if and only if copies of<P>
|
|
them made via <A REL=DEFINITION HREF="../Body/f_mk_rnd.htm#make-random-state"><B>MAKE-RANDOM-STATE</B></A> are functionally equivalent.<P>
|
|
<P>
|
|
Note that a constant <A REL=DEFINITION HREF="../Body/t_rnd_st.htm#random-state"><B>random-state</B></A> object cannot be used as the "state"<P>
|
|
argument to the function <A REL=DEFINITION HREF="../Body/f_random.htm#random"><B>RANDOM</B></A> (because <A REL=DEFINITION HREF="../Body/f_random.htm#random"><B>RANDOM</B></A> side-effects this<P>
|
|
data <A REL=DEFINITION HREF="../Body/f_docume.htm#structure"><B>structure</B></A>).<P>
|
|
<P>
|
|
Cons<P>
|
|
<P>
|
|
Two conses are similar as constants if the values of their respective<P>
|
|
<A REL=DEFINITION HREF="../Body/f_car_c.htm#car"><B>CAR</B></A> and <A REL=DEFINITION HREF="../Body/f_car_c.htm#cdr"><B>CDR</B></A> attributes are similar as constants.<P>
|
|
<P>
|
|
Array<P>
|
|
<P>
|
|
Two arrays are similar as constants if the corresponding values each<P>
|
|
of the following attributes are similar as constants:<P>
|
|
<P>
|
|
For 1-dimensional arrays:<P>
|
|
<A REL=DEFINITION HREF="../Body/f_length.htm#length"><B>LENGTH</B></A>, <A REL=DEFINITION HREF="../Body/f_ar_ele.htm#array-element-type"><B>ARRAY-ELEMENT-TYPE</B></A>, and <A REL=DEFINITION HREF="../Body/f_elt.htm#elt"><B>ELT</B></A> for all valid indices.<P>
|
|
<P>
|
|
For arrays of other dimensions:<P>
|
|
<A REL=DEFINITION HREF="../Body/f_ar_d_1.htm#array-dimensions"><B>ARRAY-DIMENSIONS</B></A>, <A REL=DEFINITION HREF="../Body/f_ar_ele.htm#array-element-type"><B>ARRAY-ELEMENT-TYPE</B></A>, <A REL=DEFINITION HREF="../Body/f_aref.htm#aref"><B>AREF</B></A> for all valid indices.<P>
|
|
<P>
|
|
In addition, if the array in the source code is a <A REL=DEFINITION HREF="../Body/t_smp_ar.htm#simple-array"><B>SIMPLE-ARRAY</B></A>, then<P>
|
|
the corresponding array in the compiled code must also be a<P>
|
|
<A REL=DEFINITION HREF="../Body/t_smp_ar.htm#simple-array"><B>SIMPLE-ARRAY</B></A>. If the array in the source code is displaced, has a<P>
|
|
fill pointer, or is adjustable, the corresponding array in the<P>
|
|
compiled code is permitted to lack any or all of these qualities.<P>
|
|
<P>
|
|
Hash Table <P>
|
|
<P>
|
|
Two hash tables are similar as constants if they meet the following<P>
|
|
three requirements:<P>
|
|
<P>
|
|
(1) They both have the same test (e.g., they are both <A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A> hash tables).<P>
|
|
<P>
|
|
(2) There is a unique one-to-one correspondence between the keys of<P>
|
|
the two tables, such that the corresponding keys are similar as<P>
|
|
constants.<P>
|
|
<P>
|
|
(3) For all keys, the values associated with two corresponding keys<P>
|
|
are similar as constants.<P>
|
|
<P>
|
|
If there is more than one possible one-to-one correspondence between<P>
|
|
the keys of the two tables, the results are unspecified. A conforming<P>
|
|
program cannot use such a table as a constant.<P>
|
|
<P>
|
|
Pathname<P>
|
|
<P>
|
|
Two pathnames are similar as constants if all corresponding <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A><P>
|
|
components are similar as constants.<P>
|
|
<P>
|
|
Stream, Readtable, Method<P>
|
|
<P>
|
|
Objects of these types are not supported in compiled constants.<P>
|
|
<P>
|
|
Function<P>
|
|
<P>
|
|
Issue <A HREF="iss082.htm">CONSTANT-FUNCTION-COMPILATION</A> specifies how the compiler and<P>
|
|
loader handle constant functions.<P>
|
|
<P>
|
|
<P>
|
|
Structure, Standard-object<P>
|
|
<P>
|
|
<<There is a cl-cleanup issue, <A HREF="iss215.htm">LOAD-OBJECTS</A>, pending which proposes<P>
|
|
a mechanism for dealing with objects.>><P>
|
|
<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
For the benefit of users, this proposal tries to define a fairly large<P>
|
|
set of types that all Common Lisp implementations are to handle. It<P>
|
|
also attempts to leave room for implementations to differ. Some<P>
|
|
implementations have made opposing choices because the language<P>
|
|
doesn't specify one over the other. Some implementations already<P>
|
|
handle constants that this proposal defines as not valid in Common<P>
|
|
Lisp programs, and that is useful to users of those systems.<P>
|
|
Different implementors have different amounts of resources to apply to<P>
|
|
their system, and implementations differ in their whole approach in<P>
|
|
some cases.<P>
|
|
<P>
|
|
This proposal appears to reflect user demand and appears not to exceed<P>
|
|
the capabilities of most implementations of the language.<P>
|
|
<P>
|
|
<P>
|
|
<B>Current practice:<P>
|
|
</B><P>
|
|
>From Gail Zacharias (Nov 14): "Coral pretty much implements this<P>
|
|
proposal (I think we currently coalesce hash table keys, but that's<P>
|
|
just a bug that will be fixed). We also fasdump packages (using the<P>
|
|
package name) and compiled functions (but not foreign functions). For<P>
|
|
symbols, we dump the name, and if (roughly speaking) the symbol would<P>
|
|
get printed with a package prefix, we also dump the package name and<P>
|
|
load the symbol into that package (otherwise it gets loaded into the<P>
|
|
current load-time package)."<P>
|
|
<P>
|
|
>From David Gray (Nov 9): "The Explorer can compile constant functions,<P>
|
|
read tables, and hash tables; an error is signalled for a stream. A<P>
|
|
package object used to break the compiler but in release 5 it has been<P>
|
|
fixed to generate instructions to call <A REL=DEFINITION HREF="../Body/f_find_p.htm#find-package"><B>FIND-PACKAGE</B></A> on the package<P>
|
|
name at load time." (Nov 15): [The Explorer does not guarantee<P>
|
|
retention of displaced-to and displaced-index-offset attributes.]<P>
|
|
"The Explorer also does not currently support dumping closures (either<P>
|
|
compiled or evaluated), although non-closure compiled functions can be<P>
|
|
dumped."<P>
|
|
<P>
|
|
>From David Moon (Jan 24): "Symbolics Genera current practice: aside<P>
|
|
from some current bugs we have with circular structures of certain<P>
|
|
types and with preserving the identity of CONSes under <A REL=DEFINITION HREF="../Body/f_eq.htm#eq"><B>EQ</B></A>, this is<P>
|
|
more or less consistent with our current practice, if you made the<P>
|
|
changes implied by my earlier comments. We preserve the :displaced-to<P>
|
|
and :fill-pointer array attributes. I doubt that we do what the<P>
|
|
proposal says for hash-tables, readtables, and random-states. We<P>
|
|
support dumping compiled and interpreted functions, but not closures,<P>
|
|
which in effect means we don't support dumping functions."<P>
|
|
<P>
|
|
>From Sandra Loosemore (Mar 3): "UCL currently can handle only<P>
|
|
constants that are of type number, character, symbol, cons,<P>
|
|
<A REL=DEFINITION HREF="../Body/t_smp_ve.htm#simple-vector"><B>simple-vector</B></A>, or string (which it turns into <A REL=DEFINITION HREF="../Body/t_smp_st.htm#simple-string"><B>simple-string</B></A>). It<P>
|
|
signals an error if an attempt is made to compile any other kind of<P>
|
|
object as a constant."<P>
|
|
<P>
|
|
<P>
|
|
<B>Adoption cost:<P>
|
|
</B><P>
|
|
Not known. Probably moderate or low -- for most implementations. The<P>
|
|
cost would be to implementors rather than users since this part of the<P>
|
|
language is currently underspecified. The author believes the cost<P>
|
|
will be reasonable for KCL, an implementation where there is some<P>
|
|
concern about this issue.<P>
|
|
<P>
|
|
This proposal is close to compatible with the Franz, Lucid, Coral,<P>
|
|
Texas Instruments, and Symbolics implementations. It is probably<P>
|
|
compatible or nearly compatible with other "Lisp Machine"<P>
|
|
implementations.<P>
|
|
<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
Users would be able to use aggregate objects in constants with<P>
|
|
confidence about the behavior of their code.<P>
|
|
<P>
|
|
<P>
|
|
<B>Conversion cost:<P>
|
|
</B><P>
|
|
Where this proposal *requires* different behavior than an existing<P>
|
|
implementation, there is a conversion cost for users of that<P>
|
|
implementation. It appears that this cost will be small, less than<P>
|
|
the cost of leaving things unspecified.<P>
|
|
<P>
|
|
<P>
|
|
<B>Esthetics:<P>
|
|
</B><P>
|
|
Since there is no adequate definition at present, a fuller definition<P>
|
|
would be more esthetic.<P>
|
|
<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
This proposal does leave some user-visible attributes of objects<P>
|
|
unspecified across the compile-and-load process, except that they must<P>
|
|
be consistent with the attributes that must be retained. This<P>
|
|
situation is a compromise between the desire for full specification on<P>
|
|
the one hand, and on the other hand the desire to leave freedom for<P>
|
|
different implementations to remain different and to support some<P>
|
|
optimizations such as compacting hash tables and "simplifying" arrays.<P>
|
|
<P>
|
|
Proposals will be entertained for tighter specification of datatypes<P>
|
|
such as arrays.<P>
|
|
<P>
|
|
The definition of similarity for random-states supports the<P>
|
|
possibility of random states that are immutable because of being in<P>
|
|
compiled constants.<P>
|
|
<P>
|
|
Readtables need not be supported by an implementation. If a <A REL=DEFINITION HREF="../Body/t_rdtabl.htm#readtable"><B>readtable</B></A><P>
|
|
contains only symbols to represent functions, here is Cris Perdue's<P>
|
|
suggested spec for similarity of readtables:<P>
|
|
<P>
|
|
Character syntax type for each character in the table;<P>
|
|
function for each readmacro character, mappings for<P>
|
|
dispatch macros; whether terminating or nonterminating<P>
|
|
for each readmacro.<P>
|
|
<P>
|
|
Interest has been expressed by a number of people including users, in<P>
|
|
support for user-definable "dumping" of CLOS objects and <A REL=DEFINITION HREF="../Body/f_docume.htm#structure"><B>structure</B></A><P>
|
|
instances. The cleanup issue <A HREF="iss215.htm">LOAD-OBJECTS</A> deals with this.<P>
|
|
<P>
|
|
This subsumes the issue CONSTANT-ARRAY-ATTRIBUTES.<P>
|
|
<P>
|
|
Earlier versions of this proposal specified an additional constraint<P>
|
|
on uninterned symbols, requiring EQLness to be preserved across the<P>
|
|
entire file. However, this special case was removed because it was<P>
|
|
thought that including it in this issue made its presentation<P>
|
|
unnecessarily complicated, since preservation of EQLness is really a<P>
|
|
separate issue (<A HREF="iss079.htm">CONSTANT-CIRCULAR-COMPILATION</A>). A consequence of the<P>
|
|
decision to remove the special casing for uninterned symbols is that,<P>
|
|
unless we accept one of the two <A HREF="iss079.htm">CONSTANT-CIRCULAR-COMPILATION</A><P>
|
|
proposals that requires EQLness of constants to be preserved, the<P>
|
|
behavior for uninterned symbols will be rather strange. PCL will<P>
|
|
reportedly break if uninterned symbols that are <A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A> in the source code<P>
|
|
do not remain <A REL=DEFINITION HREF="../Body/a_eql.htm#eql"><B>EQL</B></A> in the compiled code.<P>
|
|
</PRE>
|
|
<HR>
|
|
|
|
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
|
|
|
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
|
</BODY>
|
|
</HTML>
|