1
0
Fork 0
cl-sites/HyperSpec-7-0/HyperSpec/Issues/iss126_w.htm
2024-04-01 10:24:07 +02:00

142 lines
7.8 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 DEPRECATION-POSITION 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/iss125_w.htm">
<LINK REL=UP HREF="../Issues/iss126.htm">
<LINK REL=NEXT HREF="../Issues/iss127_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/iss125_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss126.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss127_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
<HR>
<H2>Issue DEPRECATION-POSITION Writeup</H2>
<PRE><B>Issue:</B> <A HREF="iss126.htm">DEPRECATION-POSITION</A><P>
<B>References:</B> X3J13 committee and sub-committee meetings<P>
<B>Category:</B> Policy<P>
<B>Edit history:</B> 12-DEC-88, Version 1 by Chapman<P>
20-DEC-88, Version 2 by Chapman<P>
9-JAN-89, Version 3 by Chapman<P>
<P>
<B>Problem Description:<P>
</B> <P>
When features of a language become outdated due to technology advances,<P>
or unnecessary due to the addition of better features, should the old<P>
features be deprecated from the language, or deleted outright?<P>
<P>
Since there has never been a Common Lisp <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> before, deprecation<P>
is against a de-facto <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A>, which may or may not be appropriate.<P>
Deletion, on the other hand, is cleaner, but may generate never-ending<P>
discussion when the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> goes for public review (and even in the<P>
X3J13 meeting).<P>
<P>
In summary, there are two levels:<P>
1) features in CLtL that are not present in ANSI Common Lisp 1989,<P>
2) features in ANSI Common Lisp 1989 that will likely not be present in<P>
future standards;<P>
<P>
and the issues are:<P>
a) what features fit into which category<P>
b) how should implementations deal with such features? how can programs be<P>
written to avoid problems with such features?<P>
<P>
Proposal (<A HREF="iss126.htm">DEPRECATION-POSITION:LIMITED</A>)<P>
<P>
Since Common Lisp has been used industrially, it is reasonable to <P>
assume that any level 1 feature will be a cause for<P>
at least some controversy. Therefore, this proposal suggests that<P>
X3J13 put features categorized as level 1 in a separate package,<P>
and retain features categorized as level 2 in the Lisp package, but<P>
declare them deprecated in the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A>.<P>
The members of each level will be determined on a case-by-case basis by <P>
the X3J13 committee.<P>
<P>
<B>Rationale:<P>
</B> <P>
The <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> should contain information about deprecation since<P>
the topic has been mentioned more than once in X3J13, and since<P>
Common Lisp is such a large language.<P>
<P>
It's not<P>
unreasonable for a language the size of Lisp to get rid of the<P>
never-used tools, but we don't want to generate years of discussion<P>
over a relatively minor issue when the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> goes for public review.<P>
<P>
<B>Current Practice:<P>
</B> <P>
Fortran successfully deprecated one constant. However, a proposal <P>
submitted during its latest standardization effort that <P>
suggested deleting old features in favor of new ones was<P>
opposed vehemently. The Pascal committee is currently opposed<P>
to deprecation, and the SPARC proposal suggests that <P>
deprecation should be dictated by the marketplace.<P>
<P>
<P>
<B>Adoption Cost:<P>
</B> <P>
None.<P>
<P>
<B>Benefits:<P>
</B> <P>
This policy will <A REL=DEFINITION HREF="../Body/f_provid.htm#provide"><B>provide</B></A> a basis for future X3J13 decisions.<P>
<P>
<B>Conversion Cost:<P>
</B> <P>
None.<P>
<P>
<B>Aesthetics:<P>
</B> <P>
None.<P>
<P>
<B>Discussion:<P>
</B> <P>
Comment:<P>
&quot;I personally would argue for not including &quot;deprecated&quot; features in<P>
the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> at all, because including them now will make it harder to<P>
remove them later. My perception is that ANSI Common Lisp is turning<P>
out to be a much different language than what is described in CLtL,<P>
particularly if CLOS becomes a required part of the language. If,<P>
with the benefit of hindsight and experience, we now realize that some<P>
&quot;features&quot; described in CLtL were really &quot;bugs&quot;, the time to remove<P>
them is *before* they become cast in stone as part of ANSI Common<P>
Lisp. I suspect that most implementors will continue to <A REL=DEFINITION HREF="../Body/f_provid.htm#provide"><B>provide</B></A> these<P>
features as extensions anyway, as long as a substantial number of<P>
their customers are still using them.&quot;<P>
<P>
Response:<P>
Perhaps most implementors will continue to <A REL=DEFINITION HREF="../Body/f_provid.htm#provide"><B>provide</B></A> the deleted features,<P>
but they will do that also if they are deprecated. Since the only real<P>
difference between the two is the amount of discussion one will generate<P>
over the other (I think that worrying about future difficulty of getting<P>
rid of the features is not a &quot;real&quot; difference yet), it seems that choosing<P>
the route of least resistance in this case is the wisest course.<P>
<P>
Comment: <P>
&quot;For the most part, X3J13 hasn't been able to deal with <P>
which features fit into which category until how the categories will<P>
be divided has been resolved. In particular, there are a number of <P>
features that we didn't want to remove from ANSI Common Lisp 1989 if <P>
it would be awkward for implementations to continue to support them or <P>
programs to continue to use them, but wanted to at least declare them <P>
&quot;obsolete&quot;. There's been some debate on whether CHAR-FONT, for <P>
example , should be deleted before the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> is written, or declared<P>
deprecated within the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A>.&quot;<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>