126 lines
7 KiB
HTML
126 lines
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 EVAL-OTHER 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/iss144_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss145.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss146_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/iss144_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss145.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss146_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue EVAL-OTHER Writeup</H2>
|
|
|
|
<PRE><B>Issue:</B> <A HREF="iss145.htm">EVAL-OTHER</A><P>
|
|
<B>References:</B> 5.1.1 Self-Evaluating Forms (p55)<P>
|
|
<B>Category:</B> ADDITION/CLARIFICATION<P>
|
|
<B>Edit history:</B> 07-Mar-88, Version 1 by Pitman<P>
|
|
8-Jun-88, Version 2 by Masinter (correct typo, add to discussion)<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
CLtL does not specify what the evaluation behavior of some data types.<P>
|
|
<P>
|
|
<B>Proposal (EVAL-OTHER:SELF-EVALUATE):<P>
|
|
</B><P>
|
|
Standard data types (those mentioned by CLtL) other than those for which<P>
|
|
a more explicit evaluation rule exists would be defined to self-evaluate.<P>
|
|
Such data types include, for example, structures, arrays, vectors, and<P>
|
|
pathnames.<P>
|
|
<P>
|
|
Structure types defined by users using <A REL=DEFINITION HREF="../Body/m_defstr.htm#defstruct"><B>DEFSTRUCT</B></A> should also self-evaluate<P>
|
|
unless an explicit implementation type for the <A REL=DEFINITION HREF="../Body/f_docume.htm#structure"><B>structure</B></A> is given in the<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defstr.htm#defstruct"><B>DEFSTRUCT</B></A>, in which case the rule for evaluation of that type should be<P>
|
|
used. (This is important in the case of type <A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A>.)<P>
|
|
<P>
|
|
<B>Test Case:<P>
|
|
</B><P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>LET</B></A> ((TEMP (<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A>))) (<A REL=DEFINITION HREF="../Body/f_eq.htm#eq"><B>EQ</B></A> TEMP (<A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> TEMP))) => T<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>LET</B></A> ((TEMP (<A REL=DEFINITION HREF="../Body/f_mk_ar.htm#make-array"><B>MAKE-ARRAY</B></A> <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>))) (<A REL=DEFINITION HREF="../Body/f_eq.htm#eq"><B>EQ</B></A> TEMP (<A REL=DEFINITION HREF="../Body/f_eval.htm#eval"><B>EVAL</B></A> TEMP))) => T<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
There are numerous possible positions that could be taken, from<P>
|
|
requiring that an error be signalled for all of these cases to<P>
|
|
requiring that these all have some useful behavior.<P>
|
|
<P>
|
|
By making implementations agree, code portability is enhanced.<P>
|
|
By biasing the decision away from the "signal<P>
|
|
an error" end of the choice spectrum, the least interruption is<P>
|
|
caused to implementations which already have working code.<P>
|
|
<P>
|
|
There is still some chance that implementations will have some other<P>
|
|
behavior than either signalling an error or self-evaluating, but there<P>
|
|
are probably few if any.<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
In many implementations, the other data types besides those mentioned in<P>
|
|
CLtL will self-evaluate.<P>
|
|
<P>
|
|
<B>Cost to Implementors:<P>
|
|
</B><P>
|
|
The cost is probably small. This is probably an "upward compatible"<P>
|
|
change for most or all implementations -- a few lines of change in the<P>
|
|
interpreter and/or compiler. Some code walkers may be affected as well.<P>
|
|
<P>
|
|
<B>Cost to Users:<P>
|
|
</B><P>
|
|
None, if they are not exploiting implementation-dependent features of<P>
|
|
some implementation that is being forced to make an incompatible change.<P>
|
|
<P>
|
|
There should be no performance impact since the evaluator's test for these<P>
|
|
new data types can simply be made to follow other tests already in place,<P>
|
|
so existing code will not be slowed.<P>
|
|
<P>
|
|
<B>Cost of Non-Adoption:<P>
|
|
</B><P>
|
|
Implementations will continue to differ in this relatively<P>
|
|
user-visible way.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
Portability will be enhanced because implementations will tend to agree<P>
|
|
in places where they have traditionally not always agreed.<P>
|
|
<P>
|
|
<B>Aesthetics:<P>
|
|
</B><P>
|
|
Some fans of 3LISP may find this invasive to their sense of distinction<P>
|
|
between objects and the notation used to describe objects. In general,<P>
|
|
however, this is a fairly picky detail that is not likely to trouble the<P>
|
|
average programmer.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
This idea for this proposal was suggested by the Japanese community.<P>
|
|
Pitman drafted the formal proposal and supports <A HREF="iss145.htm">EVAL-OTHER:SELF-EVALUATE</A>.<P>
|
|
<P>
|
|
Fahlman: "... I do remember the original design discussions. It was<P>
|
|
proposed that everything but lists and symbols evaluate to themselves,<P>
|
|
but at the time (this was quite early in the process) some people felt<P>
|
|
that this might close out interesting parts of the design space that<P>
|
|
might turn out to be useful for something. This hasn't happened, and<P>
|
|
I think it would be reasonable to close this door now. Some users do<P>
|
|
find it confusing that you have to quote vectors but not strings."<P>
|
|
<P>
|
|
There has been some additional discussion of this proposal (for example,<P>
|
|
an explaination of why a similar proposal in Scheme might be a bad design.)<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>
|