255 lines
17 KiB
HTML
255 lines
17 KiB
HTML
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>CLHS: Issue COMPILED-FUNCTION-REQUIREMENTS Writeup</TITLE>
|
|
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
|
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
|
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
|
<LINK REL=TOP HREF="../Front/index.htm">
|
|
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
|
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
|
<LINK REL=PREV HREF="../Issues/iss063_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss064.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss065_w.htm">
|
|
</HEAD>
|
|
<BODY>
|
|
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss063_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss064.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss065_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue COMPILED-FUNCTION-REQUIREMENTS Writeup</H2>
|
|
|
|
<PRE><B>Forum:</B> Compiler<P>
|
|
<B>Issue:</B> <A HREF="iss064.htm">COMPILED-FUNCTION-REQUIREMENTS</A><P>
|
|
<B>References:</B> CLtL p. 32, 76, 112, 143, 438-439<P>
|
|
Issue <A HREF="iss175_m.htm">FUNCTION-TYPE</A> (passed)<P>
|
|
Issue <A HREF="iss066.htm">COMPILER-LET-CONFUSION</A> (passed)<P>
|
|
Issue <A HREF="iss147.htm">EVAL-WHEN-NON-TOP-LEVEL</A> (passed)<P>
|
|
Issue <A HREF="iss216_m.htm">LOAD-TIME-EVAL</A> (passed)<P>
|
|
Issue COMPILE-ENVIRONMENT-CONSISTENCY<P>
|
|
Issue COMPILE-ARGUMENT-PROBLEMS (passed)<P>
|
|
<B>Category:</B> CLARIFICATION, CHANGE<P>
|
|
<B>Edit History:</B> V1, 3 Jan 1989 Sandra Loosemore<P>
|
|
V2, 10 Jan 1989, Sandra Loosemore (additional proposal)<P>
|
|
V3, 10 Feb 1989, Sandra Loosemore (new proposal)<P>
|
|
V4, 11 Mar 1989, Sandra Loosemore (fix wording to agree<P>
|
|
with other pending proposals)<P>
|
|
V5, 23 Mar 1989, Sandra Loosemore (restore proposal FLUSH)<P>
|
|
V6, 30 May 1989, Sandra Loosemore (fix proposal TIGHTEN to<P>
|
|
apply only to <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>)<P>
|
|
V7, 22 Jun 1989, Sandra Loosemore (restore FLUSH again)<P>
|
|
V8, 04 Jul 1989, Sandra Loosemore (amendments from meeting)<P>
|
|
<B>Status:</B> Proposal TIGHTEN passed, as amended, June 89<P>
|
|
<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
There is confusion about what functions might be or must be of type<P>
|
|
<A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A>, and what attributes must be true of<P>
|
|
COMPILED-FUNCTIONs. Is the distinction between COMPILED-FUNCTIONs and<P>
|
|
other functions only one of representation, or can user programs infer<P>
|
|
anything about COMPILED-FUNCTIONs? Are implementations required to<P>
|
|
distinguish between compiled and non-compiled functions?<P>
|
|
<P>
|
|
CLtL defines a <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A> as "a compiled code object". (Issue<P>
|
|
<A HREF="iss175_m.htm">FUNCTION-TYPE</A> says only that <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A> must be a subtype of<P>
|
|
<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>.) Although it is not explicitly stated, CLtL implies that<P>
|
|
compiled code must conform to certain rules; in particular, it states<P>
|
|
that all macros are expanded at compile time, and specifies different<P>
|
|
behavior for the COMPILER-LET and the <A REL=DEFINITION HREF="../Body/s_eval_w.htm#eval-when"><B>EVAL-WHEN</B></A> special forms<P>
|
|
depending on whether they are interpreted or compiled.<P>
|
|
<P>
|
|
The description of <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> in CLtL says that "a <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>compiled-function</B></A> object<P>
|
|
[is] produced". It is not clear to everyone whether this implies that<P>
|
|
<A REL=DEFINITION HREF="../Body/f_cmpd_f.htm#compiled-function-p"><B>COMPILED-FUNCTION-P</B></A> must be true of such functions. CLtL says nothing<P>
|
|
about whether functions defined in files compiled with <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> and<P>
|
|
subsequently loaded must be of type <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A>.<P>
|
|
<P>
|
|
There are two proposals, FLUSH and TIGHTEN.<P>
|
|
<P>
|
|
Proposal TIGHTEN presents a simple model of the compilation process. A<P>
|
|
minimal compiler could be implemented to perform a code walk to apply<P>
|
|
the indicated transformations to the function source code. Of course,<P>
|
|
most compilers will perform other transformations as well, such as<P>
|
|
translating the Lisp source code into a representation that is more<P>
|
|
compact or which can be executed more efficiently.<P>
|
|
<P>
|
|
<B>Proposal COMPILED-FUNCTION-REQUIREMENTS:FLUSH:<P>
|
|
</B><P>
|
|
(1) Remove the type specifier <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A> and the predicate<P>
|
|
<A REL=DEFINITION HREF="../Body/f_cmpd_f.htm#compiled-function-p"><B>COMPILED-FUNCTION-P</B></A> from the language.<P>
|
|
<P>
|
|
(2) Remove the language from proposal COMPILE-ARGUMENT-PROBLEMS:CLARIFY<P>
|
|
that says "it is an error" to try to <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> a function that<P>
|
|
was defined interpretively in a non-null lexical environment.<P>
|
|
Instead, state that if <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> cannot compile the function,<P>
|
|
it should simply behave as an identity operation.<P>
|
|
<P>
|
|
Rationale:<P>
|
|
<P>
|
|
Some people think the wording of proposal TIGHTEN is too vague and<P>
|
|
does not <A REL=DEFINITION HREF="../Body/f_provid.htm#provide"><B>provide</B></A> an adequate definition of what COMPILED-FUNCTIONs<P>
|
|
are. Some people think that since proposal TIGHTEN does not <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A><P>
|
|
<A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> to produce a <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A>, its specification is too <P>
|
|
weak to be of much use to users.<P>
|
|
<P>
|
|
Since we are unable to reach concensus on what a <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A><P>
|
|
really is, or how to construct one, it seems better to remove it<P>
|
|
from the language entirely.<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal COMPILED-FUNCTION-REQUIREMENTS:TIGHTEN:<P>
|
|
</B><P>
|
|
(1) Clarify that if a function is of type <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A>, the<P>
|
|
following are guaranteed about the function:<P>
|
|
<P>
|
|
- All macro calls appearing lexically within the function have <P>
|
|
already been expanded and will not be expanded again when the<P>
|
|
function is called. (See CLtL p. 143.) The process of<P>
|
|
compilation effectively turns <A REL=DEFINITION HREF="../Body/s_flet_.htm#macrolet"><B>MACROLET</B></A> and <A REL=DEFINITION HREF="../Body/s_symbol.htm#symbol-macrolet"><B>SYMBOL-MACROLET</B></A><P>
|
|
constructs into PROGNs with all instances of the local macros<P>
|
|
in the body fully expanded.<P>
|
|
<P>
|
|
- If the function contains lexically nested <A REL=DEFINITION HREF="../Body/s_ld_tim.htm#load-time-value"><B>LOAD-TIME-VALUE</B></A> forms,<P>
|
|
these have already been pre-evaluated and will not be evaluated<P>
|
|
again when the function is called.<P>
|
|
<P>
|
|
(2) Implementations are free to classify all functions as <P>
|
|
COMPILED-FUNCTIONs, provided that all functions satisfy the criteria<P>
|
|
listed in item (1). It is also permissible for functions that are<P>
|
|
not COMPILED-FUNCTIONs to satisfy the above criteria.<P>
|
|
<P>
|
|
(3) Clarify when functions are defined in a file which is compiled<P>
|
|
with <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A>, and the compiled file is subsequently LOADed,<P>
|
|
objects of type <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A> result.<P>
|
|
<P>
|
|
(4) Clarify that <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> must produce an object of type<P>
|
|
<A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A>.<P>
|
|
<P>
|
|
<P>
|
|
Rationale:<P>
|
|
<P>
|
|
This proposal allows users to count on both <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> and <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> <P>
|
|
always producing objects that are <A REL=DEFINITION HREF="../Body/f_cmpd_f.htm#compiled-function-p"><B>COMPILED-FUNCTION-P</B></A>.<P>
|
|
<P>
|
|
Some specific properties are assigned to compiled functions. Users<P>
|
|
would be able to rely on any function which is of type<P>
|
|
<A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A> having really been (at least partially) compiled.<P>
|
|
<P>
|
|
It also states what many people believe to be the minimum functionality <P>
|
|
required of a compiler.<P>
|
|
<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B> <P>
|
|
It appears that most implementations currently distinguish compiled<P>
|
|
versus non-compiled functions on the basis of representation. It seems<P>
|
|
unlikely that any implementation would have problems satisfying the<P>
|
|
stated minimum requirements for compilation.<P>
|
|
<P>
|
|
Lucid uses the same representation for both compiled and non-compiled<P>
|
|
functions, except there is a bit in the header used to distinguish them.<P>
|
|
<P>
|
|
A-Lisp uses the same representation for both compiled and interpreted<P>
|
|
functions and currently labels them both as <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A>, but the<P>
|
|
implementation of <A REL=DEFINITION HREF="../Body/f_cmpd_f.htm#compiled-function-p"><B>COMPILED-FUNCTION-P</B></A> could be easily fixed to<P>
|
|
distinguish "real" compiled functions.<P>
|
|
<P>
|
|
On the TI Explorer, the <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> function can return an object of<P>
|
|
either type <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A> or LEXICAL-CLOSURE, where the latter<P>
|
|
consists of two components -- an environment and a <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A>.<P>
|
|
There is confusion about whether microcoded functions should be<P>
|
|
considered compiled or not.<P>
|
|
<P>
|
|
In Utah Common Lisp, <A REL=DEFINITION HREF="../Body/f_cmpd_f.htm#compiled-function-p"><B>COMPILED-FUNCTION-P</B></A> currently returns true of all<P>
|
|
function objects, but there is an internal tag field in the object<P>
|
|
which allows real compiled functions to be distinguished from<P>
|
|
interpreted functions.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to implementors:<P>
|
|
</B><P>
|
|
Unknown, but probably not too great. Many implementations will<P>
|
|
probably have to make some minor changes to representation of<P>
|
|
functions and/or to the definition of <A REL=DEFINITION HREF="../Body/f_cmpd_f.htm#compiled-function-p"><B>COMPILED-FUNCTION-P</B></A>, but<P>
|
|
probably most of those changes are necessary to support the<P>
|
|
<A HREF="iss175_m.htm">FUNCTION-TYPE</A> proposal anyway.<P>
|
|
<P>
|
|
<P>
|
|
<B>Cost to users:<P>
|
|
</B><P>
|
|
Probably minimal. Since the <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A> type specifier is<P>
|
|
currently ill-defined, it is hard to imagine that existing programs<P>
|
|
can portably rely on any interpretation of what it means that is<P>
|
|
inconsistent with what is presented here.<P>
|
|
<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
The specification of what the compiler must do is made more explicit.<P>
|
|
<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
This writeup originally contained an additional proposal,<P>
|
|
TIGHTEN-COMPILE. A straw vote at the March 1989 meeting indicated<P>
|
|
that an earlier version of proposal TIGHTEN had the most support.<P>
|
|
However, a number of people still have a strong preference for<P>
|
|
proposal FLUSH. <P>
|
|
<P>
|
|
Recent mail on the cl-compiler list has indicated that Moon, Loosemore<P>
|
|
and MacLachlan favor flushing COMPILED-FUNCTION; White and Burke have<P>
|
|
no objection to doing so; and that Pitman would like to see the type<P>
|
|
retained with both <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> and <A REL=DEFINITION HREF="../Body/f_cmp_fi.htm#compile-file"><B>COMPILE-FILE</B></A> required to produce<P>
|
|
compiled functions. Nobody has explicitly stated a preference for<P>
|
|
proposal TIGHTEN in this round of discussion.<P>
|
|
<P>
|
|
Loosemore would also prefer to see the type retained, but thinks that<P>
|
|
since we have been unable to reach a consensus on what the<P>
|
|
<A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>compiled-function</B></A> type means or how to construct an object of this<P>
|
|
type, we are much better off not saying anything about it at all in<P>
|
|
the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A>, than standardizing a definition that is too vague to<P>
|
|
be of any use to users, or that some people believe is wrong.<P>
|
|
<P>
|
|
The <A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>FIXNUM</B></A> and <A REL=DEFINITION HREF="../Body/t_bignum.htm#bignum"><B>BIGNUM</B></A> types were also defined in CLtL solely on the<P>
|
|
basis of distinguished representations, and that this definition has<P>
|
|
proved inadequate for just about all portable usages of these type<P>
|
|
specifiers. Defining <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A> solely on the basis of<P>
|
|
distinguished representation seems like a bad idea.<P>
|
|
<P>
|
|
David Gray notes:<P>
|
|
We make good use of the type <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A> in our implementation,<P>
|
|
but all of the accessor functions for objects of that type are<P>
|
|
non-standard, which makes me wonder if it might be best to just remove<P>
|
|
this type from the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> along with <A REL=DEFINITION HREF="../Body/t_bignum.htm#bignum"><B>BIGNUM</B></A>.<P>
|
|
<P>
|
|
One use of the <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A> type is in declarations. A-Lisp and<P>
|
|
Lucid, for example, can compile <A REL=DEFINITION HREF="../Body/f_funcal.htm#funcall"><B>FUNCALL</B></A> more efficiently if it can be<P>
|
|
determined that the function is of type <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A>. However,<P>
|
|
in order for such declarations to be really useful, there should be a<P>
|
|
way to construct an object which is guaranteed to be of type<P>
|
|
<A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A>.<P>
|
|
<P>
|
|
Moon says:<P>
|
|
I much prefer the option FLUSH...<P>
|
|
This type has no portable meaning and never should have existed.<P>
|
|
<P>
|
|
Pierson says:<P>
|
|
What I (and believe Kent) want is a guarantee that [COMPILE] won't<P>
|
|
signal an error; if nothing else works <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> will simply apply<P>
|
|
#'<A REL=DEFINITION HREF="../Body/f_identi.htm#identity"><B>IDENTITY</B></A> to the symbol's function. Specifically, it should be<P>
|
|
legal and safe to attempt to speed up my current program(s) by<P>
|
|
doing:<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_do_sym.htm#do-symbols"><B>DO-SYMBOLS</B></A> (SYM <my-package>)<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_when_.htm#when"><B>WHEN</B></A> (<A REL=DEFINITION HREF="../Body/f_fbound.htm#fboundp"><B>FBOUNDP</B></A> SYM) (<A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> SYM)))<P>
|
|
</PRE>
|
|
<HR>
|
|
|
|
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
|
|
|
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
|
</BODY>
|
|
</HTML>
|