303 lines
23 KiB
HTML
303 lines
23 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 FUNCTION-TYPE 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/iss178_w.htm">
|
||
|
|
<LINK REL=UP HREF="../Issues/iss175_m.htm">
|
||
|
|
<LINK REL=NEXT HREF="../Issues/iss180_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/iss178_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss175_m.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss180_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
||
|
|
|
||
|
|
<HR>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<H2>Issue FUNCTION-TYPE Writeup</H2>
|
||
|
|
|
||
|
|
<PRE><B>Issue:</B> <A HREF="iss175_m.htm">FUNCTION-TYPE</A><P>
|
||
|
|
<B>References:</B> functions (p32), types (p33), <A REL=DEFINITION HREF="../Body/f_fnp.htm#functionp"><B>FUNCTIONP</B></A> (p76),<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A> (p90), <A REL=DEFINITION HREF="../Body/f_apply.htm#apply"><B>APPLY</B></A> (p107), <A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> (pp51-52)<P>
|
||
|
|
<B>Category:</B> CHANGE<P>
|
||
|
|
<B>Edit History:</B> 26-Feb-87, Version 1 by Gabriel<P>
|
||
|
|
15-Mar-87, Version 2 by Cleanup Committee<P>
|
||
|
|
10-May-87, Version 3 by Fahlman<P>
|
||
|
|
29-May-87, Version 4 by Masinter (incorporate comments)<P>
|
||
|
|
15-Jun-87, Version 5 by Fahlman (include two options)<P>
|
||
|
|
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)<P>
|
||
|
|
09-Nov-87, Version 7 by Masinter (minor cleanup)<P>
|
||
|
|
14-Nov-87, Version 8 by Pitman (major restructuring)<P>
|
||
|
|
13-Feb-88, Version 9 by Masinter, (add back 2nd option)<P>
|
||
|
|
19-May-88, Version 10 by Masinter, (modify as per X3J13)<P>
|
||
|
|
24-May-88, Version 11 by van Roggen<P>
|
||
|
|
(don't <A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>coerce</B></A> lists, relax <A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A> reqs)<P>
|
||
|
|
4-Sep-88, Version 12 by Masinter<P>
|
||
|
|
(incorporate amendments adopted at June 88 X3J13)<P>
|
||
|
|
<P>
|
||
|
|
<B>Problem Description:<P>
|
||
|
|
</B><P>
|
||
|
|
The definition of the term ``function'' in CLtL includes all symbols and<P>
|
||
|
|
many lists in addition to `true' functions.<P>
|
||
|
|
<P>
|
||
|
|
Also, page 47 of CLtL states that the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> type specifier can only<P>
|
||
|
|
be used for declaration and not for discrimination. Some of the original<P>
|
||
|
|
Common Lisp designers maintain that this restriction on the use of the<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> specifier was meant to apply only to long-form <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A><P>
|
||
|
|
specifiers, but since this intent was not explicitly stated, the status<P>
|
||
|
|
of <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> as a type is blurred. <P>
|
||
|
|
<P>
|
||
|
|
A consequence of the p47 confusion is that (<A REL=DEFINITION HREF="../Body/f_fnp.htm#functionp"><B>FUNCTIONP</B></A> x) cannot portably<P>
|
||
|
|
be relied upon to be equivalent to (<A REL=DEFINITION HREF="../Body/f_typep.htm#typep"><B>TYPEP</B></A> x '<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>).<P>
|
||
|
|
<P>
|
||
|
|
Proposal <A HREF="iss175_m.htm">FUNCTION-TYPE:X3J13-MARCH-88</A><P>
|
||
|
|
<P>
|
||
|
|
This proposal is basically the STRICT-REDEFINITION proposal of version 9<P>
|
||
|
|
of this issue, correcting a few typos, changing section 2E as<P>
|
||
|
|
agreed upon at X3J13 March 1988, allowing symbols but not lists to<P>
|
||
|
|
be FUNCALLed or APPLYed, and relaxing some SYMBOL-FUNCTION/FBOUNDP<P>
|
||
|
|
requirements.<P>
|
||
|
|
<P>
|
||
|
|
1. Redefine the type <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> so that it can be used for discrimination<P>
|
||
|
|
as well as declaration.<P>
|
||
|
|
<P>
|
||
|
|
1a. The types <A REL=DEFINITION HREF="../Body/a_cons.htm#cons"><B>CONS</B></A>, <A REL=DEFINITION HREF="../Body/t_symbol.htm#symbol"><B>SYMBOL</B></A>, <A REL=DEFINITION HREF="../Body/t_array.htm#array"><B>ARRAY</B></A>, <A REL=DEFINITION HREF="../Body/t_number.htm#number"><B>NUMBER</B></A>, <A REL=DEFINITION HREF="../Body/a_ch.htm#character"><B>CHARACTER</B></A>, and <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A><P>
|
||
|
|
are pairwise disjoint. In particular, a list may not be used<P>
|
||
|
|
to implement any <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> subtype.<P>
|
||
|
|
<P>
|
||
|
|
1b. Define that the type <A REL=DEFINITION HREF="../Body/t_cmpd_f.htm#compiled-function"><B>COMPILED-FUNCTION</B></A> is a subtype of <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>.<P>
|
||
|
|
Implementations are free to define other subtypes of <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>.<P>
|
||
|
|
<P>
|
||
|
|
2. Define that a ``function'' as used throughout the CLtL is restricted<P>
|
||
|
|
to be exactly those objects of type <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>.<P>
|
||
|
|
<P>
|
||
|
|
2a. This type no longer includes objects of type <A REL=DEFINITION HREF="../Body/t_symbol.htm#symbol"><B>SYMBOL</B></A> or lists<P>
|
||
|
|
whose <A REL=DEFINITION HREF="../Body/f_car_c.htm#car"><B>CAR</B></A> is <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A>.<P>
|
||
|
|
<P>
|
||
|
|
2b. The behavior of <A REL=DEFINITION HREF="../Body/f_fnp.htm#functionp"><B>FUNCTIONP</B></A> is defined to be exactly equivalent to<P>
|
||
|
|
#'(<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> (X) (<A REL=DEFINITION HREF="../Body/f_typep.htm#typep"><B>TYPEP</B></A> X '<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>)). This is an incompatible<P>
|
||
|
|
change.<P>
|
||
|
|
<P>
|
||
|
|
2c. Clarify that the list form of the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> type specifier may<P>
|
||
|
|
still only be used for declaration.<P>
|
||
|
|
<P>
|
||
|
|
2d. Clarify that the symbol form of the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> type specifier may<P>
|
||
|
|
be used for type discrimination.<P>
|
||
|
|
<P>
|
||
|
|
2e. <A REL=DEFINITION HREF="../Body/f_funcal.htm#funcall"><B>FUNCALL</B></A> and <A REL=DEFINITION HREF="../Body/f_apply.htm#apply"><B>APPLY</B></A> and all Common Lisp functions that<P>
|
||
|
|
take function arguments to also take a symbol, which will<P>
|
||
|
|
be coerced to a function as if by <A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A>.<P>
|
||
|
|
<P>
|
||
|
|
2f. This is an incompatible change in that it is an error to pass<P>
|
||
|
|
anything other than a function or symbol as the functional<P>
|
||
|
|
argument.<P>
|
||
|
|
<P>
|
||
|
|
3. Clarify that the result of a <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> special form must be a function.<P>
|
||
|
|
<P>
|
||
|
|
3a. This implies that some (<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> name) may be implicitly interpreted<P>
|
||
|
|
as (<A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>THE</B></A> <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> (<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> name)). <P>
|
||
|
|
<P>
|
||
|
|
4. Clarify that it is an error to use the special form <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> on a<P>
|
||
|
|
symbol that does not denote a function in the lexical environment in<P>
|
||
|
|
which the special form appears. Specifically, it is an error to use the<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> special form on a symbol that denotes a macro or special form.<P>
|
||
|
|
<P>
|
||
|
|
4a. Some implementations may choose not to signal this error for<P>
|
||
|
|
performance reasons, but implementations are forbidden from<P>
|
||
|
|
defining the failure to signal an error as a `useful' behavior.<P>
|
||
|
|
<P>
|
||
|
|
5. Clarify that <A REL=DEFINITION HREF="../Body/f_fbound.htm#fboundp"><B>FBOUNDP</B></A> must return true for a symbol naming a macro or<P>
|
||
|
|
a special form, and that it is permissible to call <A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A><P>
|
||
|
|
on any symbol for which <A REL=DEFINITION HREF="../Body/f_fbound.htm#fboundp"><B>FBOUNDP</B></A> returns true.<P>
|
||
|
|
<P>
|
||
|
|
5a. The value returned by <A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A> when <A REL=DEFINITION HREF="../Body/f_fbound.htm#fboundp"><B>FBOUNDP</B></A> returns true<P>
|
||
|
|
but the symbol denotes a macro or special form is not well-defined,<P>
|
||
|
|
but <A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A> will not signal an error. <P>
|
||
|
|
<P>
|
||
|
|
5b. <A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A> of <A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A> requires a <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> as the new value.<P>
|
||
|
|
It is an error to set the <A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A> of a symbol to a<P>
|
||
|
|
symbol or a list or the value returned by <A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A> on<P>
|
||
|
|
the name of a macro or a special form.<P>
|
||
|
|
<P>
|
||
|
|
5c. The motivation for this distinction between <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> and <P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A> is that <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> is intended for day-to-day<P>
|
||
|
|
use within programs while <A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A> is a data <A REL=DEFINITION HREF="../Body/f_docume.htm#structure"><B>structure</B></A><P>
|
||
|
|
accessor used primarily for meta-level applications and not<P>
|
||
|
|
recommended for general use. It is provided primarily to<P>
|
||
|
|
complete the set of accessors on symbols.<P>
|
||
|
|
<P>
|
||
|
|
6. <A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> is extended to allow objects to be coerced to type <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>.<P>
|
||
|
|
<P>
|
||
|
|
6a. (<A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> symbol '<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>) extracts the <A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A> of the<P>
|
||
|
|
given symbol, signalling an error if the symbol is not <A REL=DEFINITION HREF="../Body/f_fbound.htm#fboundp"><B>FBOUNDP</B></A> or<P>
|
||
|
|
if the symbol names a macro or a special-form.<P>
|
||
|
|
<P>
|
||
|
|
6b. (<A REL=DEFINITION HREF="../Body/f_coerce.htm#coerce"><B>COERCE</B></A> x '<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>), where the value of x is a list that<P>
|
||
|
|
begins with <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A>, will return a <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> similar to<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> '(<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> ,x)).<P>
|
||
|
|
<P>
|
||
|
|
7. Clarify that the value of <A REL=DEFINITION HREF="../Body/v_mexp_h.htm#STmacroexpand-hookST"><B>*MACROEXPAND-HOOK*</B></A> is first coerced to a<P>
|
||
|
|
function before being called as the expansion interface hook by<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/f_mexp_.htm#macroexpand-1"><B>MACROEXPAND-1</B></A>.<P>
|
||
|
|
<P>
|
||
|
|
<B>Rationale:<P>
|
||
|
|
</B><P>
|
||
|
|
The fuzzy definition of ``function'' has descended from older dialects of<P>
|
||
|
|
Lisp, such as Maclisp. Many places in existing code make assumptions about<P>
|
||
|
|
the current meaning, making any change painful.<P>
|
||
|
|
<P>
|
||
|
|
It is very important both for documentation clarity and for program type<P>
|
||
|
|
discrimination (such as CLOS) to have a clear term which denotes a <P>
|
||
|
|
``true function.''<P>
|
||
|
|
<P>
|
||
|
|
This proposal is a compromise between a CONSERVATIVE proposal (which left<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> alone and introduced a new type), and a STRICT-REDEFINITION proposal,<P>
|
||
|
|
which incompatibly changed not only the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> type and <A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A>,<P>
|
||
|
|
but also the behavior of <A REL=DEFINITION HREF="../Body/f_funcal.htm#funcall"><B>FUNCALL</B></A>, <A REL=DEFINITION HREF="../Body/f_apply.htm#apply"><B>APPLY</B></A> and functions with functional<P>
|
||
|
|
arguments.<P>
|
||
|
|
<P>
|
||
|
|
For compatibility reasons symbols are still acceptable to <A REL=DEFINITION HREF="../Body/f_funcal.htm#funcall"><B>FUNCALL</B></A> et al.,<P>
|
||
|
|
but for aesthetic reasons lambda-expressions (lists whose <A REL=DEFINITION HREF="../Body/f_car_c.htm#car"><B>CAR</B></A> is <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A><P>
|
||
|
|
and whose <A REL=DEFINITION HREF="../Body/f_car_c.htm#cadr"><B>CADR</B></A> is a list) are no longer acceptable.<P>
|
||
|
|
<P>
|
||
|
|
<B>Current Practice:<P>
|
||
|
|
</B><P>
|
||
|
|
In some implementations, (<A REL=DEFINITION HREF="../Body/f_typep.htm#typep"><B>TYPEP</B></A> x '<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>) signals an error.<P>
|
||
|
|
In some implementations, (<A REL=DEFINITION HREF="../Body/f_typep.htm#typep"><B>TYPEP</B></A> x '<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>) is true for values<P>
|
||
|
|
returned by <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>, symbols that are <A REL=DEFINITION HREF="../Body/f_fbound.htm#fboundp"><B>FBOUNDP</B></A>, and <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>lambda</B></A> expressions. <P>
|
||
|
|
In some implementations, (<A REL=DEFINITION HREF="../Body/f_typep.htm#typep"><B>TYPEP</B></A> x '<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>) is true only for values<P>
|
||
|
|
returned by <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A>.<P>
|
||
|
|
<P>
|
||
|
|
Implementations vary on what my go into the function cell, depending on<P>
|
||
|
|
how much error checking they want to have to do at function call time, and<P>
|
||
|
|
depending on whether they store other kinds of information (such as special<P>
|
||
|
|
form information) in the function cell.<P>
|
||
|
|
<P>
|
||
|
|
Few current Common Lisp implementations have exactly the<P>
|
||
|
|
semantics described in this proposal.<P>
|
||
|
|
<P>
|
||
|
|
<B>Cost to Implementors:<P>
|
||
|
|
</B><P>
|
||
|
|
Bringing type predicates (<A REL=DEFINITION HREF="../Body/f_fnp.htm#functionp"><B>FUNCTIONP</B></A>, etc.) and higher order functions<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/f_apply.htm#apply"><B>APPLY</B></A>, etc.) into compliance should <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> little effort in most<P>
|
||
|
|
implementations.<P>
|
||
|
|
<P>
|
||
|
|
Compiled functions are true functions in almost all current<P>
|
||
|
|
implementations, but in many implementations, interpreted functions and<P>
|
||
|
|
closures stored in the function cell of a symbol are represented as lists.<P>
|
||
|
|
Under this proposal, this representation would have to be different<P>
|
||
|
|
(implemented either as structures or as some special internal data type).<P>
|
||
|
|
The behavior of <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A>, <A REL=DEFINITION HREF="../Body/m_step.htm#step"><B>STEP</B></A>, <A REL=DEFINITION HREF="../Body/m_tracec.htm#trace"><B>TRACE</B></A>, and possibly <A REL=DEFINITION HREF="../Body/f_ed.htm#ed"><B>ED</B></A> would have to be <P>
|
||
|
|
modified to deal with functions that are not lists (but from which the<P>
|
||
|
|
list form can be reconstructed if necessary).<P>
|
||
|
|
<P>
|
||
|
|
<B>Cost to Users:<P>
|
||
|
|
</B><P>
|
||
|
|
The changes to <A REL=DEFINITION HREF="../Body/f_fnp.htm#functionp"><B>FUNCTIONP</B></A> and the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> type declaration are relatively easy<P>
|
||
|
|
to deal with. <P>
|
||
|
|
<P>
|
||
|
|
Because CLtL's language was somewhat fuzzy about what might go into the<P>
|
||
|
|
function cell of a symbol, some code that explicitly deposited symbols<P>
|
||
|
|
or lists in a symbol's function cell, or expected lists back, will<P>
|
||
|
|
have to change. Such code was already not portable, however, since some<P>
|
||
|
|
implementations signal an error when this is done.<P>
|
||
|
|
<P>
|
||
|
|
The original STRICT-REDEFINITION proposal required users to deal with<P>
|
||
|
|
the use of symbols and lambda-expressions as functional arguments. However<P>
|
||
|
|
this proposal is compatible with current CLtL definition in the use of<P>
|
||
|
|
symbols, which would be the hardest change to make. There are probably<P>
|
||
|
|
relatively few uses of lambda-expressions as ``functions'', which can<P>
|
||
|
|
be dealt with by (<A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> `(<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> ,lambda-expresssion)).<P>
|
||
|
|
<P>
|
||
|
|
<B>Benefits:<P>
|
||
|
|
</B><P>
|
||
|
|
The term ``function'' would be given a useful and precise meaning.<P>
|
||
|
|
The <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> datatype would be useful for type discrimination in CLOS.<P>
|
||
|
|
<P>
|
||
|
|
The type hierarchy would be simplified.<P>
|
||
|
|
<P>
|
||
|
|
This proposal brings Common Lisp slightly closer to Scheme and the<P>
|
||
|
|
work of the EuLisp committee. Scheme, for example, also has the concept<P>
|
||
|
|
of a ``procedure'' which is compatible with the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> type.<P>
|
||
|
|
<P>
|
||
|
|
<P>
|
||
|
|
<B>Aesthetics:<P>
|
||
|
|
</B><P>
|
||
|
|
This proposal improves the aesthetics of the language.<P>
|
||
|
|
<P>
|
||
|
|
Lambda-expressions do not obey the normal, apparent scoping rules because<P>
|
||
|
|
free variables cannot refer to lexical bindings. This is because<P>
|
||
|
|
coercing a list to a function would mean (<A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> `(<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> ,list)).<P>
|
||
|
|
<P>
|
||
|
|
The following code does -not- count the number of nodes in a graph:<P>
|
||
|
|
<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>LET</B></A> ((COUNTER 0))<P>
|
||
|
|
(TRAVERSE-THING '(<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> (NODE) (<A REL=DEFINITION HREF="../Body/m_incf_.htm#incf"><B>INCF</B></A> COUNTER))<P>
|
||
|
|
(THING-ROOT)))<P>
|
||
|
|
<P>
|
||
|
|
since it is not the same as<P>
|
||
|
|
<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>LET</B></A> ((COUNTER 0))<P>
|
||
|
|
(TRAVERSE-THING #'(<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> (NODE) (<A REL=DEFINITION HREF="../Body/m_incf_.htm#incf"><B>INCF</B></A> COUNTER))<P>
|
||
|
|
(THING-ROOT)))<P>
|
||
|
|
<P>
|
||
|
|
which does pass around a closure incrementing the <A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>LET</B></A> variable.<P>
|
||
|
|
(These examples assume COUNTER wasn't PROCLAIMed <A REL=DEFINITION HREF="../Body/d_specia.htm#special"><B>SPECIAL</B></A>.)<P>
|
||
|
|
<P>
|
||
|
|
Making the coercion of lambda-expressions to functions explicit with<P>
|
||
|
|
the use of <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> will encourage less confusing code and also highlight<P>
|
||
|
|
that use of <A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A>.<P>
|
||
|
|
<P>
|
||
|
|
<P>
|
||
|
|
<B>Discussion:<P>
|
||
|
|
</B><P>
|
||
|
|
This issue has been discussed at great length; this section attempts<P>
|
||
|
|
only to summarize the important points.<P>
|
||
|
|
<P>
|
||
|
|
There is general agreement that the definition of the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> data type<P>
|
||
|
|
must be clarified or revised. The cleanup of the type hierarchy is important<P>
|
||
|
|
to the CLOS group.<P>
|
||
|
|
<P>
|
||
|
|
The description of <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> must be changed, since it is no longer<P>
|
||
|
|
meaningful to speak of a symbol with a definition that "is a<P>
|
||
|
|
lambda-expression". We believe this is a subject for a separate<P>
|
||
|
|
proposal, as the behavior of <A REL=DEFINITION HREF="../Body/f_cmp.htm#compile"><B>COMPILE</B></A> needs additional clarification.<P>
|
||
|
|
<P>
|
||
|
|
Many different alternatives have been discussed both in the cleanup committee<P>
|
||
|
|
and X3J13. Two proposals were circulated at the March 1988 meeting of X3J13;<P>
|
||
|
|
this version is the result of discussions at that meeting. It is a compromise<P>
|
||
|
|
between the conflicting goals of backward compatibility, flexibility in the<P>
|
||
|
|
language, and simple semantics.<P>
|
||
|
|
<P>
|
||
|
|
This proposal does not address the issue of when coercion to functions occur.<P>
|
||
|
|
For example, it is allowed to write<P>
|
||
|
|
<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/f_mapc_.htm#mapcar"><B>MAPCAR</B></A> 'FROB my-list)<P>
|
||
|
|
<P>
|
||
|
|
It is not specified when the coercion of FROB to its <A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A> <P>
|
||
|
|
occurs. For example, <P>
|
||
|
|
<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A> FROB (X) <P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/m_when_.htm#when"><B>WHEN</B></A> (> X 0) (<A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A> (<A REL=DEFINITION HREF="../Body/f_symb_1.htm#symbol-function"><B>SYMBOL-FUNCTION</B></A> 'FROB) #'(<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>LAMBDA</B></A> (X) <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>)))<P>
|
||
|
|
T)<P>
|
||
|
|
<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/f_mapc_.htm#mapcar"><B>MAPCAR</B></A> 'FROB '(-1 -1 1 1))<P>
|
||
|
|
<P>
|
||
|
|
may return different results if <A REL=DEFINITION HREF="../Body/f_mapc_.htm#mapcar"><B>MAPCAR</B></A> coerces its functional argument<P>
|
||
|
|
once rather than for each element. This may <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> a separate<P>
|
||
|
|
cleanup issue.<P>
|
||
|
|
<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>
|