MTS 8: LISP and SLIP in MTS
June 1976
(DEFUN SAMPLE C (PROG (X N)
(SETQ N 1)
A (COND ((GREATERP N C) (RETURN X))
((SETQ X (APPEND X (CAR (ARG N)))))
(SETQ N (ADD1 N))
(GO A)))
This creates a function called SAMPLE, which returns a list of the CARs
of all of its arguments. SAMPLE takes an indefinite number of
arguments, or no arguments.
(SAMPLE) = NIL
(SAMPLE ’(S R T) ’(P Q) ’(R)) = (S P R)
DEFINE is the basic function for defining and naming new LISP
functions. The basic form of DEFINE is:
(DEFINE (NAME TYPE DEFN)...(NAME TYPE DEFN))
DEFINE is an N-type function which takes an indefinite number of
definitions, DEFN, as arguments. NAME is always an atom, which is the
name of the entity being defined. TYPE may be EXPR, BUG, ARRAY, SUBR,
NSUBR, or FSUBR, or may be omitted, in which case EXPR is assumed.
For an EXPR or BUG, the DEFN given is put on the PLIST of NAME
exactly as it appears. Thus, to DEFINE an EXPR, the entire LAMBDA-
expression must be written out. The form and meaning of BUG definitions
will be explained in the next subsection.
The ARRAY and SUBR definitions require special parameters which
respectively define LISP arrays and create linkage to external subrou-
tines. The form and meaning of these definitions is explained in the
subsections "Arrays" and "Calling External Routines from LISP."
The value returned from DEFINE is the name defined if only one
definition was given, or a list of the names defined if more than one
was given. For example,
(DEFINE (TEST EXPR (LAMBDA (Y) (PRINT Y)))) = TEST
This defines a function TEST which merely prints its argument.
Note: DEFUN and DEFINE, which place properties on the PLISTs of
atoms, do not work in the same way as PUT. They compare the current
indicator being placed on the PLIST with the first indicator already on
the PLIST; if they are the same, the PVAL of that indicator is replaced
with the new definition. If the current indicator does not match the
first one on the PLIST, the new property is merely placed in front of
it. This process guarantees that the most recent function definition of
an atom will be the active one.
40 LISP

MTS 8: LISP and SLIP in MTS
June 1976
BUG ___
In order to facilitate the writing of debugging routines in LISP, a
new facility called a BUG has been added to LISP/MTS. A BUG is a
pseudofunction definition which can be placed on the property-list of an
atom already defined as a function. BUG will cause an interception of
the function upon entry and upon exit. The user can display the
arguments sent to the function or any other LISP structures, can test
entry conditions, and can display the value returned from the function.
The basic form of a BUG definition is as follows:
(DEFINE (A BUG (DEFN1 . DEFN2)))
DEFN1 is a function specification (usually a LAMBDA-expression) which
must either be an FLAMBDA-function or have the same number of arguments
as the function A. Immediately prior to calling the function A, DEFN1
will be called. If it is an FLAMBDA-function, its dummy argument will
be bound to a list of the arguments of A. If it is a LAMBDA or NLAMBDA
function, its dummy arguments will be bound to the arguments of A. For
the purposes of BUGs, LAMBDA and NLAMBDA functions are identical.
After DEFN1 is called, A will be invoked as if the BUG were not
present. DEFN1 does not have the ability to alter the arguments sent to
A (except, of course, by physical modification of the argument struc-
tures), but it can abort the call entirely. (See the subsection "Error
Recovery and Debugging Procedures.")
Upon returning from the function A, DEFN2 is called. DEFN2 may be a
LAMBDA or NLAMBDA function of one argument, in which case that argument
will be bound to the value returned from A. If DEFN2 is an FLAMBDA, its
dummy argument will be bound to a list of the value returned from A.
Notes:
(1) When a BUG is placed on the property-list of an atom, and,
subsequently, a new function definition is placed on the same
property-list, the BUG will be ignored when the function is
called. In other words, BUGs must precede other system indica-
tors on a property-list in order to be effective. Thus, in a
call to DEFINE which defines a function and a BUG for the same
atom, the function definition must precede the BUG definition.
(2) One or more BUGs appearing on the property-list of an atom A,
which has no function definition, will generate an error if A is
invoked as a function.
(3) Multiple BUGs appearing on the property-list of an atom,
followed by a function definition, will be treated as "stacked"
and invoked in order. The input BUG functions will be executed
from first to last, followed by the function itself, and finally
the output BUG functions, from last to first.
LISP 41