153 lines
9 KiB
HTML
153 lines
9 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 SETF-GET-DEFAULT 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/iss305_w.htm">
|
||
|
|
<LINK REL=UP HREF="../Issues/iss306.htm">
|
||
|
|
<LINK REL=NEXT HREF="../Issues/iss307_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/iss305_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss306.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss307_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
||
|
|
|
||
|
|
<HR>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<H2>Issue SETF-GET-DEFAULT Writeup</H2>
|
||
|
|
|
||
|
|
<PRE><B>Issue:</B> <A HREF="iss306.htm">SETF-GET-DEFAULT</A><P>
|
||
|
|
<B>References:</B> <A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A> of <A REL=DEFINITION HREF="../Body/f_get.htm#get"><B>GET</B></A> (CLtL-II p. 240)<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A> of <A REL=DEFINITION HREF="../Body/f_getf.htm#getf"><B>GETF</B></A> (CLtL-II p. 242)<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A> of <A REL=DEFINITION HREF="../Body/f_gethas.htm#gethash"><B>GETHASH</B></A> (CLtL-II p. 438)<P>
|
||
|
|
Related issues: Issue <A HREF="iss281.htm">PUSHNEW-STORE-REQUIRED</A><P>
|
||
|
|
<B>Category:</B> CLARIFICATION<P>
|
||
|
|
<B>Edit history:</B> V1, 12 Feb 1991, Sandra Loosemore<P>
|
||
|
|
<P>
|
||
|
|
<B>Problem description:<P>
|
||
|
|
</B><P>
|
||
|
|
In the descriptions of <A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A> of <A REL=DEFINITION HREF="../Body/f_get.htm#get"><B>GET</B></A>, <A REL=DEFINITION HREF="../Body/f_getf.htm#getf"><B>GETF</B></A>, and <A REL=DEFINITION HREF="../Body/f_gethas.htm#gethash"><B>GETHASH</B></A>, it is stated<P>
|
||
|
|
that the optional default argument is ignored by <A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A>. It is not<P>
|
||
|
|
clear whether this means that the *subform* corresponding to the<P>
|
||
|
|
default argument that is ignored, or only the *result* of evaluating<P>
|
||
|
|
the subform. The behavior is distinguishable in situations where the<P>
|
||
|
|
subform has observable side-effects.<P>
|
||
|
|
<P>
|
||
|
|
<P>
|
||
|
|
<B>Proposal (SETF-GET-DEFAULT:EVALUATED-BUT-IGNORED):<P>
|
||
|
|
</B><P>
|
||
|
|
Clarify that if the optional "default" argument is supplied in a call<P>
|
||
|
|
to <A REL=DEFINITION HREF="../Body/f_get.htm#get"><B>GET</B></A>, <A REL=DEFINITION HREF="../Body/f_getf.htm#getf"><B>GETF</B></A>, or <A REL=DEFINITION HREF="../Body/f_gethas.htm#gethash"><B>GETHASH</B></A> appearing as a <A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A> place, that subform<P>
|
||
|
|
is evaluated according to the normal left-to-right evaluation rules for<P>
|
||
|
|
subforms of a <A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A> place. However, its value is ignored.<P>
|
||
|
|
<P>
|
||
|
|
<P>
|
||
|
|
<B>Examples:<P>
|
||
|
|
</B><P>
|
||
|
|
#1: (<A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>setf</B></A> (get 'foo 'message (print "hello world"))<P>
|
||
|
|
"goodbye, cruel world")<P>
|
||
|
|
=> prints "hello world"<P>
|
||
|
|
<P>
|
||
|
|
#2: (let ((x nil))<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>setf</B></A> (<A REL=DEFINITION HREF="../Body/f_getf.htm#getf"><B>getf</B></A> x 'message (<A REL=DEFINITION HREF="../Body/f_wr_pr.htm#print"><B>print</B></A> "hello world"))<P>
|
||
|
|
"goodbye, cruel world"))<P>
|
||
|
|
=> prints "hello world"<P>
|
||
|
|
<P>
|
||
|
|
#3: (let ((x (<A REL=DEFINITION HREF="../Body/f_mk_has.htm#make-hash-table"><B>make-hash-table</B></A> :test #'<A REL=DEFINITION HREF="../Body/f_eq.htm#eq"><B>eq</B></A>)))<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>setf</B></A> (<A REL=DEFINITION HREF="../Body/f_gethas.htm#gethash"><B>gethash</B></A> 'message x (<A REL=DEFINITION HREF="../Body/f_wr_pr.htm#print"><B>print</B></A> "hello world"))<P>
|
||
|
|
"goodbye, cruel world"))<P>
|
||
|
|
=> prints "hello world"<P>
|
||
|
|
<P>
|
||
|
|
<P>
|
||
|
|
<B>Rationale:<P>
|
||
|
|
</B><P>
|
||
|
|
Discarding the form corresponding to the default argument would be<P>
|
||
|
|
inconsistent with the rule that subforms of a <A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A> place are<P>
|
||
|
|
evaluated in left-to-right order.<P>
|
||
|
|
<P>
|
||
|
|
<B>Current Practice:<P>
|
||
|
|
</B><P>
|
||
|
|
Lucid version 4.0 does tests 1 and 3 correctly but fails on test 2.<P>
|
||
|
|
Allegro version 3.1 performs all three tests correctly.<P>
|
||
|
|
Symbolics Genera reportedly fails at least test 2.<P>
|
||
|
|
<P>
|
||
|
|
<B>Cost to Implementors:<P>
|
||
|
|
</B><P>
|
||
|
|
Minor.<P>
|
||
|
|
<P>
|
||
|
|
<B>Cost to Users:<P>
|
||
|
|
</B><P>
|
||
|
|
None.<P>
|
||
|
|
<P>
|
||
|
|
<B>Cost of non-adoption:<P>
|
||
|
|
</B><P>
|
||
|
|
Implementations will continue to differ for no good reason.<P>
|
||
|
|
<P>
|
||
|
|
<B>Performance impact:<P>
|
||
|
|
</B><P>
|
||
|
|
None.<P>
|
||
|
|
<P>
|
||
|
|
<B>Benefits:<P>
|
||
|
|
</B><P>
|
||
|
|
The language specification is made more precise and consistent.<P>
|
||
|
|
<P>
|
||
|
|
<B>Esthetics:<P>
|
||
|
|
</B><P>
|
||
|
|
Making the language more consistent is a good thing.<P>
|
||
|
|
<P>
|
||
|
|
<B>Discussion:<P>
|
||
|
|
</B><P>
|
||
|
|
Kent Pitman notes:<P>
|
||
|
|
<P>
|
||
|
|
Btw, someone (I think it was Allan Wechsler at Symbolics), that it<P>
|
||
|
|
should be permissible for:<P>
|
||
|
|
<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>LET</B></A> ((X '(A 1 B 2)))<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A> (<A REL=DEFINITION HREF="../Body/f_getf.htm#getf"><B>GETF</B></A> X 'C 3) 3)<P>
|
||
|
|
X)<P>
|
||
|
|
=> (A 1 B 2)<P>
|
||
|
|
<P>
|
||
|
|
because what the <A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A> -really- says is to make sure that (<A REL=DEFINITION HREF="../Body/f_getf.htm#getf"><B>GETF</B></A> X 'C 3)<P>
|
||
|
|
will later return 3, which that value of X does. As such, I don't<P>
|
||
|
|
even think the code should be ignored. I would prefer this<P>
|
||
|
|
interpretation if we could get consensus, and would appreciate your<P>
|
||
|
|
listing it as an option in your writeup, with me favoring it. Two<P>
|
||
|
|
pieces of rationale you might add to the writeup are that (a) this<P>
|
||
|
|
permits an application to be more space-conservative and (b) this<P>
|
||
|
|
permits an application to not gratuitously modify pages of data that<P>
|
||
|
|
don't really need to be modified, and hence may sometimes result in<P>
|
||
|
|
smaller dumps or smaller working sets in some implementations that<P>
|
||
|
|
either permit dumping an incremental image containing only the<P>
|
||
|
|
modified pages, or that have an initial data set of copy-on-modify<P>
|
||
|
|
pages.<P>
|
||
|
|
<P>
|
||
|
|
As a fall-back, I think your clarification would be an improvement<P>
|
||
|
|
over the status quo. But I think it's not as elegant.<P>
|
||
|
|
<P>
|
||
|
|
Sandra Loosemore says:<P>
|
||
|
|
<P>
|
||
|
|
I think we'd need to spec this out very carefully. Should this <P>
|
||
|
|
behavior be required or simply permitted? Does an explicit default <P>
|
||
|
|
of <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> do the same thing as no default? Does only <A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A> of <A REL=DEFINITION HREF="../Body/f_getf.htm#getf"><B>GETF</B></A> <P>
|
||
|
|
behave this way, or should we generalize this to require/permit <P>
|
||
|
|
*any* <A REL=DEFINITION HREF="../Body/a_setf.htm#setf"><B>SETF</B></A> place not to actually update the place unnecessarily?<P>
|
||
|
|
In the general case, what predicate would be used to compare the <P>
|
||
|
|
new value to the value that would be returned by the accessor? <P>
|
||
|
|
While I agree this is an attractive idea on the surface, the more I <P>
|
||
|
|
think about these questions, the more I become convinced that this <P>
|
||
|
|
is an incompatible change and probably not a good idea overall.<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>
|