414 lines
27 KiB
HTML
414 lines
27 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 DECLARE-TYPE-FREE 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/iss095_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss096.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss097_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/iss095_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss096.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss097_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue DECLARE-TYPE-FREE Writeup</H2>
|
|
|
|
<PRE><B>Status:</B> Proposal LEXICAL passed Jan 89 X3J13<P>
|
|
<B>Forum:</B> Cleanup<P>
|
|
<B>Issue:</B> <A HREF="iss096.htm">DECLARE-TYPE-FREE</A><P>
|
|
<B>References:</B> CLtL p.158<P>
|
|
<A HREF="iss092.htm">DECLARATION-SCOPE</A><P>
|
|
Related issues: <A HREF="iss176.htm">FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS</A><P>
|
|
<A HREF="iss092.htm">DECLARATION-SCOPE</A><P>
|
|
<A HREF="iss322.htm">SPECIAL-TYPE-SHADOWING</A><P>
|
|
<B>Category:</B> CLARIFICATION/ADDITION<P>
|
|
<P>
|
|
<B>Edit history:</B> Version 1, 18-Sep-88, Moon<P>
|
|
Version 2, 22-Sep-88, Moon<P>
|
|
(small edits to reflect mail discussion)<P>
|
|
Version 3, 22-Sep-88, Masinter<P>
|
|
Version 4, 27-Sep-88, JonL <P>
|
|
Version 5, 30-Sep-88, Masinter (cost to implementors)<P>
|
|
Version 6, 06-Oct-88, Pitman (minor edits in Discussion)<P>
|
|
Version 7, 5-Dec-88, Masinter (scope->extent)<P>
|
|
Version 8, 7-Dec-88, Masinter (back to scope)<P>
|
|
Version 9, 2-Jan-89, Moon (2 proposals, to clarify discussion)<P>
|
|
Version 10, 12-Jan-89, Masinter (add back lost v.6 phrase <P>
|
|
re nested declarations)<P>
|
|
<P>
|
|
<P>
|
|
<B>Problem description:<P>
|
|
</B><P>
|
|
Section 9.2 of CLtL, p158, says that a declaration specifier like<P>
|
|
(<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>TYPE</B></A> type var1 var2 ...) "... affects only variable bindings". <P>
|
|
Since declarations can occur in contexts other than establishing <P>
|
|
"variable bindings", most people interpret this statement to mean <P>
|
|
that type declarations not in such context are either (1) completely <P>
|
|
to be ignored, or (2) invalid CL syntax. Thus both of the following <P>
|
|
forms would be suspect in that the type declarations could not have <P>
|
|
any effect:<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_if.htm#if"><B>if</B></A> (<A REL=DEFINITION HREF="../Body/a_and.htm#and"><B>and</B></A> (<A REL=DEFINITION HREF="../Body/f_typep.htm#typep"><B>typep</B></A> x '<A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>fixnum</B></A>) (<A REL=DEFINITION HREF="../Body/f_typep.htm#typep"><B>typep</B></A> y '<A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>fixnum</B></A>))<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_locall.htm#locally"><B>locally</B></A> (<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>fixnum</B></A> x y)) ;LOCALLY does <A REL=DEFINITION HREF="../Body/a_not.htm#not"><B>not</B></A> bind<P>
|
|
...algorithm using x <A REL=DEFINITION HREF="../Body/a_and.htm#and"><B>and</B></A> y...) ; any variables.<P>
|
|
...similar algorithm using x <A REL=DEFINITION HREF="../Body/a_and.htm#and"><B>and</B></A> y...)<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>let</B></A> ((y 'foo))<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_setq.htm#setq"><B>setq</B></A> y 10)<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>let</B></A> ((x 5)) ;'y' is <A REL=DEFINITION HREF="../Body/a_not.htm#not"><B>not</B></A> being bound in<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>fixnum</B></A> y)) ; this particular context.<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_incf_.htm#incf"><B>incf</B></A> y)<P>
|
|
...<A REL=DEFINITION HREF="../Body/f_random.htm#random"><B>random</B></A> algorithm...))<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal (DECLARE-TYPE-FREE:ALLOW):<P>
|
|
</B> <P>
|
|
Specify that a type declaration does not only "affect variable bindings";<P>
|
|
rather, type declarations are legal in all declarations. The interpretation<P>
|
|
of a type declaration is that, during the execution of any expression <P>
|
|
within the scope of the declaration, it is an error for the value of<P>
|
|
the declared variable not to be of the declared type. For declarations<P>
|
|
that are associated with variable bindings, the type declaration also<P>
|
|
applies to the initial binding of the variable. In the special case<P>
|
|
of a declaration for which there are no executable expressions<P>
|
|
within the scope of the declaration (e.g., (locally (declare (integer x)))),<P>
|
|
the result is as if there were executable expressions.<P>
|
|
<P>
|
|
In this proposal, a type declaration affects not only variable<P>
|
|
references within its scope, but also affects variable references that<P>
|
|
are outside the scope of the declaration but dynamically inside the<P>
|
|
execution of a form that is itself inside the scope of the<P>
|
|
declaration. Such references can exist when the variable is <A REL=DEFINITION HREF="../Body/d_specia.htm#special"><B>SPECIAL</B></A><P>
|
|
or when the declaration is not attached to the variable's binding, so<P>
|
|
that the scope of the declaration does not include the entire scope<P>
|
|
of the variable.<P>
|
|
<P>
|
|
Clarify that if nested type declarations refer to the same variable,<P>
|
|
then the value of the variable must be a member of the intersection of<P>
|
|
the declared types.<P>
|
|
<P>
|
|
<P>
|
|
<B>Proposal (DECLARE-TYPE-FREE:LEXICAL):<P>
|
|
</B><P>
|
|
Specify that a type declaration does not only "affect variable bindings";<P>
|
|
rather, type declarations are legal in all declarations. The interpretation<P>
|
|
of a type declaration is that, during the execution of any reference to the<P>
|
|
declared variable within the scope of the declaration, it is an error for<P>
|
|
the value of the declared variable not to be of the declared type; and<P>
|
|
during the execution of any <A REL=DEFINITION HREF="../Body/s_setq.htm#setq"><B>SETQ</B></A> of the declared variable within the scope<P>
|
|
of the declaration, it is an error for the newly assigned value of the<P>
|
|
declared variable not to be of the declared type; and at the moment the<P>
|
|
scope of the declaration is entered, it is an error for the value of the<P>
|
|
declared variable not to be of the declared type.<P>
|
|
<P>
|
|
In this proposal, a type declaration affects only variable references within<P>
|
|
its scope, and the meaning of "free" and "variable-binding-associated" type<P>
|
|
declarations can be described identically.<P>
|
|
<P>
|
|
This proposal is equivalent to saying that the meaning of a type declaration<P>
|
|
is equivalent to changing each reference to <var> within the scope of the<P>
|
|
declaration to (<A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>THE</B></A> <type> <var>), changing each expression assigned to the<P>
|
|
variable within the scope of the declaration to (<A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>THE</B></A> <type> <new-value>),<P>
|
|
and executing (<A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>THE</B></A> <type> <var>) at the moment the scope of the declaration<P>
|
|
is entered.<P>
|
|
<P>
|
|
Clarify that if nested type declarations refer to the same variable,<P>
|
|
then the value of the variable must be a member of the intersection of<P>
|
|
the declared types.<P>
|
|
<P>
|
|
<B>Examples:<P>
|
|
</B><P>
|
|
;; this is an error under DECLARE-TYPE-FREE:ALLOW:<P>
|
|
;; the assertion that x is a <A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>fixnum</B></A> is violated between the two <P>
|
|
;; calls to (zap)<P>
|
|
;; this is a valid program under <A HREF="iss096.htm">DECLARE-TYPE-FREE:LEXICAL</A><P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>let</B></A> ((x 12) (y 'foo))<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_flet_.htm#flet"><B>flet</B></A> ((zap () (<A REL=DEFINITION HREF="../Body/m_rotate.htm#rotatef"><B>rotatef</B></A> x y)))<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_locall.htm#locally"><B>locally</B></A> (<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>fixnum</B></A> x))<P>
|
|
(zap)<P>
|
|
(zap)<P>
|
|
x)))<P>
|
|
<P>
|
|
;; this is an error under both proposals<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>let</B></A> ((x 12) (y 'foo))<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_flet_.htm#flet"><B>flet</B></A> ((zap () (<A REL=DEFINITION HREF="../Body/m_rotate.htm#rotatef"><B>rotatef</B></A> x y)))<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_locall.htm#locally"><B>locally</B></A> (<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>fixnum</B></A> x))<P>
|
|
(zap)<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_wr_pr.htm#print"><B>print</B></A> x)<P>
|
|
(zap)<P>
|
|
x)))<P>
|
|
<P>
|
|
;; this is an error under DECLARE-TYPE-FREE:ALLOW, because<P>
|
|
;; the assertion that x is a <A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>fixnum</B></A><P>
|
|
;; is violated during the call to zap, even though few <P>
|
|
;; implementations will be able to check:<P>
|
|
;; this is a valid program under <A HREF="iss096.htm">DECLARE-TYPE-FREE:LEXICAL</A><P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>let</B></A> ((x 12) (y 'foo))<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_flet_.htm#flet"><B>flet</B></A> ((zap ()<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_rotate.htm#rotatef"><B>rotatef</B></A> x y)<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_rotate.htm#rotatef"><B>rotatef</B></A> x y)))<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_locall.htm#locally"><B>locally</B></A> (<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>fixnum</B></A> x))<P>
|
|
(zap)<P>
|
|
x)))<P>
|
|
<P>
|
|
;; this is an error under both proposals, even though the<P>
|
|
;; violation of the type constraint happens after the form<P>
|
|
;; with the declaration is exited.<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>let</B></A> ((f (<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>let</B></A> ((x 3))<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>fixnum</B></A> x))<P>
|
|
#'(<A REL=DEFINITION HREF="../Body/a_lambda.htm#lambda"><B>lambda</B></A> (z) (<A REL=DEFINITION HREF="../Body/m_incf_.htm#incf"><B>incf</B></A> x z)))))<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_funcal.htm#funcall"><B>funcall</B></A> f 4.3))<P>
|
|
<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
This proposal enables optimizing compilers to make use of the otherwise<P>
|
|
ignored type information. Many people have often asked for it, and<P>
|
|
there is no strong reason to forbid it.<P>
|
|
<P>
|
|
DECLARE-TYPE-FREE:ALLOW is more restrictive on programs and hence allows<P>
|
|
more freedom for optimizing compilers. <A HREF="iss096.htm">DECLARE-TYPE-FREE:LEXICAL</A> is easier<P>
|
|
to understand but allows a specialized representation only where the scope<P>
|
|
of the variable is the same as the scope of the declaration or the compiler<P>
|
|
can prove that there are no relevant other references to the variable.<P>
|
|
<P>
|
|
<B>Current practice:<P>
|
|
</B><P>
|
|
Lucid Common Lisp allows "free" type declarations; under some <P>
|
|
circumstances the compiler issues a warning message that such usage <P>
|
|
is an extension to Common Lisp.<P>
|
|
<P>
|
|
<B>Cost to Implementors:<P>
|
|
</B><P>
|
|
Implementations that might currently warn about such declarations<P>
|
|
would have to remove the warning; otherwise, it is valid to ignore <P>
|
|
type declarations.<P>
|
|
<P>
|
|
<B>Cost to Users:<P>
|
|
</B><P>
|
|
None, this is a compatible addition.<P>
|
|
<P>
|
|
<B>Cost of non-adoption:<P>
|
|
</B><P>
|
|
Common Lisp will be less self-consistent.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
Programmers will be able to use type declaration to express their<P>
|
|
intent, rather than having to manually insert <A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>THE</B></A> wrappers around <P>
|
|
every reference.<P>
|
|
<P>
|
|
<P>
|
|
<B>Esthetics:<P>
|
|
</B><P>
|
|
It is a simpler interpretation for type declaration specifiers, with<P>
|
|
fewer special cases; hence reduces the number of exceptions in the<P>
|
|
language.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
Another cleanup issue, <A HREF="iss092.htm">DECLARATION-SCOPE</A>, addresses the scope of <P>
|
|
declarations. This proposal carefully uses the phrase "within the <P>
|
|
scope of the declaration" to avoid confounding the two issues. <P>
|
|
<P>
|
|
This issue has been discussed at the Fort Collins X3J13 meeting in<P>
|
|
November 1987, and at length on the various electronic mailing lists.<P>
|
|
<P>
|
|
At least one current implementation is able to generate more efficient<P>
|
|
code when declarations are associated with a particular binding, since<P>
|
|
it then has the option to choose type-specific specialized storage for <P>
|
|
the runtime value of the variable. So, for example, <P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>let</B></A> ((x v)) (<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>type</B></A> <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>float</B></A> x)) (+ x x))<P>
|
|
<P>
|
|
is sometimes more efficient than<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>let</B></A> ((x v)) (<A REL=DEFINITION HREF="../Body/s_locall.htm#locally"><B>locally</B></A> (<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>type</B></A> <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>float</B></A> x)) (+ x x)))<P>
|
|
<P>
|
|
However, the local type declarations allowed by this proposal do<P>
|
|
<A REL=DEFINITION HREF="../Body/f_provid.htm#provide"><B>provide</B></A> some useful information, even if it is not the *most* useful.<P>
|
|
It is possible for a sufficiently "smart" compiler to infer the <P>
|
|
equivalent of a "binding declaration" when it can ascertain that the <P>
|
|
type of the binding value -- 'v' above -- is commensurate with the <P>
|
|
type locally declared over the scope of usage of the variable.<P>
|
|
<P>
|
|
It may be useful for a compiler to issue a warning whenever it finds<P>
|
|
nested type declarations referring to the same variable and the<P>
|
|
intersection of the declared types is null.<P>
|
|
<P>
|
|
Documentation might want to discuss the style implications of<P>
|
|
nested declarations intersecting. The interesting cases are:<P>
|
|
- An inner declaration could be a subtype of an outer one.<P>
|
|
This is the most useful case and probably the only one to<P>
|
|
be encouraged in code written by humans. e.g.,<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_locall.htm#locally"><B>locally</B></A> (<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>type</B></A> <A REL=DEFINITION HREF="../Body/t_number.htm#number"><B>number</B></A> x))<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_locall.htm#locally"><B>locally</B></A> (<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>type</B></A> <A REL=DEFINITION HREF="../Body/t_intege.htm#integer"><B>integer</B></A> x))<P>
|
|
...use X as <A REL=DEFINITION HREF="../Body/t_intege.htm#integer"><B>integer</B></A>...))<P>
|
|
- An outer declaration could be a subtype of an inner one.<P>
|
|
This is useless but harmless. It might happen as the result<P>
|
|
of certain macro situations. e.g.,<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_locall.htm#locally"><B>locally</B></A> (<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>type</B></A> <A REL=DEFINITION HREF="../Body/t_intege.htm#integer"><B>integer</B></A> x))<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_locall.htm#locally"><B>locally</B></A> (<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>type</B></A> <A REL=DEFINITION HREF="../Body/t_number.htm#number"><B>number</B></A> x))<P>
|
|
...use X as <A REL=DEFINITION HREF="../Body/t_intege.htm#integer"><B>integer</B></A>...))<P>
|
|
- Two types may only partially overlap. This would presumably<P>
|
|
happen only as the result of a macro expansion.<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_locall.htm#locally"><B>locally</B></A> (<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>type</B></A> <A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>fixnum</B></A> x))<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_locall.htm#locally"><B>locally</B></A> (<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>type</B></A> (<A REL=DEFINITION HREF="../Body/a_or.htm#or"><B>or</B></A> <A REL=DEFINITION HREF="../Body/a_bit.htm#bit"><B>bit</B></A> <A REL=DEFINITION HREF="../Body/t_pkg.htm#package"><B>package</B></A>) x))<P>
|
|
...use X as <A REL=DEFINITION HREF="../Body/a_bit.htm#bit"><B>BIT</B></A>...))<P>
|
|
<P>
|
|
*start*<P>
|
|
05268 00024 USm<P>
|
|
GV-Info: X3J13-mailer@SAIL.Stanford.EDU at 7-Apr-89 15:28:47 from AG<P>
|
|
Return-Path: <X3J13-mailer@SAIL.Stanford.EDU><P>
|
|
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 07 APR 89 14:36:21 PDT<P>
|
|
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 7 Apr 89 14:20:08 PDT<P>
|
|
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 573609; Fri 7-Apr-89 17:19:10 EDT<P>
|
|
Date: Fri, 7 Apr 89 17:18 EDT<P>
|
|
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM><P>
|
|
Subject: Did you blow it?<P>
|
|
To: Guy Steele <gls@Think.COM>, rpg@lucid.com<P>
|
|
cc: x3j13@sail.stanford.edu<P>
|
|
In-Reply-To: <8904071720.AA18178@verdi.think.com><P>
|
|
Message-ID: <19890407211851.9.MOON@EUPHRATES.SCRC.Symbolics.COM><P>
|
|
<P>
|
|
Date: Fri, 7 Apr 89 13:20:57 EDT<P>
|
|
From: Guy Steele <gls@Think.COM><P>
|
|
<P>
|
|
Date: Thu, 6 Apr 89 15:19:42 PDT<P>
|
|
From: Richard P. Gabriel <rpg@lucid.com><P>
|
|
<P>
|
|
When I read the effect of Issue: <A HREF="iss096.htm">DECLARE-TYPE-FREE</A> on page 223, I<P>
|
|
completely flipped. I think you might have gotten it wrong.<P>
|
|
<P>
|
|
He did.<P>
|
|
<P>
|
|
You say that in this code:<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>defun</B></A> f (x)<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>type</B></A> <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>float</B></A> x))<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>let</B></A> ((x 'a)) ...)<P>
|
|
...)<P>
|
|
<P>
|
|
The declaration affects both bindings of x. This cannot make any sense<P>
|
|
at all. I don't have marked which version of this issue passed, but I<P>
|
|
think neither implies this. The most that is implied is that if you<P>
|
|
say this:<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>defun</B></A> f (x)<P>
|
|
...<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>let</B></A> ((y 'a))<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>type</B></A> <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>float</B></A> x))<P>
|
|
...)<P>
|
|
...)<P>
|
|
<P>
|
|
then the declaration applies to variable references within the let-y<P>
|
|
and not to within some larger scope.<P>
|
|
<P>
|
|
I hope you are wedged, because otherwise the proposal is wedged.<P>
|
|
<P>
|
|
I also hope I am wedged. I am taking the liberty of cc'ing this<P>
|
|
to X3J13 so that others can let me know what they think.<P>
|
|
<P>
|
|
I believe I was confused by this paragraph from proposal<P>
|
|
<A HREF="iss096.htm">DECLARE-TYPE-FREE:LEXICAL</A>, passed January 1989:<P>
|
|
<P>
|
|
This proposal is equivalent to saying that the meaning of a type declaration<P>
|
|
is equivalent to changing each reference to <var> within the scope of the<P>
|
|
declaration to (<A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>THE</B></A> <type> <var>), changing each expression assigned to the<P>
|
|
variable within the scope of the declaration to (<A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>THE</B></A> <type> <new-value>),<P>
|
|
and executing (<A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>THE</B></A> <type> <var>) at the moment the scope of the declaration<P>
|
|
is entered.<P>
|
|
<P>
|
|
The ambiguity concerns whether in<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>defun</B></A> f (x)<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>type</B></A> <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>float</B></A> x))<P>
|
|
x ;reference 1<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>let</B></A> ((x 'a)) ...)<P>
|
|
x ;reference 2<P>
|
|
...)<P>
|
|
<P>
|
|
the two references are construed to be to the same *variable*.<P>
|
|
(I readily grant that they refer to different *bindings*.)<P>
|
|
I assumed that they were contrued to be the same variable,<P>
|
|
in which case I believe that what I wrote on page 223 of the<P>
|
|
CLtL II draft is a correct conclusion.<P>
|
|
<P>
|
|
The phrase "within the scope of the declaration" quoted above is<P>
|
|
supposed to be a precisely defined phrase. The passed cleanup<P>
|
|
issue <A HREF="iss092.htm">DECLARATION-SCOPE</A> was supposed to define that phrase.<P>
|
|
Unfortunately, there is a problem: the precise language in version<P>
|
|
2 of the proposal was replaced with much less precise language <P>
|
|
in version 4, which was the version that was voted upon.<P>
|
|
The version 2 language was:<P>
|
|
<P>
|
|
The scope of a `bound' declaration is exactly the scope of the<P>
|
|
associated lexical variable or function. If the declaration is<P>
|
|
associated with a special variable, the scope is the scope the variable<P>
|
|
would have had if it had not been special.<P>
|
|
<P>
|
|
`Free' declarations are scoped as if they appeared in a new <A REL=DEFINITION HREF="../Body/s_locall.htm#locally"><B>LOCALLY</B></A> form<P>
|
|
which surrounded the entire special form at the beginning of whose body<P>
|
|
the declaration appears. This is the same as what CLtL p.155 defines to<P>
|
|
be the scope of `pervasive' declarations.<P>
|
|
<P>
|
|
This answers your question about special variables. I think that<P>
|
|
for declarations that concern variable or function bindings, but are<P>
|
|
not actually attached to a binding (i.e. are used free), the correct<P>
|
|
scope is the same as the scope of a non-special binding of that name<P>
|
|
surrounding the form to which the binding is attached; the language<P>
|
|
about <A REL=DEFINITION HREF="../Body/s_locall.htm#locally"><B>LOCALLY</B></A> quoted above is out of date.<P>
|
|
<P>
|
|
Gurg. Your example above is misindented. If you meant<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>defun</B></A> f (x)<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>type</B></A> <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>float</B></A> x))<P>
|
|
x ;reference 1<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>let</B></A> ((x 'a))<P>
|
|
x ;reference 2<P>
|
|
...)<P>
|
|
<P>
|
|
then the scope of the declaration does not include (let ((x 'a)) x ...)<P>
|
|
because type declarations are not "pervasive". Thus what you wrote<P>
|
|
on p.223 of CLtL is wrong.<P>
|
|
<P>
|
|
But if you meant<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>defun</B></A> f (x)<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>declare</B></A> (<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>type</B></A> <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>float</B></A> x))<P>
|
|
x ;reference 1<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_let_l.htm#let"><B>let</B></A> ((x 'a)) ...)<P>
|
|
x ;reference 2<P>
|
|
...)<P>
|
|
<P>
|
|
then the example does not address the question since reference 1<P>
|
|
and reference 2 are clearly both in the scope of the type declaration.<P>
|
|
<P>
|
|
Now that you have pointed it out, I agree that a more likely<P>
|
|
and more desirable interpretation is that the references are<P>
|
|
considered to be to different variables. Question: what if x<P>
|
|
had been proclaimed SPECIAL? Then what would the interpretation be?<P>
|
|
<P>
|
|
A special declaration should not affect the scope of a type declaration.<P>
|
|
Now, the version of DECLARATION-SCOPING that actually passed does not<P>
|
|
actually say that. But I don't think any other position is arguable.<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>
|