Issue: COMPILE-ARGUMENT-PROBLEMS-AGAINReferences: COMPILE-ARGUMENT-PROBLEMS, draft 10.156 p.3-52
Category: CHANGE
Edit History: 9-Dec-91, Version 1, by Moon
Status: Passed 10-Dec-91; 11-0 on part 1, 9-1-1 on part 2
Problem Description:
Cleanup COMPILE-ARGUMENT-PROBLEMS:CLARIFY created a couple of problems:
(1) It says "The consequences of calling COMPILE on a function that is already
compiled are unspecified" but the spec doesn't provide any way to create a
function that is guaranteed not to be compiled already. In fact the example
at the top of page 3-52 is invalid because of this.
(2) It says the consequences are undefined "if the function to be compiled was
defined interpretively in a non-null lexical environment", but a non-null
lexical environment doesn't imply a closure. It might just have declarations in
it. The original motivation was "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."
Proposal (COMPILE-ARGUMENT-PROBLEMS-AGAIN:FIX):
(1) Remove the quoted text and specify that COMPILE either returns the function
it is given or returns an equivalent function, but in any case returns a
(2) Replace the quoted text with "if the lexical environment surrounding the
function to be compiled contains any bindings other than macros, symbol macros,
or declarations".
Rationale:
(1) Given a function that is already compiled, COMPILE can simply return it.
(2) Bindings that minimal compilation would remove shouldn't prevent COMPILE
from working, since no closure would be required.
Cost to implementors:
(1) Trivial.
(2) Might require some work, depending on what the interpreter does with
macros in the lexical environment of an interpreted function.
Cost to users:
None. This is an upward-compatible change.
Benefits:
(1) Users don't have to insert extra COMPILED-FUNCTION-P checks.
(2) Make the language less restrictive.
Discussion:
Parts 1 and 2 should be voted separately.