135 lines
8.7 KiB
HTML
135 lines
8.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 FLET-IMPLICIT-BLOCK 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/iss159_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss161.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss162_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/iss159_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss161.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss162_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue FLET-IMPLICIT-BLOCK Writeup</H2>
|
|
|
|
<PRE><B>Issue:</B> <A HREF="iss161.htm">FLET-IMPLICIT-BLOCK</A><P>
|
|
Reference: CLtL p. 113, 67<P>
|
|
<B>Category:</B> OMISSION <P>
|
|
<B>Edit history:</B> Version 2 by cleanup committee 15-Mar-87 15:13:33<P>
|
|
Version 3 by Masinter (reformatting) 7-Apr-87 17:49:12 <P>
|
|
Versions 4,5 by Fahlman 11-Apr-87<P>
|
|
Version 6 by Masinter 5-Jun-87<P>
|
|
<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
Do <A REL=DEFINITION HREF="../Body/s_flet_.htm#flet"><B>FLET</B></A>, <A REL=DEFINITION HREF="../Body/s_flet_.htm#labels"><B>LABELS</B></A>, <A REL=DEFINITION HREF="../Body/m_defmac.htm#defmacro"><B>DEFMACRO</B></A>, <A REL=DEFINITION HREF="../Body/s_flet_.htm#macrolet"><B>MACROLET</B></A>, <A REL=DEFINITION HREF="../Body/m_defset.htm#defsetf"><B>DEFSETF</B></A>, DEFINE-SETF-METHOD, and<P>
|
|
<A REL=DEFINITION HREF="../Body/m_deftp.htm#deftype"><B>DEFTYPE</B></A> have an implicit block around their bodies like the body of a<P>
|
|
DEFUN? CLtL is silent on this point. Many users and some implementors<P>
|
|
assume that such blocks should be established, since they view these<P>
|
|
forms as analogous with <A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A>.<P>
|
|
<P>
|
|
<B>Test case:<P>
|
|
</B><P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>defun</B></A> test ()<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_flet_.htm#flet"><B>flet</B></A> ((test (x) (<A REL=DEFINITION HREF="../Body/s_if.htm#if"><B>if</B></A> x (<A REL=DEFINITION HREF="../Body/s_ret_fr.htm#return-from"><B>return-from</B></A> test 4) 3)))<P>
|
|
(<A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>list</B></A> (test <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>nil</B></A>) (test t))))<P>
|
|
<P>
|
|
(test)<P>
|
|
<P>
|
|
will return (3 4) if <A HREF="iss161.htm">FLET-IMPLICIT-BLOCK:YES</A> is adopted, and would<P>
|
|
return 4 in an implementation that did not add an implicit block around<P>
|
|
<A REL=DEFINITION HREF="../Body/s_flet_.htm#flet"><B>FLET</B></A>.<P>
|
|
<P>
|
|
Proposal: <A HREF="iss161.htm">FLET-IMPLICIT-BLOCK:YES</A><P>
|
|
<P>
|
|
Each function created by <A REL=DEFINITION HREF="../Body/s_flet_.htm#flet"><B>FLET</B></A> and <A REL=DEFINITION HREF="../Body/s_flet_.htm#labels"><B>LABELS</B></A> and each macro created by<P>
|
|
<A REL=DEFINITION HREF="../Body/m_defmac.htm#defmacro"><B>DEFMACRO</B></A> and <A REL=DEFINITION HREF="../Body/s_flet_.htm#macrolet"><B>MACROLET</B></A> has an implicit block around the body. The name<P>
|
|
of this block is that same as the (lexical) name of the function or<P>
|
|
macro. Similarly, the body code in <A REL=DEFINITION HREF="../Body/m_defset.htm#defsetf"><B>DEFSETF</B></A>, DEFINE-SETF-METHOD, and<P>
|
|
<A REL=DEFINITION HREF="../Body/m_deftp.htm#deftype"><B>DEFTYPE</B></A> is surrounded by a block with the same name as the accessor or<P>
|
|
type.<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
Current practice is mixed. Several implementations do not add the<P>
|
|
implicit block, others do, some add some of these blocks and not others.<P>
|
|
<P>
|
|
<B>Cost of adopting this change:<P>
|
|
</B><P>
|
|
Some implementations will have to be modified. This should be a<P>
|
|
relatively easy modification.<P>
|
|
<P>
|
|
<B>Cost of not adopting the change:<P>
|
|
</B><P>
|
|
If the issue is not clarified one way or another, continuing confusion<P>
|
|
will result in portability problems. Clarifying the issue in any other<P>
|
|
way would also <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> modifications in some implementations.<P>
|
|
<P>
|
|
<B>Cost of converting existing code:<P>
|
|
</B><P>
|
|
It is possible that some user code would break because it does a return<P>
|
|
from within a code body to an outer block that has the same as the<P>
|
|
newly-required block. Such problems will be rare, and the code in<P>
|
|
question would not run on all current Common Lisp systems because of the<P>
|
|
diverse interpretations currently in effect. It would be possible to<P>
|
|
detect all such instances automatically, though it seems unlikely that<P>
|
|
anyone will need to use this technique.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
The goal is first to clean up an ambiguous situation and, second, to do<P>
|
|
this in a way that provides consistent behavior between local and global<P>
|
|
definitions. The proposed change would allow a simple rule of thumb:<P>
|
|
any named entity that takes a code body establishes an implicit block<P>
|
|
with the obvious name.<P>
|
|
<P>
|
|
Two alternatives to the proposal were considered and rejected:<P>
|
|
<P>
|
|
The first would be to keep the implicit block in <A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A>, and to clearly<P>
|
|
state that the other forms do not create implicit blocks. This violates<P>
|
|
the goal of consistency between lexical and global definitions, and it<P>
|
|
seems to conflict with users' expectations.<P>
|
|
<P>
|
|
The second alternative was to eliminate the implicit block from <A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A><P>
|
|
rather than adding such blocks to other forms. There was some feeling<P>
|
|
that specifying the implicit block in <A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A> was a poor design decision<P>
|
|
in the first place, since it hides a reference to the name of a function<P>
|
|
within the code of the function itself. If a user decides to rename<P>
|
|
some function, he must be careful to rename any <A REL=DEFINITION HREF="../Body/s_ret_fr.htm#return-from"><B>return-from</B></A> forms within<P>
|
|
the body of the function as well.<P>
|
|
<P>
|
|
However, eliminating the implicit block in <A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A> would be a significant<P>
|
|
incompatible change. Some users find this implicit block to be a great<P>
|
|
convenience for popping out of convoluted code, and some existing code<P>
|
|
makes heavy use of this feature. While such code could be repaired<P>
|
|
automatically by searching for situations in which the user returns from<P>
|
|
a function by name and by adding an appropriate explicit block to any<P>
|
|
function containing such a forms, it would still <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> more more work<P>
|
|
on existing user code than this proposal made above.<P>
|
|
<P>
|
|
There was considerable discussion in the cleanup committee about whether<P>
|
|
these implicit blocks would interfere with tail-recursion optimization,<P>
|
|
which we hope will become more common in future Common Lisp<P>
|
|
implementations. The outcome of these discussions was general agreement<P>
|
|
that a compiler could easily eliminate the implicit block in any case<P>
|
|
where it is not actually used, and that the impact on tail-recursion<P>
|
|
optimization in compiled code is therefore minimal.<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>
|