148 lines
9.7 KiB
HTML
148 lines
9.7 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-REST-LIST-ELEMENT 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/iss177_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss178.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss175_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/iss177_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss178.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss175_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue FUNCTION-TYPE-REST-LIST-ELEMENT Writeup</H2>
|
|
|
|
<PRE><B>Forum:</B> Cleanup<P>
|
|
<B>Issue:</B> <A HREF="iss178.htm">FUNCTION-TYPE-REST-LIST-ELEMENT</A><P>
|
|
<B>References:</B> CLtL p. 27, 47-48, 61<P>
|
|
"Artifical Intelligence Programming", Charniak et. al.<P>
|
|
X3J13/86-003 (A:>GLS>clarifications.text.4)<P>
|
|
<B>Category:</B> CLARIFICATION, ADDITION<P>
|
|
<B>Edit history:</B> Version 1, 23-Nov-1987 Sandra Loosemore<P>
|
|
Version 2, 15-Jan-1988 Sandra Loosemore<P>
|
|
(incorporate comments from Scott Fahlman & others)<P>
|
|
Version 3, 13-Feb-88 Masinter<P>
|
|
Version 4, 2-Oct-88 Masinter (update references,<P>
|
|
discussion)<P>
|
|
Version 5, 14-Nov-88 Masinter (add to discussion)<P>
|
|
Related issues: <A HREF="iss177.htm">FUNCTION-TYPE-KEY-NAME</A>, <P>
|
|
<A HREF="iss176.htm">FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS</A><P>
|
|
<A HREF="iss297.htm">REST-LIST-ALLOCATION</A><P>
|
|
<P>
|
|
<B>Problem description:<P>
|
|
</B><P>
|
|
The <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> type specifier list is provided to allow declaration of<P>
|
|
function argument types and return value types. This type specifier uses a<P>
|
|
syntax similar to the usual <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>lambda</B></A> list syntax to specify which types go<P>
|
|
with which <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>lambda</B></A> list variables. However, this is actually of limited<P>
|
|
usefulness in the context of a declaration, where one normally wants type<P>
|
|
information about the actual arguments which can be passed to the function<P>
|
|
rather than the <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>lambda</B></A> variables to which they are bound.<P>
|
|
<P>
|
|
There is a particular problem with <A REL=DEFINITION HREF="../Body/03_da.htm#AMrest"><B>&REST</B></A> <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>lambda</B></A> variables, which are always<P>
|
|
bound to a value of type <A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A>. For the sake of consistency, it would seem<P>
|
|
that the corresponding type given in the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> declaration must also be<P>
|
|
<A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A>, but since this provides no information about the actual arguments,<P>
|
|
some users/implementors have instead adopted the convention of supplying<P>
|
|
the type of the actual arguments which are gathered into the list. <P>
|
|
<P>
|
|
CLtL is vague on the issue, mentioning only that <A REL=DEFINITION HREF="../Body/03_da.htm#AMrest"><B>&REST</B></A> may appear in the<P>
|
|
type specifier without touching upon its interpretation.<P>
|
|
<P>
|
|
<B>Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):<P>
|
|
</B><P>
|
|
Clarify that, in the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> type specifier, the type specifier provided<P>
|
|
with <A REL=DEFINITION HREF="../Body/03_da.htm#AMrest"><B>&REST</B></A> is the type of each actual argument, not the type of the<P>
|
|
corresponding <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>lambda</B></A> variable.<P>
|
|
<P>
|
|
<B>Example:<P>
|
|
</B><P>
|
|
The type of the function + would be specified as:<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> (<A REL=DEFINITION HREF="../Body/03_da.htm#AMrest"><B>&REST</B></A> <A REL=DEFINITION HREF="../Body/t_number.htm#number"><B>NUMBER</B></A>) <A REL=DEFINITION HREF="../Body/t_number.htm#number"><B>NUMBER</B></A>)<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
This is more useful than specifying that the type of a <A REL=DEFINITION HREF="../Body/03_da.htm#AMrest"><B>&REST</B></A> parameter must<P>
|
|
be <A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A>, since it provides information about the actual arguments.<P>
|
|
<P>
|
|
<B>Current practice:<P>
|
|
</B><P>
|
|
There does not appear to be any concensus on this issue. Most Common Lisp<P>
|
|
implementations currently ignore <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> type declarations. The only<P>
|
|
examples found so far are in a text book on Common Lisp, which follows the<P>
|
|
proposed syntax.<P>
|
|
<P>
|
|
<B>Cost to Implementors:<P>
|
|
</B><P>
|
|
Implementations that ignore the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> type specifier may continue to do<P>
|
|
so. Probably only a small amount of code would have to be written/changed<P>
|
|
in implementations that currently think that the <A REL=DEFINITION HREF="../Body/03_da.htm#AMrest"><B>&REST</B></A> argument should be<P>
|
|
<A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A>.<P>
|
|
<P>
|
|
<B>Cost to Users:<P>
|
|
</B><P>
|
|
Users who have been using the convention that the <A REL=DEFINITION HREF="../Body/03_da.htm#AMrest"><B>&REST</B></A> type parameter must<P>
|
|
be <A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A> will have to change their code. However, because this issue is so<P>
|
|
unclear, the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> type specifier is probably not used very much.<P>
|
|
<P>
|
|
<B>Cost of non-adoption:<P>
|
|
</B><P>
|
|
If nothing is done, the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> type specifier will continue to be of<P>
|
|
limited use for its intended purpose.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
Adopting the proposal will clear up an area of confusion in the language<P>
|
|
design.<P>
|
|
<P>
|
|
<B>Esthetics:<P>
|
|
</B><P>
|
|
Debatable. One the one hand, since the argument type syntax used by the<P>
|
|
<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> type specifier mirrors normal lambda-list syntax, it would be<P>
|
|
cleaner and less confusing to <A REL=DEFINITION HREF="../Body/f_provid.htm#provide"><B>provide</B></A> the type of the <A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>lambda</B></A> variable<P>
|
|
rather than the type of the actual arguments. However, considering the<P>
|
|
types specified in the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> specifier to be the types of the actual<P>
|
|
arguments rather than the types of the parameters as seen on the receiving<P>
|
|
end makes the proposed semantics more palatable.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
This issue provoked considerable debate in the cleanup committee and at<P>
|
|
X3J13. <P>
|
|
<P>
|
|
Many people objected to this proposal, and would prefer the alternative<P>
|
|
that the type given after a <A REL=DEFINITION HREF="../Body/03_da.htm#AMrest"><B>&REST</B></A> in a function declaration apply to the<P>
|
|
value of the formal parameter rather than the actual arguments. This would<P>
|
|
be even more useful if complex <A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A> type specifiers were part of Common<P>
|
|
Lisp (as the proposal in issue LIST-TYPE-SPECIFIER might add) or if it were<P>
|
|
possible to declare, for example, <A REL=DEFINITION HREF="../Body/03_da.htm#AMrest"><B>&REST</B></A> {keyword integer}*.<P>
|
|
<P>
|
|
Some additional arguments against this proposal are the apparent mismatch<P>
|
|
between the external declarations of type and the internal ones. It might<P>
|
|
be that this proposals presumes that rest lists are always lists, and the<P>
|
|
following is illegal:<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A> FOO (<A REL=DEFINITION HREF="../Body/03_da.htm#AMrest"><B>&REST</B></A> X) X)<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_apply.htm#apply"><B>APPLY</B></A> #'FOO T)<P>
|
|
<P>
|
|
which is not otherwise explicitly forbidden, but for which there is no<P>
|
|
legitimate declaration.<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>
|