[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: sandra%defun@CS.Utah.EDU
- Subject: issue COMPILE-ARGUMENT-PROBLEMS
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 2 Jan 89 23:49 EST
- Cc: CL-Compiler@SAIL.STANFORD.EDU
- In-reply-to: <8808081611.AA01749@defun.utah.edu>
I took the liberty of writing a version of this based around the
comments I made following your last proposal. The Proposal part
is very different, but I think it is "doable" in most implementations.
Personally, I think this proposal will be a lot more useful in
practice. I hope others will agree.
References: CLtL p. 438-439
Category: CLARIFICATION, CHANGE
Edit History: 08-Aug-88, Version 1 by Sandra Loosemore
02-Jan-89, Version 2 by Pitman
The description of what arguments can legitimately be passed to the
function COMPILE in CLtL is too vague. There are two specific
(1) Acceptance of the FUNCTION-TYPE proposal makes it nonsensical to
speak of a lambda-expression being an interpreted function (it is not)
or to require a symbol to have a lambda-expression as its definition
(the SYMBOL-FUNCTION must be a true FUNCTION object).
(2) Many implementations cannot correctly compile functions that are
defined interpretively in a non-null lexical environment, because the
compiler and interpreter use different representations for closures.
Although this problem arose in conjunction with the
DEFINING-MACROS-NON-TOP-LEVEL proposal, the situation can also arise
if SETF is used to store a lexical closure in the SYMBOL-FUNCTION of
(3) Compiled-only implementations are caught in a bind because the
one-argument case as described in CLtL can never not signal an error:
the contents of the function cell are always compiled.
Change the description of COMPILE to say that the function to be
compiled may be either a lambda expression (as permitted by CLtL)
or a function (as described by the FUNCTION-TYPE proposal). If the
definition is a lambda expression, it is coerced to a function.
If the definition to be compiled is already compiled, the implementation
is permitted to treat the compilation step as an identity. In any case,
the implementation must not signal an error.
If the definition to be compiled is a function which was enclosed in
a non-null lexical environment and the compiler cannot compile the
function, the compiler is permitted to treat the compilation step
as an identity.
If the definition to be compiled is a macro or special form definition,
the compiler is permitted to treat the compilation step as an identity.
If an implementation is interpreted-only, the compiler is permitted
to treat the compilation step as an identity.
The intent is that the COMPILE function should signal an error only if
it receives an argument which is not the name or definition of a valid
function, macro, or special form.
The intent is that COMPILE should be a permissible way to attempt to
`speed up' any operator definition. Implementations are encouraged to
implementation useful facilities toward this end. However, if a
definition cannot be `sped up' for some reason (for example, the
definition is already compiled, or there is some limitation of the
compiler), the original definition should be used where feasible.
For example, it should in general be permissible to do:
(DO-SYMBOLS (SYMBOL package)
(IF (FBOUNDP SYMBOL) (COMPILE SYMBOL)))
to `speed up' the functions in some PACKAGE.
This provides a consistent interpretation of COMPILE which is useful
in portable code in interpreted-only, compiled-only, or hybrid
The definition is flexible enough to permit implementations to skip
compilation in situations where the implementor deems it unreasonable.
Implementations that do not allow sharing of lexical environments
between compiled and interpreted functions include VaxLisp, Allegro
CL, and Lucid.
Lucid and Symbolics already accept an interpreted function object
as the "definition" argument to COMPILE.
Symbolics Genera signals an error if you try to compile an
Cost to implementors:
Very small. This is really just a change in the COMPILE function
interface, not in the compiler itself.
Cost to users:
None. Some cases which used to signal an error will no longer signal
This definition makes for a more useful interpretation of the
one-argument case of COMPILE in compiled-only implementations.
Uses of COMPILE will be more portable.
Cost of Non-Adoption:
The definition of COMPILE will be a real mess.
Pitman supports this proposal.