preds.tex

%Part{Preds, Root = "CLM.MSS"}
%Chapter of Common Lisp Manual.  Copyright 1984, 1988, 1989 Guy L. Steele Jr.

\clearpage\def\pagestatus{FINAL PROOF}

\ifx \rulang\Undef

\chapter{Predicates}
\label{PREDS}

A \emph{predicate} is a function that tests for some condition involving
its arguments and returns {\false} if the condition is false, or some
non-{\false} value if the condition is true.  One may think of a predicate as
producing a Boolean value, where {\false} stands for \emph{false} and anything
else stands for \emph{true}.  Conditional control structures such as
\cdf{cond},
\cdf{if}, \cdf{when}, and \cdf{unless} test such Boolean values.
We say that a predicate \emph{is true} when it returns a non-{\false} value,
and \emph{is false} when it returns {\false}; that is, it is true or false
according to whether the condition being tested is true or false.

By convention, the names of predicates usually end in the letter
\cd{p} (which stands for ``predicate'').
Common Lisp uses a uniform convention in hyphenating names of predicates.
If the name of the predicate is formed by adding a \cd{p} to
an existing name, such as the name of a data type,
a hyphen is placed before the final \cd{p} if and only if there is
a hyphen in the existing name.  For example, \cd{number} begets \cd{numberp}
but \cd{standard-char} begets \cd{standard-char-p}.
On the other hand, if the name of a predicate is formed by adding
a prefixing qualifier to the front of an existing predicate name,
the two names are joined with a hyphen and the presence or absence
of a hyphen before the final \cd{p} is not changed.  For example,
the predicate \cd{string-lessp} has no hyphen before the \cd{p}
because it is the string version of \cdf{lessp} (a MacLisp function
that has been renamed \cdf{<} in Common Lisp).  The name \cd{string-less-p}
would incorrectly imply that it is a predicate that tests for a kind
of object called a \cdf{string-less}, and the name \cd{stringlessp}
would connote a predicate that tests whether something has no strings
(is ``stringless'')!

The control structures that test Boolean values only test for
whether or not the value is {\false}, which is considered to be false.  Any
other value is considered to be true.  Often a predicate will return {\false} if
it ``fails'' and some \emph{useful} value if it ``succeeds'';
such a function can be used not only as a test but
also for the useful value provided in case of success.  An example
is \cdf{member}.

If no better non-{\nil} value is available for the purpose of indicating
success, by convention the symbol \cdf{t} is used as the ``standard''
true value.

\section{Logical Values}

The names \cdf{nil} and \cdf{t} are constants in Common Lisp.  Although they
are symbols like any other symbols, and appear to be treated
as variables when evaluated, it is not permitted to modify their
values.  See \cdf{defconstant}.

\begin{defun}[Constant]
nil

The value of {\nil} is always {\nil}.  This object represents the logical
\emph{false} value and also the empty list.  It can also be written \cd{()}.
\end{defun}

\begin{defun}[Constant]
t

The value of \cdf{t} is always \cdf{t}.
\end{defun}

\section{Data Type Predicates}

Perhaps the most important predicates in Lisp are those that deal
with data types;  that is, given a data object one can determine whether
or not it belongs to a given type, or one can compare two type specifiers.

\subsection{General Type Predicates}

If a data type is viewed as the set of all objects belonging to the type,
then the \cdf{typep} function is a set membership test, while \cdf{subtypep}
is a subset test.

\begin{defun}[Function]
typep object type

\cdf{typep} is a predicate that
is true if \emph{object} is of type \emph{type}, and is false otherwise.
Note that an object can be ``of'' more than one type, since one type can
include another.  The \emph{type} may be any of the type specifiers
mentioned in chapter~\ref{DTSPEC} \emph{except} that it may not
be or contain a type specifier list whose first element is \cdf{function}
or \cdf{values}.
A specifier of the form \cd{(satisfies \emph{fn})} is handled simply
by applying the function \emph{fn} to \emph{object}
(see \cdf{funcall}); the \emph{object} is considered
to be of the specified type if the result is not {\false}.

\begin{new}
X3J13 voted in January 1989
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS}
to change \cdf{typep} to give specialized
\cdf{array} and \cdf{complex} type specifiers the same meaning for
purposes of type discrimination as they have for declaration purposes.
Of course, this also applies to such type specifiers as \cdf{vector}
and \cdf{simple-array}
(see section~\ref{SPECIALIZED-TYPE-SPECIFIER-SECTION}).
Thus
\begin{lisp}
(typep foo '(array bignum))
\end{lisp}
in the first edition asked the question, Is \cdf{foo} an array
specialized to hold bignums? but under the new interpretation
asks the question, Could the array \cdf{foo} have resulted from
giving \cdf{bignum} as the \cd{:element-type} argument
to \cdf{make-array}?
\end{new}
\end{defun}

\begin{defun}[Function]
subtypep type1 type2

The arguments must be type specifiers that are acceptable to \cdf{typep}.
The two type specifiers are compared; this predicate is true
if \emph{type1} is definitely a (not necessarily proper) subtype of \emph{type2}.
If the result is {\false}, however, then \emph{type1} may or may not be a subtype of
\emph{type2} (sometimes it is impossible to tell, especially when
\cdf{satisfies} type specifiers are involved).
A second returned value indicates the certainty of the result;
if it is true, then the first value is an accurate indication
of the subtype relationship.  Thus there are three possible
result combinations:
\begin{tabbing}
~~~~~~~~\=~~~~~~~~\=\kill
{\true}\>{\true}\>\emph{type1} is definitely a subtype of \emph{type2} \\
{\false}\>{\true}\>\emph{type1} is definitely not a subtype of \emph{type2} \\
{\false}\>{\false}\>\cdf{subtypep} could not determine the relationship
\end{tabbing}

\begin{new}
X3J13 voted in January 1989
\issue{SUBTYPEP-TOO-VAGUE}
to place certain requirements upon the implementation of \cdf{subtypep},
for it noted that implementations in many cases simply ``give up''
and return the two values \cdf{nil} and \cdf{nil} when in fact it would have been
possible to determine the relationship between the given types.
The requirements are as follows, where it is understood that a type specifier \emph{s}
\emph{involves} a type specifier \emph{u} if either \emph{s} contains an occurrence of \emph{u}
directly or \emph{s} contains a type specifier \emph{w} defined by \cdf{deftype} whose
expansion involves \emph{u}.
\begin{itemize}
\item \cdf{subtypep} is not permitted to return a second value of \cdf{nil}
unless one or both of its arguments involves \cdf{satisfies},
\cdf{and}, \cdf{or}, \cdf{not}, or \cdf{member}.
\item \cdf{subtypep} should signal an error when one or both of its arguments
involves \cdf{values} or the list form of the \cdf{function} type specifier.
\item \cdf{subtypep} must always return the two values \cdf{t} and \cdf{t}
in the case where its arguments, after expansion of specifiers
defined by \cdf{deftype}, are \cdf{equal}.
\end{itemize}
In addition, X3J13 voted to clarify that in some cases
the relationships between types
as reflected by \cdf{subtypep} may be implementation-specific.
For example, in an implementation supporting only one type of
floating-point number, \cd{(subtypep 'float 'long-float)} would return
\cdf{t} and \cdf{t}, since the two types would be identical.

Note that \cdf{satisfies} is an exception because relationships between
types involving \cdf{satisfies} are undecidable in general, but (as X3J13 noted)
\cdf{and}, \cdf{or}, \cdf{not}, and \cdf{member} are merely very messy to deal
with.  In all likelihood these will not be addressed unless and
until someone is willing to write a careful specification that covers
all the cases for the processing of these type
specifiers by \cdf{subtypep}.  The requirements stated above were easy
to state and probably suffice for most cases of interest.
\end{new}

\begin{new}
X3J13 voted in January 1989
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS}
to change \cdf{subtypep} to give specialized
\cdf{array} and \cdf{complex} type specifiers the same meaning for
purposes of type discrimination as they have for declaration purposes.
Of course, this also applies to such type specifiers as \cdf{vector}
and \cdf{simple-array}
(see section~\ref{SPECIALIZED-TYPE-SPECIFIER-SECTION}).

If \emph{A} and \emph{B} are type specifiers (other than \cdf{*}, which technically
is not a type specifier anyway), then \cd{(array~\emph{A})}
and \cd{(array~\emph{B})} represent the same type in a given implementation
if and only if they denote arrays
of the same specialized representation in that implementation;
otherwise they are disjoint.
To put it another way, they represent the same type
%(and otherwise are disjoint)
if and only if
\cd{(upgraded-array-element-type~'\emph{A})} and
\cd{(upgraded-array-element-type~'\emph{B})} are the same type.
Therefore
\begin{lisp}
(subtypep '(array \emph{A}) '(array \emph{B}))
\end{lisp}
is true if and only if
\cd{(upgraded-array-element-type~'\emph{A})}
is the same type as
\cd{(upgraded-array-element-type~'\emph{B})}.

The \cdf{complex} type specifier is treated in a similar but subtly different
manner.
If \emph{A} and \emph{B} are two type specifiers (but not \cdf{*}, which technically
is not a type specifier anyway), then \cd{(complex~\emph{A})}
and \cd{(complex~\emph{B})} represent the same type in a given implementation
if and only if they refer to complex numbers
of the same specialized representation in that implementation;
otherwise they are disjoint.
Note, however, that there is no function called \cdf{make-complex} that
allows one to specify a particular element type (then to be upgraded);
instead, one must describe specialized complex numbers in terms of
the actual types of the parts from which they were constructed.
There is no number of type (or rather, \emph{representation\/})
\cdf{float} as such; there are only numbers of type \cdf{single-float},
numbers of type \cdf{double-float},
and so on.  Therefore we want \cd{(complex single-float)} to
be a subtype of \cd{(complex float)}.

The rule, then, is that \cd{(complex~\emph{A})}
and \cd{(complex~\emph{B})} represent the same type (and otherwise are disjoint)
in a given implementation
if and only if \emph{either} the type \emph{A} is a subtype of \emph{B}, \emph{or}
\cd{(upgraded-complex-part-type~'\emph{A})} and
\cd{(upgraded-complex-part-type~'\emph{B})} are the same type.
In the latter case \cd{(complex~\emph{A})}
and \cd{(complex~\emph{B})} in fact refer to the same specialized representation.
Therefore
\begin{lisp}
(subtypep '(complex \emph{A}) '(complex \emph{B}))
\end{lisp}
is true if and only if the results of
\cd{(upgraded-complex-part-type~'\emph{A})} and
\cd{(upgraded-complex-part-type~'\emph{B})} are the same type.

Under this interpretation
\begin{lisp}
(subtypep '(complex single-float) '(complex float))
\end{lisp}
must be true in all implementations; but
\begin{lisp}
(subtypep '(array single-float) '(array float))
\end{lisp}
is true only in implementations that do not have a specialized array representation
for \cdf{single-float} elements distinct from that for \cdf{float} elements in
general.
\end{new}
\end{defun}

\subsection{Specific Data Type Predicates}

The following predicates test for individual data types.

\begin{defun}[Function]
null object

\cdf{null} is true if its argument is {\emptylist},
and otherwise is false.
This is the same operation performed by the function \cdf{not};
however, \cdf{not} is normally used to invert a Boolean value,
whereas \cdf{null} is normally used to test for an empty list.  The programmer
can therefore express \emph{intent} by the choice of function name.
\begin{lisp}
(null x) \EQ\ (typep x 'null) \EQ\ (eq x '{\emptylist})
\end{lisp}
\end{defun}

\begin{defun}[Function]
symbolp object

\cdf{symbolp} is true if its argument is a symbol,
and otherwise is false.
\begin{lisp}
(symbolp x) \EQ\ (typep x 'symbol)
\end{lisp}
\end{defun}

\begin{defun}[Function]
atom object

The predicate \cdf{atom} is true if its argument is not a cons,
and otherwise is false.
Note that \cd{(atom '{\emptylist})} is true, because {\emptylist}$\;\equiv\;${\nil}.
\begin{lisp}
(atom x) \EQ\ (typep x 'atom) \EQ\ (not (typep x 'cons))
\end{lisp}
\end{defun}

\begin{defun}[Function]
consp object

The predicate \cdf{consp} is true if its argument is a cons,
and otherwise is false.
Note that the empty list is not a cons, so
\cd{(consp '{\emptylist})} \EQ\ \cd{(consp '{\nil})} \EV\ {\nil}.
\begin{lisp}
(consp x) \EQ\ (typep x 'cons) \EQ\ (not (typep x 'atom))
\end{lisp}
\end{defun}

\begin{defun}[Function]
listp object

\cdf{listp} is true if its argument is a cons or the empty list {\emptylist},
and otherwise is false.  It does not check for whether the list
is a ``true list'' (one terminated by {\nil}) or a ``dotted list''
(one terminated by a non-null atom).
\begin{lisp}
(listp x) \EQ\ (typep x 'list) \EQ\ (typep x '(or cons null))
\end{lisp}
\end{defun}

\begin{defun}[Function]
numberp object

\cdf{numberp} is true if its argument is any kind of number,
and otherwise is false.
\begin{lisp}
(numberp x) \EQ\ (typep x 'number)
\end{lisp}
\end{defun}

\begin{defun}[Function]
integerp object

\cdf{integerp} is true if its argument is an integer, and otherwise
is false.
\begin{lisp}
(integerp x) \EQ\ (typep x 'integer)
\end{lisp}
\end{defun}

\begin{defun}[Function]
rationalp object

\cdf{rationalp} is true if its argument is a rational number (a ratio or
an integer), and otherwise is false.
\begin{lisp}
(rationalp x) \EQ\ (typep x 'rational)
\end{lisp}
\end{defun}

\begin{defun}[Function]
floatp object

\cdf{floatp} is true if its argument is a floating-point number,
and otherwise is false.
\begin{lisp}
(floatp x) \EQ\ (typep x 'float)
\end{lisp}
\end{defun}

\begin{defun}[Function]
realp object

\cdf{realp} is true if its argument is a real number,
and otherwise is false.
\begin{lisp}
(realp x) \EQ\ (typep x 'real)
\end{lisp}
\end{defun}

\begin{defun}[Function]
complexp object

\cdf{complexp} is true if its argument is a complex number,
and otherwise is false.
\begin{lisp}
(complexp x) \EQ\ (typep x 'complex)
\end{lisp}
\end{defun}

\begin{defun}[Function]
characterp object

\cdf{characterp} is true if its argument is a character,
and otherwise is false.
\begin{lisp}
(characterp x) \EQ\ (typep x 'character)
\end{lisp}
\end{defun}

\begin{defun}[Function]
stringp object

\cdf{stringp} is true if its argument is a string,
and otherwise is false.
\begin{lisp}
(stringp x) \EQ\ (typep x 'string)
\end{lisp}
\end{defun}

\begin{defun}[Function]
bit-vector-p object

\cdf{bit-vector-p} is true if its argument is a bit-vector,
and otherwise is false.
\begin{lisp}
(bit-vector-p x) \EQ\ (typep x 'bit-vector)
\end{lisp}
\end{defun}

\begin{defun}[Function]
vectorp object

\cdf{vectorp} is true if its argument is a vector,
and otherwise is false.
\begin{lisp}
(vectorp x) \EQ\ (typep x 'vector)
\end{lisp}
\end{defun}

\begin{defun}[Function]
simple-vector-p object

\cdf{vectorp} is true if its argument is a simple general vector,
and otherwise is false.
\begin{lisp}
(simple-vector-p x) \EQ\ (typep x 'simple-vector)
\end{lisp}
\end{defun}

\begin{defun}[Function]
simple-string-p object

\cdf{simple-string-p} is true if its argument is a simple string,
and otherwise is false.
\begin{lisp}
(simple-string-p x) \EQ\ (typep x 'simple-string)
\end{lisp}
\end{defun}

\begin{defun}[Function]
simple-bit-vector-p object

\cdf{simple-bit-vector-p} is true if its argument is a simple bit-vector,
and otherwise is false.
\begin{lisp}
(simple-bit-vector-p x) \EQ\ (typep x 'simple-bit-vector)
\end{lisp}
\end{defun}

\begin{defun}[Function]
arrayp object

\cdf{arrayp} is true if its argument is an array,
and otherwise is false.
\begin{lisp}
(arrayp x) \EQ\ (typep x 'array)
\end{lisp}
\end{defun}

\begin{defun}[Function]
packagep object

\cdf{packagep} is true if its argument is a package,
and otherwise is false.
\begin{lisp}
(packagep x) \EQ\ (typep x 'package)
\end{lisp}
\end{defun}

\begin{defun}[Function]
functionp object

\begin{obsolete}
\cdf{functionp} is true if its argument is suitable for applying
to arguments, using for example the \cdf{funcall} or \cdf{apply} function.
Otherwise \cdf{functionp} is false.

\cdf{functionp} is always true of symbols, lists whose \emph{car}
is the symbol \cdf{lambda}, any value returned by the \cdf{function}
special operator, and any values returned by the function \cdf{compile}
when the first argument is {\nil}.
\end{obsolete}
\begin{newer}
X3J13 voted in June 1988 \issue{FUNCTION-TYPE}
to define
\begin{lisp}
(functionp x) \EQ\ (typep x 'function)
\end{lisp}
Because the vote also specifies that types \cdf{cons} and \cdf{symbol} are disjoint
from the type \cdf{function}, this is an incompatible change;
now \cdf{functionp} is in fact always false of symbols and lists.
\end{newer}
\end{defun}

\begin{defun}[Function]
compiled-function-p object

\cdf{compiled-function-p} is true if its argument is any compiled code object,
and otherwise is false.
\begin{lisp}
(compiled-function-p x) \EQ\ (typep x 'compiled-function)
\end{lisp}
\end{defun}

\medskip

See also \cdf{standard-char-p}, \cdf{string-char-p},
\cdf{streamp}, \cdf{random-state-p},
\cdf{readtablep},
\cdf{hash-table-p}, and \cdf{pathnamep}.

\section{Equality Predicates}

Common Lisp provides a spectrum of predicates for testing for equality of
two objects: \cdf{eq} (the most specific), \cdf{eql}, \cdf{equal}, and \cdf{equalp}
(the most general).  \cdf{eq} and \cdf{equal} have the meanings traditional
in Lisp.  \cdf{eql} was added because it is frequently needed, and
\cdf{equalp} was added primarily in order to have a version of \cdf{equal}
that would ignore type differences when comparing numbers
and case differences when comparing characters.
If two objects satisfy any one of these equality predicates,
then they also satisfy all those that are more general.

\begin{defun}[Function]
eq x y

\cd{(eq \emph{x} \emph{y})} is true
if and only if \emph{x} and \emph{y} are the same identical object.
(Implementationally, \emph{x} and \emph{y} are usually
\cdf{eq} if and only if they address the same identical memory location.)

It should be noted that things that print the same are not necessarily \cdf{eq}
to each other.  Symbols with the same print name usually are \cdf{eq} to
each other because of the use of the \cdf{intern} function.
However, numbers with the same value
need not be \cdf{eq}, and two similar lists are usually not \cdf{eq}.
For example:
\begin{lisp}
(eq 'a 'b) \textrm{is false.} \\
(eq 'a 'a) \textrm{is true.} \\
(eq 3 3) \textrm{might be true or false, depending on the implementation.} \\
(eq 3 3.0) \textrm{is false.} \\
(eq 3.0 3.0) \textrm{might be true or false, depending on the implementation.} \\
(eq \#c(3 -4) \#c(3 -4)) \\
~~\textrm{might be true or false, depending on the implementation.} \\
(eq \#c(3 -4.0) \#c(3 -4)) \textrm{is false.} \\
(eq (cons 'a 'b) (cons 'a 'c)) \textrm{is false.} \\
(eq (cons 'a 'b) (cons 'a 'b)) \textrm{is false.} \\
(eq '(a . b) '(a . b)) \textrm{might be true or false.} \\
(progn (setq x (cons 'a 'b)) (eq x x)) \textrm{is true.} \\
(progn (setq x '(a . b)) (eq x x)) \textrm{is true.} \\
(eq \#{\Xbackslash}A \#{\Xbackslash}A) \textrm{might be true or false, depending on the implementation.} \\
(eq "Foo" "Foo") \textrm{might be true or false.} \\
(eq "Foo" (copy-seq "Foo")) \textrm{is false.} \\
(eq "FOO" "foo") \textrm{is false.}
\end{lisp}

In Common Lisp, unlike some other Lisp dialects, the implementation
is permitted to make ``copies'' of
characters and numbers at any time.  (This permission is granted
because it allows tremendous performance improvements in many
common situations.)  The net effect is that
Common Lisp makes no guarantee that \cdf{eq} will be true even when both
its arguments are ``the same thing'' if that thing is a character or number.
For example:
\begin{lisp}
(let ((x 5)) (eq x x)) \textrm{might be true or false.}
\end{lisp}

The predicate \cdf{eql} is the same as \cdf{eq}, except that if the
arguments are characters or numbers of the same type then their
values are compared.  Thus \cdf{eql} tells whether two objects
are \emph{conceptually} the same, whereas \cdf{eq} tells whether two
objects are \emph{implementationally} identical.  It is for this reason
that \cdf{eql}, not \cdf{eq}, is the default comparison predicate
for the sequence functions defined in chapter~\ref{KSEQUE}.

\beforenoterule
\begin{implementation}
\cdf{eq} simply compares the two given pointers,
so any kind of object that is represented in an ``immediate'' fashion
will indeed have like-valued instances satisfy \cdf{eq}.
In some implementations, for example,
fixnums and characters happen to ``work.''
However, no program should depend on this, as other implementations
of Common Lisp might not use an immediate representation for these data types.
\end{implementation}
\afternoterule

\begin{obsolete}
An additional problem with \cdf{eq} is that the implementation is permitted
to ``collapse'' constants (or portions thereof)
appearing in code to be compiled if they are
\cdf{equal}.  An object is considered to be a constant in code to be compiled
if it is a self-evaluating form or is contained in a \cdf{quote} form.
This is why \cd{(eq "Foo" "Foo")} might be true or false; in interpreted
code it would normally be false, because reading in the
form \cd{(eq "Foo" "Foo")} would construct distinct strings for the two
arguments to \cdf{eq}, but the compiler might choose to use the same
identical string or two distinct copies as the two arguments in the
call to \cdf{eq}.  Similarly, \cd{(eq '(a . b) '(a . b))} might be true
or false, depending on whether the constant conses appearing in the
\cdf{quote} forms were collapsed by the compiler.  However,
\cd{(eq (cons 'a 'b) (cons 'a 'b))} is always false, because every distinct
call to the \cdf{cons} function necessarily produces a new and distinct cons.
\end{obsolete}

\begin{newer}
X3J13 voted in March 1989 \issue{QUOTE-SEMANTICS} to clarify that
\cdf{eval} and \cdf{compile} are not permitted either to copy or
to coalesce (``collapse'') constants (see \cdf{eq})
appearing in the code they process; the resulting
program behavior must refer to objects that are \cdf{eql} to the
corresponding objects in the source code.
Only the \cdf{compile-file}/\cdf{load} process is permitted
to copy or coalesce constants (see section~\ref{COMPILER-SECTION}).
\end{newer}
\end{defun}

\begin{defun}[Function]
eql x y

The \cdf{eql} predicate is true if its arguments are \cdf{eq},
or if they are numbers of the same type with the same value,
or if they are character objects
that represent the same character.
For example:
\begin{lisp}
(eql 'a 'b) \textrm{is false.} \\
(eql 'a 'a) \textrm{is true.} \\
(eql 3 3) \textrm{is true.} \\
(eql 3 3.0) \textrm{is false.} \\
(eql 3.0 3.0) \textrm{is true.} \\
(eql \#c(3 -4) \#c(3 -4)) \textrm{is true.} \\
(eql \#c(3 -4.0) \#c(3 -4)) \textrm{is false.} \\
(eql (cons 'a 'b) (cons 'a 'c)) \textrm{is false.} \\
(eql (cons 'a 'b) (cons 'a 'b)) \textrm{is false.} \\
(eql '(a . b) '(a . b)) \textrm{might be true or false.} \\
(progn (setq x (cons 'a 'b)) (eql x x)) \textrm{is true.} \\
(progn (setq x '(a . b)) (eql x x)) \textrm{is true.} \\
(eql \#{\Xbackslash}A \#{\Xbackslash}A) \textrm{is true.} \\
(eql "Foo" "Foo") \textrm{might be true or false.} \\
(eql "Foo" (copy-seq "Foo")) \textrm{is false.} \\
(eql "FOO" "foo") \textrm{is false.}
\end{lisp}

Normally \cd{(eql 1.0s0 1.0d0)} would be false, under the assumption
that \cd{1.0s0} and \cd{1.0d0} are of distinct data types.
However, implementations that do not provide four distinct floating-point
formats are permitted to ``collapse'' the four formats into some
smaller number of them; in such an implementation \cd{(eql 1.0s0 1.0d0)}
might be true.  The predicate \cdf{=} will compare
the values of two numbers even if the numbers are of different types.

If an implementation supports positive and negative zeros as distinct
values (as in the IEEE proposed standard floating-point format),
then \cd{(eql 0.0 -0.0)} will be false.  Otherwise, when the syntax
\cd{-0.0} is read it will be interpreted as the value \cd{0.0},
and so \cd{(eql 0.0 -0.0)} will be true.  The predicate \cdf{=}
differs from \cdf{eql} in that \cd{(= 0.0 -0.0)} will always be true,
because \cdf{=} compares the mathematical values of its operands,
whereas \cdf{eql} compares the representational values, so to speak.

Two complex numbers are considered to be \cdf{eql}
if their real parts are \cdf{eql} and their imaginary parts are \cdf{eql}.
For example, \cd{(eql \#C(4 5) \#C(4 5))} is true and
\cd{(eql \#C(4 5) \#C(4.0 5.0))} is false.
Note that while \cd{(eql \#C(5.0 0.0) 5.0)} is false,
\cd{(eql \#C(5 0) 5)} is true.
In the case of \cd{(eql \#C(5.0 0.0) 5.0)} the
two arguments are of different types
and so cannot satisfy \cdf{eql}; that's all there is to it.
In the case of \cd{(eql \#C(5 0) 5)}, however,
\cd{\#C(5 0)} is not a complex number but
is always automatically reduced by the rule of complex
canonicalization to the integer \cd{5},
just as the apparent ratio \cd{20/4} is always simplified to \cd{5}.

The case of \cd{(eql "Foo" "Foo")} is discussed above in the description
of \cdf{eq}.  While \cdf{eql} compares the values of numbers and
characters, it does not compare the contents of strings.  To compare
the characters of two strings, one should use \cdf{equal}, \cdf{equalp},
\cdf{string=}, or \cdf{string-equal}.
\end{defun}

\begin{defun}[Function]
equal x y

The \cdf{equal} predicate is true if its arguments are structurally similar
(isomorphic) objects.  A rough rule of thumb is that two objects
are \cdf{equal} if and only if their printed representations are the same.

Numbers and characters are compared as for \cdf{eql}.
Symbols are compared as for \cdf{eq}.  This method
of comparing symbols can violate the rule
of thumb for \cdf{equal} and printed representations,
but only in the infrequently occurring case of two distinct
symbols with the same print name.

Certain objects that have components are \cdf{equal} if they are of the same
type and corresponding components are \cdf{equal}.
This test is implemented in a recursive manner and may fail to
terminate for circular structures.

For conses, \cdf{equal} is defined recursively as
the two \emph{car}'s being \cdf{equal} and the two \emph{cdr}'s being
\cdf{equal}.

Two arrays are \cdf{equal} only if they are \cdf{eq},
with one exception:
strings and bit-vectors are compared element-by-element.
If either argument has a fill pointer, the fill pointer limits
the number of elements examined by \cdf{equal}.
Uppercase and lowercase letters in strings are considered by
\cdf{equal} to be distinct.  (In contrast, \cdf{equalp} ignores
case distinctions in strings.)

Two pathname objects are \cdf{equal} if and only if
all the corresponding components
(host, device, and so on) are equivalent.  (Whether or not
uppercase and lowercase letters are considered equivalent
in strings appearing in components depends on the file
name conventions of the file system.)  Pathnames
that are \cdf{equal} should be functionally equivalent.

\cdf{equal} never recursively
descends any structure or data type other than the ones explicitly
described above: conses, bit-vectors, strings, and pathnames.
Numbers and characters are compared as if by \cdf{eql}, and all other
data objects are compared as if by \cdf{eq}.

\begin{lisp}
(equal 'a 'b) \textrm{is false.} \\
(equal 'a 'a) \textrm{is true.} \\
(equal 3 3) \textrm{is true.} \\
(equal 3 3.0) \textrm{is false.} \\
(equal 3.0 3.0) \textrm{is true.} \\
(equal \#c(3 -4) \#c(3 -4)) \textrm{is true.} \\
(equal \#c(3 -4.0) \#c(3 -4)) \textrm{is false.} \\
(equal (cons 'a 'b) (cons 'a 'c)) \textrm{is false.} \\
(equal (cons 'a 'b) (cons 'a 'b)) \textrm{is true.} \\
(equal '(a . b) '(a . b)) \textrm{is true.} \\
(progn (setq x (cons 'a 'b)) (equal x x)) \textrm{is true.} \\
(progn (setq x '(a . b)) (equal x x)) \textrm{is true.} \\
(equal \#{\Xbackslash}A \#{\Xbackslash}A) \textrm{is true.} \\
(equal "Foo" "Foo") \textrm{is true.} \\
(equal "Foo" (copy-seq "Foo")) \textrm{is true.} \\
(equal "FOO" "foo") \textrm{is false.}
\end{lisp}
To compare a tree of conses using \cdf{eql}
(or any other desired predicate) on the leaves, use \cdf{tree-equal}.

\end{defun}

\begin{defun}[Function]
equalp x y

Two objects are \cdf{equalp} if they are \cdf{equal};
if they are characters and satisfy \cdf{char-equal},
which ignores alphabetic case and certain other attributes of characters;
if they are numbers and have the same numerical value,
even if they are of different types;
or if they have components that are all \cdf{equalp}.

Objects that have components are \cdf{equalp} if they are of the same
type and corresponding components are \cdf{equalp}.
This test is implemented in a recursive manner and may fail to
terminate for circular structures.
For conses, \cdf{equalp} is defined recursively as
the two \emph{car}'s being \cdf{equalp} and the two \emph{cdr}'s being
\cdf{equalp}.

Two arrays are \cdf{equalp} if and only if they have the same
number of dimensions, the dimensions match,
and the corresponding components are \cdf{equalp}.
The specializations need not match; for example,
a string and a general array that happens to contain the same characters
will be \cdf{equalp} (though definitely not \cdf{equal}).
If either argument has a fill pointer, the fill pointer limits
the number of elements examined by \cdf{equalp}.
Because \cdf{equalp} performs element-by-element comparisons
of strings and ignores the alphabetic case of characters,
case distinctions are therefore also ignored when \cdf{equalp} compares
strings.

Two symbols can be \cdf{equalp} only if they are \cdf{eq}, that is, the same
identical object.

\begin{new}
X3J13 voted in June 1989
\issue{EQUAL-STRUCTURE}
to specify that \cdf{equalp} compares components
of hash tables (see below), and to
clarify that otherwise \cdf{equalp} never recursively
descends any structure or data type other than the ones explicitly
described above: conses, arrays (including bit-vectors and strings), and pathnames.
Numbers are compared for numerical equality (see \cdf{=}),
characters are compared as if by \cdf{char-equal}, and all other
data objects are compared as if by \cdf{eq}.

Two hash tables are considered the same by \cdf{equalp} if and only if
they satisfy a four-part test:
\begin{itemize}
\item They must be
of the same kind; that is, equivalent \cd{:test} arguments were given to
\cdf{make-hash-table} when the two hash tables were created.

\item They must have the same number of entries (see \cdf{hash-table-count}).

\item For every entry (\emph{key1}, \emph{value1\/}) in one hash table
there must be a corresponding entry (\emph{key2}, \emph{value2\/}) in the
other, such that \emph{key1} and \emph{key2} are considered to be the same
by the \cd{:test} function associated with the hash tables.

\item For every entry (\emph{key1}, \emph{value1\/}) in one hash table
and its corresponding entry (\emph{key2}, \emph{value2\/}) in the
other, such that \emph{key1} and \emph{key2} are the same,
\cdf{equalp} must be true of \emph{value1} and \emph{value2}.
\end{itemize}
The four parts of this test are carried out in the order shown, and
if some part of the test fails, \cdf{equalp} returns \cdf{nil} and
the other parts of the test are not attempted.

If \cdf{equalp} must compare two structures and the \cdf{defstruct}
definition for one used the \cd{:type} option and the other did not,
then \cdf{equalp} returns \cdf{nil}.

If \cdf{equalp} must compare two structures and neither \cdf{defstruct}
definition used the \cd{:type} option,
then \cdf{equalp} returns \cdf{t} if and only if the structures have the
same type (that is, the same \cdf{defstruct} name) and the values
of all corresponding slots (slots having the same name) are \cdf{equalp}.

As part of the X3J13 discussion of this issue
the following observations were made.
    Object equality is not a concept for which there is a uniquely
    determined correct algorithm. The appropriateness of an equality
    predicate can be judged only in the context of the needs of some
    particular program. Although these functions take any type of
    argument and their names sound very generic, \cdf{equal} and \cdf{equalp} are
    not appropriate for every application. Any decision to use or not
    use them should be determined by what they are documented to do
    rather than by any abstract characterization of their function. If
    neither \cdf{equal} nor \cdf{equalp} is found to be appropriate in a particular
    situation, programmers are encouraged to create another operator
    that is appropriate rather than blame \cdf{equal} or \cdf{equalp} for ``doing
    the wrong thing.''
\end{new}

\begin{new}
Note that one consequence
of the vote to change the rules of
floating-point contagion
\issue{CONTAGION-ON-NUMERICAL-COMPARISONS}
(described in section~\ref{PRECISION-CONTAGION-COERCION-SECTION})
is to make \cdf{equalp}
a true equivalence relation on numbers.
\end{new}

\begin{lisp}
(equalp 'a 'b) \textrm{is false.} \\
(equalp 'a 'a) \textrm{is true.} \\
(equalp 3 3) \textrm{is true.} \\
(equalp 3 3.0) \textrm{is true.} \\
(equalp 3.0 3.0) \textrm{is true.} \\
(equalp \#c(3 -4) \#c(3 -4)) \textrm{is true.} \\
(equalp \#c(3 -4.0) \#c(3 -4)) \textrm{is true.} \\
(equalp (cons 'a 'b) (cons 'a 'c)) \textrm{is false.} \\
(equalp (cons 'a 'b) (cons 'a 'b)) \textrm{is true.} \\
(equalp '(a . b) '(a . b)) \textrm{is true.} \\
(progn (setq x (cons 'a 'b)) (equalp x x)) \textrm{is true.} \\
(progn (setq x '(a . b)) (equalp x x)) \textrm{is true.} \\
(equalp \#{\Xbackslash}A \#{\Xbackslash}A) \textrm{is true.} \\
(equalp "Foo" "Foo") \textrm{is true.} \\
(equalp "Foo" (copy-seq "Foo")) \textrm{is true.} \\
(equalp "FOO" "foo") \textrm{is true.}
\end{lisp}

\end{defun}

\section{Logical operators}

Common Lisp provides three operators on Boolean values: \cdf{and}, \cdf{or},
and \cdf{not}.  Of these, \cdf{and} and \cdf{or}
are also control structures because their arguments are evaluated
conditionally.
The function \cdf{not} necessarily examines its single argument, and so
is a simple function.

\begin{defun}[Function]
not x

\cdf{not} returns {\true} if \emph{x} is {\false}, and otherwise returns {\false}.
It therefore inverts its argument considered as a Boolean value.

\cdf{null} is the same as \cdf{not}; both functions are included for the sake
of clarity.  As a matter of style,
it is customary to use \cdf{null} to check whether something is the empty list
and to use \cdf{not} to invert the sense of a logical value.
\end{defun}

\begin{defmac}
and {form}*

\cd{(and \emph{form1} \emph{form2} ... )} evaluates each \emph{form}, one at a time,
from left to right.  If any \emph{form} evaluates to {\false}, the value {\nil}
is immediately returned without evaluating the remaining
\emph{form\/}s.  If every \emph{form} but the last evaluates to a non-{\false} value,
\cdf{and} returns whatever the last \emph{form} returns.
Therefore in general \cdf{and} can be used both for logical operations,
where {\false} stands for \emph{false} and non-{\false} values stand for \emph{true},
and as a conditional expression.
An example follows.
\begin{lisp}
(if (and (>= n 0) \\
~~~~~~~~~(< n (length a-simple-vector)) \\
~~~~~~~~~(eq (elt a-simple-vector n) 'foo)) \\
~~~~(princ "Foo!"))
\end{lisp}
The above expression prints \cd{Foo!} if element \cd{n} of \cd{a-simple-vector}
is the symbol \cd{foo}, provided also that \cdf{n} is indeed a valid index
for \cdf{a-simple-vector}.  Because \cdf{and} guarantees left-to-right testing
of its parts, \cdf{elt} is not called if \cd{n} is out of range.

To put it another way,
the \cdf{and} special operator does \emph{short-circuit} Boolean evaluation,
like the \textbf{and then} operator in Ada
and what in some Pascal-like languages is called \textbf{cand} (for ``conditional
and''); the Lisp \cdf{and} special operator is
unlike the Pascal or Ada \textbf{and} operator,
which always evaluates both arguments.

In the previous example writing
\begin{lisp}
(and (>= n 0) \\
~~~~~(< n (length a-simple-vector)) \\
~~~~~(eq (elt a-simple-vector n) 'foo) \\
~~~~~(princ "Foo!"))
\end{lisp}
would accomplish the same thing.  The difference is purely stylistic.
Some programmers never use expressions containing side effects
within \cdf{and}, preferring to use \cdf{if} or \cdf{when} for that purpose.

From the general definition, one can deduce that
\cd{(and \emph{x})} \EQ\ \emph{x}.  Also,
\cd{(and)} evaluates to {\true}, which is an identity for this operation.

One can define \cdf{and} in terms of \cdf{cond} in this way:
\begin{lisp}
(and \emph{x} \emph{y} \emph{z} ... \emph{w}) \EQ\ (cond \=((not \emph{x}) {\false}) \\
\>((not \emph{y}) {\false}) \\
\>((not \emph{z}) {\false}) \\
\>$\ldots$ \\
\>({\true} \emph{w}))
\end{lisp}

See \cdf{if} and \cdf{when}, which are sometimes stylistically
more appropriate than \cdf{and} for conditional purposes.
If it is necessary to test whether a predicate is true
of all elements of a list or vector (element 0 \emph{and} element 1 \emph{and}
element 2 \emph{and} $\ldots$), then the function \cdf{every} may be useful.
\end{defmac}

\begin{defmac}
or {form}*

\cd{(or \emph{form1} \emph{form2} ... )} evaluates each \emph{form}, one at a time,
from left to right.  If any \emph{form} other than the last
evaluates to something other than {\false},
\cdf{or}
immediately returns that non-{\false} value without evaluating the remaining
\emph{form\/}s.  If every \emph{form} but the last evaluates to {\false},
\cdf{or} returns whatever evaluation of the last of the \emph{form\/}s returns.
Therefore in general \cdf{or} can be used both for logical operations,
where {\false} stands for \emph{false} and non-{\false} values stand for \emph{true},
and as a conditional expression.

To put it another way,
the \cdf{or} special operator does \emph{short-circuit} Boolean evaluation,
like the \textbf{or else} operator in Ada
and what in some Pascal-like languages is called \textbf{cor} (for ``conditional
or''); the Lisp \cdf{or} special operator is
unlike the Pascal or Ada \textbf{or} operator,
which always evaluates both arguments.

From the general definition, one can deduce that
\cd{(or \emph{x})} \EQ\ \emph{x}.  Also,
\cd{(or)} evaluates to {\nil}, which is the identity for this operation.

One can define \cdf{or} in terms of \cdf{cond} in this way:
\begin{lisp}
(or \emph{x} \emph{y} \emph{z} ... \emph{w}) \EQ\ (cond (\emph{x}) (\emph{y}) (\emph{z}) ... ({\true} \emph{w}))
\end{lisp}

See \cdf{if} and \cdf{unless}, which are sometimes
stylistically more appropriate than \cdf{or} for conditional purposes.
If it is necessary to test whether a predicate is true of
one or more elements of a list or vector (element 0 \emph{or} element 1 \emph{or}
element 2 \emph{or} $\ldots$), then the function \cdf{some} may be useful.
\end{defmac}

%RUSSIAN
\else

\chapter{Предикаты}
\label{PREDS}

\emph{Предикат} --- это функция, которая проверяет некоторое условие
переданное в аргументах и возвращает {\false}, если условие ложное, или
не-{\false}, если условие истинное. Можно рассматривать, что предикат
производит булево значение, где \cd{\false} обозначает \emph{ложь} и все
остальное --- \emph{истину}. Условные управляющие структуры, такие как
\cdf{cond}, \cdf{if}, \cdf{when} и \cdf{unless} осуществляют проверку таких
булевых значений. 
Мы говорим, что предикат \emph{истинен}, когда он возвращает не-{\false}
значение, и \emph{ложен}, когда он возвращает {\false}, то есть он истинен
или ложен в зависимости от того, истинно или ложно проверяемое условие.

По соглашению, имена предикатов обычно заканчиваются на букву \cd{p} (которая
обозначает <<предикат (predicate)>>).
Common Lisp использует единое соглашение для использования дефисов в именах
предикатов. Если имя предиката создано с помощью добавления \cd{p} к уже
существующему имени, такому как имя типа данных, тогда дефис помещается перед
последним \cd{p} тогда и только тогда, когда в исходном имени были
дефисы. Например, \cd{number} становится \cd{numberp}, но \cd{standard-char}
становится \cd{standard-char-p}.
С другой стороны, если имя предиката сформировано добавлением префиксного
спецификатора в начало существующего имени предиката, то два имени соединяются с
помощью дефиса, и наличие или отсутствие перед завершающим \cd{p} не
изменяется. Например, предикат \cd{string-lessp} не содержит дефиса перед
\cd{p}, потому что это строковая версия \cd{lessp}. Имя \cd{string-less-p} было бы
некорректно указывающим на то, что это предикат проверяющий тип объекта
называемого \cd{string-less}, а имя \cd{stringlessp} имело бы смысл того, что
проверяет отсутствие строк в чем-либо. 

Управляющие структуры, которые проверяют булевы значения, проверяют только
является или нет значение ложью ({\false}). Любое
другое значение рассматривается как истинное. Часто предикат будет возвращать
{\false}, в случае <<неудачи>> и некоторое \emph{полезное} значение в случае
<<успеха>>. Такие функции могут использоваться не только для проверки, но и
также для использования полезного значения, получаемого в случае
успеха. Например \cdf{member}.

Если лучшего, чем не-{\nil} значения, в целях указания успеха не оказалось, по
соглашению в качестве <<стандартного>> значения истины используется символ \cdf{t}.

\section{Логические значения}

Имена \cdf{nil} и \cdf{t} в Common Lisp'е являются константами. Несмотря на то,
что они являются обычными символами, и могут использоваться в качестве переменных
при вычислениях, их значения не могут быть изменены. Смотрите \cd{defconstant}.

\begin{defun}[Константа]
nil

Значение {\nil} всегда {\nil}. Этот объект обозначает логическую ложь, а также
пустой список. Он также может быть записан, как \cd{()}.
\end{defun}

\begin{defun}[Константа]
t

Значение \cdf{t} всегда\cdf{t}.
\end{defun}

\section{Предикаты типов данных}

Возможно наиболее важными предикатами в Lisp'е это предикаты, которые различают
типы данных. То есть позволяют узнать принадлежит ли заданный объект данному 
типу. Также предикаты могут сравнивать два спецификатора типов.

\subsection{Основные предикаты}

Если тип данных рассматривать, как множество все объектов, принадлежащих этому
типу, тогда функция \cdf{typep} проверяет принадлежность множеству, тогда как
\cd{subtypep} --- принадлежность подмножеству.

\begin{defun}[Функция]
typep object type

\cdf{typep} является предикатом, который истинен, если объект \emph{object}
принадлежит типу \emph{type}, и ложен в противном случае.
Следует отметить, что объект может принадлежать нескольким типам, так как один
тип может включать другой. \emph{type} может быть любым спецификатором типа,
описанным в главе~\ref{DTSPEC}, за исключением того, что он не может быть или
включать список спецификатор типа, у которого первый элемент равен
\cdf{function} или \cdf{values}.
Спецификатор формы \cd{(satisfies \emph{fn})} обрабатывается просто как применение
функции \emph{fn} к объекту \emph{object} (смотрите \cdf{funcall}). Объект
\emph{object} принадлежит заданному типу, если результат не равен {\false}.

\begin{new}
X3J13 voted in January 1989
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS}
to change \cdf{typep} to give specialized
\cdf{array} and \cdf{complex} type specifiers the same meaning for
purposes of type discrimination as they have for declaration purposes.
Of course, this also applies to such type specifiers as \cdf{vector}
and \cdf{simple-array}
(see section~\ref{SPECIALIZED-TYPE-SPECIFIER-SECTION}).
Thus
\begin{lisp}
(typep foo '(array bignum))
\end{lisp}
in the first edition asked the question, Is \cdf{foo} an array
specialized to hold bignums? but under the new interpretation
asks the question, Could the array \cdf{foo} have resulted from
giving \cdf{bignum} as the \cd{:element-type} argument
to \cdf{make-array}?
\end{new}
\end{defun}

\begin{defun}[Функция]
subtypep type1 type2

Аргументы должны быть спецификаторами типов, но только теми, которые могут
использоваться и для \cdf{typep}.
Два спецификатора типа сравниваются. Данный предикат истинен, если
тип \emph{type1} точно является подтипом типа \emph{type2}, иначе предикат ложен.
Если результат {\false}, тогда тип \emph{type1} может быть, а может и не быть
подтипом типа \emph{type2} (иногда это невозможно определить, особенно когда
используется тип \cdf{satisfies}).
Второе возвращаемое значение указывает на точность результата. Если оно является
истиной, значит первое значение указывает на точную принадлежность типов. Таким
образом возможны следующие комбинации результатов:
\begin{tabbing}
~~~~~~~~\=~~~~~~~~\=\kill
{\true}\>{\true}\>\emph{type1} точно является подтипом \emph{type2} \\
{\false}\>{\true}\>\emph{type1} точно не является подтипом \emph{type2} \\
{\false}\>{\false}\>\cdf{subtypep} не может определить отношение
\end{tabbing}

\begin{new}
X3J13 voted in January 1989
\issue{SUBTYPEP-TOO-VAGUE}
to place certain requirements upon the implementation of \cdf{subtypep},
for it noted that implementations in many cases simply ``give up''
and return the two values \cdf{nil} and \cdf{nil} when in fact it would have been
possible to determine the relationship between the given types.
The requirements are as follows, where it is understood that a type specifier \emph{s}
\emph{involves} a type specifier \emph{u} if either \emph{s} contains an occurrence of \emph{u}
directly or \emph{s} contains a type specifier \emph{w} defined by \cdf{deftype} whose
expansion involves \emph{u}.
\begin{itemize}
\item \cdf{subtypep} is not permitted to return a second value of \cdf{nil}
unless one or both of its arguments involves \cdf{satisfies},
\cdf{and}, \cdf{or}, \cdf{not}, or \cdf{member}.
\item \cdf{subtypep} should signal an error when one or both of its arguments
involves \cdf{values} or the list form of the \cdf{function} type specifier.
\item \cdf{subtypep} must always return the two values \cdf{t} and \cdf{t}
in the case where its arguments, after expansion of specifiers
defined by \cdf{deftype}, are \cdf{equal}.
\end{itemize}
In addition, X3J13 voted to clarify that in some cases
the relationships between types
as reflected by \cdf{subtypep} may be implementation-specific.
For example, in an implementation supporting only one type of
floating-point number, \cd{(subtypep 'float 'long-float)} would return
\cdf{t} and \cdf{t}, since the two types would be identical.

Note that \cdf{satisfies} is an exception because relationships between
types involving \cdf{satisfies} are undecidable in general, but (as X3J13 noted)
\cdf{and}, \cdf{or}, \cdf{not}, and \cdf{member} are merely very messy to deal
with.  In all likelihood these will not be addressed unless and
until someone is willing to write a careful specification that covers
all the cases for the processing of these type
specifiers by \cdf{subtypep}.  The requirements stated above were easy
to state and probably suffice for most cases of interest.
\end{new}

\begin{new}
X3J13 voted in January 1989
\issue{ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS}
to change \cdf{subtypep} to give specialized
\cdf{array} and \cdf{complex} type specifiers the same meaning for
purposes of type discrimination as they have for declaration purposes.
Of course, this also applies to such type specifiers as \cdf{vector}
and \cdf{simple-array}
(see section~\ref{SPECIALIZED-TYPE-SPECIFIER-SECTION}).

If \emph{A} and \emph{B} are type specifiers (other than \cdf{*}, which technically
is not a type specifier anyway), then \cd{(array~\emph{A})}
and \cd{(array~\emph{B})} represent the same type in a given implementation
if and only if they denote arrays
of the same specialized representation in that implementation;
otherwise they are disjoint.
To put it another way, they represent the same type
%(and otherwise are disjoint)
if and only if
\cd{(upgraded-array-element-type~'\emph{A})} and
\cd{(upgraded-array-element-type~'\emph{B})} are the same type.
Therefore
\begin{lisp}
(subtypep '(array \emph{A}) '(array \emph{B}))
\end{lisp}
is true if and only if
\cd{(upgraded-array-element-type~'\emph{A})}
is the same type as
\cd{(upgraded-array-element-type~'\emph{B})}.

The \cdf{complex} type specifier is treated in a similar but subtly different
manner.
If \emph{A} and \emph{B} are two type specifiers (but not \cdf{*}, which technically
is not a type specifier anyway), then \cd{(complex~\emph{A})}
and \cd{(complex~\emph{B})} represent the same type in a given implementation
if and only if they refer to complex numbers
of the same specialized representation in that implementation;
otherwise they are disjoint.
Note, however, that there is no function called \cdf{make-complex} that
allows one to specify a particular element type (then to be upgraded);
instead, one must describe specialized complex numbers in terms of
the actual types of the parts from which they were constructed.
There is no number of type (or rather, \emph{representation\/})
\cdf{float} as such; there are only numbers of type \cdf{single-float},
numbers of type \cdf{double-float},
and so on.  Therefore we want \cd{(complex single-float)} to
be a subtype of \cd{(complex float)}.

The rule, then, is that \cd{(complex~\emph{A})}
and \cd{(complex~\emph{B})} represent the same type (and otherwise are disjoint)
in a given implementation
if and only if \emph{either} the type \emph{A} is a subtype of \emph{B}, \emph{or}
\cd{(upgraded-complex-part-type~'\emph{A})} and
\cd{(upgraded-complex-part-type~'\emph{B})} are the same type.
In the latter case \cd{(complex~\emph{A})}
and \cd{(complex~\emph{B})} in fact refer to the same specialized representation.
Therefore
\begin{lisp}
(subtypep '(complex \emph{A}) '(complex \emph{B}))
\end{lisp}
is true if and only if the results of
\cd{(upgraded-complex-part-type~'\emph{A})} and
\cd{(upgraded-complex-part-type~'\emph{B})} are the same type.

Under this interpretation
\begin{lisp}
(subtypep '(complex single-float) '(complex float))
\end{lisp}
must be true in all implementations; but
\begin{lisp}
(subtypep '(array single-float) '(array float))
\end{lisp}
is true only in implementations that do not have a specialized array representation
for \cdf{single-float} elements distinct from that for \cdf{float} elements in
general.
\end{new}
\end{defun}

\subsection{Специальные предикаты}

Следующие предикаты осуществляют проверку определённых типов данных.

\begin{defun}[Функция]
null object

\cdf{null} истинен, если аргумент является {\emptylist}, иначе является
ложью. Похожая операция производится \cdf{not}, однако \cdf{not} используется для
отрицания булевых значение, тогда как \cdf{null} используется для проверки
того, пустой ли список. Таким образом программист может выразить свои намерения, 
выбрав нужное имя функции.
\begin{lisp}
(null x) \EQ\ (typep x 'null) \EQ\ (eq x '{\emptylist})
\end{lisp}
\end{defun}

\begin{defun}[Функция]
symbolp object

\cdf{symbolp} истинен, если её аргумент является символом, в противном
случае ложен.
\begin{lisp}
(symbolp x) \EQ\ (typep x 'symbol)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
atom object

Предикат \cdf{atom} истинен, если аргумент не является cons-ячейкой, в
противном случае ложен.
Следует отметить \cd{(atom '{\emptylist})} являет истиной, потому что
{\emptylist}$\;\equiv\;${\nil}.
\begin{lisp}
(atom x) \EQ\ (typep x 'atom) \EQ\ (not (typep x 'cons))
\end{lisp}
\end{defun}

\begin{defun}[Функция]
consp object

Предикат \cdf{consp} истинен, если его аргумент является cons-ячейкой,
в противном случае ложен.
Следует отметить, пустой список не является cons-ячейкой, так 
\cd{(consp '{\emptylist})} \EQ\ \cd{(consp '{\nil})} \EV\ {\nil}. 
\begin{lisp}
(consp x) \EQ\ (typep x 'cons) \EQ\ (not (typep x 'atom))
\end{lisp}
\end{defun}

\begin{defun}[Функция]
listp object

\cdf{listp} истинен, если его аргумент является cons-ячейкой или пустым
списком {\emptylist}, в противном случае ложен. Она не проверяет
является ли <<список Ъ (true list)>> (завершающийся {\nil}) или <<с точкой (dotted)>>
(завершающийся не-null атомом).
\begin{lisp}
(listp x) \EQ\ (typep x 'list) \EQ\ (typep x '(or cons null))
\end{lisp}
\end{defun}

\begin{defun}[Функция]
numberp object

\cdf{numberp} истинен, если аргумент это любой вид числа, в
противном случае ложен.
\begin{lisp}
(numberp x) \EQ\ (typep x 'number)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
integerp object

\emph{integerp} истинен, если аргумент целое число, в противном
случае ложен.
\begin{lisp}
(integerp x) \EQ\ (typep x 'integer)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
rationalp object

\cdf{rationalp} истинен, если аргумент рациональное число (дробь или
целое), в противном случае ложен.
\begin{lisp}
(rationalp x) \EQ\ (typep x 'rational)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
floatp object

\cdf{floatp} истинен, если аргумент число с плавающей точкой, в
противном случае ложен.
\begin{lisp}
(floatp x) \EQ\ (typep x 'float)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
realp object

\cdf{realp} истинна, если аргумент является действительным числом,
иначе ложна.
\begin{lisp}
(realp x) \EQ\ (typep x 'real)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
complexp object

\emph{complexp} истинен, если аргумент комплексное число, в противном
случае ложен.
\begin{lisp}
(complexp x) \EQ\ (typep x 'complex)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
characterp object

\cdf{characterp} истинен, если аргумент -- буква, иначе
ложен.
\begin{lisp}
(characterp x) \EQ\ (typep x 'character)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
stringp object

\cdf{stringp} истинен, если аргумент строка, иначе ложен.
\begin{lisp}
(stringp x) \EQ\ (typep x 'string)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
bit-vector-p object

\cdf{bit-vector-p} истинен, если аргумент битовый вектор, иначе ложен.
\begin{lisp}
(bit-vector-p x) \EQ\ (typep x 'bit-vector)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
vectorp object

\cdf{vectorp} истинен, если аргумент вектор, иначе ложен.
\begin{lisp}
(vectorp x) \EQ\ (typep x 'vector)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
simple-vector-p object

\cdf{vectorp} истинен, если аргумент простой общий вектор, иначе
ложен.
\begin{lisp}
(simple-vector-p x) \EQ\ (typep x 'simple-vector)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
simple-string-p object

\cdf{simple-string-p} истинен, если аргумент простая строка, иначе
ложен.
\begin{lisp}
(simple-string-p x) \EQ\ (typep x 'simple-string)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
simple-bit-vector-p object

\cdf{simple-bit-vector-p} истинен, если аргумент простой битовый
вектор, иначе ложен.
\begin{lisp}
(simple-bit-vector-p x) \EQ\ (typep x 'simple-bit-vector)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
arrayp object

\cdf{arrayp} истинен, если аргумент массив, иначе ложен.
\begin{lisp}
(arrayp x) \EQ\ (typep x 'array)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
packagep object

\cdf{packagep} истинен, если аргумент является пакетом, иначе является
ложью.
\begin{lisp}
(packagep x) \EQ\ (typep x 'package)
\end{lisp}
\end{defun}

\begin{defun}[Функция]
functionp object

\begin{lisp}
(functionp x) \EQ\ (typep x 'function)
\end{lisp}
Типы \cdf{cons} и \cdf{symbol}
непересекаются с типом \cdf{function}.
\cdf{functionp} является ложной для символов и списков.
\end{defun}


\begin{defun}[Функция]
compiled-function-p object

\cdf{compiled-function-p} истинен, если аргумент --- скомпилированный
объект кода, иначе ложен.
\begin{lisp}
(compiled-function-p x) \EQ\ (typep x 'compiled-function)
\end{lisp}
\end{defun}

Смотрите также \cdf{standard-char-p}, \cdf{string-char-p},
\cdf{streamp}, \cdf{random-state-p},
\cdf{readtablep},
\cdf{hash-table-p} и \cdf{pathnamep}.

\section{Предикаты равенства}

Common Lisp предоставляет ряд предикатов для проверки равенства двух
объектов:  \cdf{eq} (наиболее частный), \cdf{eql}, \cdf{equal} и \cdf{equalp}
(наиболее общий). \cdf{eq} и \cdf{equal} имеют значения традиционные в
Lisp'е. \cdf{eql} был добавлен, потому что он часто бывает необходим, и
\cdf{equalp} был добавлен преимущественно, как версия \cdf{equal}, которая
игнорирует различия типов при сравнении двух чисел и различия регистров при
сравнении букв.
Если два объекта удовлетворяют любому из этих предикатов, то они
также удовлетворяют всем тем, которые носят более общий характер.

\begin{defun}[Функция]
eq x y

\cd{(eq \emph{x} \emph{y})} является истиной тогда и только тогда, когда,
\emph{x} и \emph{y} являются идентичными объектами.
(В реализациях, \emph{x} и \emph{y} обычно равны \cdf{eq} тогда и только
тогда, когда обращаются к одной ячейке памяти.)

Необходимо отметить, что вещи, которые выводят одно и то же, необязательно равны
\cdf{eql} друг другу. Символы с одинаковым именем обычно равны \cdf{eq} друг
другу, потому что используется функция \cdf{intern}.
Однако, одинаковые значения чисел могут быть не равны \cdf{eq}, и два похожих
списка обычно не равны \cdf{eq}.
Например:
\begin{lisp}
(eq 'a 'b) \textrm{ложь} \\
(eq 'a 'a) \textrm{истина} \\
(eq 3 3) \textrm{может быть истина или ложь, в зависимости от реализации} \\
(eq 3 3.0) \textrm{ложь} \\
(eq 3.0 3.0) \textrm{может быть истина или ложь, в зависимости от реализации} \\
(eq \#c(3 -4) \#c(3 -4)) \\
~~\textrm{может быть истина или ложь, в зависимости от реализации} \\
(eq \#c(3 -4.0) \#c(3 -4)) \textrm{ложь} \\
(eq (cons 'a 'b) (cons 'a 'c)) \textrm{ложь} \\
(eq (cons 'a 'b) (cons 'a 'b)) \textrm{ложь} \\
(eq '(a . b) '(a . b)) \textrm{может быть истина или ложь} \\
(progn (setq x (cons 'a 'b)) (eq x x)) \textrm{истина} \\
(progn (setq x '(a . b)) (eq x x)) \textrm{истина} \\
(eq \#{\Xbackslash}A \#{\Xbackslash}A) \textrm{может быть истина или ложь, в зависимости от реализации} \\
(eq "Foo" "Foo") \textrm{может быть истина или ложь} \\
(eq "Foo" (copy-seq "Foo")) \textrm{ложь} \\
(eq "FOO" "foo") \textrm{ложь}
\end{lisp}

В Common Lisp'е, в отличие от других диалектов, реализация в любое время может
создавать <<копии>> букв и чисел. (Это сделано для возможности в
повышении производительности.) Из этого следует правило,
что Common Lisp не гарантирует для букв и чисел то, что \cdf{eq}
будет истинен, когда оба аргумента являются <<одним и тем же>>.
Например:
\begin{lisp}
(let ((x 5)) (eq x x)) \textrm{может быть истиной или ложью}
\end{lisp}

Предикат \cdf{eql} означает то же, что и \cdf{eq}, за исключением того, что если
аргументы являются строковыми символами или числами одинакового типа, тогда
сравниваются их значения. Таким образом \cdf{eql} говорит, являются ли два объекта
<<концептуально (conceptually)>> одинаковыми, тогда как \cdf{eq} указывает, являются ли два
объекта <<реализационно (implementationally)>> одинаковыми. По этой причине
сравнительным предикатом для функций работы с последовательностями, описанными в
главе~\ref{KSEQUE}, является \cdf{eql}, а не \cdf{eq}.

\beforenoterule
\begin{implementation}
\cdf{eq} simply compares the two given pointers,
so any kind of object that is represented in an ``immediate'' fashion
will indeed have like-valued instances satisfy \cdf{eq}.
In some implementations, for example,
fixnums and characters happen to ``work.''
However, no program should depend on this, as other implementations
of Common Lisp might not use an immediate representation for these data types.
\end{implementation}
\afternoterule

\begin{obsolete}
An additional problem with \cdf{eq} is that the implementation is permitted
to ``collapse'' constants (or portions thereof)
appearing in code to be compiled if they are
\cdf{equal}.  An object is considered to be a constant in code to be compiled
if it is a self-evaluating form or is contained in a \cdf{quote} form.
This is why \cd{(eq "Foo" "Foo")} might be true or false; in interpreted
code it would normally be false, because reading in the
form \cd{(eq "Foo" "Foo")} would construct distinct strings for the two
arguments to \cdf{eq}, but the compiler might choose to use the same
identical string or two distinct copies as the two arguments in the
call to \cdf{eq}.  Similarly, \cd{(eq '(a . b) '(a . b))} might be true
or false, depending on whether the constant conses appearing in the
\cdf{quote} forms were collapsed by the compiler.  However,
\cd{(eq (cons 'a 'b) (cons 'a 'b))} is always false, because every distinct
call to the \cdf{cons} function necessarily produces a new and distinct cons.
\end{obsolete}

\begin{newer}
X3J13 voted in March 1989 \issue{QUOTE-SEMANTICS} to clarify that
\cdf{eval} and \cdf{compile} are not permitted either to copy or
to coalesce (``collapse'') constants (see \cdf{eq})
appearing in the code they process; the resulting
program behavior must refer to objects that are \cdf{eql} to the
corresponding objects in the source code.
Only the \cdf{compile-file}/\cdf{load} process is permitted
to copy or coalesce constants (see section~\ref{COMPILER-SECTION}).
\end{newer}
\end{defun}

\begin{defun}[Функция]
eql x y

Предикат \cdf{eql} истинен, если его аргументы равны \cdf{eq}, или 
если это числа одинакового типа и с одинаковыми значениями, или если это
одинаковые буквы.
Например:
\begin{lisp}
(eql 'a 'b) \textrm{ложь} \\
(eql 'a 'a) \textrm{истина} \\
(eql 3 3) \textrm{истина} \\
(eql 3 3.0) \textrm{ложь} \\
(eql 3.0 3.0) \textrm{истина} \\
(eql \#c(3 -4) \#c(3 -4)) \textrm{истина} \\
(eql \#c(3 -4.0) \#c(3 -4)) \textrm{ложь} \\
(eql (cons 'a 'b) (cons 'a 'c)) \textrm{ложь} \\
(eql (cons 'a 'b) (cons 'a 'b)) \textrm{ложь} \\
(eql '(a . b) '(a . b)) \textrm{может быть истиной или ложью} \\
(progn (setq x (cons 'a 'b)) (eql x x)) \textrm{истина} \\
(progn (setq x '(a . b)) (eql x x)) \textrm{истина} \\
(eql \#{\Xbackslash}A \#{\Xbackslash}A) \textrm{истина} \\
(eql "Foo" "Foo") \textrm{может быть истиной или ложью} \\
(eql "Foo" (copy-seq "Foo")) \textrm{ложь} \\
(eql "FOO" "foo") \textrm{ложь}
\end{lisp}

Обычно \cd{(eql 1.0s0 1.0d0)} будет ложью, так как \cd{1.0s0} и \cd{1.0d0} не
принадлежат одному типу данных. Однако в реализация может отсутствовать полный
набор чисел с плавающей точкой, поэтому в такой ситуации \cd{(eql 1.0s0 1.0d0)}
может быть истиной. Предикат \cdf{=} будет сравнивать значения двух чисел, даже
если числа принадлежат разным типам.

Если реализация поддерживает положительный и отрицательный нули, как различные
значения (так IEEE стандарт предлагает реализовывать формат числа с плавающей
точкой), тогда \cd{(eql 0.0 -0.0)} будет ложью. В противном случае, когда
синтаксис \cd{-0.0} интерпретируется, как значение \cd{0.0}, тогда \cd{(eql 0.0
  -0.0)} будет истиной. Предикат \cdf{=} отличается от \cdf{eql} в том, что
\cd{(= 0.0 -0.0)} будет всегда истинно, потому что \cdf{=} сравнивает
математические значения операндов, тогда как \cdf{eql} сравнивает, так сказать,
репрезентативные (representational) значения. FIXME.

Два комплексных числа будут равны \cdf{eql}, если их действительные части равны
\cd{eql} и мнимые части равны \cdf{eql}.
Например, \cd{(eql \#C(4 5) \#C(4 5))} является истиной и
\cd{(eql \#C(4 5) \#C(4.0 5.0))} является ложью.
Следует отметить, что \cd{(eql \#C(5.0 0.0) 5.0)} ложь,
а \cd{(eql \#C(5 0) 5)} истина.
В случае с \cd{(eql \#C(5.0 0.0) 5.0)}
два аргумента принадлежат разным типам и не равны \cdf{eql},
Однако, в случае \cd{(eql \#C(5 0) 5)},
\cd{\#C(5 0)} не является комплексным числом, и автоматически преобразуется, по
правилу канонизации комплексных чисел, в целое \cd{5}, так как дробное число
\cd{20/4} всегда упрощается до \cd{5}.

Случай \cd{(eql "Foo" "Foo")} обсуждался выше в описании \cdf{eq}. Тогда как
\cdf{eql} сравнивает значения чисел и букв, он не сравнивает
содержимое строк. Сравнение символов двух строк может быть выполнено с помощью
\cdf{equal}, \cdf{equalp}, \cdf{string=} или \cdf{string-equal}.
\end{defun}

\begin{defun}[Функция]
equal x y

Предикат \cdf{equal} истинен, если его аргументы это структурно похожие
(изоморфные) объекты. Грубое правило такое, что два объекта равны \cdf{equal}
тогда и только тогда, когда одинаково их выводимое представление.

Числа и буквы сравниваются также как и в \cdf{eql}.
Символы сравниваются как в \cdf{eq}. Этот метод сравнения символов может
нарушать правило и сравнении выводимого представления, в случае если различия
двух символов с одинаковым выводимым представлением.

Объекты, которые содержат другие элементы, будут равны \cdf{equal}, если они
принадлежат одному типу и содержащиеся элементы равны \cdf{equal}.
Эта проверка реализована в рекурсивном стиле и может быть зациклиться на
закольцованных структурах.

Для cons-ячеек, \cdf{equal} определён рекурсивно, как сравнение \cd{equal}
сначала \emph{car} элементов, а затем \emph{cdr}.

Два массива равны \cdf{equal} только, если они равны \cdf{eq}, с одним
исключением:
строки и битовые вектора сравниваются поэлементно.
Если какой-либо аргумент или оба содержат указатель заполнения (fill pointer),
данный указатель ограничит количество проверяемых с помощью \cd{equal}
элементов.
Буквы верхнего и нижнего регистров в строках расцениваются предикатом \cdf{equal}
как разные. (А \cdf{equalp} игнорирует различие в регистрах в строках.) 

Два объекта имени файла (pathname objects) равны \cdf{equal} тогда и только
тогда, когда все элементы (хост, устройство, и т.д.) равны. (Будут ли равны
буквы разных регистров зависит от файловой системы.) Имена файлов, которые равны
\cdf{equal}, должны быть функционально эквивалентны.

\cdf{equal} рекурсивно рассматривает только следующие типы данных: cons-ячейки,
битовые вектора, строки и имена файлов.
Числа и буквы сравниваются так, как если бы сравнивались с помощью
\cdf{eql}, а все остальные типы данных сравниваются как если бы с помощью \cdf{eq}.

\begin{lisp}
(equal 'a 'b) \textrm{ложь} \\
(equal 'a 'a) \textrm{истина} \\
(equal 3 3) \textrm{истина} \\
(equal 3 3.0) \textrm{ложь} \\
(equal 3.0 3.0) \textrm{истина} \\
(equal \#c(3 -4) \#c(3 -4)) \textrm{истина} \\
(equal \#c(3 -4.0) \#c(3 -4)) \textrm{ложь} \\
(equal (cons 'a 'b) (cons 'a 'c)) \textrm{ложь} \\
(equal (cons 'a 'b) (cons 'a 'b)) \textrm{истина} \\
(equal '(a . b) '(a . b)) \textrm{истина} \\
(progn (setq x (cons 'a 'b)) (equal x x)) \textrm{истина} \\
(progn (setq x '(a . b)) (equal x x)) \textrm{истина} \\
(equal \#{\Xbackslash}A \#{\Xbackslash}A) \textrm{истина} \\
(equal "Foo" "Foo") \textrm{истина} \\
(equal "Foo" (copy-seq "Foo")) \textrm{истина} \\
(equal "FOO" "foo") \textrm{ложь}
\end{lisp}
Для сравнения дерева cons-ячеек применяя \cdf{eql} (или любой другой желаемый
предикат) для листьев, используйте \cdf{tree-equal}.
\end{defun}

\begin{defun}[Функция]
equalp x y

Два объекта равны \cdf{equalp}, если они равны \cdf{equal},
если они буквы и удовлетворяют предикату \cdf{char-equal}, который
игнорирует регистр и другие атрибуты символов,
если они числа и имеют одинаковое значение, даже если числа разных типов,
если они включает в себя элементы, которые также равны \cdf{equalp}.

Объекты, которые включают в себя элементы, равны \cdf{equalp}, если они
принадлежат одному типу и содержащиеся элементы равны \cdf{equalp}.
Проверка осуществляется в рекурсивном стиле и может не завершится на
закольцованных структурах.
Для cons-ячеек, предикат \cdf{equalp} определён рекурсивно и сравнивает сначала
\emph{car} элементы, а затем \emph{cdr}.

Два массива равны \cdf{equalp} тогда и только тогда, когда они имеют одинаковое
количество измерений, и размеры измерений совпадают, и все элементы равны
\cdf{equalp}. Специализация массива не сравнивается. Например,
строка и общий массив, случилось так, имеют одинаковые буквы,
тогда они будут равны \cdf{equalp} (но определённо не равны \cdf{equal}).
Если какой-либо аргумент содержит указатель заполнения, этот указатель
ограничивает число сравниваемых элементов. Так как \cdf{equalp} сравнивает
строки побуквенно, и не различает разных регистров букв, то сравнение строк
регистронезависимо.

Два символа могут быть равны \cdf{equalp} только тогда, когда они \cdf{eq},
т.е. являются идентичными объектами.

\begin{new}
X3J13 voted in June 1989
\issue{EQUAL-STRUCTURE}
to specify that \cdf{equalp} compares components
of hash tables (see below), and to
clarify that otherwise \cdf{equalp} never recursively
descends any structure or data type other than the ones explicitly
described above: conses, arrays (including bit-vectors and strings), and pathnames.
Numbers are compared for numerical equality (see \cdf{=}),
characters are compared as if by \cdf{char-equal}, and all other
data objects are compared as if by \cdf{eq}.

Two hash tables are considered the same by \cdf{equalp} if and only if
they satisfy a four-part test:
\begin{itemize}
\item They must be
of the same kind; that is, equivalent \cd{:test} arguments were given to
\cdf{make-hash-table} when the two hash tables were created.

\item They must have the same number of entries (see \cdf{hash-table-count}).

\item For every entry (\emph{key1}, \emph{value1\/}) in one hash table
there must be a corresponding entry (\emph{key2}, \emph{value2\/}) in the
other, such that \emph{key1} and \emph{key2} are considered to be the same
by the \cd{:test} function associated with the hash tables.

\item For every entry (\emph{key1}, \emph{value1\/}) in one hash table
and its corresponding entry (\emph{key2}, \emph{value2\/}) in the
other, such that \emph{key1} and \emph{key2} are the same,
\cdf{equalp} must be true of \emph{value1} and \emph{value2}.
\end{itemize}
The four parts of this test are carried out in the order shown, and
if some part of the test fails, \cdf{equalp} returns \cdf{nil} and
the other parts of the test are not attempted.

If \cdf{equalp} must compare two structures and the \cdf{defstruct}
definition for one used the \cd{:type} option and the other did not,
then \cdf{equalp} returns \cdf{nil}.

If \cdf{equalp} must compare two structures and neither \cdf{defstruct}
definition used the \cd{:type} option,
then \cdf{equalp} returns \cdf{t} if and only if the structures have the
same type (that is, the same \cdf{defstruct} name) and the values
of all corresponding slots (slots having the same name) are \cdf{equalp}.

As part of the X3J13 discussion of this issue
the following observations were made.
    Object equality is not a concept for which there is a uniquely
    determined correct algorithm. The appropriateness of an equality
    predicate can be judged only in the context of the needs of some
    particular program. Although these functions take any type of
    argument and their names sound very generic, \cdf{equal} and \cdf{equalp} are
    not appropriate for every application. Any decision to use or not
    use them should be determined by what they are documented to do
    rather than by any abstract characterization of their function. If
    neither \cdf{equal} nor \cdf{equalp} is found to be appropriate in a particular
    situation, programmers are encouraged to create another operator
    that is appropriate rather than blame \cdf{equal} or \cdf{equalp} for ``doing
    the wrong thing.''
\end{new}

\begin{new}
Note that one consequence
of the vote to change the rules of
floating-point contagion
\issue{CONTAGION-ON-NUMERICAL-COMPARISONS}
(described in section~\ref{PRECISION-CONTAGION-COERCION-SECTION})
is to make \cdf{equalp}
a true equivalence relation on numbers.
\end{new}

\begin{lisp}
(equalp 'a 'b) \textrm{ложь} \\
(equalp 'a 'a) \textrm{истина} \\
(equalp 3 3) \textrm{истина} \\
(equalp 3 3.0) \textrm{истина} \\
(equalp 3.0 3.0) \textrm{истина} \\
(equalp \#c(3 -4) \#c(3 -4)) \textrm{истина} \\
(equalp \#c(3 -4.0) \#c(3 -4)) \textrm{истина} \\
(equalp (cons 'a 'b) (cons 'a 'c)) \textrm{ложь} \\
(equalp (cons 'a 'b) (cons 'a 'b)) \textrm{истина} \\
(equalp '(a . b) '(a . b)) \textrm{истина} \\
(progn (setq x (cons 'a 'b)) (equalp x x)) \textrm{истина} \\
(progn (setq x '(a . b)) (equalp x x)) \textrm{истина} \\
(equalp \#{\Xbackslash}A \#{\Xbackslash}A) \textrm{истина} \\
(equalp "Foo" "Foo") \textrm{истина} \\
(equalp "Foo" (copy-seq "Foo")) \textrm{истина} \\
(equalp "FOO" "foo") \textrm{истина}
\end{lisp}
\end{defun}

\section{Логические операторы}

Common Lisp содержит три логических оператора для булевых значений:
\cdf{and}, \cdf{or} и \cdf{not} (и, или, не, соответственно). \cdf{and} и
\cdf{or} являются управляющими структурами, потому что их аргументы
вычисляются в зависимости от условия.
Функции \cdf{not} необходимо инвертировать её один аргумент, поэтому она может
быть простой функцией.

\begin{defun}[Функция]
not x

\cdf{not} возвращает {\true}, если \emph{x} является {\false}, иначе
возвращает {\false}.
Таким образом она инвертирует аргумент как булево значение.

\cdf{null} то же, что и \cdf{not}, обе функции включены для ясности. По
соглашению принято использовать \cdf{null}, когда надо проверить пустой ли
список, и \cdf{not}, когда надо инвертировать булево значение.
\end{defun}

\begin{defmac}
and {form}*

\cd{(and \emph{form1} \emph{form2} ... )} последовательно слева направо
вычисляет формы. Если какая-либо форма \emph{formN} вычислилась в {\false},
тогда немедленно возвращается значение {\nil} без выполнения оставшихся форм. Если все
формы кроме последней вычисляются в не-{\false} значение, \cdf{and} возвращает
то, что вернула последняя форма.
Таким образом, \cdf{and} может использоваться, как для логических операций, где
{\false} обозначает ложь и не-{\false} значения истину, так и для условных
выражений.
Например:
\begin{lisp}
(if (and (>= n 0) \\
~~~~~~~~~(< n (length a-simple-vector)) \\
~~~~~~~~~(eq (elt a-simple-vector n) 'foo)) \\
~~~~(princ "Foo!"))
\end{lisp}
Выражение выше выводит \cd{Foo!}, если \cd{n}-ый элемент вектора
\cd{a-simple-vector} является символом \cd{foo}, проверяя при этом вхождения
\cd{n} в границы вектора \cd{a-simple-vector}. \cdf{elt} не будет вызвано с
аргументом \cd{n} выходящим за границы вектора, так как \cdf{and} гарантирует
ленивую проверку аргументов слева направо.

Оператор \cdf{and} отличается тем, что в определённых случаях
вычисляет не все аргументы.

Запись предыдущего примера
\begin{lisp}
(and (>= n 0) \\
~~~~~(< n (length a-simple-vector)) \\
~~~~~(eq (elt a-simple-vector n) 'foo) \\
~~~~~(princ "Foo!"))
\end{lisp}
будет выполнять ту же функцию. Разница в них только стилистическая. Некоторые
программисты никогда не используют в форме \cdf{and} выражения с побочными
эффектами, предпочитая для этих целей использовать \cdf{if} или \cdf{when}. 

Из общего определения можно сделать дедуктивный вывод о том, что 
\cd{(and \emph{x})} \EQ\ \emph{x}. Также \cd{(and)} выполняется в {\true},
который тождественен этой операции.

Можно определить \cdf{and} в терминах \cdf{cond} таким образом:
\begin{lisp}
(and \emph{x} \emph{y} \emph{z} ... \emph{w}) \EQ\ (cond \=((not \emph{x}) {\false}) \\
\>((not \emph{y}) {\false}) \\
\>((not \emph{z}) {\false}) \\
\>$\ldots$ \\
\>({\true} \emph{w}))
\end{lisp}

Смотрите \cdf{id} и \cdf{when}, которые иногда являются стилистически более
удобными, чем \cdf{and} в целях ветвления.
Если необходимо проверить истинность предиката для всех элементов списка или
вектора (element 0 \emph{and} element 1 \emph{and}
element 2 \emph{and} $\ldots$), можно использовать функцию \cdf{every}.
\end{defmac}

\begin{defmac}
or {form}*

\cd{(or \emph{form1} \emph{form2} ... )} последовательно выполняет каждую
форму слева направо. Если какая-либо непоследняя форма выполняется в что-либо
отличное от {\false}, \cdf{or} немедленно возвращает это не-{\false} значение
без выполнения оставшихся форм. Если все формы кроме последней, вычисляются в
{\false}, \cdf{or} возвращает то, что вернула последняя форма.
Таким образом \cdf{or} может быть использована как для логических операций, 
в который {\false} обозначает ложь, и не-{\false} истину,
так и для условного выполнения форм.

Оператор \cdf{or} отличается тем, что в определённых случаях
вычисляет не все аргументы.

Из общего определения, можно сделать дедуктивный вывод о том, что \cd{(or
  \emph{x})} \EQ\ \emph{x}. Также, \cd{(or)} выполняется в {\nil}, который
тождественен этой операции.

Можно определить \cdf{or} в терминах \cdf{cond} таким образом:
\begin{lisp}
(or \emph{x} \emph{y} \emph{z} ... \emph{w}) \EQ\ (cond (\emph{x}) (\emph{y}) (\emph{z}) ... ({\true} \emph{w}))
\end{lisp}

Смотрите \cdf{id} и \cdf{unless}, которые иногда являются стилистически более
удобными, чем \cdf{or} в целях ветвления.
Если необходимо проверить истинность предиката для всех элементов списка или
вектора (element 0 \emph{or} element 1 \emph{or}
element 2 \emph{or} $\ldots$), можно использовать функцию \cdf{some}.
\end{defmac}

\fi