[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue COMPILED-FUNCTION-REQUIREMENTS, version 1
- To: firstname.lastname@example.org
- Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 1
- From: email@example.com (Sandra J Loosemore)
- Date: Tue, 3 Jan 89 11:28:13 MST
This is a new issue.
References: CLtL p. 32, 76, 112, 143, 438-439
Issue FUNCTION-TYPE (passed)
Edit History: V1, 3 Jan 1989 Sandra Loosemore
There is confusion about what functions might be or must be of type
COMPILED-FUNCTION, and what attributes must be true of
COMPILED-FUNCTIONs. Is the distinction between COMPILED-FUNCTIONs and
other functions only one of representation, or can user programs infer
anything about COMPILED-FUNCTIONs? Are implementations required to
distinguish between compiled and non-compiled functions?
CLtL defines a COMPILED-FUNCTION as "a compiled code object". (Issue
FUNCTION-TYPE says only that COMPILED-FUNCTION must be a subtype of
FUNCTION.) Although it is not explicitly stated, CLtL implies that
compiled code must conform to certain rules; in particular, it states
that all macros are expanded at compile time, and specifies different
behavior for the COMPILER-LET and the EVAL-WHEN special forms
depending on whether they are interpreted or compiled.
The description of COMPILE in CLtL says that "a compiled-function object
[is] produced". It is not clear to everyone whether this implies that
COMPILED-FUNCTION-P must be true of such functions. CLtL says nothing
about whether functions defined in files compiled with COMPILE-FILE and
subsequently loaded must be of type COMPILED-FUNCTION.
(1) Clarify that if a function is of type COMPILED-FUNCTION, the
following are guaranteed about the function:
- All macro calls within the function have already been expanded
and will not be expanded again when the function is called.
(See CLtL p. 143.)
- Nested COMPILER-LETs will not bind any variables when the function
is called (CLtL p. 112).
- If the function contains nested EVAL-WHENs, only the LOAD (and not
the EVAL) situation is applicable.
- If the function contains nested LOAD-TIME-VALUE forms, these have
already been pre-evaluated and will not be evaluated again when
the function is called.
(2) Implementations are free to classify all functions as
COMPILED-FUNCTIONs, provided that all functions satisfy the criteria
listed in item (1). It is also permissible for interpreted FUNCTIONs
to satisfy the above criteria but not be distinguished as
(3) Clarify that COMPILE always produces an object of type
COMPILED-FUNCTION. Clarify that when functions are defined in a
file which is compiled with COMPILE-FILE, and the compiled file is
subsequently LOADed, objects of type COMPILED-FUNCTION result.
This proposal states what many people believe to be the minimum
functionality required of a compiler.
It appears that most implementations currently distinguish compiled
versus non-compiled functions on the basis of representation, but it
seems unlikely that any existing implementation would have problems
with the requirements in item (1).
A-Lisp uses the same representation for both compiled and interpreted
functions and currently labels them both as COMPILED-FUNCTION, but the
implementation of COMPILED-FUNCTION-P could be easily fixed to
distinguish "real" compiled functions.
Cost to implementors:
Unknown, but probably small.
Cost to users:
Probably minimal. Since the COMPILED-FUNCTION type specifier is
currently ill-defined, it is hard to imagine that existing programs
can portably rely on any interpretation of what it means that is
inconsistent with what is presented here.
The specification of what the compiler must do is made more explicit.
Loosemore notes that the FIXNUM type was also defined in CLtL solely
on the basis of a distinguished representation from other INTEGERs,
and that this definition has proved inadequate for just about all
portable usages of the type specifier. Defining COMPILED-FUNCTION
solely on the basis of distinguished representation seems like a bad