[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Redefining Common LISP Functions, MACROS and Special Forms
- To: firstname.lastname@example.org, sears%wrs.DEC@decwrl.DEC.COM
- Subject: Re: Redefining Common LISP Functions, MACROS and Special Forms
- From: sears%wrs.DEC@decwrl.DEC.COM
- Date: Mon, 13 Apr 1987 13:57:00 -0000
I think this is a deep issue in the language. This is especially
true for those applications that are evolving systems starting from
COMMON-LISP as a base. I think the questions are:
1. What is the protocol for adding an extension for an
2. What is the protocol for adding an extension that is compiled.
3. How are "META" functions, such as SETF and DEFSTRUCT,
to be handled.
4. Are some functions to be handled differently than others?
(Forms like OR and MULTIPLE-VALUE-RETURN).
In the case of (1), changing the function cell seems to be adequate.
In the case of (2), the compiler needs to know which definition is
intended. Using a new symbol solves this problem.
The problem in the case of (3) is that a redefined function may imply
(or not) a change to SETF. DEFSETF is the function that does this, but
it in turn is affected by compilation. A related problem is the handling
of DEFSTRUCT accessor, creator and setting functions.
In the case of (4), it may well be the case that the language can
be defined as consisting of layers, but this should be specified explicitly
if this is to be the case.
I think the exact handling of these features needs to be defined in
a way that gives the system builder explicit control.