[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FUNCTION-TYPE:STRICT-REDEFINITION proposal
- To: Masinter.pa@xerox.com
- Subject: FUNCTION-TYPE:STRICT-REDEFINITION proposal
- From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
- Date: Wed, 24 Feb 88 10:09:26 PST
- Cc: sandra%orion@cs.utah.edu, cl-cleanup@sail.stanford.edu
- In-reply-to: Masinter.pa@Xerox.COM's message of 19 Feb 88 14:17 PST <880219-141733-9723@Xerox>
re: I intended not to require that it not be a "proper" subtype in the
sense that there may be no data items that are FUNCTIONP but not
COMPILED-FUNCTIONP.
Lucid Common Lisp distinguishes "compiled" closures which exist for the
purpose of supporting entry into the interpreter from functions which are
truly compiled. It only takes a bit in a header word. If an implementation
really doesn't support an interpreter, then having every function be
COMPILED-FUNCTIONP doesn't sound like much of a loss.
But most implementations in fact do support an interpreter -- which
typically runs code at anywhere from 30 to 600 times slower than when
compiled. Thus it seems reasonable to require COMPILED-FUNCTIONP in
those implementations to be false on, say,
(eval '#'(lambda (x) (list x)))
no matter what underlying technique is used to support interpreter closures.
-- JonL --