178 lines
11 KiB
HTML
178 lines
11 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 UNDEFINED-VARIABLES-AND-FUNCTIONS 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/iss353_w.htm">
|
||
|
|
<LINK REL=UP HREF="../Issues/iss354.htm">
|
||
|
|
<LINK REL=NEXT HREF="../Issues/iss355_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/iss353_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss354.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss355_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
||
|
|
|
||
|
|
<HR>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
<H2>Issue UNDEFINED-VARIABLES-AND-FUNCTIONS Writeup</H2>
|
||
|
|
|
||
|
|
<PRE><B>Status:</B> Passed, as amended, Jun89 X3J13<P>
|
||
|
|
<B>Issue:</B> <A HREF="iss354.htm">UNDEFINED-VARIABLES-AND-FUNCTIONS</A><P>
|
||
|
|
<B>References:</B> 5.1.2 Variables (CLtL pp55-56),<P>
|
||
|
|
Slots (88-002R, p1-10)<P>
|
||
|
|
<B>Category:</B> CHANGE<P>
|
||
|
|
<B>Edit history:</B> 29-Nov-88, Version 1 by Pitman<P>
|
||
|
|
3-Jul-89, Version 2 by Masinter (as per Jun89X3J13)<P>
|
||
|
|
<B>Problem Description:<P>
|
||
|
|
</B><P>
|
||
|
|
CLtL does not specify what happens if you attempt to call a named function<P>
|
||
|
|
which is in fact undefined. In most implementations, it would be devastating to<P>
|
||
|
|
actually jump to code which you had not verified to be a function, so this error<P>
|
||
|
|
should be easily caught -- yet, CLtL does not guarantee that an error will be<P>
|
||
|
|
signalled even in the safest, least fast <A REL=DEFINITION HREF="../Body/d_optimi.htm#optimize"><B>OPTIMIZE</B></A> settings.<P>
|
||
|
|
<P>
|
||
|
|
CLtL (p56) specifies that "it is an error to refer to a variable that is unbound."<P>
|
||
|
|
<P>
|
||
|
|
CLOS (p1-10) specifies that "when an unbound slot is read, the generic function<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/f_slt_un.htm#slot-unbound"><B>SLOT-UNBOUND</B></A> is invoked. The system-supplied primary <A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> for <A REL=DEFINITION HREF="../Body/f_slt_un.htm#slot-unbound"><B>SLOT-UNBOUND</B></A><P>
|
||
|
|
signals an error."<P>
|
||
|
|
<P>
|
||
|
|
CLOS and CLtL are not in agreement on their treatment of unbound variables.<P>
|
||
|
|
<P>
|
||
|
|
CLtL is very weak in that it guarantees no support for reliably detecting<P>
|
||
|
|
and signalling an error when the error situation occurs, even in the safest,<P>
|
||
|
|
least fast <A REL=DEFINITION HREF="../Body/d_optimi.htm#optimize"><B>OPTIMIZE</B></A> setting.<P>
|
||
|
|
<P>
|
||
|
|
CLOS is very strong in that it forces detection of the error in all<P>
|
||
|
|
situations -- even in the fastest, least safe <A REL=DEFINITION HREF="../Body/d_optimi.htm#optimize"><B>OPTIMIZE</B></A> setting.<P>
|
||
|
|
<P>
|
||
|
|
The disparate positions for treatment of variables and slots should be<P>
|
||
|
|
reconciled, either by finding a compromise or by justifying the apparent<P>
|
||
|
|
inconsistency. The final story should explain function references as well.<P>
|
||
|
|
<P>
|
||
|
|
<B>Proposal (UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE):<P>
|
||
|
|
</B><P>
|
||
|
|
Define that reading an undefined function or an unbound variable<P>
|
||
|
|
must be detected in the highest safety setting,<P>
|
||
|
|
but the effect is undefined in any other safety setting. That is,<P>
|
||
|
|
- Reading an undefined function should signal an error.<P>
|
||
|
|
- Reading an an unbound variable should signal an error.<P>
|
||
|
|
<P>
|
||
|
|
By ``reading an undefined function'' in the above, we mean to <P>
|
||
|
|
include both references to the function using the <A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> <P>
|
||
|
|
special form, such as F in (<A REL=DEFINITION HREF="../Body/a_fn.htm#function"><B>FUNCTION</B></A> F) and references to the<P>
|
||
|
|
function in a call, such as F in (F X).<P>
|
||
|
|
<P>
|
||
|
|
For the case of <A REL=DEFINITION HREF="../Body/d_inline.htm#inline"><B>INLINE</B></A> functions (in implementations where they are<P>
|
||
|
|
supported), it is permissible to consider that performing the inlining<P>
|
||
|
|
constitutes the read, so that an <A REL=DEFINITION HREF="../Body/f_fbound.htm#fboundp"><B>FBOUNDP</B></A> check need not be done at<P>
|
||
|
|
execution time. Put another way, the effect of <A REL=DEFINITION HREF="../Body/f_fmakun.htm#fmakunbound"><B>FMAKUNBOUND</B></A> of a function<P>
|
||
|
|
on potentially inlined references to that function is undefined.<P>
|
||
|
|
<P>
|
||
|
|
Specify that the type of error signalled when an undefined function<P>
|
||
|
|
is detected is <A REL=DEFINITION HREF="../Body/e_undefi.htm#undefined-function"><B>UNDEFINED-FUNCTION</B></A>, and that the NAME slot of the<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/e_undefi.htm#undefined-function"><B>UNDEFINED-FUNCTION</B></A> condition is initialized to the name of the<P>
|
||
|
|
offending function.<P>
|
||
|
|
<P>
|
||
|
|
Specify that the type of error signalled when a unbound variable <P>
|
||
|
|
is detected is <A REL=DEFINITION HREF="../Body/e_unbo_1.htm#unbound-variable"><B>UNBOUND-VARIABLE</B></A>, and that the NAME slot of the<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/e_unbo_1.htm#unbound-variable"><B>UNBOUND-VARIABLE</B></A> condition is initialized to the name of the<P>
|
||
|
|
offending variable.<P>
|
||
|
|
<P>
|
||
|
|
Introduce a new condition type, <A REL=DEFINITION HREF="../Body/e_unboun.htm#unbound-slot"><B>UNBOUND-SLOT</B></A>, which inherits from<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/e_cell_e.htm#cell-error"><B>CELL-ERROR</B></A>. This new type has an additional slot, INSTANCE, which<P>
|
||
|
|
can be initialized using the :INSTANCE keyword to <A REL=DEFINITION HREF="../Body/f_mk_cnd.htm#make-condition"><B>MAKE-CONDITION</B></A>.<P>
|
||
|
|
Introdue a new function <A REL=DEFINITION HREF="../Body/f_unboun.htm#unbound-slot-instance"><B>UNBOUND-SLOT-INSTANCE</B></A> to access INSTANCE slot.<P>
|
||
|
|
<P>
|
||
|
|
Specify that the type of error signalled by the default primary<P>
|
||
|
|
<A REL=DEFINITION HREF="../Body/t_method.htm#method"><B>method</B></A> for the <A REL=DEFINITION HREF="../Body/f_slt_un.htm#slot-unbound"><B>SLOT-UNBOUND</B></A> generic function is <A REL=DEFINITION HREF="../Body/e_unboun.htm#unbound-slot"><B>UNBOUND-SLOT</B></A>,<P>
|
||
|
|
and that the NAME slot of the <A REL=DEFINITION HREF="../Body/e_unboun.htm#unbound-slot"><B>UNBOUND-SLOT</B></A> condition is initialized<P>
|
||
|
|
to the name of the offending variable, and that the INSTANCE slot<P>
|
||
|
|
of the <A REL=DEFINITION HREF="../Body/e_unboun.htm#unbound-slot"><B>UNBOUND-SLOT</B></A> condition is initialized to the offending instance.<P>
|
||
|
|
<P>
|
||
|
|
<B>Test Case:<P>
|
||
|
|
</B><P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/f_procla.htm#proclaim"><B>PROCLAIM</B></A> '(<A REL=DEFINITION HREF="../Body/d_optimi.htm#optimize"><B>OPTIMIZE</B></A> (<A REL=DEFINITION HREF="../Body/d_optimi.htm#safety"><B>SAFETY</B></A> 3) (<A REL=DEFINITION HREF="../Body/d_optimi.htm#speed"><B>SPEED</B></A> 0)))<P>
|
||
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A> FOO () X)<P>
|
||
|
|
(FOO)<P>
|
||
|
|
>>Error: The variable X is not bound.<P>
|
||
|
|
...<P>
|
||
|
|
<P>
|
||
|
|
<B>Rationale:<P>
|
||
|
|
</B><P>
|
||
|
|
This makes it easier to treat slots like variables.<P>
|
||
|
|
<P>
|
||
|
|
This makes it possible to better rely on an unbound variable error being<P>
|
||
|
|
signalled when one has occurred.<P>
|
||
|
|
<P>
|
||
|
|
This makes it possible to compile out useless error checking in CLOS<P>
|
||
|
|
code where the code is debugged and the checking is redundant.<P>
|
||
|
|
<P>
|
||
|
|
For the case of undefined functions, blindly jumping to an undefined<P>
|
||
|
|
function is an incredibly dangerous thing to do. Every implementation<P>
|
||
|
|
should guarantee at least some way to get error checking of undefined<P>
|
||
|
|
functions.<P>
|
||
|
|
<P>
|
||
|
|
<B>Current Practice:<P>
|
||
|
|
</B><P>
|
||
|
|
Until recently, Symbolics Cloe did not ever signal an error on unbound<P>
|
||
|
|
variable, even in the safest case. The excuse was that this was a CLtL<P>
|
||
|
|
didn't <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> it, but it was sometimes an impediment to debugging.<P>
|
||
|
|
<P>
|
||
|
|
Some benchmarks for Symbolics Cloe (which currently only claims to<P>
|
||
|
|
implement New Flavors, not CLOS) could be faster if checking for unbound<P>
|
||
|
|
instance variables could be optimized away.<P>
|
||
|
|
<P>
|
||
|
|
Symbolics Genera doesn't care about safety issues in variable access<P>
|
||
|
|
because the check can be done by microcode.<P>
|
||
|
|
<P>
|
||
|
|
<B>Cost to Implementors:<P>
|
||
|
|
</B><P>
|
||
|
|
This change does not force a change to any current implementation, except<P>
|
||
|
|
those which do not yet signal unbound variable or undefined function errors<P>
|
||
|
|
even in the safest setting.<P>
|
||
|
|
<P>
|
||
|
|
<B>Cost to Users:<P>
|
||
|
|
</B><P>
|
||
|
|
This checking might slow down some code which is written for the safest<P>
|
||
|
|
setting yet does not need this check.<P>
|
||
|
|
<P>
|
||
|
|
Any implementation-specific code which depended on these references not<P>
|
||
|
|
signalling would be broken. Such code was not portable, of course.<P>
|
||
|
|
<P>
|
||
|
|
Any CLOS code which depends on <A REL=DEFINITION HREF="../Body/f_slt_un.htm#slot-unbound"><B>SLOT-UNBOUND</B></A> being called even in low safety<P>
|
||
|
|
settings would be broken. The amount of such code at this point is likely<P>
|
||
|
|
to be little or none. If such cases did exist, local or global changes to<P>
|
||
|
|
safety settings would correct the problem (at some cost in speed).<P>
|
||
|
|
<P>
|
||
|
|
<B>Cost of Non-Adoption:<P>
|
||
|
|
</B><P>
|
||
|
|
Some important error checking would not occur.<P>
|
||
|
|
Some important optimizations could not be done.<P>
|
||
|
|
The language would seem internally less consistent.<P>
|
||
|
|
<P>
|
||
|
|
<B>Benefits:<P>
|
||
|
|
</B><P>
|
||
|
|
The costs of non-adoption would be avoided.<P>
|
||
|
|
<P>
|
||
|
|
<B>Aesthetics:<P>
|
||
|
|
</B><P>
|
||
|
|
This would regularize things a little.<P>
|
||
|
|
<P>
|
||
|
|
<B>Discussion:<P>
|
||
|
|
</B><P>
|
||
|
|
Pitman thinks this would be a good idea.<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>
|