199 lines
14 KiB
HTML
199 lines
14 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 TYPE-DECLARATION-ABBREVIATION 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/iss348_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss349.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss350_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/iss348_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss349.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss350_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue TYPE-DECLARATION-ABBREVIATION Writeup</H2>
|
|
|
|
<PRE><A HREF="iss349.htm">TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL</A> was passed 11-0 at the June 1990 meeting.<P>
|
|
TYPE-DECLARATION-ABBREVIATION:FORBID-ALL failed 5-8 at the June 1990 meeting.<P>
|
|
<P>
|
|
<B>Issue:</B> <A HREF="iss349.htm">TYPE-DECLARATION-ABBREVIATION</A><P>
|
|
<P>
|
|
<B>References:</B> CLtL p.158, and CLtL Table 4-1 (p.43)<P>
|
|
ANSI CL draft spec p.6-56 (rev 7.31 of 8/29/89)<P>
|
|
ANSI CL draft spec Fig 2-10, 2-11 (p.2-28, 2-29)<P>
|
|
<P>
|
|
Related Issues: COMPILE-ENVIRONMENT-CONSISTENCY<P>
|
|
<A HREF="iss214.htm">LISP-SYMBOL-REDEFINITION</A><P>
|
|
<A HREF="iss252.htm">PACKAGE-CLUTTER</A><P>
|
|
<P>
|
|
<B>Category:</B> CHANGE<P>
|
|
<P>
|
|
<B>Edit history:</B> 1-May-90, Version 1 by Moon<P>
|
|
4-May-90, Version 2 by Moon (update discussion)<P>
|
|
6-Jun-90, Version 3 by Moon (update discussion)<P>
|
|
8-Jun-90, Version 4 by Moon (reflect the X3J13 meeting)<P>
|
|
<P>
|
|
<B>Problem description:<P>
|
|
</B><P>
|
|
<A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>TYPE</B></A> declaration abbreviation, the ability to write<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>DECLARE</B></A> (<type-specifier> <var> <var>...))<P>
|
|
in place of<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> <type-specifier> <var> <var>...))<P>
|
|
is allowed only for some <type-specifier>s, not for all of them.<P>
|
|
<P>
|
|
CLtL allows the abbreviation only when <type-specifier> is a symbol<P>
|
|
and not a user-defined or implementation-defined type.<P>
|
|
<P>
|
|
The draft ANSI CL specification is unclear since it refers to the wrong<P>
|
|
table. If it really meant to refer to Figure 2-11 rather than 2-10, then<P>
|
|
it says the same thing as CLtL, assuming the mistakes in Figure 2-11 get<P>
|
|
corrected (e.g. <A REL=DEFINITION HREF="../Body/t_std_ge.htm#standard-generic-function"><B>standard-generic-function</B></A> is missing).<P>
|
|
<P>
|
|
This makes a distinction between type specifiers specified by the<P>
|
|
language <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> and type specifiers defined by the user or by the<P>
|
|
implementation. Do programmers have to know whether types they use come<P>
|
|
from the kernel language or from a library in order to know whether they<P>
|
|
are allowed to use abbreviated type declarations? Do they have to refer<P>
|
|
to this table that currently contains 91 entries and is still growing?<P>
|
|
<P>
|
|
This also makes an unnecessary distinction between type specifiers that<P>
|
|
are symbols and those that are lists or classes.<P>
|
|
<P>
|
|
This issue contains two proposals.<P>
|
|
<P>
|
|
This is Symbolics issue #31 and is related to Loosemore's issue #8<P>
|
|
of 27 Feb 90.<P>
|
|
<P>
|
|
<B>Proposal (TYPE-DECLARATION-ABBREVIATION:ALLOW-ALL):<P>
|
|
</B><P>
|
|
Allow the word <A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>TYPE</B></A> to be omitted from all <A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>TYPE</B></A> declarations.<P>
|
|
<P>
|
|
A symbol cannot be both the name of a type and the name of a<P>
|
|
declaration. Defining a symbol as a <A REL=DEFINITION HREF="../Body/t_class.htm#class"><B>class</B></A>, <A REL=DEFINITION HREF="../Body/f_docume.htm#structure"><B>structure</B></A>, condition,<P>
|
|
or type name, when the symbol has been defined or proclaimed<P>
|
|
as a declaration name, or vice versa, signals an error.<P>
|
|
<P>
|
|
<B>Examples:<P>
|
|
</B><P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A> SUBSTRING (<A REL=DEFINITION HREF="../Body/a_string.htm#string"><B>STRING</B></A> <A REL=DEFINITION HREF="../Body/03_da.htm#AMoptional"><B>&OPTIONAL</B></A> (START 0) END)<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>DECLARE</B></A> (<A REL=DEFINITION HREF="../Body/a_string.htm#string"><B>STRING</B></A> <A REL=DEFINITION HREF="../Body/a_string.htm#string"><B>STRING</B></A>)<P>
|
|
((<A REL=DEFINITION HREF="../Body/t_intege.htm#integer"><B>INTEGER</B></A> 0 *) START)<P>
|
|
((<A REL=DEFINITION HREF="../Body/a_or.htm#or"><B>OR</B></A> <A REL=DEFINITION HREF="../Body/a_null.htm#null"><B>NULL</B></A> (<A REL=DEFINITION HREF="../Body/t_intege.htm#integer"><B>INTEGER</B></A> 0 *)) END))<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_subseq.htm#subseq"><B>SUBSEQ</B></A> <A REL=DEFINITION HREF="../Body/a_string.htm#string"><B>STRING</B></A> START END))<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defstr.htm#defstruct"><B>DEFSTRUCT</B></A> SHIP HEADING TONNAGE PASSENGER-LIST)<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A> EMBARK (P S)<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>DECLARE</B></A> (SHIP S))<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_pshnew.htm#pushnew"><B>PUSHNEW</B></A> P (SHIP-PASSENGER-LIST S)))<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defcla.htm#defclass"><B>DEFCLASS</B></A> ASTRONAUT () (HELMET-SIZE FAVORITE-BEVERAGE))<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_defun.htm#defun"><B>DEFUN</B></A> CHECKOUT (A)<P>
|
|
(<A REL=DEFINITION HREF="../Body/s_declar.htm#declare"><B>DECLARE</B></A> (#.(<A REL=DEFINITION HREF="../Body/f_find_c.htm#find-class"><B>FIND-CLASS</B></A> 'ASTRONAUT) A))<P>
|
|
(<A REL=DEFINITION HREF="../Body/m_when_.htm#unless"><B>UNLESS</B></A> (<A REL=DEFINITION HREF="../Body/f_eq.htm#eq"><B>EQ</B></A> (<A REL=DEFINITION HREF="../Body/f_slt_va.htm#slot-value"><B>SLOT-VALUE</B></A> A 'FAVORITE-BEVERAGE) 'TANG)<P>
|
|
(<A REL=DEFINITION HREF="../Body/a_error.htm#error"><B>ERROR</B></A> "~A is <A REL=DEFINITION HREF="../Body/a_not.htm#not"><B>not</B></A> a proper astronaut" A)))<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
Arbitrary syntactic differences between built-in facilities and<P>
|
|
user-defined extensions are not in the spirit of Lisp.<P>
|
|
<P>
|
|
Making type names and declaration names be a single namespace<P>
|
|
eliminates any issue of ambiguity in interpreting a decl-spec.<P>
|
|
<P>
|
|
<B>Proposal (TYPE-DECLARATION-ABBREVIATION:FORBID-ALL):<P>
|
|
</B><P>
|
|
Do not allow the word <A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>TYPE</B></A> to be omitted from any <A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>TYPE</B></A> declarations.<P>
|
|
This would be an incompatible change.<P>
|
|
<P>
|
|
<B>Current practice:<P>
|
|
</B><P>
|
|
I don't know of any implementation that implements either proposal.<P>
|
|
<P>
|
|
<B>Cost to Implementors of ALLOW-ALL:<P>
|
|
</B><P>
|
|
Small. It should be easy to change the declaration parser to check<P>
|
|
whether the <A REL=DEFINITION HREF="../Body/f_car_c.htm#car"><B>car</B></A> of a decl-spec is a valid type-specifier, and if so<P>
|
|
either insert the word <A REL=DEFINITION HREF="../Body/a_type.htm#type"><B>TYPE</B></A> or signal an error, depending on whether it's<P>
|
|
also a proclaimed declaration.<P>
|
|
<P>
|
|
<B>Cost to Users of ALLOW-ALL:<P>
|
|
</B><P>
|
|
None to most users. Some users might have programs that use the same<P>
|
|
symbol as both a declaration name and a type name, and they would have<P>
|
|
to rename either the declaration or the type.<P>
|
|
<P>
|
|
<B>Cost of non-adoption:<P>
|
|
</B><P>
|
|
An aesthetic wart on the language will remain.<P>
|
|
<P>
|
|
Implementors will continue to have to maintain a large and seemingly<P>
|
|
ever-changing table of type names that are acceptable as declarations.<P>
|
|
<P>
|
|
<B>Performance impact:<P>
|
|
</B><P>
|
|
There might be a trivial increase in compilation speed as a result of<P>
|
|
adopting either proposal. There should be no run-time performance impact.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
Improved language consistency and aesthetics.<P>
|
|
<P>
|
|
<B>Esthetics:<P>
|
|
</B><P>
|
|
Arbitrary syntactic differences between built-in facilities and<P>
|
|
user-defined extensions are not in the spirit of Lisp.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
Rob MacLachlan was concerned in February about non-obvious side-effects<P>
|
|
of allowing user types here, but never mentioned a specific problem.<P>
|
|
From re-reading his mail, he was most likely concerned only about things<P>
|
|
that are not in this proposal.<P>
|
|
<P>
|
|
Another possible approach would be to eliminate type declaration<P>
|
|
abbreviation, however no one liked that idea when it was mentioned a few<P>
|
|
months ago.<P>
|
|
<P>
|
|
David Gray is opposed to allowing abbreviation for all types on the<P>
|
|
grounds that infrequently-used types might not be recognized as types by<P>
|
|
someone reading a program. Asked for suggestions, he said:<P>
|
|
<P>
|
|
Well, if I had to be limited to twelve, I would choose:<P>
|
|
<P>
|
|
<A REL=DEFINITION HREF="../Body/t_array.htm#array"><B>ARRAY</B></A> <A REL=DEFINITION HREF="../Body/a_ch.htm#character"><B>CHARACTER</B></A> <A REL=DEFINITION HREF="../Body/a_cons.htm#cons"><B>CONS</B></A> <A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>FIXNUM</B></A> <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>FLOAT</B></A> <A REL=DEFINITION HREF="../Body/t_intege.htm#integer"><B>INTEGER</B></A> <A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A> <A REL=DEFINITION HREF="../Body/t_number.htm#number"><B>NUMBER</B></A><P>
|
|
<A REL=DEFINITION HREF="../Body/t_stream.htm#stream"><B>STREAM</B></A> <A REL=DEFINITION HREF="../Body/a_string.htm#string"><B>STRING</B></A> <A REL=DEFINITION HREF="../Body/t_symbol.htm#symbol"><B>SYMBOL</B></A> <A REL=DEFINITION HREF="../Body/a_vector.htm#vector"><B>VECTOR</B></A><P>
|
|
<P>
|
|
but I suspect that this small a list would be too much of an incompatibility<P>
|
|
to be acceptable since other people are sure to have a different favorite<P>
|
|
twelve. It might be possible to agree on a list of around twenty, such as:<P>
|
|
<P>
|
|
<A REL=DEFINITION HREF="../Body/t_array.htm#array"><B>ARRAY</B></A> <A REL=DEFINITION HREF="../Body/a_bit.htm#bit"><B>BIT</B></A> <A REL=DEFINITION HREF="../Body/t_bt_vec.htm#bit-vector"><B>BIT-VECTOR</B></A> <A REL=DEFINITION HREF="../Body/a_ch.htm#character"><B>CHARACTER</B></A> <A REL=DEFINITION HREF="../Body/a_comple.htm#complex"><B>COMPLEX</B></A> <A REL=DEFINITION HREF="../Body/a_cons.htm#cons"><B>CONS</B></A> <A REL=DEFINITION HREF="../Body/t_fixnum.htm#fixnum"><B>FIXNUM</B></A> <A REL=DEFINITION HREF="../Body/a_float.htm#float"><B>FLOAT</B></A> <P>
|
|
<A REL=DEFINITION HREF="../Body/t_intege.htm#integer"><B>INTEGER</B></A> <A REL=DEFINITION HREF="../Body/t_kwd.htm#keyword"><B>KEYWORD</B></A> <A REL=DEFINITION HREF="../Body/a_list.htm#list"><B>LIST</B></A> <A REL=DEFINITION HREF="../Body/t_number.htm#number"><B>NUMBER</B></A> <A REL=DEFINITION HREF="../Body/t_pkg.htm#package"><B>PACKAGE</B></A> <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>PATHNAME</B></A> <A REL=DEFINITION HREF="../Body/t_real.htm#real"><B>REAL</B></A> <A REL=DEFINITION HREF="../Body/t_seq.htm#sequence"><B>SEQUENCE</B></A><P>
|
|
<A REL=DEFINITION HREF="../Body/t_stream.htm#stream"><B>STREAM</B></A> <A REL=DEFINITION HREF="../Body/a_string.htm#string"><B>STRING</B></A> <A REL=DEFINITION HREF="../Body/t_symbol.htm#symbol"><B>SYMBOL</B></A> <A REL=DEFINITION HREF="../Body/a_vector.htm#vector"><B>VECTOR</B></A><P>
|
|
<P>
|
|
David Moon prefers not to single out some types as special cases.<P>
|
|
<P>
|
|
Glenn Burke is not entirely comfortable with the proposal, but doesn't like<P>
|
|
restricting programmers' use of data-abstraction by singling out some types<P>
|
|
as special cases.<P>
|
|
<P>
|
|
Kim Barrett is concerned that signalling an error when there is a collision<P>
|
|
between a type name and a declaration name doesn't really solve the problem.<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>
|