[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The compilation ordering imposed by SETF methods
- To: firstname.lastname@example.org
- Subject: Re: The compilation ordering imposed by SETF methods
- From: Gregor.pa@Xerox.COM
- Date: Sun, 28 May 89 14:03 PDT
- Cc: commonloops.pa@Xerox.COM
- Fcc: BD:>Gregor>mail>outgoing-mail-6.text.newest
- In-reply-to: The message of 28 May 89 10:53 PDT from email@example.com
- Line-fold: no
- Reply-to: <Gregor.pa@Xerox.COM>
This message is important to all users of PCL.
Date: Sun, 28 May 89 12:53 CDT
That is, a call to a function not yet defined
produces at most a warning; a use of a macro not yet defined
produces incorrect code (a call to a function instead of a use of
the macro). Thus, in a many-person (e.g., department-size)
project, macros as interfaces can lead to troublesome
The interface to a CLOS class is made up primarily of functions:
everything from MAKE-INSTANCE to applicable methods to slot
readers. One exception, however, is SETF methods (including the
SETF method created through use of the :ACCESSOR slot option).
Because SETF is a macro, most Lisp systems refuse to compile a use of
SETF unless a corresponding setf-method has already been defined.
Such a restriction forces a compilation ordering on the caller and
called methods. The only resolution of the interdependency seems
to be to create a "global header file" of DEFGENERICs like
(defgeneric (setf the-slot) (right-hand-side self))
Actually, a CLOS inspired change to Common Lisp was made precisely to
solve this problem. Unfortunately, it is difficult to implement this
change in PCL.
Common Lisp has been changed to give SETF a `well known', default
expansion. When expanding a SETF macro, such as:
(setf (<foo> object) new)
if there is no declared setf method for the function <foo>, the setf
form expands as follows:
(funcall #'(setf <foo>) new object)
because of this general rule, it is possible to compile SETF forms
without preloading a mess of defsetf forms. The definition of the
actual setf function, #'(setf <foo>), can come later just like the
definition of other functions.
Note: As you can see, this change also introduced a mechanism for using
lists to name functions (i.e. lists whose car is the symbol SETF), but
that isn't really relevant.
Note: (Author's personal opinion) If you never, ever use defsetf or any
of its friends, this change makes SETF what it should have been all
along, a naming convention for setters. It gets rid of most of its
troublesome macro behavior.
The problem is that there isn't really a portable way to implement this.
For one thing, I can't add non-symbol function names portably. For
another, it is difficult to patch SETF portably. So, in the meatime, in
PCL you must take special, advance action to be able to expand calls to
setf in this new, default way. To make this easier, PCL provides the
macro DO-STANDARD-DEFSETF. You can put calls to this macro in a header
file, and then program normally. PCL also tries to help by doing one of
these standard defsetfs whenever it sees the name of an accessor, writer
or a defmethod with (setf <foo>). When you get a Common Lisp that
really has this change made to it you can delete the header file and PCL
will be able to stop doing them internally.
In fact, is there an ANSI Common Lisp mailing list? I'd like to keep
up to date on any plans for modifications to Common Lisp.
Send a message to RPG@Sail.Stanford.edu to ask to be added to the
Common-Lisp or X3J13 mailing lists.