[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
- To: firstname.lastname@example.org
- Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
- From: Dan L. Pierson <pierson@multimax.ARPA>
- Date: Mon, 07 Dec 87 18:40:46 EST
References: DISASSEMBLE (p. 439), COMPILE (p. 439)
Edit history: Version 1 by Pierson 12/2/87
Status: For Internal Discussion
The definition of DISASSEMBLE says that "if the relevant function is
not a compiled function, it is first compiled.". The definition of
COMPILE says that "If name is a non-nil symbol, then the
compiled-function is installed as the global function definition of
the symbol...". Several implementations have taken this to mean that
if DISASSEMBLE is passed a symbol which has an uncompiled function
definition, then it has the side-effect of (COMPILE 'symbol).
Clarify that when DISASSEMBLE compiles a function, it will never
install the newly compiled function.
(DEFUN F (A) (1+ A))
(TYPEP (SYMBOL-FUNCTION 'F) 'COMPILED-FUNCTION)
This code will return NIL if this proposal is adopted. Some current
implementations will return T, some will return NIL.
Several current implementations of DISASSEMBLE have surprising side
effects, especially for new users.
Allegro CL, Symbolics, and Vax Lisp install the compiled definition.
Lucid and KCL don't install it. [[This is from an informal survey at
the last meeting; please correct any mistakes.]]
Cost to Implementors:
Some implementations will have to make a simple change.
Cost to Users:
Very little. DISASSEMBLE is really part of the environment and is
probably not called by much, if any user code.
Cost of non-Adoption:
DISASSEMBLE will continue to surprise less experienced users.
DISASSEMBLE will become the predictable debugging function it was
meant to be.
Those who thought DISASSEMBLE was supposed to install the compiled
function may find that the language has become a little cleaner.