[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


I just received the following message from Gary Drescher.
It seems that there will be three proposals to discuss on the meeting on
Thursday (Math Sciences auditorium from 4 to 6pm).  HP, Xerox, and the
following one (LMI):

     ----- Begin Forwarded Messages -----

Return-Path: <@MIT-MC.ARPA:GLD@MIT-OZ>
Received: from MIT-MC.ARPA by Xerox.ARPA ; 15 AUG 85 12:54:01 PDT
Received: from MIT-OZ by MIT-MC.ARPA via Chaosnet; 15 AUG 85  15:51:03
Date: Thu, 15 Aug 85 15:52 EDT
Message-ID: <GLD.12135387162.BABYL@MIT-OZ>
To: Kahn.pa
Subject: ObjectLisp
In-reply-to: Msg of 15 Aug 1985  13:22-EDT from GLD

Hi Ken.  The folks at LMI tell me I should send my current ObjectLisp
to the appropriate CommonLisp mailing list, whose name I've
misplaced.  So I'm mailing it to you instead; could you be so kind as to
forward it to the list?

I'll be at IJCAI on the 21st & 22nd; see you then.


mit-oz:<gld.obl>manual.tex   (LaTex format)

%       -*- Mode:Text -*-

\newcommand{\code}[1]{\mbox{\tt #1}}
\newcommand{\argd}[1]{{\normalsize \sl #1}}
\newcommand{\deff}[2]{\bigskip \noindent
  \makebox[\textwidth]{\code{#1} \hfill {\it #2}}}
\newcommand{\OBL}{{\sc ObjectLisp\/}}
\newcommand{\LISP}{{\sc Lisp\/}}


{\centering \Large \OBL{} Manual\\[2ex] \large Gary L. Drescher\\}

\noindent \makebox[\textwidth]{Copyright \copyright Gary L. Drescher
 \hfill Draft of \today}

\section{Introduction: Objects and \OBL}

\OBL{} is a dialect of \LISP{} that facilitates object-oriented
programming.\footnote{The Flavors system is another such facility.  This
document introduces only \OBL{}; but there are occasional footnotes
to Flavors users, explaining how some common applications of Flavors can
mimicked using \OBL.} Object-oriented programming involves the creation
various {\em classes} (kinds or categories) of things, and {\em
(individuals, examples) of those classes.  For example, there might be a
of ``automobiles'', and ``the car I just bought'' might be an instance
of that
class.  The classes often form a hierarchy\footnotemark--
generally, the classes form a {\em lattice}.  The difference is that in
hierarchy, each class is a specialization of just one other class; in a
lattice, more than one class can be combined when making a subclass.}
you can
make a new class by saying that it is a {\em specialization}, a more
version, of another class; for example, ``convertible'' is a
specialization of
``automobile''.  In \OBL, both classes and instances are implemented by
are simply called {\em objects}.  \footnote{The word {\em object} is
traditionally used to refer to any kind of datum in \LISP-- a list, a
symbol, a
fixnum, etc.  In this document, however, {\em object} refers only to the
object-entities provided by \OBL for object-oriented programming.}

In \OBL, an object has a collection of bindings of variables and
which determine the object's properties and behavior.  A {\em variable
can be thought of as a distinct version of some variable, with its own
value for that variable; for example, one object might have a binding of
symbol \code{x} to the value 3, while another binds \code{x} to 4.  The
ordinary \LISP{} environment is considered \OBL's {\em global object},
symbols are bound there to their ordinary \LISP{} global values.  A {\it
function binding} is similar to a variable binding, but it associates a
with a definition, rather than a value.  Ordinary use of \code{defun}
creates a
global function binding.

A {\em specialization} of an existing object is a new object that can be
its own variable and function bindings; in addition, it {\em inherits}
all the
bindings of the previous object, except for symbols whose bindings the
object replaces (this is called {\em shadowing}) with bindings of its
own.  By
making a specialization of a class object, you can make a new class that
just like the old one, except for the differences you specify.

Similarly, an instance of a class inherits bindings from that class, and
can be
given exceptions and contributions of its own; in these respects, an
object is just like a specialized class object.  The difference is a
matter of
convention, of how the objects are built and used: the bindings given to
instance describe the properties of some {\em individual} entity; the
of a class describe things common to {\em all} entities of a certain

For example, we might define a class object called \code{icon}.
Instances of
this class are small pictures that can be moved about on the graphics
The \code{icon} object includes, say, a binding for the function
(which expects two numbers specifying the new X and Y coordinates at
which to
display the picture).  \code{icons}'s binding of the function
(along with any other bindings \code{icon} may have) is inherited by all
specializations of \code{icon}, and also by all instances of
\code{icon--} all
such objects share that inherited binding, except those objects where
binding has been shadowed.  In addition, each \code{icon} instance
(let's say) a binding of the variables \code{x-coord} and
\code{y-coord}; these
say where on the screen the icon is currently drawn.  Obviously, those
variables can't be shared by all icons; each icon needs its own bindings
\code{x-coord} and \code{y-coord}, since different icons can be in

Typically, as in this example, class objects are given function
bindings, and
instance objects are given variable bindings.  The functions determine
members of a class behave, and are shared by all instances of a class;
variables describe the state or attributes of individual instances, and
instance has its own.  We speak of {\em class functions} and {\em
variables}\footnote{These are analogous to flavor methods and instance
variables, respectively, in the Flavor system.  Flavors provide no
for class variables and instance functions, however.}.  In addition
less commonly) it can be useful to have variable bindings in class
(class variables) and function bindings in instance objects (instance

\OBL{} requires the use of only a handful of new primitive functions:
 \item \code{make-obj} and \code{kindof} are used to make new objects.
 \item \code{ask} is used to cause any sequence of \LISP{} expressions
to be
evaluated in the environment of a given object.
 \item \code{defobfun} is used (in place of \code{defun}) to create
function bindings in an object.
 \item \code{have} is used to create variable bindings in an object.

These primitives are described in
section~\ref{building-objects-section}.  In
addition, there are other object primitives that, although not strictly
necessary, are useful to abbreviate common patterns of functions, or for
increased efficiency and clarity, or for esoteric manipulation of
These are described in section~\ref{reference-section}.

\section{Building object systems}
\subsection{Making an object}

The function \code{make-obj} creates and returns a fresh object.  For
    (setq icon (make-obj))}
The global variable \code{icon} is now bound to a new object.

Let's define the functions \code{goto-xy}, \code{draw-self}, and
\code{undraw-self} for the object \code{icon}.
    (defobfun (goto-xy icon) (x y)
      (undraw-self x-coord y-coord)
      (draw-self x y)
      ;; Record the new position for next time.
      (setq x-coord x)
      (setq y-coord y))
    ; Draw icon at X,Y.
    (defobfun (draw-self icon) (x y)
      (bitblt-to-graphics-window tv:alu-xor icon-array x y))
    ; Erase icon already drawn at X,Y.
    (defobfun (undraw-self icon) (x y)
      (draw-self x y)) ; (XOR'ing the same thing twice cancels.)
(Assume that the global function \code{bitblt-to-graphics-window} has
defined, and that the global variables {\code x-coord} and
\code{y-coord} are
bound to coordinate numbers, and \code{icon-array} is bound to an array
has the icon's picture.)

\code{defobfun} has the same syntax as \code{defun}, except for the
function specifier.  Instead of just the function's name, there is a
list of
the function's name and another symbol.  The other symbol must be bound
to an
object.  The function is defined locally to that object-- that is, the
is given its own function binding of the symbol that names the function.
the object bound to \code{icon} gets its own function bindings of
\code{goto-xy}, \code{draw-self}, and \code{undraw-self}.

Suppose the global variables \code{x-coord} and \code{y-coord} have both
initialized to 0, and the icon has been drawn at (0,0).  To move the
icon to
(100,100), we say
    (ask icon (goto-xy 100 100))

The first argument to \code{ask} must be an object.  The remainer of the
\code{ask} form-- the body of the \code{ask}-- is evaluated in the
environment of the designated object.  This means that that object's
are in effect during the evaluation of the body.   (For the duration of
evaluation, The object passed to \code{ask} is called the {\em current
object}.)  In particular, the function \code{goto-xy} is bound in the
\code{icon} object, due to the \code{defobfun} definition above; so
\code{icon}'s definition is the one that is used when the above
form is evaluated.  When \code{goto-xy} calls \code{draw-self} and
\code{undraw-self}, we are still (dynamically) within the body of the
\code{ask}, so \code{icon}'s function bindings of \code{draw-self} and
\code{undraw-self} are referred to.

After \code{goto-xy} has run, \code{x-coord} and \code{y-coord} are both
set to
100, and the drawing of the icon has moved to (100,100).  Note that we
defined \code{goto-xy} {\em only} for the \code{icon} object; if we just
\code{(goto-xy 50 75)} without addressing \code{icon}, we get an
undefined-function error (unless of course someone has {\em also}
\code{goto-xy} globally; in that case, the global definition is

\subsection{Classes and instances}

You may have noticed something unsatisfactory about this example: there
is just
one version of each of the variables \code{x-coord}, \code{y-coord}, and
\code{icon-array} (\code{icon-array} is global; \code{x-coord} and
\code{y-coord} are bound in \code{icon}.)  How, then, is it possible to
several different icons, all at different locations (and perhaps with

The answer is to think of \code{icon} as a class object, and to create
corresponding instance objects.  Here's how that works.  Suppose we wish
create two icon instances, \code{icon1} and \code{icon2}.   We say
    (setq icon1 (kindof icon))
    (setq icon2 (kindof icon))

\code{kindof} creates a new object as a specialization of the object(s)
provided as inputs.  (Actually, \code{kindof} and \code{make-obj} are
synonyms; \code{kindof} sounds more natural when arguments are passed,
both functions accept zero or more arguments.)  When there is just one
argument-- as in this example-- the specialized object {\em inherits}
all the
bindings of the {\em base object} (the object that it specializes, that
it is
``based on'').  For example, that the above definitions of
\code{draw-self}, and \code{undraw-self} are accessible during a
to \code{icon1} or \code{icon2}, as well as to \code{icon} itself.

In addition to inheriting bindings, a specialized object can be given
its {\it
own} bindings.  These are {\em not} inherited by the base object;
only goes in one direction.  But of course, other objects can be made as
specialized objects of a given specialized object; {\em those} objects
inherit the bindings established in the given object and they will also
inherit, in turn, the bindings that the given object inherited.  The
exception to this inheritance occurs when an object {\em shadows} a
variable or
function binding that it would otherwise have inherited; it does this by
its {\em own} binding of the same variable or function, which supercedes
one it would have inherited.

We want \code{icon1} and \code{icon2} to be instances of \code{icon}.
Thus, we
must supply these objects with appropriate instance variables--
variables that
specify the individual attributes of the two icons.  In particular, we
\code{icon1} and \code{icon2} each to have its own binding of the
\code{x-coord}, \code{y-coord}, and \code{icon-array}.  We use
to create these bindings. {\code{(have '\argd{sym val})} causes
the current object to acquire its own binding of the symbol \argd{sym},
value \argd{val}.
    (ask icon1
      (have 'x-coord 0)
      (have 'y-coord 25)
      (have 'icon-array circular-design))

Now \code{icon1} has its own bindings of \code{x-coord} and
\code{y-coord} (to
0 and 25, respectively), and of \code{icon-array} (to an array with a
design, assuming that the global variable \code{circular-design} had
been bound
to such an array).  To initialize \code{icon1}'s picture on the screen,
should also say
    (ask icon1 (draw-self 0 25))
And similarly:
    (ask icon2
      (have 'x-coord 0)
      (have 'y-coord 50)
      (have 'icon-array square-design)
      (draw-self 0 50))
\code{icon1} and \code{icon2}'s variable bindings are separate from one
another, and from any global bindings of the same symbols.  For example,
evaluating \code{y-coord} globall still returns 100.  But {\code (ask
y-coord)} returns 25, and \code{(ask icon2 y-coord)} returns 50.

Suppose we say \code{(ask icon1 (goto-xy 0 75))}.  When \code{goto-xy}
done within \code{icon} instead of \code{icon1} (above), occurrences of
\code{x-coord}, \code{y-coord}, and \code{icon-array} in the body of
goto-xy} referred to the {\em global} bindings of those symbols; that
because the \code{icon} object had no bindings of those symbols.  (And
if we
now said \code{(ask icon (goto-xy 0 75))}) again, the references to
variables would {\em still} refer to their global values.)  But with
(ask icon1 (goto-xy 0 75))}, those same references occur during a
to \code{icon1}, which {\em does} bind those symbols.  Hence, the
now are to \code{icon1}'s bindings.  Notice especially that this is true
for {\em getting} the values of these symbols (when the symbols are
to provide arguments to \code{goto-xy}'s call to \code{undraw-self}),
and also
for {\em setting} their values (by the \code{setq}'s at the end of
goto-xy}).  \code{setq} never {\em creates} new variable bindings in an
only \code{have} does that.  \code{setq} just changes the value of an
existing binding.\footnote{Readers familiar with the taxonomy of binding
schemes will notice that objects are dynamically scoped closures.  That
upon entry to an object (via \code{ask}), all the variables for which
object has bindings are dynamaically bound to the associated values;
exiting the \code{ask}, those bindings are dissolved (the values first
saved in the object, for the sake of any subsequent \code{ask} to that
object).  (More accurately, if one \code{ask} occurs dynamically within
another, the outer \code{ask}'s object is exited before entering the
\code{ask}, then re-entered upon exiting the inner \code{ask}).} So now,
\code{(ask icon1 y-coord)} returns 75; but \code{(ask icon2 y-coord)}
returns 25, and evaluating \code{y-coord} globally still returns 100.

Now we have an \code{icon} class and some icon instances, but something
still awry.  Surely it is unacceptable to have to initialize each new
by \code{ask}'ing it to \code{have} each of its instance variables (and
to draw itself initially), as we did above.  This problem will be
acute when we build objects that need dozens of instance variables and
initializing actions.  Fortunately, of course, there's no need to do all
manually-- we can define a function to do it automatically.  For
    (defobfun (exist icon) (&rest args &key* (x 0) (y 0)
                                             (array default-icon-array))
      ;; Establish a binding of the variable X-COORD to the value of
      ;; the EXIST function's parameter X:
      (have 'x-coord x)
      ;; Etc:
      (have 'y-coord y)
      (have 'icon-array array)
      ;; Make the initial drawing.
      (draw-self x y)
      ;; (Ignore the following line for now; it is explained below.)
      (apply 'shadowed-exist args))
 From now on, making new ICON instances is much easier; for example:
    (setq icon3 (kindof icon))  (ask icon3 (exist))
    (setq icon4 (kindof icon))  (ask icon4 (exist 'array
The caller can provide keyword arguments to override the \code{exist}
function's defaults for the initial instance-variable values.  Of
course, we
might instead have defined the \code{exist} function to ``hardwire''
some or
all of the initial values, rather than giving the caller the choice of
supplying them; and we might have had other \code{exist} arguments, ones
did not correspond to instance-variable initializations.

Note: \code{defobfun} treats \code{\&key*} arguments slightly
differently than
\code{\&key} ones.  With \code{\&key*,} the default is that a key name
is {\it
not} put in the keyword package; hence \code{(exist 'array ...)} above
than \code{(exist :array ...)}.  Also, \code{\&allow-other-keys} is
when \code{\&key*} is used.  The rationale for these differences is
at the end of section~\ref{key-explanation}.

The idea behind the \code{exist} function is simple: although the
instances of \code{icon} cannot share instance variables with one
each instance needs its own set of instance variables-- the instances
{\em can}
share a ``template'' for {\em creating} those variables (and for
other needed initializations).  That shared template is provided, in the
of the \code{exist} function bound in the \code{icon} class object.
There is
nothing magic about using the name \code{exist} for this function; but
it turns
out to be a good idea to have a standard name for instance-initializing
functions, and \code{exist} is that standard.


We have just seen that \OBL{} does not insist on distinguishing between
and instances-- both are just objects, made by the function
\code{kindof} (or
\code{make-obj})).  In fact, the distinction between classes and
is entirely a matter of the conventions that the user follows.  Recall
when we first created the \code{icon} object, we didn't have to say
whether it
was a class or an instance-- and indeed, we used it as {\em both}.  We
the class functions \code{goto-xy}, \code{draw-self}, and
locally to \code{icon,} as though \code{icon} were a class object.  But
when we
actually told \code{icon} to move to a new position (by saying
\code{(ask icon
(goto-xy 100 100))}, we were treating it as a instance.  It is often
when creating a new class of object on the fly, to treat the class as a
prototype instance.  That way, you don't have to decide in advance what
instance variables need to be created-- you just use global variables.
conversely, it may be useful to treat an instance object as a prototype
by giving the instance some experimental function bindings to specialize
behavior.  But the conventional class/instance distinction is important,
and it
is strongly recommended that object-oriented software be designed
according to
this convention.

To facilitate the class/instance distinction, \OBL{} provides the
\code{oneof} for making instance objects, and \code{defkind} for making
objects.  Both of these primitives can be thought of as calling
as well as performing some auxiliary actions.  \code{oneof} and
are useful because their auxiliary actions are especially convenient for
instances and classes (respectively); and because these primitives make
implicit declarations about the nature of the object being created,
in more efficient code.  \code{oneof} and \code{defkind} are documented
part~\ref{reference-oneof} of the reference section.

\subsection{Object binding vs lexical binding}

Here is a point that deserves emphasis, as it is an easy one to stumble
lexical binding {\em overrides} object binding; only {\em free
references} can
refer to object bindings.  This is now explained in detail.

Within a lambda expression (or within any implicit lambda expression,
such as a
\code{defun} or a \code{let}), certain variables-- the parameters in the
arglist of a lambda expression or function body, or the variables in the
varlist of a \code{let--} are {\em lexically bound}.  Suppose the
\code{a} is lexically bound in any kind of lambda expression.  Any
reference to
\code{a} in the body of that expression-- any form to get or set the
value of
\code{a--} refers to the current lexical binding of \code{a,} {\em
of whether we happen to be inside a \code{ask} to an object that
contains a
binding of \code{a.} For example, suppose the object bound to the symbol
\code{obj1} binds \code{a} to 10 and \code{b} to 20; and suppose we say:
    (let ((a 3))
      (ask obj1
         (setq a (1+ a))
         (print a)
         (setq b (1+ b))
         (print b)))

The \code{a} that gets incremented by the expression \code{(setq a (1+
a))} is
the \code{let}'s binding of \code{a}, {\em not} \code{obj1}'s binding of
\code{a}; \code{obj1}'s binding of \code{a} is unaffected.  Similarly,
\code{a} in \code{(print a)} refers to the \code{let}'s binding of
hence, the number 4 is printed.  The two references to \code{b}, on the
hand, are {\em free} references-- that is, \code{b} is not lexically
bound in
this expression.  Therefore, \code{b} {\em does} refer to \code{obj1}'s
binding; \code{obj1}'s value for \code{b} is incremented, and the new
21, is printed.  (Of course, if \code{obj1} had no binding for \code{b,}
the reference would be to the global variable \code{b}.)

(A possible source of confusion: the function \code{have} {\em creates}
object-binding of the specified variable, rather than {\em referring} to
existing binding; so \code{(have 'a {\argd value})} gives the current
its own binding of A, {\em even if} the \code{have} occurs in an
where A is lexically bound.)

To repeat: lexical binding overrides object binding.  This fact can be
when you need to communicate one object's value for some variable to
object that binds the same variable.  For example, you should convince
that this expression:
    (ask icon1 (let ((x x-coord)
                      (y y-coord))
                  (ask icon2 (goto-xy x y))))
changes \code{icon2}'s position to coincide with \code{icon1}'s, whereas
    (ask icon1 (ask icon2 (goto-xy x-coord y-coord)))
leaves \code{icon2}'s position unchanged, since \code{x-coord} and
\code{y-coord} refer here to \code{icon2}'s own bindings.

Functions, as well as variables, can be lexically bound; function
binding is
accomplished in \LISP{} by using \code{flet} or \code{labels}.  For
too, lexical binding overrides object binding.

\section{Specialized classes}

The real power of object-oriented programming comes from being able to
{\em specialize} existing classes of objects.  A new object can be built
by saying how it {\em differs} from an old one; everything not mentioned
just inherited, and stays the same.

For example, suppose we want to make a kind of icon that draws a line
when it
moves, leaving a trail behind it.  First, we make a specialized object
    (setq icon-with-trail (kindof icon))
This time, we're going to regard the new object as a specialized {\em
object, whereas in the previous section, \code{kindof} was used to
create a
specialization of \code{icon} that we regarded as an {\em instance} of

\code{icon-with-trail} needs to shadow the inherited function binding of
\code{goto-xy} (from \code{icon}), and to supply its own definition
\code{icon-with-trail}'s \code{goto-xy} should do what the shadowed
\code{goto-xy} does; and in addition, the new \code{goto-xy} function
needs to
draw a line.  Here is a definition that is {\em almost} right:
    (defobfun (goto-xy icon-with-trail) (x y)
      ;; Draw line from (X-COORD,Y-COORD) to (X,Y), assuming that the
      ;; DRAW-LINE-ON-GRAPHICS-SCREEN has been suitably defined.
      (draw-line-on-graphics-screen x-coord y-coord x y)
      ;; Now invoke the shadowed GOTO-XY.
      (goto-xy x y)) ; This line is >WRONG<, however.
The problem here is that the occurrence of \code{goto-xy} (in the last
will {\em not} refer to the shadowed version of \code{goto-xy}; it will
to the {\em shadowing} definition, which is the above definition itself.
version of \code{goto-xy} will call {\em itself}, not the shadowed
version of

It is common for a shadowing definition of a function to want to call
shadowed version, {\em in addition} to performing some new idiosyncracy.
we could accomplish this by looking up \code{icon}'s definition of
\code{goto-xy,} and copying it into the end of \code{icon-with-trail}'s
definition.  But it is much better to be able to {\em call}
\code{goto-xy}, without needing to know how it was implemented-- and
needing to {\em change} \code{icon-with-trail}'s version of
\code{goto-xy} if
\code{icon}'s version is ever redefined, and we want to stay compatible
it.  \OBL's {\em shadowed} facility makes this possible.  Here is the
definition of \code{icon-with-trail}'s \code{goto-xy}:
    (defobfun (goto-xy icon-with-trail) (x y)
      (draw-line-on-graphics-screen x-coord y-coord x y)
      (shadowed-goto-xy x y))

Within the text of a definition of the function {\em name}, the symbol
\mbox{\code{shadowed-}{\em name}} refers to the version of {\em name}
that {\it
would have} been inherited, had not this very definition shadowed it.
So here,
for \code{icon-with-trail}, we've added our line-drawing idiosyncracy to
\code{goto-xy}'s shadowed behavior, without needing to be concerned with
that shadowed behavior was implemented.

Next, suppose we say:
    (setq icon5 (kindof icon-with-trail))
    (ask icon5 (exist 'x 10 'y 10))
    (ask icon5 (goto-xy 50 50))
Now we've got \code{icon5} drawn at (50,50), and a line drawn on the
 from (10,10) (where \code{icon5} first appeared) to (50,50).  Note that
\code{exist} function just invoked was inherited by \code{icon5} from
\code{icon-with-trail,} which in turn inherited it from \code{icon}; the
functions \code{draw-self} and \code{undraw-self} are similarly

Here's another specialization of \code{icon}:
    (setq boundary-icon (kindof icon))
    (defobfun (goto-xy boundary-icon) (x y)
      (unless (out-of-bounds? x y)
         (shadowed-goto-xy x y)))
    (defobfun (out-of-bounds? boundary-icon) (x y)
      (or (< x (car x-bounds)) (>= x (cadr x-bounds))
          (< y (car y-bounds)) (>= x (cadr y-bounds))))
    (defobfun (exist boundary-icon) (&rest args &key* (x-bounds '(0
                                                      (y-bounds '(0
      (have 'x-bounds x-bounds)
      (have 'y-bounds y-bounds)
      (apply 'shadowed-exist args))
    (setq icon6 (kindof boundary-icon))
    (ask icon6 (exist 'scale 5))
\code{boundary-icon} is a kind of \code{icon} that never strays outside
certain rectangular region.  The region is specified by the instance
\code{x-bounds} (which is a list of the lower and unpper values for the
x-coordinate) and the instance variable \code{y-bounds} (similarly).
that \code{boundary-icon}'s definition of \code{goto-xy} doesn't
invoke \code{shadowed-goto-xy}-- first, it checks to see if the new
coordinates are within bounds.  If they aren't, no further action is
taken; if
they are, \code{goto-xy} behaves as usual.

Notice how \code{boundary-icon}'s \code{exist} function is set up.  This
version of \code{exist} only knows about the instance variables that are
special to \code{boundary-icon}: the variables \code{x-bounds} and
\code{y-bounds}.  Any other key arguments that might be passed to
\code{boundary-icon}'s \code{exist} function are simply passed on to the
shadowed} \code{exist} function (via the parameter \code{args}); and
\code{boundary-icon}'s \code{exist} function has no knowledge of what
passed-on arguments may be.  This compartmentalization of knowledge is
valuable; to support it, \code{exist} functions should {\em always} be
with no arguments other than \code{\&key*} ones.  And \code{exist}
should always be defined to call \code{shadowed-exist}, passing all
along, so that the initializing actions (especially instance-variable
of the base class(es) happen along with the actions peculiar to the
object's \code{exist} definition.

\label{key-explanation} \code{\&key*} was introduced on
page~\pageref{key-intro}.  Now the rationale for \code{\&key*} becomes
apparent.  First, extraneous arguments to an \code{exist} function might
expected by a \code{shadowed-exist}; so each \code{exist} function
should allow
all keys (which happens automatically with \code{\&key*}.  Second, it is
important to avoid accidental name conflicts between one \code{exist}
function's keywords and those of a shadowed \code{exist} procedure
called be
the first one.  The only way to assure this avoidance, without knowing
other names involved, is to keep the symbols in different {\em
hence, \code{\&key*'s} default of keeping the keyword symbol's original
package, rather than moving all keyword symbols into the keyword

\section{Multiple inheritance}

\code{kindof} can be called with several base objects as arguments.  In
case, the object that \code{kindof} creates is a specialization of all
input objects-- that is, the new object inherits bindings from each of
objects.  This is useful when either:
\item The input objects are {\em disjoint}-- that is, if there is no
between the symbols bound by one such object, and those bound by any
other.  In
this case, the set of bindings inherited by the object is simply the
union of
all the input object's bindings.
 \item The input objects are all specializations of some common base
That is, each input object adds its own idosyncracies to the common base
object.  In this case, the new object is a combination of the
idiosyncracies of
the input objects, together with the common base object.  This is
more precisely below.

Consider an example of the second sort.  Here, we create a new class
\code{boundary-icon-with-trail}, that inherits from both
and \code{icon-with-trail} (which share the base object \code{icon}).
    (setq boundary-icon-with-trail (kindof boundary-icon
    (setq icon7 (kindof boundary-icon-with-trail)
    (ask icon7 (exist))            ;ICON7 is an instance of
    (ask icon7 (goto-xy 0 100))    ;ICON7 moves to 0,100, drawing a
    (ask icon7 (goto-xy 200 200)   ;Nothing happens, for 200,200 is out
of bounds.

To understand how these forms work, we need to be more explicit about
composition of objects.  Think of an object as a list of {\em binding
listed from {\em innermost} to {\em outermost}.  An object's own
reside in its innermost frame; its inherited bindings reside in the
frames, which the object shares with its base object(s).  When
\code{kindof} is
called with no arguments, the resulting object's list of frames has only
member: the freshly-created frame.  (\LISP's ordinary global
\OBL's ``global object'', can be thought of as having a frame containing
global variable and function bindings; this is implicitly the outermost
of {\em all} objects.) When \code{kindof} is called with just one
argument, the
new object's list of frames begins with a fresh frame that \code{kindof}
creates, followed by all the frames of the input object.

Now suppose \code{kindof} is called with several input objects.  Once
again, we
get a list of frames starting with the new object's own freshly-created
The other frames are gotten by, first, appending together the list of
 from each of the input objects (in the order in which the inputs were
second, eliminating any {\em duplicated} frames in the appended list,
only the {\em outermost} occurrence of each frame.  For example, just
these objects
\code{boundary-icon}: \mbox{[\code{boundary-icon}'s frame],}
 \mbox{[\code{icon}'s frame].}\\
\code{icon-with-trail}: \mbox{[\code{icon-with-trail}'s frame],}
 \mbox{[\code{icon}'s frame].}
were combined to form
\code{boundary-icon-with-trail} (before eliminating duplications):\\
\mbox{[\code{boundary-icon-with-trail}'s frame],}
\mbox{[\code{boundary-icon}'s frame],}
\mbox{[\code{icon}'s frame],}\\ \mbox{[\code{icon-with-trail}'s frame],}
\mbox{[\code{icon}'s frame].}\bigskip
after eliminating duplications:\\
\mbox{[\code{boundary-icon-with-trail}'s frame],}
\mbox{[\code{boundary-icon}'s frame],}\\
\mbox{[icon-with-trail's frame],} \mbox{[icons's frame].}

Note that after duplicates are eliminated, the inherited frames consist
of the
two specialized frames (from \code{boundary-icon} and
followed by the frame(s) (just one, in this case) from their common base
object, \code{icon}.  \code{icon7}, of course, looks like this:
\code{icon7}: \mbox{[\code{icon7}'s frame],}
 \mbox{[\code{boundary-icon-with-trail}'s frame],}
 \mbox{[\code{boundary-icon}'s frame],}\\
 \mbox{[\code{icon-with-trail}'s frame],} \mbox{[\code{icon}'s frame].}

Because the specialized frames are followed by the common inherited
the combined object behaves as though both specializations were made,
successively, to the common object.  When \code{icon7} is told to
\code{goto-xy}, the reference to \code{goto-xy} is resolved, as always,
finding the innermost frame in \code{icon7} that contains a binding of
function \code{goto-xy.} Therefore, \code{boundary-icon}'s definition is
This version of \code{goto-xy} first checks if its arguments are within
If not, no further action is taken-- in particular,
\code{shadowed-goto-xy} is
{\em not} called.  But if the coordinates are ok,
\code{shadowed-goto-xy} {\it
is} called.  This \code{shadowed-goto-xy} refers to the next-innermost
definition of \code{goto-xy} in \code{icon7}'s list of frames-- namely,
\code{icon-with-trail}'s definition.  \code{icon-with-trail}'s
draws the required trail, and also calls \code{shadowed-goto-xy}--
again to the next-innermost binding of \code{goto-xy}, in this case
\code{icon}'s.  \code{icon}'s \code{goto-xy} takes care of the basic
and redrawing of the icon's picture, and maintains the icon's
and \code{y-coord} variables.

Similarly, when \code{icon7} was told to \code{exist,}
\code{exist} function was invoked.  It called \code{shadowed-exist},
\code{icon}'s \code{exist}.  (Recall that \code{icon-with-trail} was
given its own definition of \code{exist}; it just inherits
Thus, the instance-variable creation (and other initializing actions) of
all} the objects that \code{boundary-icon-with-frame} was made from were
This underscores the need to define \code{exist} functions to call
\code{shadowed-exist}, so that combined objects get the

\section{Stylistic issues}

This section recommends certain stylistic practices for \OBL{}

\item Organize things into abstract functional units.

If there's some coherent task to perform-- like, ``move this icon to
then {\em define a function} to do the task.  This is always an
programming principle, but it is especially important for
programming.  In \OBL, one object's definition of some function (say,
\code{goto-xy}) can be shadowed by a specialized object, which
substitutes its
own definition.  This definition might, say, add some idiosyncracy to
function's task, or it might perform the same task by a different
than the shadowed version.  The more things you organize into distinct
functional units, the more things you can selectively shadow in

\item Don't bind the same symbol for {\em unrelated} purposes in

All function bindings of a given symbol should take the same arguments
fulfill the same general purpose.  It's {\em possible} to use the same
to name two completely unrelated functions in two different objects (if
always know which version of the function you want, and which kind of
you're talking to).  But this is a confusing practice.  You won't be
able to
tell, just by looking, which version of the function you're invoking
though you knew when you wrote the code).  And it won't be possible to
document the function (because such basic properties as the number of
might differ in different objects).

As always, use {\em packages} to prevent accidental duplication of the
name in different bodies of code.  In addition to the advantages of
and documentability, this may yield a runtime efficiency gain.

This principle applies to variables, too.  Don't bind the same variable
several different objects-- except, of course, for an instance variable,
serves the same purpose in each instance it appears in.  Even for an
variable, there should be only one class object that is responsible (via
\code{exist} function or a \code{definstancevar}) for creating that

Since avoiding duplication of object bindings is a matter of clarity and
efficiency (as opposed to being necessary for code to work at all), it
is ok to
be lax about it when writing small, informal, improvised programs.  But
systems should take the principle seriously.

\item Follow the principle of {\em data abstraction}: keep internal
implementation details from being accidentally accessed by users of the

Typically a class object has some set of functions that comprise the
interface to instances of that class.  That is, there are certain
that a user is expected to call inside that object (and perhaps certain
variables that the user is expected to refer to); these functions (and
variables) are the preferred interface.  Other functions and variables
supposed to be {\em internal} to the object-- these are referred to by
interface functions, but are not intended to be accessed {\em directly}
by the
user.  Typically, the internal functions and variables are ones that
cause the object to be put in an erroneous state, perhaps causing an
error to
be signalled; the interface routines are designed to guarantee
consistency of
the object's state, as long as those routines are the only ones that the
calls directly.

At the least, the documentation that goes with an object should say what
functions are part of the preferred interface; none of the object's
functions or variables should be referenced by the user.  As a further
precaution, you may wish to {\em enforce} this distinction; this, again,
is a
job for packages.  Simply create a package, and put all the code for an
in that package.  All function and variable symbols in that code will be
internal to the package, and thus inaccessible from outside, except for
explicitly declared {\em external}; these should be the designated
symbols.  (Of course, any user may, by appropriate maneuvering, access
internal symbols of a package; but users who do this know that they
proceed at
their own risk.)  Objects and packages can be orthogonal; there might be
several packages, each of which contains some code for each of several
Hence, what is accessible to whom can be finely tuned.

\item Don't overextend the object-oriented approach.

Object inheritance is appropriate when a number of entities form a
natural {it
specialization} hierarchy, one being a kind of another.  But object
specialization isn't the right way to relate the elements of other kinds
hierarchies-- for example, an inclusion hierarchy, where one entity is a
part of} another (eg, a hand is a part of an arm is a part of a body);
or a
ranking hierarchy (eg president, manager, worker), where one entity is a
subordinate of another.  A hand is not {\em a kind of} arm, and so a
object should not be defined to inherit the attributes of an arm object,
should arm inherit from body.  But hand and arm might be defined as
specializations of a general body-{\em part} object.


\subsection{Using \OBL}

\subsubsection{The \code{obj} package}

\OBL's symbols reside in the \code{obj} package.  Names of \OBL{}
and some other useful symbols, are external to the \code{obj} package.
access any of these symbols, either refer to \code{obj:{\em symbol}}, or
do a
\code{(use-package obj)} in the package from which you wish to make
The \code{user} package already uses the \code{obj} package.  The
symbols are:

    ask talkto kindof oneof make-obj remake-obj
    defobfun &key* defkind define-kind defclassvar definstancevar
    defclassvars definstancevars instancevar-defs undef-instancevar
    have unhave fhave unfhave
    ask-funcall mapc-ask mapcar-ask map-ask
    object? obj-equal current-obj exist shadowed-exist
    obj-let-globally obj-listener-loop obl
    obj-name class-name print-self
    base-objs inherited-objs
    what show show-all show-vals specializations
    own own? where there? mapc-own mapcar-own own
    fown fown? fwhere fthere? fdoc mapc-fown mapcar-fown



\code{obj-listener-loop} runs a special \OBL{} listener loop.  This is
necessary because, in the present implementation, references to object
only work properly when made textually within an \code{defobfun};
free references can only access global bindings (see \code{defobfun}).
\code{obj-listener-loop} \code{defobfun}s, and then funcalls, a dummy
for each toplevel expression you type, so that your expression can
object bindings.

If the current object is other than the global object-- if, for example,
in a break loop dynamically within a \code{ask}; of if, at toplevel,
executed a \code{talkto} for some object (see section
the \OBL{} listener loop identifies that object as part of the

\deff{obl \{\argd{form}\}*}{Macro}

\code{obl} is used to access object bindings from outside the textual
scope of
an \code{defobfun}.  \code{obl} defines (via \code{defobfun}) and
funcalls a
dummy function whose body consists of the \argd{form}s.

\subsection{Evaluating inside objects}

\deff{ask \argd{obj-form} \{\argd{form}\}*}{Macro}

\argd{obj-form} must evaluate to an object (or \code{nil}, to refer to
global object).  The \argd{form}s constitute the body of the \code{ask},
implicit progn that is evaluated inside the object that \argd{obj-form}
evaluates to.  That object is said to be the {\em current object} for
duration of the evaluation of the \argd{form}s (except, of course, when
\code{ask} is invoked during that evaluation, temporarily establishing
current object).

\deff{ask-funcall \argd{obj-form symbol} \{\argd{arg-form}\}*}{Macro}

\code{ask-funcall} is useful when you wish to invoke a function inside
object, but the arguments to the function need to be evaluated in the
object. \argd{obj-form} must evaluate to an object; \argd{symbol} must
be a
symbol.  \argd{arg-forms} are evaluated in the current object.  Then,
\argd{symbol} is \code{fsymeval}'ed inside the specified object, and the
resulting function is applied to the arguments inside the specified

A different technique for calling a function inside some object, but
with the
arguments evaluated in the current environment, is to lambda-bind some
variables to the values, then refer to those variables in the body of
\code{ask}.  This works because object scoping only captures free
See section \ref{obj-vs-lex}, Object Binding vs Lexical Binding.

\deff{mapc-ask \argd{objlist-form} \{\argd{form}\}*}{Macro}

\argd{objlist-form} must evaluate to a list of objects.  A \code{ask} is
to each in turn, using the \argd{form}s as the body.  The list of
objects is

\deff{mapcar-ask \argd{objlist-form} \{\argd{form}\}*}{Macro}

\argd{objlist-form} must evaluate to a list of objects.  A \code{ask} is
to each in turn, using the \argd{form}s as the body.  A list of the
values is returned.

\deff{talkto \&optional \argd{object}}{Function}

\argd{object} must be an object (or \code{nil}, to refer to the global
\code{object} becomes the current object.  \code{talkto} with no
argument (or
with \code{nil} as its argument) sets the current object to the global

\code{talkto} is to \code{ask} as \code{setq} is to special-variable

\code{talkto} should only be used interactively, at listener level.
\code{talkto} puts you inside an object, allowing you to get or set its
variables' values (or call its functions) just as though you were making
references.  The object listener loop's prompt indicates what the
object is, if it is other than the global object.

\subsection{Creating objects}

\deff{kindof \&rest \argd{objects}}{Function}

\code{kindof} creates and returns a new object.  The \argd{objects} must
be objects.  If no arguments are passed, \code{kindof} creates a bare
that inherits only from the global object.  If one argument is passed,
the new
object is a specialization of that object.  If several arguments are
the new object is a specialization of all the \argd{objects} (see

More precisely, \code{kindof} creates and returns an object whose
frames, innermost to outermost are: a new frame, which will contain the
object's own bindings; the frames of the first \argd{objects} argument;
frames of the next \argd{objects} argument; and so on.  (The arguments
all be objects.)  If any frame appears more than once, duplicate
are deleted, leaving only the outermost occurrence.  The global frame
(containing the ordinary \LISP{} global values and definitions for all
symbols) is implicitly the outermost frame of every object.  See
section~\ref{multiple-inherit} for elaboration.

\deff{make-obj \&rest \argd{objects}}{Function}

\code{make-obj} is a synonym of \code{kindof}.

\deff{remake-obj \argd{object} \&rest \argd{objects}}{Function}

\code{remake-obj} is used to alter an existing object's base objects.
\argd{object} is altered so that its base objects are \argd{objects},
all of
which must be objects.  The change propagates transitively to
of \argd{object}.  The new object has the same innermost binding frame
as the
original, so the original's own bindings are preserved.

Suppose there is a form in your file that says \code{(defvar obj3
obj2))}, followed by \code{defobfun}s of many functions for \code{obj3}.
you were to re-execute the \code{kindof}-- either with the same base
object, or
with different one(s)-- then the functions you had defined for the
previously bound to \code{obj3} would not be defined for the new object
to \code{obj3}.  And any specializations of the old \code{obj3} would
just be specializations of the old \code{obj3}, oblivious to any
in the new one.  Using \code{remake-obj} solves these problems.
\code{remake-obj} is called via \code{defkind}, which is described just

\deff{oneof \argd{class} \&rest \argd{keys}}{Function}

\code{oneof} is used to create a new object that is intended to be an
of {\em class}, which must be an object.  \code{oneof} creates a
{\em class}, then calls the function \code{exist} inside the new object.
keys} are passed as arguments to \code{exist}.  The new object is

\deff{exist \&rest \argd{keys} \&key* \argd{obj-name}}{Function}

The global \code{exist} function recognizes the keyword \code{obj-name};
that keyword is supplied, the current object is given a binding of
\code{obj-name} to the argument provided.  An object's binding of {\it
obj-name} helps control the object's printed representation (see
section~\ref{obj-prep}).  \code{exist} also creates bindings of instance
variables declared by \code{definstancevar}, documented in the following

\deff{defkind \argd{name} \{\argd{base-class-symbol}\}*}{Macro}

\code{defkind} is used to make an object intended to be a class object.
name} and \argd{base-class-symbol}s must be symbols; and each of the
\argd{base-class-symbol}s symbols must be bound to an object.
creates an object that is a specialization of the base class objects.
addition, \code{defkind} takes some auxiliary actions that are useful
for class

\item The global symbol \argd{name} is \code{defvar}'ed to be the new
\item Crucially, if \argd{name} is already bound to an object,
creates the new object via \code{remake-obj} (see just above),
preserving the
original object's bindings, and propagating the altered base objects to
extant specializations of the original object.  If \argd{name} is not
bound to
an object, \code{make-obj} is used instead.
\item \argd{name}'s source file is recorded.
\item The symbol \code{class-name} is bound to \argd{name} in the new
object; \code{class-name} helps control an object's printed
representation (see

\code{defkind} is for use at top level in a file (or from a listener);
should not be called from within a function.

% !!! cref examples next section

\subsection{Creating and deleting bindings}

\deff{have \argd{symbol} \&rest \argd{sym-val-pairs}}{Function}

\argd{sym-val-pairs} must be a list of alternating symbols and values.
each symbol, \code{have} gives the current object its own variable
binding of
the symbol to the corresponding value. (The last symbol's value may be
and defaults to \code{nil}.)

\deff{unhave \argd{symbol}}{Function}

\code{unhave} deletes the current object's own variable binding (if any)
of the
symbol {\em symbol}.

\deff{fhave \argd{symbol} \&rest \argd{sym-fcn-pairs}}{Function}

\argd{sym-val-pairs} must be a list of alternating symbols and
functions.  For
each symbol, \code{have} gives the current object its own function
binding of
the symbol to the corresponding function.  (The last symbol's function
may {\it
not} be omitted, since there is no reasonable default.)

\code{fhave} signals an error if \argd{symbol} is {\em unshadowable};
see the
end of section~\ref{reference-defobfun}.

\deff{unfhave \argd{symbol}}{Function}

Deletes the current object's own function binding (if any) of the symbol

\deff{defclassvar (\argd{class-sym classvar})

\code{defclassvar} makes a binding of the symbol \argd{classvar} for the
that is the value of the symbol \argd{class-sym}.  Its value is
initialized to
the value of \argd{init-form}, if that form is supplied, else
\argd{defclassvar} also declares \argd{classvar} to be a special
(which is appropriate because it will be freely-- ie nonlexically--
referenced), and records the source  where it was defined.

\deff{definstancevar (\argd{class-sym instancevar})

\code{definstancevar} is used to establish an instance variable, the
\argd{instancevar}, for all instances of the object that is the value of
symbol \code{class-sym}.  This is a little more complicated than
establishing a
class variable, since the instance objects which are to bind
haven't (necessarily) even been created yet.  \code{definstancevar}
the variable \argd{instancevar} (along with \argd{init-form}, if
supplied) with
the designated class object.  The global \code{exist} function finds all
variables for the base objects of the object being told to exist.  That
is given its own binding of each such variable, and (unless that binding
already existed) the associated \argd{init-form} is evaluated, providing
value to bind the variable to.  This is done from innermost to outermost
object; within a base object, the order is that in which the instance
were declared.
% !!! this shd really refer to inherited rather than base objs, but the
%     isn't defined yet.

Like \code{defclassvar}, \code{definstancevar} declares
special and records the source file of its definition.

% !!! ? instancevar-defs ?

\deff{undef-instancevar \argd{symbol object}}{Function}

\code{undef-instancevar} undoes the effect of any previous
\code{definstancevar} of the symbol \argd{symbol} for the object

\deff{defclassvars \argd{obj-sym} \{\argd{var-init}\}*}{Macro}

\code{defclassvars} is used to declare multiple class variables for the
object, the object which is the value of the symbol \argd{obj-sym}.
\argd{var-init} is either a symbol (which becomes a class varaible
to \code{nil}), or a list of two elements: the symbol to be bound, and
form which is evaluated to give its initial value.

\deff{definstancevars \argd{obj-sym} \{\argd{var-init}\}*}{Macro}

\code{definstancevars}is used to declare multiple instance variables for
same object.  \code{definstancevars} is to \code{definstancevar} as
\code{defclassvars} is to \code{defclassvar}.

% !!! example

\subsection{DEFOBFUN} \mbox{}

\deff{defobfun \argd{(function-name object-name) arglist}

\deff{defobfun \argd{function-name arglist} \{\argd{form}\}*}{Macro}

\code{defobfun}, like \code{defun}, defines a function with
\argd{arglist} as
its arglist and \argd{body} as its body.

\argd{function-name} and \argd{object-name} (if \argd{object-name} is
must be symbols; \argd{object-name} must evaluate to an object.  If
\argd{object-name} is supplied, the specified object is given its own
inding of \argd{function-name} to the defined function.  If
is not supplied, the function is defined globally (this is not quite the
as using \code{defun}, because of the following implementation quirk).

 \begin{quote} In the present implementation, object bindings are only
accessible for symbols referenced textually within an \code{defobfun}.
if you intend a global function to be called inside any object, and to
refer to
variables or functions bound in that object, you must define that global
function using \code{defobfun} rather than \code{defun.} If \code{defun}
used, only the global values and definitions of freely-referenced
symbols will
be accessed; object bindings will be circumvented.  This temporary
implementation restriction should {\em not} be used deliberately to
object bindings; \code{defun} should be used only for functions that are
expected never to refer to values or functions that are have object
To deliberately circumvent object bindings, use \code{(ask nil ...)}.

A related quirk is that \code{defobfun}, unlike \code{defun}, always
compiles} the function it defines.  This is because the lookup mechanism
object bindings works by intercepting free references in the compiler;
references to object bindings only work from compiled code.  This will
changed in a future release.

Textually within a \code{defobfun} of \argd{function-name}, calling
\code{shadowed-}\argd{function-name} invokes the shadowed version of
\argd{function-name}-- the version that would be referenced by the
\argd{function-name}, had not this very \code{defobfun} provided a
definition.  If no shadowed binding exists, calling
\code{shadowed-}\argd{function-name} just returns \code{nil}.

\code{defobfun} recognizes an extra lambda-list keyword, \code{\&key*}.
this variant of \code{\&key}, the default keyword symbol for each
argument is the same as the parameter symbol, rather than being a symbol
in the
keyword package.  Also, \code{\&allow-other-keys} is implicitly declared
\code{\&key*}.  Section~\ref{key-explanation} explains the rationale for

For reasons of efficiency, all symbols in the global package (part of
package system, not to be confused with the global object), as well as
symbols from certain internal system packages, are {\em unshadowable}--
cannot be shadowed by function bindings.  Hence, \code{defobfun} and
\code{fhave} signal an error if an attempt is made to function-bind such
symbol (except globally).  (If you are not familiar with the package
all this just means that you are not allowed to shadow the definitions
\LISP{} system primitives.)

\subsection{Inspecting objects}


\code{current-obj} returns the current object-- that is, returns the
object} argument from the dynamically-innermost \code{ask} (or last
\code{talkto}).  For example, \code{(ask \argd{obj} (current-obj))}
returns \argd{obj}.


Prints the printed representation of the current object.  This is always
to produce the printed representation of an object; hence, an object's
representation can be altered by giving the object an shadowing
definition of


What \code{print-self} prints is governed by the current object's
bindings of the symbols \code{obj-name} and \code{class-name}.  If the
has its own binding of \code{class-name}, then the printed
representation is
\code{\#<The generic \argd{class} \argd{id}>}, where \argd{class} is the
printed representation of the value of \code{class-name}, and \argd{id}
is a
unique internal number.  Otherwise, if the object has its own binding of
\code{obj-name}, then if it inherits a binding of \code{class-name,} the
printed representation is \code{\#<\argd{name}, a \argd{class}
\argd{id}>}.  If
the object has its own binding of \code{obj-name}, but no binding (own
inherited) of \code{class-name}, the printed representation is
\code{\#<\argd{name}, no class \argd{id}>}.  If the object does not have
own binding of \code{obj-name} or \code{class-name}, it prints as
\code{\#<Object \argd{id}>}.


For the following functions, the optional argument \argd{object}
defaults to
the current object; also, \code{nil} can be specified to refer to the

\deff{obj:what \&optional \argd{object}}{Function}

\code{what} prints the base object(s) from which \argd{object} was made.

\deff{obj:show \&optional \argd{object}}{Function}

\code{show} prints the values and functions for which \argd{object} has
own bindings.

\deff{obj:show-all \&optional \argd{object}}{Function}

\code{show-all} prints the values and functions for which \argd{object}
its own or inherited bindings (except for global bindings).

\deff{obj:show-vals \&optional \argd{object}}{Function}

\code{show-vals} prints the symbols for which \argd{object} has its own
variable bindings, together with their values.

\deff{obj:own \&optional \argd{object}}{Function}

\code{own} returns a list of all symbols for which \argd{object} has its
variable bindings.

\deff{obj:own? \argd{symbol} \&optional \argd{object}}{Function}

\code{own?} returns \code{t} or \code{nil} according to whether
has its own variable binding of the symbol \argd{symbol}.

\deff{obj:there? \argd{symbol} \&optional \argd{object}}{Function}

\code{there?} Returns \code{t} or \code{nil} according to whether
has a variable binding (its own or inherited) of the symbol

\deff{obj:where \argd{symbol} \&optional \argd{object}}{Function}

\code{where} returns the object (if any) from which {\em object}
inherits its
binding of the symbol \code{symbol} (or returns \argd{object} itself if
\argd{object} has its own variable binding of \argd{symbol}.)
\code{nil} is
returned if there is no such object, or if it is the global object.

\deff{obj:mapc-own \argd{function} \&optional \argd{object}}{Function}

\code{mapc-own} \code{mapc}'s \argd{function} over the symbols for which
\argd{object} has its own variable bindings.

\deff{obj:mapcar-own \argd{function} \&optional \argd{object}}{Function}

\code{mapcar-own} \code{mapcar}'s \argd{function} over the symbols for
\argd{object} has its own variable bindings.

\deff{obj:fown \&optional \argd{object}}{Function}

\code{fown} returns a list of all symbols for which \argd{object} has
its own
function bindings.

\deff{obj:fown? \argd{symbol} \&optional \argd{object}}{Function}

\code{fown?} returns \code{t} or \code{nil} according to whether
has its own function binding of the symbol \argd{symbol}.

\deff{obj:fthere? \argd{symbol} \&optional \argd{object}}{Function}

\code{fthere?} Returns \code{t} or \code{nil} according to whether
\argd{object} has a function binding (its own or inherited) of the

\deff{obj:fwhere \argd{symbol} \&optional \argd{object}}{Function}

\code{fwhere} returns a list of those objects, among \argd{object} and
objects that \argd{object} inherits from, that have their own function
for \argd{symbol}.  The list is from innermost (most-specialized) to
Note that \code{where} returns a single object, while \code{fwhere}
returns a
list of objects.  This is because only the single innermost binding of a
variable is accessible from an object; whereas, for a function, {\em
all} base
objects' bindings may be accessed if successive calls to the
versions are made.

\deff{obj:fdoc \argd{symbol} \&optional \argd{object}}{Function}

\code{fdoc} is used to locate any definition(s) of the symbol
\argd{symbol} in
the object \argd{object}. \code{fdoc} looks at \argd{object} itself, and
objects from which it inherits, and indicates which of those objects (if
have their own function bindings of \argd{symbol}.

\deff{obj:mapc-fown \argd{function} \&optional \argd{object}}{Function}

\code{mapc-fown} \code{mapc}'s \argd{function} over the symbols for
\argd{object} has its own function bindings.

\deff{obj:mapcar-fown \argd{function} \&optional

\code{mapcar-fown} \code{mapcar}'s \argd{function} over the symbols for
\argd{object} has its own function bindings.

\deff{base-objs \&optional \argd{object}}{Function}

\code{base-objs} returns a list of \argd{object}'s base objects.

\deff{inherited-objs \&optional \argd{object}}{Function}

\code{inherited-objs} returns a list of the objects that \argd{object}
 from.  These include not only \argd{object}'s base objects, but also
their} base objects, and so on.  More precisely, for each binding frame
\argd{object}, innermost to outermost, excluding \argd{object}'s own
frame, the
object whose own bindings are held in that frame appears (in that order)
in the
list returned by \code{inherited-objs}.

\deff{specializations \&optional \argd{object}}{Function}

\code{specializations} returns a list of the objects that inherit from
\argd{object} (unless \code{object} is \code{nil}, signifying the global
object, in which case \code{specializations} returns \code{nil}).

\deff{obj-equal \argd{object1 object2}}{Function}

\code{obj-equal} returns \code{t} or \code{nil} according to whether
\argd{object1} and \argd{object2} have the same binding frames (and in
the same
order) as one another.

\deff{object? \argd{thing}}{Function}

\code{object?} returns \code{t} or \code{nil} according to whether
is an \OBL{} object.


     ----- End Forwarded Messages -----