perm filename CLCLEA.2[COM,LSP] blob sn#858556 filedate 1988-06-18 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00495 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00072 00002
C00073 00003	∂28-Nov-87  0534	CL-Cleanup-mailer 	[Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C00079 00004	∂28-Nov-87  1105	CL-Cleanup-mailer 	Issue status
C00084 00005	∂30-Nov-87  0921	CL-Cleanup-mailer 	[Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C00087 00006	∂30-Nov-87  1446	CL-Cleanup-mailer 	Issue: FORMAT-COLON-UPARROW-SCOPE
C00097 00007	∂30-Nov-87  1733	CL-Cleanup-mailer 	Issue: FORMAT-COLON-UPARROW-SCOPE
C00099 00008	∂30-Nov-87  1911	CL-Cleanup-mailer 	Re: Issue: FORMAT-COLON-UPARROW-SCOPE
C00100 00009	∂01-Dec-87  0025	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
C00102 00010	∂01-Dec-87  0038	CL-Cleanup-mailer 	Issue: FORMAT-COLON-UPARROW-SCOPE
C00105 00011	∂01-Dec-87  0100	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
C00108 00012	∂01-Dec-87  0923	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
C00111 00013	∂01-Dec-87  1042	CL-Cleanup-mailer 	Re: Issue: FORMAT-COLON-UPARROW-SCOPE
C00113 00014	∂01-Dec-87  1043	CL-Cleanup-mailer 	Re: Issue: FORMAT-COLON-UPARROW-SCOPE
C00115 00015	∂01-Dec-87  1102	CL-Cleanup-mailer 	Issue:  FUNCTION-TYPE-REST-LIST-ELEMENT
C00126 00016	∂01-Dec-87  1103	CL-Cleanup-mailer 	Issue:  FUNCTION-TYPE-KEY-NAME
C00132 00017	∂01-Dec-87  1201	CL-Cleanup-mailer 	Issue:  FUNCTION-TYPE-KEY-NAME
C00136 00018	∂01-Dec-87  1756	CL-Cleanup-mailer 	CL-CLEANUP membership
C00140 00019	∂01-Dec-87  2016	CL-Cleanup-mailer 	introduction
C00142 00020	∂01-Dec-87  2053	CL-Cleanup-mailer 	introduction
C00144 00021	∂02-Dec-87  1008	CL-Cleanup-mailer 	Re: CL-CLEANUP membership
C00146 00022	∂02-Dec-87  1119	CL-Cleanup-mailer 	Re: CL-CLEANUP membership
C00148 00023	∂02-Dec-87  1202	CL-Cleanup-mailer 	intro
C00149 00024	∂02-Dec-87  1421	CL-Cleanup-mailer 	Issue: APPEND-DOTTED (Version 4)
C00151 00025	∂02-Dec-87  1422	CL-Cleanup-mailer 	Issue: ASSOC-RASSOC-IF-KEY (Version 4)
C00153 00026	∂02-Dec-87  1528	CL-Cleanup-mailer 	intro
C00155 00027	∂02-Dec-87  1941	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
C00158 00028	∂02-Dec-87  2043	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00167 00029	∂02-Dec-87  2146	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00171 00030	∂02-Dec-87  2225	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00173 00031	∂02-Dec-87  2236	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00175 00032	∂03-Dec-87  0953	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00184 00033	∂03-Dec-87  1042	CL-Cleanup-mailer 	Issue: FORMAT-COLON-UPARROW-SCOPE
C00187 00034	∂03-Dec-87  1059	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00190 00035	∂03-Dec-87  1059	CL-Cleanup-mailer 	CL-CLEANUP membership
C00192 00036	∂03-Dec-87  1123	CL-Cleanup-mailer 	FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00194 00037	∂03-Dec-87  1215	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00198 00038	∂03-Dec-87  1331	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00204 00039	∂04-Dec-87  1430	CL-Cleanup-mailer 	Issue: LAST-N (Version 1)
C00210 00040	∂04-Dec-87  1449	CL-Cleanup-mailer 	Issue: LAST-N (Version 1)
C00212 00041	∂04-Dec-87  1535	CL-Cleanup-mailer 	Issue: LAST-N (Version 1)
C00216 00042	∂04-Dec-87  1729	CL-Cleanup-mailer 	Re: Issue: LAST-N (Version 1)
C00217 00043	∂04-Dec-87  1729	CL-Cleanup-mailer 	Introduction
C00219 00044	∂05-Dec-87  0001	CL-Cleanup-mailer 	Introduction
C00221 00045	∂06-Dec-87  1424	CL-Cleanup-mailer 	Issue: DRIBBLE-TECHNIQUE (Version 1)
C00227 00046	∂06-Dec-87  1435	CL-Cleanup-mailer 	Introduction
C00229 00047	∂07-Dec-87  1643	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00231 00048	∂07-Dec-87  2038	CL-Cleanup-mailer 	[Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
C00234 00049	∂07-Dec-87  2310	CL-Cleanup-mailer 	introduction
C00236 00050	∂07-Dec-87  2315	CL-Cleanup-mailer 	Issue: DRIBBLE-TECHNIQUE (Version 1)
C00239 00051	∂07-Dec-87  2328	CL-Cleanup-mailer 	Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00245 00052	∂08-Dec-87  0021	CL-Cleanup-mailer 	Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00249 00053	∂08-Dec-87  0728	CL-Cleanup-mailer 	Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00251 00054	∂08-Dec-87  0857	CL-Cleanup-mailer 	Introduction
C00253 00055	∂08-Dec-87  0937	CL-Cleanup-mailer 	Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00257 00056	∂08-Dec-87  0939	CL-Cleanup-mailer 	Re: Issue: DRIBBLE-TECHNIQUE (Version 1)
C00258 00057	∂08-Dec-87  0948	CL-Cleanup-mailer 	Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00266 00058	∂08-Dec-87  1121	CL-Cleanup-mailer 	Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00268 00059	∂08-Dec-87  1123	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00274 00060	∂08-Dec-87  1231	CL-Cleanup-mailer 	Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00278 00061	∂08-Dec-87  1334	CL-Cleanup-mailer 	Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00280 00062	∂08-Dec-87  1418	CL-Cleanup-mailer 	Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00282 00063	∂08-Dec-87  1620	CL-Cleanup-mailer 	Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00285 00064	∂08-Dec-87  1644	CL-Cleanup-mailer 	Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00289 00065	∂08-Dec-87  1828	CL-Cleanup-mailer 	Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00291 00066	∂08-Dec-87  1836	CL-Cleanup-mailer 	Introductions
C00293 00067	∂09-Dec-87  0309	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00298 00068	∂09-Dec-87  0702	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00300 00069	∂09-Dec-87  0729	CL-Cleanup-mailer 	Issue: FUNCTION-DECLARATION issues
C00305 00070	∂09-Dec-87  0848	CL-Cleanup-mailer 	Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00308 00071	∂09-Dec-87  0955	CL-Cleanup-mailer 	Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00313 00072	∂10-Dec-87  2311	CL-Cleanup-mailer 	Cleanup issues from Japanese technical working group
C00326 00073	∂15-Dec-87  1050	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00328 00074	∂15-Dec-87  1128	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
C00331 00075	∂16-Dec-87  1538	CL-Cleanup-mailer 	Issue: SETF-METHOD-FOR-SYMBOLS (alternate proposal)
C00344 00076	∂17-Dec-87  1736	CL-Cleanup-mailer 	Cleanup issues from Japanese technical working group
C00352 00077	∂17-Dec-87  1740	CL-Cleanup-mailer 	Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00354 00078	∂17-Dec-87  1745	CL-Cleanup-mailer 	Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
C00359 00079	∂17-Dec-87  1757	CL-Cleanup-mailer 	Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
C00361 00080	∂17-Dec-87  1805	CL-Cleanup-mailer 	Issue: FUNCTION-DECLARATION issues
C00364 00081	∂17-Dec-87  1812	CL-Cleanup-mailer 	Cleanup issues from Japanese technical working group
C00369 00082	∂17-Dec-87  1823	CL-Cleanup-mailer 	Issue: FUNCTION-DECLARATION issues
C00372 00083	∂18-Dec-87  1439	CL-Cleanup-mailer 	whether random objects self-evaluate (was cleaup issues from Japan)
C00376 00084	∂18-Dec-87  1759	CL-Cleanup-mailer 	whether random objects self-evaluate (was cleaup issues from Japan)
C00378 00085	∂21-Dec-87  1924	CL-Cleanup-mailer 	SETF-METHOD-FOR-SYMBOLS Issue
C00380 00086	∂30-Dec-87  1625	CL-Cleanup-mailer 	Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
C00385 00087	∂30-Dec-87  1634	CL-Cleanup-mailer 	Issue: REDUCE-ARGUMENT-EXTRACTION (version 2)
C00391 00088	∂31-Dec-87  1126	CL-Cleanup-mailer 	Issue: REDUCE-ARGUMENT-EXTRACTION (version 2)
C00393 00089	∂31-Dec-87  1723	CL-Cleanup-mailer 	Releasing potentially confusing info to the CL community
C00398 00090	∂31-Dec-87  1749	CL-Cleanup-mailer 	Re: Releasing potentially confusing info to the CL community
C00401 00091	∂01-Jan-88  1245	CL-Cleanup-mailer 	New issue: FLET-DECLARATIONS
C00408 00092	∂03-Jan-88  1322	CL-Cleanup-mailer 	cleanup status
C00413 00093	∂03-Jan-88  1814	CL-Cleanup-mailer 	cleanup status
C00421 00094	∂03-Jan-88  2012	CL-Cleanup-mailer 	cleanup status
C00425 00095	∂04-Jan-88  0852	CL-Cleanup-mailer 	Re: cleanup status
C00428 00096	∂04-Jan-88  1147	CL-Cleanup-mailer 	Re: New issue: FLET-DECLARATIONS
C00430 00097	∂04-Jan-88  1309	CL-Cleanup-mailer 	Re: cleanup status
C00432 00098	∂04-Jan-88  1832	CL-Cleanup-mailer 	&REST lists
C00436 00099	∂04-Jan-88  2035	CL-Cleanup-mailer 	&REST lists
C00440 00100	∂05-Jan-88  0521	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE
C00453 00101	∂05-Jan-88  0938	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE
C00455 00102	∂05-Jan-88  1345	CL-Cleanup-mailer 	Re: Issue: DECLARATION-SCOPE
C00458 00103	∂05-Jan-88  1430	CL-Cleanup-mailer 	Re: Issue: DECLARATION-SCOPE
C00463 00104	∂05-Jan-88  1458	CL-Cleanup-mailer 	Re: Issue: DECLARATION-SCOPE
C00466 00105	∂05-Jan-88  1644	CL-Cleanup-mailer 	Re: Issue: DECLARATION-SCOPE
C00468 00106	∂05-Jan-88  1922	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE
C00470 00107	∂05-Jan-88  1958	CL-Cleanup-mailer 	Re: Issue: DECLARATION-SCOPE
C00474 00108	∂06-Jan-88  0736	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE
C00477 00109	∂06-Jan-88  1334	CL-Cleanup-mailer 	cleanup status
C00480 00110	∂06-Jan-88  1414	CL-Cleanup-mailer 	cleanup status
C00485 00111	∂06-Jan-88  1804	CL-Cleanup-mailer 	cleanup status
C00487 00112	∂06-Jan-88  2034	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE
C00493 00113	∂06-Jan-88  2318	CL-Cleanup-mailer 	Issue: DECLARE-MACROS
C00497 00114	∂06-Jan-88  2331	CL-Cleanup-mailer 	Cleanup status
C00503 00115	∂06-Jan-88  2356	CL-Cleanup-mailer 	cleanup status
C00506 00116	∂06-Jan-88  2358	CL-Cleanup-mailer 	cleanup status
C00508 00117	∂07-Jan-88  0026	CL-Cleanup-mailer 	your proposed revision
C00514 00118	∂07-Jan-88  0555	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE
C00518 00119	∂07-Jan-88  1224	CL-Cleanup-mailer 	your proposed revision
C00520 00120	∂11-Jan-88  1150	CL-Cleanup-mailer 	paper for IWoLES
C00544 00121	∂14-Jan-88  2023	CL-Cleanup-mailer 	[Jan Zubkoff <edsel!jlz@labrea.stanford.edu>: mailings]
C00546 00122	∂14-Jan-88  2023	CL-Cleanup-mailer 	Issue: APPEND-DOTTED (Version 5)
C00554 00123	∂14-Jan-88  2023	CL-Cleanup-mailer 	Re: Issue: DECLARATION-SCOPE
C00556 00124	∂14-Jan-88  2024	CL-Cleanup-mailer 	Re: New issue: FLET-DECLARATIONS
C00558 00125	∂14-Jan-88  2023	CL-Cleanup-mailer 	Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
C00560 00126	∂14-Jan-88  2045	CL-Cleanup-mailer 	Re: Issue: LAST-N (Version 1)
C00562 00127	∂14-Jan-88  2054	CL-Cleanup-mailer 	Re: Issue: LOAD-TIME-EVAL (Version 3)
C00564 00128	∂14-Jan-88  2111	CL-Cleanup-mailer 	Issue status: READY FOR LETTER BALLOT
C00571 00129	∂14-Jan-88  2116	CL-Cleanup-mailer 	Issue status: PENDING
C00589 00130	∂15-Jan-88  1056	CL-Cleanup-mailer 	Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
C00591 00131	∂15-Jan-88  1327	CL-Cleanup-mailer 	New, improved FUNCTION-TYPE-KEY-NAME proposal
C00597 00132	∂15-Jan-88  1327	CL-Cleanup-mailer 	New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00610 00133	∂15-Jan-88  1450	CL-Cleanup-mailer 	Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00612 00134	∂15-Jan-88  1511	CL-Cleanup-mailer 	Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00614 00135	∂15-Jan-88  1516	CL-Cleanup-mailer 	New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00617 00136	∂15-Jan-88  1724	CL-Cleanup-mailer 	Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00619 00137	∂15-Jan-88  1724	CL-Cleanup-mailer 	New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00622 00138	∂15-Jan-88  1741	CL-Cleanup-mailer 	Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00625 00139	∂18-Jan-88  1618	CL-Cleanup-mailer 	Issue: FORMAT-COLON-UPARROW-SCOPE (version 2)
C00635 00140	∂18-Jan-88  1831	CL-Cleanup-mailer 	Issue: FORMAT-COLON-UPARROW-SCOPE (version 2)
C00637 00141	∂19-Jan-88  1539	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
C00643 00142	∂21-Jan-88  0802	CL-Cleanup-mailer 	Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00645 00143	∂21-Jan-88  0810	CL-Cleanup-mailer 	Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
C00650 00144	∂26-Jan-88  1244	CL-Cleanup-mailer 	Issue: REMF-MULTIPLE
C00657 00145	∂26-Jan-88  1307	CL-Cleanup-mailer 	Issue: EXPORT-IMPORT
C00663 00146	∂27-Jan-88  0714	CL-Cleanup-mailer 	Issue: EXPORT-IMPORT
C00665 00147	∂28-Jan-88  0424	CL-Cleanup-mailer 	Issue: EXPORT-IMPORT
C00667 00148	∂03-Feb-88  0750	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE (Version 2)
C00669 00149	∂03-Feb-88  0755	CL-Cleanup-mailer 	Issue: EXPORT-IMPORT
C00671 00150	∂03-Feb-88  0755	CL-Cleanup-mailer 	Issue: REMF-MULTIPLE
C00673 00151	∂03-Feb-88  0756	CL-Cleanup-mailer 	New, improved FUNCTION-TYPE-KEY-NAME proposal (version 2)
C00676 00152	∂03-Feb-88  0757	CL-Cleanup-mailer 	Issue: FLET-DECLARATIONS (Version 2)
C00683 00153	∂03-Feb-88  0757	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 4)
C00693 00154	∂03-Feb-88  0757	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE (Version 2)
C00711 00155	∂03-Feb-88  0757	CL-Cleanup-mailer 	New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal (Version 2)
C00713 00156	∂03-Feb-88  0835	CL-Cleanup-mailer 	Issue: EXPORT-IMPORT
C00717 00157	∂03-Feb-88  0951	CL-Cleanup-mailer 	Issue: EXPORT-IMPORT
C00721 00158	∂03-Feb-88  1843	CL-Cleanup-mailer 	Issue: EXPORT-IMPORT
C00724 00159	∂03-Feb-88  1844	CL-Cleanup-mailer 	Issue: EXPORT-IMPORT
C00727 00160	∂03-Feb-88  1857	CL-Cleanup-mailer 	Issue: EXPORT-IMPORT
C00730 00161	∂03-Feb-88  1945	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE (Version 2)
C00738 00162	∂03-Feb-88  2023	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE (Version 2)
C00750 00163	∂04-Feb-88  1529	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE (Version 2)
C00762 00164	∂04-Feb-88  1620	CL-Cleanup-mailer 	cover letter for issues mailing
C00767 00165	∂04-Feb-88  1722	CL-Cleanup-mailer 	Cleanup committee meeting prior to X3J13
C00769 00166	∂05-Feb-88  1241	CL-Cleanup-mailer 	Ready issues
C00776 00167	∂05-Feb-88  1336	CL-Cleanup-mailer 	Re: Ready issues
C00777 00168	∂05-Feb-88  2053	CL-Cleanup-mailer 	EXPORT-IMPORT and the other random commands
C00781 00169	∂05-Feb-88  2056	CL-Cleanup-mailer 	{Improved version} EXPORT-IMPORT and the other random commands
C00786 00170	∂07-Feb-88  1207	CL-Cleanup-mailer 	New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00789 00171	∂07-Feb-88  1224	CL-Cleanup-mailer 	Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2)
C00792 00172	∂07-Feb-88  1242	CL-Cleanup-mailer 	New, improved FUNCTION-TYPE-KEY-NAME proposal (version 2)
C00795 00173	∂07-Feb-88  1300	CL-Cleanup-mailer 	Re: {Improved version} EXPORT-IMPORT and the other random commands
C00799 00174	∂07-Feb-88  1306	CL-Cleanup-mailer 	{Improved version} EXPORT-IMPORT and the other random commands
C00806 00175	∂08-Feb-88  0901	CL-Cleanup-mailer 	New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal
C00808 00176	∂08-Feb-88  1031	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
C00813 00177	∂08-Feb-88  1033	CL-Cleanup-mailer 	Issue: REDUCE-ARGUMENT-EXTRACTION (version 2)
C00815 00178	∂08-Feb-88  1037	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 4)
C00817 00179	∂08-Feb-88  1040	CL-Cleanup-mailer 	Issue: FLET-DECLARATIONS (Version 2)
C00819 00180	∂08-Feb-88  1043	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
C00822 00181	∂08-Feb-88  1051	CL-Cleanup-mailer 	Issue: FLET-DECLARATIONS (Version 2)
C00824 00182	∂08-Feb-88  1058	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE (Version 2)
C00829 00183	∂08-Feb-88  1112	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 1)
C00835 00184	∂10-Feb-88  0203	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE
C00845 00185	∂10-Feb-88  0858	Common-Lisp-Object-System-mailer 	Status of SETF functions in Common Lisp
C00851 00186	∂10-Feb-88  1007	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE (Version 2)
C00859 00187	∂11-Feb-88  1001	Common-Lisp-Object-System-mailer 	Re: Status of SETF functions in Common Lisp
C00862 00188	∂11-Feb-88  1637	CL-Cleanup-mailer 	{Improved version} EXPORT-IMPORT and the other random commands
C00869 00189	∂11-Feb-88  2044	CL-Cleanup-mailer 	Status of SETF functions in Common Lisp
C00873 00190	∂12-Feb-88  0813	CL-Cleanup-mailer 	Package Odor
C00877 00191	∂12-Feb-88  2337	CL-Cleanup-mailer 	Issue: SETF-SUB-METHODS
C00896 00192	∂13-Feb-88  1333	CL-Cleanup-mailer 	Issue: FORMAT-COLON-UPARROW-SCOPE (version 3)
C00905 00193	∂13-Feb-88  1410	CL-Cleanup-mailer 	Issue FUNCTION-TYPE-KEY-NAME, Version 3
C00912 00194	∂13-Feb-88  1428	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
C00921 00195	∂13-Feb-88  1615	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE (version 9)
C00950 00196	∂13-Feb-88  1630	CL-Cleanup-mailer 	Issue: REDUCE-ARGUMENT-EXTRACTION (version 3)
C00956 00197	∂13-Feb-88  1640	CL-Cleanup-mailer 	Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5)
C00969 00198	∂13-Feb-88  1713	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
C00988 00199	∂13-Feb-88  1720	CL-Cleanup-mailer 	New issues to be mailed to X3J13
C00993 00200	∂13-Feb-88  1722	CL-Cleanup-mailer 	Old issues for confirmation at March X3J13
C00997 00201	∂13-Feb-88  1726	CL-Cleanup-mailer 	Pending issues
C01011 00202	∂13-Feb-88  1732	CL-Cleanup-mailer 	Withdrawn issues
C01015 00203	∂13-Feb-88  1808	CL-Cleanup-mailer 	Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
C01018 00204	∂15-Feb-88  0204	CL-Cleanup-mailer 	Common Lisp cleanup issue status to X3J13
C01021 00205	∂15-Feb-88  0928	CL-Cleanup-mailer 	make-lexical-environment
C01025 00206	∂15-Feb-88  0954	CL-Cleanup-mailer 	Re:  make-lexical-environment
C01027 00207	∂15-Feb-88  1634	CL-Cleanup-mailer 	Re: Issue: DO-SYMBOLS-DUPLICATES (Version 3)
C01028 00208	∂15-Feb-88  1713	CL-Cleanup-mailer 	Re: Issue: FORMAT-COMMA-INTERVAL (Version 2)
C01031 00209	∂16-Feb-88  0939	CL-Cleanup-mailer 	FUNCTION-TYPE:STRICT-REDEFINITION proposal
C01033 00210	∂16-Feb-88  1139	CL-Cleanup-mailer 	Re: Issue: FORMAT-COMMA-INTERVAL (Version 2)
C01035 00211	∂17-Feb-88  1159	CL-Cleanup-mailer 	two minor comments: DISASSEMBLE-SIDE-EFFECT & DRIBBLE-TECHNIQUE
C01037 00212	∂19-Feb-88  1434	CL-Cleanup-mailer 	Re: FUNCTION-TYPE:STRICT-REDEFINITION proposal
C01040 00213	∂22-Feb-88  1510	CL-Cleanup-mailer 	Volunteering
C01042 00214	∂23-Feb-88  1115	CL-Cleanup-mailer 	function-type-rest-list-element
C01045 00215	∂23-Feb-88  1115	CL-Cleanup-mailer 	compiler-warning-break
C01049 00216	∂23-Feb-88  1414	CL-Cleanup-mailer 	function-type-rest-list-element
C01056 00217	∂24-Feb-88  0715	CL-Cleanup-mailer 	RE: function-type-rest-list-element
C01066 00218	∂24-Feb-88  1013	CL-Cleanup-mailer 	FUNCTION-TYPE:STRICT-REDEFINITION proposal
C01069 00219	∂24-Feb-88  1459	CL-Cleanup-mailer 	function-type-rest-list-element
C01073 00220	∂25-Feb-88  1047	CL-Cleanup-mailer 	function-type-rest-list-element
C01078 00221	∂27-Feb-88  1818	CL-Cleanup-mailer 	function-type-rest-list-element
C01084 00222	∂28-Feb-88  0807	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE
C01107 00223	∂29-Feb-88  1357	CL-Cleanup-mailer 	function-type-rest-list-element
C01123 00224	∂29-Feb-88  1553	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)
C01137 00225	∂29-Feb-88  2001	CL-Cleanup-mailer 	function-type-rest-list-element
C01141 00226	∂01-Mar-88  1009	CL-Cleanup-mailer 	function-type-rest-list-element
C01146 00227	∂01-Mar-88  1102	CL-Cleanup-mailer 	sequence-functions-exclude-arrays (pardon msg duplication, if any)
C01150 00228	∂01-Mar-88  1124	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)
C01156 00229	∂01-Mar-88  1301	CL-Cleanup-mailer 	Issue: LET-TOP-LEVEL (version 1)
C01163 00230	∂01-Mar-88  1310	CL-Cleanup-mailer 	function-type-rest-list-element (really array types)
C01169 00231	∂01-Mar-88  1318	CL-Cleanup-mailer 	UPGRADE-ARRAY-ELEMENT-TYPE: a sloution for the array TYPEP problem?
C01175 00232	∂01-Mar-88  1325	CL-Cleanup-mailer 	Re: Issue: LET-TOP-LEVEL (version 1)
C01178 00233	∂01-Mar-88  1445	CL-Cleanup-mailer 	function-type-rest-list-element (really array types)
C01181 00234	∂01-Mar-88  1515	CL-Cleanup-mailer 	Compiler cleanup issues, again
C01185 00235	∂01-Mar-88  1548	CL-Cleanup-mailer 	Compiler cleanup issues, again
C01187 00236	∂01-Mar-88  1718	CL-Cleanup-mailer 	Re: Compiler cleanup issues, again
C01191 00237	∂01-Mar-88  1749	CL-Cleanup-mailer 	Issue: LET-TOP-LEVEL (version 1)
C01195 00238	∂01-Mar-88  1830	CL-Cleanup-mailer 	compiler "clean-up" issues
C01197 00239	∂02-Mar-88  0545	CL-Cleanup-mailer 	Re: Issue: LET-TOP-LEVEL (version 1)
C01202 00240	∂02-Mar-88  0553	CL-Cleanup-mailer 	Re: Issue: LET-TOP-LEVEL (version 1)
C01208 00241	∂02-Mar-88  0821	CL-Cleanup-mailer 	Fair's Fair
C01210 00242	∂02-Mar-88  1415	CL-Cleanup-mailer 	Compiler cleanup issues, again
C01214 00243	∂02-Mar-88  1614	CL-Cleanup-mailer 	Re:  Issue: LET-TOP-LEVEL (version 1)
C01224 00244	∂02-Mar-88  1757	CL-Cleanup-mailer 	Issue: LET-TOP-LEVEL (version 1)
C01228 00245	∂02-Mar-88  2206	CL-Cleanup-mailer 	Re: Issue: LET-TOP-LEVEL (version 1)
C01231 00246	∂03-Mar-88  0825	CL-Cleanup-mailer 	Re: Issue: LET-TOP-LEVEL (version 1)
C01235 00247	∂03-Mar-88  1134	CL-Cleanup-mailer 	Re: Issue: LET-TOP-LEVEL (version 1)
C01238 00248	∂03-Mar-88  1204	CL-Cleanup-mailer 	Re: Issue: LET-TOP-LEVEL (version 1)
C01242 00249	∂03-Mar-88  1227	CL-Cleanup-mailer 	Re: Issue: LET-TOP-LEVEL (version 1)
C01246 00250	∂03-Mar-88  1453	CL-Cleanup-mailer 	Issue: LET-TOP-LEVEL (version 1)
C01251 00251	∂03-Mar-88  1456	CL-Cleanup-mailer 	Issue: LET-TOP-LEVEL (version 1)
C01256 00252	∂03-Mar-88  2155	CL-Cleanup-mailer 	Issue: LET-TOP-LEVEL (version 1)
C01263 00253	∂04-Mar-88  0932	CL-Cleanup-mailer 	Re: Compiler cleanup issues, again
C01267 00254	∂04-Mar-88  0940	CL-Cleanup-mailer 	Re: compiler-warning-break
C01270 00255	∂04-Mar-88  1052	CL-Cleanup-mailer 	Re: Issue: LET-TOP-LEVEL (version 1)
C01272 00256	∂04-Mar-88  1140	CL-Cleanup-mailer 	Cleanup subcommittee meeting, Tuesday 15 March, 9:00-12:00
C01274 00257	∂04-Mar-88  1304	CL-Cleanup-mailer 	Issue: LET-TOP-LEVEL (version 1)
C01276 00258	∂04-Mar-88  1414	CL-Cleanup-mailer 	Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
C01278 00259	∂06-Mar-88  1148	CL-Cleanup-mailer 	Re: Issue: LET-TOP-LEVEL (version 1)
C01283 00260	∂06-Mar-88  1203	CL-Cleanup-mailer 	Issue: LET-TOP-LEVEL (version 1)
C01292 00261	∂06-Mar-88  1230	CL-Cleanup-mailer 	Not about Issue: LET-TOP-LEVEL (version 1)
C01304 00262	∂06-Mar-88  1241	CL-Cleanup-mailer 	Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
C01309 00263	∂06-Mar-88  1620	CL-Cleanup-mailer 	Issue: LET-TOP-LEVEL (version 1)
C01321 00264	∂06-Mar-88  1935	CL-Cleanup-mailer 	Issue: LET-TOP-LEVEL (version 1)
C01323 00265	∂07-Mar-88  0637	CL-Cleanup-mailer 	compiler-warning-break
C01327 00266	∂07-Mar-88  0936	CL-Cleanup-mailer 	New issues for the "pending" list, from Japan
C01329 00267	∂07-Mar-88  1030	CL-Cleanup-mailer 	Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01336 00268	∂07-Mar-88  1040	CL-Cleanup-mailer 	Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01338 00269	∂07-Mar-88  1043	CL-Cleanup-mailer 	Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01340 00270	∂07-Mar-88  1059	CL-Cleanup-mailer 	Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01344 00271	∂07-Mar-88  1206	CL-Cleanup-mailer 	Issue: LAMBDA-LIST-DUPLICATES (Version 1)
C01349 00272	∂07-Mar-88  1232	CL-Cleanup-mailer 	Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01356 00273	∂07-Mar-88  1253	CL-Cleanup-mailer 	Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01361 00274	∂07-Mar-88  1257	CL-Cleanup-mailer 	Issue: EVAL-OTHER (Version 1)
C01367 00275	∂07-Mar-88  1324	CL-Cleanup-mailer 	Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1)
C01372 00276	∂07-Mar-88  1325	CL-Cleanup-mailer 	Issue: EVAL-OTHER (Version 1)
C01374 00277	∂07-Mar-88  1326	CL-Cleanup-mailer 	Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01376 00278	∂07-Mar-88  1410	CL-Cleanup-mailer 	Are you coming to the cleanup meeting?
C01377 00279	∂07-Mar-88  1719	CL-Cleanup-mailer 	Issue: EVAL-OTHER (Version 1)
C01379 00280	∂07-Mar-88  2157	CL-Cleanup-mailer 	Issue: [Not Really] LET-TOP-LEVEL (version 1)
C01383 00281	∂07-Mar-88  2216	CL-Cleanup-mailer 	Issue: EVAL-OTHER (Version 1)
C01386 00282	∂08-Mar-88  0723	CL-Cleanup-mailer 	Issue: [Not Really] LET-TOP-LEVEL (version 1)
C01392 00283	∂08-Mar-88  1126	CL-Cleanup-mailer 	Re:  Are you coming to the cleanup meeting?
C01394 00284	∂08-Mar-88  1319	CL-Cleanup-mailer 	Issue: [Not Really] LET-TOP-LEVEL (version 1)
C01397 00285	∂08-Mar-88  1350	CL-Cleanup-mailer 	Issue: LAMBDA-LIST-DUPLICATES (Version 1)
C01399 00286	∂08-Mar-88  1351	CL-Cleanup-mailer 	Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1)
C01401 00287	∂08-Mar-88  1457	CL-Cleanup-mailer 	Issue: [Not Really] LET-TOP-LEVEL (version 1)
C01404 00288	∂08-Mar-88  1712	CL-Cleanup-mailer 	[Now Macros, but formerly] Issue: LET-TOP-LEVEL (version 1)
C01406 00289	∂09-Mar-88  1221	CL-Cleanup-mailer 	Issue: [Not Really] LET-TOP-LEVEL (version 1)
C01410 00290	∂09-Mar-88  1248	CL-Cleanup-mailer 	Re: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
C01415 00291	∂09-Mar-88  1710	CL-Cleanup-mailer 	Issue: [Not Really] LET-TOP-LEVEL (version 1)
C01418 00292	∂09-Mar-88  1711	CL-Cleanup-mailer 	PROCLAIM [and "lexical scoping"?]
C01422 00293	∂11-Mar-88  1031	CL-Cleanup-mailer 	Issue: EVAL-OTHER (Version 1)
C01428 00294	∂11-Mar-88  1039	CL-Cleanup-mailer 	Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1)
C01431 00295	∂11-Mar-88  1043	CL-Cleanup-mailer 	Issue: LAMBDA-LIST-DUPLICATES (Version 1)
C01434 00296	∂11-Mar-88  1045	CL-Cleanup-mailer 	Re: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT
C01438 00297	∂12-Mar-88  1527	CL-Cleanup-mailer 	New issue: STEP-ENVIRONMENT
C01443 00298	∂12-Mar-88  1600	CL-Cleanup-mailer 	New issue: DEFPACKAGE
C01451 00299	∂12-Mar-88  1614	CL-Cleanup-mailer 	New issue: DEFPACKAGE
C01455 00300	∂12-Mar-88  1646	CL-Cleanup-mailer 	New issue: DEFPACKAGE
C01457 00301	∂12-Mar-88  1702	CL-Cleanup-mailer 	Issue: SETF-FUNCTION-VS-MACRO (version 3)
C01460 00302	∂12-Mar-88  1808	CL-Cleanup-mailer 	Issue: LAST-N (Version 2)
C01466 00303	∂13-Mar-88  1637	CL-Cleanup-mailer 	Re: New issue: DEFPACKAGE
C01468 00304	∂14-Mar-88  0007	CL-Cleanup-mailer 	Re: the array type mess....
C01470 00305	∂14-Mar-88  0013	CL-Cleanup-mailer 	Current issue status
C01493 00306	∂14-Mar-88  0110	CL-Cleanup-mailer 	New issue: STEP-ENVIRONMENT
C01496 00307	∂14-Mar-88  0115	CL-Cleanup-mailer 	New issue: DEFPACKAGE
C01499 00308	∂14-Mar-88  0559	CL-Cleanup-mailer 	New issue: DEFPACKAGE
C01502 00309	∂14-Mar-88  0637	CL-Cleanup-mailer 	DEFPACKAGE syntax
C01504 00310	∂18-Mar-88  1405	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
C01511 00311	∂18-Mar-88  1439	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 1)
C01522 00312	∂18-Mar-88  1611	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 1)
C01526 00313	∂18-Mar-88  2051	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
C01528 00314	∂18-Mar-88  2128	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 1)
C01534 00315	∂19-Mar-88  1521	CL-Cleanup-mailer 	FUNCTION-TYPE proposal
C01538 00316	∂21-Mar-88  1121	CL-Cleanup-mailer 	Pending issue status
C01546 00317	∂21-Mar-88  1628	CL-Cleanup-mailer 	Issue: MACRO-FUNCTION-ENVIRONMENT
C01551 00318	∂21-Mar-88  1726	CL-Cleanup-mailer 	RE: Issue: MACRO-FUNCTION-ENVIRONMENT
C01553 00319	∂21-Mar-88  1743	CL-Cleanup-mailer 	Issue: MACRO-FUNCTION-ENVIRONMENT
C01555 00320	∂21-Mar-88  1748	CL-Cleanup-mailer 	Re: Issue: MACRO-FUNCTION-ENVIRONMENT
C01557 00321	∂22-Mar-88  0633	CL-Cleanup-mailer 	cleanup for equal ?
C01559 00322	∂22-Mar-88  0955	CL-Cleanup-mailer 	stream-access background information
C01564 00323	∂22-Mar-88  1025	CL-Cleanup-mailer 	Re: stream-access background information
C01566 00324	∂22-Mar-88  1324	CL-Cleanup-mailer 	RE: stream-access background information
C01569 00325	∂22-Mar-88  1630	CL-Cleanup-mailer 	New "issue" and proposal
C01573 00326	∂22-Mar-88  1649	CL-Cleanup-mailer 	Re: New "issue" and proposal
C01574 00327	∂22-Mar-88  2030	CL-Cleanup-mailer 	Strings as streams
C01576 00328	∂23-Mar-88  1006	CL-Cleanup-mailer 	Strings as streams
C01580 00329	∂23-Mar-88  1048	CL-Cleanup-mailer 	Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
C01584 00330	∂23-Mar-88  1102	CL-Cleanup-mailer 	Issue: MACRO-FUNCTION-ENVIRONMENT
C01586 00331	∂23-Mar-88  1105	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-FILL-POINTER (Version 1)
C01588 00332	∂23-Mar-88  1110	CL-Cleanup-mailer 	Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
C01591 00333	∂23-Mar-88  1117	CL-Cleanup-mailer 	Issue: LAST-N (Version 2)
C01593 00334	∂23-Mar-88  1150	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)
C01604 00335	∂23-Mar-88  1151	CL-Cleanup-mailer 	New issue: DEFPACKAGE
C01615 00336	∂23-Mar-88  1156	CL-Cleanup-mailer 	New issue: DEFPACKAGE
C01617 00337	∂23-Mar-88  1330	CL-Cleanup-mailer 	Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
C01619 00338	∂24-Mar-88  0849	CL-Cleanup-mailer 	Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1)
C01623 00339	∂24-Mar-88  1052	CL-Cleanup-mailer 	Issue SUBSEQ-OUT-OF-BOUNDS
C01628 00340	∂24-Mar-88  1438	CL-Cleanup-mailer 	Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED
C01633 00341	∂25-Mar-88  1411	CL-Cleanup-mailer 	Issue SUBSEQ-OUT-OF-BOUNDS
C01636 00342	∂25-Mar-88  1456	CL-Cleanup-mailer 	Issue SUBSEQ-OUT-OF-BOUNDS
C01639 00343	∂25-Mar-88  2152	CL-Cleanup-mailer 	Issue: WITH-OPEN-STRING-APPEND-STYLE
C01645 00344	∂29-Mar-88  0759	CL-Cleanup-mailer 	Issue SUBSEQ-OUT-OF-BOUNDS, version 2
C01652 00345	∂29-Mar-88  1153	CL-Cleanup-mailer 	Re: Issue: WITH-OPEN-STRING-APPEND-STYLE
C01654 00346	∂29-Mar-88  1608	CL-Cleanup-mailer 	Re: Issue SUBSEQ-OUT-OF-BOUNDS, version 2
C01655 00347	∂29-Mar-88  2140	CL-Cleanup-mailer 	Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
C01661 00348	∂08-Apr-88  0951	CL-Cleanup-mailer 	special var type decls
C01665 00349	∂08-Apr-88  0951	CL-Cleanup-mailer 	special var type decls
C01669 00350	∂08-Apr-88  2242	CL-Cleanup-mailer 	floating point questions
C01679 00351	∂10-Apr-88  1509	CL-Cleanup-mailer 	Issue: REST-ARGUMENT-EXTENT
C01688 00352	∂11-Apr-88  0831	CL-Cleanup-mailer 	Issue: REST-ARGUMENT-EXTENT
C01691 00353	∂11-Apr-88  1032	CL-Cleanup-mailer 	Re: Issue: REST-ARGUMENT-EXTENT
C01694 00354	∂12-Apr-88  0347	CL-Cleanup-mailer 	Issue: REST-ARGUMENT-EXTENT
C01701 00355	∂13-Apr-88  1331	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (version 1)
C01708 00356	∂13-Apr-88  1334	CL-Cleanup-mailer 	[Jim McDonald: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)]
C01719 00357	∂17-Apr-88  1740	CL-Cleanup-mailer 	FORMAT-PRETTY-PRINT
C01720 00358	∂26-Apr-88  2114	CL-Cleanup-mailer 	miscellaneous questions about declarations and type specfiers
C01724 00359	∂13-May-88  0236	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
C01753 00360	∂17-May-88  0213	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)
C01760 00361	∂19-May-88  0042	CL-Cleanup-mailer 	Features
C01762 00362	∂19-May-88  1125	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
C01768 00363	∂19-May-88  1126	CL-Cleanup-mailer 	When is the Cambridge cleanup meeting?????
C01770 00364	∂19-May-88  1136	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
C01777 00365	∂19-May-88  1152	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
C01784 00366	∂19-May-88  1301	CL-Cleanup-mailer 	Re: When is the Cambridge cleanup meeting?????
C01786 00367	∂19-May-88  1354	CL-Cleanup-mailer 	PASSED X3J13 March 1988
C01792 00368	∂19-May-88  1500	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE (version 10)
C01809 00369	∂20-May-88  1914	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)
C01817 00370	∂20-May-88  1921	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE (version 10)
C01819 00371	∂20-May-88  2102	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
C01824 00372	∂21-May-88  0207	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE (version 10)
C01827 00373	∂21-May-88  0247	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
C01831 00374	∂21-May-88  0248	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
C01833 00375	∂21-May-88  0520	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)
C01838 00376	∂21-May-88  0613	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
C01846 00377	∂23-May-88  0828	CL-Cleanup-mailer 	HASH-TABLE-PRINTED-REPRESENTATION
C01853 00378	∂23-May-88  1306	CL-Cleanup-mailer 	Re: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
C01855 00379	∂23-May-88  1329	CL-Cleanup-mailer 	Re: issue FUNCTION-TYPE
C01861 00380	∂23-May-88  1340	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C01881 00381	∂23-May-88  1346	CL-Cleanup-mailer 	Issue: TRACE-FUNCTION-ONLY
C01883 00382	∂23-May-88  1500	CL-Cleanup-mailer 	Issue: TAILP-NIL
C01889 00383	∂23-May-88  1512	CL-Cleanup-mailer 	Re: Issue: TRACE-FUNCTION-ONLY
C01891 00384	∂23-May-88  1525	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
C01894 00385	∂23-May-88  1539	CL-Cleanup-mailer 	Re: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
C01897 00386	∂23-May-88  1544	CL-Cleanup-mailer 	HASH-TABLE-PRINTED-REPRESENTATION
C01900 00387	∂23-May-88  1605	CL-Cleanup-mailer 	Re: New issue: STEP-ENVIRONMENT
C01902 00388	∂23-May-88  1613	CL-Cleanup-mailer 	Re: HASH-TABLE-PRINTED-REPRESENTATION
C01906 00389	∂23-May-88  1613	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
C01918 00390	∂23-May-88  1646	CL-Cleanup-mailer 	Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
C01920 00391	∂23-May-88  1723	CL-Cleanup-mailer 	Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
C01925 00392	∂23-May-88  1727	CL-Cleanup-mailer 	Re: Issue: SPECIAL-VARIABLE-TEST (Version 1)
C01927 00393	∂23-May-88  1741	CL-Cleanup-mailer 	Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
C01937 00394	∂23-May-88  1801	CL-Cleanup-mailer 	Re: Issue: SETF-SUB-METHODS
C01939 00395	∂23-May-88  1819	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
C01942 00396	∂23-May-88  1819	CL-Cleanup-mailer 	Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
C01945 00397	∂23-May-88  1845	CL-Cleanup-mailer 	Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
C01951 00398	∂23-May-88  2212	CL-Cleanup-mailer 	Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
C01958 00399	∂24-May-88  0122	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS
C01968 00400	∂24-May-88  0145	CL-Cleanup-mailer 	Issue: SETF-SUB-METHODS (Version 2)
C01986 00401	∂24-May-88  0204	CL-Cleanup-mailer 	Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
C01989 00402	∂24-May-88  0313	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C01995 00403	∂24-May-88  0602	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 2)
C02025 00404	∂24-May-88  0707	CL-Cleanup-mailer 	Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
C02028 00405	∂24-May-88  0746	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02031 00406	∂24-May-88  0809	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 2)
C02033 00407	∂24-May-88  0906	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS
C02041 00408	∂24-May-88  1021	CL-Cleanup-mailer 	Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
C02044 00409	∂24-May-88  1201	CL-Cleanup-mailer 	Issue: SETF-SUB-METHODS (Version 2)
C02059 00410	∂24-May-88  1210	CL-Cleanup-mailer 	Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
C02061 00411	∂24-May-88  1339	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
C02069 00412	∂24-May-88  1342	CL-Cleanup-mailer 	Re: Issue: STEP-ENVIRONMENT
C02072 00413	∂24-May-88  1356	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)
C02079 00414	∂24-May-88  1400	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
C02081 00415	∂24-May-88  1402	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
C02083 00416	∂24-May-88  1425	CL-Cleanup-mailer 	issue: FUNCTION-TYPE (version 11)
C02102 00417	∂24-May-88  1436	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (version 1)
C02104 00418	∂25-May-88  0726	CL-Cleanup-mailer 	Re: issue: FORMAT-PRETTY-PRINT (version 1)
C02106 00419	∂25-May-88  0747	CL-Cleanup-mailer 	Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02109 00420	∂25-May-88  1202	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02115 00421	∂25-May-88  1321	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS
C02122 00422	∂25-May-88  1618	CL-Cleanup-mailer 	Issue: SETF-SUB-METHODS (Version 2)
C02130 00423	∂25-May-88  1634	CL-Cleanup-mailer 	mail deadline
C02132 00424	∂26-May-88  1146	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (version 2)
C02139 00425	∂26-May-88  1146	CL-Cleanup-mailer 	Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 3)
C02144 00426	∂26-May-88  1146	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 4)
C02157 00427	∂26-May-88  1647	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 4)
C02160 00428	∂26-May-88  1939	CL-Cleanup-mailer 	Issue:	SETF-SUB-METHODS (Version 4)
C02188 00429	∂26-May-88  1945	CL-Cleanup-mailer 	Issue: SETF-SUB-METHODS
C02190 00430	∂26-May-88  2103	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)
C02196 00431	∂27-May-88  0814	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 4)
C02198 00432	∂27-May-88  1815	CL-Cleanup-mailer 	[More on] Issue: DEFPACKAGE
C02202 00433	∂28-May-88  0927	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
C02204 00434	∂28-May-88  1004	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (version 2)
C02208 00435	∂28-May-88  1053	CL-Cleanup-mailer 	Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
C02211 00436	∂28-May-88  1753	CL-Cleanup-mailer 	Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
C02213 00437	∂28-May-88  2039	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
C02215 00438	∂31-May-88  0717	CL-Cleanup-mailer 	Issue: SHARPSIGN-PLUS-MINUS-NUMBER (Version 3)
C02217 00439	∂31-May-88  0814	CL-Cleanup-mailer 	Issue: SPECIAL-VARIABLE-TEST (Version 2)
C02226 00440	∂31-May-88  0840	CL-Cleanup-mailer 	Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 1)
C02230 00441	∂31-May-88  0856	CL-Cleanup-mailer 	Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 4)
C02232 00442	∂31-May-88  1308	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02242 00443	∂31-May-88  1422	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (Version 4)
C02251 00444	∂31-May-88  1438	CL-Cleanup-mailer 	Issue: DISASSEMBLE-SIDE-EFFECT (version 3)
C02255 00445	∂31-May-88  1451	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
C02259 00446	∂31-May-88  1759	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02264 00447	∂31-May-88  2211	CL-Cleanup-mailer 	Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02266 00448	∂01-Jun-88  0120	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02268 00449	∂01-Jun-88  0711	CL-Cleanup-mailer 	Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02270 00450	∂01-Jun-88  1014	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02276 00451	∂01-Jun-88  1037	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02280 00452	∂01-Jun-88  1402	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02285 00453	∂02-Jun-88  2141	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02292 00454	∂02-Jun-88  2141	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02296 00455	∂02-Jun-88  2216	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
C02322 00456	∂03-Jun-88  1048	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02327 00457	∂03-Jun-88  1134	CL-Cleanup-mailer 	Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
C02330 00458	∂07-Jun-88  1255	CL-Cleanup-mailer 	Issue: SPECIAL-VARIABLE-TEST (Version 2)
C02332 00459	∂07-Jun-88  1359	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
C02339 00460	∂07-Jun-88  1429	CL-Cleanup-mailer 	Issue:	SETF-SUB-METHODS (Version 4)
C02343 00461	∂07-Jun-88  1559	CL-Cleanup-mailer 	Cleanup issues -- OK to mail out?
C02345 00462	∂07-Jun-88  1614	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3)
C02347 00463	∂07-Jun-88  1614	CL-Cleanup-mailer 	Issue: WITH-OUTPUT-TO-STRING-APPEND-STYLE (Version 5)
C02354 00464	∂08-Jun-88  1356	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 5)
C02382 00465	∂08-Jun-88  1724	CL-Cleanup-mailer 	Re: Cleanup Committee Mtg?
C02384 00466	∂09-Jun-88  0714	CL-Cleanup-mailer 	Issue: LAST-N (Version 2)
C02386 00467	∂09-Jun-88  0907	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
C02388 00468	∂09-Jun-88  0953	CL-Cleanup-mailer 	Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 2)
C02397 00469	∂09-Jun-88  1525	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE (Version 2)
C02399 00470	∂09-Jun-88  1726	CL-Cleanup-mailer 	Re: X3 subcommittee room
C02401 00471	∂09-Jun-88  2120	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 2)
C02408 00472	∂09-Jun-88  2123	CL-Cleanup-mailer 	X3 subcommittee room
C02410 00473	∂09-Jun-88  2136	CL-Cleanup-mailer 	Issue: HASH-TABLE-PRINTED-REPRESENTATION
C02414 00474	∂09-Jun-88  2314	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-PRINTED-REPRESENTATION
C02416 00475	∂09-Jun-88  2357	CL-Cleanup-mailer 	Re: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 1)
C02418 00476	∂10-Jun-88  0000	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 2)
C02420 00477	∂10-Jun-88  0056	CL-Cleanup-mailer 	Re: Issue:	SETF-SUB-METHODS (Version 4)
C02422 00478	∂10-Jun-88  0159	CL-Cleanup-mailer 	[masinter.pa: Issue: COERCE-INCOMPLETE]
C02446 00479	∂10-Jun-88  0205	CL-Cleanup-mailer 	Issue: FOLLOW-SYNONYM-STREAM
C02452 00480	∂10-Jun-88  0223	CL-Cleanup-mailer 	Issue: FUNCTION-ARGUMENT-TYPE-SEMANTICS]
C02509 00481	∂10-Jun-88  0227	CL-Cleanup-mailer 	[Dan L. Pierson <pierson@mist.ARPA>: Issue: LET-TOP-LEVEL (version 1)]
C02517 00482	∂10-Jun-88  0228	CL-Cleanup-mailer 	Withdrawn issues
C02520 00483	∂10-Jun-88  0231	CL-Cleanup-mailer 	[Masinter.pa: Issue: Pathname-subdirectory-list]
C02535 00484	∂10-Jun-88  0244	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
C02543 00485	∂10-Jun-88  0827	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (version 3)
C02552 00486	∂10-Jun-88  0845	CL-Cleanup-mailer 	Issue: DISASSEMBLE-SIDE-EFFECT (version 4)
C02557 00487	∂10-Jun-88  0904	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE
C02559 00488	∂10-Jun-88  1006	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (version 3)
C02561 00489	∂10-Jun-88  1041	CL-Cleanup-mailer 	Re: Issue: FORMAT-PRETTY-PRINT (version 3)
C02564 00490	∂10-Jun-88  1045	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (version 4)
C02573 00491	∂10-Jun-88  1513	CL-Cleanup-mailer 	Issue:	SETF-SUB-METHODS (Version 4)
C02575 00492	∂10-Jun-88  2016	CL-Cleanup-mailer 	[Dan L. Pierson <pierson@mist.ARPA>: Issue: LET-TOP-LEVEL (version 1)]
C02578 00493	∂12-Jun-88  2142	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE
C02581 00494	∂13-Jun-88  0732	CL-Cleanup-mailer 	Issue: DISASSEMBLE-SIDE-EFFECT (version 4)
C02583 00495	∂17-Jun-88  1754	CL-Cleanup-mailer 	Issue: STREAM-ACCESS (version 1)
C02591 ENDMK
C⊗;
∂28-Nov-87  0534	CL-Cleanup-mailer 	[Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Nov 87  05:34:09 PST
Received: by labrea.stanford.edu; Sat, 28 Nov 87 05:32:29 PST
Received: from bhopal.lucid.com by edsel id AA28590g; Sat, 28 Nov 87 05:26:50 PST
Received: by bhopal id AA17747g; Sat, 28 Nov 87 05:27:53 PST
Date: Sat, 28 Nov 87 05:27:53 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8711281327.AA17747@bhopal.lucid.com>
To: labrea!Dave.Touretzky%C.CS.CMU.EDU@labrea.stanford.edu
Cc: labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: Dave.Touretzky@C.CS.CMU.EDU's message of Mon 16 Nov 87 01:57:08-EST <12350990498.13.TOURETZKY@C.CS.CMU.EDU>
Subject: [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)

There's one sense in which I share Fahlman's reluctance to accept this idea.
It seems to presume that underlying any array whatsoever is a simple
vector of elements that represent the array in dense, row-major order.

In fact, Lucid Common Lisp does just about that (as all the others do too,
I suspect!).  There is even an "internal" function named
'underlying-simple-vector'
to fetch that simple vector.

But the problem is that the simple-vector needn't be "dense" in elements
of the array!  The existence of the function array-row-major-index doesn't
require, for example, that there be no gaps between the rows.  [The
definition on CLtL, p293 is only one possibility --  the one for dense
underlying simple-vectors.]   Rather, it only requires a 1-1 mapping
between the integers {0,1,...(1- <array-total-size>)} and the full set of
multi-dimensional indices.

Your characterization of the relation between arrays and sequences exhibits
the bias towards dense, underlying simple vectors:
Let me restate the basic intuition one more time.  A sequence is like
a string of beads.  If you stretch it out straight you have a list or
vector.  If you fold it up in various ways using COERCE or MAP, you
have an n-dimensional array which you can access with AREF, which is
not a sequence function.  The beads still sit on the string in the same
order, and the sequence functions still give the same result no matter
how you fold the string of beads.  This property is guaranteed by the
existing commitment in CLtL to storing array elements in row-major order.
"Ordering" may be guaranteed by row-major order; but "density" isn't.

Not even the existence of :displaced-index-offset guarantees "density"
(especially if it's value is typically row-aligned anyway), although
I admit that you won't get portable results if you can't assume density.

Until it is decided that a particular implementation of multi-dimensional
arrays is *standard* (as opposed to the functional interface to multi-
dimensional arrays), then Common Lisp implementations should be free
to store the rows of a matrix in any random way that is convenient to
the storage layout of that implementation (e.g., "sparse" storage?).

I must confess that on "stock" hardware, it would be rather inefficient not
to use the dense, row-major odering.  But closing off other implementation
options seems premature, to me; at least until there is evidence of a *great*
win to be had by doing so.

-- JonL --

∂28-Nov-87  1105	CL-Cleanup-mailer 	Issue status
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 28 Nov 87  11:05:33 PST
Received: by labrea.stanford.edu; Sat, 28 Nov 87 11:03:53 PST
Received: from kent-state.lucid.com by edsel id AA29214g; Sat, 28 Nov 87 10:57:29 PST
Received: by kent-state id AA05304g; Sat, 28 Nov 87 10:58:08 PST
Date: Sat, 28 Nov 87 10:58:08 PST
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8711281858.AA05304@kent-state.lucid.com>
To: Masinter.pa@xerox.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 25 Nov 87 17:49 PST <871125-174935-2663@Xerox>
Subject: Issue status

Date: 25 Nov 87 17:49 PST
From: Masinter.pa@Xerox.COM

This isn't quite up to date as I've missed a few, but I thought I should
go ahead and send it out if you're keeping a score card... I think we
have some new members of the distribution list as of the last week or
so...

- SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87)
(Change recommendation for (get-setf-method symbol)?)

the meeting.  Here it is again:

There's a problem with this SETF method for symbols.  Consider the
following simplified version of SETF from p.107 of CLtL:

(DEFMACRO SETF (REFERENCE VALUE)
(MULTIPLE-VALUE-BIND (VARS VALS STORES STORE-FORM ACCESS-FORM)
(GET-SETF-METHOD REFERENCE)
(DECLARE (IGNORE ACCESS-FORM))
(LET* ,(MAPCAR #'LIST (APPEND VARS STORES) (APPEND VALS (LIST VALUE)))
,STORE-FORM)))

This results in the following macrexpansion for (SETF X 1), using the
new SETF method for symbols:

(LET* ((G0002 X)
(G0001 1))
(SETQ X G0001))

The value of G0002 is never used.  The problem is that X might be
unbound, so even just binding it to a local variable will fail.  I
don't think we want to require implementations to eliminate
unnecessary bindings in SETF expansions, just to get correct
semantics.  Nor should each SETF-like macro need a special case when
the location being stored is a symbol.

Unfortunately, I think special handling for symbols is necessary.  If
we keep the SETF method for symbols the way it is in CLtL then we need
to make a special case for symbols in the SETF methods for GETF, LDB
and the like.  If we change the SETF method as proposed here, we need
to make a special case for symbols in SETF and PSETF and any user
defined SETF-like macro that doesn't use the fifth value (ACCESS-FORM)
from GET-SETF-METHOD.

My feeling is that we should go with the new SETF method for symbols,
but describe this problem and point out to implementors that SETF and
PSETF must handle symbols specially, effectively resorting to the old
SETF method.

∂30-Nov-87  0921	CL-Cleanup-mailer 	[Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Nov 87  09:21:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 290628; Mon 30-Nov-87 12:19:35 EST
Date: Mon, 30 Nov 87 12:19 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: Dave.Touretzky@C.CS.CMU.EDU, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <19871130171930.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

Date: Sat, 28 Nov 87 05:27:53 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>

There's one sense in which I share Fahlman's reluctance to accept this idea.
It seems to presume that underlying any array whatsoever is a simple
vector of elements that represent the array in dense, row-major order.
....

That was clearly the intention of Common Lisp, although I note that the
only place in CLtL that says this explicitly is an example on p.289.
It can also be deduced from the definitions of array-total-size and
array-row-major-index, because the range of array-row-major-index's
answer is defined to be a range of integers that contains just enough
members to supply a value for each subscript set, with no gaps.

Since CLtL was not explicit enough to be clear to you, perhaps a cleanup
proposal in the "clarification" category is needed.

∂30-Nov-87  1446	CL-Cleanup-mailer 	Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 30 Nov 87  14:46:37 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Mon, 30 Nov 87 17:46:03 EST
Received: by kali.think.com; Mon, 30 Nov 87 17:45:59 EST
Date: Mon, 30 Nov 87 17:45:59 EST
From: gls@Think.COM
Message-Id: <8711302245.AA00685@kali.think.com>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 20 Nov 87 12:34 PST <871120-123444-1850@Xerox>
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE

Issue: FORMAT-COLON-UPARROW-SCOPE

References:    CLtL p. 406 and also p. 403

Category:      CLARIFICATION

Edit history:  version 1: Guy Steele, 30 November 1987

Problem description:

Implementations currently differ on the question of what is tested by the
FORMAT command "~:↑".  Some implementations test to see whether any
arguments remain in the sublist for the current iteration step; others test
to see whether any sublists remain.  The text on page 406 is not clear
on this point.

Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS):
~:↑ may be used only if the command it would terminate is ~:{ or ~:@{.
The entire iteration process is terminated if and only if the sublist
that is supplying the arguments for the current iteration step is the
last sublist (in the case of ~:{) or the last FORMAT argument (~:@{).
Note that ~:↑ is *not* equivalent to ~:#↑; the latter terminates the
entire iteration if and only if no arguments remain for the current
iteration step.

Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS):
~:↑ may be used only if the command it would terminate is ~:{ or ~:@{.
The entire iteration process is terminated if and only if no more arguments
remain for the current iteration step.  Thus ~:↑ is equivalent to ~:#↑,
just as ~↑ is equivalent to ~#↑.

Test Cases/Examples:

(format nil "~:{~@?~:↑...~}" '(("a") ("b")))

Under proposal FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS
this yields "a...b".

Under proposal FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS
this yields "a".

Rationale:

FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS is desirable
because otherwise there is no way to test whether any sublists remain.
The text on page 406 may be construed to hint at this proposal
indirectly.  To quote Nick Gall:

If one thinks about the intent of the parenthetical

(because in the standard case it tests for remaining arguments of
the current step only)

one should agree that "a...b" will be returned.  In referring to ~↑ as
the "standard case", which tests the arguments remaining in the
current argument sublist, this parenthetical implies that there is
an other case', which tests something else.'  The only other case'
discussed is ~:↑, which therefore must test something else.'  I claim
that the parentheical makes no sense if we interpret ~:↑ as testing
the same condition as ~↑.  If they both test the same condition, why
have the parenthetical explanation?

If ~:↑ doesn't test the same condition as ~↑, then what does it test?
I claim that the only test that makes sense is for ~:↑ to test the
only thing that affects the "entire iteration process:" the number of
sublists.  When there are no more sublists, "the entire iteration
process" is terminated.

FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS is desirable
only because it maintains the equivalence of ~:#↑ and ~:↑ and because
some implementations have been produced that take this approach.

Current practice:

Implementations using FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS
include Symbolics Common Lisp.

Implementations using FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS
include Kyoto Common Lisp, Allegro Common Lisp, GCLISP, and VAXLISP.

Cost to Implementors:

One or the other batch of implementors will have to make a one-line change.

Cost to Users:

It is unlikely that much user code depends on the behavior
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS, but it is
possible.  The author of this writeup (Steele) judges it somewhat more
likely that user code might depend on the behavior
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.

Users would have to be warned not to use ~:↑ in code that is meant to be
portable.

Benefits:

Elimination of yet one more ambiguity.

FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS allows greater
semantic power (there are more things one can test).

FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS maintains an
elegant but useless symmetry.

Esthetics:

Absolutely none.  We're talking about FORMAT here.

Discussion:

Nick Gall favors FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.

Kevin Layer, Rich Robbins, and Robert Poor have spoken in favor of
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS.

Guy Steele strongly prefers the interpretation
FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.

Historical note: Steele first implemented this "feature", in Zetalisp, and
so the code in Symbolics Common Lisp is likely a direct descendant of the
original code.  This might cause some to give weight to Steele's opinion.
There are two arguments against such credence.  First, there is no reason
why the original code should be regarded as part of the specification of
Common Lisp any more than any other implementation; plainly, Steele botched
the specification when he wrote the book.  Second, a professor of
literature (I believe) once told Isaac Asimov concerning a short story of
his (I quote from memory): "Tell me, Dr. Asimov, just because you wrote the
story, what makes you think you know what it means?"

∂30-Nov-87  1733	CL-Cleanup-mailer 	Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Nov 87  17:33:23 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291206; Mon 30-Nov-87 20:33:04 EST
Date: Mon, 30 Nov 87 20:33 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE
To: cl-cleanup@SAIL.STANFORD.EDU
cc: gls@Think.COM
Message-ID: <19871201013304.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

This looks ready for release to me, unless we don't want to release any
discussions containing more than one proposal.  In that case, my vote is
with FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS on the grounds
of its greater expressive power and slightly lower cost to users.

∂30-Nov-87  1911	CL-Cleanup-mailer 	Re: Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Nov 87  19:11:18 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 NOV 87 15:50:53 PST
Date: Mon, 30 Nov 87 15:50:47 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FORMAT-COLON-UPARROW-SCOPE
To: cl-cleanup@sail.stanford.edu
Message-ID: <871130-155053-1317@Xerox>

I also favor FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS.

∂01-Dec-87  0025	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Dec 87  00:25:44 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 NOV 87 15:29:31 PST
Date: 30 Nov 87 15:29 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
To: sandra%orion@cs.utah.edu
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <871130-152931-1269@Xerox>

Charniak, Riesbeck, McDermott and Meehan's "Artificial Intelligence Programming"
, says:

"Also as recommended in Steele, if &REST is given in a FUNCTION type form, the
type that follows &REST refers to the type of each argument that &REST collects,
not to the type of the &REST variable (which is always a list). The definition
of + might begin

(DEFUN + (&REST NUMBERS) ...)

Its type is
(FUNCTION (&REST NUMBER) NUMBER)."

Unfortunately, I've never found the place in CLtL where such a recommendation is

∂01-Dec-87  0038	CL-Cleanup-mailer 	Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87  00:37:55 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291526; Tue 1-Dec-87 11:26:00 EST
Date: Tue, 1 Dec 87 11:25 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE
To: gls@Think.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <871201112532.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I side with TEST-FOR-REMAINING-SUBLISTS because it offers important
flexibility that is otherwise tricky to obtain.

If we can reach consensus within the group, I'd like to see the proposal
rewritten to contain only one proposal.

If we have to retain two proposals, I think the TEST-FOR-REMAINING-ARGUMENTS
is going to need its rationale/benefits beefed up a bit. As it stands,
Steele argues only elegance and then goes on to say later that
aesthetics doesn't count in FORMAT. I don't think this is going to win
many people who are hanging in the balance.

I think the remark about aesthetics not counting at all in FORMAT is cute
but not strictly true. But since I don't have anything more consequential
to write there, I'll suggest the following compromise presentation which
(for the sake of casual readers and future historians) makes it more clear
that we're being flippant -- or at least less clear that we're being
serious...

Aesthetics:

Absolutely none.  We're talking about FORMAT here.'' -- Guy L. Steele, Jr.

∂01-Dec-87  0100	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87  01:00:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291565; Tue 1-Dec-87 11:46:33 EST
Date: Tue, 1 Dec 87 11:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
To: Masinter.pa@Xerox.COM
cc: sandra%orion@cs.utah.edu, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <19871201164614.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

Date: 30 Nov 87 15:29 PST
From: Masinter.pa@Xerox.COM

Charniak, Riesbeck, McDermott and Meehan's "Artificial Intelligence Programming", says:

"Also as recommended in Steele, if &REST is given in a FUNCTION type form, the
type that follows &REST refers to the type of each argument that &REST collects,
not to the type of the &REST variable (which is always a list). The definition
of + might begin

(DEFUN + (&REST NUMBERS) ...)

Its type is
(FUNCTION (&REST NUMBER) NUMBER)."

Unfortunately, I've never found the place in CLtL where such a recommendation is

That's because there isn't one.  Note that the reference was to "Steele", not
to CLtL.  It can be found in document X3J13 / 86-003, a many-times photocopied
5 page document that is apparently entitled "A:>GLS>clarifications.text.4".
A scribble on my copy says "be explicit about &optional, colons; remanded
to declarations committee."  I suppose the declarations committee is one of
those vapor committees that never produces anything?  This seems like a
reasonable thing for the Cleanup committee to address, expanded to cover
all lambda-list keywords in FUNCTION type-specifiers, not just &REST.

∂01-Dec-87  0923	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87  01:00:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291565; Tue 1-Dec-87 11:46:33 EST
Date: Tue, 1 Dec 87 11:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
To: Masinter.pa@Xerox.COM
cc: sandra%orion@cs.utah.edu, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <19871201164614.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

Date: 30 Nov 87 15:29 PST
From: Masinter.pa@Xerox.COM

Charniak, Riesbeck, McDermott and Meehan's "Artificial Intelligence Programming", says:

"Also as recommended in Steele, if &REST is given in a FUNCTION type form, the
type that follows &REST refers to the type of each argument that &REST collects,
not to the type of the &REST variable (which is always a list). The definition
of + might begin

(DEFUN + (&REST NUMBERS) ...)

Its type is
(FUNCTION (&REST NUMBER) NUMBER)."

Unfortunately, I've never found the place in CLtL where such a recommendation is

That's because there isn't one.  Note that the reference was to "Steele", not
to CLtL.  It can be found in document X3J13 / 86-003, a many-times photocopied
5 page document that is apparently entitled "A:>GLS>clarifications.text.4".
A scribble on my copy says "be explicit about &optional, colons; remanded
to declarations committee."  I suppose the declarations committee is one of
those vapor committees that never produces anything?  This seems like a
reasonable thing for the Cleanup committee to address, expanded to cover
all lambda-list keywords in FUNCTION type-specifiers, not just &REST.

∂01-Dec-87  1042	CL-Cleanup-mailer 	Re: Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87  10:42:13 PST
id AA01261; Tue, 1 Dec 87 13:44:29 EST
Message-Id: <8712011844.AA01261@multimax.ARPA>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
Subject: Re: Issue: FORMAT-COLON-UPARROW-SCOPE
<871201112532.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 01 Dec 87 13:44:24 EST
From: Dan L. Pierson <pierson@multimax.arpa> <pierson>

Despite my earlier comments on the common-lisp mailing list, I also
now favor TEST-FOR-REMAINING-ARGUMENTS.  It does gain more power.

∂01-Dec-87  1043	CL-Cleanup-mailer 	Re: Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87  10:43:35 PST
id AA01311; Tue, 1 Dec 87 13:45:51 EST
Message-Id: <8712011845.AA01311@multimax.ARPA>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
Subject: Re: Issue: FORMAT-COLON-UPARROW-SCOPE
<871201112532.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 01 Dec 87 13:45:41 EST
From: Dan L. Pierson <pierson@multimax.arpa> <pierson>

Ooops, make that TEST-FOR-REMIANING-SUBLISTS.  Braino.

∂01-Dec-87  1102	CL-Cleanup-mailer 	Issue:  FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87  11:02:44 PST
id AA12488; Tue, 1 Dec 87 12:02:15 MST
id AA15709; Tue, 1 Dec 87 12:02:09 MST
Date: Tue, 1 Dec 87 12:02:09 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712011902.AA15709@orion.utah.edu>
Subject: Issue:  FUNCTION-TYPE-REST-LIST-ELEMENT
To: cl-cleanup@sail.stanford.edu

Issue:         FUNCTION-TYPE-REST-LIST-ELEMENT
References:    CLtL p.47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Edit history:  Version 1, 23-Nov-1987 Sandra Loosemore
Related issues: FUNCTION-TYPE-KEY-NAME

Problem description:

The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types.  This type specifier uses a
syntax similar to the usual lambda list syntax to specify which types go
with which lambda list variables.  However, this is actually of limited
usefulness in the context of a declaration, where one normally wants type
information about the actual arguments which can be passed to the function
rather than the lambda variables to which they are bound.

There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST.  For the sake of consistency, it would seem
that the corresponding type given in the FUNCTION declaration must also be
LIST, but since this provides no information about the actual arguments,
the type of the actual arguments which are gathered into the list.

CLtL is vague on the issue, mentioning only that &REST may appear in the
type specifier without touching upon its interpretation.

Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):

Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST is the type of each actual argument, not the type of the
corresponding lambda variable.

Test Case:

The type of the function + would be specified as:

(FUNCTION (&REST NUMBER) NUMBER)

Rationale:

This is more useful than specifying that the type of a &REST parameter must
be LIST, since it provides information about the actual arguments.

Current practice:

There does not appear to be any concensus on this issue.  Many Common Lisp
implementations currently ignore FUNCTION type declarations.

Cost to Implementors:

Implementations that ignore the FUNCTION type specifier may continue to do
so.  Probably only a small amount of code would have to be written/changed
in implementations that currently think that the type of the &REST parameter
must be LIST.

Cost to Users:

Users who have been using the convention that the &REST type parameter must
be LIST will have to change their code.  However, because this issue is so
unclear, the FUNCTION type specifier is probably not used very much.

If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.

Benefits:

Adopting the proposal will clear up an area of confusion in the language
design.

Esthetics:

Ugly.  Since the argument type syntax used by the FUNCTION type specifier
mirrors normal lambda-list syntax, it is confusing to make the &REST type
to refer to the types of the actual arguments rather than the type of the
matching lambda variable.

Discussion:

Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:EXTEND-LIST-TYPE):

(1) Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST refers to the type of the corresponding lambda variable and must
be LIST or a subtype of LIST.

(2) Introduce a list form of the LIST type specifier, (LIST <type>), to
specify a list where the value of each successive CAR of the list is a
member of type <type>.

(3) Introduce a list form of the SEQUENCE type specifier, (SEQUENCE <type>),
to specify a sequence where the value of each successive element is a
member of type <type>.

Test Case:

The type of the function + would be specified as:

(FUNCTION (&REST (LIST NUMBER)) NUMBER)

Rationale:

(1) It is clear that a &REST lambda variable must be bound to a list.
Since the FUNCTION type syntax follows lambda-list syntax rather than
function call syntax, it is more consistent to make the type correspond to
the type of the lambda variable rather than that of the actual arguments.

(2) Introducing a list LIST type specifier would allow the FUNCTION type
specifier to be more useful for its intended purpose.  It would also be
useful on its own.  For example, a compiler may be able to optimize
calls to functions such as MAPCAR that operate on successive elements of
a list if information is available about the type of items in the list.
The motivation for making this part of the standard is that the syntax
of the LIST type cannot cannot be extended by user code.

(3) This is an obvious extension of (2).

Current practice:

There does not appear to be any concensus on this issue.  Many Common Lisp
implementations currently ignore FUNCTION type declarations.

Cost to Implementors:

Implementations that ignore the FUNCTION type specifier may continue to
do so.  It should be a fairly straightforward to implement the list
forms of the LIST and SEQUENCE type specifiers.

Cost to Users:

Users who have been using the convention that the &REST type parameter
specifies the type of the actual arguments will have to change their code.
However, because this issue is so unclear, the FUNCTION type specifier is
probably not used very much.

If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.

Benefits:

Adopting the proposal will clear up an area of confusion in the language
design.

Esthetics:

Since the argument type syntax used by the FUNCTION type specifier mirrors
normal lambda-list syntax, it would be cleaner and less confusing to provide
the type of the lambda variable rather than the type of the actual arguments.

Discussion:

-------

∂01-Dec-87  1103	CL-Cleanup-mailer 	Issue:  FUNCTION-TYPE-KEY-NAME
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87  11:03:14 PST
id AA12513; Tue, 1 Dec 87 12:02:44 MST
id AA15714; Tue, 1 Dec 87 12:02:36 MST
Date: Tue, 1 Dec 87 12:02:36 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712011902.AA15714@orion.utah.edu>
Subject: Issue:  FUNCTION-TYPE-KEY-NAME
To: cl-cleanup@sail.stanford.edu

Issue:         FUNCTION-TYPE-KEY-NAME
References:    CLtL p.47-48, 61
Category:      CLARIFICATION, CHANGE
Edit history:  Version 1, 23-Nov-1987 Sandra Loosemore
Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT

Problem description:

The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types.  This type specifier uses a
syntax similar to the usual lambda list syntax to specify which types go
with which lambda list variables.  However, there is a problem with &KEY
lambda variables because keyword arguments may be specified in arbitrary
order in both the the lambda list and the actual argument list.  It is not
possible to match up the types specified in the FUNCTION declaration to
either actual arguments or lambda variables without additional information.

Proposal (FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD):

(1) Specify that the &KEY parameters in a FUNCTION type specifier lambda
list should be supplied as lists of the form (<keyword> <type>).  The
<keyword> must be a symbol in the keyword package.

(2) Allow &ALLOW-OTHER-KEYS to appear in a FUNCTION type specifier lambda
list.

Test Case:

The type of the function SORT could be specified as:

(FUNCTION (SEQUENCE FUNCTION &KEY (:KEY FUNCTION)) SEQUENCE)

Rationale:

(1) This specifies a direct correspondence between the argument type and
its matching keyword.  All of the information is in one place, and the user
does not have to remember (or even know) the order in which &KEY arguments
appear in the actual function definition.

(2) This is probably an oversight in the original specification.

Current practice:

Many Common Lisp implementations currently ignore FUNCTION type
declarations.  The situation regarding type specifications for keyword
arguments is so ambiguous that few users attempt to use them.

Cost to Implementors:

Implementations that ignore the FUNCTION type specifier or keyword arguments
in a FUNCTION type specifier may continue to do so.  This proposal should
not involve massive amounts of code to be rewritten.

Conversion Cost:

Because the current situation is so ambiguous, FUNCTION type specifiers and
particularly the specification of keyword argument types are not widely used.
However, since this is an incompatible change, it would be nice if
implementations  check for, and warn about, old-style usage.

If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.

Benefits:

Adopting the proposal will clear up an area of confusion in the language
design.

Esthetics:

The syntax is fairly obvious and is analogous to the (<keyword> <variable>)
lambda list syntax.

Discussion:

-------

∂01-Dec-87  1201	CL-Cleanup-mailer 	Issue:  FUNCTION-TYPE-KEY-NAME
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87  12:01:16 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 291874; Tue 1-Dec-87 15:00:39 EST
Date: Tue, 1 Dec 87 15:00 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue:  FUNCTION-TYPE-KEY-NAME
To: sandra%orion@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <871201150013.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I am generally sympathetic to the SPECIFY-KEYWORD proposal but can't really
endorse it in its current form because...

* The problem description should make it clear that the problem is not
the keywords can be in any order in the formal and actual argument
lists, but rather just that CLtL is not clear on how the matchup is
specified. It is "possible", it's just not "defined".

* Item one of the proposal should not require that the <keyword> be in
the keyword package since there is a proposal on the floor to loosen
this requirement for keywords. Instead it should state that the <keyword>
must be a valid keyword-name symbol.

* Should we make it explicit that SUPPLIED-P information is either allowed
or disallowed in FUNCTION declarations? (I see no reason to allow it but
maybe I'm overlooking something.)

* The test case is wrong because the word SORT is omitted in the declaration.
This is presumably just a typo.

Also, though, it looks funny because of the :KEY and because the type
FUNCTION is also probably the user's idea of the argument's name. These
"coincidences" don't make the example wrong but make it hard to focus on
the points it's trying to make.

I suggest picking another example. MAKE-LIST comes to mind. eg:

(FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST)

∂01-Dec-87  1756	CL-Cleanup-mailer 	CL-CLEANUP membership
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Dec 87  17:54:06 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 30 NOV 87 11:40:08 PST
Date: 30 Nov 87 11:39 PST
From: Masinter.pa@Xerox.COM
Subject: CL-CLEANUP membership
To: cl-cleanup@Sail.stanford.edu
Message-ID: <871130-114008-117@Xerox>

There are a number of people who are either observers or members of this
subcommittee and were not listed in Mathis' announcement.

> Date: 29 Nov 87 17:22 EST
> Subject: subcommittees
> From: MATHIS@A.ISI.EDU
> To: x3j13@SAIL.STANFORD.EDU
> Message-ID: <[A.ISI.EDU]29-Nov-87 17:22:16.MATHIS>

> here is my version of how the subcommittee evolved at the Ft. Collins

> If you have an electronic mailing list, please let me know and tell
> me how people outside the subcommittee should be involved with that
> list (if at all)

> X3J13 Subcommittees (as of November 29, 1987
> (Mathis, Steele, and Gabriel try to follow all)

> Clean-up
> Larry Masinter
> Guy Steele
> Kent Pitman
> JonL White
> JScott Fahlman
> David Moon
> Ellen Waldrum

Rather than my embarassing myself by misspelling your name or otherwise mangling
the introduction, or including some and not others...  Lets have another round
of mail-check: For those who are not in the list above, please send a brief
message to CL-CLEANUP@SU-AI.STANFORD.EDU, introducing yourself. Please do not

- - - - -
This is the current distribution list for cl-cleanup@Sail.stanford.edu:

rpg

#clclea.msg[com,lsp]

Fahlman@C.CS.CMU.EDU
chiles@C.CS.CMU.EDU
ram@C.CS.CMU.EDU
mcdonald@C.CS.CMU.EDU

gls@THINK.COM

"xerox-cl-cleanup↑.pa"@XEROX.COM
(Brotsky.PA, Daniels.PA, Gregor.PA, Masinter.PA, Pavel.PA, Pedersen.PA)
(redistribution to: "Dieter Kolb:ZTISOF:Siemens")

"hpfclp!dcm"@HPLABS.HP.COM
"hpfclp!cl-technical"@HPLABS.HP.COM

kmp@SCRC-STONY-BROOK.ARPA

Moon@SCRC-STONY-BROOK.ARPA

"edsel!cl-cleanup-dist"@LABREA.STANFORD.EDU

Mathis@C.ISI.EDU
brittain@A.ISI.EDU

mly-lispm@AI.AI.MIT.EDU
JAR-CL@AI.AI.MIT.EDU

"willc%tekchips.tek.com"@RELAY.CS.NET
"Haug%ti-csl"@RELAY.CS.NET
"Waldrum%ti-csl"@RELAY.CS.NET

wjr@SCRC-STONY-BROOK.ARPA

"chapman%aitg.dec"@DECWRL.DEC.COM

pierson@multimax.arpa

"franz!akbar!layer"@ucbarpa.Berkeley.EDU

∂01-Dec-87  2016	CL-Cleanup-mailer 	introduction
Received: from UCBARPA.Berkeley.EDU by SAIL.STANFORD.EDU with TCP; 1 Dec 87  20:16:29 PST
id AA02402; Tue, 1 Dec 87 20:16:38 PST
Received: from akbar by franz (5.5/3.14)
id AA09817; Tue, 1 Dec 87 20:07:56 PST
id AA28657; Tue, 1 Dec 87 20:03:54 PST
From: franz!akbar!layer@ucbarpa.Berkeley.EDU (Kevin Layer)
Return-Path: <akbar!layer>
Message-Id: <8712020403.AA28657@akbar>
To: cl-cleanup@sail.stanford.edu
Subject: introduction
Date: Tue, 01 Dec 87 20:03:53 PST

Hello,
I'm a lisp hacker a Franz Inc. and I'm mainly on the cleanup mailing
list to monitor the activity and pitch in the "current practice" for
our Common Lisp (Allegro CL, used to be Extended Common Lisp).   I
also volunteered to write-up a few issues at the Ft. Collins meeting,
which I'll be getting to soon...

Kevin Layer

ucbvax!franz!layer
layer%franz.uucp@Berkeley.EDU

∂01-Dec-87  2053	CL-Cleanup-mailer 	introduction
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Dec 87  20:53:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 292457; Tue 1-Dec-87 23:22:58 EST
Date: Tue, 1 Dec 87 23:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: introduction
To: Kevin Layer <franz!akbar!layer@ucbarpa.Berkeley.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <19871202042310.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

Date: Tue, 01 Dec 87 20:03:53 PST
From: franz!akbar!layer@ucbarpa.Berkeley.EDU (Kevin Layer)

I'm a lisp hacker a Franz Inc. and I'm mainly on the cleanup mailing
list to monitor the activity and pitch in the "current practice" for
our Common Lisp (Allegro CL, used to be Extended Common Lisp).

Welcome.  I think we've suffered from a lack of coverage in the
"current practice" department, so I'm glad to see you join.

∂02-Dec-87  1008	CL-Cleanup-mailer 	Re: CL-CLEANUP membership
Received: from SCORE.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87  10:08:43 PST
Received: from hplabs.HP.COM by SCORE.STANFORD.EDU with TCP; Wed 2 Dec 87 10:03:14-PST
Received: from hpfcla.HP.COM (hpfcla) by hplabs.HP.COM with SMTP ; Wed, 2 Dec 87 10:08:24 PST
Received: from hpfclp.HP.COM by hpfcla.HP.COM; Wed, 2 Dec 87 10:27:53 mst
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Wed, 2 Dec 87 10:27:35 mst
Received: from hpfcdcm by hpfcdcm.HP.COM; Wed, 2 Dec 87 10:26:14 mst
Return-Path: <dcm@hpfcdcm>
To: cl-cleanup@sail.stanford.edu
Subject: Re: CL-CLEANUP membership
X-Mailer: mh6.5
<871130-114008-117@Xerox>
Date: Wed, 02 Dec 87 10:26:05 MST
Message-Id: <13622.565464365@hpfcdcm>
From: Dave Matthews   <dcm%hpfclp@hplabs.HP.COM>

"hpfclp!dcm"@HPLABS.HP.COM

Dave Matthews of Hewlett Packard. I am following the
conversation and provide current practice information when
appropriate.

"hpfclp!cl-technical"@HPLABS.HP.COM

Pipe to notes system for other reviewers within HP.

Dave

∂02-Dec-87  1119	CL-Cleanup-mailer 	Re: CL-CLEANUP membership
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 2 Dec 87  11:19:09 PST
id AA00566; Wed, 2 Dec 87 14:23:06 EST
Message-Id: <8712021923.AA00566@multimax.ARPA>
To: Masinter.pa@Xerox.COM
Cc: cl-cleanup@Sail.stanford.edu
Subject: Re: CL-CLEANUP membership
<871130-114008-117@Xerox>
Date: Wed, 02 Dec 87 14:23:02 EST
From: Dan L. Pierson <pierson@multimax.ARPA>

I'm Dan Pierson <pierson@multimax.arpa> working on Common Lisp for the
Encore Multimax.  First serial, then parallel (the Multimax is a
shared memory multiprocessor).  I'm currently working on four writeups
for this committee.

∂02-Dec-87  1202	CL-Cleanup-mailer 	intro
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87  12:02:17 PST
Date: Wed,  2 Dec 87 15:05:57 EST
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  intro
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <293701.871202.JAR@AI.AI.MIT.EDU>

I'm Jonathan Rees (JAR@AI.AI.MIT.EDU).  I'm a graduate student at MIT
working on Scheme and related things, and also a consultant for the VAX
(Common) Lisp development group at DEC.

∂02-Dec-87  1421	CL-Cleanup-mailer 	Issue: APPEND-DOTTED (Version 4)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87  14:20:51 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Wed, 2 Dec 87 17:20:07 EST
Received: by kali.think.com; Wed, 2 Dec 87 17:20:03 EST
Date: Wed, 2 Dec 87 17:20:03 EST
From: gls@Think.COM
Message-Id: <8712022220.AA04837@kali.think.com>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 23 Nov 87 12:25 PST <871123-122535-2508@Xerox>
Subject: Issue: APPEND-DOTTED (Version 4)

I support APPEND-DOTTED:REPLACE, version 4.

∂02-Dec-87  1422	CL-Cleanup-mailer 	Issue: ASSOC-RASSOC-IF-KEY (Version 4)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87  14:22:09 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Wed, 2 Dec 87 17:20:55 EST
Received: by kali.think.com; Wed, 2 Dec 87 17:20:50 EST
Date: Wed, 2 Dec 87 17:20:50 EST
From: gls@Think.COM
Message-Id: <8712022220.AA04840@kali.think.com>
To: Masinter.pa@xerox.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 23 Nov 87 12:42 PST <871123-124211-2551@Xerox>
Subject: Issue: ASSOC-RASSOC-IF-KEY (Version 4)

I am indifferent on this issue.

∂02-Dec-87  1528	CL-Cleanup-mailer 	intro
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87  15:28:07 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 DEC 87 14:47:16 PST
Date: Wed, 2 Dec 87 14:31:47 PST
From: Pavel.pa@Xerox.COM
Subject: intro
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <871202-144716-1018@Xerox>

I'm Pavel Curtis (Pavel.pa@Xerox.Com) and I'm currently trying both to finish my
thesis and not to get overly committed to work on any proposals unless there's a
crying need.  I read all of the ones that come across, though.  I expect to be
much more active when the thesis is done, in another couple of months or so.

Pavel

∂02-Dec-87  1941	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 Dec 87  19:41:22 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 2 Dec 87 22:40:45-EST
Date: Wed, 2 Dec 1987  22:40 EST
Message-ID: <FAHLMAN.12355411187.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-cleanup@SAIL.STANFORD.EDU
Cc:   sandra%orion@CS.UTAH.EDU
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
In-reply-to: Msg of 1 Dec 1987  11:46-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>

Rather than introduce some godawful kludge for declaring the type of
&rest lists (only), we should probably try to clean up the inadequacies
of the LIST data-type specification.  There should be some long-form
declaration for LIST that allows you to declare the element-type and
length, similar to the declarations for vectors.

We might or might not want to add a "true list" data type at the same
time.  A "true list" is finite in the CDR direction and terminates in
NIL.  I can forsee some arguments about whether LIST in a declaration
should mean "true list", or whetehr we should give a new name to true
lists.

This is just a trial balloon -- if there is some enthusiasm for this
idea, I'll turn it into a real proposal.  If not, we can go back to
discussing kludges for indicating the element-type in an &REST list.

-- Scott

∂02-Dec-87  2043	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87  20:42:44 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 DEC 87 20:41:08 PST
Date: 2 Dec 87 20:40 PST
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Wed, 2 Dec
87 22:40 EST
To: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871202-204108-1072@Xerox>

I'm tempted to try to address several issues with FUNCTION declarations at once.

1) I realize now that I do not understand the import of *any* of the argument
type specifiers, and specificly the language about "at least of the types
specified" that appears in CLtL p 47. However, I don't know what

(declare (function my-cons (float string) list) )

means. It says that my-cons is a function that can "accept a floating-point
number and a string (among other things), and its result is an object of type
list...."

The problem is that the argument type declaration here is of absolutely no use.
That the declared function can accept a float and a string among other things
has no content. It doesn't say that it is illegal to pass a non-float as the
first argument. It says that if you pass a float, its ok, and if you pass a
non-float, it might be OK too. Isn't that the same as saying (function my-cons
(t t) list)?

It would be more valuable as far as I can see to say that a (function (float
string) list) is one to which *only* a float and a string can be passed. Perhaps
someone familiar with an implementation that pays attention to these
declarations can explain what they are used to denote?

2) On the specific issue at hand: I'm inclined to be more sympathetic to
allowing &REST <element-type>; function type specifiers are, after all, already
a specialized little language -- the &KEY arguments have a separate syntax which
only vaguely resembles the original lambda list syntax, for example.

3) Should the function type specifier also allow &ALLOW-OTHER-KEYS?

Here is some (old) mail from the Common Lisp mailing list which touches on some
related issues:
!
Date: 18 Apr 1986 16:07-EST
Subject: Type Specifier: (OR (FUNCTION ...) ...)
From: NGALL@G.BBN.COM
Question: What is the 'most informative' type specifier for the CL function
COPY-SEQ?

How 'bout? (function (sequence) sequence)

Unfortunately, this does not tell the reader nor the compiler that if the
argument is a list, then the result is also a list, and vice versa.  So how

(or (function (list) list)
(function (vector) vector))

This is syntactically valid CL, and the definition of the OR and FUNCTION type
specifiers makes it meaningful.  Unfortunately, it is not clear from pg. 158
whether or not the following is legal:

(proclaim '(ftype (or (function (list) list)
(function (vector) vector))
copy-seq))

It is not legal in VaxLisp, and my guess is that there aren't any
implementations that would do the right thing with it. So I would like to
propose that such a use of OR/FUNCTION be considered legal CL.

Without such a declaration, one is forced to either wrap (the <result-type> ...)
around all calls to such functions or to DECLARE a restricted version of
FUNCTION in the appropriate places, e.g., (defun foo (alist avector)
(declare (list alist)
(vector avector)
(function copy-seq (list) list))
(zap (copy-seq alist)
(let ()
(declare (function copy-seq (vector) vector))
(zoop (copy-seq avector))))

Either method is a real pain.

My proposal would merely allow a way of describing it.

-- Nick

!
Date: Mon, 4 Nov 85 22:29 EST
From: Daniel L. Weinreb <DLW@SCRC-QUABBIN.ARPA>
Subject: Declaring Functions
To: shebs%utah-orion@UTAH-CS.ARPA, common-lisp@SU-AI.ARPA
Message-ID: <851104222904.2.DLW@CHICOPEE.SCRC.Symbolics.COM>

Date: Fri, 1 Nov 85 13:45:55 MST
From: shebs%utah-orion@utah-cs.arpa (Stanley Shebs)

The notion of a function type is mentioned in two places: p. 47 of the
CLM, where the (function ...) type specifier is defined, and p. 158-159,
where (ftype ...) and (function ...) are defined as options to declare.
Are they intended to be the same?

Read page 159 more carefully.  It explains that they have the same meaning, but
are syntactically different.  "function" has the disadvantage that you can only
declare one thing per clause, unlike most other declarations, but the advantage
that it looks mildly like "defun".

If so, then the second definition
should say that keywords and a (values ...) type specifier are allowed.

If by keywords you mean &optional and friends, it isn't strictly necessary to
repeat that, although it would sure clear things up if there were a cross
reference in the book.

However, there appears to be a typo on page 159.  The form following the phrase
"entirely equivalent to", which currently reads

(ftype (function arglist result-type1 result-type2 ...) name)

(ftype (function arglist (values result-type1 result-type2 ...)) name)

in order to be consistent with page 47.

∂02-Dec-87  2146	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87  21:46:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 DEC 87 21:42:53 PST
Date: Wed, 2 Dec 87 21:42:47 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871202-214253-1099@Xerox>

Larry says:
I don't know what  (declare (function my-cons (float string) list) ) means.''

It is usual in type theory for this to be read as an implication:
IF
you pass a float and a string to MY-CONS
THEN
MY-CONS is guaranteed to return a list.

More rigorously, a type theorist would see (function my-cons (float string)
list) as representing the set of all functions that, when applied to a float and
a string, return a list.

Under this view of types, we understand the constructor OR to be set-union (that
is, the type (OR t1 t2) represents the set of values in the union of the sets
represented by t1 and t2) and the AND constructor is thus set intersection.

Under this view, Nick Gall gives the wrong answer to his question about a
specific type for COPY-SEQ when he claims that a good one would be

(or (function (list) list)
(function (vector) vector))

Since this does not guarantee that COPY-SEQ will return a list when applied to a
list; in fact, a function in this type might very well bomb when presented with
a list.  In general, ORing function types isn't very helpful.  What he really
wants here is AND, not OR:

(and (function (list) list)
(function (vector) vector))

This represents the set of functions that both map lists to lists and vectors to
vectors.

Let me point out that I'm not claiming that this is how CLtL intends function
types to be interpreted, just that this meaning has proven very convenient for
most uses.

Pavel

∂02-Dec-87  2225	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87  22:25:24 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 DEC 87 22:20:29 PST
Date: 2 Dec 87 22:20 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Pavel.pa's message of Wed, 2 Dec 87 21:42:47 PST
To: Pavel.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871202-222029-1111@Xerox>

Under the interpretation outlined in your message, it would not be valid to assume, given

(declare (function my-cons (float string) list) )

that
(typep (my-cons x y) 'list)

can be assumed, unless it was also asserted (declare (float x) (string y))?

∂02-Dec-87  2236	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Dec 87  22:36:45 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 DEC 87 22:36:23 PST
Date: Wed, 2 Dec 87 22:36:17 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871202-223623-1122@Xerox>

That's right.  Unless you know something about the types of the arguments, you
can assume nothing about the type of the result.

Pavel

∂03-Dec-87  0953	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Dec 87  09:53:41 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 294082; Thu 3-Dec-87 12:53:18 EST
Date: Thu, 3 Dec 87 12:52 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871203125256.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Date: 2 Dec 87 20:40 PST
From: Masinter.pa@Xerox.COM

...
(declare (function my-cons (float string) list) )
...
The problem is that the argument type declaration here is of absolutely
no use.
...
It would be more valuable as far as I can see to say that a
(function (float string) list)
is one to which *only* a float and a string can be passed. Perhaps
someone familiar with an implementation that pays attention to these
declarations can explain what they are used to denote?

In Maclisp, if you declared a function to take arguments (fixnum flonum),
for example, special tricks were allowed to be done with passing the arguments
without having to heap-cons them. You were required to only use this declaration
if you had made it available to the compiler at the time of compiling the function
(so that it would have done the special tricks necessary to make the external
calling sequence work). The net effect was that the function had a naive entry
point (for people who didn't know about the declaration) and a magic entry point
for people who wanted to exploit the declaration information and bypass some
setup instructions.

In order to get this effect in CL, we have only to restrict the declaration of
a function to be exactly the declaration that the function was compiled under.
That is, there are a number of possible universes we could elect to be in:

* We could allow local function declarations to just say things we know to
be true, regardless of whether they were interesting. eg,
(PROCLAIM '(FUNCTION FOO (INTEGER) INTEGER))
(DEFUN FOO (X) (+ X 1))
could be matched in another file by
(LOCALLY (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (FIXNUM) FIXNUM)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (T) T)) ... (FOO ...) ...)

This would tend to thwart interesting compilations because nothing in the
declaration would tell you anything useful about how the function was compiled.

* We could allow local function declarations only if they restrict the
declaration under which the function was compiled. eg,
(PROCLAIM '(FUNCTION FOO (INTEGER) INTEGER))
(DEFUN FOO (X) (+ X 1))
could be matched in another file by
(LOCALLY (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (FIXNUM) FIXNUM)) ... (FOO ...) ...)
but not by
(LOCALLY (DECLARE (FUNCTION FOO (T) T)) ... (FOO ...) ...)

This might thwart some interesting compilations because you wouldn't know
everything about the way the function was compiled, but you'd know some
information.

* We could allow local function declarations only if they exactly match
the declaration under which the function was compiled. eg,
(PROCLAIM '(FUNCTION FOO (INTEGER) INTEGER))
(DEFUN FOO (X) (+ X 1))
could be matched in another file by
(LOCALLY (DECLARE (FUNCTION FOO (INTEGER) INTEGER)) ... (FOO ...) ...)
but not by
(LOCALLY (DECLARE (FUNCTION FOO (FIXNUM) FIXNUM)) ... (FOO ...) ...)
or (LOCALLY (DECLARE (FUNCTION FOO (T) T)) ... (FOO ...) ...)

This would have the best chance of getting interesting compilations, I think.

* We could, as I guess Pavel is suggesting (though I lost or missed the
original mail), allow multiple declarations of the same function, in which
case the information provided would be of an entirely different nature (in
what amounts to a DEFMETHOD style) than what it's used for in the previous
three bullet items.

Presumably there are some gains to be had from this style. I have no feel for
how useful they are. An example, though, would be:
(PROCLAIM '(FUNCTION FOO (LIST) LIST))
(PROCLAIM '(FUNCTION FOO (VECTOR) VECTOR))
which would let you compile
(LENGTH (FOO (THE LIST L)))
into
(SYSTEM:LENGTH-ROUTINE-FOR-THINGS-KNOWN-TO-BE-OF-TYPE-LIST (FOO L))

[Sigh. I'd have called it SYSTEM:LIST-LENGTH, but that's taken by CLtL for
something that doesn't mean what I think of as LIST-LENGTH. A poor naming

* This is a placeholder to remind readers that the likelihood that this list is
exhaustive is fairly low.

This really gets at the heart of the problem, which is:

* Are declarations just for compilation or do they serve some more abstract
higher level goal (eg, "documentation").

* How important is exact-typep information vs typep information.

* How much of a modularity violation (or documentation constraint) is it to
have to know the exact conditions under which a function was compiled.

* How important are optimal compilations?

∂03-Dec-87  1042	CL-Cleanup-mailer 	Issue: FORMAT-COLON-UPARROW-SCOPE
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Dec 87  10:42:12 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 3 Dec 87 13:41:26 EST
Received: by kali.think.com; Thu, 3 Dec 87 13:41:22 EST
Date: Thu, 3 Dec 87 13:41:22 EST
From: gls@Think.COM
Message-Id: <8712031841.AA07746@kali.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Tue, 1 Dec 87 11:25 EST <871201112532.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-COLON-UPARROW-SCOPE

Date: Tue, 1 Dec 87 11:25 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
...
I think the remark about aesthetics not counting at all in FORMAT is cute
but not strictly true. But since I don't have anything more consequential
to write there, I'll suggest the following compromise presentation which
(for the sake of casual readers and future historians) makes it more clear
that we're being flippant -- or at least less clear that we're being
serious...

Aesthetics:

Absolutely none.  We're talking about FORMAT here.'' -- Guy L. Steele, Jr.

I would accept this friendly amendment.
--Guy

∂03-Dec-87  1059	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87  10:58:54 PST
id AA20506; Thu, 3 Dec 87 11:57:15 MST
id AA21459; Thu, 3 Dec 87 11:57:05 MST
Date: Thu, 3 Dec 87 11:57:05 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712031857.AA21459@orion.utah.edu>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: Masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu,
sandra%orion@cs.utah.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 3 Dec 87 12:52 EST

One reason for wanting to use a FUNCTION type specifier is that you may
only be concerned with how many arguments a function can take, and you
don't care at all about their types.  Back when we were trying to
implement a CL compatibility package in PSL, we wanted to do the
matching of actual arguments to lambda variables at compile-time so we
could use the EXPR call protocol instead of the much slower NEXPR
protocol.  (Basically, we had an EXPR entry point for every function
with a 1-1 correspondence between actual arguments and lambda
variables.)  The problem is, you couldn't do the transformation on a
call unless you already knew something about the lambda list for the
function.

I agree that the argument type business is confusing and not very useful
in its current state.  I'd like to say that

(LOCALLY (DECLARE (FTYPE (FUNCTION (INTEGER INTEGER) INTEGER) +))
(+ X Y))

is equivalent to

(THE INTEGER (+ (THE INTEGER X) (THE INTEGER Y)))

but I'm not sure that's exactly what CLtL is getting at.

-Sandra
-------

∂03-Dec-87  1059	CL-Cleanup-mailer 	CL-CLEANUP membership
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Dec 87  10:59:19 PST
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Thu, 3 Dec 87 13:58:48 EST
Received: by kali.think.com; Thu, 3 Dec 87 13:58:44 EST
Date: Thu, 3 Dec 87 13:58:44 EST
From: gls@Think.COM
Message-Id: <8712031858.AA07850@kali.think.com>
To: Masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 30 Nov 87 11:39 PST <871130-114008-117@Xerox>
Subject: CL-CLEANUP membership

I am sending this message merely to remark that, inasmuch as my
name *was* on the list Mathis sent out, it is necessary for this
message to contain the word "axolotl" in order to distinguish it
from valid replies to Larry's request.

Sorry, but I could not resist.

--Guy

∂03-Dec-87  1123	CL-Cleanup-mailer 	FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To:   cl-cleanup@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

I'd like to reiterate what Pavel said: the declaration

(declare (function my-cons (float string) list) )

means that the function MY-CONS accepts two arguments, the first at least
of the type FLOAT (it can be a more general type), and the second at least
of the type STRING; it returns one value which is of the type LIST (it
could be more specific).

Unfortunately, it does not mean that if the two arguments are of types
FLOAT and STRING then the result is of type LIST, which would be
useful.

Lucid has a variant of this called RESTRICTIVE-FTYPE (or something),
which would mean MY-CONS assumes it receives two arguments of types
FLOAT and STRING and produces something of type LIST.

See page 47 (CLtL), the last complete paragraph, to see this.

-rpg-

∂03-Dec-87  1215	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from SCRC-YUKON.ARPA by SAIL.STANFORD.EDU with TCP; 3 Dec 87  12:15:27 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 301485; Thu 3-Dec-87 14:17:50 EST
Date: Thu, 3 Dec 87 14:17 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: sandra%orion@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Masinter.pa@xerox.com,
cl-cleanup@sail.stanford.edu
Message-ID: <871203141725.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Date: Thu, 3 Dec 87 11:57:05 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)

One reason for wanting to use a FUNCTION type specifier is that you may
only be concerned with how many arguments a function can take, and you
don't care at all about their types. ...

Thanks for remembering to mention this issue. It pops into my head from time to time
and then I always forget it before I get to the console.

Yes, the same style of issues as I raised in my last message applies to argument
number. eg, if I did

(PROCLAIM '(FUNCTION FOO (NUMBER NUMBER) NUMBER))
(DEFUN FOO (X Y) (+ X Y))

and later did:

(LOCALLY (DECLARE (FUNCTION FOO (FIXNUM &REST (LIST T)) FIXNUM)) ... (FOO ...) ...)

would I be within reason? ie, is there semantic impact to the &REST which goes beyond
type declaring the rest of the arguments to be of type T? Am I also declaring that the
function was in fact compiled believing that a &REST style argument pickup was used
(and at the same point as I've specified it here). What about:

(PROCLAIM '(FUNCTION FOO (NUMBER &REST (LIST NUMBER)) NUMBER))
(DEFUN FOO (X &REST Y) (APPLY #'+ X Y))
and then later
(LOCALLY (DECLARE (FUNCTION FOO (NUMBER NUMBER &REST (LIST NUMBER)) NUMBER))
... (FOO ...at least two arguments...) ...)

In my CL conversion of Macsyma, I threw out all the *LEXPR declarations because
CL couldn't make any use of them and they were just clutter. (And they'd be trivial
to re-conjure if they were ever needed.) But I felt funny as I did it because I did
know I was throwing away information that would be interesting to some compilers
and that seemed sad, so I definitely agree that one way or another, this is a real
issue.

∂03-Dec-87  1331	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Dec 87  13:31:12 PST
Received: ID <RAM@C.CS.CMU.EDU>; Thu 3 Dec 87 16:30:32-EST
Date: Thu, 3 Dec 1987  16:30 EST
Message-ID: <RAM.12355605918.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>, cl-cleanup@SAIL.STANFORD.EDU,
Masinter.pa@XEROX.COM, sandra%orion@CS.UTAH.EDU
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Msg of 3 Dec 1987  12:52-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>

My compiler cleanup proposal addresses a number of the issues being
meaning function type.

In my initial proposal, I had assumed a strict interpretation of
function type.  It was pointed out to me, that not only is CLTL very
clear about its non-restrictive interpretation, it is also very
difficult to use a strict interpretation within the framework of the
current type system.

Basically, the problem is that if you think about "function type
declarations" as being declarations about the type of the object which
is the function, then it isn't possible to use a strict
interpretation.  If you attempt to do so, then there will be cases
where a type declaration is necessary for a program to be correct, and
removing declarations can cause a program to be incorrect.  In
addition to problems with defining where declarations are necessary,
requiring declarations is also clearly in conflict with the stated
goals for declarations in Common Lisp.

Basically, the reason for this non-intuitive result is that a
declaration of a function's type actually makes a statement about what
definitions are legal, rather than what calls are legal.  What a
compiler really wants to know is what calls are legal.

The solution I suggest in my proposal is to introduce a mechanism that
allows arbitrary information about a function definition to be bound
at compile time.  You don't declare the function type, you just define
the function, with any appropriate argument type declarations.
Since you have asserted that calls to the function can be bound at
compile time, the compiler can apply any assertions on the formal
parameters to the actual parameters and use type information derived
from the definition as the type of the call result.

Early-binding of function names also allows many other optimizations
such as "inline expansion" and "block compilation".

Before people flame uncotrollably about the horror of static function
binding in Lisp, I will point out that I don't propose that static
function binding be required, or even that it necessarily be the
default.  It is also worth noting that the extent to which static
binding is actually done once it has been allowed is an implementation
decision.  Declaring static binding doesn't necessarily prevent
incremental redefintion or reduce safety, it might only cause better
compiler warnings to be generated.

If this capability exists, then function type declarations (and
function types) are more useless than they currently are (if that is
even possible).

Rob

P.S.  My proposal is <ram>cprop.txt on c.cs.cmu.edu

∂04-Dec-87  1430	CL-Cleanup-mailer 	Issue: LAST-N (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Dec 87  14:30:43 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 295555; Fri 4-Dec-87 16:49:13 EST
Date: Fri, 4 Dec 87 16:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAST-N (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <871204164910.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        LAST-N
References:   LAST (p267)
Category:     ENHANCEMENT
Edit history: 04-Dec-87, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

People always ask why LAST returns a cons and not an element.

BUTLAST takes an argument N but LAST does not.

Proposal (LAST-N:ALLOW-OPTIONAL-ARGUMENT):

Allow LAST to take an optional argument N, saying how many cells to return.

It is an error if N is negative or L is circular.

If N is equal to the number of cons cells in the list L, then the atom which
terminates the list L is returned.

If N is greater than the number of cons cells in the list L, then it is an
error if the list is not a proper list. If in this case the list is a proper
list, then L is returned.

Test Cases:

(LAST    '(A B C) 0) => ()
(BUTLAST '(A B C) 0) => (A B C)

(LAST    '(A B C) 1) => (C)
(BUTLAST '(A B C) 1) => (A B)

(LAST    '(A B C) 2) => (B C)
(BUTLAST '(A B C) 2) => (A)

(LAST    '(A B C) 3) => (A B C)
(BUTLAST '(A B C) 3) => ()

(LAST    '(A B C) 4) => (A B C)
(BUTLAST '(A B C) 4) => ()

(LAST    '(A B C))   => (C)
(BUTLAST '(A B C))   => (A B)

(LAST '(A . B) 0)    => B
(LAST '(A . B) 1)    => (A . B)
(LAST '(A . B) 2)    is an error.

Rationale:

BUTLAST and LAST would select complementary parts of a list in general.
That is (EQUAL L (APPEND (BUTLAST L N) (LAST L N))) would be T for N >= 0
and L being a proper list.

This would make it more obvious why LAST should return a list and not
an element. ie, it would return the "last N elements" where N=1 by default.

Current Practice:

Probably nobody does this.

Very slight. The following code would suffice:

(DEFUN LAST (LIST &OPTIONAL (N 1))
(CHECK-TYPE N (INTEGER 0))
(DO ((L LIST (CDR L))
(R LIST)
(I 0 (+ I 1)))
((ATOM L) R)
(IF (>= I N) (POP R))))

Some implementations might want to provide compiler optimizations for
the N=1 case.

Benefits:

This utility is probably needed often enough to warrant its inclusion.
It's present (as a separate function called NLEFT) in Symbolics Common
Lisp and Interlisp.

Conversion Cost:

None. This is an upward compatible extension.

Aesthetics:

This would make things a little prettier.

Discussion:

This suggestion came up recently on a Symbolics design discussion list.
Symbolics is contemplating offering it as an extension, but it seemed like
the rest of the CL community might want to adopt it, too.  Pitman thinks
it's a nice idea.

∂04-Dec-87  1449	CL-Cleanup-mailer 	Issue: LAST-N (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 Dec 87  14:49:42 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 4 Dec 87 17:49:16-EST
Date: Fri, 4 Dec 1987  17:49 EST
Message-ID: <FAHLMAN.12355882409.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: LAST-N (Version 1)
In-reply-to: Msg of 4 Dec 1987  16:49-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>

Seems harmless enough...  No strong opinion one way or the other.

-- Scott

∂04-Dec-87  1535	CL-Cleanup-mailer 	Issue: LAST-N (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Dec 87  15:35:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 295702; Fri 4-Dec-87 18:35:08 EST
Date: Fri, 4 Dec 87 18:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAST-N (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <19871204233526.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

Date: Fri, 4 Dec 87 16:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

Issue:        LAST-N
References:   LAST (p267)
Category:     ENHANCEMENT
Edit history: 04-Dec-87, Version 1 by Pitman
Proposal (LAST-N:ALLOW-OPTIONAL-ARGUMENT):

Allow LAST to take an optional argument N, saying how many cells to return.

You should say explicitly that the default for N is 1.

The following two paragraphs cannot be correct.  For example, think about
(last '(a)), which you are saying returns nil.

If N is equal to the number of cons cells in the list L, then the atom which
terminates the list L is returned.

If N is greater than the number of cons cells in the list L, then it is an
error if the list is not a proper list. If in this case the list is a proper
list, then L is returned.

I think what you really mean is

If N is zero, then the atom that terminates the list L is returned.
If N is greater than or equal to the number of cons cells in
the list L, then the result is L.

This correction makes it consistent with your examples.

With these corrections, I don't oppose the proposal.  I'm not strongly in
favor of it, since I put less priority on enhancements than on correcting
mistakes in what we've got already.  I'll favor it if others do.

∂04-Dec-87  1729	CL-Cleanup-mailer 	Re: Issue: LAST-N (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Dec 87  17:28:54 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 DEC 87 15:35:33 PST
Date: 4 Dec 87 15:35 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: LAST-N (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Fri, 4 Dec 87 16:49 EST
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <871204-153533-228@Xerox>

I don't much care. It basically looks OK.

-- Andy. --

∂04-Dec-87  1729	CL-Cleanup-mailer 	Introduction
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Dec 87  17:29:01 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 04 DEC 87 15:38:37 PST
Date: 4 Dec 87 15:38 PST
From: Daniels.pa@Xerox.COM
Subject: Introduction
To: cl-cleanup@Sail.stanford.edu
Message-ID: <871204-153837-228@Xerox>

Hello all. I'm a senior developer with Xerox's AI group. I'm also one of the two
members of the error system subgroup. I'm on this particular list mainly to keep
an eye on the accepted cleanups and changes and make sure our implementation
conforms.

For the most part, other people seem to adequately cover the space of things
I've wanted to say, so you're not likely to see much mail from me.

-- Andy. --

∂05-Dec-87  0001	CL-Cleanup-mailer 	Introduction
Received: from UUNET.UU.NET by SAIL.STANFORD.EDU with TCP; 5 Dec 87  00:01:45 PST
Received: from unido.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA28402; Sat, 5 Dec 87 03:01:28 EST
Sat, 5 Dec 87 08:30:41 +0100
From: "Dieter Kolb" <unido!ztivax!kolb@uunet.UU.NET>
Date: Fri, 4 Dec 87 16:12:40 -0100
Message-Id: <8712041512.AA03656@ztivax.uucp>
Received: by ztivax.uucp; Fri, 4 Dec 87 16:12:40 -0100
To: CL-Cleanup@sail.stanford.edu
Subject: Introduction

I am Dieter Kolb of Siemens AG, West Germany. In my group we
are developing a Common LISP system for Siemens computers.
I am also member of the EuLisp group in Europe.

I am following the conversion on CL-Cleanup to get information
for our implementation activities as well as to provide discussion
contributions based on our experience with the language.

Dieter Kolb
Siemens AG
ZTI SOF 23
Otto Hahn Ring 6
D-8000  Munich 83

Phone: +49-89-636-2386

∂06-Dec-87  1424	CL-Cleanup-mailer 	Issue: DRIBBLE-TECHNIQUE (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 6 Dec 87  14:24:29 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 296206; Sun 6-Dec-87 17:14:51 EST
Date: Sun, 6 Dec 87 17:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DRIBBLE-TECHNIQUE (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <871206171357.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        DRIBBLE-TECHNIQUE
References:   DRIBBLE (p443)
Category:     CLARIFICATION
Edit history: 06-Dec-87, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

The intent and effect of DRIBBLE is not very clearly specified.

Proposal (DRIBBLE-TECHNIQUE:MAKE-EXPLICITLY-VAGUE):

Clarify that DRIBBLE is intended primarily for interactive debugging
and that its effect cannot be relied upon from programs.

Test Case:

#1: (PROGN (DRIBBLE "temp")
(PRINT 'FOO)
(DRIBBLE))

#2: (DRIBBLE "temp")
(PROGN (PRINT 'FOO)
(DRIBBLE)
(PRINC 'BAR))

Rationale:

Users of DRIBBLE have been surprised about how differently DRIBBLE
behaves in different implementations. This makes the status quo
much more explicit and will lead to less surprise.

Current Practice:

Some implementations implement DRIBBLE as a function which simply
assigns streams such as *STANDARD-OUTPUT* to broadcast streams
(or the approximate equivalent thereof).  Even within this camp,
However, typically test case #1 will capture the output of (PRINT 'FOO)
in the file "temp" and will execute (PRINT 'BAR) but not capture its
output.

Some implementations (eg, Symbolics) push to a recursive command
loop when DRIBBLE is called with an argument, and return from that
command loop when DRIBBLE is called with no argument. In these
implementations, test case #1 will enter a recursive command loop
upon the first call to DRIBBLE and will not execute the (PRINT 'FOO)
until (DRIBBLE) is done interactively. When the second (DRIBBLE)
in test case #1 is executed, DRIBBLE will complain that output is
not currently being recorded. In test case #2, the output of
(PRINT 'FOO) will be captured, but the form (PRINT 'BAR) will never
be executed because (DRIBBLE) does not return normally (it throws).

None. This is just a clarification.

Benefits:

Users will be aware that they cannot rely on DRIBBLE in portable code.

Conversion Cost:

Effectively none.  Anyone who currently uses DRIBBLE in code that is
believed to be portable is kidding himself. If such code works in some
implementations, it can continue to work.

Aesthetics:

Since this is a clarification, there is no significant change to
the aesthetics.

Discussion:

Pitman wrote this proposal as a straw man so that CL-Cleanup would have
the issue on the books for explicit discussion.

∂06-Dec-87  1435	CL-Cleanup-mailer 	Introduction
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Dec 87  14:35:08 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 DEC 87 14:35:09 PST
Date: 6 Dec 87 14:28 PST
From: pedersen.pa@Xerox.COM
Subject: Introduction
To: CL-Cleanup@sail.stanford.edu
Message-ID: <871206-143509-2198@Xerox>

Hi,

My name is Jan Pedersen and I work for Xerox as a Xerox Lisp developer and as a
member of the Natural Language group at PARC. I'm on the CL-Cleanup list as an
observer since it is high priority here to maintain strict adherance with the
Common Lisp specification.

J.P.

∂07-Dec-87  1643	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 7 Dec 87  16:43:00 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 07 DEC 87 15:23:50 PST
Date: 7 Dec 87 14:40 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Ram@C.CS.CMU.EDU's message of Thu, 3 Dec 87 16:30 EST
To: Ram@C.CS.CMU.EDU
cc: KMP@SCRC-STONY-BROOK.ARPA, cl-cleanup@SAIL.STANFORD.EDU,
Masinter.pa@Xerox.COM, sandra%orion@CS.UTAH.EDU
Message-ID: <871207-152350-3643@Xerox>

Ram: I've scanned your latest proposal, but it still doesn't seem to address the
minor issue at hand here:

What does
(declare (function (integer integer) t) foo)
imply?

We've discussed what it could mean, what it should mean, what CLtL says it
means, but I'd to hear about current practice. What, if anything,  do current
implementations do with such declarations? Do any implementations pay attention
to the types of arguments in function declarations?

∂07-Dec-87  2038	CL-Cleanup-mailer 	[Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87  20:38:02 PST
Received: by labrea.stanford.edu; Mon, 7 Dec 87 20:31:59 PST
Received: from bhopal.lucid.com by edsel id AA02700g; Mon, 7 Dec 87 18:22:09 PST
Received: by bhopal id AA01347g; Mon, 7 Dec 87 18:22:31 PST
Date: Mon, 7 Dec 87 18:22:31 PST
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8712080222.AA01347@bhopal.lucid.com>
To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu
Cc: labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 30 Nov 87 12:19 EST <19871130171930.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: [Density?] SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)

re: It [density] can also be deduced from the definitions of array-total-size
and array-row-major-index, because the range of array-row-major-index's
answer is defined to be a range of integers that contains just enough
members to supply a value for each subscript set, with no gaps.
I think my previous note mentioned that density in storage isn't actually
required by this bijective mapping -- it would only do so if the output
of array-row-major-index were required to be a memory index.

Perhaps one couldn't imagine any other meaning for array-row-major-index
other than "index offset from base memory location"; but CLtL doesn't
say this now, and I can certainly think of alternative representations
which would reinject the "linearized" index into the multi-dimensional
format simply in order to preserve the documented property.

If any clarification is necessary, then it ought to take into account
the AREF-1D proposal, which would raise some efficiency questions if the
bijective mapping weren't "index-offset" memory access.

-- JonL --

∂07-Dec-87  2310	CL-Cleanup-mailer 	introduction
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 7 Dec 87  23:10:18 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa03665; 8 Dec 87 0:33 EST
Received: from csc.ti.com by RELAY.CS.NET id ac17859; 8 Dec 87 0:29 EST
Received: from ERDOS by tilde id AA29927; Mon, 7 Dec 87 19:20:20 CST
To: cl-cleanup@SAIL.STANFORD.EDU
Cc:
From: HAUG%erdos.csc.ti.com@RELAY.CS.NET
Subject:        introduction
Date:           7-Dec-87 19:15:55
Sender: HAUG%erdos.csc.ti.com@RELAY.CS.NET
Message-Id:     <HAUG.2774913353@ERDOS>

My name is David Haug and I work for the Symbolic Computing group at TI
and did a lot of work for the Explorer project. My participation in the
CL-cleanup group  has been as an observer to keep track of changes to
the language. However, my observer status will change if I am
sufficiently stirred.

--------- DHaug

∂07-Dec-87  2315	CL-Cleanup-mailer 	Issue: DRIBBLE-TECHNIQUE (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Dec 87  23:15:06 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 8 Dec 87 01:45:15-EST
Date: Sun, 6 Dec 1987  22:57 EST
Message-ID: <FAHLMAN.12356462749.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: DRIBBLE-TECHNIQUE (Version 1)
In-reply-to: Msg of 6 Dec 1987  17:13-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>

I support DRIBBLE-TECHNIQUE:MAKE-EXPLICITLY-VAGUE.

I'm not sure exactly what KMP means by stating that this proposal is a
straw man, but I like it.  I think that it was a mistake to put dribble
into the manual, and that we should just tell users that it differs from
system to system.  I don't think that there's any hope of getting a
standard that makes sense on editor-top-level systems, dumb
Read-Eval-Print systems, and all the flavors in between, so we should
just punt on this.

The only advantage of mentioning DRIBBLE in the standard at all is that
users know what name to look up in any given system to get this general
sort of functionality.

-- Scott

∂07-Dec-87  2328	CL-Cleanup-mailer 	Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 7 Dec 87  23:24:56 PST
id AA01737; Mon, 7 Dec 87 18:37:22 EST
Message-Id: <8712072337.AA01737@multimax.ARPA>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Date: Mon, 07 Dec 87 18:37:19 EST
From: Dan L. Pierson <pierson@multimax.ARPA>

Issue:         REDUCE-ARGUMENT-EXTRACTION
References:    REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut structure (pp. 312-313),
DELETE-IF-NOT, REMOVE-DUPLICATES, DELETE-DUPLICATES, SUBSTITUTE,
SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF,
NSUBSTITUTE-IF-NOT, FIND, FIND-IF, FIND-IF-NOT, POSITION,
POSITION-IF, POSITION-IF-NOT, COUNT, COUNT-IF, COUNT-IF-NOT,
MISMATCH, SEARCH, SORT, STABLE-SORT, MERGE (pp. 253-261),
SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT,
SUBLIS, NSUBLIS, MEMBER, MEMBER-IF, MEMBER-IF-NOT (pp. 273-275),
SET-DIFFERENCE, NSET-DIFFERENCE, SET-EXCLUSIVE-OR,
NSET-EXCLUSIVE-OR, SUBSETP (pp. 276-279),
ASSOC, ASSOC-IF, ASSOC-IF-NOT, RASSOC, RASSOC-IF, RASSOC-IF-NOT
(pp. 280-281)
Edit history:  Version 1 by Pierson 12/5/87
Issue:         For Internal Discussion

Problem description:

REDUCE is the only one of the Common Lisp functions that modify or
search lists and sequences which does not accept a :KEY argument.
This complicates many uses of REDUCE.

Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):

Change the definition of REDUCE to take a :KEY keyword.

Test Cases/Examples:

Using REDUCE to obtain the total of the ages of the possibly empty
sequence of astronauts ASTROS, would currently require:

(REDUCE #'(LAMBDA (&OPTIONAL (X 0) (Y 0)) (+ (PERSON-AGE X) (PERSON-AGE Y)))
ASTROS)

If this proposal is adopted, the same result could be obtained with:

(REDUCE #'+ ASTROS :KEY #'PERSON-AGE)

Rationale:

This proposal brings REDUCE into line with the rest of the sequence
and list modifying and searching functions at the cost of slightly
blurring the meaning of :KEY arguments.

Current practice:

Does anyone currently support this as an extension?

Cost to Implementors:

This will require most implementations to make a trivial modification
to REDUCE.  Implementations which wish to use this as an opportunity to
further optimize compiled calls to REDUCE will have to undertake more
work (which would be much more difficult today).

Cost to Users:

None, this is an upward compatible extension.

REDUCE will continue to be more difficult to use than other sequence
functions on sequences of complex objects.

Benefits:

REDUCE will become easier to use on sequences of complex objects.  It
will be easier for compilers to convert some calls to REDUCE into
efficient loops.

Aesthetics:

Slightly damaged.  All :KEY arguments are currently defined to be used
for predicates, this proposal will implicitly broaden :KEY to support
general extraction for any purpose.

Discussion:

Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY.  No one has objected
to this change in the recent round of discussions.

∂08-Dec-87  0021	CL-Cleanup-mailer 	Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 87  00:20:56 PST
id AA01767; Mon, 7 Dec 87 18:40:50 EST
Message-Id: <8712072340.AA01767@multimax.ARPA>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Date: Mon, 07 Dec 87 18:40:46 EST
From: Dan L. Pierson <pierson@multimax.ARPA>

Issue:         DISASSEMBLE-SIDE-EFFECT
References:    DISASSEMBLE (p. 439), COMPILE (p. 439)
Category:      CLARIFICATION
Edit history:  Version 1 by Pierson 12/2/87
Status:        For Internal Discussion

Problem description:

The definition of DISASSEMBLE says that "if the relevant function is
not a compiled function, it is first compiled.".  The definition of
COMPILE says that "If name is a non-nil symbol, then the
compiled-function is installed as the global function definition of
the symbol...".  Several implementations have taken this to mean that
if DISASSEMBLE is passed a symbol which has an uncompiled function
definition, then it has the side-effect of (COMPILE 'symbol).

Proposal (DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL):

Clarify that when DISASSEMBLE compiles a function, it will never
install the newly compiled function.

Test Cases/Examples:

(DEFUN F (A) (1+ A))
(DISASSEMBLE 'F)
(TYPEP (SYMBOL-FUNCTION 'F) 'COMPILED-FUNCTION)

This code will return NIL if this proposal is adopted.  Some current
implementations will return T, some will return NIL.

Rationale:

Several current implementations of DISASSEMBLE have surprising side
effects, especially for new users.

Current practice:

Allegro CL, Symbolics, and Vax Lisp install the compiled definition.
Lucid and KCL don't install it.  [[This is from an informal survey at
the last meeting; please correct any mistakes.]]

Cost to Implementors:

Some implementations will have to make a simple change.

Cost to Users:

Very little.  DISASSEMBLE is really part of the environment and is
probably not called by much, if any user code.

DISASSEMBLE will continue to surprise less experienced users.

Benefits:

DISASSEMBLE will become the predictable debugging function it was
meant to be.

Aesthetics:

Those who thought DISASSEMBLE was supposed to install the compiled
function may find that the language has become a little cleaner.

Discussion:

∂08-Dec-87  0728	CL-Cleanup-mailer 	Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87  07:28:44 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 8 Dec 87 10:27:51-EST
Date: Tue, 8 Dec 1987  10:27 EST
Message-ID: <FAHLMAN.12356850608.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   "Dan L. Pierson" <pierson@MULTIMAX.ARPA>
Cc:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
In-reply-to: Msg of 7 Dec 1987  18:40-EST from Dan L. Pierson <pierson at multimax.ARPA>

I support DO-NOT-INSTALL.

∂08-Dec-87  0857	CL-Cleanup-mailer 	Introduction
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87  08:51:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 08:41:54 PST
Date: 8 Dec 87 08:41 PST
From: Brotsky.pa@Xerox.COM
Subject: Introduction
To: CL-Cleanup@sail.stanford.edu
cc: Brotsky.pa@Xerox.COM
Message-ID: <871208-084154-4763@Xerox>

I'm Dan Brotsky.  I used to be at the MIT AI Lab and now I'm at Xerox PARC. I've
been fighting for years to clean up the entire first half of the alphabet,
concentrating so far primarily on the letters A, B, and M.  So (as you might
imagine) I'm quite excited about participating in an effort directed at the
other 10.

dan

∂08-Dec-87  0937	CL-Cleanup-mailer 	Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 87  09:37:06 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 297870; Tue 8-Dec-87 12:36:31 EST
Date: Tue, 8 Dec 87 12:36 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
To: pierson@MULTIMAX.ARPA
cc: cl-cleanup@sail.stanford.edu
Message-ID: <871208123627.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I mostly approve of the proposal contained in this write-up, though I have

Date: Mon, 07 Dec 87 18:40:46 EST
From: Dan L. Pierson <pierson@multimax.ARPA>

Issue:         DISASSEMBLE-SIDE-EFFECT
...
Test Cases/Examples:

(DEFUN F (A) (1+ A))
(DISASSEMBLE 'F)
(TYPEP (SYMBOL-FUNCTION 'F) 'COMPILED-FUNCTION)

This code will return NIL if this proposal is adopted.  Some current
implementations will return T, some will return NIL.
...

This isn't quite the right test case. Our Cloe implementation will return
T if this proposal is adopted because it is a compiled-only implementation.
I suggest:

(DEFUN F (A) (1+ A))
(EQ (SYMBOL-FUNCTION 'F)
(PROGN (DISASSEMBLE 'F)
(SYMBOL-FUNCTION 'F)))

I believe this will return T for all implementations if this proposal is
adopted and might return either T or NIL right now.

Current practice:

Allegro CL, Symbolics, and Vax Lisp install the compiled definition.
Lucid and KCL don't install it.  [[This is from an informal survey at
the last meeting; please correct any mistakes.]]

I checked the various Symbolics implementations, and I guess my stated
beliefs in this informal survey were wrong. We don't install it so should
be listed with Lucid and KCL. [Actually, we have three situations. Our
released system signals an error, our development system compiles a dummy
function and does not install the definition, and our Cloe system (a CL
for the 80386) is a compiled-only implementation so this issue is not
meaningful.

...
Aesthetics:

Those who thought DISASSEMBLE was supposed to install the compiled
function may find that the language has become a little cleaner.
...

I would say "Some who worried..." rather than "Those who thought...".

∂08-Dec-87  0939	CL-Cleanup-mailer 	Re: Issue: DRIBBLE-TECHNIQUE (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87  09:38:58 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 09:39:02 PST
Date: 8 Dec 87 09:38 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: DRIBBLE-TECHNIQUE (Version 1)
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sun, 6 Dec
87 22:57 EST
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871208-093902-4884@Xerox>

I agree that DRIBBLE should be explicitly vague.

-- Andy. --

∂08-Dec-87  0948	CL-Cleanup-mailer 	Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 87  09:48:22 PST
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 297885; Tue 8-Dec-87 12:47:14 EST
Date: Tue, 8 Dec 87 12:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
To: pierson@MULTIMAX.ARPA
cc: cl-cleanup@sail.stanford.edu, KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <871208124709.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I mostly support the contained proposal, but have a number of specific comments...

Date: Mon, 07 Dec 87 18:37:19 EST
From: Dan L. Pierson <pierson@multimax.ARPA>

Issue:         REDUCE-ARGUMENT-EXTRACTION
References:    REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut structure (pp. 312-313),
DELETE-IF-NOT, REMOVE-DUPLICATES, DELETE-DUPLICATES, SUBSTITUTE,
SUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE, NSUBSTITUTE-IF,
NSUBSTITUTE-IF-NOT, FIND, FIND-IF, FIND-IF-NOT, POSITION,
POSITION-IF, POSITION-IF-NOT, COUNT, COUNT-IF, COUNT-IF-NOT,
MISMATCH, SEARCH, SORT, STABLE-SORT, MERGE (pp. 253-261),
SUBST, SUBST-IF, SUBST-IF-NOT, NSUBST, NSUBST-IF, NSUBST-IF-NOT,
SUBLIS, NSUBLIS, MEMBER, MEMBER-IF, MEMBER-IF-NOT (pp. 273-275),
SET-DIFFERENCE, NSET-DIFFERENCE, SET-EXCLUSIVE-OR,
NSET-EXCLUSIVE-OR, SUBSETP (pp. 276-279),
ASSOC, ASSOC-IF, ASSOC-IF-NOT, RASSOC, RASSOC-IF, RASSOC-IF-NOT
(pp. 280-281)

I think this references list will scare people voting. I think the references is
intended to give people an idea of how sweeping the change is. If we feel strongly
that this isn't enough, we might want to have both a references and a cross-references
field. But for now I'd just leave the references as

REDUCE (pp. 251-252), :KEY arguments (p. 246),
the astronaut example (pp. 312-313)

and drop the rest.

Edit history:  Version 1 by Pierson 12/5/87
Issue:         For Internal Discussion

Problem description:

REDUCE is the only one of the Common Lisp functions that modify or
search lists and sequences which does not accept a :KEY argument.
This complicates many uses of REDUCE.

Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):

Change the definition of REDUCE to take a :KEY keyword.

This needs to be more elaborated. You need to say what the :KEY keyword will do.
The proposal part of these write-ups is intended to stand on its own.

Test Cases/Examples:
...

This is a good example.

Rationale:

This proposal brings REDUCE into line with the rest of the sequence
and list modifying and searching functions at the cost of slightly
blurring the meaning of :KEY arguments.

I would not mention the discussion of the name :KEY here at all. Leave it for
the discussion because it's confusing unless presented in full form, and it's
too much work to present here. Maybe just say:

This proposal makes many common situations where REDUCE would be useful
much less cumbersome.

Current practice:

Does anyone currently support this as an extension?
...

It's not worth mentioning in the proposal, but for your general information
so you don't think we didn't notice the question, Symbolics does not currently
support this.

Aesthetics:

Slightly damaged.  All :KEY arguments are currently defined to be used
for predicates, this proposal will implicitly broaden :KEY to support
general extraction for any purpose.

I might say "Slightly damaged in one way..." and then have a second paragraph
that says "Slightly improved in another way. Many common situations where
REDUCE could be used would be easier to write and easier to later read."

Discussion:

Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY.  No one has objected
to this change in the recent round of discussions.

There is no "definition" of :KEY. At best, it's an unwritten rule. It's arguably
just a coincidence. Anyway, the general sentiment of this paragraph is right,
but it should be worded more carefully so that it doesn't set a precedent for
"unwritten rules" having to be too strongly justified.

∂08-Dec-87  1121	CL-Cleanup-mailer 	Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87  11:21:10 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 11:18:30 PST
Date: 8 Dec 87 11:18 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
In-reply-to: Dan L. Pierson <pierson@multimax.ARPA>'s message of Mon, 07 Dec 87
18:40:46 EST
To: cl-cleanup@sail.stanford.edu
cc: pierson@multimax.ARPA
Message-ID: <871208-111830-5089@Xerox>

I support DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL. BTW, Xerox Lisp does not
install the compiled definition.

-- Andy. --

∂08-Dec-87  1123	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87  11:22:50 PST
Received: ID <RAM@C.CS.CMU.EDU.#Internet>; Tue 8 Dec 87 14:22:06-EST
Date: Tue, 8 Dec 1987  14:21 EST
Message-ID: <RAM.12356893261.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   Masinter.pa@XEROX.COM
Cc:   cl-cleanup@SAIL.STANFORD.EDU, KMP@SCRC-STONY-BROOK.ARPA,
sandra%orion@CS.UTAH.EDU
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Msg of 7 Dec 1987  17:40-EST from Masinter.pa at Xerox.COM

Date: Monday, 7 December 1987  17:40-EST
From: Masinter.pa at Xerox.COM
To:   Ram at C.CS.CMU.EDU
cc:   KMP at SCRC-STONY-BROOK.ARPA, cl-cleanup at SAIL.STANFORD.EDU,
Masinter.pa at Xerox.COM, sandra%orion at CS.UTAH.EDU
Re:   Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues

[...] What does (declare (function (integer integer) t) foo) imply?

We've discussed what it could mean, what it should mean, what CLtL
says it means, but I'd to hear about current practice. What, if
anything, do current implementations do with such declarations? Do
any implementations pay attention to the types of arguments in
function declarations?

Our current compiler totally ignores function type declarations.

I am working on a new compiler that currently gives function type
declarations a strict interpretation, i.e. the function must be called
only with two integer arguments.  (I suspect that this is like the
RESTRICTIVE-FTYPE declarations that someone from Lucid mentioned.)  At
least as an interpretation for FTYPE, this is clearly wrong.  I intend
to at least rename this declaration, and perhaps entirely flush it as
a user-visible facility.

I think that we should either entirely flush the concept of "function
types" or change the theory behind them.  The CLtL interpretation is
well-defined, but not very useful.  The intuitive strict
interpretation is useful, but is not a type declaration, at least in
the sense used in CLtL.

The restrictive interpretation can be modeled as a sort of magic
syntactic shorthand for a bunch of THE declarations at the call site:
(the t (foo (the integer x) (the integer y)))

But under this interpretation, a "function type" isn't a type at all,
since it isn't in any sense the type of the function object being
called.  It wouldn't be meaningful to declare a variable or value to
have a function type.  A "function type declaration" would be a piece
of magic recognized by the implementation that constrains calls to a
particular function variable.

If we did this, then the concept of a "function type specifier" should
be flushed, since "function types" can't be used in any of the ways
real types can.  The "function type" syntax would become part of the
syntax peculiar to a "function type declaration".  (A minor beneficial
side-effect is that it would make obvious the restriction on function
types in TYPEP.)

One problem that I have with this interpretation is that it makes the
evaluation of the functional position even more peculiar than it
already is.  Since a "function type declaration" would be purely
syntactic, it would only take effect when there was a syntactic match,
i.e. an obvious normal call to a declared function variable.  It would
probably be incorrect to do this transformation:
(funcall #'foo x y)  ==>
(the t (funcall #'foo (the integer x) (the integer y))))

Rob

∂08-Dec-87  1231	CL-Cleanup-mailer 	Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87  12:31:10 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 12:05:20 PST
Date: 8 Dec 87 12:05 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
In-reply-to: Dan L. Pierson <pierson@multimax.ARPA>'s message of Mon, 07 Dec 87
18:37:19 EST
To: pierson@multimax.ARPA
cc: cl-cleanup@sail.stanford.edu
Message-ID: <871208-120520-5164@Xerox>

In general I favor this proposal, but it needs some cleaning up before I'm happy
with it.

It cleans up a non-uniformity in the arguments passed to the reduction function
that has always bothered me: If there is no initial value, the first call to the
accumulated value and a sequence element. The order of these arguments depends
on :FROM-END as well. I've taken to providing an :INITIAL-VALUE argument just to
avoid cluttering up the reduction function with the hair to handle all this.

In fact, because of this nonsense, the example given in the proposal only works
for sequences with exactly two elements. A more correct example is

(reduce #'(lambda (x y) (+ x (person-age y))) astros :initial-value 0)

NB: Since there's an initial value you can dispense with the &optional, and the
first argument to the reduction function is now always the accumulated value.

Even with this new example, I think I'd still rather write

(reduce #'+ astros :key #'person-age)

The intent of the code seems clearer to me here.

There are a few details missing from the proposal.

1) The key-fn is never applied to the initial value, if any.

2) The wording in CLtL about how the initial value participates in the reduction
will have to be changed a bit.

3) If the specified subsequence contains exactly one element, no initial value
is given, and a key-fn has been provided, it is applied to that element and the
resulting value is returned.

If people are unhappy about using the :KEY keyword for this purpose because of
the aesthetic problems, I'm happy to entertain suggestions for another keyword

-- Andy. --

∂08-Dec-87  1334	CL-Cleanup-mailer 	Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87  13:34:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 13:19:30 PST
Date: 8 Dec 87 12:36 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
In-reply-to: Dan L. Pierson <pierson@multimax.ARPA>'s message of Mon, 07 Dec 87
18:37:19 EST
To: pierson@multimax.ARPA
cc: cl-cleanup@sail.stanford.edu
Message-ID: <871208-131930-5290@Xerox>

This is a good writeup. I think we should add the alternative form

(reduce  #'+ (mapcar #'person-age astros))

as the most natural equivalence; the stuff with the &optional arguments is
arcane and bogus in cases where there is an initial value.

I think that it is true that

(reduce <fn> sequence :key <key-fn>)  = (reduce <fn> (mapcar <key-fn> sequence))

except of course in the matter of order of evaluation.

∂08-Dec-87  1418	CL-Cleanup-mailer 	Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87  14:18:37 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 14:12:24 PST
Date: 8 Dec 87 14:10 PST
From: Daniels.pa@Xerox.COM
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
In-reply-to: Masinter.pa's message of 8 Dec 87 12:36 PST
To: Masinter.pa@Xerox.COM
cc: pierson@multimax.ARPA, cl-cleanup@sail.stanford.edu
Message-ID: <871208-141224-5386@Xerox>

Masinter writes:

I think that it is true that

(reduce <fn> sequence :key <key-fn>)  = (reduce <fn> (mapcar
<key-fn> sequence))

except of course in the matter of order of evaluation.

Well, that and the fact that MAPCAR doesn't work on arrays...

-- Andy. --

∂08-Dec-87  1620	CL-Cleanup-mailer 	Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Dec 87  16:16:41 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 DEC 87 16:05:38 PST
Date: 8 Dec 87 15:22 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Tue, 8 Dec 87 12:36 EST
To: cl-cleanup@sail.stanford.edu
Message-ID: <871208-160538-5539@Xerox>

I think we should take a step back and ask what the place of DISASSEMBLE, ED,
TRACE, BREAK, DRIBBLE, INSPECT etc.. should be in the ANSI standard.   These are
things for which constructing a denotational semantics is not feasible,  cann't
be easily tested with a  validation suites, etc.

I think a more global change of status for these is called for; I'd propose that
the ANSI Standard should say something like:

"The following are suggested features for a ANSI Common Lisp programming
environment. Conforming implementations are required to document what, if
anything, these functions do, in detail. However, no portable ANSI Common Lisp
program can rely on the behavior of these functions, because the behavior is
specifically not specified in the standard."

Once we move away from conformance and standard into recommendation, we might
actually be more able to make better progress  recommending, for example, that
systems call their GC function (GC) and their exit function (EXIT) etc.

Opinions?

∂08-Dec-87  1644	CL-Cleanup-mailer 	Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 87  16:44:47 PST
id AA01634; Tue, 8 Dec 87 16:50:18 EST
Message-Id: <8712082150.AA01634@multimax.ARPA>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
<871208124709.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 08 Dec 87 16:50:09 EST
From: Dan L. Pierson <pierson@multimax.ARPA>

Date: Tue, 8 Dec 87 12:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

Discussion:

Several members of the committee feel that the increased functionality
outweighs the damage to the definition of :KEY.  No one has objected
to this change in the recent round of discussions.

There is no "definition" of :KEY. At best, it's an unwritten rule. It's arguably
just a coincidence. Anyway, the general sentiment of this paragraph is right,
but it should be worded more carefully so that it doesn't set a precedent for
"unwritten rules" having to be too strongly justified.

To quote from CLtL page 246: "If an operation tests elements of a
sequence in any manner, the keyword argument :KEY, if not NIL, should
be function of one argument that will extract from an element the part
to be tested in place of the whole element."

This seems like a definition of :KEY to me, though I will cheerfully
agree that it doesn't specify that this is the only legal meaning of
:KEY.

Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY):

Change the definition of REDUCE to take a :KEY keyword.

This needs to be more elaborated. You need to say what the :KEY keyword will do.
The proposal part of these write-ups is intended to stand on its own.

The text on page 246 is also the only place that :KEY is documented in
CLtL.  However, I agree that a full description should be here both
because this is a slightly different use of :KEY and because our
standard document is likely to be more verbose than CLtL.

∂08-Dec-87  1828	CL-Cleanup-mailer 	Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87  18:28:33 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Tue 8 Dec 87 21:28:09-EST
Date: Tue, 8 Dec 1987  21:28 EST
Message-ID: <FAHLMAN.12356970828.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Masinter.pa@XEROX.COM
Cc:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
In-reply-to: Msg of 8 Dec 1987  18:22-EST from Masinter.pa at Xerox.COM

Explicitly excluding these environment thingies from the standard, and
demoing them to mere "suggested names" seems like a reasonable way to
go.

-- Scott

∂08-Dec-87  1836	CL-Cleanup-mailer 	Introductions
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Dec 87  18:36:13 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Tue 8 Dec 87 21:35:51-EST
Date: Tue, 8 Dec 1987  21:35 EST
Message-ID: <FAHLMAN.12356972234.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Introductions

I'm Scott Fahlman of Carnegie-Mellon University, and most of you know
me, I think.

There are three other CMU people on the cleanup list, all full-time CMU
staff members who work with me in the CMU Common Lisp project (formerly
Spice Lisp).  Dave McDonald and Bill Chiles are on the list mostly as
observers, making sure that we know about changes so that our
implementation can track them accurately.  Chiles has also had some
dealings with the error committee.  Rob Maclachlan (please note the
spelling) has been more vocal, especially on issues related to
compilation, types, and I/O.

-- Scott

∂09-Dec-87  0309	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Dec 87  03:03:38 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 DEC 87 03:00:06 PST
Date: 9 Dec 87 02:59 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
In-reply-to: Ram@C.CS.CMU.EDU's message of Tue, 8 Dec 87 14:21 EST
To: Ram@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
Message-ID: <871209-030006-1558@Xerox>

I think I understand and agree with most of what you say, in particular "I think
that we should either entirely flush the concept of "function types" or change
the theory behind them.  The CLtL interpretation is well-defined, but not very
useful. "

There are two components to your proposal: (1) what is allowed (and what it
means), and (2) how it is described in the standard.

I like the part of your proposal which is to change the interpretation of
function declarations to mean an implicit assertion of argument and value types
(the "restrictive interpretation").

I like defining  (declare (type (function (frob grid) bunker) x)) to mean

(funcall x y z) has implicitly means  (the bunker (funcall (the function x)
(the frob y) (the grid z)))

I don't see, however, that there is much leverage to removing FUNCTION from the
section on type specifiers. It would do some violence to the otherwise useful
concept of
(deftype binary-arithmetic () '(function (number number) number))

to be used in

(declare (ftype binary-arithmetic x y z)) .

I don't see at all that (funcall #'foo x y) doesn't mean (the t (funcall #'foo
(the integer x) (the integer y)))) given (declare (function foo (integer
integer) t)).

In the type propagation rules, you can transform funcall and apply expressions
using the asserted value of the function argument, and the asserted value type
of #'name is derived from the asserted ftype of name.

In this interpretation, AND would distribute nicely,

Given (proclaim '(function foo (s1 t1) v1)) and (declare (function foo (s2 t2)
v2)) you could assert that

(foo x y) => (the (and v1 v2) (foo (the (and s1 s2) x) (the (and t1 t2) y))).

(OR doesn't distribute as nicely, e.g., given (declare (ftype (or (function (s1
t1) v1) (function (s2 t2) v2)) foo)),  there isn't a simple way to describe the
type assertions made for (foo x y).

We might even want to explicitly allow FUNCTION declarations in THE
expressions, as in

(funcall (the binary-arithmetic x)  y z).

∂09-Dec-87  0702	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 87  07:02:20 PST
id AA09306; Wed, 9 Dec 87 08:00:52 MST
id AA16131; Wed, 9 Dec 87 08:00:48 MST
Date: Wed, 9 Dec 87 08:00:48 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8712091500.AA16131@orion.utah.edu>
Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues
To: Masinter.pa@xerox.com
Cc: Ram@c.cs.cmu.edu, cl-cleanup@sail.stanford.edu, sandra%orion@cs.utah.edu
In-Reply-To: Masinter.pa@Xerox.COM, 9 Dec 87 02:59 PST

Date: 9 Dec 87 02:59 PST
From: Masinter.pa@Xerox.COM

Given (proclaim '(function foo (s1 t1) v1)) and (declare (function foo (s2 t2)
v2)) you could assert that

(foo x y) => (the (and v1 v2) (foo (the (and s1 s2) x) (the (and t1 t2) y))).

I disagree.  The DECLARE should shadow the PROCLAIM; see p. 156 of
CLtL.  Or is there another proposal in the works to change declaration

-Sandra
-------

∂09-Dec-87  0729	CL-Cleanup-mailer 	Issue: FUNCTION-DECLARATION issues
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Dec 87  07:29:24 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Wed 9 Dec 87 10:28:51-EST
Date: Wed, 9 Dec 1987  10:28 EST
Message-ID: <FAHLMAN.12357112955.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-DECLARATION issues
In-reply-to: Msg of 9 Dec 1987  05:59-EST from Masinter.pa at Xerox.COM

Seems to me that we're trying to overload the type definition for
FUNCTION in ways that are not altogether consistent.  I'd suggest the
following:

1. Leave the FUNCTION type specifier alone.  It's not terribly useful in
its non-restrictive form, but it is harmless and it does fit in with the
rest of the type system.  (Of course, we would make it a full-fledged
type-specifier as discussed in the FUNCTION-TYPE proposal.)

2. Add an extended form for the LIST type specifier so that one can
indicate element type and, perhaps, length.  This can be used to say
something useful about rest-args, without having to put in ugly special
syntax for this.

3. Add a new declaration/proclamation, distinct from TYPE, by which
users can tell the compiler restrictive things about what a given
function will accept and what it will return.  This notation can be set
up so that you can say things like "if all args are integer, the result
will be" and "if the second arg is spaceship, the result will be
Martian".  Obviously this bit will require some careful design so that
we can make it maximally expressive and minimally confusing.  I don't
have a proposal ready; maybe Rob does.

4. Let me toss in here a related idea by Dave Touretzky that I've been
waiting to introduce whenever the time is right for a new batch of
issues: the RESTRICT declaration/proclamation.  Basically, (DECLARE
(RESTRICT type1 type2)) says that, within the extent covered by this
declaration, anything that is of type1 is guaranteed to be of type2 as
well, where type2 is generally more restrictive.  One could say
(RESTRICT NUMBER (INTEGER -1024 1024)), which tells the compiler that
any time it can prove something is a number, it can assume it is a
fixnum.  In some contexts, this can replace about six dozen THE
forms.  Users find it very awkward to say things like

(the (integer -1024 1024) (+ (the (integer -1024 1024) x)
(the (integer -1024 1024) y))

..yet often that is the only portable way to assure the compiler that it
can generate fixnum-only code on most machines.

The reson I bring up RESTRICT at this time is that I think the function
restriction mentioned in point 3 is related to this.  Maybe it should be
called RESTRICT-CALL or something.

-- Scott

∂09-Dec-87  0848	CL-Cleanup-mailer 	Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 9 Dec 87  08:48:03 PST
id AA05595; Wed, 9 Dec 87 11:51:24 EST
Message-Id: <8712091651.AA05595@multimax.ARPA>
To: Daniels.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)
<871208-141224-5386@Xerox>
Date: Wed, 09 Dec 87 11:51:12 EST
From: Dan L. Pierson <pierson@multimax.ARPA>

From: Daniels.pa@Xerox.COM
Subject: Re: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1)

Masinter writes:

I think that it is true that

(reduce <fn> sequence :key <key-fn>)  = (reduce <fn> (mapcar
<key-fn> sequence))

except of course in the matter of order of evaluation.

Well, that and the fact that MAPCAR doesn't work on arrays...

Make that:
(reduce <fn> sequence :key <key-fn>) =
(reduce <fn> (map 'list <key-fn> sequence))

Feel free to replace the "'list" with your favorite sequence type.
I'll change REDUCE-ARGUMENT-EXTRACTION to use this construct as the
present case.  You're absolutely right that my previous code was badly
broken and attempts to fix it up produce a real mess.  This almost
makes it interesting because the result is as cons-efficient as the
proposed new feature, while the mapping approach builds a whole new,
unecessary structure.

∂09-Dec-87  0955	CL-Cleanup-mailer 	Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 9 Dec 87  09:55:08 PST
id AA06214; Wed, 9 Dec 87 12:58:47 EST
Message-Id: <8712091758.AA06214@multimax.ARPA>
To: Masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1)
<871208-160538-5539@Xerox>
Date: Wed, 09 Dec 87 12:58:41 EST
From: Dan L. Pierson <pierson@multimax.ARPA>

From: Masinter.pa@Xerox.COM

"The following are suggested features for a ANSI Common Lisp programming
environment. Conforming implementations are required to document what, if
anything, these functions do, in detail. However, no portable ANSI Common Lisp
program can rely on the behavior of these functions, because the behavior is
specifically not specified in the standard."

This approach makes a lot of sense, but I think we need to give
somewhat more guidance than just a list of names.  We need something
along the lines of:

"The following are suggested features for a ANSI Common Lisp
programming environment.  No conforming implementation is required to
support any of these features.  However all implementations must
document which of these features they support and must adhere to the
following guidelines for the features they do support.  No portable
ANSI Common Lisp program can rely on the behavior of these functions,
because the behavior is sepcifically not specified in the standard."

This would be followed by a set of guidelines that:

1. Guarantee that, for example, ED invokes some sort of
editor.

2. Provide some of the CLtL standard interfaces so that
people porting their programs to a new implementation
will have a fighting chance at simple use of features
TRACE and DRIBBLE without reading the manual.

The second point is important.  I was recently a developer at a
software house doing more than 10 simultaneous ports.  Each port was
handled by one or more junior porters and developers only got called
in when problems happened.  In this sort of environment, the last
thing you want to do is spend an hour or few reading manuals before
looking at the problem.

This approach is sort of like the one take by the FORTH folks for the
Forth-83 standard.  They divided Forth up into: the required words,
the optional words with mandatory definitions, and suggested (or were
they experimental) extentions.

∂10-Dec-87  2311	CL-Cleanup-mailer 	Cleanup issues from Japanese technical working group
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Dec 87  23:10:30 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 10 DEC 87 23:10:38 PST
Date: 10 Dec 87 23:10 PST
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@Sail.Stanford.EDU
Subject: Cleanup issues from Japanese technical working group
Message-ID: <871210-231038-2589@Xerox>

I asked for the list of open Common Lisp issues from the JEIDA technical working
group. This is their list.

I've added some comments in <<brackets>>. Some of these will require separate

----- Begin Forwarded Messages -----

Return-Path: <@RELAY.CS.NET:yuasa%tutics.tut.junet@UTOKYO-RELAY.CSNET>
Message-Id: <8712101502.AA05475@tutics.tut.junet>
Date: Thu, 10 Dec 87 15:02:57 jst
From: Taiichi Yuasa <yuasa%tutics.tut.junet@utokyo-relay.CSNET>
To: Masinter.pa
Subject: Re: US work on List standards

Q: Michiaki Yasumura (Hitachi)
A: TG/A members
[nn.nn.nn] indicates section numbers in CLtL

*******************************************************************
The following subjects should be clarified.
*******************************************************************

1) CLtL says nothing about whether structure or array is self evaluating
form. [5.1.1]
It is suggested that not only numbers, characters, and bit-vectors,
but also structures, arrays, vectors, packages be self-evaluating forms.
Yuasa:  There may possibly be some reason that these objects are not
allowed to be evaluated.  But the reason is not known.
This simplification is convenient both for the user and for the implementor.
Note that some implementations such as Exper Common Lisp signal an error
when those objects that CLtL does not explicitly say are self-evaluating
are being evaluated.

<<The Rationale for this could easily be provided in the standard.
Does this need an Issue? >>

2) Arguments of function are evaluated left to right. [12.1]

<<This is clearly stated and should be even more ambiguous given a
formal semantics. I think no issue. >>

3) It should be an error if two variables specified in a single lambda
list are named by a same symbol. [15.2]

<<This was discussed in the CL mail, but I suppose it needs
New issue LAMBDA-LIST-DUPLICATES? >>

4) For mapping functions (MAPCAR, SOME, EVERY, etc.) and DOLIST,
it is an error to perform destructive operations on the mapping argument.
The result will be implementation dependent. [7.8.4]
<<New issue MAPPING-DESTRUCTIVE-INTERACTION?>>

5) Property lists are global.  There is no local property list even if
the symbol is locally bound. (Common Sense?) [10.1]
<<This is just confusion; symbols are not variables, they just name them.
I think no issue.>>

*************************************************************************
The following subjects are loosely stated in CLtL, and should be clarified.
*************************************************************************

1) If read-base is 16, 1E0' is read as an integer and not a float. [2.1.3]
<< I think this is a wording change rather than an Issue.>>

2) (LAMBDA (X) X) is both of the LIST type and of the FUNCTION type. [2.13]
Umemura: Cons cells must be regarded as function type objects, since
it is strange to check the syntactic validity when the type
of an object is computed.

<< Issue FUNCTION-TYPE would address this >>

3) DEFTYPE affect only the type checking mechanism and no more and less.
[4.7]
<< I'm not sure what this means. DEFTYPE also affects TYPEP, TYPECASE. >>

4) Symbols whose names begin with & are not allowed in a lambda list. [5.2.2]
<< I don't think this is true. It is a bad idea, but it isn't required.
Issue? >>

5) Same keyword parameter can appear more than once in an actual argument
list. [5.2.2]
This is necessary to overwrite passed keyword arguments.
<< New issue KEYWORD-ARGUMENT-DUPLICATES? >>

6) #C(5/3,7.0) is converted to #C(1.66666,7.0) because
real part and imaginary part must be of the same for efficient
calculation on complex numbers. [2.1.4]
<< This is clear, I thought, from CLtL >>

7) For destructive sequence functions such as DELETE, it is an error
to use the side effect of original data structure.
Implementation dependent result will be returned.
It is possible to defined DELETE as
(defun delete (&rest↓αβ∧¬επλ
!
∞∂⊂⊃∩∪∀∃⊗↔←→≠$≤ by REMF-DESTRUCTION-UNSPECIFIED >> 8) It is an error to apply non-list arguments for the list handling functions. [15.5] << I think is specified. No issue? >> 9) Structures defined with the option :TYPE LIST are simple lists and there is no way to distinguish these data from lists. [19.5] << I this is specified. No issue? >> ********************************************************** The following subject have problems in CLtL specification. ********************************************************** 1) ------ Q: What happens if a function is defined in a body of a function. For example: (defun bar () (bar) (defun bar () (something)) (bar) ) ; <-- Should BAR be affected in the execution of FOO? A: CLtL says the DEFUN is a simple macro which changes the symbols definition. So, BAR should be affected. Problems: If so, the tail merging optimization is very difficult. We cannot know how to define the effect of DEFUN in order to allow this optimization. Yuasa: How about defining only the compiler semantics? For almost all Common Lisp programs run in compiled code. << Unless BAR is proclaimed INLINE, you have to do tail optimization by indirect thru the function cell. This was discussed at length. Does this need an issue? FUNCTION-TAIL-RECURSION?>> 2) ----- Q: Is it possible to redefine predefined (built-in) functions and macros such as DEFUN, AND, OR. A: CLtL says nothing about this thing, but almost all implementations allow such redefinition. Problems: We cannot image what happens. Suggestion: Redefining a predefined symbol signals an error. However, Redefining user function does not signals an error. << This is issue LISP-SYMBOL-REDEFINITION >> 3) --- Q: Is there any way to cancel the PROCLAIM. A: No. There should be such a function. << Well, PROCLAIM-LEXICAL had such, but is in trouble. >> 4) --- Q: Is there any way to escape from Lisp context. A: Some systems, such as Lisp machine have no concept of escaping. This is needed for Lisp systems under stock operating systems. It is necessary to determine the name even if the function may be implementation dependent. Recommendation: (QUIT) will be a proper word for this operation. << Seems like it goes in the environment section. >> 5) -- Q: Is it possible to UNINTERN the DEFCONSTANTed symbols. A: CLtL says yes, but it is hard to compile such a program. Umemura: We should define the semantics of compile-file. Changing readbase, readmacro, packaged in a file also introduce similar problems. << This seems to be mainly about UNINTERN during file compilation. seems like this is part of the compiler specification. >> *************************************************************** These function can be defined in CLtL itself, but should be added to CLtL for the efficiency or user convenience. *************************************************************** 1) --- Q: Is there any way to test whether a symbol is special or not? A: We can define such a function in a tricky way, But there should be this function, for compiler needs this function and it seems that almost all implementations support such a function internally. << This has been asked for before. Issue SPECIAL-VARIABLE-TEST ? >> ∂15-Dec-87 1050 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 15 Dec 87 10:50:00 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA18399; Tue, 15 Dec 87 11:45:11 MST Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA02778; Tue, 15 Dec 87 11:45:06 MST Date: Tue, 15 Dec 87 11:45:06 MST From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8712151845.AA02778@orion.utah.edu> Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues To: Masinter.pa@xerox.com Cc: cl-cleanup@sail.stanford.edu, sandra%orion@cs.utah.edu In-Reply-To: Masinter.pa@Xerox.COM, 9 Dec 87 02:59 PST I'm confused as to what the current status is here. Should I revise my earlier proposals that deal primarily with syntax, or work on a new one that tries to address the question of function declaration semantics as well? -Sandra ------- ∂15-Dec-87 1128 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Dec 87 11:28:26 PST Received: from Cabernet.ms by ArpaGateway.ms ; 15 DEC 87 11:26:03 PST Date: 15 Dec 87 11:26 PST From: Masinter.pa@Xerox.COM Subject: Re: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT, FUNCTION-DECLARATION issues In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of Tue, 15 Dec 87 11:45:06 MST To: sandra%orion@cs.utah.edu cc: cl-cleanup@sail.stanford.edu Message-ID: <871215-112603-1532@Xerox> I apologize for sidetracking your original proposal with the related one of whether function argument declarations have semantics at all. It did seem to me that deciding whether one writes (function + (&rest number) number) or (function + (&rest (list number)) number) might wait for some resolution of whether there is any conceivable utility, other than documentation, for making either declaration, lest the issue bee moot. However, we probably should go forward with the discussion of the form of the declaration independent of its semantics, and separate out, say, FUNCTION-ARGUMENT-TYPE-SEMANTICS, from FUNCTION-TYPE-REST-LIST-ELEMENT. If there's no objection to doing so, I'll open up another issue name, and attempt to write up a FUNCTION-ARGUMENT-TYPE-SEMANTICS. ∂16-Dec-87 1538 CL-Cleanup-mailer Issue: SETF-METHOD-FOR-SYMBOLS (alternate proposal) Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Dec 87 15:38:43 PST Received: by labrea.stanford.edu; Wed, 16 Dec 87 15:27:56 PST Received: from gypsy-moth.lucid.com by edsel id AA09557g; Wed, 16 Dec 87 14:25:00 PST Received: by gypsy-moth id AA01336g; Wed, 16 Dec 87 14:25:56 PST Date: Wed, 16 Dec 87 14:25:56 PST From: Ken Olum <edsel!kdo@labrea.stanford.edu> Message-Id: <8712162225.AA01336@gypsy-moth.lucid.com> To: cl-cleanup@sail.stanford.edu In-Reply-To: Masinter.pa@Xerox.COM's message of 23 Oct 87 15:22 PDT <871023-152308-1515@Xerox> Subject: Issue: SETF-METHOD-FOR-SYMBOLS (alternate proposal) I don't think this issue has anything to do with symbols. For example, consider the form (setf (ldb (byte 8 0) x) (prog1 1 (setf (ldb (byte 8 8) x) 2))) Suppose that X is 0. This form now sets X to 1. However, if X is replaced with (CAR X), then the form will set (CAR X) to #x201. In order to have constant behavior, GETF and LDB must ALWAYS completely evaluate their subform, whether it is a symbol or not. If we do this with all setf-methods then we might as well flush the idea of an access-form since this must always be no more than a local variable reference. Furthermore the access-form must always be defined even if the case is just SETF, because you will always access it as EB points out in a previous message. Furthermore, I think this behavior is unnatural. Many applications set up flag-words and the like, and a side-effect of computing a value for one flag might well be the setting of another flag in the same word. In this case the same sub-place is being used to store various objects, and there should be as little interaction between the setting of the different objects as possible. Therefore, I propose that we change the definition of a subform for this order-of-evaluation issue and keep the methods on both pages 105 and 106. See SETF-METHOD-FOR-SYMBOLS:CHANGE-MEANING-OF-SUBFORM below. ! ISSUE: SETF-METHOD-FOR-SYMBOLS References: CLtL pp. 105, 106, 99. Issue: PUSH-EVALUATION-ORDER. Category: CHANGE Edit history: Version 1 Moon 21 Sep 87 Version 2 Masinter 23-Oct-87 Version 3 Masinter 11-Nov-87 Version 4 KDO 4-Dec-87 Problem description: The description of SETF in CLtL and various SETF methods are inconsistent. The description on page 99 clearly requires side-effects to be elaborated in left-to-right order; however, the combination of the sample setf-method for LDB on p.106 and the sample setf-method for symbols given on p. 105 results in incorrect order of evaluation. Test Case A: Given (LET* ((R (LIST 'A 1 'B 2 'C 3)) (S R)) (SETF (GETF R 'B) (PROGN (SETQ R NIL) 6)) (VALUES R S)) If side-effects are elaborated in left-to-right order, the setq of R to NIL should not affect the result, since it occurs after R is read and before R is written, and therefore the value of both R and S should be (A 1 B 6 C 3). A typical result in an implementation that believes CLtL p.105 more than CLtL p.99 is R = (B 6) and S = (A 1 B 2 C 3). Test Case B: Given: (LET((A 0)) (INCF (LDB (BYTE 2 2) A) (SETQ A 2)) A) Does this return 8, 10, or 2? If p. 99's description of order of evaluation is correct, this should return 8. It was pointed out that it is possible to get the required result for the test case by modifying the get-setf-method for GETF (and other setf-able items) to set up the bindings when the modified form is a symbol, as is done in Spice Lisp. However, we believe that user programs are much more likely to have copied the setf method for LDB given on p.106 than the setf method for symbols schematized on p.105, and this is the simplest change to achieve compatibility and correct behavior. Proposal: SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE Change the example of the result of (GET-SETF-METHOD 'FOO) from NIL NIL (#:G1174) (SETQ FOO #:G1174) FOO (as currently described in CLtL) to return, for example, (#:G1175) (FOO) (#:G1174) (SETQ FOO #:G1174) #:G1175 Rationale: The general principle mentioned on p.99 should override the specific example on p.105. The latter is probably just a mistake. Current practice: Symbolics and Lucid return the incorrect result mentioned in the test case A. (Symbolics plans to fix this in the next release.) Franz and Xerox returns something else: R = nil and S = (a 1 b 6 c 3); Xerox returns A=10 in Test Case B. HP Common Lisp produces the recommended value. Spice Lisp returns the recommended value for the test case A, even though it uses the suggested value for the setf-method for symbols, because the get-setf-method for GETF introduces additional temporary bindings. Adoption Cost: SETF is an intricate part of Common Lisp, and the fact that not all implementations currently return the same thing indicates that some care might be required in updating implementations. However, in some implementations changing what get-setf-method returns when its argument is a symbol is the only change required. It's been pointed out that this change might cause less efficient code to be produced in some cases, since setf methods will involve more temporary variables, however Moon believes that the optimizations are not difficult and probably are already done by most implementations. Cost of non-adoption: Users will think SETF is complicated and hard to understand, because implementations won't conform to a simple general principle that side-effects are elaborated in left-to-right order. Benefits: Improved portability of Common Lisp programs. Conversion Cost: This change is incompatible because it changes the result of some forms that are not erroneous. However, it's unlikely that very many users are intentionally depending on the current behavior. In addition, the current behavior is not consistent across implementations, which makes changing it less problematic. Esthetics: See "cost of non-adoption". Discussion: A specification of Common Lisp would do well to included some better examples of precisely what is meant by the "obvious' semantics" mentioned on page 99. This proposal is consistent with PUSH-EVALUATION-ORDER:ITEM in affirming the left-right order of evaluation of subforms of generalized variable access forms. It was pointed out that it is possible to get the required result for the test case by modifying the get-setf-method for GETF (and other setf-able items) to set up the bindings when the modified form is a symbol, as is done in Spice Lisp. However, we believe that user programs are much more likely to have copied the setf method for LDB given on p.106 than the setf method for symbols schematized on p.105, and this is the simplest change to achieve compatibility and correct behavior. Proposal: SETF-METHOD-FOR-SYMBOLS:CHANGE-MEANING-OF-SUBFORM Keep the old definition for symbols as examplified on p. 105 and the definition for LDB on p. 106. Specify that "subforms of generalized-variable references" on p. 99 does not includes subforms which will be stored into, but only those necessary to specify the place to store. In other words if the setf-method for a form must recusively make use of the setf-method for a subform, that that subform (but not any sub-subforms) is permitted to be evaluted at the time of the store instead of in its lexical position. Benefits: Anyone who has copied examples from p.105 and p.106 will continue to be able to use them. Setf of (LDB ... X) will be consistant with (LDB ... (CAR X)) and all other subplaces. It is very unlikely that anyone is depending on the left-to-right evaluation in this case, but quite possible that someone is depending on the non-left-to-right evaluation for maintaining several bit-fields in a symbol value. ∂17-Dec-87 1736 CL-Cleanup-mailer Cleanup issues from Japanese technical working group Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 17:35:48 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306483; Thu 17-Dec-87 20:35:35 EST Date: Thu, 17 Dec 87 20:35 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Cleanup issues from Japanese technical working group To: CL-CLEANUP@SAIL.STANFORD.EDU In-Reply-To: <871210-231038-2589@Xerox> Message-ID: <19871218013528.0.MOON@EUPHRATES.SCRC.Symbolics.COM> I have comments on excerpts from this. For most of the issues raised, I have no comment. Feel free to forward these comments back to our Japanese friends if desired. 1) CLtL says nothing about whether structure or array is self evaluating form. [5.1.1] It is suggested that not only numbers, characters, and bit-vectors, but also structures, arrays, vectors, packages be self-evaluating forms. Yuasa: There may possibly be some reason that these objects are not allowed to be evaluated. But the reason is not known. This simplification is convenient both for the user and for the implementor. Note that some implementations such as Exper Common Lisp signal an error when those objects that CLtL does not explicitly say are self-evaluating are being evaluated. <<The Rationale for this could easily be provided in the standard. Does this need an Issue? >> It's not true that CLtL says nothing about this; the bottom of page 54 in the English edition says evaluating any other object is an error. I don't know what the rationale was; unless somebody knows, we can't easily provide it in the standard! At Symbolics we pondered this for a while and settled on the idea that only objects of type (OR CONS SYMBOL) do anything special when evaluated, and all other objects evaluate to themselves. We haven't had any problems as a result of this. CLtL says something about implementation-dependent extensions for evaluating other types of objects, but we decided that this didn't make sense for any of the object types defined by CLtL. An implementation could certainly invent a new, non-COMMON object type with a new way of evaluating it, and then that (OR CONS SYMBOL) would be extended to (OR CONS SYMBOL other-type) in that implementation. But since a portable program presumably wouldn't use any objects of that implementation-dependent type, this should't interfere with portability even if we define that all objects of types defined by CLtL, other than CONS and SYMBOL, are self-quoting. Evidently current practice varies between implementations. This needs an issue if we want to change it, but since "is an error" allows complete implementation-dependent freedom, we don't have to say anything if we think the status quo is okay. 1) If read-base is 16, 1E0' is read as an integer and not a float. [2.1.3] << I think this is a wording change rather than an Issue.>> I don't think this is a problem at all, since 22.1.2 (page 343) is very explicit about this. 5) Same keyword parameter can appear more than once in an actual argument list. [5.2.2] This is necessary to overwrite passed keyword arguments. << New issue KEYWORD-ARGUMENT-DUPLICATES? >> Not an issue, 5.2.2 (page 62 in the English edition) is already very explicit about this "If more than one such argument pair matches, it is not an error; the leftmost argument pair is used." 4) --- Q: Is there any way to escape from Lisp context. A: Some systems, such as Lisp machine have no concept of escaping. This is needed for Lisp systems under stock operating systems. It is necessary to determine the name even if the function may be implementation dependent. Recommendation: (QUIT) will be a proper word for this operation. << Seems like it goes in the environment section. >> I remember this was discussed at length a couple years ago, and the conclusion was that the semantics of quitting varied so much between implementations that there was no point in trying to standardize anything. Even without thinking about multiprocess systems, nor about Lisp machines, you have to ask whether after quitting the Lisp vanishes or can be restarted, whether a command string can be returned to the operating system, whether a success/failure code is required to be returned to the operating system, etc. Finally it is unclear how a portable program could usefully benefit from this. ∂17-Dec-87 1740 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 1) Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 17:40:12 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306486; Thu 17-Dec-87 20:39:48 EST Date: Thu, 17 Dec 87 20:39 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 1) To: Dan L. Pierson <pierson@MULTIMAX.ARPA> cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8712072340.AA01767@multimax.ARPA> Message-ID: <19871218013945.1.MOON@EUPHRATES.SCRC.Symbolics.COM> I support DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL as well as KMP's suggested improvement to the test case, which I was going to suggest myself. The COMPILED-FUNCTION type specifier is not well-defined and if I remember correctly the FUNCTION-TYPE cleanup issue proposes to remove it. ∂17-Dec-87 1745 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1) Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 17:45:36 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306494; Thu 17-Dec-87 20:45:27 EST Date: Thu, 17 Dec 87 20:45 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 1) To: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <871208-160538-5539@Xerox> Message-ID: <19871218014525.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 8 Dec 87 15:22 PST From: Masinter.pa@Xerox.COM I think we should take a step back and ask what the place of DISASSEMBLE, ED, TRACE, BREAK, DRIBBLE, INSPECT etc.. should be in the ANSI standard. These are things for which constructing a denotational semantics is not feasible, cann't be easily tested with a validation suites, etc. I think a more global change of status for these is called for; I'd propose that the ANSI Standard should say something like: "The following are suggested features for a ANSI Common Lisp programming environment. Conforming implementations are required to document what, if anything, these functions do, in detail. However, no portable ANSI Common Lisp program can rely on the behavior of these functions, because the behavior is specifically not specified in the standard." This seems like a reasonable idea, although it's perhaps not in the domain of the Cleanup committee. Once we move away from conformance and standard into recommendation, we might actually be more able to make better progress recommending, for example, that systems call their GC function (GC) and their exit function (EXIT) etc. I think this would be a mistake. The functions listed earlier are to be called by users and generally are not useful to call from programs. The only reason those functions were ever in CLtL as functions is that Common Lisp didn't want to assume that some kind of command processor, separate from Lisp evaluation, exists since opinions on how this should work diverge so wildly. GC and EXIT are in a different category. GC is likely to be called by programs, except that as we found when we discussed it a while back, it doesn't seem to be possible to say anything at all implementation-independent about the semantics of this, which makes it not very useful for portable programs. EXIT surely must be for programs, rather than users, since every operating system already has a way for users to get out; but again there is no portable semantics. While it's useful to have some "suggested features" for users, to ease learning how to use a new Common Lisp implementation as well as to give implementors an idea of the minimum environment expected, it's not useful to have "suggested features" for programs, since if they are only suggested, no portable program can use them. ∂17-Dec-87 1757 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 1) Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 17:57:01 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306500; Thu 17-Dec-87 20:57:01 EST Date: Thu, 17 Dec 87 20:56 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 1) To: Dan L. Pierson <pierson@MULTIMAX.ARPA> cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8712072337.AA01737@multimax.ARPA> Message-ID: <19871218015659.3.MOON@EUPHRATES.SCRC.Symbolics.COM> I favor REDUCE-ARGUMENT-EXTRACTION:KEY. I'd like to see a version 2 of this proposal, amended according to the comments received. The changes would all be to the form of the proposal, not its substance, but would make it more approvable. Proposals containing test cases that have not been tested are a real no-no! ∂17-Dec-87 1805 CL-Cleanup-mailer Issue: FUNCTION-DECLARATION issues Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Dec 87 18:05:08 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 306504; Thu 17-Dec-87 21:05:03 EST Date: Thu, 17 Dec 87 21:05 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: FUNCTION-DECLARATION issues To: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <FAHLMAN.12357112955.BABYL@C.CS.CMU.EDU> Message-ID: <19871218020501.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 9 Dec 1987 10:28 EST From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> 2. Add an extended form for the LIST type specifier so that one can indicate element type and, perhaps, length. This can be used to say something useful about rest-args, without having to put in ugly special syntax for this. I very strongly prefer having the thing after the &rest in a function type-specifier refer to each remaining argument, as Steele suggested two years ago, rather than having it refer to the value of the &rest parameter, as you seem to be assuming. This is partly because I very strongly prefer having the function type-specifier be a description of arguments rather than a description of parameters. Thus I prefer (function + (&rest number) number) over (function + (&rest (list number)) number) I really have no opinion on the other features being discussed in this conversation, including the very existence of the list form of the function type-specifier. All this stuff seems both overcomplicated and useless to me, but that's not an informed opinion. ∂17-Dec-87 1812 CL-Cleanup-mailer Cleanup issues from Japanese technical working group Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 18:12:45 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Thu 17 Dec 87 21:12:34-EST Date: Thu, 17 Dec 1987 21:12 EST Message-ID: <FAHLMAN.12359327290.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA> Cc: CL-CLEANUP@SAIL.STANFORD.EDU Subject: Cleanup issues from Japanese technical working group In-reply-to: Msg of 17 Dec 1987 20:35-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM> It's not true that CLtL says nothing about this; the bottom of page 54 in the English edition says evaluating any other object is an error. I don't know what the rationale was; unless somebody knows, we can't easily provide it in the standard! At Symbolics we pondered this for a while and settled on the idea that only objects of type (OR CONS SYMBOL) do anything special when evaluated, and all other objects evaluate to themselves. We haven't had any problems as a result of this. I remember some of the discussions on this issue (though I no longer remember which side I was on -- scary!). A number of people wanted to make all objects other than Conses and Symbols be self-evaluating; a number of other people didn't want to close off the space of possible extensions in this way. The latter group won. In retrospect, it seems clear that this was a mistake -- nobody has used the added freedom as far as I know, and the need to quote such things as vectors has definitely led to confusion among new users and an occasional spurious bug report. I'd support a move to change this, so that we could all assume self-evaluating objects when we're writing portable code. Since "it is an error" to eval objects of miscellaneous types, implementations are legally free to adopt the self-eval convention, but I would argue that it is a bit treacherous for their users if they do, since the local users will be in for a nasty surprise whenever they move to a system that doesn't use this convetion. On the Quit issue, I think that Masinter has suggested the right way to handle this: ed, dribble, and friends should be suggested names for certain environment-related operations, but nothing more. The standard would explicitly say that these environment functions may or may not exist in any given implementation, and that what they do will vary from one environment to another. CLtL currently says a bit too much about some of these things, which causes people to want to say even more. -- Scott ∂17-Dec-87 1823 CL-Cleanup-mailer Issue: FUNCTION-DECLARATION issues Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 Dec 87 18:22:55 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Thu 17 Dec 87 21:22:49-EST Date: Thu, 17 Dec 1987 21:22 EST Message-ID: <FAHLMAN.12359329156.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA> Cc: cl-cleanup@SAIL.STANFORD.EDU Subject: Issue: FUNCTION-DECLARATION issues In-reply-to: Msg of 17 Dec 1987 21:05-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM> I very strongly prefer having the thing after the &rest in a function type-specifier refer to each remaining argument, as Steele suggested two years ago, rather than having it refer to the value of the &rest parameter, as you seem to be assuming. This is partly because I very strongly prefer having the function type-specifier be a description of arguments rather than a description of parameters. Thus I prefer (function + (&rest number) number) over (function + (&rest (list number)) number) Hmmm...I never thought about it this way. If we look at the syntax you prefer as a special case for talking about the elements in the rest list, then this is a hideous kludge. On the other hand, if we look at this as a way of talking about the type of each of the rest arguments, then it has a certain elegance. I wouldn't object, as long as it's explained this way. We may still want to adopt a better type specifier for LIST, but that is a separable issue. -- Scott ∂18-Dec-87 1439 CL-Cleanup-mailer whether random objects self-evaluate (was cleaup issues from Japan) Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 18 Dec 87 14:39:50 PST Received: from relay2.cs.net by RELAY.CS.NET id aa20706; 18 Dec 87 17:33 EST Received: from tektronix.tek.com by RELAY.CS.NET id bz29779; 18 Dec 87 17:26 EST Received: by tektronix.TEK.COM (5.51/6.24) id AA17683; Fri, 18 Dec 87 11:41:33 PST Received: by tekchips.TEK.COM (5.51/6.24) id AA22225; Fri, 18 Dec 87 11:40:04 PST Message-Id: <8712181940.AA22225@tekchips.TEK.COM> To: Fahlman@C.CS.CMU.EDU Cc: Moon@SCRC-STONY-BROOK.ARPA, CL-CLEANUP@SAIL.STANFORD.EDU, willc%tekchips.tek.com@RELAY.CS.NET Subject: whether random objects self-evaluate (was cleaup issues from Japan) In-Reply-To: Your message of Thu, 17 Dec 1987 21:12 EST. <FAHLMAN.12359327290.BABYL@C.CS.CMU.EDU> Date: 18 Dec 87 11:40:02 PST (Fri) From: willc%tekchips.tek.com@RELAY.CS.NET Let me report on the Scheme situation and my experience. As in Common Lisp, it is "an error" to evaluate a random object, but most implementations extend the language by allowing at least some random objects (notably the empty list, since only a few implementations yet distinguish the empty list from #f) to evaluate to themselves. MacScheme allows all random objects to evaluate to themselves, but unlike Symbolics I have found this to be a (minor) problem, and I recommend that implementors avoid my mistake. The problem: In writing a macro using backquote I sometimes leave out a quote mark, insert an extra comma, or put a comma in the wrong place. Then an expanded macro can look like (... #<PROCEDURE> ...) when I wanted it to look like (... '#<PROCEDURE foo> ...) or (... (lambda (...) ...) ...). I would like to get an error message from the incremental compiler, because I never deliberately write code with unquoted procedures, but with self-evaluating procedures no error will occur until the expression is executed, and then the values seen in the debugger can seem very strange. In my code, this kind of macro bug almost always shows up as a procedure that was closed in the wrong environment, but if I'm unlucky the incorrect procedure will pass control to an altogether unfamiliar part of the system before trapping on some unrelated error such as taking the car of the empty list. As better macro facilities become more universal, this is of course becoming less of a problem. Peace, Will ∂18-Dec-87 1759 CL-Cleanup-mailer whether random objects self-evaluate (was cleaup issues from Japan) Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Dec 87 17:58:59 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Fri 18 Dec 87 20:58:45-EST Date: Fri, 18 Dec 1987 20:58 EST Message-ID: <FAHLMAN.12359586922.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: willc%tekchips.tek.com@RELAY.CS.NET Cc: CL-CLEANUP@SAIL.STANFORD.EDU Subject: whether random objects self-evaluate (was cleaup issues from Japan) Will, It would be easy enough to say that most objects are self-evaluating, but that function objects (strict definition) signal an error if you evaluate them. Then again, it would be nice to avoid making odd exceptions of this kind -- I've heard tell that some people think Common Lisp already is something of a kludge. I wonder if the problem you cite is as likely to occur in Common Lisp as it is in Scheme. I've never seen this in my own coding, but that might be because I am terribly conservative in my use of backquotery. What do others think? -- Scott ∂21-Dec-87 1924 CL-Cleanup-mailer SETF-METHOD-FOR-SYMBOLS Issue Received: from DECWRL.DEC.COM by SAIL.STANFORD.EDU with TCP; 21 Dec 87 19:22:17 PST Received: by decwrl.dec.com (5.54.4/4.7.34) id AA16788; Mon, 21 Dec 87 15:10:11 PST Date: Mon, 21 Dec 87 15:10:11 PST Message-Id: <8712212310.AA16788@decwrl.dec.com> From: greek%aitg.DEC@decwrl.dec.com To: cl-cleanup@sail.stanford.edu Subject: SETF-METHOD-FOR-SYMBOLS Issue I spent some time reading the issue entitled SETF-METHOD-FOR-SYMBOLS. Seems to me it avoids the real question. Consider Test Case A. Once the (GETF ...) and (PROGN ...) are evaluated, what happens. We notice that the key B already appears in the list, so we replace its value with 6. Then do we store the list back in R? If so, R will be (A 1 B 6 C 3). If not, it will be NIL. Now if the key does not appear in the list, we must cons it on the front and then are forced to store it back in B. So perhaps for consistency we should always store it back. So I guess my question is: is the place in (SETF (GETF R ...) ...) R or is it the list in R or is the pair in the list in R? - Paul Anagnostopoulos ∂30-Dec-87 1625 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2) Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 30 Dec 87 16:25:13 PST Received: by multimax.ARPA (5.51/25-eef) id AA18793; Wed, 30 Dec 87 19:29:57 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA19273; Wed, 30 Dec 87 19:26:34 EST Message-Id: <8712310026.AA19273@mist.UUCP> To: cl-cleanup%sail.stanford.edu@multimax Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2) Date: Wed, 30 Dec 87 19:26:32 EST From: Dan L. Pierson <pierson@mist> Issue: DISASSEMBLE-SIDE-EFFECT References: DISASSEMBLE (p. 439), COMPILE (p. 439) Category: CLARIFICATION Edit history: Version 2 by Pierson 12/30/87 Status: For Internal Discussion Problem description: The definition of DISASSEMBLE says that "if the relevant function is not a compiled function, it is first compiled.". The definition of COMPILE says that "If name is a non-nil symbol, then the compiled-function is installed as the global function definition of the symbol...". Several implementations have taken this to mean that if DISASSEMBLE is passed a symbol which has an uncompiled function definition, then it has the side-effect of (COMPILE 'symbol). Proposal (DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL): Clarify that when DISASSEMBLE compiles a function, it will never install the newly compiled function. Test Cases/Examples: (DEFUN F (A) (1+ A)) (EQ (SYMBOL-FUNCTION 'F) (PROGN (DISASSEMBLE 'F) (SYMBOL-FUNCTION 'F))) This code will return T if this proposal is adopted. Some current implementations will return T, some will return NIL. Rationale: Several current implementations of DISASSEMBLE have surprising side effects, especially for new users. Current practice: Allegro CL and Vax Lisp install the compiled definition. Lucid, Symbolics, Xerox, and KCL don't install it. [[This is from an informal survey at the last meeting; please correct any mistakes.]] Cost to Implementors: Some implementations will have to make a simple change. Cost to Users: Very little. DISASSEMBLE is really part of the environment and is probably not called by much, if any user code. Cost of non-Adoption: DISASSEMBLE will continue to surprise less experienced users. Benefits: DISASSEMBLE will become the predictable debugging function it was meant to be. Aesthetics: Some who worried that DISASSEMBLE was supposed to install the compiled function may find that the language has become a little cleaner. Discussion: ∂30-Dec-87 1634 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 2) Received: from MULTIMAX.ARPA by SAIL.STANFORD.EDU with TCP; 30 Dec 87 16:34:14 PST Received: by multimax.ARPA (5.51/25-eef) id AA18840; Wed, 30 Dec 87 19:39:01 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA19317; Wed, 30 Dec 87 19:35:38 EST Message-Id: <8712310035.AA19317@mist.UUCP> To: cl-cleanup%sail.stanford.edu@multimax Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 2) Date: Wed, 30 Dec 87 19:35:36 EST From: Dan L. Pierson <pierson@mist> Issue: REDUCE-ARGUMENT-EXTRACTION References: REDUCE (pp. 251-252), :KEY arguments (p. 246), the astronaut structure (pp. 312-313), Category: ADDITION Edit history: Version 2 by Pierson 12/30/87 Issue: For Internal Discussion Problem description: REDUCE is the only one of the Common Lisp functions that modify or search lists and sequences which does not accept a :KEY argument. This complicates many uses of REDUCE. Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY): Change the definition of REDUCE to take a :KEY keyword described as follows: If a :KEY argument is supplied, its value must be a function of one argument which will be used to extract the values to reduce. The :KEY function will be applied exactly once to each element of the sequence in the order implied by the reduction order but not to the value of the :INITIAL-VALUE argument, if any. Test Cases/Examples: Using REDUCE to obtain the total of the ages of the possibly empty sequence of astronauts ASTROS, would currently require: (REDUCE #'+ (MAP 'LIST #'PERSON-AGE ASTROS)) If this proposal is adopted, the same result could be obtained without creating a new list by: (REDUCE #'+ ASTROS :KEY #'PERSON-AGE) Rationale: This proposal makes many common situations where REDUCE would be useful much less cumbersome. Current practice: Does anyone currently support this as an extension? Cost to Implementors: This will require most implementations to make a trivial modification to REDUCE. Implementations which wish to use this as an opportunity to further optimize compiled calls to REDUCE will have to undertake more work (which would be much more difficult today). Cost to Users: None, this is an upward compatible extension. Cost of non-Adoption: REDUCE will continue to be more difficult to use than other sequence functions on sequences of complex objects. Benefits: REDUCE will become easier to use on sequences of complex objects. It will be easier for compilers to convert some calls to REDUCE into efficient loops. Aesthetics: Slightly damaged in one way. All :KEY arguments are currently defined to be used for predicates, this proposal will implicitly broaden :KEY to support general extraction for any purpose. Slightly improved in another way. Many common situations where REDUCE could be used would be easier to write and easier to later read. Discussion: Several members of the committee feel that the increased functionality outweighs the damage to the definition of :KEY. No one has objected to this change in the recent round of discussions. There is some controversy over whether the "definition" of :KEY arguments on page 246 of CLtL really constitutes a definition or just an "unwritten rule". ∂31-Dec-87 1126 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 2) Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 31 Dec 87 11:26:05 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 313154; Thu 31-Dec-87 14:26:24 EST Date: Thu, 31 Dec 87 14:26 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 2) To: Dan L. Pierson <pierson@multimax.com> cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8712310035.AA19317@mist.UUCP> Message-ID: <19871231192614.0.MOON@EUPHRATES.SCRC.Symbolics.COM> This looks fine to me. Current practice: Symbolics does not have :KEY in REDUCE currently. ∂31-Dec-87 1723 CL-Cleanup-mailer Releasing potentially confusing info to the CL community Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 31 Dec 87 17:23:01 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 313392; Thu 31-Dec-87 20:22:54 EST Date: Thu, 31 Dec 87 20:22 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Releasing potentially confusing info to the CL community To: masinter.PARC@Xerox.COM cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <871231-163511-2608@Xerox> Message-ID: <871231202220.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> [Common-Lisp removed; CL-Cleanup added.] Date: 31 Dec 87 16:34:23 PST (Thursday) From: masinter.PARC@Xerox.COM To: COMMON-LISP@SAIL.STANFORD.EDU There will probably be a letter ballot to X3J13 to confirm the cleanup items accepted by voice vote at the recent X3J13 meetings. I'd say that these changes would then has as much official' status as anything. ... Which is to say: "none". I would say that this is a misleading statement. Our committee has no charter to legislate changes to CL as it exists now. The committee which could do that has not met for two years. It was not even clear whether it had the power to make changes when it did meet. I'm firmly of the belief that people should not be encouraged to assume that present-day CL is other than CLtL. CLtL is a target that can be hit. If people start randomizing some but not all dialects in a disorganized fashion to try to take "cleanup" changes into effect, there will be even more chaos than there is already. Some changes are not compatible. The others are only compatible if you assume that all implementations are changed in lockstep; if some implementations change and others do not, then porting code from changed implementations to non-changed implementations may be expensive. Our current environmental impact statements do not discuss this I-think-peculiar-and-undesirable situation. I very very strongly believe that the chunking size of any information to the CL community should be considerably larger (ie, something like a "draft proposed standard") than these proposals -- never something trivially separable like this. Otherwise you get into a non-linear situation where one CL implementation has informally made changes A, B, and C and others have made changes C, D, and E and you can't compare them. On the other hand, it is easy to compare CLtL to draft CL-88 or perhaps-not-draft CL-90 because the changes will be sufficiently bundled that we can afford to give them a name. I'm loathe to think that CL's will be identified by non-linear names like CLtL+FLET-fix+... Either that or it might work to number the decisions and say that if you implement any cleanups, you must implement all the cleanups which precede it so that a single revision number may be assigned to your implementation. I'd have to think more about this if anyone wanted to pursue it. -kmp ∂31-Dec-87 1749 CL-Cleanup-mailer Re: Releasing potentially confusing info to the CL community Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 31 Dec 87 17:49:30 PST Received: from Burger.ms by ArpaGateway.ms ; 31 DEC 87 17:48:25 PST Sender: "Larry_Masinter.PARC"@Xerox.COM Date: 31 Dec 87 17:47:39 PST (Thursday) Subject: Re: Releasing potentially confusing info to the CL community From: masinter.PARC@Xerox.COM To: KMP@STONY-BROOK.SCRC.Symbolics.COM cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-to: KMP%STONY-BROOK.SCRC.Symbolics:COM's message of 31 Dec 87 17:23:13 PST (Thursday) Message-ID: <871231-174825-2644@Xerox> Sigh. Present-day CL isn't CLtL either... since most present-day CL implementations have bugs, have places where they differ from CLtL, have lots of variations. I think that we can dissimenate information that X3J13 has "endorsed" some changes in a letter ballot, and once the changes have been endorsed, implementors are encouraged to go ahead and adopt those changes and document them. I hear your concern to be that we want to reduce the amount of chaos in the CL world, and encourage compatibility. If so, I agree whole-heartedly. The issue then comes down to whether releasing X3J13-adopted resolutions is likely to increase or decrease people's understanding of where ambiguities in CLtL might lie and what they can watch out for. I think the mere existance of the issue and the Discussion in fact are very informative for most users, and will help them understand areas that they have to watch out for. From that perspective, isn't releasing the approved' drafts doing everyone a service? We do talk about current practice and whether this is a compatible change from 'current' implementations, etc. ∂01-Jan-88 1245 CL-Cleanup-mailer New issue: FLET-DECLARATIONS Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jan 88 12:44:53 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 313515; Fri 1-Jan-88 15:45:15 EST Date: Fri, 1 Jan 88 15:45 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: New issue: FLET-DECLARATIONS To: Cl-Cleanup@SAIL.STANFORD.EDU cc: Hornig@STONY-BROOK.SCRC.Symbolics.COM Message-ID: <19880101204506.6.MOON@EUPHRATES.SCRC.Symbolics.COM> This comes from Steele's 1985 list. I thought that the Cleanup committee had picked this one up long ago, but in looking over the status list it seems like it's never been written up. Perhaps it's too non-controversial? I think we may have discussed this at a face to face meeting last year and decided we were afraid of anything that touches upon declaration scoping. However, I think there is only one possible declaration scoping rule for these that is consistent with CLtL. Issue: FLET-DECLARATIONS References: FLET, LABELS, MACROLET (CLtL p.113) X3J13 document 86-003 item 113 Category: ADDITION Edit history: Version 1, Moon, 1 Jan 1988 Problem description: Declarations are not allowed before the body of FLET, LABELS, and MACROLET, even though Common Lisp allows declarations in other seemingly analogous places, such as LET. Proposal (FLET-DECLARATIONS:ALLOW): Change the syntax of FLET, LABELS, and MACROLET to allow declarations between the list of local function/macro definitions and the body forms. In MACROLET, an invocation of one of the macros locally defined by that MACROLET is permitted to expand into a DECLARE (assuming Common Lisp is not changed to forbid any macros to expand into DECLARE). The scope of such declarations in FLET and LABELS includes the bodies of the locally defined functions, when the declarations are pervasive. Non-pervasive declarations have no effect on those bodies, except when LABELS includes the body in the scope of a function non-pervasively declared. This paragraph follows directly from CLtL p.155 if the locally defined function bodies are treated like initialization forms. (This paragraph will be superseded by a proposal on declaration scoping that Hornig plans to make soon.) The scope of such declarations does not include the bodies of the macro expander functions defined by MACROLET. This is consistent with the existing rule that the bodies of those functions are in the global environment, not the local lexical environment. This rule is required in order to permit macros to expand into DECLARE, as noted above. Test Cases/Examples: (defun example (y l) (flet ((attach (x) (setq l (append l (list x))))) (declare (inline attach)) (dolist (x y) (unless (null (cdr x)) (attach x))) l)) (example '((a apple apricot) (b banana) (c cherry) (d) (e)) '((1) (2) (3) (4 2) (5) (6 3 2))) => ((1) (2) (3) (4 2) (5) (6 3 2) (a apple apricot) (b banana) (c cherry)) The above function is erroneous in current Common Lisp. With this proposal, it would have an intuitively obvious meaning. Rationale: This will make the syntax of FLET and LET consistent. This will make it possible to attach declarations to function bindings; currently only variable bindings can have attached declarations. Current practice: I do not know of any Common Lisp implementations that allow declarations there. Cost to Implementors: The compilation and interpretation of three special forms will have to be changed, however the same techniques already developed for declarations in LET should be applicable. Cost to Users: No cost since this is an upward-compatible addition. Cost of non-adoption: Unnecessary inconsistency in the syntax of Common Lisp. Benefits: There is no major benefit but the language will be more consistent. Esthetics: Makes the language more consistent. Discussion: We need to resolve this for CLOS, because CLOS introduces two new special forms similar to FLET and LABELS and we need to make their syntax consistent. ∂03-Jan-88 1322 CL-Cleanup-mailer cleanup status Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 3 Jan 88 13:21:55 PST Received: from Burger.ms by ArpaGateway.ms ; 03 JAN 88 13:03:43 PST Sender: "Larry_Masinter.PARC"@Xerox.COM Date: 2 Jan 88 23:04:12 PST (Saturday) Subject: cleanup status From: masinter.PARC@Xerox.COM To: KMP@STONY-BROOK.SCRC.Symbolics.COM cc: CL-Cleanup@SAIL.STANFORD.EDU Message-ID: <880103-130343-1016@Xerox> Kent: I composed the following as a follow-up to mail to common-lisp@sail.stanford.edu. Would this address your concerns? - - - - - - - - - - - My recent message prompted enough debate that I thought I would clarify what I meant in my recent message about FLET. Some assumptions: X3J13 is attempting to define an ANSI standard for Common Lisp. X3J13 is starting with "Common Lisp the Language" by Guy L. Steele, Jr. and considering various clarifications, changes, additions, enhancements, modifications. The "cleanup committee" of X3J13 is considering those minor clarifications, changes, additions, enhancements, modifications as do not fit within the charter of the other subcommittee's of X3J13 (namely objects, windows & graphics, characters, iteration, compilation, validation, and possibly some others that I forget.) The process for various cleanups is that we (the cleanup committee) consider proposals either that we generate (e.g., based on Guy Steele's original list of proposed modifications), that we get from the community, or are based on mail to common-lisp@Sail.stanford.edu that seems to have reached some convergence. We produce a writeup (similar to the one I mailed for FLET-IMPLICIT-BLOCK) for consideration by X3J13. X3J13 then can vote on a ballot which essentially says ("we believe the ANSI standard for Common Lisp should reflect the following change/addition/enhancement" etc.) Until there's an official standard, there isn't an official standard. Until there's an official standard, the best an implementor can do is to document the ways in which the implementation differs from CLtL. The cleanup proposals, in their various draft forms, are a good indication of those places where CLtL is ambiguous, lacking, or subject to change; those cleanup proposals endorsed by X3J13 are a very good indication of what the ANSI standard will look like. However, the result of the standard process will be a single standard with (we hope) no options. An implementation will either conform or it will not. They are, of course, not official until there is an official standard that includes them. What's it all mean to you? Well, if you have strong opinions about any of the proposals, make sure your X3J13 representative hears about them. If you would like some additional changes, please give them to your X3J13 representative to submit. ∂03-Jan-88 1814 CL-Cleanup-mailer cleanup status Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jan 88 18:13:55 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 313876; Sun 3-Jan-88 21:14:04 EST Date: Sun, 3 Jan 88 21:13 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: cleanup status To: masinter.PARC@Xerox.COM cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880103-130343-1016@Xerox> Message-ID: <880103211335.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: 2 Jan 88 23:04:12 PST (Saturday) From: masinter.PARC@Xerox.COM Kent: I composed the following as a follow-up to mail to common-lisp@sail.stanford.edu. Would this address your concerns? It helps considerably, and it may be that it expresses the majority viewpoint. But there's one paragraph that really misses my preference. I've marked it below. - - - - - - - - - - - My recent message prompted enough debate that I thought I would clarify what I meant in my recent message about FLET. Some assumptions: X3J13 is attempting to define an ANSI standard for Common Lisp. X3J13 is starting with "Common Lisp the Language" by Guy L. Steele, Jr. and considering various clarifications, changes, additions, enhancements, modifications. The "cleanup committee" of X3J13 is considering those minor clarifications, changes, additions, enhancements, modifications as do not fit within the charter of the other subcommittee's of X3J13 (namely objects, windows & graphics, characters, iteration, compilation, validation, and possibly some others that I forget.) The process for various cleanups is that we (the cleanup committee) consider proposals either that we generate (e.g., based on Guy Steele's original list of proposed modifications), that we get from the community, or are based on mail to common-lisp@Sail.stanford.edu that seems to have reached some convergence. We produce a writeup (similar to the one I mailed for FLET-IMPLICIT-BLOCK) for consideration by X3J13. X3J13 then can vote on a ballot which essentially says ("we believe the ANSI standard for Common Lisp should reflect the following change/addition/enhancement" etc.) Until there's an official standard, there isn't an official standard. Until there's an official standard, the best an implementor can do is to document the ways in which the implementation differs from CLtL. If I had my way, this previous paragraph would be (what seems to me) radically different. I would say something more like: The information contained in these proposals is provided for informational purposes only and is not a suggestion that implementors should implement the changes mentioned. In fact, implementors are strongly encouraged not to implement any changes which are incompatible with CLtL, since the principle value of CLtL as a standard is that it has no competitors. If implementors pick and choose from CLtL and whichever of these modifications they find easy or interesting, the state of informal standardization in the Common Lisp community will be lessened. Extensions mentioned in these writeups which are compatible extensions can, of course, be added at any time but should not be described as Common Lisp. Until an ANSI or ISO Common Lisp standard is available, the name Common Lisp should refer only to what is in CLtL for the sake of everyone's sanity. These extensions may be referred to as "proposed extensions" which might someday be part of a future Common Lisp standard. The cleanup proposals, in their various draft forms, are a good indication of those places where CLtL is ambiguous, lacking, or subject to change; those cleanup proposals endorsed by X3J13 are a very good indication of what the ANSI standard will look like. However, the result of the standard process will be a single standard with (we hope) no options. An implementation will either conform or it will not. You might mention here that even though they have received endorsement in isolation, they may be later superseded by other proposals or rescinded on the basis of "new evidence". They are, of course, not official until there is an official standard that includes them. What's it all mean to you? Well, if you have strong opinions about any of the proposals, make sure your X3J13 representative hears about them. If you would like some additional changes, please give them to your X3J13 representative to submit. The rest of this is quite good. ∂03-Jan-88 2012 CL-Cleanup-mailer cleanup status Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jan 88 20:11:59 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Sun 3 Jan 88 23:11:43-EST Date: Sun, 3 Jan 1988 23:11 EST Message-ID: <FAHLMAN.12363805431.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: CL-Cleanup@SAIL.STANFORD.EDU Subject: cleanup status In-reply-to: Msg of 3 Jan 1988 21:13-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM> Well, for what it's worth, I tend to agree with Masinter on this rather than KMP. I think that it is unreasonable to tell implementors to stick with CLtL and to ignore all the individual proposals that have been adopted until ANSI and ISO formally adopt a new standard for all of Common Lisp. Maybe that has to be our legal position so that this committee doesn't get sued, but in a rational world (meaning one in which all the lawyers and those who traffic with them have been killed off), it would make sense for implementors to track these changes as they are adopted, or perhaps in discrete batches. I grant that it is wrong to pick and choose among these issues; in a given release you should adopt all of them up to some particular cutoff date, and should clearly state what you have done. Most of these items, after all, resolve some ambiguity in CLtL. To ignore them is to perpetuate a situation where no standardization currently exists. Some others (the error system and CLOS, but also some smaller ones) address omissions from CLtL that people are dealing with in various incompatible ways. In very few cases are we proposing a truly incompatible change, and where we do it is usually in some case where the existing situation is unworkable or is incompatible with some of the above-mentioned extensions. In each case, we have addressed the issue of how existing code can be updated to fit into the new system. Obviously it creates some portability problems if implementations track these changes with different delays, but I think that the situation we would get if we advised people to wait a few years until this is done would be much worse in practice. I'm not sure what the current official statement is on when we might expect an official standard or even an approved draft standard from X3J13, but we can't really expect people to stand pat until the great day arrives. -- Scott ∂04-Jan-88 0852 CL-Cleanup-mailer Re: cleanup status Received: from A.ISI.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 08:52:25 PST Date: 4 Jan 1988 11:50-EST Sender: MATHIS@A.ISI.EDU Subject: Re: cleanup status From: MATHIS@A.ISI.EDU To: KMP@SCRC-STONY-BROOK.ARPA Cc: cl-cleanup@SAIL.STANFORD.EDU Message-ID: <[A.ISI.EDU] 4-Jan-88 11:50:38.MATHIS> In-Reply-To: <880103211335.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I usually keep quiet on this list, but I think the proposed message of Larry's with Kent's modifications is coming pretty close to something we should distribute to the whole community. I get requests for X3J13 documents and send them out with some form of disclaimer - this is only a working draft of something under consideration. But people want to know what's going on. After the upcoming Palo Alto meeting, I expect we will have more documents which have achieved some form of voted status, but which we still do not want to be considered any kind of incremental version of the standard. The clean-up committee has been considering two kinds of things -- one, clarifications of the current CLtL; and two, things that go (slightly?) beyond the book. We should try to clearly identify which is which and put together appropriate information for wider distribution. People who want to be involved with the discussions and decision making should be working within X3J13; but we also have a responsibility for providing authoritative information on what we are doing and what implications it may have for current and future implementations of the "standard." Bob ∂04-Jan-88 1147 CL-Cleanup-mailer Re: New issue: FLET-DECLARATIONS Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Jan 88 11:47:42 PST Received: from Cabernet.ms by ArpaGateway.ms ; 04 JAN 88 11:45:03 PST Date: Mon, 4 Jan 88 11:44:49 PST From: Pavel.pa@Xerox.COM Subject: Re: New issue: FLET-DECLARATIONS In-reply-to: <19880101204506.6.MOON@EUPHRATES.SCRC.Symbolics.COM> To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Cc: Cl-Cleanup@SAIL.STANFORD.EDU, Hornig@STONY-BROOK.SCRC.Symbolics.COM Message-ID: <880104-114503-2255@Xerox> For the current practice section, the Xerox Lisp compiler (and maybe interpreter, I don't remember for sure and don't immediately have access to a Lisp image) already supports all of these declarations with the specified scope. Pavel ∂04-Jan-88 1309 CL-Cleanup-mailer Re: cleanup status Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Jan 88 13:09:35 PST Received: from Cabernet.ms by ArpaGateway.ms ; 04 JAN 88 13:09:08 PST Date: 4 Jan 88 13:08 PST From: Masinter.pa@Xerox.COM Subject: Re: cleanup status In-reply-to: various To: CL-Cleanup@SAIL.STANFORD.EDU Message-ID: <880104-130908-2402@Xerox> When all is said in done, it doesn't matter much what we "recommend" implementors do; they'll do what they please, including shipping things that don't implement lexical scoping correctly. It is probably just as well to leave out what we recommend to implementors and leave our recommendation to users, viz: note that these are proposed likely changes to the standard and to watch out for them. ∂04-Jan-88 1832 CL-Cleanup-mailer &REST lists Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Jan 88 18:32:43 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 314827; Mon 4-Jan-88 21:32:30 EST Date: Mon, 4 Jan 88 21:31 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: &REST lists To: Fahlman@C.CS.CMU.EDU cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <FAHLMAN.12364037774.BABYL@C.CS.CMU.EDU> Message-ID: <880104213156.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> [Common-Lisp removed; I can't bear to be heard by such multitudes. CL-Cleanup added.] Date: Mon, 4 Jan 1988 20:27 EST From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> Is there general agreement on whether it is valid Common Lisp to destructively modify (RPLACA, RPLACD) the list to which a &REST parameter is bound? I can't find a reference in CLtL for this. I think there's general agreement that &rest args are supposed to be righteous lists with indefinite extent, so RPLAC'ing them ought to be legal. However, this was one part of the Common Lisp spec that several early implementations deliberately chose to deviate from in the interest of greater efficiency. (Symbolics and TI were able to gain considerable efficiency by consing rest args on the stack.) Both companies had plans to fix this eventually, stack-consing only when the compiler could prove it was safe to do so, but I don't know if this has finally been accomplished and distributed to all users. I think TI has already fixed it. Symbolics' Cloe also fixes it. Symbolics Genera plans to fix it at some unspecified future date. But anyway, the rplaca/rplacd problem is not related to the issue of stack allocation. It's the following problem, which comes up in conventional architectures as well: (DEFVAR *MY-LIST* '(A B C)) (DEFUN FOO (&REST X) (EQ X *MY-LIST*)) (APPLY #'FOO *MY-LIST*) => T ;on Symbolics systems and probably ; many stock hardware implementations This implies that (DEFUN BAR (&REST X) (RPLACA X 'D)) (APPLY #'BAR *MY-LIST*) *MY-LIST* => (D B C) ;on Symbolics systems and probably many stock ; hardware implementations ∂04-Jan-88 2035 CL-Cleanup-mailer &REST lists Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Jan 88 20:35:28 PST Received: by labrea.stanford.edu; Mon, 4 Jan 88 20:35:23 PST Received: from kent-state.lucid.com by edsel id AA13360g; Mon, 4 Jan 88 20:27:31 PST Received: by kent-state id AA00227g; Mon, 4 Jan 88 20:29:31 PST Date: Mon, 4 Jan 88 20:29:31 PST From: Eric Benson <edsel!eb@labrea.stanford.edu> Message-Id: <8801050429.AA00227@kent-state.lucid.com> To: KMP@stony-brook.scrc.symbolics.com Cc: Fahlman@c.cs.cmu.edu, CL-Cleanup@sail.stanford.edu In-Reply-To: Kent M Pitman's message of Mon, 4 Jan 88 21:31 EST <880104213156.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Subject: &REST lists Date: Mon, 4 Jan 88 21:31 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Date: Mon, 4 Jan 1988 20:27 EST From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> Is there general agreement on whether it is valid Common Lisp to destructively modify (RPLACA, RPLACD) the list to which a &REST parameter is bound? I can't find a reference in CLtL for this. I think there's general agreement that &rest args are supposed to be righteous lists with indefinite extent, so RPLAC'ing them ought to be legal. ... I think TI has already fixed it. Symbolics' Cloe also fixes it. Symbolics Genera plans to fix it at some unspecified future date. But anyway, the rplaca/rplacd problem is not related to the issue of stack allocation. It's the following problem, which comes up in conventional architectures as well: (DEFVAR *MY-LIST* '(A B C)) (DEFUN FOO (&REST X) (EQ X *MY-LIST*)) (APPLY #'FOO *MY-LIST*) => T ;on Symbolics systems and probably ; many stock hardware implementations This implies that (DEFUN BAR (&REST X) (RPLACA X 'D)) (APPLY #'BAR *MY-LIST*) *MY-LIST* => (D B C) ;on Symbolics systems and probably many stock ; hardware implementations The Revised↑3 Report on Scheme specifies that the equivalent of a &REST argument must be a newly allocated list, to avoid precisely this problem. ∂05-Jan-88 0521 CL-Cleanup-mailer Issue: DECLARATION-SCOPE Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 5 Jan 88 05:21:13 PST Received: from WINTER.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 156176; Tue 5-Jan-88 08:21:23 EST Date: Tue, 5 Jan 88 08:21 EST From: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM> Subject: Issue: DECLARATION-SCOPE To: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <871119-175949-1009@Xerox> Message-ID: <19880105132119.9.HORNIG@WINTER.SCRC.Symbolics.COM> Issue: DECLARATION-SCOPING References: Section 9.1 (pp. 153-157). Category: CHANGE Edit history: V1: Hornig@Symbolics.COM -- 5 January 1988 Problem description: The description of the scope of declarations made with DECLARE is both unclear (although unambiguous) and arguably a mistake. The issue is whether the scope of some or all of the declarations includes code appearing in the non-body part of the special form containing the declaration. Proposal DECLARATION-SCOPING:LIKE-VARIABLE: For the purposes of this proposal, we divide all declarations introduced with DECLARE into two classes. When a declaration of a variable appears before the body of a special form or lambda-expression that binds that variable, the declaration is called normal'. All other declarations are called free'. This division replaces the division into pervasive, nonpervasive, and SPECIAL declarations appearing in CLtL. The scope of a normal' declaration is exactly the scope of the associated lexical variable or function. If the declaration is associated with a special variable, the scope is the scope the variable would have had if it had not been special. Free' declarations are scoped as if they appeared in a new LOCALLY form which surrounded the entire special form of which the declaration appears at the beginning of the body. SPECIAL declarations may be either normal', affecting both a binding and references, or free', affecting only references. TYPE and IGNORE declarations may only be normal'. (There has been some discussion in X3J13 of permitting free' TYPE declarations.) If Common Lisp is extended to permit declarations in FLET and LABELS forms, then declarations of functions (FTYPE, FUNCTION, INLINE, and NOTINLINE) which appear before the body of a FLET or LABELS form which defines that function are also normal'. Common Lisp is ambiguous about whether a variable may be bound several times by a single form. It has been proposed that multiple bindings be permitted for LET*, DO*, PROG* forms and for &AUX variables in lambda expressions. If multiple bindings are permitted, normal' declarations are treated as if there were a separate normal' declaration for each of the bindings. Examples: ;;; Some examples of free' and normal' declarations. (let ((a 1)) (declare (optimize speed)) ;this is a free' declaration (let ((b 2)) (declare (type integer b)) ;this is a normal' declaration (declare (special a)) ;this is a free' declaration ())) ;;; This example applies if you believe that FLET may have declarations. (flet ((foo (x) (1+ x))) (declare (notinline foo)) ;this is a normal' declaration (declare (notinline 1+)) ;this is a free' declaration ()) ;;; The following code is from Pavel. ;;; It produces 7 in existing implementations. ;;; If the proposal is adopted, it will produce 8. (let ((foo 6)) ;a special binding of FOO (declare (special foo)) ;normal' declaration (let ((foo 7)) ;a lexical binding of FOO (let ((foo (1+ foo))) ;is the second FOO special or not? (declare (special foo)) ;normal' declaration foo))) ;;; Treatment of LET* under the proposal if multiple bindings of the same name are allowed. ;;; This form produces the value 9. (let ((foo 6)) ;a special binding of FOO (declare (special foo)) ;normal' declaration (let ((foo 7)) ;a lexical binding of FOO (let* ((foo (1+ foo)) ;special binding, lexical reference (foo (1+ foo))) ;special binding, special reference (declare (special foo)) ;normal' declaration, applies to both bindings foo)) ;special reference Rationale: Normal' declarations are made to control a particular binding of a variable and should be scoped the same way as that binding. This is as true of normal' declarations which were pervasive under the old rules as it is of those that were not. Current practice: The normal'/free' division based on context replaces CLtL's static pervasive/nonpervasive/SPECIAL division. Most implementations implement the rules in CLtL. Symbolics currently implements rules based on Zetalisp which are different from both this proposal and Common Lisp. Symbolics plans to change to Common Lisp rules in the future. Cost to Implementors: The cost of implementing this change should be moderate. The change will be localized to a handful of places in the compiler and interpreter which apply declarations to variables. The other cost would be in providing tools for users to find programs whose meaning will change. Cost to Users: The proposal changes only the treatment of normal' declarations. This change will break very few existing production programs. It is possible to mechanically examine a program to determine whether its behavior would change under the new rules. This permits an implementation to provide a transition tool to ease conversion to the new definition. Cost of non-adoption: The ability of a normal' declaration to affect code outside the scope of the variable which it appears to declare has led to endless confusion and discussion at Symbolics, on the Common-Lisp mailing list, and elsewhere. It will continue to do so unless it is smoothed over somehow. Benefits: The costs of non-adoption will be avoided. Aesthetics: The distinction between normal' and free' declarations introduced by this proposal is a natural one. Discussion: A proposal to forbid free' declarations except in LOCALLY forms and a proposal to have free' declarations affect only the body were discarded as being too incompatible. The mapping from the existing pervasive/nonpervasive/SPECIAL division of declarations and the one proposed here is complex. In general, nonpervasive declarations are normal' and pervasive declarations are free'. SPECIAL declarations are either normal' or free' based on their context, and are no longer treated as a special case. Some historical support for having free' and normal' declarations: Date: Tue, 20 Dec 83 15:50 EST From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA> Subject: Declarations To: Common-Lisp@SU-AI.ARPA ... There are two disjoint classes of declaration: those that are attached to a particular variable binding, and those that are not. Note that I am not discussing proclamations here; they have their own scoping rules which are different from the rules for declarations. The scoping rule for the first kind of declaration is that it applies to precisely the text that is in the lexical scope of the variable binding with which it is associated. Such declarations are shadowed by a variable binding for the same name inside their scope. Since the lexical scoping rules are very well and precisely defined, we already understand everything about this kind of declaration. The scoping rule for the second kind of declaration is that it is pervasive. The declaration is attached to a lambda-expression or to a form (one of the special forms listed on page 125). The declaration applies to all text inside that expression or form; there are no special cases such as init-forms of LET or DO. Such declarations are shadowed by a conflicting declaration inside their scope. Possible names for the two kinds of declaration are "lexical" and "pervasive" or "variable" and "non-variable." ... ∂05-Jan-88 0938 CL-Cleanup-mailer Issue: DECLARATION-SCOPE Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Jan 88 09:37:59 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 315295; 5 Jan 88 12:35:50 EST Date: Tue, 5 Jan 88 12:35 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: DECLARATION-SCOPE To: cl-cleanup@SAIL.STANFORD.EDU cc: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM> In-Reply-To: <19880105132119.9.HORNIG@WINTER.SCRC.Symbolics.COM> Message-ID: <19880105173525.2.MOON@EUPHRATES.SCRC.Symbolics.COM> I'm strongly in favor of DECLARATION-SCOPING:LIKE-VARIABLE; I think it nicely settles a long-standing problem with Common Lisp. I support this even though I'm usually opposed to incompatible changes. ∂05-Jan-88 1345 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jan 88 13:45:23 PST Received: from Cabernet.ms by ArpaGateway.ms ; 05 JAN 88 13:45:00 PST Date: Tue, 5 Jan 88 13:44:36 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: DECLARATION-SCOPE In-reply-to: <19880105132119.9.HORNIG@WINTER.SCRC.Symbolics.COM> To: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM> Cc: cl-cleanup@SAIL.STANFORD.EDU Message-ID: <880105-134500-4150@Xerox> Unsurprisingly, since it's so close to what I informally proposed a year or two ago, I generally favor this proposal; it is much much better than the status quo. I do have a few concerns, though: 1) It is not clear to me that free declarations should cover the entire form. I note, in particular, that none of the discussion or rationale mentions the scoping of free declarations. The alternative that seems more natural to me has them covering only the body of the special form in which they appear, not the entire special form. Charles, could you discuss this? 2) I would very much like to see more detail in the proposal. In particular, I would like a complete listing of the types of declarations and their kinds (normal vs. free). Conceivably, a list of all of the macros and special forms supporting declarations and the scopes in each case should also be included. It may be, however, that this description is implied by the (sometimes nonexistent) definitions of the semantics of the various macros and special forms. 3) I don't like using the name normal'' for one half of a dichotomy, especially considering that the other half is named free''. Is there any reason not to call the others bound'' instead of normal''? Pavel ∂05-Jan-88 1430 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 5 Jan 88 14:30:28 PST Received: from WINTER.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 156483; Tue 5-Jan-88 17:30:38 EST Date: Tue, 5 Jan 88 17:30 EST From: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM> Subject: Re: Issue: DECLARATION-SCOPE To: Pavel.pa@Xerox.COM cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <880105-134500-4150@Xerox> Message-ID: <19880105223028.7.HORNIG@WINTER.SCRC.Symbolics.COM> Date: Tue, 5 Jan 88 13:44:36 PST From: Pavel.pa@Xerox.COM Unsurprisingly, since it's so close to what I informally proposed a year or two ago, I generally favor this proposal; it is much much better than the status quo. I do have a few concerns, though: 1) It is not clear to me that free declarations should cover the entire form. I note, in particular, that none of the discussion or rationale mentions the scoping of free declarations. The alternative that seems more natural to me has them covering only the body of the special form in which they appear, not the entire special form. Charles, could you discuss this? I was trying for greater compatibility. Most free' declarations are currently pervasive and apply to the entire form. The intent of the proposal was to leave them mostly as they are now. I would consider changing them to apply only to the body to be a separable and separate change. 2) I would very much like to see more detail in the proposal. In particular, I would like a complete listing of the types of declarations and their kinds (normal vs. free). Conceivably, a list of all of the macros and special forms supporting declarations and the scopes in each case should also be included. It may be, however, that this description is implied by the (sometimes nonexistent) definitions of the semantics of the various macros and special forms. When I started to do this, I got bogged down in all sorts of unrelated issues. For example, are free TYPE declarations permitted in Common Lisp? I didn't want this proposal to become a vehicle for all sorts of unrelated changes or claraifications to declaration processing. 3) I don't like using the name normal'' for one half of a dichotomy, especially considering that the other half is named free''. Is there any reason not to call the others bound'' instead of normal''? I'd love to use a better name. I hope others will comment on this. ∂05-Jan-88 1458 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Jan 88 14:58:10 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 315732; Tue 5-Jan-88 17:57:50 EST Date: Tue, 5 Jan 88 17:57 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Re: Issue: DECLARATION-SCOPE To: Pavel.pa@Xerox.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM, Hornig@ALDERAAN.SCRC.Symbolics.COM cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880105-134500-4150@Xerox>, <19880105173525.2.MOON@EUPHRATES.SCRC.Symbolics.COM>, <19880105132119.9.HORNIG@WINTER.SCRC.Symbolics.COM> Message-ID: <880105175714.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I concur with Moon's supportive remarks about Hornig's proposal. Date: Tue, 5 Jan 88 13:44:36 PST From: Pavel.pa@Xerox.COM ... It is not clear to me that free declarations should cover the entire form. ... We discussed this internally before Hornig sent the proposal. I and others here wanted free declarations to cover the entire form mainly because you need to be able to declare things in the lambda list of a DEFUN form and you can't put a LOCALLY around the outside of the DEFUN or the defun will no longer be at top level (and hence may not get compiled in some implementations). eg, consider (DEFUN FOO (&OPTIONAL (X Z) (Y Z)) (DECLARE (SPECIAL Z)) ...) If you don't have the proposed semantics, you have to write: (LOCALLY (DECLARE (SPECIAL Z)) (DEFUN FOO (&OPTIONAL (X Z) (Y Z)) ...)) which doesn't really work for the reasons cited above, or (DEFUN FOO (&OPTIONAL (X (LOCALLY (DECLARE (SPECIAL Z)) Z)) (Y (LOCALLY (DECLARE (SPECIAL Z)) Z))) ...) which works but is very tedious to write. ∂05-Jan-88 1644 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jan 88 16:44:00 PST Received: from Cabernet.ms by ArpaGateway.ms ; 05 JAN 88 16:42:09 PST Date: Tue, 5 Jan 88 16:41:43 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: DECLARATION-SCOPE In-reply-to: <880105175714.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> To: Hornig@ALDERAAN.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU Message-ID: <880105-164209-4496@Xerox> Kent points out that having free declarations cover the entire form allows one to conveniently cover the expressions in &optional, &key and &aux expressions. In some sense, those expressions are a part of the body'' of the lambda expression. Perhaps a more picky definition of body'' would be better than the blanket coverage. That is, let declarations in lambda forms cover the entire form but those in, say, LET forms only cover the body. This allows me to understand LET as a macro expanding into a simple call of a LAMBDA without any caveats about declaration parsing. Pavel ∂05-Jan-88 1922 CL-Cleanup-mailer Issue: DECLARATION-SCOPE Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 88 19:22:16 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Tue 5 Jan 88 22:22:19-EST Date: Tue, 5 Jan 1988 22:22 EST Message-ID: <FAHLMAN.12364320725.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: CL-Cleanup@SAIL.STANFORD.EDU Subject: Issue: DECLARATION-SCOPE DECLARATION-SCOPE:LIKE-VARIABLE looks good to me. I agree that "normal" is a somewhat loaded term. "Bound" seems wrong. How about calling these "binding-related declarations"? Not a critically important issue in any case. Is there any effective difference between saying that "free" declarations surround the whole form and saying that they surround only the body, but that the init forms are part of the body? If not, the former way of stating it seems clearer. -- Scott ∂05-Jan-88 1958 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jan 88 19:58:42 PST Received: from Cabernet.ms by ArpaGateway.ms ; 05 JAN 88 19:57:40 PST Date: Tue, 5 Jan 88 19:57:09 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: DECLARATION-SCOPE In-reply-to: <FAHLMAN.12364320725.BABYL@C.CS.CMU.EDU> To: CL-Cleanup@SAIL.STANFORD.EDU Message-ID: <880105-195740-4775@Xerox> Scott asks, Is there any effective difference between saying that "free" declarations surround the whole form and saying that they surround only the body, but that the init forms are part of the body? If not, the former way of stating it seems clearer.'' I assume that this is addressed to my suggestion that free declarations in LAMBDA-forms cover the default-value expressions in &optional, &aux, and &key parameters. The point is that I would rather that such declarations didn't cover the init-expressions in LET and the bodies of the lexical functions in FLET and LABELS. If you macroexpand LET in the obvious way, with the declarations inside the LAMBDA form, then the init forms are outside of the scope of the free declarations, as I would desire. I think that the reason that I want this is that in the following: (let ((foo init-expression)) (declare ((bound-declaration foo) (free-declaration))) body) the free declaration covers the init expression while the bound one does not. I think of declarations as appearing at the head of the code that they cover and so I'd want both of these declarations to cover only the body. In fact, I think that I would rather that the free declarations in a LAMBDA form only cover the real body, and not the default-value expressions, for just this reason. I guess that I'm not impressed by Kent's example since I don't see very much use for local declarations around default-value expressions. Perhaps he'll show me some startlingly clear-cut example of this being useful. Bound declarations, on the other hand, should have identical scope with the variable to which they refer. This seems intuitive since they are, in effect, changing the overal meaning of that variable. Pavel ∂06-Jan-88 0736 CL-Cleanup-mailer Issue: DECLARATION-SCOPE Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 07:36:46 PST Received: ID <RAM@C.CS.CMU.EDU.#Internet>; Wed 6 Jan 88 10:36:51-EST Date: Wed, 6 Jan 1988 10:29 EST Message-ID: <RAM.12364453185.BABYL@> Sender: RAM From: Ram at c.cs.cmu.edu To: Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM> Cc: CL-Cleanup at SAIL.STANFORD.EDU, Hornig at ALDERAAN.SCRC.Symbolics.COM, Moon at STONY-BROOK.SCRC.Symbolics.COM, Pavel.pa at Xerox.COM Subject: Issue: DECLARATION-SCOPE In-reply-to: Msg of 5 Jan 1988 17:57-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM> ReSent-Date: Wed 6 Jan 88 10:36:50-EST ReSent-From: Rob.MacLachlan@C.CS.CMU.EDU ReSent-To: cl-cleanup@SAIL.STANFORD.EDU ReSent-Message-ID: <12364454448.17.RAM@C.CS.CMU.EDU> Date: Tuesday, 5 January 1988 17:57-EST From: Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM> cc: CL-Cleanup at SAIL.STANFORD.EDU Re: Issue: DECLARATION-SCOPE [...] I and others here wanted free declarations to cover the entire form mainly because you need to be able to declare things in the lambda list of a DEFUN form and you can't put a LOCALLY around the outside of the DEFUN or the defun will no longer be at top level (and hence may not get compiled in some implementations). I think that this argument is pretty weak, since the concept of "at top level" doesn't belong in the language (and isn't currently defined). Any implementation that doesn't compile a definition when a LOCALLY (or anything else) is wrapped around it is a broken implementation. Rob ∂06-Jan-88 1334 CL-Cleanup-mailer cleanup status Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 13:34:21 PST Received: by labrea.stanford.edu; Wed, 6 Jan 88 13:34:23 PST Received: from bhopal.lucid.com by edsel id AA20541g; Wed, 6 Jan 88 12:48:49 PST Received: by bhopal id AA11867g; Wed, 6 Jan 88 12:51:10 PST Date: Wed, 6 Jan 88 12:51:10 PST From: Jon L White <edsel!jonl@labrea.stanford.edu> Message-Id: <8801062051.AA11867@bhopal.lucid.com> To: labrea!MATHIS%A.ISI.EDU@labrea.stanford.edu Cc: labrea!cl-cleanup%SAIL@labrea.stanford.edu In-Reply-To: MATHIS@A.ISI.EDU's message of 4 Jan 1988 11:50-EST <[A.ISI.EDU] 4-Jan-88 11:50:38.MATHIS> Subject: cleanup status re: People who want to be involved with the discussions and decision making should be working within X3J13; but we also have a responsibility for providing authoritative information on what we are doing and what implications it may have for current and future implementations of the "standard." This seems to me a succinct, reasonable statement of policy regarding "outsiders". There's probably no need for us to lecture the vendors on how closely the must adhere to CLtL -- it's their responsibility to document their deviations and extensions. -- JonL -- ∂06-Jan-88 1414 CL-Cleanup-mailer cleanup status Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 6 Jan 88 14:14:24 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 316518; Wed 6-Jan-88 17:13:58 EST Date: Wed, 6 Jan 88 17:13 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: cleanup status To: edsel!jonl@labrea.stanford.edu cc: CL-Cleanup@SAIL.STANFORD.EDU, MATHIS@ADA20.ISI.EDU In-Reply-To: <8801062051.AA11867@bhopal.lucid.com> Message-ID: <880106171310.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Wed, 6 Jan 88 12:51:10 PST From: Jon L White <edsel!jonl@labrea.stanford.edu> ... There's probably no need for us to lecture the vendors on how closely the must adhere to CLtL -- it's their responsibility to document their deviations and extensions. I'm sorry, but I disagree. I do not believe that we with our vendors' hats on do have the wisdom or the freedom from conflict of interest to make that decision correctly. When there was only CLtL, it was obvious what was the right thing and what was not. It is no longer obvious because our committee is randomizing things. Our committee must speak clearly to the community about what we intend so that people who want to adhere to that advice can do so. It is in vendors' best interest to add as many whizzy features as they can because it makes for more bullet items on marketing literature, because bug fixes sound (naively) like an improvement over non-bug fixes, and because the more you can make your implementation different than CL, the more locked into your product your customer base becomes. On the other hand, I believe it is in the community's best interest for there to be a clear source of authority. For better or worse, a standard exists with certain features people can depend upon. If people go changing things around at random, application vendors get screwed trying to keep up with the different rates of change on the different platforms. I'm speaking from experience as a Macsyma maintainer (large 3rd party product) not from my current position as a lisp developer. In Cloe, the LISP package does exactly what the LISP package in CLtL says it should. If we wanted to extend anything, we did it on a proprietary package that shadowed the LISP symbol. For example, CLOE:IF takes a body but LISP:IF is true to the standard. CLOE:CHAR-EQUAL fixes the CHAR-EQUAL mess, but LISP:CHAR-EQUAL does what CLtL losingly says it should. I think this is the right approach for all vendors to take until a standard is reached. If we don't say this to the community, who can? If chaos results, who is to blame but us? ∂06-Jan-88 1804 CL-Cleanup-mailer cleanup status Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 18:04:23 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Wed 6 Jan 88 21:04:28-EST Date: Wed, 6 Jan 1988 21:04 EST Message-ID: <FAHLMAN.12364568696.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA> Cc: CL-Cleanup@SAIL.STANFORD.EDU Subject: cleanup status In-reply-to: Msg of 6 Jan 1988 17:13-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM> If chaos results, who is to blame but us? Well, maybe there is some middle ground between chaos and living with CLtL, as is, for two or three more galactic rotations. If those are the only two choices, I'll take chaos. ∂06-Jan-88 2034 CL-Cleanup-mailer Issue: DECLARATION-SCOPE Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 20:34:17 PST Received: by labrea.stanford.edu; Wed, 6 Jan 88 20:34:19 PST Received: from bhopal.lucid.com by edsel id AA00386g; Wed, 6 Jan 88 20:23:40 PST Received: by bhopal id AA14597g; Wed, 6 Jan 88 20:26:00 PST Date: Wed, 6 Jan 88 20:26:00 PST From: Jon L White <edsel!jonl@labrea.stanford.edu> Message-Id: <8801070426.AA14597@bhopal.lucid.com> To: labrea!Hornig%ALDERAAN.SCRC.Symbolics.COM@labrea.stanford.edu Cc: labrea!cl-cleanup%SAIL@labrea.stanford.edu In-Reply-To: Charles Hornig's message of Tue, 5 Jan 88 08:21 EST <19880105132119.9.HORNIG@WINTER.SCRC.Symbolics.COM> Subject: Issue: DECLARATION-SCOPE I welcome this proposal wholeheartedly -- it irons out another of those brainos for which no one can now even remember a decent rationale. However, there is one point I'd like to see pressed further. You propose: The scope of a normal' declaration is exactly the scope of the associated lexical variable or function. . . . SPECIAL declarations may be either normal', affecting both a binding and references, or free', affecting only references. TYPE and IGNORE declarations may only be normal'. (There has been some discussion in X3J13 of permitting free' TYPE declarations.) I think it is very shortsighted to limit the TYPE and IGNORE declarations this way. In so far as IGNORE is merely advice to the compiler to stop issuing worthless "bound, but unreferenced" warning messages, there is no incompatiblity with it being in a LOCALLY form; it just means inhibit warning messages for instances found in this lexical range. Now the probable rationale for limiting the TYPE declaration must have been so that it could affect the way in which bindings occur [e.g., in pdp10 MacLisp, a flonum is stored on a float pdl, but a regular variable is stored on the regpdl.] It is all well and fine if the user-supplied scoping information can include the binding; but what if it can't? is it so bad that the supplied information can be only partly useful in optimization? Isn't it much better to permit the compiler to use the useful part than to prohibit it from noticing at all? Take, for example: (let ((x <some-value>)) (if (floatp x) (locally (type float x) (+ x 3.4)) (if (integerp x) (ash x -3) (error "What the heck")))) If the compiler is prohibited from noticing the LOCALLY type declaration, then it can't open-code the "+" operation; otherwise, it can open-code it. True, it will be fetching x from a regular "pointer" location rather than from a floating-point register (or whatever), but at least it will be doing something that can make an order of magnitude difference in speed (at least with Lucid's compiler). After all, nothing compels a conforming compiler to do anything *different* with a binding when it notices a TYPE declaration affecting the variable being bound. This particular problem may be more than you wanted to bite off; if so, maybe I'll be able to find the time to submit a separate proposal on it. But since you've taken the plunge already on declaration scoping (and since I've been so busy with product deadlines etc.) I thought you may want to field the whole matter. -- JonL -- ∂06-Jan-88 2318 CL-Cleanup-mailer Issue: DECLARE-MACROS Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Jan 88 23:18:05 PST Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 88 23:18:53 PST Date: 6 Jan 88 23:18 PST From: Masinter.pa@Xerox.COM Subject: Issue: DECLARE-MACROS to: cl-cleanup@sail.stanford.edu Message-ID: <880106-231853-6452@Xerox> I thought that while there were some objections to DECLARE-MACROS the proposal recieved very strong endorsement from many members of the community. I thought we needed to address the objections and resubmit it. Does anyone else have any notes or recollection? ----- Begin Forwarded Messages ----- Return-Path: <Moon@STONY-BROOK.SCRC.Symbolics.COM> Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by Xerox.COM ; 04 JAN 88 19:09:02 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 314856; Mon 4-Jan-88 22:08:36 EST Date: Mon, 4 Jan 88 22:08 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Re: New issue: FLET-DECLARATIONS To: Masinter.pa cc: Moon@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <880104-170649-2879@Xerox> Message-ID: <19880105030822.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: 4 Jan 88 17:06 PST From: Masinter.pa@Xerox.COM I think we should presume in future cleanup issues that DECLARE-MACROS has been accepted. Your writeup sentence "This rule is required in order to permit macros to expand into DECLARE, as noted above." should probably be changed. Really? I had pretty well assumed that DECLARE-MACROS was being withdrawn, because so many people had surfaced who depend on macros expanding into declarations, so that it would be a significant incompatible change. From a language cleanliness point of view, I'd like macros not to expand into declarations, but from a practical point of view I no longer care; at one point I had mistakenly claimed that this was a major source of slowness in our compiler, but that turned out not to be true. It's related to a source of slowness, and fixing the slowness is made more complex by the need to worry about macros expanding into declarations, but removing the feature from the language really wouldn't help us very much. I was just confused on that point. ----- End Forwarded Messages ----- ∂06-Jan-88 2331 CL-Cleanup-mailer Cleanup status Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Jan 88 23:29:07 PST Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 88 23:29:40 PST Date: 6 Jan 88 23:28 PST From: Masinter.pa@Xerox.COM Subject: Cleanup status To: CL-Cleanup@SAIL.STANFORD.EDU Message-ID: <880106-232940-6463@Xerox> OK, here's another try. My recent message prompted enough debate that I thought I would clarify what I meant in my recent message about FLET. Some assumptions: X3J13 is attempting to define an ANSI standard for Common Lisp. X3J13 is starting with "Common Lisp the Language" by Guy L. Steele, Jr. and considering various clarifications, changes, additions, enhancements, modifications. The "cleanup committee" of X3J13 is considering those minor clarifications, changes, additions, enhancements, modifications as do not fit within the charter of the other subcommittee's of X3J13 (namely objects, windows & graphics, characters, iteration, compilation, validation, and possibly some others that I forget.) The process for various cleanups is that we (the cleanup committee) consider proposals either that we generate (e.g., based on Guy Steele's original list of proposed modifications), that we get from the community, or are based on mail to common-lisp@Sail.stanford.edu that seems to have reached some convergence. We produce a writeup (similar to the one I mailed for FLET-IMPLICIT-BLOCK) for consideration by X3J13. X3J13 then can vote on a ballot which essentially says ("we believe the ANSI standard for Common Lisp should reflect the following change/addition/enhancement" etc.) The cleanup proposals, in their various draft forms, are a good indication of those places where CLtL is ambiguous, lacking, or subject to change; those cleanup proposals endorsed by X3J13 are a very good indication of what the ANSI standard will look like. However, the result of the standard process will be a single standard with (we hope) no options. An implementation will either conform or it will not. If implementors want our advice (unlikely as that might be), we'd advise them to quickly adopt those proposals which resolve ambiguities in CLtL and (as "Proposed Extensions likely to be in the Common Lisp standard") to implement those proposals that are extensions. However, we would advise implementors not to release (at least as "Common Lisp") implementations with the proposals that are incompatible changes; to do otherwise would increase the diversity of "Common Lisp" implementations for users, rather than decrease it. Most strongly, of course, we'd advise implementors to document their implementation carefully in these areas, so that users might at least #+ and #- around problem areas. Part of the reason is that, even though the proposals have received endorsement in isolation, they may be later superseded by other proposals or rescinded on the basis of "new evidence". What's it all mean to users of Common Lisp? Well, of course, we hope the proposals themselves cntain useful information, and explain why there was an issue at all, and the reasons for our choice. If you have strong opinions about any of the proposals, make sure your X3J13 representative hears about them. If you would like some additional changes, please give them to your X3J13 representative to submit. ∂06-Jan-88 2356 CL-Cleanup-mailer cleanup status Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 23:56:48 PST Received: by labrea.stanford.edu; Wed, 6 Jan 88 23:56:35 PST Received: from bhopal.lucid.com by edsel id AA00572g; Wed, 6 Jan 88 21:52:33 PST Received: by bhopal id AA14990g; Wed, 6 Jan 88 21:54:55 PST Date: Wed, 6 Jan 88 21:54:55 PST From: Jon L White <edsel!jonl@labrea.stanford.edu> Message-Id: <8801070554.AA14990@bhopal.lucid.com> To: labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu Cc: labrea!CL-Cleanup%SAIL@labrea.stanford.edu, labrea!MATHIS%ADA20.ISI.EDU@labrea.stanford.edu In-Reply-To: Kent M Pitman's message of Wed, 6 Jan 88 17:13 EST <880106171310.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Subject: cleanup status re: If we don't say this to the community, who can? The validation committee. There seem to be two choices here: -- restrict information as to how the cleanup is going, as a means of exerting authority over the vendors (whom you say you don't trust). -- disseminate information so that cooperative vendors, who are continuing their individual development plans anyway, can act accordingly. Scott and I favor the latter approach; and I'd just as soon leave the policing of vendors up to another authority [maybe even the marketplace?]. I suggest you take your concerns to the validation committee. Maybe that will resurrect it from it's current death-like status. -- JonL -- ∂06-Jan-88 2358 CL-Cleanup-mailer cleanup status Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 88 23:58:10 PST Received: by labrea.stanford.edu; Wed, 6 Jan 88 23:57:57 PST Received: from bhopal.lucid.com by edsel id AA00588g; Wed, 6 Jan 88 21:57:35 PST Received: by bhopal id AA15006g; Wed, 6 Jan 88 21:59:58 PST Date: Wed, 6 Jan 88 21:59:58 PST From: Jon L White <edsel!jonl@labrea.stanford.edu> Message-Id: <8801070559.AA15006@bhopal.lucid.com> To: labrea!Fahlman%C.CS.CMU.EDU@labrea.stanford.edu Cc: labrea!cl-cleanup%sail@labrea.stanford.edu In-Reply-To: "Scott E. Fahlman"'s message of Wed, 6 Jan 1988 21:04 EST <FAHLMAN.12364568696.BABYL@C.CS.CMU.EDU> Subject: cleanup status re: Well, maybe there is some middle ground between chaos and living with CLtL, as is, for two or three more galactic rotations. If those are the only two choices, I'll take chaos. Hmmm, there's one viewpoint that says "Lots of CLtL *is* chaos". In fact, isn't that why this committee exists in the first place? to "clean up" the chaos? -- JonL -- ∂07-Jan-88 0026 CL-Cleanup-mailer your proposed revision Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 7 Jan 88 00:26:42 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 316777; Thu 7-Jan-88 03:26:13 EST Date: Thu, 7 Jan 88 03:25 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: your proposed revision To: Masinter.PARC@Xerox.COM cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880106-232940-6463@Xerox> Message-ID: <880107032551.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> This looks better, and maybe it's the best I can hope for within this group, which apparently largely disagrees with me. But for the record, I'm absolutely not happy with any recommendation that people run out and implement any of this unless we name the subsets which we are encouraging them to implement in some way that does not change daily. If it does turn out that we change any of these, we may end up feeling guilty for having encouraged people to adopt what even now seem like compatible changes because in the future we will have to consider any further change as not only potentially in conflict with CLtL but also potentially in conflict with the supposedly non-binding changes we announced earlier and strongly encouraged people to rush out and implement. Moreoever, even what seems like a compatible change will cause headache for people who learn to depend on the new feature and then port to a CL that doesn't have it. Since I myself am involved in the maintenance of a Lisp, and since I'm very conservative about what goes into that Lisp, I will be unhappy if our users come complaining to me that other lisps support one of these extensions (with no official status) and claims that it is my Lisp which is faulty for not providing it. I think it is unfair of this committee to put me in such a position and I think that's exactly what you are doing. I will be in a damned-if-i-do and damned-if-i-don't position if you make these changes non-binding while still urging everyone to rush out and implement them. I would rather see you simply observe that it is possible to make some extensions now if they want, but not do any form of encouraging or urging. Even an explicit plug for implementors who want to maintain the status quo would be in order in my opinion. In any case, I think that explicit wording should be given in your message saying that even if they provide these proposed changes, they should document them as deviations from the standard. Your remarks about "proposed changes likely to..." are not clear about whether this is a phrase they should say to themselves to keep their conscience clean or to their customers for the sake of truth in advertising. I think both, but I can see some people preferring to do only the former. Mostly, I feel like I am saying the same thing over and over and getting nowhere. I think you understand my position, so if I haven't convinced you of its importance either to me personally, to me as an implementor, or to the community at large, perhaps it is about time for me to give up and be silent. Just didn't want anyone to construe that silence as some form of consent... ∂07-Jan-88 0555 CL-Cleanup-mailer Issue: DECLARATION-SCOPE Received: from [128.81.41.109] by SAIL.STANFORD.EDU with TCP; 7 Jan 88 05:55:26 PST Received: from WINTER.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 156925; Thu 7-Jan-88 08:55:37 EST Date: Thu, 7 Jan 88 08:55 EST From: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM> Subject: Issue: DECLARATION-SCOPE To: Jon L White <edsel!jonl@labrea.stanford.edu> cc: cl-cleanup@sail.stanford.edu In-Reply-To: <8801070426.AA14597@bhopal.lucid.com> Message-ID: <19880107135530.3.HORNIG@WINTER.SCRC.Symbolics.COM> Date: Wed, 6 Jan 88 20:26:00 PST From: Jon L White <edsel!jonl@labrea.stanford.edu> I welcome this proposal wholeheartedly -- it irons out another of those brainos for which no one can now even remember a decent rationale. However, there is one point I'd like to see pressed further. You propose: The scope of a normal' declaration is exactly the scope of the associated lexical variable or function. . . . SPECIAL declarations may be either normal', affecting both a binding and references, or free', affecting only references. TYPE and IGNORE declarations may only be normal'. (There has been some discussion in X3J13 of permitting free' TYPE declarations.) I think it is very shortsighted to limit the TYPE and IGNORE declarations this way. In so far as IGNORE is merely advice to the compiler to stop issuing worthless "bound, but unreferenced" warning messages, there is no incompatiblity with it being in a LOCALLY form; it just means inhibit warning messages for instances found in this lexical range. .... This particular problem may be more than you wanted to bite off; if so, maybe I'll be able to find the time to submit a separate proposal on it. But since you've taken the plunge already on declaration scoping (and since I've been so busy with product deadlines etc.) I thought you may want to field the whole matter. My intention was only to restate what was already in CLtL. I would be happy to see a proposal to permit free' TYPE declarations. I am trying not to let the DECLARATION-SCOPING proposal get side-tracked again trying to become a "fix all bugs with declarations" proposal. ∂07-Jan-88 1224 CL-Cleanup-mailer your proposed revision Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 7 Jan 88 12:24:00 PST Return-Path: <gls@Think.COM> Received: from kali.think.com by Think.COM; Thu, 7 Jan 88 15:23:37 EST Received: by kali.think.com; Thu, 7 Jan 88 15:23:33 EST Date: Thu, 7 Jan 88 15:23:33 EST From: gls@Think.COM Message-Id: <8801072023.AA02073@kali.think.com> To: Masinter.PARC@xerox.com, KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu In-Reply-To: Kent M Pitman's message of Thu, 7 Jan 88 03:25 EST <880107032551.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Subject: your proposed revision I think Larry has done a very good job on the latest draft. However, I must agree with KMP on one point. In our capacity as members of X3J13, I don't think it is wise to encourage anyone to depend on any action of X3J13 except for a draft explicitly voted out for public examination. To do otherwise could conceivably put us in a position of liability. The minutes of our meetings and the records of our votes are available, and anyone can get them and choose whether or not to track our progress. It is not our place, however, to encourage (or discourage) someone in this. --Guy ∂11-Jan-88 1150 CL-Cleanup-mailer paper for IWoLES Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 88 11:49:56 PST Received: from Cabernet.ms by ArpaGateway.ms ; 11 JAN 88 11:50:13 PST Date: 11 Jan 88 11:47 PST From: Masinter.pa@Xerox.COM Subject: paper for IWoLES To: cl-cleanup@Sail.stanford.edu Message-ID: <880111-115013-4302@Xerox> I've committed to producing a paper for IWoLES (International Workshop on LISP Evolution and Standardization) next month. I took my draft letter to Common Lisp and a few other things and tried to turn it into a paper. I need to send this off right away, but I thought, since it purports to speak for the cleanup process as a whole, I should run it by you. \documentstyle{article} \title{Common Lisp Cleanup} \author{Larry Masinter} \date{10 January 1988} \evensidemargin=0cm \oddsidemargin=0cm \topmargin=0cm \textheight=22.5cm \textwidth=16.5cm \columnwidth=\textwidth \begin{document} \maketitle This paper describes some of the activities of the cleanup'' sub-committee of the ANSI X3J13 group. It describes some fundamental assumptions of our work in this sub-committee, the process we use to consider changes, and a sampler of some of the changes we are considering. \section{Assumptions.} We believed the only reasonable way to obtain a standard for Lisp was to start with a known, widely implemented description, namely Common Lisp the Language'' by Guy L. Steele Jr. ({\em CLtL}) and to consider individually various clarifications, changes, additions, enhancements, modifications. Common Lisp works''. It is widely implemented. Common Lisp has a relatively small kernel of semantics, facilities for extensions, and a large library of data types and operations on them. It is a good starting point for a Lisp standard. We do not believe that it is necessary to start over to design a good Lisp standard. Even if one favors modifications to the fundamentals of the language semantics (e.g., function and variable name scoping), most of the library of data types and operations of Common Lisp will continue to form a good basis for applications and it is valuable to clarify the operation of the library. There are three kinds of problems with CLtL we would like to resolve in creating a standard. First, CLtL had its roots in a user's level description of a programming system; although it is wonderfully specific as user manuals go, there are numerous places that allow more implementation flexibility than is desirable in a standard. In a standard, we would expect that ambiguities to be either eliminated or else {em explicitly} allowed. Secondly, CLtL was written and published without extensive prior use of some of its features; a few have turned out to be unworkable or useless and not implemented. We hope to change or remove those features. Third, we've discovered that there are features that exist in nearly in every implementation but with different names and calling conventions or (in a very few instances) are logical extensions of the current specification. We would like to augment the standard by providing access from the standard language to those features. \section {The process.} The cleanup subcommittee considers those minor changes that are not being addressed by any of the other single-topic subcommittees of X3J13 (objects, windows and graphics, characters, iteration, compilation, validation, and a few others.) We consider proposals both internally generated by members of the cleanup committee or are received from members of the community. Almost all work of the committee is handled via electronic mail. We rarely meet as a group in person. Most decisions are made by consensus. When we cannot agree by consensus whether to endorse a proposal, we may present it to X3J13 for voting with the various points of view represented in the writeup; we believe our responsibility is to fully describe the issues, and allow the larger community to vote. We attempt to analyze the costs and benefits for each proposed modification. Each proposal, considered individually, must make the language better--enough better to be worth the cost of making a change. To this end, we require that each proposal be accompanied by an analysis of the various costs and benefits. Of course, there are conflicts in the interpretation of costs and benefits. There are some general principles of good programming language design: programs should be easy to read; programs should be easy to write; the language should allow users to write efficient prgrams. These goals sometimes work against each other: for example, adding features makes the job easier for the program writer, but harder for the reader. These conflicts in desired make the design process difficult, because it is not possible to optimize all of the design goals simultaneously. The process of explicitly addressing costs and benefits has successfully eliminated arguments based merely on personal preference. Most often, what initially seems like a matter of taste in fact has roots in a more explicit judgment of benefit over cost. By adopting an explicit format for those items, we've managed to expose the underlying principles. We only consider complete'' proposals. While we've discussed some open problems, we generally avoid design by committee.'' Rather, after some initial discussion, a single individual will produce a proposal. \subsection {Elements of a proposal.} These are the important elements of the cleanup'' proposals we develop: \paragraph {Category.} We attempt to distinguish between a clarification (proposal to resolve an ambiguity or case of under-specified situation in CLtL), a change (proposal to make an incompatible change to the language), and an addition (proposal to add an upward compatible feature.) The category of a proposal will likely dictate what a responsible implementor of Common Lisp would do prior to the acceptance of a new draft standard; e.g., clarifications can be adopted immediately, while incompatible changes might wait until there is an official standard or be implemented in a separate "package", at which time incompatible changes can be adopted all at once. \paragraph {Problem Description.} Suprisingly, requiring an explicit description of the problem, indpendent of some design for its solution, has been most helpful in avoiding unnecessary changes to the language. Why does anything need to happen at all? (If it ain't broke, don't fix it.'') \paragraph {Proposal.} We expect proposals to separate out the description of the proposal from the arguments for it. Again, this simple measure helps lend a great deal of objectivity to the process. While our proposals are expected to be precise and accompanied by test cases and examples, we generally look to the editor and editorial committee of X3J13 to actually produce the specification that reflects the proposal. \paragraph {Current practice.} What do current Common Lisp implementations do? Current implementations (at least implementation that attempt to be faithful to CLtL) often give us good indication of what implementors believed CLtL to mean. We put some faith that they attempted a reasonable interpretation. In cases where no implementation exactly matches CLtL, this is a good indication that CLtL's description is flawed. \paragraph {Costs.} Every change or resolution costs something to adopt: to implementors (What does it take to change a non-conforming implementation to a conforming one? Does this affect some, one, many functions? Is public-domain code available?), and to current users (to convert existing user code or tools.) We hope to give a measure of whether the changes required for each are small or large. In general, we take cost to users more seriously than cost to implementors. \paragraph {Benefits.} Benefits are diverse: our goals are to improve the portability of the language, its performance, the cleanliness of its semantics, and its aesthetics. Our major concern is with allowing important applications of Common Lisp to work well across many different implementations. \section {Open issues.} \renewcommand{\descriptionlabel}[1]{\hspace\labelsep$\bullet} This section lists most of the proposals currently being considered, in an extremely abbreviated form. Many of these issues have {\em not} been adopted and many {\em will not be}; they are listed here to give an idea of the kinds of issues the cleanup committee is currently addressing. New issues--especially that has affected the portability of any current program--are welcome. {\em Reminder: these proposals have not been accepted; they are not part of any standard. This is a list of issues considered, not of issues passed. While some have been endorsed by X3J13, others are likely to be rejected.} \paragraph {Clarifications.} These are cases where CLtL does not specify behavior; usually these are also cases where implementations actually differ and users have found code non-portable. \begin{description} \item[append-dotted] \verb|(APPEND '(A . B) '(E F))| is not an error, returns \verb|(A E F)|. \item[colon-number] \verb|:123| is an error and not a keyword symbol. \item[declaration-scope] Specify more precisely the scope of declarations. \item[compiler-warning-break] \verb|*BREAK-ON-WARNINGS*| applies to compiler warnings too. \item[flet-implicit-block] The bodies of functions defined in \verb|FLET|, \verb|MACROLET| and \verb|LABELS| have implicit \verb|BLOCK|s wrapped around them in the same manner as \verb|DEFUN| and \verb|DEFMACRO| bodies. \item[defvar-documentation] In \verb|(DEFVAR x y documentation)|, documentation is not evaluated. \item[defvar-initialization] In \verb|(DEFVAR x y)|, y is evaluated when \verb|DEFVAR| is. \item[pathname-stream] Pathnames can be obtained only from streams opened with pathnames (or synonym streams. \item[push-evaluation-order] \verb|(PUSH (A) (CAR (B)))| evaluates\verb|(A)| before \verb|(B)|. \item[remf-destruction-unspecified] What side effects are allowed/possible by REMF, NREVERSE etc.? \item[setf-method-for-symbols] Examples in CLtL of \verb|SETF|-method for symbols and \verb|LDB| are inconsistent with left-to-right evaluation order. Change them. \item[shadow-already-present] What does SHADOW do if symbol is already there? \item[sharpsign-plus-minus-package] Elements of \verb|*FEATURES*| are in the keyword package. \item[sharpsign-plus-minus-number] Numeric \verb|*FEATURES*| are not allowed. \item[unwind-protect-non-local-exit] Exit from cleanup clause of \verb|UNWIND-PROTECT| overrides any unwind in progress. \item[adjust-array-displacement] More precise rules for interaction of \verb|ADJUST-ARRAY| and displaced arrays. \item[do-symbols-duplicates] Can \verb|DO-SYMBOLS| visit a symbol more than once? \item[format-uparrow-scope] What is the scope of \verb|~↑| in \verb|FORMAT| loops? \item[function-argument-type-semantics] What are the semantics of argument types in \verb|FUNCTION| declarations? \item[lisp-symbol-redefinition] It is illegal (non-portable) to redefine or shadow with \verb|FLET|, \verb|MACROLET|, \verb|LABELS| functions defined in CLtL. \item[princ-character] \verb|(PRINC #\C)| prints C. \item[import-setf-symbol-package] \verb|IMPORT| has no effect on a symbol's home package. \item[format-op-c] \verb|(format t "~C" '#\C)| prints C. \item[disassemble-side-effect] \verb|DISASSEMBLE| has no side-effects. \end {description} \paragraph {Additions.} These are some new features we are considering adding to Common Lisp. \begin {description} \item[aref-1d] Add \verb|(ROW-MAJOR-AREF X N)| to reference n-th row-major element of an array. \item[format-comma-interval] Add option to \verb|FORMAT| to specify intervals other than 3 between digit delimiter character. \item[get-setf-method-environment] Add an environment argument to \verb|GET-SETF-METHOD|. \item[keyword-argument-name-package] Allow arbitrary symbols as keyword-argument tokens. \item[sequence-functions-exclude-arrays] Allow some sequence functions to work on multi-dimensional arrays. \item[assoc-rassoc-if-key] Add \verb|:KEY| argument to \verb|ASSOC-IF|. \item[reduce-argument-extraction] Add \verb|:KEY| argument to \verb|REDUCE|. \item[setf-function-vs-macro] Allow {\tt(DEFUN (SETF FN) (VALUE ARGUMENTS ...) ...)} to define what \verb|(SETF (FN ...) value)| means. \item[pathname-subdirectory-list] Recommend that directory component of a pathname be a list in a hierarchical file system. \item[format-atsign-colon] \verb|@:| and \verb|:@| are the same in format directives. \item[stream-class-access] Add functions for finding out stream class, accessing parts. \item[structure-definition-access] Add functions for getting at \verb|DEFSTRUCT| accessor slots. \item[trace-function-only] Enhance TRACE arguments. \end {description} \paragraph {Changes.} These proposals are generally incompatible changes to the language, although in some cases they are consistent with CLtL. \begin {description} \item Require \verb|STREAM|, \verb|PACKAGE|, \verb|PATHNAME|, \verb|READTABLE|, \verb|RANDOM-STATE| be disjoint types. \item[pathname-symbol] Symbols do not automatically coerce to pathnames, e.g., \verb|(LOAD 'FILE)| is not allowed. \item[declare-macros] \verb|(LET (A B) (MY-DECLARE) ...)| Disallow macros expanding into declarations. \item[function-type] Change the \verb|FUNCTION| type to be distinct from any other type, and change \verb|FUNCTIONP| to accept only \verb|FUNCTION| objects (not symbols or lists that begin with \verb|LAMBDA|.). Require the \verb|FUNCTION| always returns a \verb|FUNCTION| object. Disallow automatic coercion from symbols to functions by \verb|FUNCALL|, \verb|APPLY|, etc. \item[defmacro-body-lexical-environment] Allow \verb|DEFMACRO| and \verb|DEFTYPE| bodies to have a lexical environment. \end {description} \section {Open problems.} There are a number of areas that are currently not being addressed, either by the cleanup committee or by other current committee's of X3J13. We would like to see some attempts at standardizing on those areas that are most concern to users attempting to write portable code. One is that with the acceptance of a reasonable signal system, the hard work of specifying the signals which may be raised by various error conditions remain. We would like to make a part of the standard interface to functions the classes of errors they can invoke under various circumstances. No work is currently going on in the area of specifying reference to multi-programming features, although many implementations of Common Lisp include them. There are several problems in the language specification for which we have no good proposals. Most of these involve interactions of the many functions in the Common Lisp library, e.g., how \verb|EQUAL| behaves on \verb|DEFSTRUCT| objects. We believe these items need to be standardized, but have not found a reasonable design. \end{document} ∂14-Jan-88 2023 CL-Cleanup-mailer [Jan Zubkoff <edsel!jlz@labrea.stanford.edu>: mailings] Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:23:07 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 17:49:06 PST Date: 14 Jan 88 17:48 PST From: Masinter.pa@Xerox.COM Subject: [Jan Zubkoff <edsel!jlz@labrea.stanford.edu>: mailings] To: cl-cleanup@Sail.stanford.edu Message-ID: <880114-174906-4688@Xerox> I am unfortunately going to be away for two weeks starting on Monday. (Rather suddenly.) When I get back, I will try to gather up all of the issues that are ready for release for mailing out and do a mailing. The time will be pretty short. I'm going to at least try to get an updated status list out before I leave, and mark the ones that seem ripe for harvesting. Let me urge you to try to reach some convergence on the open issues in the next two weeks. We need to get more things behind us if we're going to have a draft standard by the end of the year. I know you've seen this, but ... This is a reminder that any subcommittee papers need to be mailed by Friday 2/5 in order to reach committee members in time. That's only 3 weeks from Friday folks... ∂14-Jan-88 2023 CL-Cleanup-mailer Issue: APPEND-DOTTED (Version 5) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:23:13 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 18:43:08 PST Date: 14 Jan 88 18:42 PST From: Masinter.pa@Xerox.COM to: cl-cleanup@Sail.stanford.edu cc: Masinter.pa@Xerox.COM Subject: Issue: APPEND-DOTTED (Version 5) Message-ID: <880114-184308-4782@Xerox> Sigh, making a status list, I come across little edits that are hard to avoid making. This version incorporates a few typos and a report on Current Practice. Please don't reply unless you have some objections, there'll be an opportunity to say "OK" to the whole group. ! Issue: APPEND-DOTTED References: APPEND (p268) Category: CHANGE/CLARIFICATION Edit history: 27-Jul-87, Version 1 by Pitman 29-Oct-87, Version 2 by Pitman (loose ends) 14-Nov-87, Version 3 by Masinter 23-Nov-87, Version 4 by Masinter 14-Jan-88, Version 5 by Masinter Problem Description: The description of APPEND on p268 is not adequately clear on the issue of what happens if an argument to APPEND is a dotted list. The only case explicitly mentioned is the last argument, viz: "The last argument [to APPEND] actually need not be a list but may be any LISP object, which becomes the tail end of the constructed list. For example, (append '(a b c) 'd) => (a b c . d)." While this specifies the behavior of APPEND when the last argument is not a list, the behavior when any of the other arguments are not lists is not specified. Proposal (APPEND-DOTTED:REPLACE): Define that the cdr of the last cons in any but the last argument given to APPEND or NCONC is discarded (whether NIL or not) when preparing the list to be returned. In the degenerate case where there is no last cons (i.e., the argument is NIL) in any but the last list argument, clarify that the entire argument is effectively ignored. Point out that in this situation, if the last argument is a non-list, the result of APPEND or NCONC can be a non-list. Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are the same, since these two might legitimately differ in situations involving dotted lists. As such, deciding which to use is not just a stylistic issue. Examples: (APPEND '(A B C . D) '()) => (A B C) ;Proposed (NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed Note that (COPY-LIST '(A B C . D)) would still return (A B C . D). (APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed (NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed (APPEND '() 17) => 17 ;Proposed (NCONC (LIST) 17) => 17 ;Proposed Rationale: This function is used a lot and its behavior should be well-defined across implementations. This proposal upholds the apparent status quo in a number of implementations. Current Practice: Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed interpretation (at least in the interpreter). Franz's Allegro Common Lisp conforms to the proposed behavior except in the case of (NCONC (LIST) 17) => 17, where it returns NIL instead of 17. Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted list. Xerox Common Lisp signals an error on APPEND and implements the proposed interpretation on NCONC. Cost to implementors: Technically, the change should be relatively small for those implementations which don't already implement it. However, implementations which have microcoded APPEND or NCONC incompatibly may find the small change somewhat painful. Some implementations may have optimized their APPEND or NCONC to expect only NIL when SAFETY is 0. In this case, depending on implementation details, requiring an ATOM check rather than a NULL check may slow things down. Cost to users: This change is upward compatible. Benefits: Since non-lists are allowed as a last argument and since APPEND and NCONC can therefore produce dotted lists, some readers may have (incorrectly) assumed that APPEND and NCONC can reliably deal in general with dotted lists, something that doesn't appear to be guaranteed by a strict reading. The proposed extension would happen to legitimize such assumptions. Aesthetics: Whether or not users will think this improves the aesthetics of the language will depend largely on how they view the relation between lists and dotted lists. Those who view dotted lists as a special kind of list may feel differently than those who view lists as a special kind of dotted list. Discussion: The cleanup committee supports this proposal. ∂14-Jan-88 2023 CL-Cleanup-mailer Re: Issue: DECLARATION-SCOPE Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:23:25 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 19:46:17 PST Date: 14 Jan 88 19:45 PST From: Masinter.pa@Xerox.COM Subject: Re: Issue: DECLARATION-SCOPE In-reply-to: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>'s message of Thu, 7 Jan 88 08:55 EST To: Hornig@ALDERAAN.SCRC.Symbolics.COM cc: cl-cleanup@sail.stanford.edu Message-ID: <880114-194617-4828@Xerox> In order for this proposal to go out in the mailing to X3J13 committee members, we will need a version of the proposal that reflects, either in the cost/benefit analysis, or in the discussion, the topics mentioned in the mail so far. If you want to separate out the issues of type declarations into a separate proposal, then this proposal is misnamed, it probably should be DECLARE-SPECIAL-SCOPE and you need another one that is DECLARE-TYPE-SCOPE. Personally, I think we are close enough to attempt a comprehensive set of rules for DECLARATION-SCOPE and that you should go for it; there's not that much time. ∂14-Jan-88 2024 CL-Cleanup-mailer Re: New issue: FLET-DECLARATIONS Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:23:45 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 20:18:27 PST Date: 14 Jan 88 20:17 PST From: Masinter.pa@Xerox.COM Subject: Re: New issue: FLET-DECLARATIONS In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of Fri, 1 Jan 88 15:45 EST To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: Cl-Cleanup@SAIL.STANFORD.EDU, Hornig@STONY-BROOK.SCRC.Symbolics.COM Message-ID: <880114-201827-4858@Xerox> I think this issue would be ready to mail out with just a few changes: a) I think it is independent of whether DECLARE-MACROS passes. Certainly if DECLARE-MACROS doesn't pass, it is even more important, but as written it seems like it more intertwined. B) It should probably reference DECLARATION-SCOPE. c) That at least one CL implementation does this is probably support (in Current Practice) I support this proposal. ∂14-Jan-88 2023 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:23:37 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 20:04:21 PST Date: 14 Jan 88 20:03 PST From: Masinter.pa@Xerox.COM Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2) In-reply-to: Dan L. Pierson <pierson@mist.ARPA>'s message of Wed, 30 Dec 87 19:26:32 EST To: pierson@mist.ARPA cc: cl-cleanup@sail.stanford.edu Message-ID: <880114-200421-4849@Xerox> I think we can ship a version 3 that has the [[]] remarks removed. Probably we want to add to the Discussion section. What do folks think about a paragraph like: DISASSEMBLE is an environment feature; some question has been raised as to the place and force of environment features in the standard. However, this proposal stands if DISASSEMBLE is part of the standard language. ∂14-Jan-88 2045 CL-Cleanup-mailer Re: Issue: LAST-N (Version 1) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:45:30 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 20:45:06 PST Date: 14 Jan 88 20:44 PST From: Masinter.pa@Xerox.COM Subject: Re: Issue: LAST-N (Version 1) In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of Fri, 4 Dec 87 16:49 EST To: KMP@STONY-BROOK.SCRC.Symbolics.COM cc: CL-Cleanup@SAIL.Stanford.EDU Message-ID: <880114-204506-4881@Xerox> For the record, I'm opposed to this proposal. Its a random addition that I can't imagine using more than once every 2 years. Implementationally it turns a simple primitive LAST into a complex one. Of course you can optimize it, but that makes the implementation even more complex. ∂14-Jan-88 2054 CL-Cleanup-mailer Re: Issue: LOAD-TIME-EVAL (Version 3) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 20:53:54 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 20:54:32 PST Date: 14 Jan 88 20:53 PST From: Masinter.pa@Xerox.COM Subject: Re: Issue: LOAD-TIME-EVAL (Version 3) In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of Thu, 12 Nov 87 18:48 EST To: CL-CLEANUP@SAIL.STANFORD.EDU Message-ID: <880114-205432-4891@Xerox> The last mail on this topic was 12 November. Jul 23: Jim Kempf's version 2 mailed Nov 11: mail about a few typos and bugs in it which he agreed to adopt. Nov 12: Kent Pitman mailed version 3 Dave Moon replied. Version 2 is incompatible with Version 3. Do we go back to version 2 (#, as currently spec'd, allowed only within constants?) ∂14-Jan-88 2111 CL-Cleanup-mailer Issue status: READY FOR LETTER BALLOT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 21:11:47 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 21:12:23 PST Date: 14 Jan 88 21:11 PST From: Masinter.pa@Xerox.COM Subject: Issue status: READY FOR LETTER BALLOT To: cl-cleanup@Sail.stanford.edu Message-ID: <880114-211223-4922@Xerox> Just to get them out of the other list, I've separated out into a separate message those issues that I think are, as of today, ready for sending out in letter ballot form; they were either endorsed by X3J13 at a previous meeting (if it says so) or else there's been no objections to the last version mailed and the discussion is conclusive. New for this meeting: - ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87) (Interaction of ADJUST-ARRAY and displaced arrays) - APPEND-DOTTED (Version 5, 14-Jan-88) (What happens to CDR of last CONS? in other than last arg?) - ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87) (Extend ASSOC-IF, etc. to allow :KEY) - COMPILER-WARNING-BREAK (Version 4,23-Nov-87 ) (Does *BREAK-ON-WARNING* affect the compiler?) - DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87) (Documentation string is not evaluated.) - DEFVAR-INIT-TIME (Version 2, 29-May-87) (DEFVAR initializes when evaluated, not later.) Version 2 passed X3J13/Jun87. - DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87) ( DO-SYMBOLS can the same symbol twice?) - PATHNAME-SYMBOL (Version 3, 23-OCT-87) (Do symbols automaticly coerce to pathnames?) - PUSH-EVALUATION-ORDER (Version 5,25-Nov-87) (What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?) - REDUCE-ARGUMENT-EXTRACTION (version 2, 30 Dec 87) (Add :KEY to REDUCE) - SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87) (Change recommendation for (get-setf-method symbol)?) - SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87) (Allow (DEFUN (SETF FOO) ..)) - SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43) (What does SHADOW do if symbol is already there?) - SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87) ( *FEATURES* are in the keyword package) Already passed: - AREF-1D (Version 7, 14-Nov-87) (Add a new function for accessing arrays with row-major-index) Version 5 conditionally passed X3J13/Jun87 Version 7 passed X3j13/Nov87 - COLON-NUMBER (Version 1, 22-oct-87) (Is :1 a number, a symbol, or undefined?) Version 1 passed X3J13/Nov87 - COMPILER-WARNING-STREAM (Version 6, 5-Jun-87) (Compiler warnings are printed on *ERROR-OUTPUT*) Version 6 passed X3J13/Jun87 - DEFVAR-INITIALIZATION (Version 4, Jun-87) ((DEFVAR var) doesn't initialize) Version 4 passed X3J13, Jun87. - FLET-IMPLICIT-BLOCK (Version 6, 5-Jun-87) (do FLETs have implicit named blocks around them?) Version 6 passed X3J13/Jun87. - FORMAT-ATSIGN-COLON (Version 4, 5-jun-87) (@: == :@ in format) Version 4 passed X3J13/Jun87. - FORMAT-COMMA-INTERVAL (Version 2, 15 June 87) (paramerize number of digits between commas) Version 2 passed X3J13/Nov87 - FORMAT-OP-C (Version 5, 11-Jun-87) (What does ~C do?) Version 5 passed X3J13/Jun87. - GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87) (Environment argument for GET-SETF-METHOD) Version 4 conditionally passed X3J13/Jun87. Version 5 passed X3J13/Nov87. - IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87) (Does IMPORT affect home package?) Version 5 passed X3J13/Jun87. - KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87) (&KEY arguments not in keyword package?) Version 6 conditionally passed X3J13/Jun87. Version 8 passed X3J13/Nov87 - PATHNAME-STREAM (Version 6, 14-Nov-87) (PATHNAME only works on file streams) Version 2 conditionally passed X3J13/Jun 87 Version 6 passed X3J13/Nov 87 - PRINC-CHARACTER (Version 3) (PRINC behavior on character objections) Version 3 passed X3J13/Jun87. ∂14-Jan-88 2116 CL-Cleanup-mailer Issue status: PENDING Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jan 88 21:16:44 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 JAN 88 21:17:18 PST Date: 14 Jan 88 21:16 PST From: Masinter.pa@Xerox.COM Subject: Issue status: PENDING To: CL-Cleanup@SAIL.Stanford.Edu Message-ID: <880114-211718-4930@Xerox> This is my current list of pending issues. This list is not as accurate; I've not carefully checked it against the latest versions of all of the issue mail files. However, I don't think I'll have a chance to do that before I leave, so here 'tis. I hope that some of these can be turned into final, endorsed proposals (we're very close on a number of them) so that they can be included in the mailing for the March meeting. Please. In discussion. - DECLARE-MACROS (Version 2, 9-Nov-87) (Disallow macros expanding into declarations.) Kent will resubmit. - DECLARATION-SCOPE (Version 1, 5-Jan-88) (What is the scope of SPECIAL declarations? INLINE declarations? where can declarations be placed?) should include INLINE, TYPE declarations - DISASSEMBLE-SIDE-EFFECT (version 2) (DISASSEMBLE doesn't smash the def if not compiled) nearly ready. - FLET-DECLARATION (Version 1, 1 Jan 88) (Allow declarations in FLET, MACROLET) nearly ready - FORMAT-COLON-UPARROW-SCOPE (Version 1) (what iteration does ~:↑ exit from?) Common-Lisp mailing list discussion Nov 87 Nearly ready - FUNCTION-ARGUMENT-TYPE-SEMANTICS (not yet submitted) I'm hoping to get this one out when I get back, but I know its hopeless. Maybe I can mail it out *not* in time for a letter ballot but in time for discussion. - FUNCTION-TYPE-KEY-NAME (Version 1, 1 Dec 87) (allow type (FUNCTION (SEQUENCE FUNCTION &KEY (:KEY FUNCTION)) SEQUENCE) ) needs minor edits as per KMP - FUNCTION-TYPE (Version 7,8, 9-Nov-87, 14-Nov-87) (Change definition of FUNCTIONP, function type ...) Discussed at X3J13, new proposal due. Not eady for release - LOAD-TIME-EVAL (Version 3, 11-Nov-87) (New function/macro/special form for evaluation when compiled file is loaded?) nearly ready for release - PROCLAIM-LEXICAL (Version 5, 14-Nov-87) (add LEXICAL, GLOBAL, CONSTANT proclaimation) - REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 ) (Specification of side-effect behavior in CL) DEFINED, VAGUE and IN-BETWEEN Not ready for release - SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4, 11-Nov-87) (FIND, SUBSTITUTE etc work on multi-dimensional arrays?) Could be ready for release - TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87) (Allow trace for SETF functions, macros, etc.) Environment extension? ? Ready for release? - UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87) (What happens with non-local exits out of UNWIND-PROTECT cleanup clauses?) Not ready for release Need volunteer: - ADJUST-ARRAY-FILL-POINTER - CONSTANT-SIDE-EFFECTS (not yet submitted) (It is an error to do destructive operations on constants in code, defconstant.) Discussed 12/86 - 1/87 Will take on if no compiler proposal - DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted) (Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be required to be disjoint from other types?) From CLOS committee, not yet submitted - EQUAL-STRUCTURE (not yet submitted) (Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.) What do EQUAL EQUALP and friends do on structures? (ALarson@HI-MULTICS.Arpa, edsel!jonl@labrea.stanford.edu, Okuno@SUMEX-AIM.STANFORD.EDU, goldman@vaxa.isi.EDU) - FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT) (P 425) "Generalize FILE-LENGTH to accept any filename, not just an open file-stream. Let it take a keyword argument :ELEMENT-TYPE, defaulting to STRING-CHAR for non-stream arguments and to the element-type of the stream for a stream argument." Need volunteer to write up. - FORMAT-NEGATIVE-PARAMETERS (mail 19 May 87, no formal proposal) "format parameters are assumed to be non-negative integers except as specifically stated" Steele? will write up. - FUNCTION-TYPE-REST-LIST-ELEMENT (not yet submitted) (allow &rest <type> in function types to refer to element type rather than list) Disscussed at length in the past. sandra%orion@cs.utah.edu. - FUNCTION-SPECS (not yet submitted) (add "function specs" for defun, trace etc) Mail from Moon 6-Jun. cf SETF-FUNCTION-VS-MACRO. (SMH!franz@ucbarpa.berkeley.edu, JonL, RWK) - LISP-SYMBOL-REDEFINITION (no formal proposal yet) Is it legal to redefine symbols in the LISP package? Mail 14-Aug-87 Merge with SPECIAL-FORM-SHADOW Needs volunteer - MACRO-FUNCTION-ENVIRONMENT (Add environment argument to MACRO-FUNCTION?) re-extracted from ENVIRONMENT-ARGUMENTS CLOS committee to submit? - PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87) How to deal with subdirectory structures in pathname functions? make :DIRECTORY a list? Need volunteer to rewrite. - PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted) Mail Aug 87 discussion How to deal with logical devices, :unspecific components, etc in pathname functions RWK@YUKON.SCRC.Symbolics.COM may submit proposal. - REDUCE-ARGUMENT-EXTRACTION (no proposal) Mail on COMMON-LISP about adding a new keyword argument to REDUCE to extract the appropriate value. - SPECIAL-FORM-SHADOW (no formal proposal) (Is it OK to shadow a special form with FLET, LABELS, MACROLET?) In discussion, no formal proposal submitted. - STANDARD-INPUT-INITIAL-BINDING (from ISSUES.TXT file) (P 328) "Remove the requirement that *STANDARD-INPUT*, etc., must be initially bound to synonym streams to *TERMINAL-IO*; demote this to the level of an implementation suggestion. This is to allow flexibility of implementation, for example to allow UNIX redirection to win." Need volunteer to submit - STREAM-CLASS-ACCESS (No formal proposal) (Originally FOLLOW-SYNONYM-STREAM 19-DEC-86) Define stream accessors as if synonym-stream two-way-stream etc were CLOS classes? - STRUCTURE-DEFINITION-ACCESS (No formal proposal) (access to slot accessors for DEFSTRUCT etc.) Need volunteer to write up - SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal) (p 246) "Specify that it is an error for the SUBSEQ indices or any :START or :END argument have a negative index or point past the end of the sequence in question. (With respect to whether signalling is required, this error will be treated the same as array out-of-bounds.)" Need volunteer to write up - TAILP-NIL (no formal proposal yet) (Operation of TAILP given NIL) Needs writeup in current format. - VECTOR-PUSH-EXTEND-DEFAULT (no proposal yet) CLtL says that vectors are extended by a "reasonable" amount. What's that? Hold: Awaiting action from another committee. - DECLARE-TYPE-EXACT (from Kempf as EXACT-CLASS) (Want to be able to declare (EQ (TYPE-OF X) 'Y), i.e., not a subclass.) Useful after CLOS - DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted) What is the lexical environment of DEFTYPE, DEFINE-SETF bodies? Mail 11-12 Oct 87 on common-lisp Interacts with compiler proposal' - DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file) (p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions. Specify that it is an error for two slots in a single DEFSTRUCT to have the same name. If structure A includes structure B, then no additional slot of A may have the same name as any slot of B." Need volunteer to sort out DEFSTRUCT issues post-CLOS. - DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file) (p 305) "The default value in a defstruct slot is not evaluated unless it is needed in the creation of a particular structure instance. If it is never needed, there can be no type-mismatch error, even if the type of the slot is specified, and no warning should be issued." Need volunteer to sort out DEFSTRUCT issues post-CLOS. - DRIBBLE-TECHNIQUE (Version 1) (editorial board remove DRIBBLE from standard language -> standard environment) - FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no formal proposal) (What does FILE-WRITE-DATE do if no such file?) "there should not be a formal proposal for fixing the file-write-date ambiguity until we are at the point where we can make proposals that discuss signalling named conditions. " Awaiting error proposal. - IF-BODY (Version 7, 16-Jun-87) (extend IF to implicit progn if more than one ELSE form?) Draft released 16-Jun-87. Discussed at X3J13/Jun 87. Postpone pending resolution of policy on extensions - IGNORE-ERRORS (Version 4, 29-May-87) (Introduce error catcher) Awaiting error proposal - SHARPSIGN-BACKSLASH-BITS (What does C-META-H-X mean?) Forwarded to character committee. Tabled: Awaiting new proposal. - ADJUST-ARRAY-NOT-ADJUSTABLE (Version 1, 22-Apr-87) (ADJUST-ARRAY on non-adjustable arrays returns copy) extend COPY-ARRAY instead? Tabled until resubmitted - DEFINITION-FUNCTIONS (no formal proposal) (Extensions for documentation-type for delete-definition for type FUNCTION, VARIABLE, TYPE. ) Rough draft mailed 9-Oct-87. JonL may mail something. - EVAL-DEFEATS-LINKER (Version 1, 12 Jun-87) ("selective linking" means GC non-used symbols; proposal to change #., #, and part of FUNCTION-TYPE Wait on FUNCTION-TYPE, LOAD-TIME-EVAL Propose #., #, changes independently. - EXPORT-COORDINATION (no formal proposal) Add new macros for defining, export at same time Too many interactions with package system - GC-MESSAGES (version 1) (Control over unsolicited GC messages in typescript) merge with other controls for unsolicited messages? - KEYWORD-KEYWORDS (version 1) - OPEN-KEYWORDS (Version 1, 17-Jul-87) Discussion 9-Nov-87 Questionable; needs stronger justification. Tabled until resubmitted. - PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87) (interaction between PEEK-CHAR, READ-CHAR and streams made by MAKE-ECHO-STREAM) "Fixing echo streams is fine, but I don't think that it is appropriate for the standard to specify how terminal interaction must or even ought to work." - PROMPT-FOR (Version 1) (add new function which prompts) Tabled until re-submitted. - REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87) (where does REQUIRE look for files?) Doesn't really solve our problems? - SHARPSIGN-PLUS-MINUS-NUMBER (Is #+68000, #-3600 allowed?) Mild disagreement: it is an error? Table until resubmitted ∂15-Jan-88 1056 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 2) Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 10:56:18 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Fri 15 Jan 88 13:49:12-EST Date: Fri, 15 Jan 1988 13:49 EST Message-ID: <FAHLMAN.12366848744.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: Masinter.pa@XEROX.COM Cc: cl-cleanup@SAIL.STANFORD.EDU Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 2) What do folks think about a paragraph like: DISASSEMBLE is an environment feature; some question has been raised as to the place and force of environment features in the standard. However, this proposal stands if DISASSEMBLE is part of the standard language. It would be cleaner to go ahead and clarify that these environment things are mere suggestions and will not be part of the standard. But if that can't be done in time, or if it is not within the charter of our committee to say such a thing, then this sort of clarification seems reasonable. -- Scott ∂15-Jan-88 1327 CL-Cleanup-mailer New, improved FUNCTION-TYPE-KEY-NAME proposal Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Jan 88 13:26:53 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA22311; Fri, 15 Jan 88 14:25:40 MST Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA12185; Fri, 15 Jan 88 14:25:34 MST From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8801152125.AA12185@orion.utah.edu> Date: Fri, 15 Jan 88 14:25:32 MST Subject: New, improved FUNCTION-TYPE-KEY-NAME proposal To: cl-cleanup@sail.stanford.edu Issue: FUNCTION-TYPE-KEY-NAME References: CLtL p.47-48, 61 Category: CLARIFICATION, CHANGE Edit history: Version 1, 23-Nov-1987 Sandra Loosemore Version 2, 15-Jan-1988 Sandra Loosemore (from comments by Kent Pitman) Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT Problem description: The FUNCTION type specifier list is provided to allow declaration of function argument types and return value types. This type specifier uses a syntax similar to the usual lambda list syntax to specify which types go with which lambda list variables. However, there is a problem with &KEY lambda variables because CLtL does not specify how the types specified in the FUNCTION declaration are matched up to either the actual arguments passed to the function, or the lambda variables in the function definition (since the ordering of keyword arguments is arbitrary). Proposal (FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD): (1) Specify that the &KEY parameters in a FUNCTION type specifier lambda list should be supplied as lists of the form (<keyword> <type>). The <keyword> must be a valid keyword-name symbol. (2) Allow &ALLOW-OTHER-KEYS to appear in a FUNCTION type specifier lambda list. Test Case: The type of the function MAKE-LIST could be declared as: (FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST) Rationale: (1) This specifies a direct correspondence between the argument type and its matching keyword. All of the information is in one place, and the user does not have to remember (or even know) the order in which &KEY arguments appear in the actual function definition. (2) This is probably an oversight in the original specification. Current practice: Many Common Lisp implementations currently ignore FUNCTION type declarations. The situation regarding type specifications for keyword arguments is so ambiguous that few users attempt to use them. Cost to Implementors: Implementations that ignore the FUNCTION type specifier or keyword arguments in a FUNCTION type specifier may continue to do so. This proposal should not involve massive amounts of code to be rewritten. Conversion Cost: Because the current situation is so ambiguous, FUNCTION type specifiers and particularly the specification of keyword argument types are not widely used. However, since this is an incompatible change, it would be nice if implementations check for, and warn about, old-style usage. Cost of non-adoption: If nothing is done, the FUNCTION type specifier will continue to be of limited use for its intended purpose. Benefits: Adopting the proposal will clear up an area of confusion in the language design. Esthetics: The syntax is fairly obvious and is analogous to the (<keyword> <variable>) lambda list syntax. Discussion: ------- ∂15-Jan-88 1327 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Jan 88 13:27:24 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA22350; Fri, 15 Jan 88 14:26:23 MST Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA12191; Fri, 15 Jan 88 14:26:17 MST From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8801152126.AA12191@orion.utah.edu> Date: Fri, 15 Jan 88 14:26:15 MST Subject: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal To: cl-cleanup@sail.stanford.edu Issue: FUNCTION-TYPE-REST-LIST-ELEMENT References: CLtL p. 27, 47-48, 61 "Artifical Intelligence Programming", Charniak et. al. X3J13/86-003 (A:>GLS>clarifications.text.4) Category: CLARIFICATION, ADDITION Edit history: Version 1, 23-Nov-1987 Sandra Loosemore Version 2, 15-Jan-1988 Sandra Loosemore (incorporate comments from Scott Fahlman & others) Related issues: FUNCTION-TYPE-KEY-NAME Problem description: The FUNCTION type specifier list is provided to allow declaration of function argument types and return value types. This type specifier uses a syntax similar to the usual lambda list syntax to specify which types go with which lambda list variables. However, this is actually of limited usefulness in the context of a declaration, where one normally wants type information about the actual arguments which can be passed to the function rather than the lambda variables to which they are bound. There is a particular problem with &REST lambda variables, which are always bound to a value of type LIST. For the sake of consistency, it would seem that the corresponding type given in the FUNCTION declaration must also be LIST, but since this provides no information about the actual arguments, some users/implementors have instead adopted the convention of supplying the type of the actual arguments which are gathered into the list. CLtL is vague on the issue, mentioning only that &REST may appear in the type specifier without touching upon its interpretation. Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE): Clarify that, in the FUNCTION type specifier, the type specifier provided with &REST is the type of each actual argument, not the type of the corresponding lambda variable. Test Case: The type of the function + would be specified as: (FUNCTION (&REST NUMBER) NUMBER) Rationale: This is more useful than specifying that the type of a &REST parameter must be LIST, since it provides information about the actual arguments. Current practice: There does not appear to be any concensus on this issue. Many Common Lisp implementations currently ignore FUNCTION type declarations. Cost to Implementors: Implementations that ignore the FUNCTION type specifier may continue to do so. Probably only a small amount of code would have to be written/changed in implementations that currently think that the type of the &REST parameter must be LIST. Cost to Users: Users who have been using the convention that the &REST type parameter must be LIST will have to change their code. However, because this issue is so unclear, the FUNCTION type specifier is probably not used very much. Cost of non-adoption: If nothing is done, the FUNCTION type specifier will continue to be of limited use for its intended purpose. Benefits: Adopting the proposal will clear up an area of confusion in the language design. Esthetics: Ugly. Since the argument type syntax used by the FUNCTION type specifier mirrors normal lambda-list syntax, it is confusing to make the &REST type to refer to the types of the actual arguments rather than the type of the matching lambda variable. Discussion: Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:EXTEND-LIST-TYPE): (1) Clarify that, in the FUNCTION type specifier, the type specifier provided with &REST refers to the type of the corresponding lambda variable and must be LIST or a subtype of LIST. (2) Introduce a list form of the LIST type specifier, (LIST <type>). If the type is specified, then it indicates that the list is a true list (that is, finite and null-terminated), and that the value of each successive CAR of the list is a member of type <type>. Test Case: The type of the function + would be specified as: (FUNCTION (&REST (LIST NUMBER)) NUMBER) Rationale: (1) It is clear that a &REST lambda variable must be bound to a list. Since the FUNCTION type syntax follows lambda-list syntax rather than function call syntax, it is more consistent to make the type correspond to the type of the lambda variable rather than that of the actual arguments. (2) Introducing a list LIST type specifier would allow the FUNCTION type specifier to be more useful for its intended purpose. It would also be useful on its own. For example, a compiler may be able to optimize calls to functions such as MAPCAR that operate on successive elements of a list if information is available about the type of items in the list. The motivation for making this part of the standard is that the syntax of the LIST type cannot cannot be extended by user code. The motivation for making (LIST <type>) specify a true list is that leaving the issue unresolved would probably introduce more problems than it solves; see also the discussion under "esthetics" below. Current practice: There does not appear to be any concensus on this issue. Many Common Lisp implementations currently ignore FUNCTION type declarations. Cost to Implementors: Implementations that ignore the FUNCTION type specifier may continue to do so. It should be a fairly straightforward to implement the list form of the LIST type specifiers. Cost to Users: Users who have been using the convention that the &REST type parameter specifies the type of the actual arguments will have to change their code. However, because this issue is so unclear, the FUNCTION type specifier is probably not used very much. Since there is no list form of the LIST type specifier defined now, adding it should not affect user code. The semantics of the non-list form remain unchanged. Cost of non-adoption: If nothing is done, the FUNCTION type specifier will continue to be of limited use for its intended purpose. Benefits: Adopting the proposal will clear up an area of confusion in the language design. Esthetics: Since the argument type syntax used by the FUNCTION type specifier mirrors normal lambda-list syntax, it would be cleaner and less confusing to provide the type of the lambda variable rather than the type of the actual arguments. On the issue of why (LIST <type>) should imply a true list, the notion of a list of <type> implies a certain bias or asymmetry in the list structure: the CARs of each cons contain an element of type <type> and the CDRs contain a link to the next cons. Moreover, in most applications of the extended form of the LIST type specifier, one would almost certainly want to use it to specify a true list. (For example, CLtL routinely uses the term list'' to mean true list'', and states that it is an error to pass a dotted list to a function where the corresponding argument is described as a list.) If there is a need to specify the component types of lists being used as trees, it would probably make more sense to define a list form of the CONS type specifier that allows the types of both the CAR and CDR to be supplied. Discussion: ------- ∂15-Jan-88 1450 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Jan 88 14:49:59 PST Received: from Cabernet.ms by ArpaGateway.ms ; 15 JAN 88 14:48:47 PST Date: 15 Jan 88 14:48 PST From: Masinter.pa@Xerox.COM Subject: Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of Fri, 15 Jan 88 14:26:15 MST To: sandra%orion@cs.utah.edu cc: cl-cleanup@sail.stanford.edu Message-ID: <880115-144847-6100@Xerox> I don't think we can release a proposal with two choices. This issue is not important enough for us to debate two choices before X3J13. I propose a majority vote of the individuals who care to vote in response to this message. For the record, my vote is USE-ACTUAL-ARGUMENT-TYPE; the simplicity of the declarations and the ugliness of the alternative, as well as the weight of current practice, argue for it. ∂15-Jan-88 1511 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Jan 88 14:49:59 PST Received: from Cabernet.ms by ArpaGateway.ms ; 15 JAN 88 14:48:47 PST Date: 15 Jan 88 14:48 PST From: Masinter.pa@Xerox.COM Subject: Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of Fri, 15 Jan 88 14:26:15 MST To: sandra%orion@cs.utah.edu cc: cl-cleanup@sail.stanford.edu Message-ID: <880115-144847-6100@Xerox> I don't think we can release a proposal with two choices. This issue is not important enough for us to debate two choices before X3J13. I propose a majority vote of the individuals who care to vote in response to this message. For the record, my vote is USE-ACTUAL-ARGUMENT-TYPE; the simplicity of the declarations and the ugliness of the alternative, as well as the weight of current practice, argue for it. ∂15-Jan-88 1516 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 15:15:52 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Fri 15 Jan 88 18:15:45-EST Date: Fri, 15 Jan 1988 18:15 EST Message-ID: <FAHLMAN.12366897279.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ Cc: cl-cleanup@SAIL.STANFORD.EDU Subject: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal In-reply-to: Msg of 15 Jan 1988 16:26-EST from sandra%orion at cs.utah.edu (Sandra J Loosemore) I think we should go with USE-ACTUAL-ARGUMENT-TYPE as the sole proposed option. Earlier I argued against this, but as I said in a previous message, I found Moon's arguments on this issue to be persuasive: we can consider the types specified in the FUNCTION specifier to be the types of the arguments rather than the types of the parameters as seen on the receiving end. In fact, given this shift in viewpoint, I no longer consider this option to be ugly. I'd change the comment in the aesthetics section from "Ugly." to "Some may consider this ugly." and point out the alternative way of looking at this. -- Scott ∂15-Jan-88 1724 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Jan 88 14:49:59 PST Received: from Cabernet.ms by ArpaGateway.ms ; 15 JAN 88 14:48:47 PST Date: 15 Jan 88 14:48 PST From: Masinter.pa@Xerox.COM Subject: Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of Fri, 15 Jan 88 14:26:15 MST To: sandra%orion@cs.utah.edu cc: cl-cleanup@sail.stanford.edu Message-ID: <880115-144847-6100@Xerox> I don't think we can release a proposal with two choices. This issue is not important enough for us to debate two choices before X3J13. I propose a majority vote of the individuals who care to vote in response to this message. For the record, my vote is USE-ACTUAL-ARGUMENT-TYPE; the simplicity of the declarations and the ugliness of the alternative, as well as the weight of current practice, argue for it. ∂15-Jan-88 1724 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 15 Jan 88 15:15:52 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Fri 15 Jan 88 18:15:45-EST Date: Fri, 15 Jan 1988 18:15 EST Message-ID: <FAHLMAN.12366897279.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ Cc: cl-cleanup@SAIL.STANFORD.EDU Subject: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal In-reply-to: Msg of 15 Jan 1988 16:26-EST from sandra%orion at cs.utah.edu (Sandra J Loosemore) I think we should go with USE-ACTUAL-ARGUMENT-TYPE as the sole proposed option. Earlier I argued against this, but as I said in a previous message, I found Moon's arguments on this issue to be persuasive: we can consider the types specified in the FUNCTION specifier to be the types of the arguments rather than the types of the parameters as seen on the receiving end. In fact, given this shift in viewpoint, I no longer consider this option to be ugly. I'd change the comment in the aesthetics section from "Ugly." to "Some may consider this ugly." and point out the alternative way of looking at this. -- Scott ∂15-Jan-88 1741 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Jan 88 17:41:01 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA27567; Fri, 15 Jan 88 16:57:17 MST Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA12554; Fri, 15 Jan 88 16:57:12 MST From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8801152357.AA12554@orion.utah.edu> Date: Fri, 15 Jan 88 16:57:09 MST Subject: Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu> Cc: cl-cleanup@sail.stanford.edu In-Reply-To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>, Fri, 15 Jan 1988 18:15 EST As I'm not on the cl-cleanup mailing list, I think I may have missed out on some of the discussion relating to FUNCTION declaration semantics. If there is now a concensus that FUNCTION declarations describe calls to the function and not the function itself, I agree that the USE-ACTUAL-ARGUMENT-TYPE option is not really as "ugly" as it would be otherwise, and it's certainly simpler than the alternative. Perhaps someone who is actually on the cleanup committee should "adopt" this proposal at this point, and do whatever needs to be done to it to get it to the point where you all think it's ready to be voted on? I volunteered to write it up, not make it into a life-long crusade.... -Sandra ------- ∂18-Jan-88 1618 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 2) Received: from Think.COM by SAIL.Stanford.EDU with TCP; 18 Jan 88 16:18:36 PST Return-Path: <gls@Think.COM> Received: from kali.think.com by Think.COM; Mon, 18 Jan 88 16:47:00 EST Received: by kali.think.com; Mon, 18 Jan 88 16:46:55 EST Date: Mon, 18 Jan 88 16:46:55 EST From: gls@Think.COM Message-Id: <8801182146.AA14007@kali.think.com> To: cl-cleanup@sail.stanford.edu Subject: Issue: FORMAT-COLON-UPARROW-SCOPE (version 2) Issue: FORMAT-COLON-UPARROW-SCOPE References: CLtL p. 406 and also p. 403 Category: CLARIFICATION Edit history: version 1: Guy Steele, 30 November 1987 version 2: Guy Steele, 18 January 1988 Problem description: Implementations currently differ on the question of what is tested by the FORMAT command "~:↑". Some implementations test to see whether any arguments remain in the sublist for the current iteration step; others test to see whether any sublists remain. The text on page 406 is not clear on this point. The two behaviors are presented below as two proposals. Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS): ~:↑ may be used only if the command it would terminate is ~:{ or ~:@{. The entire iteration process is terminated if and only if the sublist that is supplying the arguments for the current iteration step is the last sublist (in the case of ~:{) or the last FORMAT argument (~:@{). Note that ~:↑ is *not* equivalent to ~:#↑; the latter terminates the entire iteration if and only if no arguments remain for the current iteration step. Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS): ~:↑ may be used only if the command it would terminate is ~:{ or ~:@{. The entire iteration process is terminated if and only if no more arguments remain for the current iteration step. Thus ~:↑ is equivalent to ~:#↑, just as ~↑ is equivalent to ~#↑. Test Cases/Examples: (format nil "~:{~@?~:↑...~}" '(("a") ("b"))) Under proposal FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS this yields "a...b". Under proposal FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS this yields "a". Rationale: FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS is desirable because otherwise there is no way to test whether any sublists remain. The text on page 406 may be construed to hint at this proposal indirectly. To quote Nick Gall: If one thinks about the intent of the parenthetical (because in the standard case it tests for remaining arguments of the current step only) one should agree that "a...b" will be returned. In referring to ~↑ as the "standard case", which tests the arguments remaining in the current argument sublist, this parenthetical implies that there is an other case', which tests something else.' The only other case' discussed is ~:↑, which therefore must test something else.' I claim that the parentheical makes no sense if we interpret ~:↑ as testing the same condition as ~↑. If they both test the same condition, why have the parenthetical explanation? If ~:↑ doesn't test the same condition as ~↑, then what does it test? I claim that the only test that makes sense is for ~:↑ to test the only thing that affects the "entire iteration process:" the number of sublists. When there are no more sublists, "the entire iteration process" is terminated. FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS is desirable only because it maintains the equivalence of ~:#↑ and ~:↑ and because some implementations have been produced that take this approach. Current practice: Implementations using FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS include Symbolics Common Lisp and TI Lisp. Implementations using FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS include Kyoto Common Lisp, Allegro Common Lisp, GCLISP, and VAXLISP. Cost to Implementors: One or the other batch of implementors will have to make a small change, probably a one-liner. Cost to Users: It is unlikely that much user code depends on the behavior FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS, but it is possible. The author of this writeup (Steele) judges it somewhat more likely that user code might depend on the behavior FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS. Cost of non-adoption: Users would have to be warned not to use ~:↑ in code that is meant to be portable. Benefits: Elimination of yet one more ambiguity. FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS allows greater semantic power (there are more things one can test). FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS maintains an elegant but useless symmetry. Esthetics: Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele Jr. Discussion: Guy Steele very strongly prefers the interpretation FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS. David Moon, Kent Pitman, Pavel Curtis, Dan Pierson, Rob Poor, and Nick Gall favor FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS. Kevin Layer and Rich Robbins have spoken in favor of FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-ARGUMENTS. Historical note: Steele first implemented this "feature", in Zetalisp, and so the code in Symbolics Common Lisp is likely a direct descendant of the original code. This might cause some to give weight to Steele's opinion. There are two arguments against such credence. First, there is no reason why the original code should be regarded as part of the specification of Common Lisp any more than any other implementation; plainly, Steele botched the specification when he wrote the book. Second, a professor of literature (I believe) once told Isaac Asimov concerning a short story of his (I quote from memory): "Tell me, Dr. Asimov, just because you wrote the story, what makes you think you know what it means?" ∂18-Jan-88 1831 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 2) Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 18 Jan 88 18:31:24 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Mon 18 Jan 88 21:31:19-EST Date: Mon, 18 Jan 1988 21:31 EST Message-ID: <FAHLMAN.12367719313.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: cl-cleanup@SAIL.STANFORD.EDU Subject: Issue: FORMAT-COLON-UPARROW-SCOPE (version 2) In-reply-to: Msg of 18 Jan 1988 16:46-EST from gls at Think.COM CMU Common Lisp (known as Spice Lisp in spicier days) seems to implement TEST-FOR-REMAINING-ARGUMENTS. Some other implementations may have taken their cue from us. Nevertheless, following the herd, I favor TEST-FOR-REMAINING-SUBLISTS. -- Scott ∂19-Jan-88 1539 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 1) Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 19 Jan 88 15:38:50 PST Received: by multimax.ARPA (5.51/25-eef) id AA02319; Tue, 19 Jan 88 18:38:04 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA20676; Tue, 19 Jan 88 18:39:06 EST Message-Id: <8801192339.AA20676@mist.UUCP> To: cl-cleanup%sail.stanford.edu@multimax Cc: franz!smh%berkeley.edu@multimax Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 1) Date: Tue, 19 Jan 88 18:39:04 EST From: Dan L. Pierson <pierson@mist> Issue: STANDARD-INPUT-INITIAL-BINDING References: Standard streams (pp. 327-329) Category: CHANGE Edit history: Version 1 by Pierson and Haflich 1/19/87 Status: For Internal Discussion Problem description: CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*, *ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are initially bound to synonym streams to *TERMINAL-IO*. This requirement hampers the integration of Common Lisp with operating systems such as Unix which support input-output redirection. Proposal (STANDARD-INPUT-INITIAL-BINDING:TERMINAL-IO-OPTIONAL): The initial bindings of *STANDARD-INPUT*, *STANDARD-OUTPUT*, *ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, *DEBUG-IO*, and *TERMINAL-IO* are undefined. Implementors are encouraged to make them all refer to the user's console (possibly via *TERMINAL-IO*) if it makes sense in the current invocation of Common Lisp. Test Cases/Examples: A Unix implementation is currently unable to legally support standard error output even though Common Lisp defines *ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound to the same stream as *STANDARD-OUTPUT*. A workstation environnment which provides stream access to windows as an extension is currently forbidden to make trace output appear in a separate window by default. Rationale: The language is CLtL prevents implementations from doing sensible things. Current practice: Lucid binds *TERMINAL-IO* to a special internal stream type. Franz binds *TERMINAL-IO* to a special internal stream type for terminal streams which reads from Unix standard input and writes to Unix standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream with input from Unix standard input and output to Unix standard output. Cost to Implementors: None required, implementors would be given more freedom to tailor their implementations to the target harware and operating system. Cost to Users: No direct costs because this proposal doesn't require any implementation to change. Cost of non-Adoption: Many implementations will have to continue to choose between conforming to the standard and providing a superior user environment. Benefits: Implementations will be more able to match their IO behavior to their environment and their user's expectations. Aesthetics: While the aesthetics of the language won't change much, the aesthetics of environments would be allowed to improve. Discussion: This proposal carefully tries not to answer questions like the following: When is and isn't real access to the terminal via *TERMINAL-IO* desired? It certainly isn't for batch programs. For Unix which of different std{in,out,err} is *TERMINAL-IO* bound to? The KCL binding of *TERMINAL-IO* is a stream with no associated pathname(s). CLtL makes this more likely than not, which is not a good thing in the Unix environment. Do we need another proposal to determine stream types and access components of two-way streams? Does STREAM-CLASS-ACCESS cover this area? ∂21-Jan-88 0802 CL-Cleanup-mailer Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 21 Jan 88 08:02:26 PST Received: by multimax.ARPA (5.51/25-eef) id AA24101; Thu, 21 Jan 88 11:02:59 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA26178; Thu, 21 Jan 88 11:04:05 EST Message-Id: <8801211604.AA26178@mist.UUCP> To: Masinter.pa%Xerox.COM@multimax Cc: sandra%orion%cs.utah.edu@multimax, cl-cleanup%sail.stanford.edu@multimax Subject: Re: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal In-Reply-To: Your message of 15 Jan 88 14:48:00 -0800. <880115-144847-6100@Xerox> Date: Thu, 21 Jan 88 11:04:02 EST From: Dan L. Pierson <pierson@mist> My vote is for USE-ACTUAL-ARGUMENT-TYPE for &rest args in function specs. It may or may not damage the pure aesthetics of the language, but, since the resulting code is easier to read and write, it seems like an aesthetic improvement to me. I would like to see a separate proposal for a parameterized LIST type specifier; I think that it would be useful outside function specs. ∂21-Jan-88 0810 CL-Cleanup-mailer Issue: DISASSEMBLE-SIDE-EFFECT (version 3) Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 21 Jan 88 08:09:57 PST Received: by multimax.ARPA (5.51/25-eef) id AA24169; Thu, 21 Jan 88 11:10:10 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA26219; Thu, 21 Jan 88 11:11:16 EST Message-Id: <8801211611.AA26219@mist.UUCP> To: cl-cleanup%sail.stanford.edu@multimax Subject: Issue: DISASSEMBLE-SIDE-EFFECT (version 3) Date: Thu, 21 Jan 88 11:11:14 EST From: Dan L. Pierson <pierson@mist> Issue: DISASSEMBLE-SIDE-EFFECT References: DISASSEMBLE (p. 439), COMPILE (p. 439) Category: CLARIFICATION Edit history: Version 2 by Pierson 12/30/87 Version 3 by Pierson 1/21/88 Status: Ready For Release? Problem description: The definition of DISASSEMBLE says that "if the relevant function is not a compiled function, it is first compiled.". The definition of COMPILE says that "If name is a non-nil symbol, then the compiled-function is installed as the global function definition of the symbol...". Several implementations have taken this to mean that if DISASSEMBLE is passed a symbol which has an uncompiled function definition, then it has the side-effect of (COMPILE 'symbol). Proposal (DISASSEMBLE-SIDE-EFFECT:DO-NOT-INSTALL): Clarify that when DISASSEMBLE compiles a function, it will never install the newly compiled function. Test Cases/Examples: (DEFUN F (A) (1+ A)) (EQ (SYMBOL-FUNCTION 'F) (PROGN (DISASSEMBLE 'F) (SYMBOL-FUNCTION 'F))) This code will return T if this proposal is adopted. Some current implementations will return T, some will return NIL. Rationale: Several current implementations of DISASSEMBLE have surprising side effects, especially for new users. Current practice: Allegro CL and Vax Lisp install the compiled definition. Lucid, Symbolics, Xerox, and KCL don't install it. Cost to Implementors: Some implementations will have to make a simple change. Cost to Users: Very little. DISASSEMBLE is really part of the environment and is probably not called by much, if any user code. Cost of non-Adoption: DISASSEMBLE will continue to surprise less experienced users. Benefits: DISASSEMBLE will become the predictable debugging function it was meant to be. Aesthetics: Some who worried that DISASSEMBLE was supposed to install the compiled function may find that the language has become a little cleaner. Discussion: DISASSEMBLE is an environment feature; some question has been raised as to the place and force of environment features in the standard. However, this proposal stands if DISASSEMBLE is part of the standard language. ∂26-Jan-88 1244 CL-Cleanup-mailer Issue: REMF-MULTIPLE Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Jan 88 12:44:38 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 328834; Tue 26-Jan-88 15:44:51 EST Date: Tue, 26 Jan 88 15:44 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: REMF-MULTIPLE To: CL-Cleanup@SAIL.STANFORD.EDU Message-ID: <880126154442.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Issue: REMF-MULTIPLE References: REMPROP (p166), REMF (p167) Category: CLARIFICATION Edit history: 26-Jan-88, Version 1 by Pitman Status: For Internal Discussion Problem Description: The descriptions of REMF and REMPROP are not explicit about what happens in the case that a duplicated indicator occurs on the plist. One or both indicators might be removed. Proposal (REMF-MULITPLE:REMOVE-ONE): Clarify that REMF and REMPROP at most one indicator/value pair from the designated plist. Rationale: In a property list maintained by the normal property list operations, there will only be one property by each name. This approach won't waste time trying to remove other properties which are not present in the first place. Proposal (REMF-MULTIPLE:REMOVE-ALL): Clarify that REMF and REMPROP remove all matching indicator/value pairs from the designated plist. Rationale: In a property list maintained by other operations than the standard ones, this might be useful. Also, since the return value of REMF and REMPROP is not well-defined, iterating to remove more than one property is expensive because you have to start over from the head of the list. Test Case: ;; Case #1 - removing symbol properties,etc. using REMPROP (DEFUN REMF-MULTIPLE-TEST-1 () (LET ((SYMBOL (GENSYM))) (SETF (SYMBOL-PLIST SYMBOL) (LIST 'A 'B 'C 'D 'A 'B 'C 'D)) (FORMAT T "~&Before: ~S~%" (SYMBOL-PLIST SYMBOL)) (REMPROP SYMBOL 'A) (FORMAT T "~&After: ~S~%" (SYMBOL-PLIST SYMBOL)) (FORMAT T "~&This implementation uses REMF-MULTIPLE:~:[REMOVE-ALL~;REMOVE-ONE~] ~ for REMPROP.~%" (GET SYMBOL 'A)))) ;; Case #2 - removing keywords,etc. using REMF (DEFUN REMF-MULTIPLE-TEST-2 () (LABELS ((HELPER (&REST ARGUMENTS &KEY (A 1) (B 2)) (FORMAT T "~&Helper received: ~S~%" ARGUMENTS) (LIST A B)) (DRIVER (&REST ARGUMENTS) (FORMAT T "~&Helper received: ~S~%" ARGUMENTS) (SETQ ARGUMENTS (COPY-LIST ARGUMENTS)) (REMF ARGUMENTS ':A) (APPLY #'HELPER ARGUMENTS))) (LET ((RESULT (DRIVER :A 3 :B 4 :A 5 :B 6))) (FORMAT T "~&Returned: ~S~%" RESULT) (FORMAT T "~&This implementation uses REMF-MULTIPLE:~:[REMOVE-ALL~;REMOVE-ONE~] ~ for REMF.~%" (= (CAR RESULT) 5))))) Current Practice: Symbolics implements REMF-MULTIPLE:REMOVE-ONE. Cost to Implementors: For implementations needing to change, the cost of a change is probably very small in most cases. Implementations needing change which do REMPROP and/or REMF in microcode might have a slightly harder time, but any change should still be very localized. Cost to Users: None. Users must tread lightly on this issue right now because it is not well-defined. Cost of Non-Adoption: The language description would continue to be vague for no particularly good reason. Benefits: Users who want to use REMPROP or REMF in situations which involve lists that might have duplicated elements would be able to do so more reliably. Aesthetics: There is probably no particular aesthetic reason to think one of these solutions is better than the other, but having the issue nailed down is probably an aesthetic improvement. Discussion: Pitman is agnostic on this for now. There are advantages to both. If everybody already implements REMOVE-ONE, that would seem the way to go. ∂26-Jan-88 1307 CL-Cleanup-mailer Issue: EXPORT-IMPORT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Jan 88 13:07:09 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 328851; 26 Jan 88 16:07:13 EST Date: Tue, 26 Jan 88 16:07 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: EXPORT-IMPORT To: CL-Cleanup@SAIL.STANFORD.EDU cc: KMP@STONY-BROOK.SCRC.Symbolics.COM Message-ID: <880126160702.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Issue: EXPORT-IMPORT References: EXPORT (p186) Category: CLARIFICATION Edit history: 26-Jan-88, Version 1 by Pitman Status: For Internal Discussion Problem Description: The description of EXPORT in CLtL says that it makes its argument symbols become accessible as external symbols in PACKAGE.'' It does not specify how much work EXPORT should be willing to go through in order to make this happen. Proposal (EXPORT-IMPORT:YES): Clarify that if the symbols which are specified to EXPORT are not in [the argument] PACKAGE then EXPORT should do an implicit IMPORT of those symbols and then should EXPORT them. Rationale: In most cases where a package is going to export symbols from another package, the idiom (IMPORT '(symbol-a symbol-b ...)) (EXPORT '(symbol-a symbol-b ...)) must be written. Maintaining both lists consistently is more error-prone and it would be simpler if one could just write the EXPORT call and not worry about the import. Proposal (EXPORT-IMPORT:NO): Clarify that if the symbols which are specified to EXPORT are not in [the argument] PACKAGE then EXPORT should signal a continuable error. If continued, EXPORT should IMPORT the indicated symbols and continue. Rationale: The package system is very tricky and setting things up correctly is very difficult. The programmer should be asked to be explicit about intent so that the system can diagnose as many potential errors as possible. Test Case: (MAKE-PACKAGE 'EXPORT-TEST-PACKAGE :USE '()) (EXPORT '(CAR CDR CONS) (FIND-PACKAGE "EXPORT-TEST-PACKAGE")) Current Practice: Symbolics implements EXPORT-IMPORT:NO. (The error we signal says you can "Proceed without any special action." which doesn't make it completely clear that it will do the implicit import, but that's apparently what happens.) [Pitman is pretty sure several implementations implement EXPORT-IMPORT:YES because we get a lot of bug reports from people who seem to think this is something guaranteed but who cannot cite a passage saying where. Hopefully people will volunteer more cases here.] Cost to Implementors: Presumably this change would be very isolated and easy for implementors to make. Cost to Users: EXPORT-IMPORT:YES is upward-compatible, though produces diminished error checking. A change to EXPORT-IMPORT:NO might cause some users to have to write an explicit call to IMPORT in some package declarations. Since continuing the error mentioned in the EXPORT-IMPORT:NO spec will produce the EXPORT-IMPORT:YES behavior, though, the incompatibility should be easy to work around in a transition period. Cost of Non-Adoption: Users will continue to be frustrated by a vague description of EXPORT. Benefits: Users will know clearly what EXPORT does in a case which seems to come up fairly often in practice. Aesthetics: There are aesthetic pluses and minuses to both approaches. The most important thing is to get this nailed down. Discussion: Pitman supports EXPORT-IMPORT:NO. ∂27-Jan-88 0714 CL-Cleanup-mailer Issue: EXPORT-IMPORT Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 27 Jan 88 07:14:35 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Wed 27 Jan 88 10:14:51-EST Date: Wed, 27 Jan 1988 10:14 EST Message-ID: <FAHLMAN.12369955463.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: CL-Cleanup@SAIL.STANFORD.EDU Subject: Issue: EXPORT-IMPORT In-reply-to: Msg of 26 Jan 1988 16:07-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM> CMU Common Lisp (formerly Spice Lisp) implements NO. Presumably several derived implementations follow us in this. I don't have a strong opinion on this, one way or the other, but the "NO" option seems less likely to cause confusion, so I'm mildly in favor of "NO". -- Scott ∂28-Jan-88 0424 CL-Cleanup-mailer Issue: EXPORT-IMPORT Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 28 Jan 88 04:24:17 PST Received: by labrea.Stanford.EDU; Thu, 28 Jan 88 04:24:30 PST Received: from bhopal.lucid.com by edsel id AA23832g; Thu, 28 Jan 88 04:14:23 PST Received: by bhopal id AA03482g; Thu, 28 Jan 88 04:18:15 PST Date: Thu, 28 Jan 88 04:18:15 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8801281218.AA03482@bhopal.lucid.com> To: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU Subject: Issue: EXPORT-IMPORT Lucid Common Lisp implements NO (offering an error continuation option of importing the unavailable symbol). Although I'll admit that the proposal has some pragmatic merit, it hardly seems a pressing issue. Since Kent favors NO too, then I wonder where the interest if pushing it comes from? -- JonL -- ∂03-Feb-88 0750 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2) Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:50:47 PST Received: from WINTER.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 165444; Wed 3-Feb-88 09:13:15 EST Date: Wed, 3 Feb 88 09:13 EST From: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM> Subject: Issue: DECLARATION-SCOPE (Version 2) To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <19880203034640.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <19880203141314.4.HORNIG@WINTER.SCRC.Symbolics.COM> Date: Tue, 2 Feb 88 22:46 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> ... Here is a revision that addresses the only two suggested changes above where it was actually possible to take any action. I'd like to see this sent out, since I think this issue is important. I didn't check with Hornig before rewriting his proposal, so I hope I have not done any damage to it. I am happy with Moon's revisions. ... ∂03-Feb-88 0755 CL-Cleanup-mailer Issue: EXPORT-IMPORT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:55:34 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334267; Tue 2-Feb-88 20:22:39 EST Date: Tue, 2 Feb 88 20:22 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: EXPORT-IMPORT To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880126160702.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880203012230.4.MOON@EUPHRATES.SCRC.Symbolics.COM> I favor EXPORT-IMPORT:NO. I don't know of any implementations whose current practice is EXPORT-IMPORT:YES. I agree that it would be good to document more explicitly than CLtL which cases are errors. ∂03-Feb-88 0755 CL-Cleanup-mailer Issue: REMF-MULTIPLE Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:55:51 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334269; Tue 2-Feb-88 20:28:42 EST Date: Tue, 2 Feb 88 20:28 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: REMF-MULTIPLE To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880126154442.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880203012838.5.MOON@EUPHRATES.SCRC.Symbolics.COM> I favor withdrawal of the REMF-MULTIPLE issue. Here's why: The only thing that CLtL pages 163-167 says about duplicated indicators on plists is that there aren't any (first line on page 164). Contrary to what I thought, it does not even guarantee that GETF returns the first occurrence. If we're going to extend Common Lisp to allow duplicated indicators on plists, we should do it for all the property list functions, not just REMF and REMPROP. ∂03-Feb-88 0756 CL-Cleanup-mailer New, improved FUNCTION-TYPE-KEY-NAME proposal (version 2) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:56:39 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334273; Tue 2-Feb-88 20:36:34 EST Date: Tue, 2 Feb 88 20:36 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: New, improved FUNCTION-TYPE-KEY-NAME proposal (version 2) To: Sandra J Loosemore <sandra%orion@cs.utah.edu> cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8801152125.AA12185@orion.utah.edu> Message-ID: <19880203013624.6.MOON@EUPHRATES.SCRC.Symbolics.COM> I favor FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD. However, I'd like to point out a pitfall in the syntax, which I feel should be documented in the discussion section. It may not be evident to a user whether the proper declaration for MAKE-LIST is (FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST) or (FUNCTION MAKE-LIST ((INTEGER 0) &KEY (INITIAL-ELEMENT T)) LIST) The former is what you propose, but the latter is more analogous to regular lambda lists. If the former is correct, it would not be valid for a compiler to diagnose the latter as invalid (note that X3J13 accepted KEYWORD-ARGUMENT-NAME-PACKAGE in November). I don't see any way around this problem, as I think the former declaration, as you proposed, probably is the more desirable choice. Also you didn't say in your proposal whether you intend that such a declaration, without &ALLOW-OTHER-KEYS, is also a declaration that only the listed keywords are valid. This should be stated explicitly. ∂03-Feb-88 0757 CL-Cleanup-mailer Issue: FLET-DECLARATIONS (Version 2) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:56:52 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334282; Tue 2-Feb-88 21:04:33 EST Date: Tue, 2 Feb 88 21:04 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: FLET-DECLARATIONS (Version 2) To: Cl-Cleanup@SAIL.STANFORD.EDU cc: Hornig@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <19880101204506.6.MOON@EUPHRATES.SCRC.Symbolics.COM>, <880104-114503-2255@Xerox>, <880114-201827-4858@Xerox> Message-ID: <19880203020430.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 14 Jan 88 20:17 PST From: Masinter.pa@Xerox.COM I think this issue would be ready to mail out with just a few changes.... Here's the revised version, with your suggested changes. I don't think anyone has said they don't support this, so it should be ready to mail out. Issue: FLET-DECLARATIONS References: FLET, LABELS, MACROLET (CLtL p.113) X3J13 document 86-003 item 113 Cleanup issue DECLARATION-SCOPE. Cleanup issue DECLARE-MACROS. Category: ADDITION Edit history: Version 1, Moon, 1 Jan 1988 Version 2, Moon, 2 Feb 1988 (edits suggested by Masinter) Problem description: Declarations are not allowed before the body of FLET, LABELS, and MACROLET, even though Common Lisp allows declarations in other seemingly analogous places, such as LET. Proposal (FLET-DECLARATIONS:ALLOW): Change the syntax of FLET, LABELS, and MACROLET to allow declarations between the list of local function/macro definitions and the body forms. The scope of such declarations in FLET and LABELS includes the bodies of the locally defined functions, when the declarations are pervasive. Non-pervasive declarations have no effect on those bodies, except when LABELS includes the body in the scope of a function non-pervasively declared. This paragraph follows directly from CLtL p.155 if the locally defined function bodies are treated like initialization forms. (This paragraph will be superseded by cleanup issue DECLARATION-SCOPE if it passes.) The scope of such declarations does not include the bodies of the macro expander functions defined by MACROLET. This is consistent with the existing rule that the bodies of those functions are in the global environment, not the local lexical environment. If cleanup issue DECLARE-MACROS is not passed, in MACROLET an invocation of one of the macros locally defined by that MACROLET is permitted to expand into a DECLARE. Test Cases/Examples: (defun example (y l) (flet ((attach (x) (setq l (append l (list x))))) (declare (inline attach)) (dolist (x y) (unless (null (cdr x)) (attach x))) l)) (example '((a apple apricot) (b banana) (c cherry) (d) (e)) '((1) (2) (3) (4 2) (5) (6 3 2))) => ((1) (2) (3) (4 2) (5) (6 3 2) (a apple apricot) (b banana) (c cherry)) The above function is erroneous in current Common Lisp. With this proposal, it would have an intuitively obvious meaning. Rationale: This will make the syntax of FLET and LET consistent. This will make it possible to attach declarations to function bindings; currently only variable bindings can have attached declarations. Current practice: Xerox Common Lisp implements FLET-DECLARATIONS:ALLOW. Symbolics Common Lisp does not allow declarations in this position. Cost to Implementors: The compilation and interpretation of three special forms will have to be changed, however the same techniques already developed for declarations in LET should be applicable. Cost to Users: No cost since this is an upward-compatible addition. Cost of non-adoption: Unnecessary inconsistency in the syntax of Common Lisp. Benefits: There is no major benefit but the language will be more consistent. Esthetics: Makes the language more consistent. Discussion: We need to resolve this for CLOS, because CLOS introduces two new special forms similar to FLET and LABELS and we need to make their syntax consistent with FLET and LABELS. ∂03-Feb-88 0757 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 4) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:57:15 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334287; Tue 2-Feb-88 21:25:34 EST Date: Tue, 2 Feb 88 21:25 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: LOAD-TIME-EVAL (Version 4) To: cl-cleanup@SAIL.STANFORD.EDU, kempf%hplabsz@hplabs.hp.com, kempf%hplabs@hplabs.hp.com In-Reply-To: <870723-155014-1175@Xerox>, <871111-021711-6498@Xerox>, <880114-205432-4891@Xerox> Message-ID: <19880203022524.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 14 Jan 88 20:53 PST From: Masinter.pa@Xerox.COM The last mail on this topic was 12 November. Jul 23: Jim Kempf's version 2 mailed Nov 11: mail about a few typos and bugs in it which he agreed to adopt. Nov 12: Kent Pitman mailed version 3 Dave Moon replied. Version 2 is incompatible with Version 3. Do we go back to version 2 (#, as currently spec'd, allowed only within constants?) Yes. Here's a version 4, which is version 2 with your suggested corrections. I don't know if this meets Kent's requirements, since I never figured out precisely what they were. Issue: LOAD-TIME-EVAL References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70) Category: ADDITION Edit history: Version 2 submitted 7/17/87, James Kempf. Version 3, Pitman, 11/12/87 (alternate direction) Version 4, Moon, 2/1/88 (Version 2 with edits suggested by Masinter) Problem description: The specification of #, (load time evaluation) in Common Lisp provides a means, during compilation, of arranging for the evaluation of a quoted or (in some implementations) unquoted form within embedded forms processed by the reader, when the compiled file is loaded. Inhibition of processing when a file is loaded into the interpreter is possible using (EVAL-WHEN (LOAD) ... ). Code which is returned during macroexpansion, however, is not processed by the reader, so there is no way to arrange for deferral of processing until compiled file load time in macroexpanded code. Proposal (LOAD-TIME-EVAL:MAKE-LOAD-TIME-EVAL): Add the function MAKE-LOAD-TIME-EVAL: (MAKE-LOAD-TIME-EVAL <form> <env>) => <object> <form> is a Lisp form, <env> is an environment of the sort received by the &ENVIRONMENT argument to a macro, and <object> is the result of evaluating <form>. When MAKE-LOAD-TIME-EVAL is called from the interpreter or the COMPILE function, it simply evaluates <form> in the null lexical environment and returns its value. When MAKE-LOAD-TIME-EVAL is called during a file compilation, the <object> is a special object that is recognized at load time, when it occurs inside a constant. At load time, <form> is evaluated and its value is substituted for <object>. This is the same mechanism that the #, reader macro uses. MAKE-LOAD-TIME-EVAL uses its <env> argument and/or dynamic state to determine whether it is being called during a file compilation. Until Common Lisp is modified to specify the semantics of file compilation more precisely, this is necessarily implementation dependent. Example 1: (defmacro print-software-version (&environment env) (quote ,(make-load-time-eval '(format T "~A~%" (software-version)) env))) When interpreted or processed during invocation of COMPILE, this macro prints the value of (software-version) at macro expansion time and expands into (quote nil). When macroexpanded during a file compilation, printing is deferred until the compiled file is loaded, and the constant is still (quote nil). Example 2: (defmacro table-of-tables (&rest predicates &environment env) (quote ,(mapcar #'(lambda (predicate) (,predicate ,(make-load-time-eval (make-hash-table :test ',predicate) env))) predicates))) (table-of-tables eql equal) expands into (quote ((eql #<table :test eql>) (equal #<table :test equal>))) except that when macroexpanded during a file compilation, the tables are not created until load time. This example shows that the <object> returned by make-load-time-eval is recognized even when it is interior to a quoted constant. Rationale: Currently, there is no portable way to arrange for code returned from a macro to defer evaluation until load time. Current practice: Currently, every version of Common Lisp is required to implement compiler hooks for #, but, since this is only recognized by the reader, there is no portable way to achieve the same effect. Users of Portable CommonLoops are encouraged to implement something similar. Adoption Cost: The cost to implementors will depend on how #, is implemented. In some implementations, the primitives for implementing MAKE-LOAD-TIME-EVAL may already exist, in others, more substantial changes may be required. Cost of non-adoption: There are numerous possible uses for this facility. Version control and system building facilities (such as the example) and optimization of method invocation in the Common Lisp Object System come immediately to mind. While every implementation of Common Lisp could certainly provide an implementation specific facility, portability would suffer. Benefits: Portability. May make extensions to the Common Lisp Object system via. the metaobject protocol easier. Conversion Cost: Most applications developers should not see much difference. Esthetics: The proposal fills a hole in the spectrum of alternatives for deferring evaluation until a compiled file is loaded. Currently, code which is read by the reader can arrange for it to be done, as can top level code, but embedded code cannot. Discussion: There is likely to be some controversy about this proposal, since there is no universally agreed upon formal processing model for Common Lisp, but only a set of informal rules and various implementations. Those implementations which have the primitives available should be able to implement MAKE-LOAD-TIME-EVAL with little change to their kernels, those which don't may require more extensive modifications. ∂03-Feb-88 0757 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:57:36 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334297; Tue 2-Feb-88 22:46:51 EST Date: Tue, 2 Feb 88 22:46 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: DECLARATION-SCOPE (Version 2) To: cl-cleanup@SAIL.STANFORD.EDU cc: Hornig@ALDERAAN.SCRC.Symbolics.COM In-Reply-To: <880114-194617-4828@Xerox> Message-ID: <19880203034640.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 14 Jan 88 19:45 PST From: Masinter.pa@Xerox.COM In order for this proposal to go out in the mailing to X3J13 committee members, we will need a version of the proposal that reflects, either in the cost/benefit analysis, or in the discussion, the topics mentioned in the mail so far. In the hope of helping out, I re-read the mail on the topic. The suggested changes were: -- use a less judgemental term than normal'. Suggestions were bound' and binding-related'. Bound' doesn't have quite the right connotations, but I prefer it over normal'. -- change the scope of free' declarations to be something different from what CLtL p.155 defines to be the scope of pervasive' declarations. There was no coherent proposal, instead the discussion was diverted by a variety of red herrings. -- extend Common Lisp to allow TYPE declarations to be used free'. The proposal already mentions that X3J13 is discussing this. It's a complex issue, and is concerned with semantics rather than with scoping, so I believe it should be handled independently. -- extend Common Lisp to allow IGNORE declarations to be used free'. However, no meaningful interpretation of this was proposed. -- include a table of all existing declarations, showing whether they are normal' or free'. If you want to separate out the issues of type declarations into a separate proposal, then this proposal is misnamed, it probably should be DECLARE-SPECIAL-SCOPE and you need another one that is DECLARE-TYPE-SCOPE. Free type declarations are not a scoping issue. Personally, I think we are close enough to attempt a comprehensive set of rules for DECLARATION-SCOPE and that you should go for it; there's not that much time. Here is a revision that addresses the only two suggested changes above where it was actually possible to take any action. I'd like to see this sent out, since I think this issue is important. I didn't check with Hornig before rewriting his proposal, so I hope I have not done any damage to it. Issue: DECLARATION-SCOPE References: Section 9.1 (pp. 153-157). Cleanup issue FLET-DECLARATIONS. Category: CHANGE Edit history: V1: Hornig@Symbolics.COM -- 5 January 1988 Version 2, Moon, 2-Feb-1988 (edits based on discussion) Problem description: The description of the scope of declarations made with DECLARE is both unclear (although unambiguous) and arguably a mistake. The issue is whether the scope of some or all of the declarations includes code appearing in the non-body part of the special form containing the declaration. Proposal DECLARATION-SCOPING:LIKE-VARIABLE: For the purposes of this proposal, we divide all declarations introduced with DECLARE into two classes. When a declaration of a variable appears before the body of a special form or lambda-expression that binds that variable, the declaration is called bound'. All other declarations are called free'. This division replaces the division into pervasive, nonpervasive, and SPECIAL declarations appearing in CLtL. The scope of a bound' declaration is exactly the scope of the associated lexical variable or function. If the declaration is associated with a special variable, the scope is the scope the variable would have had if it had not been special. Free' declarations are scoped as if they appeared in a new LOCALLY form which surrounded the entire special form at the beginning of whose body the declaration appears. This is the same as what CLtL p.155 defines to be the scope of pervasive' declarations. The following is a complete listing of the types of declarations and their class (bound' or free'): SPECIAL declarations may be either bound', affecting both a binding and references, or free', affecting only references, depending on whether the declaration is attached to a variable binding, as described above. TYPE declarations may only be bound' (see next section). FTYPE and FUNCTION declarations may only be free' (see next section). INLINE declarations may only be free' (see next section). NOTINLINE declarations may only be free' (see next section). IGNORE declarations may only be bound'. OPTIMIZE declarations may only be free'. The free' or bound' scoping of implementation-dependent declaration specifiers is implementation-dependent. Interactions with other proposals: There has been some discussion in X3J13 of permitting free' TYPE declarations. This is a semantic issue, not a scoping issue, and should be treated independently. If Common Lisp is extended to permit declarations in FLET and LABELS forms, by acceptance of cleanup proposal FLET-DECLARATIONS:ALLOW, then declarations of functions (FTYPE, FUNCTION, INLINE, and NOTINLINE) which appear before the body of a FLET or LABELS form which defines that function are bound'. Such declarations in other contexts remain free'. Common Lisp is ambiguous about whether a variable may be bound several times by a single form. It has been proposed that multiple bindings be permitted for LET*, DO*, PROG* forms and for &AUX variables in lambda expressions. If multiple bindings are permitted, bound' declarations are treated as if there were a separate bound' declaration for each of the bindings. Examples: ;;; Some examples of free' and bound' declarations. (let ((a 1)) (declare (optimize speed)) ;this is a free' declaration (let ((b 2)) (declare (type integer b)) ;this is a bound' declaration (declare (special a)) ;this is a free' declaration ())) ;;; This example applies if you believe that FLET may have declarations. (flet ((foo (x) (1+ x))) (declare (notinline foo)) ;this is a bound' declaration (declare (notinline 1+)) ;this is a free' declaration ()) ;;; The following code is from Pavel. ;;; It produces 7 in existing implementations. ;;; If the proposal is adopted, it will produce 8. (let ((foo 6)) ;a special binding of FOO (declare (special foo)) ;bound' declaration (let ((foo 7)) ;a lexical binding of FOO (let ((foo (1+ foo))) ;is the second FOO special or not? (declare (special foo)) ;bound' declaration foo))) ;;; Treatment of LET* under the proposal if multiple bindings of the same name are allowed. ;;; This form produces the value 9. (let ((foo 6)) ;a special binding of FOO (declare (special foo)) ;bound' declaration (let ((foo 7)) ;a lexical binding of FOO (let* ((foo (1+ foo)) ;special binding, lexical reference (foo (1+ foo))) ;special binding, special reference (declare (special foo)) ;bound' declaration, applies to both bindings foo)) ;special reference Rationale: Bound' declarations are made to control a particular binding of a variable and should be scoped the same way as that binding. This is as true of bound' declarations which were pervasive under the old rules as it is of those that were not. Current practice: The bound'/free' division based on context replaces CLtL's static pervasive/nonpervasive/SPECIAL division. Most implementations implement the rules in CLtL. Symbolics currently implements rules based on Zetalisp which are different from both this proposal and Common Lisp. Symbolics plans to change to Common Lisp rules in the future. Cost to Implementors: The cost of implementing this change should be moderate. The change will be localized to a handful of places in the compiler and interpreter which apply declarations to variables. The other cost would be in providing tools for users to find programs whose meaning will change. Cost to Users: The proposal changes only the treatment of bound' declarations. This change will break very few existing production programs. It is possible to mechanically examine a program to determine whether its behavior would change under the new rules. This permits an implementation to provide a transition tool to ease conversion to the new definition. Cost of non-adoption: The ability of a bound' declaration to affect code outside the scope of the variable which it appears to declare has led to endless confusion and discussion at Symbolics, on the Common-Lisp mailing list, and elsewhere. It will continue to do so unless it is smoothed over somehow. Benefits: The costs of non-adoption will be avoided. Aesthetics: The distinction between bound' and free' declarations introduced by this proposal is a natural one. Discussion: A proposal to forbid free' declarations except in LOCALLY forms and a proposal to have free' declarations affect only the body were discarded as being too incompatible. The mapping from the existing pervasive/nonpervasive/SPECIAL division of declarations and the one proposed here is complex. In general, nonpervasive declarations are bound' and pervasive declarations are free'. SPECIAL declarations are either bound' or free' based on their context, and are no longer treated as a special case. Some historical support for having free' and bound' declarations: Date: Tue, 20 Dec 83 15:50 EST From: "David A. Moon" <Moon%SCRC-TENEX@MIT-MC.ARPA> Subject: Declarations To: Common-Lisp@SU-AI.ARPA ... There are two disjoint classes of declaration: those that are attached to a particular variable binding, and those that are not. Note that I am not discussing proclamations here; they have their own scoping rules which are different from the rules for declarations. The scoping rule for the first kind of declaration is that it applies to precisely the text that is in the lexical scope of the variable binding with which it is associated. Such declarations are shadowed by a variable binding for the same name inside their scope. Since the lexical scoping rules are very well and precisely defined, we already understand everything about this kind of declaration. The scoping rule for the second kind of declaration is that it is pervasive. The declaration is attached to a lambda-expression or to a form (one of the special forms listed on page 125). The declaration applies to all text inside that expression or form; there are no special cases such as init-forms of LET or DO. Such declarations are shadowed by a conflicting declaration inside their scope. Possible names for the two kinds of declaration are "lexical" and "pervasive" or "variable" and "non-variable." ... ∂03-Feb-88 0757 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal (Version 2) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 07:56:51 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334275; Tue 2-Feb-88 20:47:21 EST Date: Tue, 2 Feb 88 20:47 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal (Version 2) To: Sandra J Loosemore <sandra%orion@cs.utah.edu> cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8801152126.AA12191@orion.utah.edu>, <880115-144847-6100@Xerox>, <8801152357.AA12554@orion.utah.edu> Message-ID: <19880203014708.7.MOON@EUPHRATES.SCRC.Symbolics.COM> I strongly favor FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE, for the same reasons that Masinter gave. Date: Fri, 15 Jan 88 16:57:09 MST From: sandra%orion@cs.utah.edu (Sandra J Loosemore) I volunteered to write it up, not make it into a life-long crusade.... I know very, very well how you feel. :-) ∂03-Feb-88 0835 CL-Cleanup-mailer Issue: EXPORT-IMPORT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 08:35:17 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334619; Wed 3-Feb-88 09:11:16 EST Date: Wed, 3 Feb 88 11:34 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: EXPORT-IMPORT To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <19880203012230.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880203113410.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> The dialect of Common Lisp which Paul Robertson (my boss) wrote for the 386, and which later became the basis for the Cloe Runtime system (our native 386 Lisp) is an example of a Lisp where the implementor assumed that EXPORT was to do an implicit import. As Paul explains it to me, he doesn't see any ambiguity. The documentation says it makes the argument symbols accessible as externals of the designated package, and the only way to do that is to first import them if necessary, so that's what he does. He's not even sure why it needs a clarification -- from his point of view, all other implementations are simply buggy. I have to say I think he makes perfectly believable case and it's arguably reasonable to call this a request for an incompatible change, not just a clarification. But in any case, I think there's no question that there's at least an ambiguity. (By the way, Paul's preference is for EXPORT-IMPORT:YES, but I'm pretty sure he can be talked into EXPORT-IMPORT:NO if that's what everyone seems to think is best.) The reason for this issue in the first place is that we have an outstanding bug report from a Cloe customer who says that EXPORT is not doing an implicit IMPORT on the 3600 (while it is doing the IMPORT on the 386) and I'm trying to figure out which side to fix. So this is not a contrived issue (as Jonl suggested it might be). ∂03-Feb-88 0951 CL-Cleanup-mailer Issue: EXPORT-IMPORT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 09:51:44 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 334859; Wed 3-Feb-88 12:51:44 EST Date: Wed, 3 Feb 88 12:51 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: EXPORT-IMPORT To: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880203113410.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880203175149.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 3 Feb 88 11:34 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> The dialect of Common Lisp which Paul Robertson (my boss) wrote for the 386, and which later became the basis for the Cloe Runtime system (our native 386 Lisp) is an example of a Lisp where the implementor assumed that EXPORT was to do an implicit import. That changes the Current Practice picture from what I had thought based on the proposal and the ensuing discussion, which was that all known implementations had adopted EXPORT-IMPORT:NO. However, section 11.4, referenced from the description of EXPORT, is quite explicit. At the bottom of CLtL p.177 and the top of p.178, the operation of EXPORT is described in quite explicit terms that are not consistent with EXPORT-IMPORT:YES. Thus I suggest that the EXPORT-IMPORT issue should be dropped, as there is no ambiguity in the language definition. Steele's knuckles should be rapped for writing a book that contained explicit information which several highly skilled Lisp experts were unable to find even after repeated readings of the book. (No offense. It's a good book for what it was intended to be, it's just that we all turned around and asked it to be more. Blame all of us old Common Lisp folks for not realizing from the beginning that a more precise specification would be demanded.) Aside to Kent: We need to be a little more careful about the phrase "the Symbolics implementation" in the Current Practice writeups now, since there is more than one. ∂03-Feb-88 1843 CL-Cleanup-mailer Issue: EXPORT-IMPORT Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 18:43:50 PST Received: by labrea.Stanford.EDU; Wed, 3 Feb 88 18:44:08 PST Received: from bhopal.lucid.com by edsel id AA03576g; Wed, 3 Feb 88 17:34:44 PST Received: by bhopal id AA12488g; Wed, 3 Feb 88 17:38:55 PST Date: Wed, 3 Feb 88 17:38:55 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8802040138.AA12488@bhopal.lucid.com> To: labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU Cc: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU In-Reply-To: Kent M Pitman's message of Wed, 3 Feb 88 11:34 EST <880203113410.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Subject: Issue: EXPORT-IMPORT re: The reason for this issue in the first place is that we have an outstanding bug report from a Cloe customer who says that EXPORT is not doing an implicit IMPORT . . . and I'm trying to figure out which side to fix. So this is not a contrived issue (as Jonl suggested it might be). No, I didn't suggest that it was somehow contrived. Your original proposal mentioned that "some users" erroneously though that export was defined to do an import first, and I too have seen persons make this mistake. Instead, I question why IMPORT-EXPORT:YES comes up as a cleanup proposal (rather than as a topic for discussion on, say, the common-lisp mailing list). At best, more emphasis in the documentation might be needed, if users continue to be misled here. -- JonL -- ∂03-Feb-88 1844 CL-Cleanup-mailer Issue: EXPORT-IMPORT Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 18:44:10 PST Received: by labrea.Stanford.EDU; Wed, 3 Feb 88 18:44:26 PST Received: from bhopal.lucid.com by edsel id AA03683g; Wed, 3 Feb 88 17:43:28 PST Received: by bhopal id AA12513g; Wed, 3 Feb 88 17:47:47 PST Date: Wed, 3 Feb 88 17:47:47 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8802040147.AA12513@bhopal.lucid.com> To: labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU Cc: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU, labrea!common-lisp%sail@labrea.Stanford.EDU In-Reply-To: Kent M Pitman's message of Wed, 3 Feb 88 11:34 EST <880203113410.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Subject: Issue: EXPORT-IMPORT The reason why some users may be mislead about EXPORT is that they fail to heed the directive on the second line of p186: "See section 11.4 for details". The one paragraph description of EXPORT on p186 is grossly incomplete without reference to that other section, which cleary states: (p177, last paragraph) "The function EXPORT takes a symbol that is *accessible* in some specified package ... If the symbols is not accessible at all in the specified package, a correctable error is signalled that, upon continuing, asks the user whether the symbol should be imported." [my emphasis]. Every implementation I'm familiar with seems to implement the above semantics rigidly; no one quietly imports the symbol without first signalling an error. -- JonL -- ∂03-Feb-88 1857 CL-Cleanup-mailer Issue: EXPORT-IMPORT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 18:57:17 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 335471; Wed 3-Feb-88 21:56:43 EST Date: Wed, 3 Feb 88 21:56 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: EXPORT-IMPORT To: edsel!jonl@labrea.stanford.edu cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <8802040138.AA12488@bhopal.lucid.com> Message-ID: <880203215637.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I spoke to Paul and we're content to withdraw this issue based on Moon's reference to an authoritative (albeit slightly misplaced) section. I guess I try never to bring -anything- up on the Common-Lisp mailing list ever because it is too large to be of any practical value to me. I'm personally not interested in the simultaneous opinion of tens of thousands of implementors, users, and none-of-the-aboves if we can decide an issue amongst ourselves. I assume we all read Common-Lisp so it's hardly like having sent this out to Common-Lisp would have spared any of us. I treat Common-Lisp as a potential source for more topics for our discussions, not as an alternative forum for our discussions. ∂03-Feb-88 1945 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Feb 88 19:45:24 PST Received: by labrea.Stanford.EDU; Wed, 3 Feb 88 19:45:35 PST Received: from bhopal.lucid.com by edsel id AA04962g; Wed, 3 Feb 88 19:35:03 PST Received: by bhopal id AA12851g; Wed, 3 Feb 88 19:39:14 PST Date: Wed, 3 Feb 88 19:39:14 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8802040339.AA12851@bhopal.lucid.com> To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU Cc: labrea!cl-cleanup%SAIL@labrea.Stanford.EDU, labrea!Hornig%ALDERAAN.SCRC.Symbolics.COM@labrea.Stanford.EDU In-Reply-To: David A. Moon's message of Tue, 2 Feb 88 22:46 EST <19880203034640.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Issue: DECLARATION-SCOPE (Version 2) I'm not a little dismayed at the verbosity of this proposal. Does the following 3-sentence summary encompass most of the statement of problem: (1) Some declarations only affect how a particular instance of a binding is interpreted. [these are called 'bound' in the terminology of the proposal]. (2) Some don't. [i.e, they affect something else other than some property of a particular instance of a binding.] (3) Except for SPECIAL, no declaration in category (1) is permitted to have any other interpretation. [Thus (3) prevents the following "natural" extension of declare IGNORE: (locally ... (let ((x <computation>)) (declare (ignore x)) <body-without-x>) ...) <==> (locally (declare (ignore x)) ... (let ((x <computation>)) <body-without-x>) ...) ] The proposal, then, is presumably to clarify that (4) The scope of a bound' declaration is exactly the scope of the associated [lexical] variable or function. [Since only SPECIAL is permitted to have both 'free' and 'bound' meanings, then (4) really only applies to it, for otherwise, the scope of a 'bound' declaration is simply the one binding it is attached to.] A primary consequence of this is that (let ((x <computation>)) (declare (special x)) <body>) is not equivalent to (locally (declare (special x)) (let ((x <computation>)) <body>)) nor is it equivalent to (locally (declare (special x)) (let ((x <computation>)) (declare (special x)) <body>)) because the LOCALLY form would be permitted to affect the references in <computation> and the scope of the variable 'x' does not include the form <computation>. On the other hand, because the following SPECIAL declaration is not linked to the binding(s) occuring in the surrounding LET, then (let ((x <computation>)) (declare (special y)) <body>) is equivalent to (locally (declare (special y)) (let ((x <computation>)) <body>)) in which case the declaration *does* affect the (free) references to 'y' found in <computation>. Is this indeed the intended effect? If so, is this the answer to the questions about how to gag the compiler messages about "free" variables appearing in &optional (etc) init forms of defuns? Now, I think (3) above has some nasty consequences; in particular the inability to give local type declarations over a lexical interval. MacLisp wasn't scoped like this. I vaguely remember discussion a long time ago that the reason why Common Lisp variable declarations aren't scoped like this is because of the inadvertent capturing of lexically- apparent declarations by macroexpanded code. [Indeed, some implementations of DEFSUBST still have the bug that they have macro-expansion semantics rather than function-call semantics.] It would be a shame if the declarational scheme had to be castrated simply because no one could figure out a better solution to the captured lexical environment problem. I really don't see that having one construct -- ordinary macros -- that can lose referential transparency is so bad; we certainly need a "safe" version thereof, like DEFSUBST should be; but this hardly seems the time to grossly revise the semantics of macro expansion, which have other problems with lack of transparency. [Someone may point out that the phrase "Kohlbecker's Thesis" ought to be invoked here.] If the macro-induced lack of "referential transparency" isn't a factor at all in CL's prohibition against allowing "pervasive" declarations to affect bindings found in enclosed forms, then I apologies for the above two-paragraph excursion. But I still would like to see a more succinct 3-or-4-sentence summary of this proposal's problem description. -- JonL -- ∂03-Feb-88 2023 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Feb 88 20:22:51 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 335527; Wed 3-Feb-88 23:22:25 EST Date: Wed, 3 Feb 88 23:22 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: DECLARATION-SCOPE (Version 2) To: Jon L White <edsel!jonl@labrea.Stanford.EDU> cc: cl-cleanup@SAIL.STANFORD.EDU, Hornig@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <8802040339.AA12851@bhopal.lucid.com> Message-ID: <19880204042224.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 3 Feb 88 19:39:14 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> I'm not a little dismayed at the verbosity of this proposal. Hornig can correct me, but I believe that was in response to requests for clarity and specificity. Does the following 3-sentence summary encompass most of the statement of problem: (1) Some declarations only affect how a particular instance of a binding is interpreted. [these are called 'bound' in the terminology of the proposal]. (2) Some don't. [i.e, they affect something else other than some property of a particular instance of a binding.] Sorry, but I can't figure out what precisely the above two sentences mean. (3) Except for SPECIAL, no declaration in category (1) is permitted to have any other interpretation. There appear to be several types of declarations that can be either free or bound, depending on whether they appear attached to a binding of the variable or function that they declare, or appear someplace else. The major error in the existing declaration scoping, I feel, was the idea that pervasive or non-pervasive could be a property of a declaration specifier, independent of context. [Thus (3) prevents the following "natural" extension of declare IGNORE: (locally ... (let ((x <computation>)) (declare (ignore x)) <body-without-x>) ...) <==> (locally (declare (ignore x)) ... (let ((x <computation>)) <body-without-x>) ...) ] I can't figure out what you intend this supposedly natural extension to mean. The ignore declaration would apply to all references to x inside its scope, except for references shadowed by an inner binding of the name x. But this is nonsense! The ignore declaration applies to the absence of references; the only way it applies to references is the minor feature that CLtL suggests the compiler ought to warn if you declare a variable to be ignored and then reference it. The proposal, then, is presumably to clarify that (4) The scope of a bound' declaration is exactly the scope of the associated [lexical] variable or function. [Since only SPECIAL is permitted to have both 'free' and 'bound' meanings, then (4) really only applies to it, for otherwise, the scope of a 'bound' declaration is simply the one binding it is attached to.] It's not true that special is the only such declaration. A primary consequence of this is that (let ((x <computation>)) (declare (special x)) <body>) is not equivalent to (locally (declare (special x)) (let ((x <computation>)) <body>)) nor is it equivalent to (locally (declare (special x)) (let ((x <computation>)) (declare (special x)) <body>)) because the LOCALLY form would be permitted to affect the references in <computation> and the scope of the variable 'x' does not include the form <computation>. The above is true unless I have misunderstood what you're saying. On the other hand, because the following SPECIAL declaration is not linked to the binding(s) occuring in the surrounding LET, then (let ((x <computation>)) (declare (special y)) <body>) is equivalent to (locally (declare (special y)) (let ((x <computation>)) <body>)) in which case the declaration *does* affect the (free) references to 'y' found in <computation>. That's correct too, I believe. It's also the same as in CLtL. Is this indeed the intended effect? If so, is this the answer to the questions about how to gag the compiler messages about "free" variables appearing in &optional (etc) init forms of defuns? I can't figure out what that question has to do with any of this. Perhaps those questions were on some mailing list that I am happily not a member of? Now, I think (3) above has some nasty consequences; in particular the inability to give local type declarations over a lexical interval. MacLisp wasn't scoped like this. I vaguely remember discussion a long time ago that the reason why Common Lisp variable declarations aren't scoped like this is because of the inadvertent capturing of lexically- apparent declarations by macroexpanded code. [Indeed, some implementations of DEFSUBST still have the bug that they have macro-expansion semantics rather than function-call semantics.] It would be a shame if the declarational scheme had to be castrated simply because no one could figure out a better solution to the captured lexical environment problem. I really don't see that having one construct -- ordinary macros -- that can lose referential transparency is so bad; we certainly need a "safe" version thereof, like DEFSUBST should be; but this hardly seems the time to grossly revise the semantics of macro expansion, which have other problems with lack of transparency. [Someone may point out that the phrase "Kohlbecker's Thesis" ought to be invoked here.] If the macro-induced lack of "referential transparency" isn't a factor at all in CL's prohibition against allowing "pervasive" declarations to affect bindings found in enclosed forms, then I apologies for the above two-paragraph excursion. I can't figure out what any of this means. Perhaps you're still going on about the fact that Hornig refuses to include in his DECLARATION-SCOPE proposal the unrelated proposal to change what CLtL says about TYPE, namely that it affects only variable bindings (not references)? I'm on Hornig's side there; it's not a good idea to bundle unrelated proposals together. If you want to change the rules for TYPE, and by the way I agree with you that they should be changed, just write a CL-Cleanup proposal to do so and let it stand on its own merits. It's completely and totally independent of Hornig's proposal. It can go into the language with exactly the same semantics regardless of whether Hornig's proposal is approved or rejected. The only difference would be whether the description of a TYPE declaration that is not attached to a binding uses the word "free" or uses the word "pervasive". But I still would like to see a more succinct 3-or-4-sentence summary of this proposal's problem description. It seems clear that my attempt to revise the proposal to make it clearer, in response to the mail discussion, didn't work. I'm willing to spend some more time helping with this proposal, but since I don't really understand what's unclear about it to you, I don't see what to change. Perhaps you could tell me what questions it doesn't answer. ∂04-Feb-88 1529 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Feb 88 15:29:09 PST Received: by labrea.Stanford.EDU; Thu, 4 Feb 88 15:29:25 PST Received: from bhopal.lucid.com by edsel id AA08824g; Thu, 4 Feb 88 14:13:28 PST Received: by bhopal id AA00979g; Thu, 4 Feb 88 14:17:52 PST Date: Thu, 4 Feb 88 14:17:52 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8802042217.AA00979@bhopal.lucid.com> To: labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU Cc: labrea!cl-cleanup%SAIL@labrea.Stanford.EDU, labrea!Hornig%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU In-Reply-To: David A. Moon's message of Wed, 3 Feb 88 23:22 EST <19880204042224.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Issue: DECLARATION-SCOPE (Version 2) re: It seems clear that my attempt to revise the proposal to make it clearer, in response to the mail discussion, didn't work. ... I don't really understand what's unclear about it to you, I don't see what to change. Perhaps you could tell me what questions it doesn't answer. Here's one, taken from our interchange: {JonL} [Since only SPECIAL is permitted to have both 'free' and 'bound' meanings then (4) really only applies to it, for otherwise, the scope of a 'bound declaration is simply the one binding it is attached to.] {Moon} It's not true that special is the only such declaration. I didn't fully believe that either, but taking the words from your rewriting of the proposal: The following is a complete listing of the types of declarations and their class (bound' or free'): SPECIAL declarations may be either bound', affecting both a binding and references, or free', affecting only references, depending on whether the declaration is attached to a variable binding, as described above. TYPE declarations may only be bound' (see next section). FTYPE and FUNCTION declarations may only be free' (see next section). INLINE declarations may only be free' (see next section). NOTINLINE declarations may only be free' (see next section). IGNORE declarations may only be bound'. OPTIMIZE declarations may only be free'. All except SPECIAL are restricted to one kind or the other, and this is alleged to be a complete list. Now, I would prefer to see SPECIAL, NOT/INLINE, and TYPE declarations all have the same scoping rules. For example, if the "cleanup" proposal for NOT/INLINE declarations on lexical functions were accepted, then a form like: (locally (declare (notinline car)) [1] (flet ((car (z) [2] (list (cdr z) (car z)))) [3] (declare (inline car)) [4] . . . (print (car x)))) [5] wouldn't be ambiguous, as it apprently now is. If NOTINLINE were scoped like this proposal for SPECIAL, then it would be clear that the declaration on line [4] applies only to the "car" defined on line [2], and that the usage of "car" on line [3] isn't affected by it {see how nice and parallel that is to the SPECIAL rules}; on the other hand, the usage on line [3] is affected by the 'free' declaration on line [1]. I hope that this is your preference too. One of the problems I had in reading the proposal was figuring out what you meant by "'bound' declaration". I realize that this isn't a specific question that you can "answer", but it was a concern. Apparently, in return, you couldn't figure out my question as to its meaning. I had asked if it was like: (1) Some declarations only affect how a particular instance of a binding is interpreted. [these are called 'bound' in the terminology of the proposal]. If I may try again, let me point to the declare on line [4] above. It applies to the *particular* instance of the binding of the name "car" on line [2], does it not? It says "interpret this function as an inline version of something named car". It doesn't separately apply to the usage on line [5], because [5] is a reference to the lexical name established by [2] and its properties are completely determined by that binding on line [2]. Furthermore, unlike MacLisp's scoping rules, the declare on line [4] would have no effect on any inner re-bindings (by FLET) of "car" such as might occur in the part elided ". . .". That's why I say "a particular instance of a binding". If this still isn't clear to you, and if no one else is particularly concerned about it, then maybe we could take any further comments "off-line". You have also expressed confusion as to what the non-standard code (locally (declare (ignore x)) (let ((x 3)) (mumble))) could possibly mean. I thought I stated it by giving an equivalent in standard code. That is, unlike existing practice, but *like* MacLisp, I could imagine it to mean the same as: (let ((x 3)) (declare (ignore x)) (mumble)) It shouldn't be too hard to believe that such a translation can be done fully mechanically. Since this kind of declaration inheritance was the norm in MacLisp, and since you used MacLisp for years, I didn't realize you'd have trouble remembering it [the "norm", in particular for SPECIAL and TYPE declarations]. I know only too well that such a interpretation of 'pervasive', or 'free', declarations conflicts with meaning given for them by CLtL -- that any inner binding of a name is completely shielded from any outer, lexical declarations. This is one of the two parts that differ substantially from MacLisp -- the other being that a declare before the body of a special form is not generally equivalent to the same declare wrapped LOCALLY around the form. But since PROCLAMations stick with the name, and are not walled-out by ordinary bindings, then it's not too hard to imagine some 'free' declarations operating this way. [One might use the term "shadowed" rather than "walled-out", but I dislike it since there is another technical meaning for "shadow"; also, the allegedly shadowing binding isn't by itself providing an alternate "shadowing" declaration.] I perceive the current dilemma, which "DECLARATION-SCOPE" proposes to alleviate in some small way, as stemming from Common Lisp's partial attempt to cure the problem of captured lexical declarations during macro expansion. That's all I intended to say in the two-paragraph essay near the end of my msg. Consequently, I'm totally amazed at your reply to it: . . . Perhaps you're still going on about the fact that Hornig refuses to include in his DECLARATION-SCOPE proposal the unrelated proposal to change what CLtL says about TYPE, . . . especially since I publicly lauded this proposal when it came out, and have never expressed dissatisfaction with Hornig's handling of it. I remember remarking on the similarity of the two issues -- they are *not* totally unrelated -- but that has nothing at all to do with the conjecture about "macroexpansions capturing lexical declarations". -- JonL -- ∂04-Feb-88 1620 CL-Cleanup-mailer cover letter for issues mailing Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Feb 88 16:20:02 PST Received: from Cabernet.ms by ArpaGateway.ms ; 04 FEB 88 16:20:22 PST Date: 4 Feb 88 16:20 PST From: Masinter.pa@Xerox.COM to: cl-cleanup@Sail.stanford.edu subject: cover letter for issues mailing Message-ID: <880204-162022-1310@Xerox> Hi -- I've just managed to make a pass thru my backlog of mail and hope to get the mailing ready in the next day or so. (I think this means getting it into the mail Monday morning, which I hope is not too late.) I propose to mail out at least the issues listed in my 14-Jan-88 message subject Issue status: READY FOR LETTER BALLOT and those few that seem to have reached convergence since then. (I'm not sure what those are yet, I haven't sorted out all the mail.) Subject: Issues from the cleanup sub-committee To: X3J13@Sail.stanford.edu reply-to: CL-CLEANUP@Sail.Stanford.EDU The cleanup committee has a number of issues for discussion and/or voting at the next X3J13 meeting. I will be mailing out those issues which are ready for voting at the next meeting, one at a time. I am uncertain as to the exact procedure for voting; I imagine that Bob Mathis will help clarify. My current understanding is that you should be prepared either to vote for endorsing a proposal or should prepare a written objection. Please address your replies directly to cl-cleanup@Sail.stanford.edu. We promise to summarize and redistribute any replies we get. X3J13@Sail.stanford.edu should *not* be used for technical discussions, however. The cleanup issues fall into several categories. Passed X3J13/Jun87: Mailed to X3J13 prior to the June 1987 meeting of X3J13 and passed (via voice vote) at that meeting. As these were distributed before, they will not be mailed again except by individual request, although the issues will appear on the ballot. Conditionally passed X3J13/Jun87, new version passed X3J13/Nov87: While an earlier version was mailed to X3J13 prior to the Jun87 meeting, the most recent version was distributed only in hardcopy at the November 1987 meeting. Passed X3J13/Nov87: Distributed only via hardcopy at the November 1987 meeting. New ballot items for Mar88: Not previously distributed to X3J13, but ready for voting. In discussion: Some of these issues may be distributed via electronic mail to X3J13 prior to the March meeting for discussion at the meeting, although they will not appear on a ballot at that time. ∂04-Feb-88 1722 CL-Cleanup-mailer Cleanup committee meeting prior to X3J13 Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Feb 88 17:22:26 PST Received: from Cabernet.ms by ArpaGateway.ms ; 04 FEB 88 17:22:48 PST Date: 4 Feb 88 17:22 PST From: Masinter.pa@Xerox.COM Subject: Cleanup committee meeting prior to X3J13 To: cl-cleanup@Sail.stanford.edu Message-ID: <880204-172248-1451@Xerox> I'm a bit disorganized at the moment, as I recall at least one message (from Scott Fahlman) that I can no longer find about a subcommittee meeting prior to X3J13. Since I can't find it, I may be off-base, but: I propose the cleanup committee meet on Tuesday morning, March 15, 9 AM-12 Noon. I think this leaves us some time for informal discussions before and after, and is not as likely to interfere with other subcommittee meetings. (The character subcommittee is proposed to meet all day Monday, Tuesday and Friday, so a conflict with it is currently unavoidable.) ∂05-Feb-88 1241 CL-Cleanup-mailer Ready issues Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Feb 88 12:40:59 PST Received: from Cabernet.ms by ArpaGateway.ms ; 05 FEB 88 12:33:45 PST Date: 5 Feb 88 12:33 PST From: Masinter.pa@Xerox.COM Subject: Ready issues To: cl-cleanup@Sail.stanford.edu Message-ID: <880205-123345-2825@Xerox> New for this meeting: - ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87) (Interaction of ADJUST-ARRAY and displaced arrays) - APPEND-DOTTED (Version 5, 14-Jan-88) (What happens to CDR of last CONS? in other than last arg?) - ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87) (Extend ASSOC-IF, etc. to allow :KEY) - COMPILER-WARNING-BREAK (Version 4,23-Nov-87 ) (Does *BREAK-ON-WARNING* affect the compiler?) - DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87) (Documentation string is not evaluated.) - DISASSEMBLE-SIDE-EFFECT (version 3, 21 Jan 88) (DISASSEMBLE doesn't smash the def if not compiled) - DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87) ( DO-SYMBOLS can the same symbol twice?) - FLET-DECLARATION (Version 2, 2 Feb 88) (Allow declarations in FLET, MACROLET) - PATHNAME-SYMBOL (Version 3, 23-OCT-87) (Do symbols automaticly coerce to pathnames?) - PUSH-EVALUATION-ORDER (Version 5,25-Nov-87) (What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?) - REDUCE-ARGUMENT-EXTRACTION (version 2, 30 Dec 87) (Add :KEY to REDUCE) - SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87) (Change recommendation for (get-setf-method symbol)?) - SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87) (Allow (DEFUN (SETF FOO) ..)) - SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43) (What does SHADOW do if symbol is already there?) - SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87) ( *FEATURES* are in the keyword package) Already passed: - AREF-1D (Version 7, 14-Nov-87) (Add a new function for accessing arrays with row-major-index) Version 5 conditionally passed X3J13/Jun87 Version 7 passed X3j13/Nov87 - COLON-NUMBER (Version 1, 22-oct-87) (Is :1 a number, a symbol, or undefined?) Version 1 passed X3J13/Nov87 - COMPILER-WARNING-STREAM (Version 6, 5-Jun-87) (Compiler warnings are printed on *ERROR-OUTPUT*) Version 6 passed X3J13/Jun87 - DEFVAR-INIT-TIME (Version 2, 29-May-87) (DEFVAR initializes when evaluated, not later.) Version 2 passed X3J13/Jun87. - DEFVAR-INITIALIZATION (Version 4, Jun-87) ((DEFVAR var) doesn't initialize) Version 4 passed X3J13, Jun87. - FLET-IMPLICIT-BLOCK (Version 6, 5-Jun-87) (do FLETs have implicit named blocks around them?) Version 6 passed X3J13/Jun87. - FORMAT-ATSIGN-COLON (Version 4, 5-jun-87) (@: == :@ in format) Version 4 passed X3J13/Jun87. - FORMAT-COMMA-INTERVAL (Version 2, 15 June 87) (paramerize number of digits between commas) Version 2 passed X3J13/Nov87 - FORMAT-OP-C (Version 5, 11-Jun-87) (What does ~C do?) Version 5 passed X3J13/Jun87. - GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87) (Environment argument for GET-SETF-METHOD) Version 4 conditionally passed X3J13/Jun87. Version 5 passed X3J13/Nov87. - IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87) (Does IMPORT affect home package?) Version 5 passed X3J13/Jun87. - KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87) (&KEY arguments not in keyword package?) Version 6 conditionally passed X3J13/Jun87. Version 8 passed X3J13/Nov87 - PATHNAME-STREAM (Version 6, 14-Nov-87) (PATHNAME only works on file streams) Version 2 conditionally passed X3J13/Jun 87 Version 6 passed X3J13/Nov 87 - PRINC-CHARACTER (Version 3) (PRINC behavior on character objections) Version 3 passed X3J13/Jun87. ----- End Forwarded Messages ----- ----- End Forwarded Messages ----- ∂05-Feb-88 1336 CL-Cleanup-mailer Re: Ready issues Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Feb 88 13:36:21 PST Received: from Cabernet.ms by ArpaGateway.ms ; 05 FEB 88 13:33:53 PST Date: 5 Feb 88 13:30 PST From: Masinter.pa@Xerox.COM Subject: Re: Ready issues In-reply-to: Masinter.pa's message of 5 Feb 88 12:33 PST To: Masinter.pa@Xerox.COM cc: cl-cleanup@Sail.stanford.edu Message-ID: <880205-133353-2970@Xerox> Ooops ... I meant to mail that to myself, rather than cl-cleanup. I'll have a real "ready issues" list available, hopefully by the end of the day. ∂05-Feb-88 2053 CL-Cleanup-mailer EXPORT-IMPORT and the other random commands Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 20:53:00 PST Received: from AI.AI.MIT.EDU by labrea.Stanford.EDU with TCP; Fri, 5 Feb 88 20:52:50 PST Date: Fri, 5 Feb 88 23:53:29 EST From: "Robert W. Kerns" <RWK@ai.ai.mit.edu> Subject: EXPORT-IMPORT and the other random commands To: CL.BOYER@r20.utexas.edu Cc: common-lisp@sail.stanford.edu, edsel!jonl@labrea.stanford.edu, labrea!CL-Cleanup%SAIL@labrea.stanford.edu, labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu In-Reply-To: Msg of Wed 3 Feb 88 21:48:23-CST from Bob Boyer <CL.BOYER at R20.UTEXAS.EDU> Message-Id: <322177.880205.RWK@AI.AI.MIT.EDU> Date: Wed 3 Feb 88 21:48:23-CST From: Bob Boyer <CL.BOYER at R20.UTEXAS.EDU> I think that the "Put in seven extremely random user commands" stuff needs to be documented much more rigorously. I don't think that any collection of cross-references in CLTL will suffice to make things clear. Frankly, I think this would be a waste of time. I don't think ANY amount of documenting and test suites has any chance of working. The underlying idea that you define the package environment by performing a series of side-effects on the package system is so wrong it is beyond repair. It is so entirely sensitive to complex and obscure order-of-events issues that even if you were successful in getting all implementations to do exactly the same thing, real-life users could not adaquately standardize their workstyles and interactions to avoid problems, even if they could understand all the rules! I think the time would be better spent on specifying and adopting a DEFPACKAGE macro. This would always be the first form of the first file loaded. (Or at least, before any IN-PACKAGE's for that package). I think it is much easier to specify the behaviour when you don't have to consider all the order-of-operations issues. Of course, it still needs to be carefully specified, but the problem is more constrained, and you're not so burdened with issues of compatibilty or programing environment issues. There are quite a number of us who think the DEFPACKAGE issue is important, but so far as I know there aren't any actual proposals being written up. ∂05-Feb-88 2056 CL-Cleanup-mailer {Improved version} EXPORT-IMPORT and the other random commands Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 5 Feb 88 20:56:15 PST Received: from AI.AI.MIT.EDU by labrea.Stanford.EDU with TCP; Fri, 5 Feb 88 20:56:08 PST Date: Fri, 5 Feb 88 23:56:53 EST From: "Robert W. Kerns" <RWK@ai.ai.mit.edu> Subject: {Improved version} EXPORT-IMPORT and the other random commands To: CL.BOYER@r20.utexas.edu Cc: common-lisp@sail.stanford.edu, edsel!jonl@labrea.stanford.edu, labrea!CL-Cleanup%SAIL@labrea.stanford.edu, labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu Message-Id: <322178.880205.RWK@AI.AI.MIT.EDU> Date: Wed 3 Feb 88 21:48:23-CST From: Bob Boyer <CL.BOYER at R20.UTEXAS.EDU> I think that the "Put in seven extremely random user commands" stuff needs to be documented much more rigorously. I don't think that any collection of cross-references in CLTL will suffice to make things clear. You've identified an important issue, *BUT*: Frankly, I think this approach would be a waste of time. I don't think ANY amount of documenting and test suites has any chance of working. The underlying idea that you define the package environment by performing a series of side-effects on the package system is so wrong it is beyond repair. It is so entirely sensitive to complex and obscure order-of-events issues that even if you were successful in getting all implementations to do exactly the same thing, real-life users could not adaquately standardize their workstyles and interactions to avoid problems, even if they could understand all the rules! I think the time would be better spent on specifying and adopting a DEFPACKAGE macro. This would always be the first form of the first file loaded. (Or at least, before any IN-PACKAGE's for that package). I think it is much easier to specify the behaviour when you don't have to consider all the order-of-operations issues. Of course, it still needs to be carefully specified, but the problem is more constrained, and you're not so burdened with issues of compatibilty or programing environment issues. There are quite a number of us who think the DEFPACKAGE issue is important, but so far as I know there aren't any actual proposals being written up. Presumably the issue is one of manpower to address it, not of lack of interest, so I would be dissapointed to see us discuss ways of "fixing" this rather bleak area of CL, rather than working on DEFPACKAGE. ∂07-Feb-88 1207 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Feb 88 12:07:19 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338018; Sun 7-Feb-88 15:07:23 EST Date: Sun, 7 Feb 88 15:07 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal To: sandra%orion@cs.utah.edu cc: cl-cleanup@sail.stanford.edu In-Reply-To: <8801152126.AA12191@orion.utah.edu> Message-ID: <880207150705.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> My preference is for EXTEND-LIST-TYPE because: * I'm afraid USE-ACTUAL-ARGUMENT-TYPE will get us into trouble somehow. * I find it bothersome that the same argument declarations which are used internally in the function would not be be usable externally. * I think it's unfair to provide only this special-purpose way of declaring a sequence type when in fact there are numerous other places in the language where it might be useful to declare a sequence type. If we did go with USE-ACTUAL-ARGUMENT-TYPE, it should be stated explicitly (if it is not already in CLtL somewhere) that the following is illegal: (DEFUN FOO (&REST X) X) (APPLY #'FOO T) since there will be no way to type-declare this. Even though this is an obscure case (that doesn't even work in some implementations), it's the sort of thing that makes me queasy about USE-ACTUAL-ARGUMENT-TYPE. I'm content to have the proposal presented as USE-ACTUAL-ARGUMENT-TYPE and I expect that will pass, but I want to be listed as dissenting. ∂07-Feb-88 1224 CL-Cleanup-mailer Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Feb 88 12:24:15 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338037; Sun 7-Feb-88 15:22:35 EST Date: Sun, 7 Feb 88 15:22 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Re: Issue: DISASSEMBLE-SIDE-EFFECT (version 2) To: Masinter.pa@Xerox.COM cc: pierson@mist.ARPA, CL-Cleanup@SAIL.Stanford.EDU In-Reply-To: <880114-200421-4849@Xerox> References: The message of 30 Dec 87 19:26 EST from Dan L. Pierson <pierson@mist.ARPA> Message-ID: <880207152219.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: 14 Jan 88 20:03 PST From: Masinter.pa@Xerox.COM I think we can ship a version 3 that has the [[]] remarks removed. Probably we want to add to the Discussion section. What do folks think about a paragraph like: DISASSEMBLE is an environment feature; some question has been raised as to the place and force of environment features in the standard. However, this proposal stands if DISASSEMBLE is part of the standard language. All fine with me. ∂07-Feb-88 1242 CL-Cleanup-mailer New, improved FUNCTION-TYPE-KEY-NAME proposal (version 2) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Feb 88 12:41:59 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338083; Sun 7-Feb-88 15:41:47 EST Date: Sun, 7 Feb 88 15:41 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: New, improved FUNCTION-TYPE-KEY-NAME proposal (version 2) To: sandra%orion@cs.utah.edu cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8801152125.AA12185@orion.utah.edu> References: <19880203013624.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880207154134.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I also am mostly happy with version 2 of FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD, though I'd like to see it address Moon's concern about specifying clearly whether the declared keyword list is exhaustive. By the way, on a related point, if I specify FOO as: (FUNCTION FOO (&KEY (:A INTEGER) (:B INTEGER) &ALLOW-OTHER-KEYS)) is it safe to assume that other keys are really ignored. Does this mean I have done: (DEFUN FOO (&KEY A B &ALLOW-OTHER-KEYS) ...) in which case the other keys are literally discarded, or might I have done: (DEFUN FOO (&REST Z &KEY A B &ALLOW-OTHER-KEYS) ...) in which case the other keys might not really be getting ignored. Some clarification on this point might also be useful. ∂07-Feb-88 1300 CL-Cleanup-mailer Re: {Improved version} EXPORT-IMPORT and the other random commands Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 88 13:00:33 PST Received: from tully.Berkeley.EDU ([128.32.150.44]) by labrea.Stanford.EDU with TCP; Sun, 7 Feb 88 13:00:31 PST Received: by tully.Berkeley.EDU (5.57/1.25) id AA07693; Sun, 7 Feb 88 00:15:20 PST From: hilfingr%tully.Berkeley.EDU@berkeley.edu (Paul Hilfinger) Message-Id: <8802070815.AA07693@tully.Berkeley.EDU> To: "Robert W. Kerns" <RWK@ai.ai.mit.edu> Cc: CL.BOYER@r20.utexas.edu, common-lisp@sail.stanford.edu, edsel!jonl@labrea.stanford.edu, labrea!CL-Cleanup%SAIL@labrea.stanford.edu, labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu Subject: Re: {Improved version} EXPORT-IMPORT and the other random commands In-Reply-To: Your message of Fri, 05 Feb 88 23:56:53 EST. <322178.880205.RWK@AI.AI.MIT.EDU> Date: Sun, 07 Feb 88 00:15:12 PST I'm also interested in seeing the "package problem" cleared up. I have two questions. 1) Has anyone written a definitive "why CL packages stink" article or message, preferably one that someone regards as definitive? 2) You write > ... The underlying idea that you define the package environment > by performing a series of side-effects on the package system > is so wrong it is beyond repair. It is so entirely sensitive > to complex and obscure order-of-events issues that even if > you were successful in getting all implementations to do > exactly the same thing, real-life users could not adaquately > standardize their workstyles and interactions to avoid > problems, even if they could understand all the rules! > > I think the time would be better spent on specifying and > adopting a DEFPACKAGE macro. This would always be the first > form of the first file loaded. (Or at least, before any > IN-PACKAGE's for that package).... Are you saying that this DEFPACKAGE macro would NOT have any side-effects on the package system? How would it have its effect? Or, more generally, what is the underlying idea with which you want to replace "side-effects on the package system"? (Somehow, electronic mail adds an unwonted note of harshness to my syntax; that last question was meant to be straight, not rhetorical.) Paul Hilfinger U. C. Berkeley Hilfinger@Berkeley.EDU ∂07-Feb-88 1306 CL-Cleanup-mailer {Improved version} EXPORT-IMPORT and the other random commands Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Feb 88 13:06:43 PST Received: from AI.AI.MIT.EDU by labrea.Stanford.EDU with TCP; Sun, 7 Feb 88 13:06:31 PST Date: Sun, 7 Feb 88 07:04:36 EST From: "Robert W. Kerns" <RWK@ai.ai.mit.edu> Subject: {Improved version} EXPORT-IMPORT and the other random commands To: hilfingr%tully.Berkeley.EDU@ucbvax.berkeley.edu Cc: common-lisp@sail.stanford.edu, CL.BOYER@r20.utexas.edu, edsel!jonl@labrea.stanford.edu, labrea!CL-Cleanup%SAIL@labrea.stanford.edu, labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu In-Reply-To: Msg of Sun 07 Feb 88 00:15:12 PST from hilfingr%tully.Berkeley.EDU at berkeley.edu (Paul Hilfinger) Message-Id: <322657.880207.RWK@AI.AI.MIT.EDU> Date: Sun, 07 Feb 88 00:15:12 PST From: hilfingr%tully.Berkeley.EDU at berkeley.edu (Paul Hilfinger) I'm also interested in seeing the "package problem" cleared up. I have two questions. 1) Has anyone written a definitive "why CL packages stink" article or message, preferably one that someone regards as definitive? I don't think there's complete agreement on all the reasons why "CL packages stink". Personally, in fact, I think they're not bad, in use, but the setup is what stinks. Others would disagree. But I think there's pretty good agreement that the seven extremely perverse functions are perverse. 2) You write > ... The underlying idea that you define the package environment > by performing a series of side-effects on the package system > is so wrong it is beyond repair. It is so entirely sensitive > to complex and obscure order-of-events issues that even if > you were successful in getting all implementations to do > exactly the same thing, real-life users could not adaquately > standardize their workstyles and interactions to avoid > problems, even if they could understand all the rules! > > I think the time would be better spent on specifying and > adopting a DEFPACKAGE macro. This would always be the first > form of the first file loaded. (Or at least, before any > IN-PACKAGE's for that package).... Are you saying that this DEFPACKAGE macro would NOT have any side-effects on the package system? How would it have its effect? Or, more generally, what is the underlying idea with which you want to replace "side-effects on the package system"? No, the important word up there was "series". There's no problem with a single declarative form, at the very start. It's when you dribble things out over several files with a series of "functions" which have to be treated specially by the compiler, that you start running into problems. Not to mention the confusion factor. The very fact that this silly mnemonic (which I can never remember) is needed to keep the order straight should be a dead givaway that something is wrong with splitting up declaring the package into a series of micro-steps. You might think of these as "package microcode". It shouldn't be supprising that there are dependencies on the particular way an implementation does its environment. If you declare imports, exports, inheritences, etc. at the same time you CREATE the package, you can't have any problems with symbols accidentally getting created before things are set up right. (Just for one example). (Somehow, electronic mail adds an unwonted note of harshness to my syntax; that last question was meant to be straight, not rhetorical.) I know the problem. You'll notice I sent an improved version of my note, when I noticed it sounded like I was being critical of Bob Boyer's complaint. (Instead of urging a different approach to solving it). Paul Hilfinger U. C. Berkeley Hilfinger@Berkeley.EDU ∂08-Feb-88 0901 CL-Cleanup-mailer New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal Received: from VALLECITO.SCRC.Symbolics.COM (SCRC-VALLECITO.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 09:01:27 PST Received: from EUPHRATES.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 202361; Mon 8-Feb-88 12:01:38 EST Date: Mon, 8 Feb 88 12:00 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: New version of FUNCTION-TYPE-REST-LIST-ELEMENT proposal To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> cc: sandra%orion@cs.utah.edu, cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <880207150705.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880208170043.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Sun, 7 Feb 88 15:07 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> My preference is for EXTEND-LIST-TYPE because.... Does this mean you have a solution in mind for the well-known problems with the element-type argument to the ARRAY type specifier? If so, I'd like to hear it. If not, I think you would be heading towards making the LIST and SEQUENCE type specifiers either have the same problem or be inconsistent with ARRAY. ∂08-Feb-88 1031 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:31:29 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338697; Mon 8-Feb-88 13:30:18 EST Date: Mon, 8 Feb 88 13:30 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 1) To: pierson@MULTIMAX.ARPA cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM, franz!smh@BERKELEY.EDU In-Reply-To: <8801192339.AA20676@mist.UUCP> Message-ID: <880208133005.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I can't support this proposal. I believe that the correct fix is for wording to be added that explains that *TERMINAL-IO* might be a bidirectional stream which directs input from and to a virtual and not necessarily a physical terminal. As such, *TERMINAL-IO* should properly be initialized to (MAKE-TWO-WAY-STREAM SYSTEM-INTERNALS:*UNIX-STANDARD-INPUT* SYSTEM-INTERNALS:*UNIX-STANDARD-OUTPUT*) If it were, then *STANDARD-INPUT* and *STANDARD-OUTPUT* would behave correctly with no relaxation of the requirements on their initial values. I think it is important that *STANDARD-INPUT*, *STANDARD-OUTPUT*, etc. be defined to be bound to synonym streams initially. Here are some reasons: * It may be important to the programmer to recover the value of this virtual terminal. There is already a restriction on binding *TERMINAL-IO* in Common Lisp, so the virtual terminal will always be accessible from *TERMINAL-IO*. If the virtual terminal were in *STANDARD-INPUT* and *STANDARD-OUTPUT*, the user might bind himself into a corner where he could no longer recover the value of the virtual terminal. * I think the initial I/O pairing should be available as a unit rather than in two different places. * If there is no physical console, the value of *TERMINAL-IO* will have garbage. There is no reason that input/output from/to programs to *TERMINAL-IO* should fail just because an alternate input or output stream was provided. You cannot make *TERMINAL-IO* indirect via synonym stream to *STANDARD-INPUT*,etc. without risking complete disaster. If it did, the user might do: (LET ((*STANDARD-INPUT* (MAKE-SYNONYM-STREAM '*TERMINAL-IO*))) ...) and get a circular synonym stream. In order to make sure that programs can portably use synonym streams at all, it is extremely important that the directionality of synonym streams be well-defined (ie, from *STANDARD-INPUT* to *TERMINAL-IO* and not vice versa) and that there be a known bottoming out point, *TERMINAL-IO*, which cannot be a synonym stream to anything the user can get his hands on. ∂08-Feb-88 1033 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 2) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:33:42 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338699; Mon 8-Feb-88 13:32:48 EST Date: Mon, 8 Feb 88 13:32 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 2) To: pierson@MULTIMAX.ARPA cc: CL-Cleanup@SAIL.Stanford.EDU In-Reply-To: <8712310035.AA19317@mist.UUCP> Message-ID: <880208133244.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I support REDUCE-ARGUMENT-EXTRACTION:KEY. The Edit History seems to have lost the info about Version 1. That should be restored. There's a stray comma at the end of the References field. ∂08-Feb-88 1037 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 4) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:36:53 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338711; Mon 8-Feb-88 13:36:22 EST Date: Mon, 8 Feb 88 13:36 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: LOAD-TIME-EVAL (Version 4) To: CL-Cleanup@SAIL.Stanford.EDU cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM, kempf%hplabs@hplabs.hp.com In-Reply-To: <19880203022524.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880208133616.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I'm afraid we're going in circles on LOAD-TIME-EVAL. I'm not in favor of this approach. Moon's Version 4 undoes all of what was important to me in Version 3. I'll try to get the relevant parties together for a meeting on this internally to Symbolics prior to the March meeting and we'll see if we can present a coherent front. ∂08-Feb-88 1040 CL-Cleanup-mailer Issue: FLET-DECLARATIONS (Version 2) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:40:36 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338723; Mon 8-Feb-88 13:40:23 EST Date: Mon, 8 Feb 88 13:40 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: FLET-DECLARATIONS (Version 2) To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM, Hornig@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <19880203020430.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880208134020.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I support FLET-DECLARATIONS:ALLOW. I found the second paragraph of the proposal part ("The scope of such ...") to be very hard to read. ∂08-Feb-88 1043 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:42:44 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338725; Mon 8-Feb-88 13:41:39 EST Date: Mon, 8 Feb 88 13:41 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 1) To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> cc: pierson@MULTIMAX.ARPA, CL-Cleanup@SAIL.STANFORD.EDU, franz!smh@BERKELEY.EDU In-Reply-To: <880208133005.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880208184148.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Kent, I agree with your comments, however you did not address yourself to the issue that Unix requires *STANDARD-OUTPUT* and *ERROR-OUTPUT* to go to different output destinations, while Common Lisp requires *STANDARD-OUTPUT* and *ERROR-OUTPUT* to be initially bound to synonyms for the same stream. I don't know precisely what the "correct fix" to Common Lisp is here, but I don't think it involves either making all the stream variables' bindings initially undefined, nor leaving all but *TERMINAL-IO* defined to be synonym streams to *TERMINAL-IO*. Maybe the variables should be defined in terms of their contracts rather than their implementations. I think the proposal needs another iteration based on a new idea. ∂08-Feb-88 1051 CL-Cleanup-mailer Issue: FLET-DECLARATIONS (Version 2) Received: from VALLECITO.SCRC.Symbolics.COM (SCRC-VALLECITO.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:51:31 PST Received: from EUPHRATES.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 202409; Mon 8-Feb-88 13:52:24 EST Date: Mon, 8 Feb 88 13:51 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: FLET-DECLARATIONS (Version 2) To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> cc: CL-Cleanup@SAIL.STANFORD.EDU, Hornig@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <880208134020.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880208185144.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 8 Feb 88 13:40 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> I found the second paragraph of the proposal part ("The scope of such ...") to be very hard to read. Then we should pass the DECLARATION-SCOPE proposal, which supersedes that paragraph. :-} ∂08-Feb-88 1058 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 10:58:21 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338755; Mon 8-Feb-88 13:58:07 EST Date: Mon, 8 Feb 88 13:57 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: DECLARATION-SCOPE (Version 2) To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM, Hornig@ALDERAAN.SCRC.Symbolics.COM In-Reply-To: <19880203034640.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880208135758.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I support DECLARATION-SCOPE:LIKE-VARIABLE, but I have some related issues I'd like to ask about while we're on the topic. I wonder about the following cases. Do we believe that they all follow clearly from the indicated rules (and/or other known and agreed upon rules)? (DEFUN FOO-1 (X) (DECLARE (INLINE FOO-1)) (+ X 1)) (DEFUN BAR-1 (X) (FOO-1 X)) Can FOO-1 be inlined in BAR-1? I say no because of modularity and incremental debugging constraints. I think there are implementations which do this inlining. I would like to see this and other situations treated explicitly. (DEFUN BAR-2 (X) (FLET ((FOO-2 (X) (DECLARE (INLINE FOO-2)) (+ X 1))) (FOO-2 X))) Can FOO-2 be inlined in BAR-2? I say it's not totally unreasonable and I wouldn't be surprised if some implementations have resorted to this as a way for users to say that FOO-2 is inline since they cannot put the information at the top of the FLET body. I found the wording of this proposal to be a little vague on whether this INLINE declaration spans the whole FLET, but my final impression was that it does. Is this right? Can we get this into the spec? Other examples I'd like to see made explicit: (DEFUN FOO-3 (X) (DECLARE (FUNCTION FOO-3 (FIXNUM) FIXNUM)) (+ X 1)) (DEFUN BAR-3 (X) (THE FIXNUM (+ (FOO-3 X) 1))) Can I use fixnum arithmetic in FOO-3? (I say yes.) Can I use fixnum arithmetic in BAR-3? (I say no, to avoid problems if one function is changed while the other is not.) (LABELS ((FOO-4 (X) (DECLARE (FUNCTION FOO-4 (FIXNUM) FIXNUM)) (+ X 1)) (BAR-4 (X) (THE FIXNUM (+ (FOO-4 X) 1)))) (FLET ((BAZ-4 (X) (THE FIXNUM (+ (FOO-4 X) 1)))) ...)) Can I use fixnum arithmetic in FOO-4? in BAR-4? In BAZ-4? I hope yes to all. ∂08-Feb-88 1112 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Feb 88 11:12:12 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 338778; Mon 8-Feb-88 14:10:25 EST Date: Mon, 8 Feb 88 14:10 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 1) To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, pierson@MULTIMAX.ARPA, CL-Cleanup@SAIL.STANFORD.EDU, franz!smh@BERKELEY.EDU In-Reply-To: <19880208184148.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880208141018.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Mon, 8 Feb 88 13:41 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Kent, I agree with your comments, however you did not address yourself to the issue that Unix requires *STANDARD-OUTPUT* and *ERROR-OUTPUT* to go to different output destinations, while Common Lisp requires *STANDARD-OUTPUT* and *ERROR-OUTPUT* to be initially bound to synonyms for the same stream. Ah, somehow I missed this issue. It should have been in the problem description, not in the test case/example section. I don't know precisely what the "correct fix" to Common Lisp is here, but I don't think it involves either making all the stream variables' bindings initially undefined, nor leaving all but *TERMINAL-IO* defined to be synonym streams to *TERMINAL-IO*. Maybe the variables should be defined in terms of their contracts rather than their implementations. Sounds like a plausible avenue to pursue. I think the proposal needs another iteration based on a new idea. Agreed. I'm certainly willing to continue entertaining discussion on the issue. If it helps the Unix guys putting together the next round of proposals, I'm willing to have relax the requirement that *ERROR-OUTPUT* be bound to a synonym stream to *TERMINAL-IO*. It's mainly the -IO* variables and *STANDARD-INPUT* and *STANDARD-OUTPUT* that I'm concerned about having point to *TERMINAL-IO* initially. *ERROR-OUTPUT* and *TRACE-OUTPUT* are less important to me as long as the issues are clearly documented. In fact, though, I think that many supposedly portable programs are -extremely- sloppy about distinguishing *ERROR-OUTPUT* and *TERMINAL-IO* and that lots of dumb problems like (FORMAT *ERROR-OUTPUT* "You did something bad: ...") (YES-OR-NO-P "Continue anyway? ") will be shown up if *ERROR-OUTPUT* and *TERMINAL-IO* do not initially point to the same stream. Maybe it's just as well that such bugs do get shown up, but I think there should be a guide to what kinds of things belong on *ERROR-OUTPUT* and what belongs on *QUERY-IO* and what on *TERMINAL-IO* and what on *STANDARD-OUTPUT*. We're still way too vague about all this. Any proposal to fix things must be more specific, not more vague, since systems cannot come up with "creative" solutions to the Unix problem in the absence of cooperation from the users. ∂10-Feb-88 0203 CL-Cleanup-mailer Issue: DECLARATION-SCOPE Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 02:02:58 PST Received: by labrea.Stanford.EDU; Wed, 10 Feb 88 02:02:57 PST Received: from bhopal.lucid.com by edsel id AA05180g; Wed, 10 Feb 88 01:45:42 PST Received: by bhopal id AA05095g; Wed, 10 Feb 88 01:50:27 PST Date: Wed, 10 Feb 88 01:50:27 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8802100950.AA05095@bhopal.lucid.com> To: labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU Cc: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU, labrea!Hornig%ALDERAAN.SCRC.Symbolics.COM.labrea!moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU In-Reply-To: Kent M Pitman's message of Mon, 8 Feb 88 13:57 EST <880208135758.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Subject: Issue: DECLARATION-SCOPE You are asking a broader set of questions that Horning apparently didn't want to address in his original cleanup proposal. There are a plethora of issues related to this -- the whole semantics of declarations in Common Lisp seems to be in disarray now. I think these broader issues must be raised, and that is one reason why what started out as a very small clarification has grown into a much larger controversy. Perhaps it was premature to think we could take the dragon by the tail and not feel his hot breath too. I would actually like to see a *coordinated* set of cleanup issues on declarations. "Coordinated", because it often doesn't make sense to talk about these issues in isolation; witness the extremely close link of this scoping proposal with the FLET-DECLARATIONS:ALLOW proposal. If this proposal -- DECLARATION-SCOPE:LIKE-VARIABLE is to be seriously considered in isolation, the I would at least like to suggest an alteration as outlined below. First, a very brief overview of the proposal: Hornig's purpose stated in the original message of "Tue, 5 Jan 88 08:21 EST" was: . . . The issue is whether the scope of some or all of the declarations includes code appearing in the non-body part of the special form containing the declaration. . . . Normal' declarations are made to control a particular binding of a variable and should be scoped the same way as that binding. This is as true of normal' declarations which were pervasive under the old rules as it is of those that were not. So the original DECLARATION-SCOPE proposal would seem to be addressing the specific kinds of problem illustrated by this example: (setf (symbol-value 'x) 0) (trace car) (defun foo (x y) (let ((x (car y)) (car (+ 4 x))) (declare (special x) (inline car +)) (list car (car x)))) A reasonable test, after compiling [and hypothetically assuming that a call to CAR that isn't declared "inline" will go out-of-line] works like: (foo 4 '((hello))) ==> {fn: CAR, arglist: ( ((hello)) )} ;trace output (8 hello) namely, that unlike in some implementations, the special declaration does not apply to the form "(+ 4 x)", and further, the inline declaration applies to "(car x)" but not to "(car y)". But still a lot of issues are left open. [One of them, for example, is how to say that the inline declaration of "car" above doesn't apply to the binding of the variable "car" established in the special form in which the declaration occurs 'normally'. It seems obvious to a reader with intuition; it's not so obvious from reading all the legalese and generalizations of a formal prescription.] I call attention again to Hornig's guiding principle: Normal' declarations are made to control a particular binding of a variable and should be scoped the same way as that binding. I think it would be a great simplification that declares in a binding special form (like, LET, PROG, LABELS, etc) should either "control a particular binding" and thus by definition have the scope of that binding [and nothing more], or be scoped as follows. For those declarations that in a binding special form that don't correlate with any of the bindings being established -- like the inline declaration for "+" in the example above -- their scope should be the same as if there had been a "variable" in the binding list for it to "control". That is, rather than (let ((z (+ 4 x))) (declare (special z) (inline +)) (+ z 5)) being equivalent to (locally (declare (inline +)) (let ((z (+ 4 x))) (declare (special z)) (+ z 5))) I think it would be more consistent for it to be equivalent to: (let ((z (+ 4 x))) (declare (special z)) (locally (declare (inline +)) (+ z 5))) I could submit a proposal called DECLARATION-SCOPE:FULLY-LEXICAL to specify this. But as I said before, I think there are a whole plethora of issues that ought to be considered together, so some attention needs to be paid to all the related issues. This FULLY-LEXICAL approach would help certify one of your feelings; you posed the example (DEFUN FOO-1 (X) (DECLARE (INLINE FOO-1)) (+ X 1)) (DEFUN BAR-1 (X) (FOO-1 X)) and suggeted that the inline declaration should not apply to the "reference" to FOO-1 in function BAR-1. Easily handled by the "lexical" approach. However, I would even question the appropriateness a form like (DEFUN FOO-3 (X) (DECLARE (FUNCTION FOO-3 (FIXNUM) FIXNUM)) (+ X 1)) The kind of binding being in this special form is a LAMBDA binding -- a "variable" binding, not a "function" binding -- so the ftype declaration on FOO-3 certainly doesn't apply to X. Hence it ought not to act like a global proclaim. Indeed, PROCLAIM exists precisely to cover the case of setting a global function cell; and this isn't the same kind of binding that occurs in, say, FLET, or LABELS. To achieve the effect you are supposing, you might have to say: (locally (declare (function foo-3 (fixnum) fixnum)) (defun foo-3 (x) (+ x 1))) or possibly (defun foo-3 (X) (flet ((foo-3 (x) (+ x 1))) (declare (function foo-3 (fixnum) fixnum)) (foo-3 x))) -- JonL -- ∂10-Feb-88 0858 Common-Lisp-Object-System-mailer Status of SETF functions in Common Lisp Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Feb 88 08:58:45 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 340430; Wed 10-Feb-88 11:57:41 EST Date: Wed, 10 Feb 88 11:57 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Status of SETF functions in Common Lisp To: Jon L White <edsel!jonl@labrea.Stanford.EDU> cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, sun!franz!smh@labrea.Stanford.EDU, rwk@AI.AI.MIT.EDU, CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <8802100814.AA05040@bhopal.lucid.com> Message-ID: <19880210165749.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 10 Feb 88 00:14:17 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Date: Thu, 4 Feb 88 14:46:35 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> .... re: But, haven't we already extended symbol-function to take lists of the form (setf fn) as an argument. If not, how do we get hold of setf generic-functions? I don't recall how the recent discussions on this mailing list suggested to do it. This was in a cleanup proposal which the Cleanup committee already approved, submitted to X3J13 in November, and was approved by X3J13 at that time. I wasn't there, so I don't know for sure what happened, but I don't think there was any voting. Perhaps there was some kind of verbal approval. Anyway my point is that this is as settled an issue as any issue can be and there's a place where the answer is written down. I don't have a copy of it myself or I'd send it to you. You're jumping the gun here. The issue of (setf fn) as a function name came up as a need from CLOS, but was never presented for approval. Then I guess one of Larry's status reports saying that issue had been approved was mistaken, or I misread it. Larry assigned a sub-sub-committee to try to write up some proposal that would encompass "function specs". That's exactly what I did -not- want to happen. If setf functions, which CLOS needs, get bogged down in all kinds of extraneous issues about function specs, which CLOS does not need and does not want, CLOS could end up getting the shaft. I think standardizing function specs for Common Lisp is likely to be a fine thing, but I don't want CLOS to have to wait for it to be completed. We (this sub-sub-...) have met by conference phone, and discussed what to do; initially Bob Kerns is working on a "definition specs" proposal that will clean up and extend the LispMachine's functions specs somewhat. But we all feel that this is new development -- not just a simple "clarification", or "cleanup" or minor extension to Common Lisp, and more serious thought needs to be given to the question. Most likely there will much discussion about it in Palo Alto next month. The only thing that's been settled so far is that we all agree on the need to do something. The actual scope of what is done, the names of the constructs, and as Danny asks "how do we get hold of setf generic-functions?" are hardly a settled issues right now. At any rate, I think he (Danny) was just asking how "we", the CLOS development, proposed to get access to these things. I guess I should wait until there is a report of the sub-sub-committee to read, before drawing any conclusions or making any more intemperate statements. ∂10-Feb-88 1007 CL-Cleanup-mailer Issue: DECLARATION-SCOPE (Version 2) Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 10 Feb 88 10:07:39 PST Received: ID <RAM@C.CS.CMU.EDU.#Internet>; Wed 10 Feb 88 13:08:48-EST Date: Wed, 10 Feb 1988 13:08 EST Message-ID: <RAM.12373657131.BABYL@> Sender: RAM@λλ From: Ram@C.CS.CMU.EDU To: cl-cleanup@SAIL.STANFORD.EDU Subject: Issue: DECLARATION-SCOPE (Version 2) In-reply-to: Msg of 8 Feb 1988 13:57-EST from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM> Date: Monday, 8 February 1988 13:57-EST From: Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM> To: Moon at STONY-BROOK.SCRC.Symbolics.COM Re: Issue: DECLARATION-SCOPE (Version 2) [...] I wonder about the following cases. I don't understand the unclarity that you seem to perceive in the rules for scoping. We may not agree on what the lexical scope for DECLARE should be, but I think we all agree that it is lexical. A DECLARE at the head of a DEFUN (or lambda, or let, or anything else) shouldn't affect anything outside of the body. The only pseudo-exception is macros, which are known to violate referential transparency. (DEFUN FOO-1 (X) (DECLARE (INLINE FOO-1)) (+ X 1)) (DEFUN BAR-1 (X) (FOO-1 X)) Can FOO-1 be inlined in BAR-1? No, because the call to FOO-1 isn't within the scope of the declaration. [...] I think there are implementations which do this inlining. I would like to see this and other situations treated explicitly. I agree, and in my compiler cleanup proposal I have treated the concept of compile-time function binding (which inlining is a special case of) at some length. (DEFUN BAR-2 (X) (FLET ((FOO-2 (X) (DECLARE (INLINE FOO-2)) (+ X 1))) (FOO-2 X))) Can FOO-2 be inlined in BAR-2? I say it's not totally unreasonable and I wouldn't be surprised if some implementations have resorted to this [...] Is this right? Can we get this into the spec? Yes, but not for the reason you say. A lexical function can be called however the compiler bloody well wants to, since there is no way that the user can ever redefine it. If the compiler happens to take a spurious declaration as a cue, that's fine, but it could just as well use the phase of the moon. But once again, it is clear that the INLINE declaration doesn't affect the function FOO-2 that you are talking about, it is allowing inline expansion of some other FOO-2 (presumably global) within the body of the lexical FOO-2. [...] (DEFUN FOO-3 (X) (DECLARE (FUNCTION FOO-3 (FIXNUM) FIXNUM)) (+ X 1)) Can I use fixnum arithmetic in FOO-3? (I say yes.) I don't think so, although this rides on a combination of interpretations of sticky points: function types in general, and pervasive function type declarations in particular. First of all, function type semantics require that the compiler prove that the argument is a fixnum before it can assume that the result is a fixnum. This means that even a global function type declaration is useless when compiling the body, since there is no way the compiler can convince itself it has seen all possible calls. Secondly, the interpretation of the pervasive function type declarations is really unclear, especially in the absence of any calls within the scope. It seems that what you are saying is that within this scope (but perhaps not elsewhere), FOO-3 will return a fixnum when given a fixnum. If the compiler could prove that a declaration that is true in this scope would be true in any scope (here plausible), then this type declaration could perhaps be applied to other calls, but only when the compiler could be sure that the same FOO-3 was being referred to, which is difficult given the lack of a general mechanism for allowing compile-time resolution of global function names. But the fact that there is no call to FOO-3 within the scope leads one to wonder whether any random declaration might be vacuously true. As I have said before, I think that the concept of function type in Common Lisp (as correctly interpreted) is fairly useless. In my compiler cleanup proposal, I handle compile-time function typing as a special case of compile-time function binding. If you have a proclamation that says all gloabal references to a function are to a version that has been processed by the compiler, then the compiler can propagate the types declared for the formal parameter variables to the actual calls. The compiler is free to use whatever type-inference method it pleases to determine the result type. The other examples you gave seem to refelect a similarly perplexing interpretation of pervasive function type declartions. Rob ∂11-Feb-88 1001 Common-Lisp-Object-System-mailer Re: Status of SETF functions in Common Lisp Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Feb 88 10:01:40 PST Received: from Salvador.ms by ArpaGateway.ms ; 11 FEB 88 10:00:52 PST From: masinter.PA@Xerox.COM Date: 11 Feb 88 10:00:26 PST Subject: Re: Status of SETF functions in Common Lisp In-reply-to: Moon@STONY-BROOK.SCRC.Symbolics.COM's message of Wed, 10 Feb 88 11:57 EST, <19880210165749.0.MOON@EUPHRATES.SCRC.Symbolics.COM> To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> cc: Jon L White <edsel!jonl@labrea.Stanford.EDU>, Common-Lisp-Object-System@SAIL.STANFORD.EDU, sun!franz!smh@labrea.Stanford.EDU, rwk@AI.AI.MIT.EDU, CL-Cleanup@SAIL.STANFORD.EDU Message-ID: <880211-100052-7099@Xerox> I've been out with the flu since last Friday afternoon (I thought it was just jet lag...) The issue SETF-FUNCTION-VS-SYMBOL was distributed and tentatively approved at the November 1987 meeting of X3J13. The larger question of generalizing this beyond SETF functions, and beyond merely DEFUN and FLET, seemed like it was open for another, larger, more comprehensive proposal. I'm still at home today and don't have easy access to all of the files. I'm hoping I am not too late to get the mailing out for X3J13 of all of the new issues. ∂11-Feb-88 1637 CL-Cleanup-mailer {Improved version} EXPORT-IMPORT and the other random commands Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 16:36:50 PST Received: from XX.LCS.MIT.EDU by labrea.Stanford.EDU with TCP; Thu, 11 Feb 88 16:36:41 PST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 11 Feb 88 19:28-EST Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 80142; 11 Feb 88 19:27:38-EST Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 93873; Wed 10-Feb-88 16:25:21-EST Date: Thu, 11 Feb 88 19:26 est From: mike%acorn@LIVE-OAK.LCS.MIT.EDU To: RWK@ai.ai.mit.edu Subject: {Improved version} EXPORT-IMPORT and the other random commands Cc: hilfingr%tully.Berkeley.EDU@ucbvax.berkeley.edu, common-lisp@sail.stanford.edu, CL.BOYER@r20.utexas.edu, edsel!jonl@labrea.stanford.edu, labrea!CL-Cleanup%SAIL@labrea.stanford.edu, labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu I'm also interested in seeing the "package problem" cleared up. I have two questions. 1) Has anyone written a definitive "why CL packages stink" article or message, preferably one that someone regards as definitive? I don't think there's complete agreement on all the reasons why "CL packages stink". Personally, in fact, I think they're not bad, in use, but the setup is what stinks. Others would disagree. I concur that they're ok, and even necessary for a symbolic language. The problem I feel is that they are good for preventing "symbol" mixups, but not "modularization". E.G., suppose you have a symbolic differentiator, and so do I, and we don't want my dx/ds symbol to be confused with your dx/ds symbol lest they not be able to work together on an expression being differentiated. Unfortunately, what packages are mostly used for is for some notion of "modules" or "subsystems". (I agree that in lisp systems which cons up expressions and eval or compile them that there is little difference between these two scenarios, and we have to allow for them, but most systems just don't do that kind of thing.) This is why I think the notion of LOCALE's from scheme or T or whatever keeps cropping up. My belief is that all "environment" (as opposed to package or "obarray") based approaches to solving name conflict problems are really designed to solve the problems of "modules" or "subsystems" for software engineering. This is a different problem from what packages can really solve. But I think there's pretty good agreement that the seven extremely perverse functions are perverse. The last thing I saw on the subject which was under consideration by the x3j13 compiler committee was a proposal to treat the "seven" specially as a compiled file header. This is more than just implicitly evaling them at compile time. Basically, this would clean up the issue of what "side effects" these have at compile time vs. load time of the compiled file. It would also bless specifically the notion of a file-format for common lisp programs, thereby making it clearly a lose to put IN-PACKAGE calls in the middle of files, etc. This has not been firmed up yet. What I think is needed is really a STYLE GUIDE to common lisp. Something that says how you OUGHT to program to avoid the majority of problems with things like the package system, etc. I think most package problems come from misuse. For instance, I would recommend that people be encouraged to avoid USE-PACKAGE other than for package LISP, and instead enumerate symbols one by one using the other package functions. My experience is that noone wants to qualify any names so what they do is carefully use every package that they've ever seen, not realizing that (let ((string "abcd")) ....) in their code is creating a spec-bind because they are using a package where string is a special. nuff said. ...mike beckerle ∂11-Feb-88 2044 CL-Cleanup-mailer Status of SETF functions in Common Lisp Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Feb 88 20:44:21 PST Received: by labrea.Stanford.EDU; Thu, 11 Feb 88 20:44:28 PST Received: from bhopal.lucid.com by edsel id AA14316g; Thu, 11 Feb 88 20:32:51 PST Received: by bhopal id AA10636g; Thu, 11 Feb 88 20:37:43 PST Date: Thu, 11 Feb 88 20:37:43 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8802120437.AA10636@bhopal.lucid.com> To: labrea!masinter.PA%Xerox.COM@labrea.Stanford.EDU Cc: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU, labrea!Common-Lisp-Object-System%SAIL.labrea!Moon%STONY-BROOK.SCRC.Symbolics.COM@labrea.Stanford.EDU, labrea!RG%AI.AI.MIT.EDU.sun!franz!smh@labrea.Stanford.EDU, labrea!rwk%AI.AI.MIT.EDU@labrea.Stanford.EDU In-Reply-To: masinter.PA@Xerox.COM's message of 11 Feb 88 10:00:26 PST <880211-100052-7099@Xerox> Subject: Status of SETF functions in Common Lisp re: The issue SETF-FUNCTION-VS-SYMBOL was distributed and tentatively approved at the November 1987 meeting of X3J13. The issue name was SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS It had two parts: (1) Specify that the expansion of SETF is into a function rather than merely into a "macro"; (2) Allow a generalized name for this function. The discussion under this issue is what led to formation of the "definition specs" group. I doubt that anything that comes up under the broader scope could conflict with the minimal assumptions stated in that proposal. In particular, a nomenclature style like (SETF FN) must be acceptable, and #'(SETF FN) will designate the function so named. I certainly remember the overwhelming approval for this direction of extension, but I think the reason it didn't just end with this single proposal is that every place that accepts function names is involved, not just SETF methods. -- JonL -- ∂12-Feb-88 0813 CL-Cleanup-mailer Package Odor Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 08:13:07 PST Received: from NRL-AIC.ARPA by labrea.Stanford.EDU with TCP; Fri, 12 Feb 88 08:12:32 PST Return-Path: <hoey@nrl-aic.arpa> Received: Fri, 12 Feb 88 11:11:02 EST by nrl-aic.arpa id AA02816 Date: 12 Feb 1988 10:22:34 EST (Fri) From: Dan Hoey <hoey@nrl-aic.arpa> Subject: Package Odor Message-Id: <571677767/hoey@nrl-aic.arpa> To: mike%acorn@live-oak.lcs.mit.edu Cc: RWK@ai.ai.mit.edu, hilfingr%tully.Berkeley.EDU@ucbvax.berkeley.edu, common-lisp@sail.stanford.edu, CL.BOYER@r20.utexas.edu, edsel!jonl@labrea.stanford.edu, labrea!CL-Cleanup%SAIL@labrea.stanford.edu, labrea!KMP%STONY-BROOK.SCRC.Symbolics.COM@labrea.stanford.edu Date: Thu, 11 Feb 88 19:26 est From: mike%acorn@oak.lcs.mit.edu ...My experience is that no one wants to qualify any names so what they do is carefully use every package that they've ever seen, not realizing that (let ((string "abcd")) ....) in their code is creating a spec-bind because they are using a package where string is a special.... Note that this is not *quite* the problem, since STRING is a symbol in the LISP package, and anyone who is using random packages must surely use LISP. In that case it is the error of the other package in proclaiming a symbol of the LISP package SPECIAL (or CONSTANT), and you couldn't defend against the error by not using that package. That this is an error should be made explicit--I once broke the compiler by proclaiming LISP:FUNCTION constant, and the compiler wanted to bind it in a macroexpansion. Making it SPECIAL might have screwed things up beyond hope of diagnosis. The problem of using every package is still there, though. You should know the names of all the symbols you import (including all the symbols exported from packages you use), not only so you don't get surprised about them being special, but so you don't accidentally make them special when they shouldn't be. What the package system buys you is letting this not be all the symbols in the world. Dan ∂12-Feb-88 2337 CL-Cleanup-mailer Issue: SETF-SUB-METHODS Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Feb 88 23:37:24 PST Received: by labrea.Stanford.EDU; Fri, 12 Feb 88 23:37:47 PST Received: from bhopal.lucid.com by edsel id AA19656g; Fri, 12 Feb 88 23:26:38 PST Received: by bhopal id AA13404g; Fri, 12 Feb 88 23:31:35 PST Date: Fri, 12 Feb 88 23:31:35 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8802130731.AA13404@bhopal.lucid.com> To: labrea!CL-Cleanup%SAIL@labrea.Stanford.EDU Subject: Issue: SETF-SUB-METHODS Ken Olum and I [JonL White] have given some thought to the problem that spurred the issue SETF-METHOD-FOR-SYMBOLS, and feel that the issue as stated attacks a small manifestation of the problem rather than the root underlying case. Worse yet, the TEMPORARY-VARIABLE proposal requires a change which creates a bug in another area of SETF usage [see below]. We propose that the problem lies in understanding of how SETF works when the SETF expansion for a form like (<access-fun> <place> ...) involves the sub-recursive SETF expansion of <place>, or in other words, when the accessing technique isn't fully specified just by looking at the get-setf-method of <access-fun>. The class of such <access-fun>'s is enumerated in CLtL, at the top of p96, except that GETF is missing from that list [we propose that it be added there in the next manual]. This message will propose a clarification the issues of left-to-right evaluation in such cases, and will also detail the actions that should be taken by SETF methods on each of these place-types. ! ISSUE: SETF-SUB-METHODS References: CLtL pp. 95-96, 99, 105-106, 166 Issue: PUSH-EVALUATION-ORDER Issue: SETF-METHOD-FOR-SYMBOLS Category: Clarification Edit history: Version 1 JonL & KDO 12-Feb-88 Problem description: Tim Daly of IBM noticed that several implementations do not observe left-to-right order of evaluation in the following form: (setq r '(a 1 b 2 c 3)) (setq s r) (setf (getf r 'b) (progn (setq r nil) 6)) In these implementations, the side-effect of the setq happens before the evaluation of the "subforms" necessary to fetch the list being updated. A typical result is that 'r' = (B 6), 's' = (A 1 B 2 C 3) after the operation. Surely, it should at least be the case that 's' = (A 1 B 6 C 3), since the expectation is that the B property in this list is being (destructively) changed. Similar problems exist with LDB and CHAR-BIT. It is not necessary to clarify that left-to-right order of evaluation semantics should be observed; CLtL p99 is quite explicit about that. Rather, a distinction needs to be made between the computations involved in "evaluation" of the subforms, and other computations that are implicit in the notion of "doing an access" or "doing a store". Proposal: SETF-SUB-METHODS:DELAYED-ACCESS-STORES Elaborate the documentation of SETF, especially in the case of access forms whose sub-forms are permitted to be generalized variable references [and thus which need to call GET-SETF-METHOD during setf macro expansion]. We remember that GET-SETF-METHOD returns the following: Some temporary variables A list of value-producing forms A list of store-variables (normally one). A storing form. An accessing form. Then we want to say that: Code generated using GET-SETF-METHOD does 2 or 3 of the following things: It evaluates the value-producting forms, and binds the temporary variables to them. This will be called "binding the temporaries." It evaluates the accessing form to get the old value of the place. This will be called "doing the access." It binds the store-variable to a new value and calls the storing form to install it in the place. This will be called "doing the store." The forms listed at the top of CLtL p96 permit recursive <place> specifiers; for each one, we will describe how the sub-recursive information from GET-SETF-METHOD is used. LDB: In a form such as (SETF (LDB <byte-spec> <place-form>) <value-form>) the place referred to by the <place-form> must always be both accessed and updated. Even if the <place-form> refers to a bignum, the bignum itself will not be modified but rather a new bignum stored in the <place-form>. Thus this SETF should generate code to do the following: 1. Evaluate <byte-spec> 2. Bind the temporaries for <place-form> 3. Evaluate <value-form> 4. Do the access to <place-form> 5. Do the store into <place-form> with the given bit-field replaced with the value from step 3. If the evaluation of <value-form> in step 3 sets a different bit-field in the given place then since the access is done later at step 4 this change will be preserved. See ROTATEF example in discussion below. Nevertheless the evaluations required for binding the temporaries are done in step 2, and thus the expected left-to-right evaluation order is seen. GETF: The case of GETF is complicated by the fact that two different "place" locators are involved: one to use if the specified indicator is present in the property list, and another if not. For example, in (SETF (GETF (AREF ... I) 'B) 6), if the I'th slot of the array is NIL, then that slot must be changed, but if it contains a list with the property B then only the cons cell with that property value needs to be changed. This decision cannot be made at macro-expansion time. It depends entirely on the contents of the list in question, and so must be delayed until the last possible moment. In the first place, GETF should be listed among the other place forms that admit place forms as one of their arguments. See CLtL at the bottom of p95 and the top of p96. More specifically, the expansion of (SETF (GETF <place-form> <ind-form>) <value-form>) should generate code to do the following: 1. Bind the temporaries for <place-form> 2. Do the access to <place-form> [Binding the temporaries and then doing the access is equivalent to evaluating the <place-form>.] 3. Evaluate <ind-form> [and save the result in a temporary variable]. 4. Check whether the value from 2 has the indicator from 3. If so: 5A. Find cons-cell after indicator from above 6A. Evaluate <value-form> 7A. RPLACA cons-cell from 5A with value from 6A [In this case, we do not do a store into <place-form>. When the indicator is already present then the location specifed by <place-form> doesn't need a new value.] If not: 5B. Evaluate <value-form> 6B. Do the access to <place-form>, using the temporaries saved from step 1 [this is not another evaluation -- but it may involve some non trivial computation, depending on how complex the access method really is.]. 7B. Do the store into <place-form>, again using the temporaries saved from step 1, setting it to a list with indicator from 3, new value from 5B, and old list from 6B. Test Cases: (setq integer #x69) (rotatef (ldb (byte 4 4) integer) (ldb (byte 4 0) integer)) Rationale: As a principle, (setf (foo-a x) (setf (foo-b x) ...)) should always set both of the "slots" of X, even if these slots are implemented as bit-fields, getf-properties, and so on. However, (setf (foo-a x) (setf (foo-a x) ...)) is an error [that is, what happens is undefined.] Current Practice: -- Xerox and Franz already operate on GETF according to this perscription. -- Symbolics and Lucid differ by always doing a setf on the variable rather than updating the appropriate cons cell of the property list; additionally, they fail to connect the new value put into 'r' to the original property list which was 'r's value initially. -- HP and VAX Common Lisps update the cons cell, but then set the variable 'r' again, nullifying the effect of the "(setq r nil)" in the <value-form> computation. Adoption cost: Several implementations would require several hours of programmer and documentation time. Cost of non-adoption: Users will think SETF is unnatural in that left-to-right order of evaluation isn't always observed. Benefits: Uniform semantics and portability in the face of recursive "place specifiers" for SETF. Setf of (LDB ... <place>) and of (GETF <place> ...) will behave uniformly no matter the nature of the <place>. Anyone who has copied examples from p105 and p106 will continue to be able to use them. Conversion Cost: This is a clarification of a point not sufficiently elaborated in CLtL. Symbolics and Lucid are already modifying their interpretation of this code -- in some way or other. Esthetics: See "Cost of non-adoption" Discussion: In the case that spurred this discussion, (setq r '(a 1 b 2 c 3)) (setq s r) (setf (getf r 'b) (progn (setq r nil) 6)) the consequent update is a RPLACA to some list cell -- not a setf of the variable 'r' -- and thus 'r' should be NIL and 's' should now be (A 1 B 6 C 3). There is an interesting parallel between this case for GETF and the very common mistake made by Lisp programmers with respect to the function DELETE. How often the complaint is filed that DELETE didn't do anything when it should have; but in fact the filer simply forgot that delete can either update some CAR slot of the list originally given it, or return some tail of the list originally give it, but not both! E.g. (setq l '(a a b c d)) ==> (a a b c d) (delete 'a l) ==> (b c d) l ==> (a a b c d) The unwary user thinks that because 'l' is still eq to the original value that "DELETE didn't do anything". The variability of action at runtime here parallels the variable choice of location specifier for (SETF (GETF ...) ...) A previous proposal to fix this problem was misdirected. It was phrased as follows: Proposal: SETF-METHOD-FOR-SYMBOLS:TEMPORARY-VARIABLE Change the result of (get-setf-method 'foo) from NIL NIL (#:G1174) (SETQ FOO #:G1174) FOO to (#:G1175) (FOO) (#:G1174) (SETQ FOO #:G1174) #:G1175 The problem with this is that it breaks a relatively simple client of setf technology: (setq integer #x69) (rotatef (ldb (byte 4 4) integer) (ldb (byte 4 0) integer)) no longer does the "right thing". Using the prescription for setf methods on symbols from CLtL p105, the result of this 'rotatef' is that integer = #x96; using that given by the TEMPORARY-VARIABLE proposal leads to either #x99 [or #x66 depending on which order the implementation chooses to do the actual stores in]. In addition, if 'integer' is replaced by '(car x)' here, then the behavior is different under the TEMPORARY-VARIABLE proposal because that only applies to symbols. Implicitly, two "places" are being specified here to be updated; but in fact the two places are not independent -- they both involve setq'ing the variable 'integer'. Furthermore, each store operation implicitly requires fetching the value from that place in order to combine it with DPB. It is necessary to delay the accesses until the last moment before combining with DPB in order to see the side-effects of the earlier store operations. ∂13-Feb-88 1333 CL-Cleanup-mailer Issue: FORMAT-COLON-UPARROW-SCOPE (version 3) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 13:33:42 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 13:33:24 PST Date: 13 Feb 88 13:32 PST From: Masinter.pa@Xerox.COM to: cl-cleanup@Sail.stanford.edu Subject: Issue: FORMAT-COLON-UPARROW-SCOPE (version 3) Message-ID: <880213-133324-10349@Xerox> This apparently did not get mailed before. This issue is too simple to present two proposals. I've tried to represent TEST-FOR-REMAINING-SUBLISTS as the single proposal and eliminate TEST-FOR-REMAINING-ARGUMENTS. ! Issue: FORMAT-COLON-UPARROW-SCOPE References: CLtL p. 406 and also p. 403 Category: CLARIFICATION Edit history: version 1: Guy Steele, 30 November 1987 version 2: Guy Steele, 18 January 1988 version 3: Masinter, 5 February 1988 Problem description: Implementations currently differ on the question of what is tested by the FORMAT command "~:↑". Some implementations test to see whether any arguments remain in the sublist for the current iteration step; others test to see whether any sublists remain. The text on page 406 is not clear on this point. Proposal (FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS): ~:↑ may be used only if the command it would terminate is ~:{ or ~:@{. The entire iteration process is terminated if and only if the sublist that is supplying the arguments for the current iteration step is the last sublist (in the case of ~:{) or the last FORMAT argument (~:@{). Note that ~:↑ is *not* equivalent to ~:#↑; the latter terminates the entire iteration if and only if no arguments remain for the current iteration step. Test Cases/Examples: (format nil "~:{~@?~:↑...~}" '(("a") ("b"))) Under this proposal, this yields "a...b", rather than "a". Rationale: This proposal is desirable because otherwise there is no way to test whether any sublists remain. The text on page 406 may be construed to hint at this proposal indirectly. To quote Nick Gall: If one thinks about the intent of the parenthetical (because in the standard case it tests for remaining arguments of the current step only) one should agree that "a...b" will be returned. In referring to ~↑ as the "standard case", which tests the arguments remaining in the current argument sublist, this parenthetical implies that there is an other case', which tests something else.' The only other case' discussed is ~:↑, which therefore must test something else.' I claim that the parentheical makes no sense if we interpret ~:↑ as testing the same condition as ~↑. If they both test the same condition, why have the parenthetical explanation? If ~:↑ doesn't test the same condition as ~↑, then what does it test? I claim that the only test that makes sense is for ~:↑ to test the only thing that affects the "entire iteration process:" the number of sublists. When there are no more sublists, "the entire iteration process" is terminated. Current practice: Some implementations already have the proposed behavior, include Symbolics Common Lisp and TI Lisp. Many other implementations currently have a different interpretation: the test case returns "a", since ~:↑ in those implementations test for the remaining arguments rather than remaining sublists. These currently include Kyoto Common Lisp, Allegro Common Lisp, GCLISP, Xerox Common Lisp, Spice Lisp, and VAXLISP. Cost to Implementors: Many implementations will have to make a small change, probably a one-liner. Cost to Users: It is unlikely that much user code depends on the behavior of testing for remaining arguments, but it is possible. The author of this writeup (Steele) judges it somewhat more likely that user code might depend on the behavior of testing for remaining sublists.. Cost of non-adoption: Users would have to be warned not to use ~:↑ in code that is meant to be portable. Benefits: Elimination of yet one more ambiguity. The proposed semantics allows greater semantic power (there are more things one can test). Esthetics: Absolutely none. We're talking about FORMAT here.'' -- Guy L. Steele Jr. Discussion: Guy Steele very strongly prefers the interpretation FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS. David Moon, Kent Pitman, Pavel Curtis, Dan Pierson, Rob Poor, Scott Fahlman and Nick Gall favor FORMAT-COLON-UPARROW-SCOPE:TEST-FOR-REMAINING-SUBLISTS. Kevin Layer and Rich Robbins have spoken in favor f an alternative proposal, to test for the remaining arguments. Historical note: Steele first implemented this "feature", in Zetalisp, and so the code in Symbolics Common Lisp is likely a direct descendant of the original code. This might cause some to give weight to Steele's opinion. There are two arguments against such credence. First, there is no reason why the original code should be regarded as part of the specification of Common Lisp any more than any other implementation; plainly, Steele botched the specification when he wrote the book. Second, a professor of literature (I believe) once told Isaac Asimov concerning a short story of his (I quote from memory): "Tell me, Dr. Asimov, just because you wrote the story, what makes you think you know what it means?" ∂13-Feb-88 1410 CL-Cleanup-mailer Issue FUNCTION-TYPE-KEY-NAME, Version 3 Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 14:10:06 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 14:10:49 PST Date: 13 Feb 88 14:10 PST From: Masinter.pa@Xerox.COM Subject: Issue FUNCTION-TYPE-KEY-NAME, Version 3 To: cl-cleanup@sail.stanford.edu, sandra%orion@cs.utah.edu Message-ID: <880213-141049-10374@Xerox> ! Issue: FUNCTION-TYPE-KEY-NAME References: CLtL p.47-48, 61 Category: CLARIFICATION, CHANGE Edit history: Version 1, 23-Nov-1987 Sandra Loosemore Version 2, 15-Jan-1988 Sandra Loosemore (from comments by Kent Pitman) Version 3, 13-Feb-88 Masinter Related issues: FUNCTION-TYPE-REST-LIST-ELEMENT, KEYWORD-ARGUMENT-NAME-PACKAGE FUNCTION-ARGUMENT-TYPE-SEMANTICS Problem description: The FUNCTION type specifier list is provided to allow declaration of function argument types and return value types. This type specifier uses a syntax similar to the usual lambda list syntax to specify which types go with which lambda list variables. However, there is a problem with &KEY lambda variables because CLtL does not specify how the types specified in the FUNCTION declaration are matched up to either the actual arguments passed to the function, or the lambda variables in the function definition (since the ordering of keyword arguments is arbitrary). Proposal (FUNCTION-TYPE-KEY-NAME:SPECIFY-KEYWORD): (1) Specify that the &KEY parameters in a FUNCTION type specifier lambda list should be supplied as lists of the form (<keyword> <type>). The <keyword> must be a valid keyword-name symbol as must be supplied in the actual arguments of a call. (This is usually a symbol in the keyword package, but, as per KEYWORD-ARGUMENT-NAME-PACKAGE, not necessarily so.) (2) Allow &ALLOW-OTHER-KEYS to appear in a FUNCTION type specifier lambda list. The interpretation of such declarations is that, when &KEY is given in a FUNCTION type specifier lambda list, it is safe to assume that the &KEYs given are exhaustive unless &ALLOW-OTHER-KEYS is present. &ALLOW-OTHER-KEYS is an indication that other keyword arguments may actually be supplied and, if supplied, may be used. Test Case: The type of the function MAKE-LIST could be declared as: (FUNCTION MAKE-LIST ((INTEGER 0) &KEY (:INITIAL-ELEMENT T)) LIST) Rationale: (1) This specifies a direct correspondence between the argument type and its matching keyword. All of the information is in one place, and the user does not have to remember (or even know) the order in which &KEY arguments appear in the actual function definition. (2) This is probably an oversight in the original specification. Current practice: Many Common Lisp implementations currently ignore FUNCTION type declarations. The situation regarding type specifications for keyword arguments is so ambiguous that few users attempt to use them. Cost to Implementors: Implementations that ignore the FUNCTION type specifier or keyword arguments in a FUNCTION type specifier may continue to do so. This proposal should not involve massive amounts of code to be rewritten. Conversion Cost: Because the current situation is so ambiguous, FUNCTION type specifiers and particularly the specification of keyword argument types are not widely used. However, since this is an incompatible change, it would be nice if implementations check for, and warn about, old-style usage. Cost of non-adoption: If nothing is done, the FUNCTION type specifier will continue to be of limited use for its intended purpose. Benefits: Adopting the proposal will clear up an area of confusion in the language design. Esthetics: The syntax is fairly obvious and is analogous to the (<keyword> <variable>) lambda list syntax. Discussion: The exact semantics of function declarations and the types of arguments is still under discussion, as are several other issues dealing with declarations. However, this issue seemed separable. ∂13-Feb-88 1428 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 14:28:00 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 14:28:43 PST Date: 13 Feb 88 14:28 PST From: Masinter.pa@Xerox.COM Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3) To: cl-cleanup@sail.stanford.edu cc: Masinter.pa@Xerox.COM Message-ID: <880213-142843-10387@Xerox> ! Issue: FUNCTION-TYPE-REST-LIST-ELEMENT References: CLtL p. 27, 47-48, 61 "Artifical Intelligence Programming", Charniak et. al. X3J13/86-003 (A:>GLS>clarifications.text.4) Category: CLARIFICATION, ADDITION Edit history: Version 1, 23-Nov-1987 Sandra Loosemore Version 2, 15-Jan-1988 Sandra Loosemore (incorporate comments from Scott Fahlman & others) Version 3, 13-Feb-88 Masinter Related issues: FUNCTION-TYPE-KEY-NAME, FUNCTION-ARGUMENT-TYPE-SEMANTICS Problem description: The FUNCTION type specifier list is provided to allow declaration of function argument types and return value types. This type specifier uses a syntax similar to the usual lambda list syntax to specify which types go with which lambda list variables. However, this is actually of limited usefulness in the context of a declaration, where one normally wants type information about the actual arguments which can be passed to the function rather than the lambda variables to which they are bound. There is a particular problem with &REST lambda variables, which are always bound to a value of type LIST. For the sake of consistency, it would seem that the corresponding type given in the FUNCTION declaration must also be LIST, but since this provides no information about the actual arguments, some users/implementors have instead adopted the convention of supplying the type of the actual arguments which are gathered into the list. CLtL is vague on the issue, mentioning only that &REST may appear in the type specifier without touching upon its interpretation. Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE): Clarify that, in the FUNCTION type specifier, the type specifier provided with &REST is the type of each actual argument, not the type of the corresponding lambda variable. Example: The type of the function + would be specified as: (FUNCTION (&REST NUMBER) NUMBER) Rationale: This is more useful than specifying that the type of a &REST parameter must be LIST, since it provides information about the actual arguments. Current practice: There does not appear to be any concensus on this issue. Most Common Lisp implementations currently ignore FUNCTION type declarations. The only examples found so far are in a text book on Common Lisp, which follows the proposed syntax. Cost to Implementors: Implementations that ignore the FUNCTION type specifier may continue to do so. Probably only a small amount of code would have to be written/changed in implementations that currently think that the &REST argument should be LIST. Cost to Users: Users who have been using the convention that the &REST type parameter must be LIST will have to change their code. However, because this issue is so unclear, the FUNCTION type specifier is probably not used very much. Cost of non-adoption: If nothing is done, the FUNCTION type specifier will continue to be of limited use for its intended purpose. Benefits: Adopting the proposal will clear up an area of confusion in the language design. Esthetics: Debatable. One the one hand, since the argument type syntax used by the FUNCTION type specifier mirrors normal lambda-list syntax, it would be cleaner and less confusing to provide the type of the lambda variable rather than the type of the actual arguments. However, considering the types specified in the FUNCTION specifier to be the types of the actual arguments rather than the types of the parameters as seen on the receiving end makes the proposed semantics more palatable. Discussion: This issue provoked considerable debate in the cleanup committee. There was some support for an alternative proposal to require that the &REST argument declaration, if any, always be LIST or a subtype of LIST, and to extend the LIST type to allow declarations of the form, e.g., (LIST NUMBER). Those who favor USE-ACTUAL-ARGUMENT-TYPE (including David Moon and Larry Masinter) argue that the simplicity of the declarations and the ugliness of the alternative, as well as the weight of current practie, argue for it. Kent Pitman has argued against this proposal on the following grounds: * It is bothersome that the same argument declarations which are used internally in the function would not be be usable externally. * It is unfair to provide only this special-purpose way of declaring a sequence type when in fact there are numerous other places in the language where it might be useful to declare a sequence type. If we did go with USE-ACTUAL-ARGUMENT-TYPE, it should be stated explicitly (if it is not already in CLtL somewhere) that the following is illegal: (DEFUN FOO (&REST X) X) (APPLY #'FOO T) since there will be no way to type-declare this. Even though this is an obscure case (that doesn't even work in some implementations), it's the sort of thing that makes me queasy about USE-ACTUAL-ARGUMENT-TYPE. ∂13-Feb-88 1615 CL-Cleanup-mailer Issue: FUNCTION-TYPE (version 9) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 16:15:04 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 16:15:39 PST Date: 13 Feb 88 16:14 PST From: Masinter.pa@Xerox.COM Subject: Issue: FUNCTION-TYPE (version 9) TO: CL-CLEANUP@SAIL.STANFORD.EDU LINE-FOLD: NO cc: Masinter.pa@Xerox.COM Message-ID: <880213-161539-10473@Xerox> I've left the CONSERVATIVE proposal pretty much intact, and attempted to add back in the STRICT-REDEFINITION proposal as an alternative proposal with a shared cost/benefit analysis. We really owe X3J13 a version they can vote on, and I think that this is one issue that is big enough and thorny enough that we can ask for votes on more than one alternative. ! Issue: FUNCTION-TYPE References: functions (p32), types (p33), FUNCTIONP (p76), SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52) Category: COMPATIBLE CHANGE Edit History: 26-Feb-87, Version 1 by Gabriel 15-Mar-87, Version 2 by Cleanup Committee 10-May-87, Version 3 by Fahlman 29-May-87, Version 4 by Masinter (incorporate comments) 15-Jun-87, Version 5 by Fahlman (include two options) 23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION) 09-Nov-87, Version 7 by Masinter (minor cleanup) 14-Nov-87, Version 8 by Pitman (major restructuring) 13-Feb-88, Version 9 by Masinter, (add back 2nd option) Problem Description: The definition of the term function'' in CLtL includes all symbols and many lists in addition to true' functions. Also, page 47 of CLtL states that the FUNCTION type specifier can only be used for declaration and not for discrimination. Some of the original Common Lisp designers maintain that this restriction on the use of the FUNCTION specifier was meant to apply only to long-form FUNCTION specifiers, but since this intent was not explicitly stated, the status of FUNCTION as a type is blurred. A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably be relied upon to be equivalent to (TYPEP x 'FUNCTION). Proposal FUNCTION-TYPE:CONSERVATIVE 1. Introduce a new type PROCEDURE that can be used both for declaration and discrimination. 1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and PROCEDURE are pairwise disjoint. In particular, a list may not be used to implement any PROCEDURE subtype. 1b. Define that the type COMPILED-FUNCTION is a subtype of PROCEDURE. Implementations are free to define other subtypes of PROCEDURE. 1c. Introduce a new function, PROCEDUREP, such that (PROCEDUREP x) == (TYPEP x 'PROCEDURE). 2. Define that a function'' may be a procedure, a list whose car is the symbol LAMBDA, or any symbol (whether fbound or not). 2a. Clarify that the FUNCTION type behaves as if it had been defined by: (DEFUN LAMBDA-P (X) (AND (NOT (ATOM X)) (EQ (CAR X) 'LAMBDA))) (DEFTYPE FUNCTION () (OR SYMBOL (SATISFIES LAMBDA-P) PROCEDURE)) 2b. Clarify that (FUNCTIONP x) == (TYPEP x 'FUNCTION). This change is compatible. 2c. Clarify that the list form of the FUNCTION type specifier may still only be used for declaration. 2d. Clarify that the symbol form of the FUNCTION type specifier may be used for type discrimination. 2e. Clarify that FUNCALL and APPLY continue to accept functions as arguments. However, some implementations may produce better code for expressions such as (FUNCALL (THE PROCEDURE ...) ...) or (APPLY (THE PROCEDURE ...) ...). 3. Clarify that the result of a FUNCTION special form must be a procedure. 3a. This implies that some (FUNCTION name) may be implicitly interpreted as (THE PROCEDURE (FUNCTION name)). As such, the potential optimizations mentioned in 2e are also possible for (FUNCALL (FUNCTION ...) ...) and (APPLY (FUNCTION ...) ...). 4. Clarify that it is an error to use the special form FUNCTION on a symbol that does not denote a function in the lexical environment in which the special form appears. Specifically, it is an error to use the FUNCTION special form on a symbol that denotes a macro or special form. 4a. Some implementations may choose not to signal this error for performance reasons, but implementations are forbidden from defining the failure to signal an error as a useful' behavior. 5. Clarifythat it is permissible for FBOUNDP to return true for a macro or special form, and that it is permissible to call SYMBOL-FUNCTION on any symbol for which FBOUNDP returns true. 5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true but the symbol denotes a macro or special form is not well-defined, but SYMBOL-FUNCTION will not signal an error. 5b. Assuming that symbol is fbound, (PROCEDUREP (SYMBOL-FUNCTION symbol)) implies (AND (NOT (MACRO-FUNCTION symbol)) (NOT (SPECIAL-FORM-P symbol))). 5c. The effect of (SETF (SYMBOL-FUNCTION symbol) non-procedure) is not defined. Implementations are permitted to signal an error, but they are also permitted to define useful (non-portable) interpretations. 5d. The motivation for this distinction between FUNCTION and SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day use within programs while SYMBOL-FUNCTION is a data structure accessor used primarily for meta-level applications and not recommended for general use. It is provided primarily to complete the set of accessors on symbols. Implementations are permitted, but not required, to store information about a global macro-function or special form in the function cell. This definition of SYMBOL-FUNCTION is intended to leave enough freedom for such implementations to conveniently implement FUNCTION, SPECIAL-FORM-P, and MACRO-FUNCTION using SYMBOL-FUNCTION as the underlying subprimitive. 6. COERCE is extended to allow objects to be coerced to type procedure. 6a. (COERCE symbol 'PROCEDURE) extracts the symbol-function of the given symbol, signalling an error if SYMBOL is not fbound or if the contents of the symbol-function cell is not a procedure. 6b. (COERCE lambda-expression 'PROCEDURE) is equivalent to (EVAL (FUNCTION ,lambda-expression)). 7. Clarify *MACROEXPAND-HOOK* is permitted to contain any kind of function. The function is coerced to a procedure before being called as the expansion interface hook by MACROEXPAND-1. ! Proposal FUNCTION-TYPE:STRICT-REDEFINITION STRICT-REDEFINITION is similar to CONSERVATIVE, except that it redefines the type FUNCTION instead of adding a new type PROCEDURE, and it restricts coercion by functions that take functions as arguments. The numbering of CONSERVATIVE is preserved for comparison. 1. Redefine the type FUNCTION so that it can be used for discrimination as well as declaration. 1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION are pairwise disjoint. In particular, a list may not be used to implement any PROCEDURE subtype. 1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION. Implementations are free to define other subtypes of FUNCTION. 2. Define that a function'' as used throughout the CLtL is restricted to be exactly those objects of type FUNCTION. 2a. This type no longer includes objects of type SYMBOL or lists with CAR = LAMBDA. 2b. The behavior of FUNCTIONP is defined to be exactly equivalent to #'(LAMBDA (X) (TYPEP X 'FUNCTION)). This is an incompatible change. 2c. Clarify that the list form of the FUNCTION type specifier may still only be used for declaration. 2d. Clarify that the symbol form of the FUNCTION type specifier may be used for type discrimination. 2e. Change FUNCALL and APPLY such that they accept only a function as the functional argument. This restriction is inherited by all functions in Common Lispthat take a functional argument. It is no longer legal to pass a symbol or lambda expression as the functional argument to any of these functions; to do so "is an error". 3. Clarify that the result of a FUNCTION special form must be a function. 3a. This implies that some (FUNCTION name) may be implicitly interpreted as (THE FUNCTION (FUNCTION name)). 4. Clarify that it is an error to use the special form FUNCTION on a symbol that does not denote a function in the lexical environment in which the special form appears. Specifically, it is an error to use the FUNCTION special form on a symbol that denotes a macro or special form. 4a. Some implementations may choose not to signal this error for performance reasons, but implementations are forbidden from defining the failure to signal an error as a useful' behavior. 5. Clarify that it is permissible for FBOUNDP to return true for a macro or special form, and that it is permissible to call SYMBOL-FUNCTION on any symbol for which FBOUNDP returns true. 5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true but the symbol denotes a macro or special form is not well-defined, but SYMBOL-FUNCTION will not signal an error. 5b. Assuming that symbol is fbound, (FUNCTIONP (SYMBOL-FUNCTION symbol)) implies (AND (NOT (MACRO-FUNCTION symbol)) (NOT (SPECIAL-FORM-P symbol))). 5c. The effect of (SETF (SYMBOL-FUNCTION symbol) non-procedure) is not defined. Implementations are permitted to signal an error. 5d. The motivation for this distinction between FUNCTION and SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day use within programs while SYMBOL-FUNCTION is a data structure accessor used primarily for meta-level applications and not recommended for general use. It is provided primarily to complete the set of accessors on symbols. 6. COERCE is extended to allow objects to be coerced to type procedure. 6a. (COERCE symbol 'FUNCTION) extracts the symbol-function of the given symbol, signalling an error if SYMBOL is not fbound or if the contents of the symbol-function cell is not a procedure. 6b. (COERCE lambda-expression 'FUNCTION) is equivalent to (EVAL (FUNCTION ,lambda-expression)). 7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a function before being called as the expansion interface hook by MACROEXPAND-1. ! Rationale: Since the two proposals are similar, they are discussed together. Where motiviation and justification differ, the proposals are referred to by name (STRICT-REDEFINITION, CONSERVATIVE.) The fuzzy definition of function'' has descended from older dialects of Lisp, such as Maclisp. Many places in existing code make assumptions about the current meaning, making any change painful. It is very important both for documentation clarity and for program type discrimination (such as CLOS) to have a clear term which denotes a true function.'' CONSERVATIVE manages a compatible definition with most existing uses of the term function'' while providing a graceful upgrade path to the term procedure'' for use in situations that call for a higher degree of clarity. STRICT-REDEFINITION avoids introducing a new term at the cost of incompatible change. Current Practice: In some implementations, (TYPEP x 'FUNCTION) signals an error. In some implementations, (TYPEP x 'FUNCTION) is the same as (FUNCTIONP x). In some implementations, (TYPEP x 'FUNCTION) is the same as what this new proposal calls (TYPEP x 'PROCEDURE). Implementations vary on what my go into the function cell, depending on how much error checking they want to have to do at function call time, and depending on whether they store other kinds of information (such as special form information) in the function cell. Few current Common Lisp implementations are likely to have exactly the semantics described in either. CONSERVATIVE is more compatible with current practice than STRICT-REDEFINITION, however. Cost to Implementors: Bringing type predicates (FUNCTIONP, etc.) and higher order functions (APPLY, etc.) into compliance should require little effort in most implementations. While STRICT-REDEFINITION makes it an error to pass non-function arguments to APPLY, FUNCALL etc, there is no requirement to check for that error. Compiled functions are true functions in almost all current implementations, but in some implementations interpreted functions and closures stored in the function cell of a symbol are represented as lists. Under this proposal, such lists would have to be changed to be procedures (implemented either as structures or to some special internal data type). The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be modified to deal with functions that are not lists (but from which the list form can be reconstructed if necessary). Cost to Users: The conversion cost associated with CONSERVATIVE is very low because the model of FUNCTIONP which it takes is largely consistent with existing practice. The new features introduced by CONSERVATIVE, particularly the PROCEDURE data type, can be converted to fairly lazily. The conversion cost for the STRICT-REDEFINITION proposal is higher. The changes to FUNCTIONP and the FUNCTION type declaration is relatively easy to deal with. However, the strict redefinition of FUNCALL, APPLY and functional arguments will require the addition of an explicit coercion would have to be added whenever a symbol or lambda expression is used as a functional argument. Many such cases can be identified at compile time, but not all. Some implementations might provide tools to assist in detecting implicit coercion of symbols to functions. For example, an implementation might add run-time test in which the implementation still does the coercion but that issues a warning message whenever the coercion is actually needed. Alternatively, a "smart" code-walker or editor macro might find all of the calls to FUNCALL, APPLY, and the 61 Common Lisp functions that take :TEST or :KEY arguments and, if the argument is not already an explicitly quoted FUNCTION form, wrap a COERCE around the body. For either proposal: Because CLtL's language was somewhat fuzzy about what might go into the function cell of a symbol, some code that explicitly deposited symbols or lists in a symbol's function cell might have to change. Such code was already not portable, however, since some implementations signal an error when this is done. Benefits: For CONSERVATIVE: The term function'' would be given a useful meaning that was relatively compatible with existing usage. A new term procedure'' would be available for descriptional clarity. The new PROCEDURE datatype would be useful for type discrimination in CLOS. For STRICT-REDEFINITION: The term function'' would be given a useful and precise meaning. The FUNCTION datatype would be useful for type discrimination in CLOS. STRICT-REDEFINITION provides useful constraints which will be of aid to systems doing automatic program analysis for the purpose of selective linking.'' Such tools may in turn make it possible to reduce the total size of a delivered application program because only those Common Lisp functions that are actually called need to be included. For either proposal: The type hierarchy would be simplified. Either proposal brings Common Lisp into closer alignment with Scheme and the work of the EuLisp committee. Scheme, for example, also has the concept of a procedure'' which is compatible with this proposal. Aesthetics: Both proposals improve the aesthetics of the language. Discussion: These proposals have been discussed at great length; this section attempts only to summarize the important points. There is general agreement that the definition of the FUNCTION data type must be clarified or revised. The cleanup of the type hierarchy is important to the CLOS group. The description of COMPILE must be changed, since it is no longer meaningful to speak of a symbol with a definition that "is a lambda-expression". We believe this is a subject for a separate proposal, as the behavior of COMPILE needs additional clarification. Many different alternatives have been discussed both in the cleanup committee and X3J13. These two proposals are the distillation of the alternatives. The CONSERVATIVE proposal offers the advantage of backward compatibility, and considerably more flexibility in the language. The STRICT-REDEFINITION proposal offers the advantage of a slightly cleaner resulting language. Some concerns were raised about STRICT-REDEFINITION in a previous discussion about "late binding" of function definitions. Neither proposal disallows late binding of symbols to functions. For example, in the call (MAPCAR #'FROB my-list) the effect of the FUNCTION special form (as generated by the #' read macro) is to obtain the function definition of FROB at the time the #'FROB is evaluated. Neither proposal changes this. Currently, it is allowed to write (MAPCAR 'FROB my-list) while this form would no longer be allowed under the STRICT-REDEFINITION clause. Currently, neither CLtL nor the CONSERVATIVE proposal addresses the question of the time at which FROB's function definition is obtained; if, during the processing of my-list, FROB is redefined, it is not clear whether the processing of subsequent elements would be changed. ∂13-Feb-88 1630 CL-Cleanup-mailer Issue: REDUCE-ARGUMENT-EXTRACTION (version 3) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 16:30:13 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 16:28:49 PST Date: 13 Feb 88 16:28 PST From: Masinter.pa@Xerox.COM Subject: Issue: REDUCE-ARGUMENT-EXTRACTION (version 3) to: cl-cleanup@Sail.stanford.edu cc: Masinter.pa@Xerox.COM Message-ID: <880213-162849-10481@Xerox> very minor edits here ! Issue: REDUCE-ARGUMENT-EXTRACTION References: REDUCE (pp. 251-252), :KEY arguments (p. 246), the astronaut structure (pp. 312-313) Category: ADDITION Edit history: Version 1 by Pierson 5-Dec-87 Version 2 by Pierson 30-Dec-87 Version 3 by Masinter 13-Feb-88 Problem description: REDUCE is the only one of the Common Lisp functions that modify or search lists and sequences which does not accept a :KEY argument. This complicates many uses of REDUCE. Proposal (REDUCE-ARGUMENT-EXTRACTION:KEY): Change the definition of REDUCE to take a :KEY keyword described as follows: If a :KEY argument is supplied, its value must be a function of one argument which will be used to extract the values to reduce. The :KEY function will be applied exactly once to each element of the sequence in the order implied by the reduction order but not to the value of the :INITIAL-VALUE argument, if any. Test Cases/Examples: Using REDUCE to obtain the total of the ages of the possibly empty sequence of astronauts ASTROS, would currently require: (REDUCE #'+ (MAP 'LIST #'PERSON-AGE ASTROS)) If this proposal is adopted, the same result could be obtained without creating a new list by: (REDUCE #'+ ASTROS :KEY #'PERSON-AGE) Rationale: This proposal makes many common situations where REDUCE would be useful much less cumbersome. Current practice: We know of no implementation which currently supports this feature. Cost to Implementors: This will require most implementations to make a trivial modification to REDUCE. Implementations which wish to use this as an opportunity to further optimize compiled calls to REDUCE will have to undertake more work (which would be much more difficult today). Cost to Users: None, this is an upward compatible extension. Cost of non-Adoption: REDUCE will continue to be more difficult to use than other sequence functions on sequences of complex objects. Benefits: REDUCE will become easier to use on sequences of complex objects. It will be easier for compilers to convert some calls to REDUCE into efficient loops. Aesthetics: Slightly damaged in one way. All :KEY arguments are currently defined to be used for predicates, this proposal will implicitly broaden :KEY to support general extraction for any purpose. Slightly improved in another way. Many common situations where REDUCE could be used would be easier to write and easier to later read. Discussion: Several members of the committee feel that the increased functionality outweighs the damage to the definition of :KEY. No one has objected to this change in the recent round of discussions. There is some controversy over whether the "definition" of :KEY arguments on page 246 of CLtL really constitutes a definition or just an "unwritten rule". ∂13-Feb-88 1640 CL-Cleanup-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 16:39:47 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 16:39:54 PST Date: 13 Feb 88 16:39 PST From: Masinter.pa@Xerox.COM Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5) To: cl-cleanup@Sail.stanford.edu cc: Masinter.pa@Xerox.COM Message-ID: <880213-163954-10487@Xerox> This is another version that I apparently neglected to mail out. ! Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS References: Sequences (pp245-261) Issue REMF-DESTRUCTURING-UNSPECIFIED (discussion of NREVERSE, NSUBSTITUTE) Issue AREF-1D Category: ENHANCEMENT Edit history: 05-Feb-87, Version 1 by Touretzky 28-Apr-87, Version 2 by Pitman (variations on the theme) 26-Oct-87, Version 3 by Masinter (clean up for release) 11-Nov-87, Version 4 by Masinter (respond to comments) 5-Feb-88, Version 5 by Masinter Description: Common Lisp provides many useful operations on lists and vectors which don't apply to arrays. For example, one can FILL a vector with 0's, but not an array. One can REPLACE the contents of one vector with another, but one can't do this for arrays. One can verify that EVERY element of a vector has some property, but one can't do this for arrays, and so on. The programmer who wishes to use arrays instead of vectors must give up most of the useful tools CLtL provides for manipulating sequences, even though there is no intuitive reason why operations like FILL, REPLACE, and EVERY shouldn't work on arrays. Common Lisp already provides a facility called "displaced arrays" which can be used to overlay one array on top of a portion of another, even if the two are of different ranks, so that the two share storage or use the awkward convention of creating a displaced array to the operand. However, creating a displaced array merely to perform FILL, REPLACE or EVERY is awkward. Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE): 1) Extend the definitions of sequence functions that either return their argument sequences or return non-sequences so that they also allow arrays of rank other than 1. These functions should treat array arguments as vectors displaced to the array storage (in row-major format). The affected functions are LENGTH, ELT, COUNT, FIND, POSITION, SOME, EVERY, NOTANY, NOTEVERY, REDUCE, SEARCH, MISMATCH, FILL, REPLACE, SORT. For example, suppose A is a 3x2x7 array. (LENGTH A) should return 42, and (ELT A 7) should return the same element as (AREF A 0 1 0). :START and :END keywords would be interpreted relative to the vector, as would the results returned by POSITION and SEARCH. 2) Extend the definitions of sequence functions whose result should be the same shape as but not necessarily EQ to some argument. These functions should deal with array arguments by returning an array of the same shape as the argument, and operate on their argument in row-major order. The affected functions are SUBSTITUTE, NSUBSTITUTE, REVERSE, NREVERSE, SUBSTITUTE-IF, NSUBSTITUTE-IF, SUBSTITUTE-IF-NOT, NSUBSTITUTE-IF-NOT and MAP. 3) Sequence functions that modify the number of elements in the array remain unchanged: it is an error to pass arrays of rank other than 1. (The functions are not extended because the shape would be undefined.) The unaffected functions are SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES. Note that EQUALP does -not- treat arrays as vectors. It is not a sequence function, and it already has a well-defined behavior for arrays. To test whether the arrays A and B, of different shapes, have the same elements, one might write: (AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)). Rationale: This is a useful upward compatible extension with relatively low adoption cost. Cost to implementors: This would involve a lot of changes to functions, but all of the changes are likely to be minor. The presence of displaced arrays in the language already guarantees that the internal storage format needed to back up these proposed changes is already in place. Cost to Users: This change is upward compatible; current user code should run unmodified. Benefits: This proposal adds natural support for multi-dimensional arrays. Currently, users must write nested DO loops every time they want to perform an array operation equivalent to FILL, REPLACE, REDUCE, etc., or else they buld displaced vectors by hand and pass them to the sequence functions when necessary. With this proposal, users of arrays do not have to use home-grown utilities to duplicate functionality already primitively provided to users of arrays. The sequence functions become useful in a variety of new situations. Aesthetics: This proposal extends sequence functions to cover arrays while neatly avoiding the temptation to turn Common Lisp into a half-baked APL. Instead of trying to provide a full set of array handling primitives (which would be needed to take arbitrary k-dimensional slices out of n-dimensional arrays, or to apply an operator across a specific dimension of a multidimensional array), it requires just one rule: treat arrays as displaced vectors where it is well-defined. Current Practice: We know of no current implementation of this proposal. Discussion: This issue was discussed by the cleanup committee at length; what follows is only a brief summary of the discussion. An alternative considered was to only affect those functions which didn't explicitly depend on the shape of the array; that is, to modify COUNT, SOME, EVERY, NOTANY, NOTEVERY, FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP, and expressly forbid arrays as arguments to other sequence functions, including LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH, MISMATCH, REVERSE, NREVERSE, SORT, MAP, as well as SUBSEQ, COPY-SEQ, CONCATENATE, MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES. This would be less controversial, since it includes only those functions which do not deal with positional information. Some hedging over REDUCE and FIND, which often have non-positional uses, were considered. Touretzky supports SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE. He's been building displaced vectors to pass to sequence functions when necessary and really dislikes it. We considered but discarded as unworkable an alternative where POSITION and FIND might deal with "positions" as lists of array subscripts. At one point, this proposal included an extension to COERCE to allow COERCE to translate from array types to sequences, but it was thought better to separate out COERCE. We considered a proposal to only introduce a change to COERCE, and require users who want to operate on arrays explictly perform, e.g., (COUNT item (COERCE x 'SEQUENCE)). This alternative would have the lowest adoption cost but was deemed awkward. Sequence functions like FILL and COUNT are already generalized to arrays in non-Lisp contexts; in English we use the generalized forms all the time, e.g., "count the number of 1's in this matrix." There is some concern that this proposal makes the requirement for row-major ordering of internal storage for arrays even more evident. While such an internal ordering is implied by the ability to create displaced arrays and the AREF-1D proposal, this proposal adds yet another constraint. The general reason for opposing this change is that it adds more mechanism than it is worth. The general reason for liking it is that it adds generality at little cost. ∂13-Feb-88 1713 CL-Cleanup-mailer Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:13:05 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:13:05 PST Date: 13 Feb 88 17:12 PST From: Masinter.pa@Xerox.COM Subject: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3) To: cl-cleanup@Sail.stanford.edu, Hornig@SCRC.Symbolics.COM Line-fold: 80 cc: Masinter.pa@Xerox.COM Message-ID: <880213-171305-10510@Xerox> As this issue is somewhat controversial, it is not for inclusion in the mailing. I tried to at least go back and extract what I thought were David's previous arguments about this proposal and include them in the discussion section. Its been almost a year now since this was first brought up... we should get some closure soon. ! Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT References: UNWIND-PROTECT (p140, p142, p39) Issue IGNORE-ERRORS, Draft error proposal. Category: CLARIFICATION/CHANGE Edit history: Version 1 by Pitman 27-Feb-87 Version 2 by Masinter 24-Oct-87 Version 3 by Masinter 27-Oct-87 Version 4 by Masinter 13-Feb-88 Problem Description: If a non-local return is done while in the cleanup form of an UNWIND-PROTECT, the behavior is not always well-defined. There are three basic cases: Situation 0. Transfer to another point within the cleanup form. (UNWIND-PROTECT 3 (BLOCK NIL (RETURN 4)) (PRINT 'XXX)) There is no ambiguity about how this form is to be interpreted. Effectively: . 3 evaluates to itself, which is queued for return from the UNWIND-PROTECT. . The BLOCK expression is entered, 4 is returned to it and discarded because this is a not-for-value situation. . XXX is printed, XXX is returned by the PRINT and that value is discarded because this is a not-for-value situation. . The 3 which was yielded earlier is retrieved and returned as the value of the UNWIND-PROTECT. Situation 1. Transfer to a point inside the point to which control would have transferred. (CATCH 'FOO (CATCH 'BAR (UNWIND-PROTECT (THROW 'FOO 3) (THROW 'BAR 4) (PRINT 'XXX)))) This is a subject of controversy because: . 3 evaluates to itself and is saved by THROW which begins searching for tag FOO. . 4 evaluates to iself and is saved by THROW which begins searching for tag BAR. . Disagreement exists as to whether it is an error if the BAR tag is not found within the local dynamic scope of the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4) but is found within the scope of the target of the pending THROW (to FOO). Situation 2. Transfer to a point outside the point to which return would already have been. For example: (CATCH 'BAR (CATCH 'FOO (UNWIND-PROTECT (THROW 'FOO 3) (THROW 'BAR 4) (PRINT 'XXX)))) This is a subject of controversy because: . 3 evaluates to itself and is saved by THROW which begins searching for tag FOO. . 4 evaluates to iself and is saved by THROW which begins searching for tag BAR. . Disagreement exists as to whether it is an error if the BAR tag is not found within the local dynamic scope of the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4) but is found outside the scope of the target of the pending THROW (to FOO). What is the appropriate behavior for situation 1 and situation 2 and similar ones? For example, suppose that when WITH-OPEN-FILE tries to close the file upon unwinding, it signals an error, and the condition handler also attempts to throw? The question applies to all non-local transfers, whether performed by THROW, RETURN-FROM, RETURN, GO. Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:CONTINUATION-MODEL): In all cases, a transfer of control within an UNWIND-PROTECT cleanup form to a point outside of the UNWIND-PROTECT causes the original control transfer which initiated the execution of the cleanup forms to be abandonded. During the execution of the cleanup forms of an UNWIND-PROTECT a non-local exit to a point outside of the scope of the UNWIND-PROTECT, but still within the dynamic scope of of the target of the original non-local exit succeeds, and the original pending exit is discarded. For example, in Situation 1, the pending seek for tag FOO is discarded by the second THROW to BAR and the value 4 is transfered to (CATCH 'BAR ...), which returns 4. The (CATCH 'FOO ...) then reurns the 4 because its first argument has returned normally. XXX is not printed. Where an UNWIND-PROTECT cleanup form attempts a non-local exit to a point outside the original non-local exit, control is passed to the outer exit (and the pending original non-local exit is discarded.) For example, in Situation 2, the value 4 is returned from the (CATCH 'BAR ...); XXX is not printed. In no case will UNWIND-PROTECT cleanup forms ever be attempted more than once. Rationale: The primary issues have to do with the safety of the language vs. the uniformity of the model behind non-local transfer of control. Current Practice: Some implementations generate garbage code in situations 1 and 2. Some have differing behavior compiled and interpreted. Most that have implementations seem to implement the proposed semantics for situation 2, but there is some divergence in Situation 1. For example, Spice Lisp and Xerox implement the proposed semantics, while Symbolics Common Lisp signals an error. Adoption Cost: While require some compiler modifications in some implementations, in most cases, that work was in order anyway since compilers may currently be doing nothing particularly useful or defensible with the code in question. Benefits: Having this situation uniformly treated seems critical: Programs that do this accidentally should behave the same on all systems so that bugs can be detected and fixed very early rather than being found later on a system which disagrees. Programs that do this on purpose generally are trying to do something fairly intricate and really need to be able to depend on it being uniformly treated. A portable error/signal system and debugger may be among these. For example, one programmer created his own "top level", to which the system "abort" character would return, by doing: (DEFUN MY-TOPLEVEL () (TAGBODY LOOP (UNWIND-PROTECT (REALLY-MY-TOPLEVEL) (GO LOOP)))) Aesthetics: This proposal is more intuitive to programmers who reason about programs in terms of continuation passing. It falls out of the normal scoping rules as a consequence of the fact that the cleaup code is evaluated in the lexical and dynamic environment in which the UNWIND-PROTECT form appears. The action of THROW is usefully described by saying that it is just like any other function. It happens to discard the current continuation, run some cleanup things (like variable unbindings and UNWIND-PROTECT actions), and transfer control elsewhere in the program. In doing so, the function uses data structure primitives not generally available to other programs, but it is not linguistically different and receives no special exemption with regard to THROWs or other non-local transfers of control done within its execution. A THROW from within an UNWIND-PROTECT cleanup is not different than one in any other code; it discards the ongoing action (stack unwinding) and replaces it by another action (as it happens, another stack unwinding). The previous unwind is never resumed. Conversion Cost: Most user programs don't do this so the cost of converting existing code is probably minimal. (There is some evidence that there are programs that expect this behavior, so there is no conversion cost for those programs.) Discussion: Two alternatives for situation 2 were seriously considered: that it should signal an error, and that it the second non-local exit instead continues the original (more extensive) one; e.g., in Situation 1, the second THROW to BAR would be discarded in lieu of continuing the THROW to FOO. Either of these alternatives would help prevent users from (either intentionally or unintentionally) creating situations where it is impossible to abort a computation with a THROW or other non-local return (e.g., an interrupt implemented via THROW.) For example, given (LOOP (CATCH 'FOO (UNWIND-PROTECT (LOOP) (THROW 'FOO T)))) With this proposal there is no way of exiting such a form. Signalling an error would prevent programmers from getting into this unfortunate situation. However, similar "unstoppable" loops can be created, without resorting to non-nested non-local transfers within UNWIND-PROTECT clauses; for example: (LABELS ((HA () (UNWIND-PROTECT (LOOP) (HA)))) (HA)) While it would be for a programmer to accidentally create such an unstoppable loop, the user has pretty clearly asked to have a loop that cannot be exited and deserves to have that request carried out. One implication is that it is likely that programming environments need to provide some mechanism other than THROW to stop a truly run-away computation. An interesting example which supports this proposal is one where there are two BLOCKs (block foo (block bar (unwind-protect (return-from foo 'foo) (return-from bar 'bar)))) Since there is no reason for FOO and BAR not to be treated interchangably, signalling an error in this situation would be inappropriate. To quote Guy Steele: "We have here a classic case of the irresistible force (QUIT, dammit!) versus the immovable mountain (UNWIND-PROTECT). I find that the suggestion that situation 1 produce an error, but one that IGNORE-ERRORS won't ignore, to be at least one level of epicycle too many. Which mechanism are to we regard as primitive: the error system or the catch/throw system? Or are they disjoint? I prefer, for simplicity, a model in which the error system can be explained. as much as possible, as a complex thing built on top of catch, throw, and unwind-protect." David Moon says: "Of the several alternative proposals for this issue, the only one that seemed appropriate to me has been removed. After re-reading the 12 messages on the topic that I thought were worth saving, I get the feeling that the issues have not really been clarified and that the discussion is largely dealing with strawmen. It seems like the cleanup committee is heading towards making a serious mistake here. Consider the form (loop (catch 'foo (unwind-protect (loop) (throw 'foo t)))) With the proposed semantics, it is impossible to stop this program except by hitting it with two throws in rapid succession, with exactly the right amount of delay between them so that the catch and unwind-protect have not yet been re-established when the second throw strikes. Consider any program-stopping operation that aborts execution by throwing to a catch in the top-level read-eval-print loop (control-G in Maclisp or c-Abort in Genera; most other systems have their own equivalent of this). With the proposed semantics, when this throw executes the unwind-protect cleanup handler, as it must, the throw will be abandoned and execution will resume looping. To me, the inability to stop a program is a much worse problem than providing so-called correct semantics for a contrived program that doesn't correspond to any real application. It was suggested that the error system might depend on the ability to abort throws like this. If that were demonstrated, I would change my tune, but until it's demonstrated I am completely skeptical of the notion that any error system would do this." ∂13-Feb-88 1720 CL-Cleanup-mailer New issues to be mailed to X3J13 Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:20:38 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:21:25 PST Date: 13 Feb 88 17:21 PST From: Masinter.pa@Xerox.COM Subject: New issues to be mailed to X3J13 To: cl-cleanup@Sail.stanford.edu Message-ID: <880213-172125-10516@Xerox> These versions have not been distributed before: - ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87) (Interaction of ADJUST-ARRAY and displaced arrays) - APPEND-DOTTED (Version 5, 14-Jan-88) (What happens to CDR of last CONS? in other than last arg?) - ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87) (Extend ASSOC-IF, etc. to allow :KEY) - COMPILER-WARNING-BREAK (Version 4,23-Nov-87 ) (Does *BREAK-ON-WARNING* affect the compiler?) - DECLARE-MACROS (Version 3, 5-FEB-88) (Disallow macros expanding into declarations.) - DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87) (Documentation string is not evaluated.) - DISASSEMBLE-SIDE-EFFECT (version 3, 21 Jan 88) (DISASSEMBLE doesn't smash the def if not compiled) - DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87) ( DO-SYMBOLS can the same symbol twice?) - DRIBBLE-TECHNIQUE (Version 1) (dribble can't be used programmatically) - FLET-DECLARATION (Version 2, 2 Feb 88) (Allow declarations in FLET, MACROLET) - FORMAT-COLON-UPARROW-SCOPE (Version 3, 5 Feb 88) (what iteration does ~:↑ exit from?) Common-Lisp mailing list discussion Nov 87 - FUNCTION-TYPE-KEY-NAME (Version 3, 5 Feb 88) (allow &KEY (:KEYNAME type)) in FUNCTION decls ) - FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3, 13-Feb-88) (allow &rest <type> in function types to refer to element type) - FUNCTION-TYPE (Version 9, 13-Feb-88) (Change definition of FUNCTIONP, function type ...) - PATHNAME-SYMBOL (Version 5, 5-Feb-88) (Do symbols automaticly coerce to pathnames?) - PUSH-EVALUATION-ORDER (Version 5,25-Nov-87) (What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?) - REDUCE-ARGUMENT-EXTRACTION (version 3, 13-Feb-88) (Add :KEY to REDUCE) - SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87) (Allow (DEFUN (SETF FOO) ..)) - SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5, 5-Feb-88) (let FIND, SUBSTITUTE etc work on multi-dimensional arrays) - SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43) (What does SHADOW do if symbol is already there?) - SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87) ( *FEATURES* are in the keyword package) ∂13-Feb-88 1722 CL-Cleanup-mailer Old issues for confirmation at March X3J13 Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:22:31 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:23:16 PST Date: 13 Feb 88 17:22 PST From: Masinter.pa@Xerox.COM Subject: Old issues for confirmation at March X3J13 To: cl-cleanup@Sail.stanford.edu Message-ID: <880213-172316-10518@Xerox> These issues were already passed at previous meetings. However, I expect that there will be an opportunity for a more formal vote at the March X3J13 meeting. - AREF-1D (Version 7, 14-Nov-87) (Add a new function for accessing arrays with row-major-index) Version 5 conditionally passed X3J13/Jun87 Version 7 passed X3j13/Nov87 - COLON-NUMBER (Version 1, 22-oct-87) (Is :1 a number, a symbol, or undefined?) Version 1 passed X3J13/Nov87 - COMPILER-WARNING-STREAM (Version 6, 5-Jun-87) (Compiler warnings are printed on *ERROR-OUTPUT*) Version 6 passed X3J13/Jun87 - DEFVAR-INIT-TIME (Version 2, 29-May-87) (DEFVAR initializes when evaluated, not later.) Version 2 passed X3J13/Jun87. - DEFVAR-INITIALIZATION (Version 4, Jun-87) ((DEFVAR var) doesn't initialize) Version 4 passed X3J13, Jun87. - FLET-IMPLICIT-BLOCK (Version 6, 5-Jun-87) (do FLETs have implicit named blocks around them?) Version 6 passed X3J13/Jun87. - FORMAT-ATSIGN-COLON (Version 4, 5-jun-87) (@: == :@ in format) Version 4 passed X3J13/Jun87. - FORMAT-COMMA-INTERVAL (Version 2, 15 June 87) (paramerize number of digits between commas) Version 2 passed X3J13/Nov87 - FORMAT-OP-C (Version 5, 11-Jun-87) (What does ~C do?) Version 5 passed X3J13/Jun87. - GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87) (Environment argument for GET-SETF-METHOD) Version 4 conditionally passed X3J13/Jun87. Version 5 passed X3J13/Nov87. - IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87) (Does IMPORT affect home package?) Version 5 passed X3J13/Jun87. - KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87) (&KEY arguments not in keyword package?) Version 6 conditionally passed X3J13/Jun87. Version 8 passed X3J13/Nov87 - PATHNAME-STREAM (Version 6, 14-Nov-87) (PATHNAME only works on file streams) Version 2 conditionally passed X3J13/Jun 87 Version 6 passed X3J13/Nov 87 - PRINC-CHARACTER (Version 3) (PRINC behavior on character objections) Version 3 passed X3J13/Jun87. ∂13-Feb-88 1726 CL-Cleanup-mailer Pending issues Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:26:15 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:26:21 PST Date: 13 Feb 88 17:25 PST From: Masinter.pa@Xerox.COM Subject: Pending issues to: cl-cleanup@Sail.stanford.edu Message-ID: <880213-172621-10520@Xerox> Be prepared to discuss these issues at the cleanup subcommittee meeting Tuesday. Since our time is limited, you should come prepared. I expect discussion to be limited at the subcommittee meeting on Tuesday, but that we'll have some opportunity to find out at least who has opinions on any of these issues. - ADJUST-ARRAY-FILL-POINTER (Interaction of Adjust-ARRAY and fill pointers.) Need volunteer to write up. - CONSTANT-SIDE-EFFECTS (not yet submitted) (It is an error to do destructive operations on constants in code, defconstant.) Discussed 12/86 - 1/87 Will take on if no compiler proposal - DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted) (Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be required to be disjoint from other types?) From CLOS committee, not yet submitted - DECLARATION-SCOPE (Version 2, 2-Feb-88) (What is the scope of SPECIAL declarations? INLINE declarations? where can declarations be placed?) *FOR DISCUSSION MARCH 1988* - DECLARE-TYPE-EXACT (from Kempf as EXACT-CLASS) (Want to be able to declare (EQ (TYPE-OF X) 'Y), i.e., not a subclass.) Useful after CLOS - DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted) What is the lexical environment of DEFTYPE, DEFINE-SETF bodies? Mail 11-12 Oct 87 on common-lisp Interacts with compiler proposal? - DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file) (p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions. Specify that it is an error for two slots in a single DEFSTRUCT to have the same name. If structure A includes structure B, then no additional slot of A may have the same name as any slot of B." Need volunteer to sort out DEFSTRUCT issues post-CLOS. - DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file) (p 305) "The default value in a defstruct slot is not evaluated unless it is needed in the creation of a particular structure instance. If it is never needed, there can be no type-mismatch error, even if the type of the slot is specified, and no warning should be issued." Need volunteer to sort out DEFSTRUCT issues post-CLOS. - EQUAL-STRUCTURE (not yet submitted) (Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.) What do EQUAL EQUALP and friends do on structures? (ALarson@HI-MULTICS.Arpa, edsel!jonl@labrea.stanford.edu, Okuno@SUMEX-AIM.STANFORD.EDU, goldman@vaxa.isi.EDU) - FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT) (P 425) "Generalize FILE-LENGTH to accept any filename, not just an open file-stream. Let it take a keyword argument :ELEMENT-TYPE, defaulting to STRING-CHAR for non-stream arguments and to the element-type of the stream for a stream argument." Need volunteer to write up. - FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no formal proposal) (What does FILE-WRITE-DATE do if no such file?) "there should not be a formal proposal for fixing the file-write-date ambiguity until we are at the point where we can make proposals that discuss signalling named conditions. " Awaiting error proposal. - FORMAT-NEGATIVE-PARAMETERS (mail 19 May 87, no formal proposal) "format parameters are assumed to be non-negative integers except as specifically stated" need volunteer. - FUNCTION-ARGUMENT-TYPE-SEMANTICS (not yet submitted) I'm hoping to get this one out when I get back, but I know its hopeless. Maybe I can mail it out *not* in time for a letter ballot but in time for discussion. - FUNCTION-SPECS (not yet submitted) (add "function specs" for defun, trace etc) Mail from Moon 6-Jun. cf SETF-FUNCTION-VS-MACRO. (SMH!franz@ucbarpa.berkeley.edu, JonL, RWK) - GC-MESSAGES (version 1) (Control over unsolicited GC messages in typescript) merge with other controls for unsolicited messages? - LAST-N (version 1, 4-DEC-87) (Extend LAST to take an optional N) Needs rewrite as per Moon - LISP-SYMBOL-REDEFINITION (no formal proposal yet) Is it legal to redefine symbols in the LISP package? Mail 14-Aug-87 Merge with SPECIAL-FORM-SHADOW Needs volunteer - LOAD-TIME-EVAL (Versin 4, 2 Feb 88) (evaluation when compiled file is loaded) - MACRO-FUNCTION-ENVIRONMENT (Add environment argument to MACRO-FUNCTION?) re-extracted from ENVIRONMENT-ARGUMENTS CLOS committee to submit? - PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87) How to deal with subdirectory structures in pathname functions? make :DIRECTORY a list? Need volunteer to rewrite. - PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted) Mail Aug 87 discussion How to deal with logical devices, :unspecific components, etc in pathname functions RWK@YUKON.SCRC.Symbolics.COM may submit proposal. - PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87) (interaction between PEEK-CHAR, READ-CHAR and streams made by MAKE-ECHO-STREAM) "Fixing echo streams is fine, but I don't think that it is appropriate for the standard to specify how terminal interaction must or even ought to work." - PROCLAIM-LEXICAL (Version 5, 14-Nov-87) (add LEXICAL, GLOBAL, CONSTANT proclaimation) some serious problems - PROMPT-FOR (Version 1) (add new function which prompts) Tabled until re-submitted. - REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 ) (Specification of side-effect behavior in CL) DEFINED, VAGUE and IN-BETWEEN Not ready for release - REMF-MULTIPLE (Version 1, 26 Jan 88) (What does REMF do if it sees more than one INDICATOR?) Withdraw? - REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87) (where does REQUIRE look for files?) Doesn't really solve our problems? - REST-LIST-ALLOCATION (not yet submitted) (APPLY #'LIST X) == (COPY-LIST X)? need volunteer - SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87) (Change recommendation for (get-setf-method symbol)?) - SETF-SUB-METHODS (version 1, 12-Feb-88) - SHARPSIGN-PLUS-MINUS-NUMBER (Is #+68000, #-3600 allowed?) Mild disagreement: it is an error? Tabled - SPECIAL-FORM-SHADOW (no formal proposal) (Is it OK to shadow a special form with FLET, LABELS, MACROLET?) In discussion, no formal proposal submitted. - SHARPSIGN-BACKSLASH-BITS (What does C-META-H-X mean?) Forwarded to character committee. - STANDARD-INPUT-INITIAL-BINDING (Version 1, 19 Jan 88) Move text of Test case/Example to Problem description. Somewhere between completely undefining and current situation is wanted. - STREAM-CLASS-ACCESS (No formal proposal) (Originally FOLLOW-SYNONYM-STREAM 19-DEC-86) Define stream accessors as if synonym-stream two-way-stream etc were CLOS classes? Need volunteer - STRUCTURE-DEFINITION-ACCESS (No formal proposal) (access to slot accessors for DEFSTRUCT etc.) Need volunteer to write up - SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal) (p 246) "Specify that it is an error for the SUBSEQ indices or any :START or :END argument have a negative index or point past the end of the sequence in question. (With respect to whether signalling is required, this error will be treated the same as array out-of-bounds.)" Need volunteer to write up - TAILP-NIL (no formal proposal yet) (Operation of TAILP given NIL) Needs writeup in current format. - TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87) (Allow trace for SETF functions, macros, etc.) Environment extension? ? Ready for release? - UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87) (What happens with non-local exits out of UNWIND-PROTECT cleanup clauses?) Not ready for release - VECTOR-PUSH-EXTEND-DEFAULT (no proposal yet) CLtL says that vectors are extended by a "reasonable" amount. What's that? ∂13-Feb-88 1732 CL-Cleanup-mailer Withdrawn issues Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 17:32:34 PST Received: from Cabernet.ms by ArpaGateway.ms ; 13 FEB 88 17:33:21 PST Date: 13 Feb 88 17:32 PST From: Masinter.pa@Xerox.COM Subject: Withdrawn issues To: cl-cleanup@Sail.stanford.edu Message-ID: <880213-173321-10526@Xerox> I am removing these issues from the list of ones that I will report status on. This does not preclude someone from resubmitting them, but these have been dropped. I hope this doesn't cause anyone too much pain. - ADJUST-ARRAY-NOT-ADJUSTABLE (Version 1, 22-Apr-87) (ADJUST-ARRAY on non-adjustable arrays returns copy) extend COPY-ARRAY instead? Tabled until resubmitted - DEFINITION-FUNCTIONS (no formal proposal) (Extensions for documentation-type for delete-definition for type FUNCTION, VARIABLE, TYPE. ) Rough draft mailed 9-Oct-87. JonL may mail something. - EVAL-DEFEATS-LINKER (Version 1, 12 Jun-87) ("selective linking" means GC non-used symbols; proposal to change #., #, and part of FUNCTION-TYPE Wait on FUNCTION-TYPE, LOAD-TIME-EVAL Propose #., #, changes independently. - EXPORT-COORDINATION (no formal proposal) Add new macros for defining, export at same time Too many interactions with package system - EXPORT-IMPORT EXPORT doesn't do an IMPORT. The book says so, just not in the right place. - IF-BODY (Version 7, 16-Jun-87) (extend IF to implicit progn if more than one ELSE form?) Draft released 16-Jun-87. Discussed at X3J13/Jun 87. Postpone pending resolution of policy on extensions - IGNORE-ERRORS (Version 4, 29-May-87) (Introduce error catcher) Awaiting error proposal - KEYWORD-KEYWORDS (version 1) (Change &REST to :REST) - OPEN-KEYWORDS (Version 1, 17-Jul-87) Discussion 9-Nov-87 Questionable; needs stronger justification. Tabled until resubmitted. - REQUIRED-KEYWORD-ARGUMENTS (&REQUIRED-KEY etc?) - SEQUENCE-EXTREME-SEARCH (not yet submitted) Want MINIMIZE and MAXIMIZE sequence functions ∂13-Feb-88 1808 CL-Cleanup-mailer Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Feb 88 18:08:15 PST Received: from Salvador.ms by ArpaGateway.ms ; 13 FEB 88 18:07:49 PST Date: Sat, 13 Feb 88 18:07:23 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3) In-reply-to: <880213-171305-10510@Xerox> To: cl-cleanup@Sail.stanford.edu, Hornig@SCRC.Symbolics.COM Message-ID: <880213-180749-10547@Xerox> With reference to Moon's objections to the given proposal, namely that he wants a way within his environment to interrupt any loop, no matter how perversely defined, I remain unconvinced that this is really a language issue. Since the language does not specify any relationship between user actions (such as pushing some magic key on the keyboard) and a linguistic effect (such as performing some throw or other non-local transfer), I cannot accept this argument at the linguistic level. If you really want this facility in your environment, then add another operation to the abstract machine of the implementation, a THROW that can't be overridden by any nested'' THROW. Your debugger or whatever can then be implemented in terms of that (when appropriate) and the language definition remains clean. I remain strongly in favor of this proposal; it seems to me to have a wonderfully simple semantics, easily understood and eassily incorporated into the programmer's mental model. Pavel ∂15-Feb-88 0204 CL-Cleanup-mailer Common Lisp cleanup issue status to X3J13 Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 88 02:04:37 PST Received: by labrea.Stanford.EDU; Mon, 15 Feb 88 02:04:58 PST Received: from bhopal.lucid.com by edsel id AA27162g; Mon, 15 Feb 88 01:49:09 PST Received: by bhopal id AA15579g; Mon, 15 Feb 88 01:54:15 PST Date: Mon, 15 Feb 88 01:54:15 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8802150954.AA15579@bhopal.lucid.com> To: labrea!CL-CLEANUP@sail.stanford.edu In-Reply-To: Masinter.pa@Xerox.COM's message of 14 Feb 88 14:54 PST <880214-145515-1510@Xerox> Subject: Common Lisp cleanup issue status to X3J13 Hmmmm, you did drop DEFINITION-FUNCTIONS off our list of "needs volunteers". I still would like to take a crack at it if nobody else does. By the bye, that's a very a misleanding name for what's wanted -- the issue was that of adding some deletor type functions [e.g. DELETE-DEFSTRUCT, DELETE-PACKAGE, DELETE-TYPE etc.] for any function which adds to an implicit global data base. It might be extended more generally a la Interlisp's HASDEF facility but . . . This issue, along with a couple dozen others, are on my "back burner" list of things I'd like to see "cleaned up" [for Lucid's benefit, and for the benefit of the community at large ] but haven't seen discussed so far on the list. I'll bring a hardcopy of this list of semi-proposals to the X3J13 meeting, just in case there isn't enough to do! -- JonL -- ∂15-Feb-88 0928 CL-Cleanup-mailer make-lexical-environment Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 15 Feb 88 09:28:02 PST Received: by labrea.Stanford.EDU; Mon, 15 Feb 88 09:28:18 PST Received: from kent-state.lucid.com by edsel id AA28423g; Mon, 15 Feb 88 09:15:40 PST Received: by kent-state id AA08272g; Mon, 15 Feb 88 09:20:16 PST Date: Mon, 15 Feb 88 09:20:16 PST From: Eric Benson <edsel!eb@labrea.Stanford.EDU> Message-Id: <8802151720.AA08272@kent-state.lucid.com> To: cperdue@sun.com Cc: CommonLoops.PA@xerox.com, cl-cleanup@sail.stanford.edu In-Reply-To: Cris Perdue's message of Sun, 14 Feb 88 16:10:03 PST <8802150010.AA09197@clam.sun.com> Subject: make-lexical-environment Redistributed: CommonLoops.PA Date: Sun, 14 Feb 88 16:10:03 PST From: cperdue@sun.com (Cris Perdue) Is the following code adequate for make-lexical-environment (compared with the code in walk.lisp), and if not, is it inadequate for a good reason related to the definition of Common Lisp, or just because implementation quirks of some Lisps? This code is certainly a bit simpler. (defmacro current-env (&environment e) ',e) (defun make-lexical-environment (form env) (evalhook (,(first form) ,(second form) ; Local macro defns () ; No declarations, though according to the ; PCL comments, they are illegal here. (current-env)) ; body of the macrolet nil nil env)) Thanks for any info on this. -Cris In some Common Lisp implementations, the environments used in EVALHOOK and those used in MACROEXPAND are not compatible. This code would take an existing EVALHOOK environment and return a MACROEXPAND environment. The result could not be passed to EVALHOOK again. Furthermore, some implementations allocate environment objects on the stack, so returning that object from CURRENT-ENV would result in garbage. You are probably correct in your assessment that these are "implementation quirks of some Lisps" and not intrinsic to the Common Lisp standard. The operative phrase in CLtL is "The hook feature is provided as an aid to debugging." EVALHOOK (unlike MACROEXPAND) is part of the programming environment rather than part of the programming language. This issue should be addressed by the cleanup committee. ∂15-Feb-88 0954 CL-Cleanup-mailer Re: make-lexical-environment Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 15 Feb 88 09:54:11 PST Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2) id AA06452; Mon, 15 Feb 88 09:54:37 PST Received: from clam.sun.com by snail.sun.com (4.0/SMI-3.2) id AA15221; Mon, 15 Feb 88 09:46:52 PST Received: by clam.sun.com (3.2/SMI-3.2) id AA10068; Mon, 15 Feb 88 09:55:43 PST Date: Mon, 15 Feb 88 09:55:43 PST From: cperdue@Sun.COM (Cris Perdue) Message-Id: <8802151755.AA10068@clam.sun.com> To: edsel!eb@labrea.Stanford.EDU Subject: Re: make-lexical-environment Cc: CommonLoops.PA@xerox.com, cl-cleanup@sail.stanford.edu Just a further note. CLtL, p. 322, does say that the values passed as the last argument to eval hook functions (or apply hook functions) "are suitable for the functions evalhook, applyhook, and macroexpand". This in turn means that these arguments are suitable as the second argument to a macro expander function. (See the discussion of macroexpand.) I guess I don't see anything that implies that all environment objects acceptable to macro expander functions have to be acceptable to evalhook, though the idea is attractive. -Cris ∂15-Feb-88 1634 CL-Cleanup-mailer Re: Issue: DO-SYMBOLS-DUPLICATES (Version 3) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Feb 88 16:34:29 PST Received: from Cabernet.ms by ArpaGateway.ms ; 15 FEB 88 16:30:38 PST Date: 15 Feb 88 16:29 PST From: Daniels.pa@Xerox.COM Subject: Re: Issue: DO-SYMBOLS-DUPLICATES (Version 3) In-reply-to: Masinter.pa's message of 14 Feb 88 11:37 PST To: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880215-163038-2296@Xerox> The rationale contains a type: DO-PACKAGE for DO-SYMBOLS. -- Andy. -- ∂15-Feb-88 1713 CL-Cleanup-mailer Re: Issue: FORMAT-COMMA-INTERVAL (Version 2) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Feb 88 17:13:42 PST Received: from Cabernet.ms by ArpaGateway.ms ; 15 FEB 88 17:14:22 PST Date: 15 Feb 88 17:14 PST From: Daniels.pa@Xerox.COM Subject: Re: Issue: FORMAT-COMMA-INTERVAL (Version 2) In-reply-to: Masinter.pa's message of 14 Feb 88 12:04 PST To: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880215-171422-2360@Xerox> First of all, there is a typo in one of the test cases. (format nil "~19,0,' ,4:B" 3333) should be (format nil "~19,'0,' ,4:B" 3333), i.e., the pad character should be quoted. This example is somewhat problematic. Just what is the interaction of "insert comma characters" and "pad the output with padchar?" If padding is to be added after the commas are inserted, then the result should be "000001101 0000 0101" instead of "0000 1101 0000 0101". To produce the latter result, either commas must be inserted after padding, or somehow both done simultaneously. In this case does the padding get commas or not? The above example says yes, but this seems like the wrong answer for the "default" case of (format nil "~20:D" 1234567890) => " 1,234,567,890" (not " , 1,234,567,890"!) Does this need a separate clarification, ir is the example simply wrong? -- Andy. -- ∂16-Feb-88 0939 CL-Cleanup-mailer FUNCTION-TYPE:STRICT-REDEFINITION proposal Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Feb 88 09:39:23 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA23751; Tue, 16 Feb 88 10:39:08 MST Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA25191; Tue, 16 Feb 88 10:39:04 MST From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8802161739.AA25191@orion.utah.edu> Date: Tue, 16 Feb 88 10:39:02 MST Subject: FUNCTION-TYPE:STRICT-REDEFINITION proposal To: cl-cleanup@sail.stanford.edu Sections 1a and 6 of this proposal refer to the PROCEDURE type. I assume this is really supposed to be the FUNCTION type? Also, I have a question about 1b, where it states that COMPILED-FUNCTION is a subtype of FUNCTION. Does this imply that it must be a *proper* subtype? For example, in the Lisp I've been working on sporadically for my Atari, the interpreted version of (FUNCTION (LAMBDA ...)) returns a compiled function object (it's a closure which will apply the lambda expression to the function arguments). Likewise I can conceive of implementations which compile everything and don't have an "interpreter" at all. I think this needs to be clarified. -Sandra ------- ∂16-Feb-88 1139 CL-Cleanup-mailer Re: Issue: FORMAT-COMMA-INTERVAL (Version 2) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Feb 88 11:39:05 PST Received: from Salvador.ms by ArpaGateway.ms ; 16 FEB 88 11:33:51 PST Date: Tue, 16 Feb 88 11:33:48 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: FORMAT-COMMA-INTERVAL (Version 2) In-reply-to: <880215-171422-2360@Xerox> To: CL-CLEANUP@Sail.Stanford.EDU Message-ID: <880216-113351-3592@Xerox> Grumble. Yeah, I guess Andy's right and the example is bogus. The only way I can see to get what I wanted is to specify that the padding gets commas inserted into it if and only if the padchar is a digit in the output base. This is highly gross, however, so I guess I won't push it. I guess we should just remove the offending example. Sigh. That example was one of the better uses for the facility, too... Pavel ∂17-Feb-88 1159 CL-Cleanup-mailer two minor comments: DISASSEMBLE-SIDE-EFFECT & DRIBBLE-TECHNIQUE Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 17 Feb 88 11:59:26 PST Date: 17 Feb 88 14:58:00 EDT From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> Subject: two minor comments: DISASSEMBLE-SIDE-EFFECT & DRIBBLE-TECHNIQUE To: "cl-cleanup" <cl-cleanup@sail.stanford.edu> cc: vanroggen Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> Before I send more mail, let me state that I have not been following the cleanup subcommittee mail, so I may be repeating previous arguments. I'm not on the cl-cleanup mailing list, either, btw. The comment about what VAX LISP does for DISASSEMBLE-SIDE-EFFECT is incorrect; we don't modify the function cell of the symbol if the function is interpreted. I think we changed the behavior when the mail about this issue first came up, which was several years ago. DRIBBLE-TECHNIQUE: For a while the way we implemented DRIBBLE made it impossible to have nested DRIBBLEs. We fixed this problem many years ago, but at the time a suggested error message was: No double dribbling allowed. ---Walter ------ ∂19-Feb-88 1434 CL-Cleanup-mailer Re: FUNCTION-TYPE:STRICT-REDEFINITION proposal Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Feb 88 14:34:11 PST Received: from Cabernet.ms by ArpaGateway.ms ; 19 FEB 88 14:17:33 PST Date: 19 Feb 88 14:17 PST From: Masinter.pa@Xerox.COM Subject: Re: FUNCTION-TYPE:STRICT-REDEFINITION proposal In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of Tue, 16 Feb 88 10:39:02 MST To: sandra%orion@cs.utah.edu cc: cl-cleanup@sail.stanford.edu Message-ID: <880219-141733-9723@Xerox> "Sections 1a and 6 of this proposal refer to the PROCEDURE type. I assume this is really supposed to be the FUNCTION type?" Yes, looks like a typo on my part. "Also, I have a question about 1b, where it states that COMPILED-FUNCTION is a subtype of FUNCTION. Does this imply that it must be a *proper* subtype? For example, in the Lisp I've been working on sporadically for my Atari, the interpreted version of (FUNCTION (LAMBDA ...)) returns a compiled function object (it's a closure which will apply the lambda expression to the function arguments). Likewise I can conceive of implementations which compile everything and don't have an "interpreter" at all. I think this needs to be clarified." I intended not to require that it not be a "proper" subtype in the sense that there may be no data items that are FUNCTIONP but not COMPILED-FUNCTIONP. This can be clarified. ∂22-Feb-88 1510 CL-Cleanup-mailer Volunteering Received: from aai2 (aai2.ISTC.sri.com) by SAIL.Stanford.EDU with TCP; 22 Feb 88 15:10:19 PST Received: by aai2 (3.2/5.00) id AA09507 for cl-cleanup@sail.stanford.edu; Mon, 22 Feb 88 15:10:57 PST Date: Mon, 22 Feb 88 15:10:57 PST From: Jeff Rininger <jeffr@spam.istc.sri.com> Message-Id: <8802222310.AA09507@aai2> To: cl-cleanup@sail.stanford.edu Subject: Volunteering Folks: Could you tell me what is involved with the preparation of "issue writeups" for the issues still under consideration by the cleanup committee ? If the task is mainly summarizing past correspondence on a particular issue, and putting the information in the format I have seen distributed in the past, I would like to volunteer to help. I'm not what I would consider a "lisp weenie," although I have used the language for several years, and currently use it for applied AI work here at SRI. If you feel preparing issue writeups is within my capabilities, and my description of the task is basically correct, feel free to send me the cogent correspondence on an "open" issue (your choice) and I'll get started. - Jeff Rininger SRI International ∂23-Feb-88 1115 CL-Cleanup-mailer function-type-rest-list-element Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 23 Feb 88 11:14:22 PST Date: 23 Feb 88 14:07:00 EDT From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> Subject: function-type-rest-list-element To: "cl-cleanup" <cl-cleanup@sail.stanford.edu> cc: vanroggen Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> We oppose the proposal FUNCTION-TYPE-REST-LIST-ELEMENT: USE-ACTUAL-ARGUMENT-LIST. We feel that although specifying the element type in a function type specifier is slightly more convenient, it is outweighed by its inconsistency and lack of expressiveness. If specifying the element type of lists is an important issue, and we think it is, then we should extend the LIST type to be a list type: (LIST [<element-type> [<length>]]) just like for VECTOR. In fact, it would also be wise to extend SEQUENCE in the same way. VAX LISP has always made use of FUNCTION type specifiers, although it has ignored the &REST and &KEY type information. There's no reason why someone might not write a function type specifier with &REST being a supertype of LIST. It just can't conflict with LIST. The statement in the discussion favoring USE-ACTUAL-ARGUMENT-TYPE referring to the weight of current practice'' itself doesn't have any weight when previous statements say that function type specifiers are in limited use and that most implementations ignore them--there is no current practice''. We agree with Kent Pitman's first two comments (at the end of the Discussion section), but don't understand his last one. ---Walter ------ ∂23-Feb-88 1115 CL-Cleanup-mailer compiler-warning-break Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 23 Feb 88 11:15:33 PST Date: 23 Feb 88 14:06:00 EDT From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> Subject: compiler-warning-break To: "cl-cleanup" <cl-cleanup@sail.stanford.edu> cc: vanroggen Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> The proposal COMPILER-WARNING-BREAK:YES leaves a lot of issues unresolved. As it stands we must oppose the proposal. The principal problem is that it isn't clear what warnings are. Currently VAX LISP distinguishes between two different kinds of error conditions'': ones signalled during compilation with ERROR, CERROR, WARN, and the like, and ones detected by the compiler from examination of the source code being compiled. The former arise in cases like (EVAL-WHEN (COMPILE) (PRINT (+ 3 'A))) or when READ encounters an error while reading a form from the file. However, when this happens during a COMPILE-FILE, we try to continue with the compilation, so as to maximize the usefulness and information generated by the compiler. During COMPILE, the normal error signalling and handling is in effect, so *BREAK-ON-WARNINGS* would indeed control breaking'' upon WARN. The latter arise when the compiler is compiling a form like (SEARCH X) or (LET 3 (F)) Then we also distinguish these cases by how serious they are. In particular there are errors'' and warnings''. However, detecting these anomalies is expected of the compiler, and thus they are not treated as errors'' or warnings'' in the sense of the lisp functions ERROR or WARN. It doesn't make sense to break'' and go into the debugger if the compiler happens to see a variable that was bound but was unused (with no IGNORE declaration). So it isn't clear from the proposal which of these cases are being addressed. If it's really more to control what happens when one does a COMPILE, then the proposal should be changed to say that COMPILE-FILE is not specified as proposed, and what conditions should be reported as being warnings'' should be specified. ---Walter ------ ∂23-Feb-88 1414 CL-Cleanup-mailer function-type-rest-list-element Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Feb 88 14:14:01 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 349602; Tue 23-Feb-88 17:13:00 EST Date: Tue, 23 Feb 88 17:12 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: function-type-rest-list-element To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: The message of 23 Feb 88 13:07 EST from "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> Message-ID: <19880223221249.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 23 Feb 88 14:07:00 EDT From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> We oppose the proposal FUNCTION-TYPE-REST-LIST-ELEMENT: USE-ACTUAL-ARGUMENT-LIST. We feel that although specifying the element type in a function type specifier is slightly more convenient, it is outweighed by its inconsistency and lack of expressiveness. If specifying the element type of lists is an important issue, and we think it is, then we should extend the LIST type to be a list type: (LIST [<element-type> [<length>]]) just like for VECTOR. In fact, it would also be wise to extend SEQUENCE in the same way. But the analogy to VECTOR is false! (VECTOR element-type) does not mean a vector all of whose current elements are of type element-type. Nor does it mean a vector constrained such that that all elements that can be stored into it are of type element-type. The ambiguous language on CLtL p.47 might lead you to think that's what it means, but CLtL p.45 makes it clear. For declaration, (VECTOR element-type) [via (ARRAY element-type (*))] means a one-dimensional array of the most specialized type that is capable of holding objects of type element-type. Therefore, unless element-type is STRING-CHAR or BIT, or a subtype of one of them, this guarantees exactly nothing about the types of the elements of the vector. Maybe the element-type argument to these type-specifiers should mean something else, but that's what it means in Common Lisp as currently defined. VAX LISP has always made use of FUNCTION type specifiers, although it has ignored the &REST and &KEY type information. There's no reason why someone might not write a function type specifier with &REST being a supertype of LIST. It just can't conflict with LIST. Yes, but I don't see what that could be useful for. Here's an interesting thought experiment that might shed some light on what the FUNCTION declaration, and the &REST type specifier nested within in, might be for. Suppose you had an implementation that thought materializing &REST arguments as lists was too inefficient, especially if you didn't bother to do the (fairly simple) flow analysis needed to figure out that the list has dynamic extent and doesn't have to be consed in the heap. So in your implementation, you made a new lambda-list keyword &REST2, which is just like &REST except that the value to which the parameter variable is bound is a stack-allocated object of some implementation-dependent type, and the only legal operations on it are LENGTH2, NTH2, DOLIST2, and APPLY2 (all just like the standard functions with similar names except that they take one of these funny objects as an argument where the standard functions take a list). The caller of a function doesn't need to know or care whether the function accepts its arguments with &REST or with &REST2. If the FUNCTION declaration is for the benefit of callers, then the FUNCTION declaration should be independent of whether the callee is written with &REST or with &REST2. From this I conclude that the &REST type specifier nested within a FUNCTION declaration shouldn't say anything about lists. ∂24-Feb-88 0715 CL-Cleanup-mailer RE: function-type-rest-list-element Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 24 Feb 88 07:15:01 PST Date: 24 Feb 88 10:06:00 EDT From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> Subject: RE: function-type-rest-list-element To: "cl-cleanup" <cl-cleanup@sail.stanford.edu> cc: vanroggen Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> But the analogy to VECTOR is false! (VECTOR element-type) does not mean a vector all of whose current elements are of type element-type. Nor does it mean a vector constrained such that that all elements that can be stored into it are of type element-type. The ambiguous language on CLtL p.47 might lead you to think that's what it means, but CLtL p.45 makes it clear. For declaration, (VECTOR element-type) [via (ARRAY element-type (*))] means a one-dimensional array of the most specialized type that is capable of holding objects of type element-type. Therefore, unless element-type is STRING-CHAR or BIT, or a subtype of one of them, this guarantees exactly nothing about the types of the elements of the vector. Maybe the element-type argument to these type-specifiers should mean something else, but that's what it means in Common Lisp as currently defined. The discussion of ARRAY type specifiers on p.45 is talking about the permissible and expected representations of arrays, not of the possible types of the elements of such arrays. So what's on p.45 doesn't make anything clear here. What would you expect to be the type of the result of the following code: (let ((a ...)) (declare (type (vector foo) a)) (aref a 3)) I believe that in every implementation, the result should be of type FOO, for any type FOO. What is discussed on p.45 says that A might not be of type (VECTOR FOO). But this is unrelated to the question of whether the elements of the array have any particular type. Setting an element of A to be something that's not of type FOO is an error. The representation might allow it, because the new value might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it correct. It's just a matter of whether the array happened to remember the precise type it was created with. I haven't read any clean-up mail, so if you've talked about this issue and resolved it somehow, please tell me. There's no reason why someone might not write a function type specifier with &REST being a supertype of LIST. It just can't conflict with LIST. Yes, but I don't see what that could be useful for. I was just referring to the statement in the first paragraph of the Discussion: "the &REST argument declaration, if any, always be LIST or a subtype of LIST..." Here's an interesting thought experiment that might shed some light on what the FUNCTION declaration, and the &REST type specifier nested within in, might be for. Suppose you had an implementation that thought materializing &REST arguments as lists was too inefficient, especially if you didn't bother to do the (fairly simple) flow analysis needed to figure out that the list has dynamic extent and doesn't have to be consed in the heap. So in your implementation, you made a new lambda-list keyword &REST2, which is just like &REST except that the value to which the parameter variable is bound is a stack-allocated object of some implementation-dependent type, and the only legal operations on it are LENGTH2, NTH2, DOLIST2, and APPLY2 (all just like the standard functions with similar names except that they take one of these funny objects as an argument where the standard functions take a list). The caller of a function doesn't need to know or care whether the function accepts its arguments with &REST or with &REST2. If the FUNCTION declaration is for the benefit of callers, then the FUNCTION declaration should be independent of whether the callee is written with &REST or with &REST2. From this I conclude that the &REST type specifier nested within a FUNCTION declaration shouldn't say anything about lists. One can't expect people to write function type specifiers in Common Lisp with knowledge about the particular implementation's lambda-list- keywords. So I agree with you there. But it's the only thing one could write. Indeed, there might not be any relationship between the lambda-list in a function type specifier and the real lambda-list. (proclaim '(ftype (function (&key (:key1 integer :key2 string)) ...) f)) (defun f (&optional k1 v1 k2 v2) ...) should be OK if F is always called (F :KEY2 x) and the like. Presumably the reason for having lambda-list-keywords in function type specifiers is to indicate the range of number of arguments permissible. The problem here is in trying to use lambda-list syntax for describing function calls. Already there's a slight contortion by having the actual keywords be included in the function type for &KEY arguments. So it isn't quite as simple as just taking the real lambda-list, deleting all the init forms and &AUXen, and replacing parameter names with their types. But I think this way of looking at how function type specifiers are derived is easier than starting with just a positional approach (i.e., the second arg, if supplied, has to be of type X, etc.) and then modifying it to also convey number-of-args and keyword information. Thus one would prefer having the type specifier for the &REST argument be the real type specifier for the &REST argument. ---Walter ------ ∂24-Feb-88 1013 CL-Cleanup-mailer FUNCTION-TYPE:STRICT-REDEFINITION proposal Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 10:13:28 PST Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 09:35:10 PST Received: from bhopal.lucid.com by edsel id AA21578g; Wed, 24 Feb 88 10:03:43 PST Received: by bhopal id AA26979g; Wed, 24 Feb 88 10:09:26 PST Date: Wed, 24 Feb 88 10:09:26 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8802241809.AA26979@bhopal.lucid.com> To: Masinter.pa@xerox.com Cc: sandra%orion@cs.utah.edu, cl-cleanup@sail.stanford.edu In-Reply-To: Masinter.pa@Xerox.COM's message of 19 Feb 88 14:17 PST <880219-141733-9723@Xerox> Subject: FUNCTION-TYPE:STRICT-REDEFINITION proposal re: I intended not to require that it not be a "proper" subtype in the sense that there may be no data items that are FUNCTIONP but not COMPILED-FUNCTIONP. Lucid Common Lisp distinguishes "compiled" closures which exist for the purpose of supporting entry into the interpreter from functions which are truly compiled. It only takes a bit in a header word. If an implementation really doesn't support an interpreter, then having every function be COMPILED-FUNCTIONP doesn't sound like much of a loss. But most implementations in fact do support an interpreter -- which typically runs code at anywhere from 30 to 600 times slower than when compiled. Thus it seems reasonable to require COMPILED-FUNCTIONP in those implementations to be false on, say, (eval '#'(lambda (x) (list x))) no matter what underlying technique is used to support interpreter closures. -- JonL -- ∂24-Feb-88 1459 CL-Cleanup-mailer function-type-rest-list-element Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 24 Feb 88 14:57:43 PST Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 14:19:23 PST Received: from bhopal.lucid.com by edsel id AA22851g; Wed, 24 Feb 88 13:38:35 PST Received: by bhopal id AA01988g; Wed, 24 Feb 88 13:44:20 PST Date: Wed, 24 Feb 88 13:44:20 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8802242144.AA01988@bhopal.lucid.com> To: Moon@stony-brook.scrc.symbolics.com Cc: vanroggen%aitg.decnet@hudson.dec.com, cl-cleanup@sail.stanford.edu In-Reply-To: David A. Moon's message of Tue, 23 Feb 88 17:12 EST <19880223221249.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: function-type-rest-list-element re: Here's an interesting thought experiment that might shed some light on what the FUNCTION declaration, and the &REST type specifier nested within in, might be for. Suppose you had an implementation ... [with] lambda-list keyword &REST2, which is just like &REST except that the value to which the parameter variable is bound is a stack-allocated object of some implementation-dependent type, and the only legal operations on it are LENGTH2, NTH2, DOLIST2, and APPLY2 (all just like the standard functions with similar names except that they take one of these funny objects as an argument where the standard functions take a list). The caller of a function doesn't need to know or care whether the function accepts its arguments with &REST or with &REST2. This "gedanken experiment" isn't hypothetical at all. VAX/NIL, one of the predecessors of Common Lisp, actually had &RESTV and &RESTL in addition to &REST. &RESTV guaranteed a stack-allocated VECTOR and, &RESTL guaranteed a heap-allocated list. &REST was left ambiguous just so that the user couldn't know which of the two kinds of structures was being worked upon, and thus couldn't depend upon any accidental properties. But at "flag day", few other CL participants saw any value to cluttering up &rest *lists*. -- JonL -- ∂25-Feb-88 1047 CL-Cleanup-mailer function-type-rest-list-element Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Feb 88 10:46:56 PST Received: by labrea.Stanford.EDU; Thu, 25 Feb 88 10:08:28 PST Received: from bhopal.lucid.com by edsel id AA26191g; Thu, 25 Feb 88 09:13:40 PST Received: by bhopal id AA05861g; Thu, 25 Feb 88 09:19:28 PST Date: Thu, 25 Feb 88 09:19:28 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8802251719.AA05861@bhopal.lucid.com> To: vanroggen%aitg.decnet@hudson.dec.com Cc: Moon@stony-brook.scrc.symbolics.com, cl-cleanup@sail.stanford.edu In-Reply-To: Walter van Roggen's message of Wed 24 Feb 88 10:06:00 EDT Subject: function-type-rest-list-element re: The discussion of ARRAY type specifiers on p.45 is talking about the permissible and expected representations of arrays, not of the possible types of the elements of such arrays. So what's on p.45 doesn't make anything clear here. Well, it's true that CLtL pp45-47 are anything but "clear". But what Dave is saying (I think) is that a number of wizards have groveled over those pages and all agree that there is only one interpretation of them consistent with the rest of CLtL. And that interpretaton is at variance with your comments: Setting an element of A to be something that's not of type FOO is an error. The representation might allow it, because the new value might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it correct. It's just a matter of whether the array happened to remember the precise type it was created with. Perhaps the clearest indicator that CLtL really isn't saying this is found on p291, under the description of ARRAY-ELEMENT-TYPE. Note how this section really is "clear" that an array made by (make-array 5 :element-type '(mod 5)) may legitimately have an element stored into it that is of type (mod 8) but not necessarily of type (mod 5). There was a rather lengthy interchange on this whole topic (about two months ago?) on the Common-Lisp@SU-AI list. One proposal was to require implementations to conform with your comments quoted above, but it certainly didn't seem to have unanimous approval. Someone pointed out that all current implementations do a form of element-type "upgrading" on at least some :element-type specifiers. Try it in VAXLISP, for example, with (SIGNED-BYTE 5) instead of (MOD 5) and see what you get. If you don't have archives of that mail interchange, I'll can arrange to send you a copy personally. -- JonL -- ∂27-Feb-88 1818 CL-Cleanup-mailer function-type-rest-list-element Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 27 Feb 88 18:18:33 PST Received: ID <RAM@C.CS.CMU.EDU.#Internet>; Sat 27 Feb 88 21:17:29-EST Date: Sat, 27 Feb 1988 21:17 EST Message-ID: <RAM.12378202550.BABYL@> Sender: RAM@λλ From: Ram@C.CS.CMU.EDU To: Jon L White <edsel!jonl@LABREA.STANFORD.EDU> Cc: cl-cleanup@SAIL.STANFORD.EDU, Moon@SCRC-STONY-BROOK.ARPA, vanroggen%aitg.decnet@HUDSON.DEC.COM Subject: function-type-rest-list-element In-reply-to: Msg of 25 Feb 1988 12:19-EST from Jon L White <edsel!jonl at labrea.Stanford.EDU> Well, I don't agree with VanRoggen's stand on the &rest type issue, but I think he is pretty close to the mark about array types. This isn't inconsistent, since the desirability or feasilibility of a typed list specifier is pretty unrelated to the &rest issue. Date: Thursday, 25 February 1988 12:19-EST From: Jon L White <edsel!jonl at labrea.Stanford.EDU> To: vanroggen%aitg.decnet at hudson.dec.com [...] Setting an element of A to be something that's not of type FOO is an error. The representation might allow it, because the new value might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it correct. It's just a matter of whether the array happened to remember the precise type it was created with. Perhaps the clearest indicator that CLtL really isn't saying this is found on p291, under the description of ARRAY-ELEMENT-TYPE. Note how this section really is "clear" that an array made by (make-array 5 :element-type '(mod 5)) may legitimately have an element stored into it that is of type (mod 8) but not necessarily of type (mod 5). No, this example doesn't make it clear. If you make an array :element-type (mod 5), then it is an error to ever store anything in that array that isn't (mod 5). What the example make clear is that implementation has discretion to upgrade the element type. A corollary is that it has discretion to not upgrade the element type. Since a Common Lisp implementation is free to implement whatever specialized array types it pleases, Common Lisp programs must assume that every type potentially has an exact specialization. The only rationale under which one could store something not (mod 5) into that array would be that they could make the array, then call ARRAY-ELEMENT-TYPE to find out that element types it can actually hold, and then store randomness into it. I don't believe that this is a reasonable thing to do. This basically amounts to bogotifying the language in order to make ARRAY-ELEMENT-TYPE work. This is a bad idea, since I think that the semantics of ARRAY-ELEMENT-TYPE are just as seriously flawed as the semantics of TYPE-OF. (which is another flame) It is much easier to give types a clean semantics in Common Lisp if ARRAY-ELEMENT-TYPE and TYPE-OF are ignored. For example, without these functions, there would be no way for users to even know that "array element type upgrading" exists. (Assuming the array TYPEP "feature" mentioned in the manual is fixed.) Rob ∂28-Feb-88 0807 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Feb 88 08:07:33 PST Received: from Salvador.ms by ArpaGateway.ms ; 28 FEB 88 08:08:05 PST From: masinter.pa@Xerox.COM Date: 28 Feb 88 8:07:18 PST Subject: Issue: COERCE-INCOMPLETE To: cl-cleanup@sail.stanford.edu Message-ID: <880228-080805-2138@Xerox> I'm not really back until next week, but this came in for consideration... ---------- Return-Path: <@RELAY.CS.NET:a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET> Received: from RELAY.CS.NET by Xerox.COM ; 25 FEB 88 23:39:52 PST Received: from relay2.cs.net by RELAY.CS.NET id aa07232; 26 Feb 88 2:16 EST Received: from utokyo-relay by RELAY.CS.NET id aa26262; 26 Feb 88 2:06 EST Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET) id AA19019; Fri, 26 Feb 88 15:54:40 JST Received: by tansei.cc.u-tokyo.junet (4.12/6.3Junet-1.0) id AA12493; Fri, 26 Feb 88 15:55:57+0900 Date: Fri, 26 Feb 88 15:55:57+0900 From: Masayuki Ida <a37078%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET> Return-Path: <a37078@tansei.cc.u-tokyo.junet> Message-Id: <8802260655.AA12493@tansei.cc.u-tokyo.junet> To: ida%tansei.cc.u-tokyo.junet@UTOKYO-RELAY.CSNET, masinter.pa Subject: Coercion Dear Larry Masinter, I wrote my opinion on coercion which is attached consulting your suggestion on the format. Please find and use if you think it is valuable to have. Masayuki Ida -------------------------------------------------------------------- Issue: Coerce Reference: coerce (CLtL p50) Category: change Edit history: version 1 by M.Ida, 26-Feb-1988 Problem Description: -------------------- Problem 1: Coerce is not symmetric or not generic among data types. In CLtL, Coerce is defined in page 50 and 51 that, 1) a sequence type may be converted to any other sequence type. 2)Some strings, symbols, and integers may be converted to characters. 2-1) If object is a string of length 1, then the sole element of the string is returned. 2-2) If object is a symbol whose print name is of length 1, then the sole element of the print name is returned. 2-3) If object is an integer n, then (int-char n) is returned. 3) any non-complex number can be converted to a XXX-float. 4) any number can be converted to a complex number. The next table shows that how coerce is not symmetric among character, string, symbol and integer. TABLE 1. Possible Conversions among character, string,symbol, integer type of conversion provided functions coercion under the CLtL character -> string string X character <- string coerce (if the string has only one char.) O character -> symbol (intern (string @i[ch])) X character <- symbol coerce (if pname length is 1) O character -> integer char-code, char-int X character <- integer code-char (zero font-, zero bits- attrib.) O int-char (any font- and any bits-) string -> symbol intern, make-symbol X string <- symbol string, symbol-name X string -> integer (char-code (coerce @i[string] 'character)) X string <- integer (string (code-char @i[integer])) X symbol -> integer (char-code (coerce @i[symbol] 'character)) X symbol <- integer (intern (string (code-char @i[integer]))) X Problem 2: The function of coerce for character is defined to act as char-int/int-char not as char-code/code-char. Proposal: Coerce :replace ------------------------- COERCE should be more generalized for string, symbol, integer, and character data types. The observations show there are no problem if extensions are fully written out in the details. Here is an extension to the current coerce definition using the CLOS. (defmethod coerce ((x character) (y (eql string))) (string x)) (defmethod coerce ((x character) (y (eql symbol))) (intern (string x))) (defmethod coerce ((x character) (y (eql integer))) (char-code x)) (defmethod coerce ((x string) (y (eql symbol))) (intern x)) (defmethod coerce ((x symbol) (y (eql string))) (string x)) (defmethod coerce ((x string) (y (eql integer))) (char-code (coerce x 'character))) (defmethod coerce ((x integer) (y (eql string))) (string (code-char x))) (defmethod coerce ((x symbol) (y (eql integer))) (char-code (coerce x 'character))) (defmethod coerce ((x integer) (y (eql symbol))) (intern (sting (code-char x)))) (defmethod coerce ((x integer) (y (eql character))) (code-char x)) ; redefinition. CLtL defines as int-char The keys are a) ignore char-bits and char-font upon the conversion of characters, assuming font-attribute will be flushed from the language spec. b) ignore the package name upon the conversion of symbols. (package name has no role upon the conversion.) c) the created symbol will be interned to the current package. Rationale: ---------- By extending the definition as this document suggests, the functionality of coerce is symmetric among characters, strings, symbols and integers. Current Practice: Cost to implementors: Cost to users: Benefits: Aesthetics: Discussion: Among the functions in Table 1, we can pick up the role of @t[STRING] function. @T[STRING] has odd definition. It was also the starting point of discussions described in the following. The problems or the awkwards are mainly on the design of the symmetry of the function names. We would start the discussion with the following two observations.@* i) @t[(string @i(x))] is OK. But, @t[(coerce @i(x) 'string)] is illegal.@* While, @t[(character @i(x))] is OK. And @t[(coerce @i(x) 'character)] is OK too..@* ii) To convert from a symbol to a string, use @t[SYMBOL-NAME] or @t[STRING]. While, to convert from a string to a symbol, use @t[MAKE-SYMBOL] to an uninterned symbol, or use @t[INTERN] to an interned symbol.@* @* @* @b[ Discussions on Coercion in Common-Lisp E-mails 1986] The awkward were discussed already in Common-lisp E-mails. The author checked the 10M bytes E-mails on disk. The discussions around @t[coerce] were almost in 1986, and not much in 1985 or before. The sequence of our concern started by a mail of fateman@@dali.berkeley.edu, dated Fri, 16 May 1986 15:40 PDT as follows.@* 1) fateman@@dali.berkeley.edu fri 16 may 1986 15:40 PDT:@* This mail describes the same issue as for STRING function. 2) jeff@@aiva.edinburgh.ac.uk sun 18 may 17:17 GMT@* @t[ ... 'string' applied to a sequence of characters gives an error, typically saying the sequence can't be coerced to a string, but 'coerce' will in fact coerce it...] 3) gls@@think.com, Mon 19 may 1986 12:20 EDT@* @begin[t]Research shows that the Common Lisp archives up to a couple of months ago contains 18 messages that mention @t[COERCE]. None explicitly addresses this issue, but the general tone of the messages is one of conservatism. I now remember that this issue was tied up with the design of the sequence functions. There was real resistance to letting symbols be treated as general sequences, and so the general decision was made that string-specific functions would accept symbols, but general sequence functions would not. ...@end[t] To check his talk, @b[3.3] shows all the early discussions on @t[coerce] the author can find. 4) fahlman@@c.cs.cmu.edu Mon, 19 May 1986 20:44 EDT@* @t[... I would not object to generalizing coerce to handle some of the additional cases that people imagine it ought to handle.] @begin[verbatim] 5) cfry@@oz.ai.mit.edu, Tue, 20 May 1986 03:21 EDT@* ... Coercion is a powerful, easy to remember concept. I think it should be extended as much as possible. ... : (coerce #\a 'string) => "a" (coerce 123 'string) => "123" (coerce #\a 'integer) => (char-code #\a) ; explicitly not provided CLtL p52. It appears that the only reason is that no one could decide on using char-code or char-int for the conversion so they chose not to do it at all. This reasoning is odd. Pick the most frequently used way, document it, and permit it. Same argument for coercion of numeric types. Further out extensions might be: (coerce #'foo 'compiled-function) => returns a compiled function object ... (coerce string-1 'pathname) (coerce bit-vector-1 'integer) ... Undoubtedly there are other coercions which would make sense. ... Users would save a lot of manual searching if coerce was extended. @end[verbatim] 6) Eliot@@umass-cs.csnet, Tue 20 May 1986 15:31 EST@* @t[Coercing symbols to stings is fine, as long as NIL is treated as the empty SEQUENCE, rather than as a symbol.] @begin[verbatim] 7) REM@@IMSSS, 19 May 09:34 PST referring to the mail of gls saying that "@t[COERCE] was limited to ... sequence and numerical coercions". This is one of the bad points of many LISPs, including CL, functions that are miss-named or otherwise don't do what you'd expect from their name. ... I hope the international standards committee will fix this kind of problem so programmers reading somebody else's code can have the meaning apparent in most cases form general programming tradition rather than having to constantly check the manual to see if the function does what it seems to say it would do. 8) DCP@@scrc-quabbin.arpa, Wed, 21 May 1986 16:45 EDT,@* Does (coerce @i(symbol) 'string) return (symbol-name @i(symbol)), or (format nil "~S" @i(symbol)), or (format nil "~A::~A" (package-name (symbol-package @i(symbol))) (symbol-name @i(symbol))) or what ? If this weren't enough, added in with my personal views of style and functionality, for me to want to help veto this coercion, the special casing of NIL certainly would. Programs should reflect their meaning. A string is a sequence, a symbol is not. Why shouldn't @# (coerce :ascii-EOT 'integer) work? The answer is that the requested behavior is not a coercion between compatible types, it is a functional translation between human understandable names for the ascii control characters and the integers that are their corresponding values. @end[verbatim] We found that there is a possibility to extend the semantics of @t[coerce] to cope with more generic types. It should be noted that the two key designers of Common Lisp mentioned their opinions, and they do not always be against to the extension. The discussion was stopped at this point and we cannot find their continuation yet. We find from this story that @* 1) If we don't care about the package, we may extend the coerce to the function from a symbol to a string, @* 2) If we are free to care about the font- and bits- attribute, we may extend the coerce to include the function from a character to other types.@* @* @* @b[ Early discussions on coercion] The following sequence was picked up from the archives. They are almost all the meaningful talk the author can find. They were in 1983, one year before @i(CLtL) was published. @begin(verbatim) 1) Guy Steele, dated 27 May 83 01:23:14 EDT, (in the summary of the discussion with DLW and moon upon the laser edition update) a)No.38: it is noted that DLW said "coercing of characters to integers should probably be allowed too." and this point was marked as {controversial}. b) Moon's comment. "if (string x) <=> (coerce x 'string) exactly, say so. Both of these should coerce a character into a 1-element string; neither says so now. The old argument against this, that people might expect string of a number to give not numbers." and Guy Steele agreed. N.197: {gloss} string is required to signal an error if its argument is not a string and not a symbol. This is wrong; it should convert a character to a one-character string. Also it says that string will not convert a sequence of characters into a string, but coerce will. This might be all right, except under coerce it says that when coercing to a string the implementation is allowed to return a more general type. ... Also the coerce writeup doesn't say anything for or against coercing from a character to a 1-long string. {controversial} {will clarify} 2) Fahlman, dated Sat, 28 May 1983 22:34 EDT; At least, I would like you to consider dropping these. ... Page 38: Coercing of characters to integers is not a very useful operation in portable code if the language spec does not specify the correspondence (and Common Lisp does not). Do you still want to propose that we add this coercion? I'm not particularly opposed, I just worry that users will find it too easy to inadvertently do non-portable things if given this coercion. 3) Moon, date: sat, 28 May 1983, 22:40-EDT I don't think coercion of characters to integers should be allowed, because how do you know whether you want the char-code or what. Dan was probably just stuck in our old mindset from not having character objects on the Lisp machine. Coercion of characters to strings, however, I believe is useful. 4) Daniel L.Weinreb, Date: Tuesday, 31 May 1983, 15:40-EDT ... It's OK with me if COERCE doesn't coerce characters to integers. However, I strongly suggest putting in a clarification note to that effect... Or maybe a Rationale note saying that it doesn't because it wouldn't be clear what to do about the char-code versus whole character, and telling you to use the particularly function instead. This note is for the benefit of users more than of implementors. 5) Scott E. Fahlman, Date: Wed, 1 Jun 1983 01:47 EDT < referring 4)> It's OK with me if COERCE doesn't coerce characters to integers. However, I strongly suggest putting in a clarification note to that ... << I assume Guy will do this. >> @end(verbatim) As far as we can see from this talk, that the process of making a coercion between characters and integers be restricted such that char-to-integer conversion is not provided, while integer-to-char is. The coercions from characters to integers are purposely not provided; @t[char-code] or @t[char-int] may be used explicitly to perform such conversions (See @b[Appendix] for the definitions of @t[char-code] and @t[char-int]). The difference between @t(char-int) and @t(char-code) is on the treatment of @i(font) and @i(bits) attributes. If these two attributes have no significant meaning and are ignored by everyone, we can make the story much simpler. (And @b[4.] describes at least font- is not alive). ∂29-Feb-88 1357 CL-Cleanup-mailer function-type-rest-list-element Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Feb 88 13:57:40 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 353104; Mon 29-Feb-88 16:54:04 EST Date: Mon, 29 Feb 88 16:53 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: function-type-rest-list-element To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>, Jon L White <edsel!jonl@labrea.Stanford.EDU>, Ram@C.CS.CMU.EDU cc: cl-cleanup <cl-cleanup@SAIL.STANFORD.EDU> In-Reply-To: The message of 24 Feb 88 09:06 EST from "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>, <8802242144.AA01988@bhopal.lucid.com>, <8802251719.AA05861@bhopal.lucid.com>, <RAM.12378202550.BABYL@> Message-ID: <19880229215350.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 24 Feb 88 10:06:00 EDT From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> But the analogy to VECTOR is false! (VECTOR element-type) does not mean a vector all of whose current elements are of type element-type. Nor does it mean a vector constrained such that that all elements that can be stored into it are of type element-type. The ambiguous language on CLtL p.47 might lead you to think that's what it means, but CLtL p.45 makes it clear. For declaration, (VECTOR element-type) [via (ARRAY element-type (*))] means a one-dimensional array of the most specialized type that is capable of holding objects of type element-type. Therefore, unless element-type is STRING-CHAR or BIT, or a subtype of one of them, this guarantees exactly nothing about the types of the elements of the vector. Maybe the element-type argument to these type-specifiers should mean something else, but that's what it means in Common Lisp as currently defined. The discussion of ARRAY type specifiers on p.45 is talking about the permissible and expected representations of arrays, not of the possible types of the elements of such arrays. So what's on p.45 doesn't make anything clear here. What would you expect to be the type of the result of the following code: (let ((a ...)) (declare (type (vector foo) a)) (aref a 3)) I don't see anything in CLtL that addresses this question. I believe that in every implementation, the result should be of type FOO, for any type FOO. What is discussed on p.45 says that A might not be of type (VECTOR FOO). But this is unrelated to the question of whether the elements of the array have any particular type. Setting an element of A to be something that's not of type FOO is an error. The representation might allow it, because the new value might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it correct. It's just a matter of whether the array happened to remember the precise type it was created with. I agree that this is a reasonable approach. I don't think CLtL says this, but I don't think it says anything that contradicts it, either. I think this is not too relevant to my point that the (VECTOR FOO) type-specifier does not mean a vector all of whose elements are of type FOO. As you point out, it means that a portable program "should" (in CLtL "is an error" sense) assume that it can only store elements of type FOO into that vector. But I think your proposed meaning for (LIST FOO) was rather stronger. Perhaps I should make my point a different way: I don't think that Common Lisp's current type system for compound types is well enough specified for this kind of extension to work obviously and naturally without exposing problems. I haven't read any clean-up mail, so if you've talked about this issue and resolved it somehow, please tell me. It's been discussed periodically but I don't think it's ever come close to resolution. It's perhaps too large an issue for the Cleanup committee. The problem here is in trying to use lambda-list syntax for describing function calls. Already there's a slight contortion by having the actual keywords be included in the function type for &KEY arguments. So it isn't quite as simple as just taking the real lambda-list, deleting all the init forms and &AUXen, and replacing parameter names with their types. But I think this way of looking at how function type specifiers are derived is easier than starting with just a positional approach (i.e., the second arg, if supplied, has to be of type X, etc.) and then modifying it to also convey number-of-args and keyword information. Thus one would prefer having the type specifier for the &REST argument be the real type specifier for the &REST argument. I agree with you, up to the last sentence, which I can't understand. There isn't such a thing as an "&REST argument" in Common Lisp, unless you mean the last argument to APPLY. If where you said "argument" you meant "parameter", then I understand what you're saying but don't agree with it. One could equally well conclude from the preceding paragraph that the type specifier for the &REST arguments (note the plural) should be the type specifier for each actual argument. Since there isn't a one to one correspondence of arguments to parameters in this one case, the analogy of function type specifiers to lambda-lists doesn't really give us any guidance. I'm being too long-winded here, since I don't even know what these FUNCTION type specifiers are useful for, anyway. My main reason for jumping in was to point out a possible misconception about how strong the VECTOR type specifier is in current Common Lisp. Date: Thu, 25 Feb 88 09:19:28 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> re: The discussion of ARRAY type specifiers on p.45 is talking about the permissible and expected representations of arrays, not of the possible types of the elements of such arrays. So what's on p.45 doesn't make anything clear here. Well, it's true that CLtL pp45-47 are anything but "clear". But what Dave is saying (I think) is that a number of wizards have groveled over those pages and all agree that there is only one interpretation of them consistent with the rest of CLtL. And that interpretaton is at variance with your comments: Setting an element of A to be something that's not of type FOO is an error. The representation might allow it, because the new value might be (TYPEP x (ARRAY-ELEMENT-TYPE A)), but that doesn't make it correct. It's just a matter of whether the array happened to remember the precise type it was created with. Perhaps the clearest indicator that CLtL really isn't saying this is found on p291, under the description of ARRAY-ELEMENT-TYPE. Note how this section really is "clear" that an array made by (make-array 5 :element-type '(mod 5)) may legitimately have an element stored into it that is of type (mod 8) but not necessarily of type (mod 5). Well, this is simply another way of stating the root problem here. CLtL isn't sure whether its data types are portable, fairly abstract types or are ways to find out about implementation details. Date: Sat, 27 Feb 1988 21:17 EST From: Ram@C.CS.CMU.EDU Well, I don't agree with VanRoggen's stand on the &rest type issue, but I think he is pretty close to the mark about array types. This isn't inconsistent, since the desirability or feasilibility of a typed list specifier is pretty unrelated to the &rest issue. Not really, since VanRoggen's proposal was to employ a typed list specifier in the resolution of the &rest issue. By the way, I'm not arguing in favor of the way array types currently are defined, I'm just pointing out the facts. If we're now going to redesign array types, I think that's a good idea, or at least an interesting one, but I'll probably limit my contribution to pointing out that it isn't easy, i.e. the obvious trivial fixes don't completely work. The only rationale under which one could store something not (mod 5) into that array would be that they could make the array, then call ARRAY-ELEMENT-TYPE to find out that element types it can actually hold, and then store randomness into it. I don't believe that this is a reasonable thing to do. But someone else might believe that it is. See my comment above that CLtL isn't sure what the goal of the type system is. This basically amounts to bogotifying the language in order to make ARRAY-ELEMENT-TYPE work. This is a bad idea, since I think that the semantics of ARRAY-ELEMENT-TYPE are just as seriously flawed as the semantics of TYPE-OF. (which is another flame) It is much easier to give types a clean semantics in Common Lisp if ARRAY-ELEMENT-TYPE and TYPE-OF are ignored. For example, without these functions, there would be no way for users to even know that "array element type upgrading" exists. (Assuming the array TYPEP "feature" mentioned in the manual is fixed.) Yes, the semantics would be cleaner if there weren't compound objects, or if there weren't implementation dependencies. No argument about that. I think removing those primitives from the language may be just sweeping the problem under a rug, not solving it, though. Admittedly that would be in the tradition of Common Lisp. ∂29-Feb-88 1553 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 2) Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 29 Feb 88 15:52:45 PST Received: by multimax.ARPA (5.51/25-eef) id AA04746; Mon, 29 Feb 88 18:54:32 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA19855; Mon, 29 Feb 88 18:55:17 EST Message-Id: <8802292355.AA19855@mist.UUCP> To: cl-cleanup%sail.stanford.edu@multimax Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2) Date: Mon, 29 Feb 88 18:55:14 EST From: Dan L. Pierson <pierson@mist> Issue: STANDARD-INPUT-INITIAL-BINDING References: Standard streams (pp. 327-329) Category: CHANGE Edit history: Version 1 by Pierson and Haflich 1/19/87 Version 2 by Pierson 2/29/88 Status: For Internal Discussion This is a complete rewrite. I hope the added complexity is worth it, I don't see anyway to both hide the hair and do better than CLtL. Problem description: CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*, *ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are initially bound to synonym streams to *TERMINAL-IO*. This requirement hampers the integration of Common Lisp with many existing and potential operating environments. For example, a Unix implementation is currently unable to legally support Unix standard error output even though Common Lisp defines *ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound to the same stream as *STANDARD-OUTPUT*. A workstation environnment which provides stream access to windows as an extension is currently forbidden to make trace output appear in a separate window by default because *TRACE-OUTPUT* is required to start out bound to the same stream as *STANDARD-OUTPUT*. Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS): A Common Lisp implementation is required to provide two sets of open streams, Primitive Streams, and User Streams. Most user programs should only use the User Streams; each User Stream has a specific purpose as defined in CLtL. [[ If this proposal is accepted I can be persuaded to retype the page and a half of definitions here.]] The Primitive Streams are the initial defined interfaces between Lisp and the non-Lisp world. The primary purpose of the Primitive Streams is to make it possible to portably recover from a stream-binding error on any User Stream, for this reason it is an error to rebind or set any Primitive Stream. Implementations are encouraged, but not required to signal a correctable error if a Primitive Stream is rebound. Primitive Streams: *INITIAL-INPUT* This stream is bound to the primary default input of the Lisp system (e.g. standard input on Unix, SYSINPUT on VMS).  While
this will probably be an interactive terminal or window during
program development, it may well be a data file for a
non-interactive application.
*INITIAL-OUTPUT*
This stream is bound to the primary default output of the Lisp
system (e.g. standard output on Unix, SYSOUTPUT on VMS). While this will probably be an interactive terminal or window during program development, it may well be a data file for a non-interactive application. *INITIAL-QUERY-INPUT* Whenever possible, this stream is bound to an interactive input source. This may be the same as *initial-input* in a development environment, or it may be a separate window, or terminal. If the Lisp system is running under an operating system such as Aegis which provides a separate error input source, this stream should probably be bound to that source. In a non-interactive environment for which no interactive input is available, reading this stream will always result in EOF. *INITIAL-ERROR-OUTPUT* If *initial-query-input* is bound to an interactive input source, this stream should be bound to the cooresponding interactive output destination such that *query-io* will work in the expected way if bound to a two-way stream between these two streams. If the Lisp system is running under an operating system such as Aegis, Unix, or VMS which provides a separate error output destination, this stream should be bound to that destination. In a non-interactive environment without a separate error destination, this stream should be bound to the same destination as *initial-output*. User Streams: *TERMINAL-IO* The initial binding of *terminal-io* is a two-way stream between *initial-input* and *initial-output* unless these streams can be determined to be non-interactive and *initial-query-input* and *initial-error-output* can both be determined to be real interactive streams (e.g. reading *initial-query-input* does not always result in EOF), in which case *terminal-io* is bound to a two-way stream between them. In a windowing environment, *terminal-io* may refer to a different window than *query-io* (and therefore than any of the *initial-foo* streams) as long as all of these streams refer to windows. *STANDARD-INPUT* The initial binding of *standard-input* is *initial-input*. *STANDARD-OUTPUT* The initial binding of *standard-output* is *initial-output*. *ERROR-OUTPUT* The initial binding of *error-output* is *initial-error-output*. *TRACE-OUTPUT* The initial binding of *trace-output* is *initial-error-output* in a non-windowed environment. In a windowed environment, *trace-output* may start out bound in some other way (e.g. to a non-existant trace output window which will be automagically created when output is first done to *trace-output*). *QUERY-IO* Initially bound to a two way stream between *initial-query-input* and *initial-error-output*. *DEBUG-IO* The initial binding of *debug-io* is *initial-error-output* in a non-windowed environment. In a windowed environment, *debug-io* may start out bound in some other way. Test Cases/Examples: (PROGN (PRINT "Output" *STANDARD-OUTPUT*) (PRINT "Error" *STANDARD-ERROR*)) In current Common Lisp will write: ------ Output Error ------ With proposal *might* write: ------ Output ------ and "Error" appears somewhere else. Rationale: This proposal attempts to provide a balance between over-specifying behavior to the point that Lisp programs can't behave like other programs in conventional operating systems and providing enough specification that Common Lisp programs can perform portable input and output including safe rebinding of the standard streams. Current practice: Lucid binds *TERMINAL-IO* to a special internal stream type. Franz binds *TERMINAL-IO* to a special internal stream type for terminal streams which reads from Unix standard input and writes to Unix standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream with input from Unix standard input and output to Unix standard output. Cost to Implementors: All implementations will have to change to some degree but the changes will probably be simple and localized. Most implementations already include some or all of the initial streams as internal stream types so this is largely a documentation and initialization task. Cost to Users: User code which depends on the strict binding hierarchy in CLtL may have to change. Cost of non-Adoption: It will continue to be difficult or impossible to integrate portable Common Lisp progams in conventional operating system environments. Many implementations will have to continue to choose between conforming to the standard and providing a superior user environment. Benefits: Implementations will be more able to match their IO behavior to their environment and their user's expectations. Aesthetics: The four new streams appear to add complexity but they also separate the previous intermixed concepts of initial bindings and standard purpose streams. Discussion: The repeated mention of windowing environments above seems to be getting dangerously close to the environmental issues this standard is supposed to avoid, but Pierson feels that if we have to do more than leave these areas undefined, we also have to give advanced environments official permission to do their thing. ∂29-Feb-88 2001 CL-Cleanup-mailer function-type-rest-list-element Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Feb 88 19:59:55 PST Received: by labrea.Stanford.EDU; Mon, 29 Feb 88 19:21:33 PST Received: from bhopal.lucid.com by edsel id AA04105g; Mon, 29 Feb 88 19:48:13 PST Received: by bhopal id AA04652g; Mon, 29 Feb 88 19:54:18 PST Date: Mon, 29 Feb 88 19:54:18 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803010354.AA04652@bhopal.lucid.com> To: Moon@stony-brook.scrc.symbolics.com Cc: cl-cleanup@sail.stanford.edu, vanroggen%aitg.decnet@hudson.dec.com, Ram@c.cs.cmu.edu In-Reply-To: David A. Moon's message of Mon, 29 Feb 88 16:53 EST <19880229215350.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: function-type-rest-list-element re: . . . CLtL isn't sure whether its data types are portable, fairly abstract types or are ways to find out about implementation details. Good point. In that series of messages a couple of months ago (?) on this issue, there were basically two camps of opinions: (1) array types should be completely portable -- hence the exact equivalence class of the :element-type specifier must be "remembered" (2) "Upgrading" is reasonable, albeit a source of non-portability akin to the fixnum/bignum split; to do otherwise isn't worth it. Both Rob and Walter are espousing position (1), and may not have fully noticed that it isn't mandated by CLtL. I myself forget the horrible intricacies of array types from time to time. Worse yet, I waffle between preferring (1) and (2) depending on the latest "arguments" for one or the other. To me, this indicates that an easy solution isn't at hand. While there seemed to be no clear consensus on saying that types "must be" portable, almost everyone agreed that the schizophrenia induced by CLtL p45 is a bad idea, and could easily be dropped. This is the part that says "Types can therefore be used for two different purposes: declaration and discrimination. ...", and implies as a consquence that the result of: (make-array <n> :element-type '<type-spec>) will probably not be of typep (array <type-spec>). Not only is this very counterintuitive, but it really doesn't satisfy any need that I'm aware of. At first blush, it might seem to be a corollary of "upgrading"; but it isn't at all. -- JonL -- ∂01-Mar-88 1009 CL-Cleanup-mailer function-type-rest-list-element Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Mar 88 10:07:38 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 353704; Tue 1-Mar-88 13:07:13 EST Date: Tue, 1 Mar 88 13:07 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: function-type-rest-list-element To: Jon L White <edsel!jonl@labrea.Stanford.EDU> cc: cl-cleanup@SAIL.STANFORD.EDU, vanroggen%aitg.decnet@hudson.dec.com, Ram@c.cs.cmu.edu In-Reply-To: <8803010354.AA04652@bhopal.lucid.com> Message-ID: <19880301180711.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 29 Feb 88 19:54:18 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> While there seemed to be no clear consensus on saying that types "must be" portable, almost everyone agreed that the schizophrenia induced by CLtL p45 is a bad idea, and could easily be dropped. This is the part that says "Types can therefore be used for two different purposes: declaration and discrimination. ...", and implies as a consquence that the result of: (make-array <n> :element-type '<type-spec>) will probably not be of typep (array <type-spec>). Not only is this very counterintuitive, but it really doesn't satisfy any need that I'm aware of. At first blush, it might seem to be a corollary of "upgrading"; but it isn't at all. I don't know why the declaration vs discrimination thing was done. The only thing I can guess at is that the idea was that if (typep a '(array foo)), then it's -guaranteed- that (typep (aref a n) 'foo) is true, because a is implemented with a representation that only holds objects of type foo. Before speculating further I should of course leaf through CLtL to see if it already contains somewhere an explanation of why the declaration vs discrimination distinction was drawn. Offhand getting rid of this distinction into two kinds of types seems like a good idea. However, I'm a bit leery of changing things in the language when I don't understand why they are there. At first thought, removing the distinction seems like an upward-compatible change in the sense that all it does is make some types that currently have no members, in a particular implementation, have some members. However there might be subtle incompatibilities with existing programs, since the subtype rules would be changed, and in a way that depends on what array representations a particular implementation has. I don't claim to understand the implications right now. ∂01-Mar-88 1102 CL-Cleanup-mailer sequence-functions-exclude-arrays (pardon msg duplication, if any) Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 1 Mar 88 11:01:53 PST Date: 1 Mar 88 13:45:00 EDT From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> Subject: sequence-functions-exclude-arrays (pardon msg duplication, if any) To: "cl-cleanup" <cl-cleanup@sail.stanford.edu> cc: vanroggen Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> We currently oppose the proposal SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS: GENERALIZE as it stands. There are a number of issues that should be addressed. The proposal merely offers new syntax for functionality already provided by displaced vectors. The argument that users (or at least one user) "dislikes" using displaced vectors has little meaning. The syntax for displaced vectors could be improved with some trivial macros, while efficiency concerns should be handled by the compiler. The availability of ROW-MAJOR-AREF would seem to make this proposal even less necessary than before. It wouldn't change the behavior of FILL, COUNT, etc. but does make such array operations even easier to implement efficiently. There is no description of the meaning of :START and :END keyword arguments for affected functions in the current proposal. Do ARRAYs become a subtype of SEQUENCE? We assume not, but this should be specified. However, the sequence functions won't just be sequence'' functions any more. It's confusing to remember which functions work on arrays and which don't. Despite the proposal's claim to the contrary, it strikes us that this is precisely an attempt to make Common Lisp into a kind of half-baked APL. We feel adoption of this proposal will almost certainly result in pressure to extend still more sequence functions. This may or may not be desirable in the long run; but this proposal is only a partial measure. ---Walter van Roggen & Jeff Piazza ------ ∂01-Mar-88 1124 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 2) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Mar 88 11:24:14 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 353802; 1 Mar 88 14:23:46 EST Date: Tue, 1 Mar 88 14:23 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2) To: Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>, Pierson@MULTIMAX.ARPA cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8802292355.AA19855@mist.UUCP> Message-ID: <19880301192344.0.MOON@EUPHRATES.SCRC.Symbolics.COM> There are actually three parts to this proposal, and perhaps it should be written in a way that makes the distinction even clearer. First, the specification of *STANDARD-INPUT* etc. is changed to specify them in terms of what they do, rather than in terms of how they are implemented. I wholeheartedly support this. I think the proposal needs to go a little farther in this direction. For instance, it seems to apply that the initial binding of *TERMINAL-IO* will be a value returned by the MAKE-TWO-WAY-STREAM function. That's implementation. Instead it should say only that the initial binding of *TERMINAL-IO* behaves in such a way that input comes from, and output goes to, an interactive place, if there is one. If no interactive places exist, I think you say (the wording is a bit confusing) that *TERMINAL-IO* is bound to (MAKE-TWO-WAY-STREAM *STANDARD-INPUT* *STANDARD-OUTPUT*), even though it's not a terminal. I'm not sure, but I think it might be better for *TERMINAL-IO* to be unbound, or a stream that signals an error if used, in this case, since anything that explicitly uses *TERMINAL-IO* is trying to do something that simply can't be done. I suspect that the alignment of the *TERMINAL-IO* interactive place with the *STANDARD-INPUT* and *QUERY-IO* interactive places should be left up to the implementation, rather than trying to say (as you do) it goes here if that's interactive, else it goes there. There is probably a great deal of variation among implementations on this point, and I don't see that a portable program needs to know whether *TERMINAL-IO* is the same as *STANDARD-INPUT*, the same as *QUERY-IO*, or the same as neither of them; a portable program should use whichever stream is the one it really means, not use some different one on the assumption that it's really the same. Second, you propose to add the variable *INITIAL-QUERY-INPUT*, which doesn't quite correspond to *QUERY-IO*. This gives access to a primitive stream that hadn't been identified as primitive before, but that exists in some implementations. Although I don't understand how an application program would use an input-only query stream, I see no harm in making this change. No one is forced to use it if they don't want to. I'd drop the word "initial" from the variable name. Third, you propose to add three new variables that retain the initial values of three of the existing stream variables, in case the existing variables are rebound. I don't see any value in this, except that it helps you describe the meanings of the other streams. A program that wished to portably recover from a stream-binding error on any User Stream could start by saving the values of the existing variables. We don't need to add new variables for this. This sounds a bit critical, but I think this is basically a very good proposal. I hope you find my suggested improvements constructive. ∂01-Mar-88 1301 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1) Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 1 Mar 88 13:01:05 PST Received: by multimax.ARPA (5.51/25-eef) id AA11586; Tue, 1 Mar 88 16:02:47 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA21522; Tue, 1 Mar 88 16:02:38 EST Message-Id: <8803012102.AA21522@mist.UUCP> To: cl-cleanup%sail.stanford.edu@multimax Subject: Issue: LET-TOP-LEVEL (version 1) Date: Tue, 01 Mar 88 16:02:35 EST From: Dan L. Pierson <pierson@mist> Issue: LET-TOP-LEVEL References: Top-Level Forms (p. 66), DEFUN (p. 67), DEFVAR, DEFPARAMETER, DEFCONSTANT (pp. 68-69) Category: ADDITION Edit history: Version 1 by Pierson 3/1/88 Status: For Internal Discussion Problem description: The main defining forms in CLtL do not support defining (as opposed to creating) closures in lexical environments. Proposal (LET-TOP-LEVEL:ALLOW-DEF): Require implementations to support DEFUN, DEFVAR, DEFPARAMETER, and DEFCONSTANT enclosed in a LET at top level as well as a PROGN at top level. Do not require support for DEFMACRO (environment irrelevant) or EVAL-WHEN. Explicitly note that a "top level" let can be included in a top level PROGN. Test Cases/Examples: The following creates a simple resource allocation package for THINGs. It needs to be COMPILE-FILEd to test it. (LET ((THINGS '())) (DEFUN GET-THING () (IF THINGS (PROG1 (CAR THINGS) (SETF THINGS (CDR THINGS))) (MAKE-THING))) (DEFUN FREE-THING (THING) (SETF THINGS (CONS THING THINGS)))) Rationale: Common Lisp tries to support lexical closures but this support is really confined to anonymous lambdas within other function definitions. This proposal attempts to move lexical closures closer to first-class status in Common Lisp. Current practice: The above example works in both Ibuki Lisp and Lucid, however only Ibuki Lisp describes (SYMBOL-FUNCTION 'GET-THING) as a closure. Both Symbolics and TI are reported to leave GET-THING and FREE-THING as named-lambdas instead of compiling them. Cost to Implementors: While there is obviously some work required, it shouldn't be too hard since all Common Lisp compilers are required to understand functions in lexical closures in other contexts. Cost to Users: None, this is an upward compatible change. Cost of non-Adoption: Common Lisp will continue to leave a major style of lexical closure use unsupported. This is probably most important to people converting from Scheme to Common Lisp. Benefits: Lexical closures will become more useful. The increased information hiding available may make some programs more maintainable by reducing the number of global variables which really should be private to a small group of functions. It will be easier to migrate some Scheme programming styles to Common Lisp. Aesthetics: The aesthetics of the language will be improved by supporting a more uniform view and use of lexical closures. Discussion: It has been pointed out that much of this proposal can be accomplished by layering macros on top of SETF of SYMBOL-FUNCTION. The problem with the macro approach is that it doesn't support whatever additional environmental things the implementation may decide to do with DEFUN (e.g. make an entry in the cross reference database). One disadvantage of this proposal is that it doesn't interact well with Lisp-style incremental development, for example a new top-level defun of GET-THING wouldn't work. Pierson believes that this is an inherent consequence of heavy use of lexical closures and that the best workaround is to use an inspector which can support incremental development within the current lexical scope, however this is all outside the purvue of this committee. Maybe this should be a compiler proposal instead of a cleanup proposal. ∂01-Mar-88 1310 CL-Cleanup-mailer function-type-rest-list-element (really array types) Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 13:09:54 PST Received: ID <RAM@C.CS.CMU.EDU.#Internet>; Tue 1 Mar 88 16:08:28-EST Date: Tue, 1 Mar 1988 16:08 EST Message-ID: <RAM.12378932724.BABYL@> Sender: RAM@λλ From: Ram@C.CS.CMU.EDU To: Jon L White <edsel!jonl@LABREA.STANFORD.EDU> Cc: cl-cleanup@SAIL.STANFORD.EDU, Moon@SCRC-STONY-BROOK.ARPA, vanroggen%aitg.decnet@HUDSON.DEC.COM Subject: function-type-rest-list-element (really array types) In-reply-to: Msg of 29 Feb 1988 22:54-EST from Jon L White <edsel!jonl at labrea.Stanford.EDU> Date: Monday, 29 February 1988 22:54-EST From: Jon L White <edsel!jonl at labrea.Stanford.EDU> To: Moon at stony-brook.scrc.symbolics.com Re: function-type-rest-list-element re: . . . CLtL isn't sure whether its data types are portable, fairly abstract types or are ways to find out about implementation details. Good point. In that series of messages a couple of months ago (?) on this issue, there were basically two camps of opinions: (1) array types should be completely portable -- hence the exact equivalence class of the :element-type specifier must be "remembered" (2) "Upgrading" is reasonable, albeit a source of non-portability akin to the fixnum/bignum split; to do otherwise isn't worth it. Both Rob and Walter are espousing position (1), and may not have fully noticed that it isn't mandated by CLtL. Actually I'm not proposing 1, at least as I understand what you are saying. My idea is that TYPEP automatically "upgrade" its type argument to the corresponding "implementation type", i.e. a type actually supported by the implementation. This basically amounts to requiring the programmer (as opposed to the array) the remember the array element type, but in the absence of a hard semantics for ARRAY-ELEMENT-TYPE/TYPE-OF, this is the same as requiring that arrays "remember their element-type". I think that analogies with the FIXNUM/INTEGER are flawed: FIXNUM has is a precisely defined concept within the language: (integer ,most-negative-fixnum ,most-positive-fixnum) Given this definition, a Common Lisp program can have a portable understanding of what it means to be a FIXNUM. For example, it is clear that (typep most-negative-fixnum 'fixnum) is true in any Common Lisp implementation. With arrays, TYPEP is simply broken. Unless you use one of the special element types, BIT, STRING-CHAR or T, TYPEP doesn't mean anything on arrays. It seems to me that the FIXNUM issue is kind of like a resource restriction: "This program will only run when a fixnum is at least 16 bits." is similar to "This program will only run when you can have 1e6 element bit-vectors." In constrast, there is no way to characterize the set of implementations in which TYPEP will work on arrays. In fact, there probably are no such implementations. [...] almost everyone agreed that the schizophrenia induced by CLtL p45 is a bad idea, and could easily be dropped. This is the part that says "Types can therefore be used for two different purposes: declaration and discrimination. ...", and implies as a consquence that the result of: (make-array <n> :element-type '<type-spec>) will probably not be of typep (array <type-spec>). Not only is this very counterintuitive, but it really doesn't satisfy any need that I'm aware of. Yes, I agree with this. Rob ∂01-Mar-88 1318 CL-Cleanup-mailer UPGRADE-ARRAY-ELEMENT-TYPE: a sloution for the array TYPEP problem? Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 13:16:30 PST Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 12:38:16 PST Received: from bhopal.lucid.com by edsel id AA06523g; Tue, 1 Mar 88 13:03:03 PST Received: by bhopal id AA05817g; Tue, 1 Mar 88 13:09:10 PST Date: Tue, 1 Mar 88 13:09:10 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803012109.AA05817@bhopal.lucid.com> To: Moon@stony-brook.scrc.symbolics.com Cc: cl-cleanup@sail.stanford.edu, vanroggen%aitg.decnet@hudson.dec.com, Ram@c.cs.cmu.edu In-Reply-To: David A. Moon's message of Tue, 1 Mar 88 13:07 EST <19880301180711.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: UPGRADE-ARRAY-ELEMENT-TYPE: a sloution for the array TYPEP problem? re: I don't know why the declaration vs discrimination thing was done. . . . Offhand getting rid of this distinction into two kinds of types seems like a good idea. However, I'm a bit leery of changing things in the language when I don't understand why they are there. . . . I share your queasiness here. My first impluse is to ask for a function (which would be "implementation revealing") named UPGRADE-ARRAY-ELEMENT-TYPE whose purpose would be to tell you what the canonical representation for a type name is (when used as an :element-type specifier). E.g., suppose: (setq a (make-array size :element-type 'foo) (setq real-element-type (upgrade-array-element-type 'foo)) then the following two specifiers would be type-equivalent: (array foo) (array ,real-element-type) even if "'foo" and "real-element-type" be not type-equivalent. Furthermore, (typep (aref a n) real-element-type) is always true, even though in the face of non-trivial upgrading, (typep (aref a n) 'foo) could be false. I would consider UPGRADE-ARRAY-ELEMENT-TYPE in the same genre of features as MOST-POSITIVE-FIXNUM. Programmers would inevitably choose to use "real-element-type" rather than "'foo", and ocasionally find that their code wasn't so trivially portable to a system that had a fundamentally different kind of upgrading. But if "upgrading" is to remain in CL, I don't see how we can avoid opening it up a bit for inspection. My second impluse is to toss out upgrading altogether, and require every array to remember the type (or, a canonical name therefor) by which it was created. The reason this is second, rather than first, on my list is that to make types absolutely portable this way is a very pyrrhic success. Sure, your program will port to the Y machine -- it will just run two orders of magnitude slower [because you started out on, say, a Multics machine with (MOD 512) arrays optimized, and ported to an implementation for an engineering workstation that prefers (UNSIGNED-BYTE 8) arrays ...]. Finally, as I've said before, I don't think it's an acceptable solution for Lisp to take the same route as C (and others) to achieve portability. The kinds of array types in such languages are limited to a small (albeit very useful) set that seems inspired by one particular hardware architecture. -- JonL -- P.S. Of course UPGRADE-ARRAY-ELEMENT-TYPE can currently be implemented in a "consy" way doing something like: (array-element-type (make-array 0 :element-type 'foo)) But the presence of a "first class" function UPGRADE-ARRAY-ELEMENT-TYPE would be more for the purpose of encouraging cognizance of these problems than for avoiding the consing. Implicitly, such a function lies underneath any implementation of MAKE-ARRAY already. ∂01-Mar-88 1325 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Mar 88 13:25:17 PST Received: from Salvador.ms by ArpaGateway.ms ; 01 MAR 88 13:24:51 PST Date: Tue, 1 Mar 88 13:24:19 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: LET-TOP-LEVEL (version 1) In-reply-to: <8803012102.AA21522@mist.UUCP> To: cl-cleanup@sail.stanford.edu Message-ID: <880301-132451-3075@Xerox> First, I would claim that this is a clarification'' as opposed to an addition''. I see no language in CLtL to support the belief that DEFUN can only be used in certain scopes. This reminds me of the debate over whether or not the compiler is required to be reentrant; of course it is, for the same reason that MAP is, for example: it's just another function with a particular contract. In any case, I don't oppose the proposal because I think it's important for implementors to support this style. I have some other comments, though. Why does the proposal not cover all of the defining forms? In particular, why not DEFMACRO? It makes just as much sense for the expansion function to be a closure. Of course, the compiler will not be able to expand uses of that macro later in the same file, since it can't provide the proper lexical environment to the expansion function, but that just means that this style would have to be used in a separate file that is loaded before compilation of uses of the macro. The same goes for the defining forms DEFSTRUCT, DEFTYPE, etc. I not particularly happy with the explicit use of the term top-level'', but until Rob's compiler proposal gets a fair hearing, I don't see any way around it. For the current practice section, Xerox Lisp also implements the proposed behavior. ∂01-Mar-88 1445 CL-Cleanup-mailer function-type-rest-list-element (really array types) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 14:45:22 PST Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 14:07:04 PST Received: from bhopal.lucid.com by edsel id AA06877g; Tue, 1 Mar 88 13:59:18 PST Received: by bhopal id AA06724g; Tue, 1 Mar 88 14:05:25 PST Date: Tue, 1 Mar 88 14:05:25 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803012205.AA06724@bhopal.lucid.com> To: Ram@c.cs.cmu.edu Cc: cl-cleanup@sail.stanford.edu, Moon@scrc-stony-brook.arpa, vanroggen%aitg.decnet@hudson.dec.com In-Reply-To: Ram@C.CS.CMU.EDU's message of Tue, 1 Mar 1988 16:08 EST <RAM.12378932724.BABYL@> Subject: function-type-rest-list-element (really array types) re: My idea is that TYPEP automatically "upgrade" its type argument to the corresponding "implementation type", i.e. a type actually supported by the implementation. . . . There are two problems with respect to typep. Consider arrays made by (MAKE-ARRAY <n> :element-type '<foo>) then: 1. (TYPEP <array> '(ARRAY <foo>)) frequently fails for such arrays 2. (TYPEP (AREF <array> <n>) '<foo>) frequently fails for such arrays These are two separate problems, and as I read your comments about having TYPEP do the "upgrading", I think they apply only to case (1), right? This may be another way of trying to say that (ARRAY FOO) is type equivalent to (ARRAY ,(upgrade array-element-type 'foo)) re: I think that analogies with the FIXNUM/INTEGER are flawed: FIXNUM has is a precisely defined concept within the language: (integer ,most-negative-fixnum ,most-positive-fixnum) See my comments in the previous note about a "pyrrhic success". -- JonL -- ∂01-Mar-88 1515 CL-Cleanup-mailer Compiler cleanup issues, again Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Mar 88 15:15:14 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA24776; Tue, 1 Mar 88 16:15:40 MST Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA06356; Tue, 1 Mar 88 16:15:30 MST From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8803012315.AA06356@orion.utah.edu> Date: Tue, 1 Mar 88 16:15:28 MST Subject: Compiler cleanup issues, again To: smh%franz.uucp@ucbarpa.berkeley.edu, ram@c.cs.cmu.edu, mike%acorn@LIVE-OAK.LCS.MIT.EDU Cc: cl-cleanup@sail.stanford.edu (flame on) If there is not going to be a compiler subcommittee meeting at this month's X3J13 meeting, I think the subcommittee should be officially disbanded. As far as I can tell, we have accomplished nothing at all since November, and nothing has happened lately to convince me that things are going to change. As I have been saying for quite a while now, I think the current trend of tabling small, well-defined proposals while waiting for the Grand Theory of Compilation to be revealed is a mistake -- what ever happened to the divide-and-conquer approach? I don't think any of us have the time to really take charge of the situation, put together a moby proposal that addresses all of the issues, and push it through the full committee. (We've already seen that there is such a diversity among implementations that I find it hard to believe that implementors will be able to agree on *any* Grand Theory.) On the other hand, there does seem to be somewhat more agreement on some of the smaller issues considered individually. (flame off) The cleanup subcommittee seems to be doing a good job of pushing issues through and I think they would be a better chance of getting compiler-related issues resolved than we would, given our track record so far. Perhaps we should try to arrange for an official transfer of responsibilities at the upcoming meeting? -Sandra ------- ∂01-Mar-88 1548 CL-Cleanup-mailer Compiler cleanup issues, again Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 15:48:14 PST Received: ID <RAM@C.CS.CMU.EDU.#Internet>; Tue 1 Mar 88 18:47:54-EST Date: Tue, 1 Mar 1988 18:47 EST Message-ID: <RAM.12378961749.BABYL@> Sender: RAM@λλ From: Ram@C.CS.CMU.EDU To: sandra%orion@λcs.utah.edu (Sandra J Loosemore)λ Cc: cl-cleanup@SAIL.STANFORD.EDU, mike%acorn@LIVE-OAK.LCS.MIT.EDU, smh%franz.uucp@UCBARPA.BERKELEY.EDU Subject: Compiler cleanup issues, again In-reply-to: Msg of 1 Mar 1988 18:15-EST from sandra%orion at cs.utah.edu (Sandra J Loosemore) Well, currently I haven't been to any X3J13 meeting because CMU won't pay for peons to go flying around the country. Now that Scott Fahlman has ceased to be active in X3J13, he has been pusing to have me made the CMU delegate, so I might make it at some future meeting. But I think that the value of in-person meeting time is overrated. What sort of small, well-defined proposals (that have been tabled) do you have in mind? Rob ∂01-Mar-88 1718 CL-Cleanup-mailer Re: Compiler cleanup issues, again Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 1 Mar 88 17:18:14 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA29680; Tue, 1 Mar 88 18:18:51 MST Received: by orion.utah.edu (5.54/utah-1.0-slave) id AA06603; Tue, 1 Mar 88 18:18:47 MST From: sandra%orion@cs.utah.edu (Sandra J Loosemore) Message-Id: <8803020118.AA06603@orion.utah.edu> Date: Tue, 1 Mar 88 18:18:44 MST Subject: Re: Compiler cleanup issues, again To: Ram@c.cs.cmu.edu Cc: cl-cleanup@sail.stanford.edu, mike%acorn@live-oak.lcs.mit.edu, smh%franz.uucp@ucbarpa.berkeley.edu In-Reply-To: Ram@C.CS.CMU.EDU, Tue, 1 Mar 1988 18:47 EST > But I think that the value of in-person meeting time is overrated. Actually, I agree. But there hasn't been anything happening via e-mail or over the telephone, either. > What sort of small, well-defined proposals (that have been tabled) do > you have in mind? I submitted two to the cleanup committee before the November meeting. One was an attempt to specify how top-level forms in a file (such as DEFMACRO or DEFSETF) affect how COMPILE-FILE compiles subsequent forms in the file. At that time, the cleanup committee didn't want to consider compiler-related issues at all, although there did seem to be an overwhelming agreement with the actual content of the proposal. The other proposal tried to specify how REQUIRE works in a little more detail so that it would actually be meaningful to use in specifying inter-file compilation dependencies. On this one, there was a general feeling that PROVIDE and REQUIRE were a poor substitute for a DEFSYSTEM utility. At the November meeting I volunteered to send a draft DEFSYSTEM proposal around to the compiler subcommittee for review (and in fact I have had both documentation and code sitting around for months), but in spite of repeated promises from Steve, our mailing list has never materialized and I don't have e-mail addresses for everybody (where's David Bartley?). > Rob -Sandra ------- ∂01-Mar-88 1749 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 17:49:34 PST Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 17:11:13 PST Received: from bhopal.lucid.com by edsel id AA08004g; Tue, 1 Mar 88 17:00:45 PST Received: by bhopal id AA07266g; Tue, 1 Mar 88 17:06:53 PST Date: Tue, 1 Mar 88 17:06:53 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803020106.AA07266@bhopal.lucid.com> To: pierson@mist Cc: cl-cleanup@sail.Stanford.EDU In-Reply-To: Dan L. Pierson's message of Tue, 01 Mar 88 16:02:35 EST <8803012102.AA21522@mist.UUCP> Subject: Issue: LET-TOP-LEVEL (version 1) re: Problem description: The main defining forms in CLtL do not support defining (as opposed to creating) closures in lexical environments. . . . Rationale: Common Lisp tries to support lexical closures but this support is really confined to anonymous lambdas within other function definitions. This proposal attempts to move lexical closures closer to first-class status in Common Lisp. I don't believe this problem description. In particular, previous discussions on these mailing lists suggested that DEFUN is merely a macro that turns into something like: (setf (symbol-function 'foo) #'(lambda (x y ...) ...)) so that anything said about "anonymous lambdas" should also be equally applicable to "defun"'s. re: Current practice: The above example works in both Ibuki Lisp and Lucid, however only Ibuki Lisp describes (SYMBOL-FUNCTION 'GET-THING) as a closure. In Lucid Common Lisp, *all* functions are "closures". It doesn't serve any purpose to distinguish one which has some captured lexical environment "inside it" from another that doesn't. [However, I recently adduced reasons why it would be profitable to distinguish those that are merely "trampolines" back into the interpreter from the real "compiled functions".] re: Current practice: . . . Both Symbolics and TI are reported to leave GET-THING and FREE-THING as named-lambdas instead of compiling them. At least some persons from Symbolics have agreed that this is a flaw in the particular compiler's techniques -- not a flaw in language design. -- JonL -- ∂01-Mar-88 1830 CL-Cleanup-mailer compiler "clean-up" issues Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 1 Mar 88 18:30:00 PST Date: 1 Mar 1988 21:26-EST Sender: MATHIS@A.ISI.EDU Subject: compiler "clean-up" issues From: MATHIS@A.ISI.EDU To: sandra%orion@CS.UTAH.EDU Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU Cc: smh%franz.uucp@UCBARPA.BERKELEY.EDU Cc: bartley%ti-csl@RELAY.CS.NET Cc: cl-cleanup@SAIL.STANFORD.EDU Message-ID: <[A.ISI.EDU] 1-Mar-88 21:26:26.MATHIS> >At the November meeting I volunteered to send a draft >DEFSYSTEM proposal around to the compiler subcommittee for review (and >in fact I have had both documentation and code sitting around for >months), please bring some printed copies to Palo Alto > but in spite of repeated promises from Steve, our mailing list >has never materialized we'll get Jan Zubkoff to take care of it after Palo Alto > and I don't have e-mail addresses for everybody >(where's David Bartley?). Bartley%TI-CSL@CSNET-RELAY ∂02-Mar-88 0545 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1) Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 2 Mar 88 05:45:25 PST Received: by multimax.ARPA (5.51/25-eef) id AA14503; Wed, 2 Mar 88 08:47:10 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA22737; Wed, 2 Mar 88 08:46:48 EST Message-Id: <8803021346.AA22737@mist.UUCP> To: Pavel.pa%Xerox.COM@multimax Cc: cl-cleanup%sail.stanford.edu@multimax Subject: Re: Issue: LET-TOP-LEVEL (version 1) In-Reply-To: Your message of Tue, 01 Mar 88 13:24:19 -0800. Date: Wed, 02 Mar 88 08:46:45 EST From: Dan L. Pierson <pierson@mist> Date: Tue, 1 Mar 88 13:24:19 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: LET-TOP-LEVEL (version 1) To: cl-cleanup@sail.stanford.edu Please excuse my regrinding of your message where the lines didn't fit after being indented. First, I would claim that this is a clarification'' as opposed to an addition''. I see no language in CLtL to support the belief that DEFUN can only be used in certain scopes. This reminds me of the debate over whether or not the compiler is required to be reentrant; of course it is, for the same reason that MAP is, for example: it's just another function with a particular contract. The CLtL reference is page 66, 5.3 Top-Level Forms: "It is not illegal to use these forms at other than top level, but whether it is meaningful to do so depends on context. Compilers, for example, may not recognize these forms at other than top-level contexts." In any case, I don't oppose the proposal because I think it's important for implementors to support this style. I have some other comments, though. Why does the proposal not cover all of the defining forms? In particular, why not DEFMACRO? It makes just as much sense for the expansion function to be a closure. Of course, the compiler will not be able to expand uses of that macro later in the same file, since it can't provide the proper lexical environment to the expansion function, but that just means that this style would have to be used in a separate file that is loaded before compilation of uses of the macro. The same goes for the defining forms DEFSTRUCT, DEFTYPE, etc. I may have gotten confused here, my thinking was that since MACROLET ignores lexical bindings that DEFMACRO should too. I don't feel strongly about this though. I not particularly happy with the explicit use of the term top-level'', but until Rob's compiler proposal gets a fair hearing, I don't see any way around it. It's the current CLtL language, I'd be happy to see it changed. ∂02-Mar-88 0553 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1) Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 2 Mar 88 05:53:18 PST Received: by multimax.ARPA (5.51/25-eef) id AA14574; Wed, 2 Mar 88 08:55:06 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA22763; Wed, 2 Mar 88 08:54:44 EST Message-Id: <8803021354.AA22763@mist.UUCP> To: Jon L White <edsel!jonl%labrea.Stanford.EDU@multimax> Cc: cl-cleanup%sail.Stanford.EDU@multimax Subject: Re: Issue: LET-TOP-LEVEL (version 1) In-Reply-To: Your message of Tue, 01 Mar 88 17:06:53 -0800. <8803020106.AA07266@bhopal.lucid.com> Date: Wed, 02 Mar 88 08:54:41 EST From: Dan L. Pierson <pierson@mist> Date: Tue, 1 Mar 88 17:06:53 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> To: pierson@mist Cc: cl-cleanup@sail.Stanford.EDU Subject: Issue: LET-TOP-LEVEL (version 1) As usual, please excuse regrinding. re: Problem description: The main defining forms in CLtL do not support defining (as opposed to creating) closures in lexical environments. . . . Rationale: Common Lisp tries to support lexical closures but this support is really confined to anonymous lambdas within other function definitions. This proposal attempts to move lexical closures closer to first-class status in Common Lisp. I don't believe this problem description. In particular, previous discussions on these mailing lists suggested that DEFUN is merely a macro that turns into something like: (setf (symbol-function 'foo) #'(lambda (x y ...) ...)) so that anything said about "anonymous lambdas" should also be equally applicable to "defun"'s. The relevant sentence is on page 67: "Other implementation-dependent bookkeeping actions may be taken as well by DEFUN." re: Current practice: The above example works in both Ibuki Lisp and Lucid, however only Ibuki Lisp describes (SYMBOL-FUNCTION 'GET-THING) as a closure. In Lucid Common Lisp, *all* functions are "closures". It doesn't serve any purpose to distinguish one which has some captured lexical environment "inside it" from another that doesn't. [However, I recently adduced reasons why it would be profitable to distinguish those that are merely "trampolines" back into the interpreter from the real "compiled functions".] I sit corrected, however there appears to be no way in Lucid Common Lisp to inspect or debug a function which has some captured lexical environment to see what the captured environment is so I couldn't find this out. re: Current practice: . . . Both Symbolics and TI are reported to leave GET-THING and FREE-THING as named-lambdas instead of compiling them. At least some persons from Symbolics have agreed that this is a flaw in the particular compiler's techniques -- not a flaw in language design. I agree philosophically, but see page 66, second paragraph on Top-Level Forms. -- JonL -- ∂02-Mar-88 0821 CL-Cleanup-mailer Fair's Fair To: cl-cleanup@SAIL.Stanford.EDU From: Dick Gabriel <RPG@SAIL.Stanford.EDU> Steve Haflich asked me several weeks ago (more than a month ago) to set up cl-compiler and cl-compiler-request, and I did. Here are the current members: smh%franz.uucp@berkeley.edu sandra%orioncs.utah.edu ram@c.cs.cmu.edu mike%acorn@LIVE-OAK.LCS.MIT.EDU Bartley%TI-CSL@RELAY.CS.NET rg@ai.ai.mit.edu vanroggen@hudson.dec.com pierson@multimax.arpa I thought I saw some message announcing its existence from Steve. We should keep in mind that many of us are very busy and cannot devote a tremendous amount of time to X3J13, and we shouldn't find fault when we ourselves can be held up for criticism. -rpg- ∂02-Mar-88 1415 CL-Cleanup-mailer Compiler cleanup issues, again Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 88 14:15:36 PST Received: by ucbarpa.Berkeley.EDU (5.58/1.26) id AA11300; Wed, 2 Mar 88 14:16:58 PST Received: by franz (5.5/3.14) id AA03377; Wed, 2 Mar 88 12:25:27 PST Received: by feast (5.5/3.14) id AA03448; Wed, 2 Mar 88 15:12:55 EST Date: Wed, 2 Mar 88 15:12:55 EST From: franz!feast!smh@ucbarpa.Berkeley.EDU (Steven M. Haflich) Message-Id: <8803022012.AA03448@feast> To: sandra@cs.utah.edu Cc: ram@c.cs.cmu.edu, mike%acorn@live-oak.lcs.mit.edu, cl-cleanup@sail.stanford.edu In-Reply-To: Sandra J Loosemore's message of Tue, 1 Mar 88 16:15:28 MST <8803012315.AA06356@orion.utah.edu> Subject: Compiler cleanup issues, again Hmmm. The murk begins to lift. We *have* had a mailing list since January, courtesy of Gabriel, but it's just become clear that it isn't reaching everyone. I kicked off an inquiry to Gabriel; perhaps he can determine what's wrong. The list is cl-compiler@sail.stanford.edu Anyway, this explains the missing responses to my earlier solicitation about schedules for the Mar 14 week. I did receive replies from Greenblatt and Pierson, but nothing from the rest. I feel strongly that we should meet during the week. Twice would be more productive than once. I'll be in the Bay area from Monday afternoon through Saturday and can be available essentially any time during that span. I just reread your COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS. It laudably clarifies the issues. Nonetheless, if I try to construct particularly perverse examples, I think there are still additional issues upon which this clarification should comment, if only to identify for the portable code writer further things upon which he *cannot* depend. I'll follow with a separate message to keep the administrivia and technical issues separate. ∂02-Mar-88 1614 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1) Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 2 Mar 88 16:12:15 PST Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa11508; 2 Mar 88 21:51 GMT From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK> Date: Wed, 2 Mar 88 21:19:16 gmt Message-Id: <27876.8803022119@aiva.ed.ac.uk> To: jonl <@labrea.stanford.edu:jonl@edsel.uucp>, pierson <@multimax.arpa:pierson@mist.uucp> Subject: Re: Issue: LET-TOP-LEVEL (version 1) Cc: cl-cleanup@sail.stanford.edu ] Date: Tue, 1 Mar 88 17:06:53 PST ] From: Jon L White <jonl%edsel@edu.stanford.labrea> ] Rationale: ] Common Lisp tries to support lexical closures but this support is ] really confined to anonymous lambdas within other function ] definitions. This proposal attempts to move lexical closures closer ] to first-class status in Common Lisp. ] ] I don't believe this problem description. In particular, previous ] discussions on these mailing lists suggested that DEFUN is merely a ] macro that turns into something like: ] ] (setf (symbol-function 'foo) #'(lambda (x y ...) ...)) I basically agree with this point -- that the rationale / problem description is wrong, and for the reason given -- but there is still something there, namely that DEFUN isn't always sufficiently equivalent to such a macro. Some implementations do not expand DEFUN into anything so reasonable, or else define DEFUN as a special form that is not equivalent to the macro expansion. They may thus end up with DEFUN semantics that are different from the semantics of functions produced by the appropriate SETF of SYMBOL-FUNCTION. I would say these implementations are incorrect, because of the description of DEFUN on page 67 of CLtL, where a LAMBDA expression for the function is explicitly given and where it is specified that that function is "defined in the lexical environment in which the DEFUN form was executed", and because the macro definition of a macro implemented as a special form is supposed to be equivalent to the special form definition (CLtL, p. 57), but there are reasons why they may be able to get away with it: (1) the specification of DEFUN is weakened by the discussion of top-level forms on page 66, and (2) the macro equivalence constraint is too weak -- implementations seem to regard it as allowing the special form to make "improvements" that the macro does not. (See the KCL example below.) In addition there is a more general problem about macros that often occurs with defun -- nothing seems to rule out expansions to expresions like (SYSTEM::DO-A-DEFUN '(DEFUN ...)). (See the other example.) Some cleanup issue should deal with the first problem: that top-level forms may not be meaningful in some (unspecified) embedded contexts. It should also address the meaning with respect to lexical context of top-level defining forms other than DEFUN. Nonetheless, the top-level forms in question are all macros, and so macro questions arise as well. The discussion of top-level forms on page 66 of CLtL suggests that compilers may not recognize these forms "properly" in embedded contexts. Nothing [else] in CLtL allows compilers to fail to recognize macros. The general macro issue involved might be the subject of a separate cleanup issue. Specifically, consider the implementation note on page 58. The restriction on what may appear in macro expansions is insufficient to "ensure that the expansion can be processed ... in an implementation- independent manner". But what would be sufficient? A necessary condition is that all implementation-specific special forms be accompanied by equivalent (modulo efficiency and what else?) macro definitions so that any expression can be "fully expanded" so as to contain no implementation-specific special forms. CLtL does require equivalent macros for special form implementations of operations defined as macros in Common Lisp, but does not say anything about other special forms an implementation may use. Such a requirement should be added. However, for sufficiency something must rule out functions of the DO-A-DEFUN sort (special forms in disguise). Perhaps this is being addressed as a compiler issue? --- DEFUN Examples --- 1. PopLog Common Lisp. Here the macro expansion is rather unhelpful and, indeed, not equivalent to a SETF of SYMBOL-FUNCTION with the appropriate LAMBDA expression. A DEFUN is always with respect to the null lexical environment. Note that PopLog always compiles. Thus the statement on page 66 that "compilers may not recognize these forms properly in other than top-level contexts" may be cited to justify its behavior. A SETF of SYMBOL function does work correctly. == (macroexpand-1 '(defun f (x) x)) (SYSTEM::DEFUN '(F (X) X)) T 2. KCL. Although KCL does have a macro of the kind you suggest, the expansion is not what DEFUN actually does. [Nonetheless, DEFUN inside LET does work as desired (closure over the environment).] KCl (Kyoto Common Lisp) June 3, 1987 >(macroexpand-1 '(defun f (x) x)) (PROGN (SETF (SYMBOL-FUNCTION 'F) #'(LAMBDA (X) (BLOCK F X))) 'F) T >(eval *) F >#'f (LAMBDA-CLOSURE () () () (X) (BLOCK F X)) >(defun f (x) x) F >#'f (LAMBDA-BLOCK F (X) X) DEFUN in Gould CL has similar effects, but the macroexpansion is so long that I won't show it here. Then there are other systems (e.g., VAX Lisp v2.1) where the differences between the effects of the macro expansion and the DEFUN are insignificant (but still present). Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton ∂02-Mar-88 1757 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 2 Mar 88 17:57:09 PST Received: by labrea.Stanford.EDU; Wed, 2 Mar 88 17:17:36 PST Received: from bhopal.lucid.com by edsel id AA13022g; Wed, 2 Mar 88 15:35:33 PST Received: by bhopal id AA10857g; Wed, 2 Mar 88 15:41:45 PST Date: Wed, 2 Mar 88 15:41:45 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803022341.AA10857@bhopal.lucid.com> To: pierson@mist Cc: cl-cleanup@sail.Stanford.EDU In-Reply-To: Dan L. Pierson's message of Wed, 02 Mar 88 08:54:41 EST <8803021354.AA22763@mist.UUCP> Subject: Issue: LET-TOP-LEVEL (version 1) re: [re-grinding] Good. I do it too. The only reason I mention it here is to ask anyone else who cares about it to raise their objections now, or forever ... re: ... so that anything said about "anonymous lambdas" should also be equally applicable to "defun"'s. The relevant sentence is on page 67: "Other implementation-dependent bookkeeping actions may be taken as well by DEFUN." I don't believe that the sentence about "Other implementation-dependent ..." negates the understanding of DEFUN as basically a rewrite to (setf (symbol-function 'foo) #'(lambda (x y ...) ...)) If anything needs "clarifying" around this topic, perhaps it should be just that. In particular, the sorts of things I imagine would legitimately fall into "Other implementation-dependent ..." are items like hooks for cross-referencing programs, file-indexing programs, extensions the normal error-signalling upon redefinition (to facilitate "patch" files etc). But nothing that would change the underlying equation of DEFUN's with named lambda functions. [Now, the corresponding issue re DEFMACRO isn't so nice. I hope some excuse can be found to do the simple thing with it too, rather than requiring some singular behaviour with regard to capturing lexical environments. But this is another issue, another can of worms.] -- JonL -- P.S. Apparently the return address in your messages isn't good enough to be used through Labrea.Stanford.edu; do you have another? ∂02-Mar-88 2206 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1) Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 2 Mar 88 22:06:29 PST Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa11922; 2 Mar 88 22:39 GMT From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK> Date: Wed, 2 Mar 88 22:38:43 gmt Message-Id: <28475.8803022238@aiva.ed.ac.uk> To: cl-cleanup@sail.stanford.edu, pierson <@multimax.arpa:pierson@mist.uucp> Subject: Re: Issue: LET-TOP-LEVEL (version 1) ] Date: Wed, 02 Mar 88 08:46:45 EST ] From: "Dan L. Pierson" <pierson@mist> I apologize if my messages on this topic arrive at a time when they are no longer relevant, something certainly possible given the trans- Atlantic time delay. Anyway... ] I may have gotten confused here, my thinking was that since MACROLET ] ignores lexical bindings that DEFMACRO should too. I don't feel ] strongly about this though. Just for a complete set of references: DEFMACRO is specified to define the expansion function in the global (i.e. null lexical) environment on page 145. Jeff Dalton, JANET: J.Dalton@uk.ac.ed AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton ∂03-Mar-88 0825 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1) Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 3 Mar 88 08:25:05 PST Received: by multimax.ARPA (5.51/25-eef) id AA24445; Thu, 3 Mar 88 11:26:43 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA24921; Thu, 3 Mar 88 11:26:23 EST Message-Id: <8803031626.AA24921@mist.UUCP> To: Jon L White <edsel!jonl%labrea.Stanford.EDU@Multimax> Cc: cl-cleanup%sail.Stanford.EDU@Multimax Subject: Re: Issue: LET-TOP-LEVEL (version 1) In-Reply-To: Your message of Wed, 02 Mar 88 15:41:45 -0800. <8803022341.AA10857@bhopal.lucid.com> Date: Thu, 03 Mar 88 11:26:21 EST From: Dan L. Pierson <pierson@mist> re: ... so that anything said about "anonymous lambdas" should also be equally applicable to "defun"'s. The relevant sentence is on page 67: "Other implementation-dependent bookkeeping actions may be taken as well by DEFUN." I don't believe that the sentence about "Other implementation-dependent ..." negates the understanding of DEFUN as basically a rewrite to (setf (symbol-function 'foo) #'(lambda (x y ...) ...)) If anything needs "clarifying" around this topic, perhaps it should be just that. In particular, the sorts of things I imagine would legitimately fall into "Other implementation-dependent ..." are items like hooks for cross-referencing programs, file-indexing programs, extensions the normal error-signalling upon redefinition (to facilitate "patch" files etc). I have no argument about "the essence of DEFUN", my point was that the potential existence of this sort of bookkeeping activity prevents me simply defining my own macro which expands to SETF of SYMBOL-FUNCTION and using it instead of DEFUN. A couple of people seriously proposed that alternative in the common-lisp discussion on this topic last July. ∂03-Mar-88 1134 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Mar 88 11:34:39 PST Received: from Salvador.ms by ArpaGateway.ms ; 03 MAR 88 10:45:04 PST Date: Thu, 3 Mar 88 10:44:43 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: LET-TOP-LEVEL (version 1) In-reply-to: <28475.8803022238@aiva.ed.ac.uk> To: cl-cleanup@sail.stanford.edu Message-ID: <880303-104504-6403@Xerox> Jeff says: Just for a complete set of references: DEFMACRO is specified to define the expansion function in the global (i.e. null lexical) environment on page 145.'' Right, but I thought that this was generally recognized to be an error, a misunderstanding. There is no reason to restrict DEFMACRO in this way. Dan says: I may have gotten confused here, my thinking was that since MACROLET ignores lexical bindings that DEFMACRO should too. I don't feel strongly about this though.'' MACROLET could also use lexical bindings, but it would lead to difficulties for the compiler. That is, any use of the macro would have to be expanded each time the form is evaluated. Thus, the uses would have to be interpreted, not compiled. I don't recommend this to anyone, but it could be done, I suppose. The real difference between DEFMACRO and MACROLET is that the expansion functions produced by the former have indefinite extent, while those produced by the latter have only dynamic extent, if that. It thus makes sense that they might have different environment behavior. Pavel ∂03-Mar-88 1204 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Mar 88 12:03:50 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 355463; Thu 3-Mar-88 15:03:25 EST Date: Thu, 3 Mar 88 15:03 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Re: Issue: LET-TOP-LEVEL (version 1) To: Pavel.pa@Xerox.COM cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <880303-104504-6403@Xerox> Message-ID: <19880303200314.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Thu, 3 Mar 88 10:44:43 PST From: Pavel.pa@Xerox.COM The real difference between DEFMACRO and MACROLET is that the expansion functions produced by the former have indefinite extent, while those produced by the latter have only dynamic extent, if that. That can't be quite right, since (defun foo (x) (macrolet ((baz (x y) (print (baz ,x ,y expanded)) (list ,x ,y))) (lambda (z) (baz x z)))) (setq bar (foo 1)) (funcall bar 3) => (1 3) and in an implementation that has an interpreter that doesn't preprocess [not ours], the expander function for baz would not be called until after foo had returned. Thus the expander function must have indefinite extent. The real difference between DEFMACRO and MACROLET, I think, is that in DEFMACRO there is a clear separation between the lexical environment of definition and the lexical environment of use, but in MACROLET the use environment is always nested inside the definition environment. However, that's not too relevant. In a compiler or an interpreter that preprocesses, the definition environment has not even been created at the time the expander has to be called. This is quite clear for MACROLET. For DEFMACRO, it depends on what the granularity for preprocessing is, but with the usual model of file compilation, I think DEFMACRO has the same issue. Think about this nonsensical program: (let ((x (big-computation-that-returns-22/7))) (defmacro foo (y) (list ,x ,y)) (defun bar (z) (foo (1+ z)))) (bar 2) => (22/7 3) if it evaluates to anything, but how could the compiler know that? ∂03-Mar-88 1227 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Mar 88 12:26:53 PST Received: from Salvador.ms by ArpaGateway.ms ; 03 MAR 88 12:16:31 PST Date: Thu, 3 Mar 88 12:15:58 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: LET-TOP-LEVEL (version 1) In-reply-to: <19880303200314.2.MOON@EUPHRATES.SCRC.Symbolics.COM> To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Cc: cl-cleanup@SAIL.STANFORD.EDU Message-ID: <880303-121631-6583@Xerox> Dave says: Think about this nonsensical program: (let ((x (big-computation-that-returns-22/7))) (defmacro foo (y) (list ,x ,y)) (defun bar (z) (foo (1+ z)))) (bar 2) => (22/7 3) if it evaluates to anything, but how could the compiler know that?'' This is just the issue that I addressed in my first message on this topic. When you define a macro with a non-null closed-over environment, it is clear that the compiler cannot know how to evaluate the expansion function. It is therefore reasonable to assume that the compiler cannot expand uses of that macro during the same compilation that encounters the DEFMACRO form. If you want a macro like this, you must put the DEFMACRO in a separate file, compile and load that file, and then compile any uses of the macro. This may be very reasonable for some applications. In particular, it can be used in the same Scheme-style way that uses a lexical variable to carry module-global state. For example, it might be reasonable for DEFSTRUCT to be defined in this way, with the DEFMACRO for DEFSTRUCT and the DEFUN's for the other structure-handling subprimitives all within the same non-global lexical environment: (let ((destruct-database ...)) (defmacro defstruct ...) (defun tell-me-about-this-structure-type ...) ...other code that doesn't use DEFSTRUCT...) This style doesn't disgust me and I see no reason not to support it. Pavel ∂03-Mar-88 1453 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 14:53:52 PST Received: by labrea.Stanford.EDU; Thu, 3 Mar 88 14:15:37 PST Received: from bhopal.lucid.com by edsel id AA16357g; Thu, 3 Mar 88 13:41:55 PST Received: by bhopal id AA13368g; Thu, 3 Mar 88 13:48:03 PST Date: Thu, 3 Mar 88 13:48:03 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803032148.AA13368@bhopal.lucid.com> To: jeff%aiva.edinburgh.ac.uk@nss.cs.ucl.ac.uk Cc: cl-cleanup@sail.Stanford.EDU, pierson@multimax In-Reply-To: Jeff Dalton's message of Wed, 2 Mar 88 21:19:16 gmt <27876.8803022119@aiva.ed.ac.uk> Subject: Issue: LET-TOP-LEVEL (version 1) KCL's variation on DEFUN may not in fact be significant; it appears as though the special-form version is producing an "optimized" form of closure, which "knows" that it didn't capture any lexical environment. [But I don't really know about this -- someone more familiar with KCL should comment further.] The "top-level" issues, while impacting DEFUN usage, shouldn't be an issue in DEFUN semantics (or at least, I don't think so). As you suggest, the notion of "top-level" needs to be treated in its own right; I hope the inability to find a complete solution for it won't prevent taking partial, useful steps in the right direction. Perhaps the most disturbing underlying problem is the failure of some implementation to provide meaningful expansions for CLtL's special forms. I certainly wouldn't expect such macroexpansions to be limited to the documented CLtL functions, but having the meaning of them be hidden underneath an "internal" function is defeating of the reason for having the macro in the first place. I'm referring to an expansion like the example you gave ("special forms in disguise"): (DEFUN FOO ...) ==> (SYSTEM::DO-A-DEFUN '(DEFUN FOO ...)) It seems to me that many of the special forms could be documented in such a way that *if* one were to use the obvious macro expansions on them, then at worst he would miss out on some little niceity of the programming environment; he should not be subject to major semantic difficulties. E.g., to the degree that (SYSTEM::DO-A-DEFUN '(DEFUN ...)) does something substanially different from (SETF (SYMBOL-FUNCTION FOO) #'(LAMBDA ...)) it should only be in the realm of optional, informational features. This kind of constraint would allow implementational flexibility while permitting something useful to be said about "Standards". -- JonL -- ∂03-Mar-88 1456 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 14:55:55 PST Received: by labrea.Stanford.EDU; Thu, 3 Mar 88 14:17:36 PST Received: from kent-state.lucid.com by edsel id AA16479g; Thu, 3 Mar 88 14:14:12 PST Received: by kent-state id AA26244g; Thu, 3 Mar 88 14:19:49 PST Date: Thu, 3 Mar 88 14:19:49 PST From: Eric Benson <edsel!eb@labrea.Stanford.EDU> Message-Id: <8803032219.AA26244@kent-state.lucid.com> To: Pavel.pa@xerox.com Cc: Moon@stony-brook.scrc.symbolics.com, cl-cleanup@sail.stanford.edu In-Reply-To: Pavel.pa@Xerox.COM's message of Thu, 3 Mar 88 12:15:58 PST <880303-121631-6583@Xerox> Subject: Issue: LET-TOP-LEVEL (version 1) I concur with Pavel. I have written code that does exactly this sort of thing. (Say what you want about this style). This creates a constant vector of character names, used by NAME-CHAR and CHAR-NAME. The two functions share a single structure, which is not stored in a global variable. Notice I ended up using SETF of MACRO-FUNCTION because of problems with DEFMACRO. (let ((char-name-table (make-array (1+ (char-code #\Space)) :initial-element nil))) (flet ((add-char-name (code name) "Enter a new name for this character code" (let* ((old-entry (svref char-name-table code)) (new-entry (cond ((null old-entry) name) ((consp old-entry) (cons name old-entry)) (t (list name old-entry))))) (setf (svref char-name-table code) new-entry)))) (flet ((add-char-names (code namelist) "Add names for the character codes in sequence from this one" (dolist (name namelist) (add-char-name code name) (incf code)))) ;;The standard ASCII names (add-char-names 0 '("NUL" "SOH" "STX" "ETX" "EOT" "ENQ" "ACK" "BEL" "BS" "HT" "NL" "VT" "NP" "CR" "SO" "SI" "DLE" "DC1" "DC2" "DC3" "DC4" "NAK" "SYN" "ETB" "CAN" "EM" "SUB" "ESC" "FS" "GS" "RS" "US" "SP")) ;;Other names for the same characters ;;The last name added is the one returned by CHAR-NAME (add-char-names 7 '("Bell" "Backspace" "Tab" "Linefeed")) (add-char-name 0 "Null") (add-char-name 12 "Page") (add-char-name 13 "Return") (add-char-name 32 "Space") (add-char-name 10 "Newline"))) ;;Bug in Common Lisp definition makes this not work: ;;(defmacro char-name-table-ref (code) ...) (setf (macro-function 'char-name-table-ref) #'(lambda (form env) (declare (ignore env)) (let ((code (second form))) (svref ',char-name-table ,code))))) ∂03-Mar-88 2155 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 3 Mar 88 21:54:56 PST Received: by labrea.Stanford.EDU; Thu, 3 Mar 88 21:16:22 PST Received: from bhopal.lucid.com by edsel id AA17397g; Thu, 3 Mar 88 17:45:37 PST Received: by bhopal id AA14256g; Thu, 3 Mar 88 17:51:53 PST Date: Thu, 3 Mar 88 17:51:53 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803040151.AA14256@bhopal.lucid.com> To: Moon@stony-brook.scrc.symbolics.com, Pavel.pa@xerox.com Cc: cl-cleanup@sail.stanford.edu In-Reply-To: David A. Moon's message of Thu, 3 Mar 88 15:03 EST <19880303200314.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Issue: LET-TOP-LEVEL (version 1) re: (let ((x (big-computation-that-returns-22/7))) (defmacro foo (y) (list ,x ,y)) (defun bar (z) (foo (1+ z)))) (bar 2) => (22/7 3) if it evaluates to anything, but how could the compiler know that? This is perhaps a bad example of what you are trying to illustrate, for it needlesly violates the "global environment" constraint of CLtL p145. Since you are merely trying to show up a flaw in the "pre-processor" style of evaluators (that pervasively expand macros before beginning evaluation), you could adequately point that out with: (let ((x (big-computation-that-returns-22/7))) (defmacro foo (y) (quote ,y)) ;; or, use variant: (eval '(defmacro foo (y) (quote ,y))) (print x) (defun bar (z) (foo (1+ z)))) [The problem is that the "call" to FOO inside BAR is resolved and macro- expanded during the pre-process phase, at which time the "wrong" decision will be made regarding it; during the evaluation phase, FOO will have the macro definition of (quote ,y) installed, but that is too late]. This also illustrates a problem with current compilation techniques (or, rather, with the current lack of a definition for "top-level"), but without involving the macro-expansion function in a lexical-capturing situation. On the other hand, if we relenquish the strictures of CLtL p145 (which some implementations do), then I don't see any problem with the following example: ;;; Beginning of file (eval-when (eval compile) (let ((cnt 0)) (defmacro do-it-once (x) (incf cnt) (PRINT ,x)) (defmacro total-count () ',cnt)) ) (defun foo (x) (do-it-once x) (do-it-once x) (total-count)) ;;; End of file So I'm wondering what is meant by the claim: "When you define a macro with a non-null closed-over environment, it is clear that the compiler cannot know how to evaluate the expansion function. It is therefore reasonable to assume that the compiler cannot expand uses of that macro during the same compilation that encounters the DEFMACRO form. If you want a macro like this, you must put the DEFMACRO in a separate file, compile and load that file, and then compile any uses of the macro." If this claim was intended to be limited to "solitary forms", as opposed to files, then the following pathelogical function should be considered: (defun tryit () (compiler-let ((cnt 0)) (compiler-let ((throw-away (progn (defmacro do-it-once (x) (incf cnt) (QUOTE ,x)) (defmacro total-count () (QUOTE ,cnt)) t))) (defun foo (x) (do-it-once x) (do-it-once x) (total-count))))) I can make some sense of this claim if I make a lot of presumptions about the notion of "top-level"; but this is still a murky area ("top-level"). For example, if the notion of top level "passes through" LET as well as through COMPILER-LET, then the claim makes enough sense to be discussed; and in that discussion, I would offer rebutting cases similar to the ones above. -- JonL -- ∂04-Mar-88 0932 CL-Cleanup-mailer Re: Compiler cleanup issues, again Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Mar 88 09:32:20 PST Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAR 88 09:32:39 PST Date: 4 Mar 88 09:32 PST From: Masinter.pa@Xerox.COM Subject: Re: Compiler cleanup issues, again In-reply-to: sandra%orion@cs.utah.edu (Sandra J Loosemore)'s message of Tue, 1 Mar 88 16:15:28 MST To: sandra%orion@cs.utah.edu cc: smh%franz.uucp@ucbarpa.berkeley.edu, ram@c.cs.cmu.edu, mike%acorn@LIVE-OAK.LCS.MIT.EDU, cl-cleanup@sail.stanford.edu Message-ID: <880304-093239-8035@Xerox> Sandra, I agree with you that if the compiler committee can't revive itself we should take some more drastic action. Whether the cleanup committee does it or another, new committee, (e.g., with you as chair), following the same model of cleanup is less clear to me. The problem with most of the proposals is that many of them require the introduction of a new computational model for Common Lisp, with the following attributes: * clear definitions and descriptions of the relationships between read-time, macro-expansion-time, lexical-analysis-time (compilation), and execution-time * a clear(er) distinction between top-level and non-top-level * the semantics of a "file" vs the interactive top level (read-eval-print) loop * a model for errors which is more fine grained than the current "is an error", "signals an error" and "must" * a model for the semantics of declarations The cleanup committee's proposal format and discussion mechanism isn't well suited for concept definition. Given an accepted computational model, we can consider, as cleanups, various changes to Common Lisp to bring things more in line with that computational model. Perhaps it would help to try to separate out the concept definition from cleanup proposals. If previous experience holds, it may be that there will be iterations in the concept definitions as various cleanup proposals are discussed. My recollection is that "RAM's compiler proposal" combines both concept definition and also proposals for changes to the language. ∂04-Mar-88 0940 CL-Cleanup-mailer Re: compiler-warning-break Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Mar 88 09:40:17 PST Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAR 88 09:41:04 PST Date: 4 Mar 88 09:40 PST From: Masinter.pa@Xerox.COM Subject: Re: compiler-warning-break In-reply-to: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>'s message of 23 Feb 88 14:06:00 EDT To: vanroggen%aitg.decnet@hudson.dec.com cc: cl-cleanup@Sail.stanford.edu Message-ID: <880304-094104-8049@Xerox> Am I correct in reading your message ("As it stands we must oppose the proposal"), that you feel the proposal writeup is unclear, and that you would prefer to have a greater distinction between those errors for which *break-on-warnings* have effect and those it does not? (Your example, (EVAL-WHEN (COMPILE) (PRINT (+ 3 'A))) , by the way, is not affected by *break-on-warnings*.) My impression of the original intent is that the proposal writer very much wanted *break-on-warnings* to cause a break "if the compiler happens to see a variable that was bound but was unused", or other such anomolies. However, this proposal was made before there had been more work on the signal system. It might be more useful to arrive at a way that environment programs can consistently interact with the compiler using well-defined signals rather than the cruder *break-on-warnings* mechanism (which may well be obsolete.) Do you think such a proposal be more suitable? ∂04-Mar-88 1052 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Mar 88 10:52:06 PST Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAR 88 10:52:41 PST Date: Fri, 4 Mar 88 10:52:27 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: LET-TOP-LEVEL (version 1) In-reply-to: <8803040151.AA14256@bhopal.lucid.com> To: Jon L White <edsel!jonl@labrea.Stanford.EDU> Cc: cl-cleanup@sail.stanford.EDU Message-ID: <880304-105241-8203@Xerox> I'm completely lost by your message. My point had nothing to do with top-level forms at all. It was simply making a case for allowing DEFMACRO-defined expansion functions to make use of their lexical environment. Pavel ∂04-Mar-88 1140 CL-Cleanup-mailer Cleanup subcommittee meeting, Tuesday 15 March, 9:00-12:00 Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Mar 88 11:40:35 PST Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAR 88 11:32:47 PST Date: 4 Mar 88 11:31 PST From: Masinter.pa@Xerox.COM Subject: Cleanup subcommittee meeting, Tuesday 15 March, 9:00-12:00 To: CL-Cleanup@sail.stanford.edu, vanroggen%aitg.decnet@hudson.dec.com cc: Masinter.pa@Xerox.COM Message-ID: <880304-113247-8304@Xerox> The cleanup subcommittee will meet at Xerox PARC Tuesday 15 March, 9:00-12:00. If you've not been here before, the address is 3333 Coyote Hill Road Palo Alto, CA 94304 It is at the corner of Coyote Hill and Hillview, near the corner of Page Mill Road and Foothill Expressway. My phone number is (415) 494-4365. I propose for the agenda that we take the list of current open issues (i.e., the ones in the "in discussion" list) and spend a maximum of 5 minutes each seeing who, if anyone, has some comment or opinion on the issue. I think we will want to also reserve 30 minutes to talk about the schedule for dealing with issues. ∂04-Mar-88 1304 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 4 Mar 88 13:02:12 PST Received: by labrea.Stanford.EDU; Fri, 4 Mar 88 12:23:57 PST Received: from bhopal.lucid.com by edsel id AA22090g; Fri, 4 Mar 88 12:50:24 PST Received: by bhopal id AA17139g; Fri, 4 Mar 88 12:56:40 PST Date: Fri, 4 Mar 88 12:56:40 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803042056.AA17139@bhopal.lucid.com> To: Pavel.pa@xerox.com Cc: cl-cleanup@sail.stanford.edu In-Reply-To: Pavel.pa@Xerox.COM's message of Fri, 4 Mar 88 10:52:27 PST <880304-105241-8203@Xerox> Subject: Issue: LET-TOP-LEVEL (version 1) You were in the "TO:" line of my reply to Moon because he was commenting on some distinction you were making between MACROLET and DEFMACRO. The issue led into the problems of a compiler treating forms like DEFMACRO "specially" at toplevel. I took it for granted that we all prefer to have the restriction on defmacro expansion functions removed. -- JonL -- ∂04-Mar-88 1414 CL-Cleanup-mailer Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Mar 88 14:13:57 PST Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAR 88 13:53:03 PST Date: 4 Mar 88 13:52 PST From: Masinter.pa@Xerox.COM Subject: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT In-reply-to: Pavel.pa's message of Fri, 4 Mar 88 10:52:27 PST To: cl-cleanup@sail.stanford.EDU Message-ID: <880304-135303-8627@Xerox> I'd given a separate name, DEFMACRO-BODY-LEXICAL-ENVIRONMENT, to the issue of the lexical environment of DEFMACRO. I think it is related to, but separate from, the LET-TOP-LEVEL issue. LET-TOP-LEVEL is (from my perspective) a clarification, while DEFMACRO-BODY-LEXICAL-ENVIRONMENT is a proposal for a change. I think we are in general agreement about LET-TOP-LEVEL with the only discussion being wording (is this a "change" or a "clarification", etc., ) which can probably be finessed. DEFMACRO-BODY-LEXICAL-ENVIRONMENT has more problems, because we lack good definitions the terms involved in giving a precise definition of when such lexical environments can be used. ∂06-Mar-88 1148 CL-Cleanup-mailer Re: Issue: LET-TOP-LEVEL (version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 88 11:48:05 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 356997; Sun 6-Mar-88 14:47:53 EST Date: Sun, 6 Mar 88 14:47 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Re: Issue: LET-TOP-LEVEL (version 1) To: Pavel.pa@Xerox.COM cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <880303-121631-6583@Xerox> Message-ID: <19880306194744.4.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Thu, 3 Mar 88 12:15:58 PST From: Pavel.pa@Xerox.COM Dave says: Think about this nonsensical program: (let ((x (big-computation-that-returns-22/7))) (defmacro foo (y) (list ,x ,y)) (defun bar (z) (foo (1+ z)))) (bar 2) => (22/7 3) if it evaluates to anything, but how could the compiler know that?'' This is just the issue that I addressed in my first message on this topic. When you define a macro with a non-null closed-over environment, it is clear that the compiler cannot know how to evaluate the expansion function. It is therefore reasonable to assume that the compiler cannot expand uses of that macro during the same compilation that encounters the DEFMACRO form. If you want a macro like this, you must put the DEFMACRO in a separate file, compile and load that file, and then compile any uses of the macro. This may be very reasonable for some applications. Right. The problem is, do you really want the definition of Common Lisp to say that a DEFMACRO defines a macro that can be used in the same compilation "sometimes"? "Sometimes" means it can be used if the body of the macro doesn't reference any captured free identifiers, but not if it does, unless the use is in a context where expansion happens at load time instead of compile time. Ick. I'm fairly sure that we went through this line of reasoning in 1983 or so, and that's what led to the present restriction in the first paragraph on CLtL page 145, as the lesser of two evils. This style [captured free identifiers referenced in macro expander functions] doesn't disgust me and I see no reason not to support it. It doesn't disgust me either. The problem is the inconsistency you get when a language supports both that style and the style of putting macro definitions in the same file as macro invocations. This problem is compounded by Common Lisp's present vague semantics of compilation, but I think even with a crisp semantics of compilation, it would be a problem; I might be wrong about that, depending on what the crisp semantics said about "top level." I'd rather not outlaw either style, but so far I don't see how to make them coexist. I would not support changing Common Lisp incompatibly to add the one style at the expense of outlawing the other, just because I think incompatible changes are rarely warranted at this stage in Common Lisp's life. ∂06-Mar-88 1203 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 88 12:02:42 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357003; Sun 6-Mar-88 15:02:18 EST Date: Sun, 6 Mar 88 15:02 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: LET-TOP-LEVEL (version 1) To: Jon L White <edsel!jonl@labrea.Stanford.EDU> cc: Pavel.pa@xerox.com, cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8803040151.AA14256@bhopal.lucid.com> Message-ID: <19880306200213.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Thu, 3 Mar 88 17:51:53 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> re: (let ((x (big-computation-that-returns-22/7))) (defmacro foo (y) (list ,x ,y)) (defun bar (z) (foo (1+ z)))) (bar 2) => (22/7 3) if it evaluates to anything, but how could the compiler know that? This is perhaps a bad example of what you are trying to illustrate, for it needlesly violates the "global environment" constraint of CLtL p145. On the contrary, violation of that constraint was precisely the topic I was trying to illustrate. Removal of that constraint was the subject under discussion. Since you are merely trying to show up a flaw in the "pre-processor" style of evaluators (that pervasively expand macros before beginning evaluation), That is not at all what I was trying to do. You completely missed the point. However, some of what you then went on to point out is worth discussing; see below. For more on the first point, see the message I just sent to Pavel cc to CL-Cleanup. .... On the other hand, if we relenquish the strictures of CLtL p145 (which some implementations do), then I don't see any problem with the following example: ;;; Beginning of file (eval-when (eval compile) (let ((cnt 0)) (defmacro do-it-once (x) (incf cnt) (PRINT ,x)) (defmacro total-count () ',cnt)) ) (defun foo (x) (do-it-once x) (do-it-once x) (total-count)) ;;; End of file This works because the variable named cnt is only referenced at compile time. In a more complex case, such as others suggested earlier, where some data structure was needed at run time too, this type of approach would not work, or at least it's not clear that it would work. After the problem of the conflict between the lexical environment of the macro invocation and the lexical environment of the macro definition is resolved, e.g. with Kohlbecker's scheme or one of the more recent similar schemes, references to the compile time variable could be incorporated into code resulting from macro expansion, and we would need to make sure that the semantics of compilation and loading properly preserved the identity of that variable binding. An even weirder case would exist if you had said (eval-when (eval load compile) ...), which would seem quite reasonable to most users, and would be necessary if cnt had been accessed by any defuns (in addition to defmacros). The eval-when would evaluate its body twice, once at compile time, and again at load time, creating two distinct variables named cnt. Now the defuns would reference one variable and the defmacros would reference the other. The point is that this kind of construction works fine when interpreted, but does not work when compiled (to a file). We want to minimize the semantic differences between those two ways of executing a program. So I'm wondering what is meant by the claim: "When you define a macro with a non-null closed-over environment, it is clear that the compiler cannot know how to evaluate the expansion function. It is therefore reasonable to assume that the compiler cannot expand uses of that macro during the same compilation that encounters the DEFMACRO form. If you want a macro like this, you must put the DEFMACRO in a separate file, compile and load that file, and then compile any uses of the macro." You are correct in (implicitly) pointing out that this claim of Pavel's should have been limited to the case where the non-null closed-over environment (really the captured free identifiers) came from a load-time binding rather than a compile-time binding. Throwing in an eval-when compile (and not load) eliminates the issue by eliminating the magic two-phase evaluation that the compiler does. If this claim was intended to be limited to "solitary forms", as opposed to files, then the following pathelogical function should be considered: (defun tryit () (compiler-let ((cnt 0)) (compiler-let ((throw-away (progn (defmacro do-it-once (x) (incf cnt) (QUOTE ,x)) (defmacro total-count () (QUOTE ,cnt)) t))) (defun foo (x) (do-it-once x) (do-it-once x) (total-count))))) I don't understand how this is relevant, since compiler-let is an operation on dynamic variables, not lexical variables. I can make some sense of this claim if I make a lot of presumptions about the notion of "top-level"; but this is still a murky area ("top-level"). Precisely. See my message to Pavel cc to CL-Cleanup. ∂06-Mar-88 1230 CL-Cleanup-mailer Not about Issue: LET-TOP-LEVEL (version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 88 12:30:28 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357014; Sun 6-Mar-88 15:29:39 EST Date: Sun, 6 Mar 88 15:29 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Not about Issue: LET-TOP-LEVEL (version 1) To: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK> cc: Jon L White <jlw@SAIL.STANFORD.EDU>, pierson <pierson%mist@MULTIMAX.ARPA>, cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <27876.8803022119@aiva.ed.ac.uk> Message-ID: <19880306202933.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 2 Mar 88 21:19:16 gmt From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK> I've extracted from this message a side-discussion, about the meaning of Common Lisp's specification that except for a few primitive special forms, all special forms are really macros that expand into something other than special forms. Some implementations do not expand DEFUN into anything so reasonable, or else define DEFUN as a special form that is not equivalent to the macro expansion. They may thus end up with DEFUN semantics that are different from the semantics of functions produced by the appropriate SETF of SYMBOL-FUNCTION. I would say these implementations are incorrect, because of the description of DEFUN on page 67 of CLtL, where a LAMBDA expression for the function is explicitly given and where it is specified that that function is "defined in the lexical environment in which the DEFUN form was executed", and because the macro definition of a macro implemented as a special form is supposed to be equivalent to the special form definition (CLtL, p. 57).... ....In addition there is a more general problem about macros that often occurs with defun -- nothing seems to rule out expansions to expresions like (SYSTEM::DO-A-DEFUN '(DEFUN ...)). Right. I've long felt that what CLtL says on page 57 is bankrupt. More politely, it sounded like a nice idea, but when it comes to implement it, you realize that the language does not contain all the primitives needed to implement these macro expansions in a way that can truly be understood by a portable program-understanding program. Furthermore, as a practical matter it's unlikely that the implementations can all agree with each other on the semantics of things like DEFUN at this level of detail, because this impinges on the program development environment; it's outside the domain of the language proper. I think it would have been smarter to have more special forms. It's easier to write a portable program-understanding program that recognizes DEFUN, than to write one that recognizes the zillions of different things that DEFUN might macroexpand into. Keeping the interface in terms defined by CLtL ensures that the semantics that the program-understanding program needs to be aware of are visible, and the program development environment semantics that it's not interested in are kept out of the way, rather than become visible as function calls to implementation dependent functions. Alternatively, we could have made a clean separation between the language and the program-development environment, and defined as part of the language all the hooks for the program-development environment. Then we could have precisely specified the expansion of all these macros; not just said "implementors are encouraged", but specified precisely what the macros do. For example, we could have required DEFUN to be implemented exactly as (defmacro defun (name lambda-list &body declarations-and-forms &environment env) (multiple-value-bind (declarations documentation body) (parse-declarations declarations-and-forms env) (progn (program-development-environment:begin-definition ',name 'function) (setf (symbol-function ',name) (function (lambda ,lambda-list (declare (name ,name)) (declare (documentation ,documentation)) ,@declarations ,@body))) (setf (documentation ',name 'function) ,documentation) (compiler:notice-function-definition ,name ,lambda-list) (program-development-environment:end-definition ',name 'function) ',name))) Note all the things here that aren't in Common Lisp currently. I don't guarantee that deeper thought wouldn't change the above expansion. I think the above alternative approach would produce, in the end, a better language. However, I suspect the amount of work required to get there would be impractically large for either the present organizational structure or the organizational structure that originally defined Common Lisp. A place where we went wrong in designing Common Lisp was to think that the problem in writing a program-understanding program was in making it understand all the special forms, and in thinking that that was a syntactic problem, because special forms have idiosyncratic syntax. It's true that it takes some code to understand all the special forms. But that's just syntax, and it's easy. The real issue is idiosyncratic semantics, and minimizing idiosyncratic syntax does nothing to help with that problem, and in fact makes it worse by obscuring it and by leading people to think at first that the problem has been solved already. Specifically, consider the implementation note on page 58. The restriction on what may appear in macro expansions is insufficient to "ensure that the expansion can be processed ... in an implementation- independent manner". But what would be sufficient? A necessary condition is that all implementation-specific special forms be accompanied by equivalent (modulo efficiency and what else?) macro definitions so that any expression can be "fully expanded" so as to contain no implementation-specific special forms. CLtL does require equivalent macros for special form implementations of operations defined as macros in Common Lisp, but does not say anything about other special forms an implementation may use. Such a requirement should be added. However, for sufficiency something must rule out functions of the DO-A-DEFUN sort (special forms in disguise). I agree with you. My comments above are a restatement of the same concerns, I think. Perhaps this is being addressed as a compiler issue? Not as far as I am aware. It's really not a compiler issue anyway: if we only had an interpreter the issue would be exactly the same. The meta-issue is whether to the goals on pp.1-3 of CLtL the community wishes to add a goal of precisely defined, portable semantics for things like DEFUN. If not, the half baked attempt on pp.57-8 should be removed. If so, a lot needs to be added. I'm not sure any of the existing committees are chartered to work on this. ∂06-Mar-88 1241 CL-Cleanup-mailer Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Mar 88 12:41:05 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357018; Sun 6-Mar-88 15:41:14 EST Date: Sun, 6 Mar 88 15:41 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT To: Masinter.pa@Xerox.COM cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <880304-135303-8627@Xerox> Message-ID: <19880306204110.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: 4 Mar 88 13:52 PST From: Masinter.pa@Xerox.COM I'd given a separate name, DEFMACRO-BODY-LEXICAL-ENVIRONMENT, to the issue of the lexical environment of DEFMACRO. I think it is related to, but separate from, the LET-TOP-LEVEL issue. LET-TOP-LEVEL is (from my perspective) a clarification, while DEFMACRO-BODY-LEXICAL-ENVIRONMENT is a proposal for a change. I agree that these issues should be separated. I think we are in general agreement about LET-TOP-LEVEL with the only discussion being wording (is this a "change" or a "clarification", etc., ) which can probably be finessed. I don't think so. For example, the proposal only mentions LET. This is obviously incomplete. It should at least mention LET*. But what about the LAMBDA combination that is almost equivalent to LET? What about other binding forms such as DO? What about other bindings besides variables, such as MACROLET, FLET, and BLOCK? I think the proposal needs much more careful attention to how narrow or broad its scope is supposed to be. Understand that I do not object to the change proposed by this proposal. I think that that change is going to be part of the real proposal; I just don't think it makes sense to do that one change by itself. More generally, I think this proposal is patching Common Lisp's ill-defined notion of "top level" instead of fixing it. While there are some practical benefits to the patch, as it makes a small increase in the number of programs that are portable, I don't think it really solves the problem. In practical terms, I can't see asking my compiler people to spend time implementing this when it's obvious that this is an interim change and something better is, or should be, on its way. I'd rather they spend their energies elsewhere until Common Lisp has really got its act together on this "top level form" business, and then they can implement what is really the right thing. If this proposal were presented in its current form, I would oppose it. No amount of wording changes would change my position. I want to see a broader proposal. DEFMACRO-BODY-LEXICAL-ENVIRONMENT has more problems, because we lack good definitions the terms involved in giving a precise definition of when such lexical environments can be used. Agreed. See the other mail I sent today for more on that topic. ∂06-Mar-88 1620 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 6 Mar 88 16:20:26 PST Received: by labrea.Stanford.EDU; Sun, 6 Mar 88 16:21:07 PST Received: from bhopal.lucid.com by edsel id AA01167g; Sun, 6 Mar 88 16:03:38 PST Received: by bhopal id AA20764g; Sun, 6 Mar 88 16:10:06 PST Date: Sun, 6 Mar 88 16:10:06 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803070010.AA20764@bhopal.lucid.com> To: Moon@stony-brook.scrc.symbolics.com Cc: Pavel.pa@xerox.com, cl-cleanup@sail.stanford.edu In-Reply-To: David A. Moon's message of Sun, 6 Mar 88 15:02 EST <19880306200213.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Issue: LET-TOP-LEVEL (version 1) re: This is perhaps a bad example of what you are trying to illustrate, for it needlesly violates the "global environment" constraint of CLtL p145. On the contrary, violation of that constraint was precisely the topic I was trying to illustrate. Removal of that constraint was the subject under discussion. Since you are merely trying to show up a flaw in the "pre-processor"... That is not at all what I was trying to do. Yes, Dave, I know that was not the main point of this series of discussions; and I'm fully aware that you were trying to find another example where the extent of the lexical environment for the expander function is critical. I'm sorry for characterizing your comments so flippantly. What I was trying to point out to you was that the problems of pre-processors occur long before you get to the captured lexical environment problem. Since defmacros in "the same form" as their clients don't in general work right during this kind of pre-processing, I think it's moot to talk about the additional problems of capturing lexical variables in such macros. Thus your example: (defun foo (x) (macrolet ((baz (x y) (print (baz ,x ,y expanded)) (list ,x ,y))) (lambda (z) (baz x z)))) nicely illustrates the need for indefinite extent of the lexical environment containing the argument to FOO; but the example called "nonsensical program" fails to make a similar point so strikingly, since attempts to compile or pre-process it break down (in the typical pre-processor) regardless of the lexical variable questions. re: (defun tryit () (compiler-let ((cnt 0)) (compiler-let ((throw-away (progn (defmacro do-it-once (x) (incf cnt) (QUOTE ,x)) (defmacro total-count () (QUOTE ,cnt)) t))) (defun foo (x) (do-it-once x) (do-it-once x) (total-count))))) I don't understand how this is relevant, since compiler-let is an operation on dynamic variables, not lexical variables. Ah, I thought this little cleverity might go over peoples' heads. The issue being illustrated is how 'compiler-let' is a loophole, permitting backdoor calls to EVAL during the simple compilation of a function. THERE IS NO EXPECTATION THE VARIABLES USED ARE LEXICAL. The time-of-evaluation issues related to "pre-processing" and/or compilation can to some degree be circumvented by this loophole; thus there is no absolute need to put macros in a file (or separate lexical environment) in order to get them to expand "right". Now it certainly would be a different question if the variable CNT in this TRYIT example were referenced freely by the DEFUN for FOO. Then it would be all very interesting to ask what the program might mean if the binding for CNT were with a LET rather than a compiler LET (but the binding for THROW-AWAY would still be a COMPILER-LET). This might, I think, illustrate the weird situation that you have been hinting at, where there is a mismatch of times at which a lexical environment must exist. [Note, of course, that there is no "file" involved, so that not all of the issues called "Toplevel" are restrictd to file compilations.] However, your original "nonsensical program" doesn't have this property: (let ((x (big-computation-that-returns-22/7))) (defmacro foo (y) (list ,x ,y)) (defun bar (z) (foo (1+ z)))) Notice that at eval time, (FOO (1+ Z)) expands as the equivalent: (defun bar (z) (list 22/7 (1+ z))) and this form doesn't have any pointers to the lexical environment outside of the defun. And, conceivably, if "TopLevel" were to "pass thru" a LET, then this would be the same situation at compile time. IF instead, you had give the example as: (defun bar (z) (list x (foo (1+ z)))) THEN it would illustrate the issue to be clarified, for then the macroexpansion would lead to: (defun bar (z) (list x (list 22/7 (1+ z)))) and "x" is the captured lexical variable whose compile-time/load-time existence is in question. But I don't see this inconsistency as much worse than the fact that macro expansions will "freeze" values at compile time which would be different had the expansion function been run at a later time (say, load time). re: You are correct in (implicitly) pointing out that this claim of Pavel's should have been limited to the case where the non-null closed-over environment (really the captured free identifiers) came from a load-time binding rather than a compile-time binding. This clarification of the "claim" reduces its contention to the situation where there is something like the ambiguity of compile-time/load-time just mentioned. The TRYIT example says nothing about the reduced claim. However, it still leaves open the question of what to do at compile time. As I recall the discussions on this matter over the past years, I see: (1) Many users who claim that having the defmacro expander function be treated like any other form (i.e., its lexical environment is the same as the surrounding context) is a very useful capabililty that they full well understand how to use without causing problems; (2) Attempts to illustrate an ambiguous extent situation for the lexical environment of defmacros are not "garden variety" code, and are in general subsidary to the problems of specifying even when the global environment is to be changed [i.e., just when is the macro-function "cell" named by a defmacro to be updated?]. To me, this looks like mounting evidence that retracting the special limitation on defmacro would be in the best interests of the community. On the other hand, I see stability as an even more paramount concern, particularly since the user who wants the capability currently denied him for defmacro can simply "hand-expand" the defmacro into a setf of macro-function. No easy choice, again. -- JonL -- P.S.: I also don't see future extensions to "TopLevel" being done in such a way so that it will "pass thru" a LET. It's nice to contemplate this, but I suspect it will cause more problems than it solves. ∂06-Mar-88 1935 CL-Cleanup-mailer Issue: LET-TOP-LEVEL (version 1) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Mar 88 19:35:25 PST Received: from Salvador.ms by ArpaGateway.ms ; 06 MAR 88 19:36:07 PST From: masinter.PA@Xerox.COM Date: 6 Mar 88 19:35:18 PST Subject: Issue: LET-TOP-LEVEL (version 1) To: cl-cleanup@sail.stanford.edu Message-ID: <880306-193607-1193@Xerox> I have the feeling we could go on forever on this topic with subtle examples that illustrate various points... however, it doesn't seem to be converging. I do have a feeling that if we can come to some agreement on the notion of "top level" vs "embedded" and "file" and a few other things like that, it would help out a lot in resolving things in subsequent discussions. So: the floor is open for proposals for definitions of terms. ∂07-Mar-88 0637 CL-Cleanup-mailer compiler-warning-break Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 7 Mar 88 06:36:51 PST Date: 7 Mar 88 09:27:00 EDT From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> Subject: compiler-warning-break To: "cl-cleanup" <cl-cleanup@sail.stanford.edu> cc: vanroggen Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> From: Masinter.pa@Xerox.COM Message-ID: <880304-094104-8049@Xerox> Am I correct in reading your message ("As it stands we must oppose the proposal"), that you feel the proposal writeup is unclear, and that you would prefer to have a greater distinction between those errors for which *break-on-warnings* have effect and those it does not? Yes, not only a greater distinction, but some definition as to when and how this could be used. What kinds of conditions must be "warned"? Are "potential errors" detected by the compiler real "errors"? Is there a difference in such behavior between COMPILE and COMPILE-FILE? (Your example, (EVAL-WHEN (COMPILE) (PRINT (+ 3 'A))) , by the way, is not affected by *break-on-warnings*.) You're right. (Unless an implementation decided to WARN when an arithmetic operation got illegal arguments, I suppose.) However the point of the example was to distinguish run-time signalled conditions from conditions detected by the compiler in examining source code. My impression of the original intent is that the proposal writer very much wanted *break-on-warnings* to cause a break "if the compiler happens to see a variable that was bound but was unused", or other such anomolies. However, this proposal was made before there had been more work on the signal system. It might be more useful to arrive at a way that environment programs can consistently interact with the compiler using well-defined signals rather than the cruder *break-on-warnings* mechanism (which may well be obsolete.) Do you think such a proposal be more suitable? Yes, I think deciding on an error system and deciding what conditions are signalled by the compiler should precede decisions on such minor things as what *BREAK-ON-WARNINGS* means in a few particular situations. ---Walter ------ ∂07-Mar-88 0936 CL-Cleanup-mailer New issues for the "pending" list, from Japan Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Mar 88 09:36:50 PST Received: from Cabernet.ms by ArpaGateway.ms ; 07 MAR 88 09:29:04 PST Date: 7 Mar 88 09:27 PST From: Masinter.pa@Xerox.COM Subject: New issues for the "pending" list, from Japan To: cl-cleanup@Sail.stanford.edu Message-ID: <880307-092904-1841@Xerox> These issues were derived from the list submitted by the Japanese technical working group on Lisp. They are all "need volunteer". EVAL-OTHER (Should structures, arrays, vectors, ... self-evaluate?) LAMBDA-LIST-DUPLICATES (Is it an error to have the same symbol more than once in a lambda list?) MAPPING-DESTRUCTIVE-INTERACTION (The interaction of mapping functions and DOLIST and destructive operations on the list operated on is explictly left undefined.) SPECIAL-VARIABLE-TEST (Want a way to ask if a variable is proclaimed special.) ∂07-Mar-88 1030 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 10:30:03 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357557; Mon 7-Mar-88 13:30:18 EST Date: Mon, 7 Mar 88 13:29 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1) To: CL-Cleanup@SAIL.Stanford.EDU Message-ID: <880307132956.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Issue: SPECIAL-VARIABLE-TEST References: Declaring Global Variables and Named Constants (pp68-69), Declaration Specifiers (p157) Category: ADDITION Edit history: 07-Mar-88, Version 1 by Pitman Status: For Internal Discussion Problem Description: CLtL does not define a way to test to see if a variable has been proclaimed special. Programs such as macros, code-walkers, and program-generating programs may need such information from time to time in order to do certain kinds of reasoning about code-motion, unused variables, etc. Proposal (SPECIAL-VARIABLE-TEST:SPECIALP) Add a function SPECIAL-VARIABLE-P by analogy with SPECIAL-FORM-P which is defined as: SPECIAL-VARIABLE-P symbol &optional environment [Function] Returns T iff -symbol- names a variable which is SPECIAL in the indicated lexical -environment-. Otherwise, it returns NIL. It is an error if -symbol- is not a symbol. If not supplied, the -environment- defaults to NIL, meaning the null lexical environment. Test Case: (PROCLAIM '(SPECIAL SPECIAL-FOO)) (MACROLET ((TEST (NAME &ENVIRONMENT ENV) (,NAME ',(SPECIAL-VARIABLE-P NAME ENV)))) (LIST* (TEST SPECIAL-FOO) ;0 (TEST FOO) (LET ((SPECIAL-FOO 1) (FOO 1)) (LIST* (TEST SPECIAL-FOO) ;1 (TEST FOO) (LET ((SPECIAL-FOO 2) (FOO 2)) (DECLARE (SPECIAL FOO)) (LIST* (TEST SPECIAL-FOO) ;2 (TEST FOO) (LET ((SPECIAL-FOO 3) (FOO 3)) (LIST (TEST SPECIAL-FOO) ;3 (TEST FOO))))))))) => ((SPECIAL-FOO T) (FOO NIL) ;0 (SPECIAL-FOO T) (FOO NIL) ;1 (SPECIAL-FOO T) (FOO T) ;2 (SPECIAL-FOO T) (FOO NIL)) ;3 Rationale: This would allow programs that reason about other programs to obtain important information about SPECIAL declarations and proclamations. Current Practice: Interpreters and compilers must, of necessity, have a way to do this internally. In some implementations, information about special variable proclamations is kept on a symbol's plist, and users eventually "figure out" how to take advantage of that. In most implementations, getting information about special declarations is neither documented nor easy to "figure out". Cost to Implementors: By necessity, compilers and interpreters must have a way to get the information returned by this facility. In general, it should just be a matter of providing a program interface to that facility. Cost to Users: None. This is an upward-compatible extension. Cost of Non-Adoption: Some code-walkers, macros, etc. would continue be hard to write in a portable way. Benefits: The cost of non-adoption would be avoided. Aesthetics: Although SPECIAL variables provide some benefit to Common Lisp, that benefit has not been without price. It's difficult to do proper code analysis if lexical and special variables look the same. The presence of this operator makes it easier to write code which reasons clearly and correctly about other programs, and so will probably tend to improve the aesthetics of such programs. Discussion: This proposal came to the Cleanup committee from the Japanese community. Pitman wrote it up formally and supports SPECIAL-VARIABLE-TEST:SPECIALP. ∂07-Mar-88 1040 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 10:40:34 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 357573; 7 Mar 88 13:40:46 EST Date: Mon, 7 Mar 88 13:40 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1) To: KMP@STONY-BROOK.SCRC.Symbolics.COM cc: CL-Cleanup@SAIL.Stanford.EDU In-Reply-To: <880307132956.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <880307134024.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> That should have been '(,NAME ,(SPECIAL-VARIABLE-P NAME ENV)) rather than (,NAME ',(SPECIAL-VARIABLE-P NAME ENV)) in the test case, of course. Sorry about that. Whoever does the next draft should make that correction. ∂07-Mar-88 1043 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 10:43:42 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357577; Mon 7-Mar-88 13:44:05 EST Date: Mon, 7 Mar 88 13:43 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1) To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880307132956.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880307184333.9.MOON@EUPHRATES.SCRC.Symbolics.COM> I approve of SPECIAL-VARIABLE-TEST:SPECIALP (except why isn't the proposal named SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P ?) For the current practice section: Symbolics Genera has a function named SYS:SPECIAL-VARIABLE-P that does this. The function is not documented, currently, probably because we've been waiting to see if Common Lisp standardizes on a different name. ∂07-Mar-88 1059 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 10:59:49 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357594; Mon 7-Mar-88 14:00:08 EST Date: Mon, 7 Mar 88 13:59 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1) To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880307132956.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Supersedes: <19880307184333.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Comments: I noticed an overlooked issue after sending this message the first time. Message-ID: <19880307185953.0.MOON@EUPHRATES.SCRC.Symbolics.COM> I approve of SPECIAL-VARIABLE-TEST:SPECIALP (except why isn't the proposal named SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P ?) For the current practice section: Symbolics Genera has a function named SYS:SPECIAL-VARIABLE-P that does this. The function is not documented, currently, probably because we've been waiting to see if Common Lisp standardizes on a different name. After looking at our SYS:SPECIAL-VARIABLE-P, I note a possible oversight in this proposal. With Common Lisp, as opposed to Zetalisp, scoping rules for SPECIAL declarations, there are two distinct questions one can ask about the declaration of a variable. One is, "would a reference to this variable in this environment be special?". The second is, "would a binding of this variable in this environment be special?". The proposal only answers the first question. The second question is a little harder because you need to figure out how to feed local declarations attached to the binding to the predicate. I suggest a very simple solution: to ask the second question, one supplies NIL as the environment, which accesses the proclamations without the declarations, and then one handles manually any local declarations attached to the binding. This is minimalist but should do the job. The proposal doesn't need any technical changes for this, but should include a brief mention of this issue and the solution. ∂07-Mar-88 1206 CL-Cleanup-mailer Issue: LAMBDA-LIST-DUPLICATES (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 12:06:20 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357667; Mon 7-Mar-88 15:06:35 EST Date: Mon, 7 Mar 88 15:06 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1) To: CL-Cleanup@SAIL.Stanford.EDU Message-ID: <880307150614.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Issue: LAMBDA-LIST-DUPLICATES References: 5.1.2 Variables (pp55-56) 5.2.2 Lambda-Expressions (pp59-65), LET* (p111-112), PROG* (pp131-132) Category: ADDITION Edit history: 07-Mar-88, Version 1 by Pitman Related Issues: DECLARATION-SCOPE Status: For Internal Discussion Problem Description: CLtL forbids binding the same variable more than once in the same binding form. This rule is claimed by some to be overly restrictive because there are some well-defined situations in which it would be useful to duplicate a variable name in the same binding list. Proposal (LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE): Allow variable names to be repeated in situations where bindings are sequential and the binding construct is non-iterative (specifically, in the &AUX part of a normal lambda list, in the bindings of LET*, and in the bindings of PROG*). Test Case: ((LAMBDA (B &AUX (B (+ B 1)) (B (+ B 1))) B) 0) => 2 (LET* ((B 0) (B (+ B 1))) B) => 1 (PROG* ((B 0) (B (+ B 1))) (RETURN B)) => 1 Rationale: Because these bindings are inherently sequential and non-iterative, there would no ambiguity about the intended scope bindings, and it is sometimes useful to repeat the name of a binding when doing various kinds of encapsulations or successive refinements to the same value. The intent of duplicated bindings in "parallel binding" constructs like LET or iterative constructs like DO* is less easy to predict, so it is not proposed that the current rule be relaxed for such constructs. Current Practice: The Symbolics implementation currently checks for this case and signals an error. [Others?] Cost to Implementors: Converting would be relatively easy, but not completely trivial. There is some interaction with declaration processing which becomes involved, too (see issue DECLARATION-SCOPE). Cost to Users: None. This is an upward-compatible change. Cost of Non-Adoption: Some useful expressional style would be lost. Benefits: A useful expressional style would be made available. Aesthetics: The rule for variable duplication would be more syntactically complex but pragmatically simpler. Discussion: A request for a discussion of this issue came from the Japanese community. Pitman drafted this formal proposal and supports LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE. ∂07-Mar-88 1232 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 12:32:39 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357713; Mon 7-Mar-88 15:33:00 EST Date: Mon, 7 Mar 88 15:32 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1) To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <19880307185953.0.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880307153239.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Mon, 7 Mar 88 13:59 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> ... why isn't the proposal named SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P ... Editing error. I changed the name from SPECIALP to SPECIAL-VARIABLE-P while evolving the proposal and didn't make the change completely enough. For clarity, someone should change it in the next draft. For the current practice section: Symbolics Genera has a function named SYS:SPECIAL-VARIABLE-P that does this. The function is not documented, currently, probably because we've been waiting to see if Common Lisp standardizes on a different name. After looking at our SYS:SPECIAL-VARIABLE-P, I note a possible oversight in this proposal. With Common Lisp, as opposed to Zetalisp, scoping rules for SPECIAL declarations, there are two distinct questions one can ask about the declaration of a variable. One is, "would a reference to this variable in this environment be special?". The second is, "would a binding of this variable in this environment be special?". The proposal only answers the first question. The second question is a little harder because you need to figure out how to feed local declarations attached to the binding to the predicate. I suggest a very simple solution: to ask the second question, one supplies NIL as the environment, which accesses the proclamations without the declarations, and then one handles manually any local declarations attached to the binding. This is minimalist but should do the job. The proposal doesn't need any technical changes for this, but should include a brief mention of this issue and the solution. This sounds mostly ok, though we'd need to be clear about which of these an appropriate type-2 call to SPECIAL-VARIABLE-P looked like: 1. (SPECIAL-VARIABLE-P 'FOO '((DECLARE (SPECIAL X) (FIXNUM X)) (DECLARE (SPECIAL Y)))) 2. (SPECIAL-VARIABLE-P 'FOO '(DECLARE (SPECIAL X) (FIXNUM X) (SPECIAL Y))) 3. (SPECIAL-VARIABLE-P 'FOO '(((SPECIAL X) (FIXNUM X)) ((SPECIAL Y)))) 4. (SPECIAL-VARIABLE-P 'FOO '((SPECIAL X) (FIXNUM X) (SPECIAL Y))) 5. (SPECIAL-VARIABLE-P 'FOO '(X Y)) 1, 4, and 5 look ok to me. 1 seems like it would be easiest to arrange for in practice, and hence perhaps the best choice. I note also that this only works because special bindings are not pervasive. If they were not, you'd have to have the environment argument also. In philosophy courses I've taken, we'd say it is "true" that the environment is not needed, but it is not "necessarily true" (i.e., there exist consistent, possible universes in which it is not true). For implementational flexibility in case anyone -wants- pervasive bindings (as an, arguably incompatible, extension) or in case we later want to change the language, it might be cleaner to say (SPECIAL-VARIABLE-P 'FOO ENV '(...decls...)) and to mention to implementors that in fact the ENV may be ignored if the decls are passed. It's especially interesting in the case of (SPECIAL-VARIABLE-P 'FOO NIL) ;null environment vs (SPECIAL-VARIABLE-P 'FOO '()) ;no decls because these both do the same thing but for completely different reasons. It really stretches the pun to unreasonable lengths. I'd be content to rewrite the proposal to accomodate this additional issue if others concurred. ∂07-Mar-88 1253 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 12:53:42 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357734; Mon 7-Mar-88 15:54:07 EST Date: Mon, 7 Mar 88 15:53 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1) To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880307153239.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880307205356.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 7 Mar 88 15:32 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Date: Mon, 7 Mar 88 13:59 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> After looking at our SYS:SPECIAL-VARIABLE-P, I note a possible oversight in this proposal. With Common Lisp, as opposed to Zetalisp, scoping rules for SPECIAL declarations, there are two distinct questions one can ask about the declaration of a variable. One is, "would a reference to this variable in this environment be special?". The second is, "would a binding of this variable in this environment be special?". The proposal only answers the first question. The second question is a little harder because you need to figure out how to feed local declarations attached to the binding to the predicate. I suggest a very simple solution: to ask the second question, one supplies NIL as the environment, which accesses the proclamations without the declarations, and then one handles manually any local declarations attached to the binding. This is minimalist but should do the job. The proposal doesn't need any technical changes for this, but should include a brief mention of this issue and the solution. This sounds mostly ok, though we'd need to be clear about which of these an appropriate type-2 call to SPECIAL-VARIABLE-P looked like: 1. (SPECIAL-VARIABLE-P 'FOO '((DECLARE (SPECIAL X) (FIXNUM X)) (DECLARE (SPECIAL Y)))) 2. (SPECIAL-VARIABLE-P 'FOO '(DECLARE (SPECIAL X) (FIXNUM X) (SPECIAL Y))) 3. (SPECIAL-VARIABLE-P 'FOO '(((SPECIAL X) (FIXNUM X)) ((SPECIAL Y)))) 4. (SPECIAL-VARIABLE-P 'FOO '((SPECIAL X) (FIXNUM X) (SPECIAL Y))) 5. (SPECIAL-VARIABLE-P 'FOO '(X Y)) Huh? I was proposing that the second argument to SPECIAL-VARIABLE-P would be NIL and the caller would have to do his own declaration parsing. Thus (OR (SPECIAL-VARIABLE-P var NIL) (MEMBER var parsed-special-dcls)). If we wanted a function to help compute parsed-special-dcls, that would be a separate function. I'm not sure we need one as part of the Common Lisp standard. I note also that this only works because special bindings are not pervasive. Yes, in Zetalisp they are pervasive and the issue does not arise, since the two questions yield the same answer. [philosophy deleted] ∂07-Mar-88 1257 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 12:57:13 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357740; Mon 7-Mar-88 15:57:37 EST Date: Mon, 7 Mar 88 15:57 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: EVAL-OTHER (Version 1) To: CL-Cleanup@SAIL.Stanford.EDU Message-ID: <880307155717.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Issue: EVAL-OTHER References: 5.1.1 Self-Evaluating Forms (p55) Category: ADDITION/CLARIFICATION Edit history: 07-Mar-88, Version 1 by Pitman Status: For Internal Discussion Problem Description: CLtL does not specify what the evaluation behavior of some data types. Proposal (EVAL-OTHER:SELF-EVALUATE): Standard data types (those mentioned by CLtL) other than those for which a more explicit evaluation rule exists would be defined to self-evaluate. Such data types include, for example, structures, arrays, vectors, and pathnames. Structure types defined by users using DEFSTRUCT should also self-evaluate unless an explicit implementation type for the structure is given in the DEFSTRUCT, in which case the rule for evaluation of that type should be used. (This is important in the case of type LIST.) Test Case: (LET ((TEMP (MAKE-PATHNAME))) (EQ TEMP (EVAL TEMP))) => T (LET ((TEMP (MAKE-ARRAY NIL))) (EQ TEMP (EVAL TEMP))) => T Rationale: There are numerous possible positions that could be taken, from requiring that an error be signalled for all of these cases to requiring that these all have some useful behavior. By making implementations agree, code portability is enhanced. By choosing not to make a change from things being useful to things being useful (i.e., by biasing the decision away from the "signal an error" end of the choice spectrum), the least interruption is caused to implementations which already have working code. There is still some chance that implementations will have some other behavior than either signalling an error or self-evaluating, but there are probably few if any. Current Practice: In many implementations, the other data types besides those mentioned in CLtL will self-evaluate. Cost to Implementors: The cost is probably small. This is probably an "upward compatible" change for most or all implementations -- a few lines of change in the interpreter and/or compiler. Some code walkers may be affected as well. Cost to Users: None, if they are not exploiting implementation-dependent features of some implementation that is being forced to make an incompatible change. There should be no performance impact since the evaluator's test for these new data types can simply be made to follow other tests already in place, so existing code will not be slowed. Cost of Non-Adoption: Implementations will continue to differ in this relatively user-visible way. Benefits: Portability will be enhanced because implementations will tend to agree in places where they have traditionally not always agreed. Aesthetics: Some fans of 3LISP may find this invasive to their sense of distinction between objects and the notation used to describe objects. In general, however, this is a fairly picky detail that is not likely to trouble the average programmer. Discussion: This idea for this proposal was suggested by the Japanese community. Pitman drafted the formal proposal and supports EVAL-OTHER:SELF-EVALUATE. ∂07-Mar-88 1324 CL-Cleanup-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 13:24:38 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357783; Mon 7-Mar-88 16:25:04 EST Date: Mon, 7 Mar 88 16:24 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1) To: CL-Cleanup@SAIL.Stanford.EDU Message-ID: <880307162443.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Issue: MAPPING-DESTRUCTIVE-INTERACTION References: MAPCAR, MAPLIST, ... (p128); DOLIST (p126); MAPHASH (p285); DO-SYMBOLS, DO-EXTERNAL-SYMBOLS, DO-ALL-SYMBOLS (pp187-188); All functions using :TEST Category: CLARIFICATION Edit history: 07-Mar-88, Version 1 by Pitman Status: For Internal Discussion Problem Description: The interaction of mapping functions and DOLIST with destructive operations on the list being operated on is unclear. For example, if you destructively modify some tail of a list being mapped down, does that affect the mapping process? Proposal (MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE): Document the fact that it is an error for code run by a "structure traversing" operation to destructively modify the set of things being traversed while the traversal operation is going on. Test Case: (LET* ((L (LIST 'A 'B 'C)) (LL L) (I 0)) (DOLIST (FOO L) (INCF I) (IF (EQ FOO 'B) (SETF (CDR LL) NIL) (POP LL))) (LIST I L)) might return (2 (A B)) or (3 (A B)), for example. Rationale: The likelihood that the user will want to destructively alter a structure while it is being traversed is low. The likelihood that such code would be readable and maintainable is also low. The likelihood that a compiler could do some interesting optimization if this point were not pinned down is high enough to be the overriding consideration in this case. Current Practice: The Symbolics implementation of DOLIST returns (3 (A B)) for the test case. Cost to Implementors: None. This simply makes the status quo explicit. Cost to Users: Technically none. People who were mistakenly assuming that CLtL guaranteed things which it does not might be inclined to rewrite their code in a more portable way. Cost of Non-Adoption: Users would be less informed. Benefits: users would be more informed. Aesthetics: Some might say it would be clearer to define this one way or the other, but advocates of both camps exist and their arguments are fairly symmetric. In any case, since this is a proposal to preserve the status quo, it has no major impact on aesthetics. Discussion: This idea for this proposal was suggested by the Japanese community. Pitman drafted the formal proposal and supports MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE. ∂07-Mar-88 1325 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 13:25:28 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357784; Mon 7-Mar-88 16:25:54 EST Date: Mon, 7 Mar 88 16:25 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: EVAL-OTHER (Version 1) To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880307155717.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880307212550.8.MOON@EUPHRATES.SCRC.Symbolics.COM> I favor EVAL-OTHER:SELF-EVALUATE. Under rationale, the sentence beginning "By choosing not to make a change from things being useful to things being useful" is probably a typographical error. I remember this issue being discussed only a few months ago on either Common-Lisp or CL-Cleanup. I think somebody had some reasons to oppose this proposal, but I don't remember finding them convincing. Sorry I don't remember any of the details, I mention it because perhaps this will stimulate someone else's memory. ∂07-Mar-88 1326 CL-Cleanup-mailer Issue: SPECIAL-VARIABLE-TEST (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Mar 88 13:26:32 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 357786; Mon 7-Mar-88 16:26:49 EST Date: Mon, 7 Mar 88 16:26 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: SPECIAL-VARIABLE-TEST (Version 1) To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <19880307205356.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880307162627.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Mon, 7 Mar 88 15:53 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> ... Huh? I was proposing that the second argument to SPECIAL-VARIABLE-P would be NIL and the caller would have to do his own declaration parsing. Thus (OR (SPECIAL-VARIABLE-P var NIL) (MEMBER var parsed-special-dcls)). Oh, I see. This is fine. ∂07-Mar-88 1410 CL-Cleanup-mailer Are you coming to the cleanup meeting? Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Mar 88 14:10:00 PST Received: from Cabernet.ms by ArpaGateway.ms ; 07 MAR 88 14:03:30 PST Date: 7 Mar 88 14:03 PST From: Masinter.pa@Xerox.COM Subject: Are you coming to the cleanup meeting? To: cl-cleanup@Sail.stanford.edu Message-ID: <880307-140330-2633@Xerox> As I was ordering bagels etc for next Tuesday morning, I realized that I had no idea how many people would be here. If you're coming to the cleanup meeting, could you let me know? ∂07-Mar-88 1719 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1) Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 17:19:34 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Mon 7 Mar 88 20:19:44-EST Date: Mon, 7 Mar 1988 20:19 EST Message-ID: <FAHLMAN.12380551338.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: CL-Cleanup@SAIL.STANFORD.EDU Subject: Issue: EVAL-OTHER (Version 1) In-reply-to: Msg of 7 Mar 1988 16:25-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM> I favor EVAL-OTHER:SELF-EVALUATE. -- Moon Me too. I don't remember any useful discussion of this recently, but I do remember the original design discussions. It was proposed that everything but lists and symbols evaluate to themselves, but at the time (this was quite early in the process) some people felt that this might close out interesting parts of the design space that might turn out to be useful for something. This hasn't happened, and I think it would be reasonable to close this door now. Some users do find it confusing that you have to quote vectors but not strings. -- Scott ∂07-Mar-88 2157 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 21:57:03 PST Received: by labrea.Stanford.EDU; Mon, 7 Mar 88 21:57:43 PST Received: from bhopal.lucid.com by edsel id AA05980g; Mon, 7 Mar 88 21:35:06 PST Received: by bhopal id AA05406g; Mon, 7 Mar 88 21:41:38 PST Date: Mon, 7 Mar 88 21:41:38 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803080541.AA05406@bhopal.lucid.com> To: masinter.PA@xerox.com Cc: cl-cleanup@sail.stanford.edu In-Reply-To: masinter.PA@Xerox.COM's message of 6 Mar 88 19:35:18 PST <880306-193607-1193@Xerox> Subject: Issue: [Not Really] LET-TOP-LEVEL (version 1) re: I do have a feeling that if we can come to some agreement on the notion of "top level" vs "embedded" and "file" and a few other things like that, it would help out a lot in resolving things in subsequent discussions. Maybe not. At least not for the root cause that spurred the "flurry" of examples. In case you hadn't noticed, the discussion that went on under the subjet line of "LET-TOP-LEVEL (version 1)", after the first round of interchanges, is really about an issue that would have better been by-lined under the DEFMACRO-BODY-LEXICAL-ENVIRONMENT issue. [But that doesn't cover the issue adequately either, since a strict interpretation on that topic might limit it to the notion of "lexical environment".] The problem underlying these still seems to be the discrepancy possible between eval/load time definition and macroexpansion, and compile time definition and macroexpansion. X3J13 had a subcommittee that was supposed to investigate the semantics of macros. It appears to be defunct. And as so often happens, the interest that could have been focused there has landed on the Cleanup committee mails. Wegman once volunteered (I think) to head up the macro committee. Mark? -- JonL -- ∂07-Mar-88 2216 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 7 Mar 88 22:16:18 PST Received: by labrea.Stanford.EDU; Mon, 7 Mar 88 22:16:54 PST Received: from bhopal.lucid.com by edsel id AA06092g; Mon, 7 Mar 88 22:04:35 PST Received: by bhopal id AA05477g; Mon, 7 Mar 88 22:11:09 PST Date: Mon, 7 Mar 88 22:11:09 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803080611.AA05477@bhopal.lucid.com> To: Fahlman@c.cs.cmu.edu Cc: CL-Cleanup@sail.stanford.edu In-Reply-To: "Scott E. Fahlman"'s message of Mon, 7 Mar 1988 20:19 EST <FAHLMAN.12380551338.BABYL@C.CS.CMU.EDU> Subject: Issue: EVAL-OTHER (Version 1) re: . . . but I do remember the original design discussions. It was proposed that everything but lists and symbols evaluate to themselves, but at the time (this was quite early in the process) some people felt that this might close out interesting parts of the design space that might turn out to be useful for something. . . . Another way of saying this, and justifying the decision now to be made, is that "Programs are encoded into lists and symbols; other data-types viewed as programs shall be interpreted as constant data". Thus the purpose of QUOTE is so that you can introduce, say, the particular datum (CAR X) into the program described as (DEFUN FOO (X) (LIST '(CAR X) '= (CAR X))) ;who is data, and who is program? Lisp program syntax really hasn't changed much in 20 years. Note that &OPTIONAL and :TEST-NOT are still symbols -- not some obscure internal data structure invented for just this case of program syntax. Someone may still want to nit-pick about numbers as tags in a tagbody, but I don't think this is an important problem; it's merely a footnote as to what a "program" is. -- JonL -- ∂08-Mar-88 0723 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Mar 88 07:23:03 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 358321; Tue 8-Mar-88 03:08:49 EST Date: Tue, 8 Mar 88 10:17 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: [Not Really] LET-TOP-LEVEL (version 1) To: edsel!jonl@labrea.Stanford.EDU cc: masinter.PA@xerox.com, cl-cleanup@sail.stanford.edu In-Reply-To: <8803080541.AA05406@bhopal.lucid.com> Message-ID: <880308101753.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Date: Mon, 7 Mar 88 21:41:38 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> ... The problem underlying these still seems to be the discrepancy possible between eval/load time definition and macroexpansion, and compile time definition and macroexpansion. X3J13 had a subcommittee that was supposed to investigate the semantics of macros. It appears to be defunct. ... Well, kinda and kinda not. The real problem is the committee overlap. When the macro committee was formed, it was in specific answer to the Lisp1/Lisp2 issue and was to focus on macro hygeine (a la Kohlbecker), which turns out to have nothing to do with (i.e., to be complete orthogonal to) expansion -time-. We on the committee studied Kohlbecker's thesis and while the ideas were interesting, they were not clearly something we could just lift and use directly in Common Lisp. It seemed clear that some "research" needs to be done and none of us on the macro committee has had time to do the necessary research. The Scheme community is still in flux on the macro issue, and we're also waiting and watching to see what happens there... We also decided not to feel terribly guilty about not doing the aforementioned research because even if it were successful and we had something to propose based on the results, it's very likely that it would be "radical" and inappropriate for a standard at this time (though not, for example, inappropriate for a new language or a particular implementation). Put another way, our decision to do nothing was not completely out of laziness. Our "informed judgement" at this point was that while macros could use some cleanup, such cleanup might be potentially destabilizing. It is not important to CL that every committee form a proposal. It is only necessary that committees look hard at the issues and determine if a proposal needs to be made. One of the stumbling blocks we encountered in our discussions is that there is no clear macro expansion time, but we felt that this issue was outside of our charter. Rightly, we felt the Compiler committee was in charge of this, but regardless of who is in charge, there's really no practical way in the current political arena that I can see anyone giving in on the following single very important point: to get good clear semantics (and I use that word in the informal sense; subsitute the word "meaning" if it makes you uncomfortable) you have to do initial pre-processing of forms at a known time, even in the interpreter. My impression is that there is a camp of die-hards who will not give up lazy macro expansion, and so I expect this issue never to go anywhere. Maybe I will write up a cleanup item on macro expansion time just to see if my impression is imaginary. It would certainly clean up so many things if we could get people to agree to it... ∂08-Mar-88 1126 CL-Cleanup-mailer Re: Are you coming to the cleanup meeting? Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 8 Mar 88 11:25:43 PST Received: from relay2.cs.net by RELAY.CS.NET id ag25706; 8 Mar 88 13:12 EST Received: from csc.ti.com by RELAY.CS.NET id an03153; 8 Mar 88 13:06 EST Received: from home by tilde id AA10255; Tue, 8 Mar 88 10:54:08 CST Received: by home id AA08511; Tue, 8 Mar 88 10:53:55 CST Date: Tue, 8 Mar 88 10:53:55 CST From: Ellen Waldrum <waldrum@home.csc.ti.com> Message-Id: <8803081653.AA08511@home> To: Masinter.pa@XEROX.COM, cl-cleanup@SAIL.STANFORD.EDU Subject: Re: Are you coming to the cleanup meeting? Larry, I currently plan to be there. -- Ellen ∂08-Mar-88 1319 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1) Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 8 Mar 88 13:18:17 PST Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa09784; 8 Mar 88 20:04 GMT From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK> Date: Tue, 8 Mar 88 20:01:37 gmt Message-Id: <18023.8803082001@aiva.ed.ac.uk> To: KMP@scrc-stony-brook.arpa, jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK, jonl <@labrea.stanford.edu:jonl@edsel.uucp> Subject: Issue: [Not Really] LET-TOP-LEVEL (version 1) Cc: cl-cleanup@sail.stanford.edu, masinter.PA@xerox.com > X3J13 had a subcommittee that was supposed to investigate the semantics > of macros. It appears to be defunct. As I recall, the macro committee was the subject of some confusion. The subcommittee was originally formed to investigate issues arising from Lisp1/Lisp2, and that aspect has been inactive, but I believe Mark Wegman and Julian Padget did some work over the summer concerning both the Lisp1/Lisp2 (name capture) issues and expansion environment issues. Julian reported (briefly) on this at the last X3J13, which surprised some people who hadn't know of this revival of activity. -- Jeff ∂08-Mar-88 1350 CL-Cleanup-mailer Issue: LAMBDA-LIST-DUPLICATES (Version 1) Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 8 Mar 88 13:49:29 PST Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa10126; 8 Mar 88 20:36 GMT From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK> Date: Tue, 8 Mar 88 20:28:54 gmt Message-Id: <18233.8803082028@aiva.ed.ac.uk> To: CL-Cleanup@sail.stanford.edu Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1) Cc: KMP@scrc-stony-brook.arpa Current practice: Both PopLog Common Lisp and KCL allow variables to appear more than once in a lambda-list. In the three suggested test cases, they both have the later binding current in the body of the form and so return the values 2, 1, and 1 respectively. In addition, both allow variables in other cases, specifically: KCL: ((lambda (a a) a) 1 2) => 2 PopLog: ((lambda (a a) a) 1 2) => 1 ∂08-Mar-88 1351 CL-Cleanup-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1) Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 8 Mar 88 13:51:28 PST Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa10183; 8 Mar 88 20:41 GMT From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK> Date: Tue, 8 Mar 88 20:22:00 gmt Message-Id: <18213.8803082022@aiva.ed.ac.uk> To: CL-Cleanup@sail.stanford.edu Subject: Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1) Cc: KMP@scrc-stony-brook.arpa Current practice: KCL and PopLog Common Lisp both return (3 (A B)) in the test case. ∂08-Mar-88 1457 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Mar 88 14:57:26 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 358861; Tue 8-Mar-88 17:47:50 EST Date: Tue, 8 Mar 88 17:48 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: [Not Really] LET-TOP-LEVEL (version 1) To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> cc: edsel!jonl@labrea.Stanford.EDU, masinter.PA@xerox.com, cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <880308101753.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880308224806.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Date: Tue, 8 Mar 88 10:17 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> We on the committee studied Kohlbecker's thesis and while the ideas were interesting, they were not clearly something we could just lift and use directly in Common Lisp. It seemed clear that some "research" needs to be done and none of us on the macro committee has had time to do the necessary research. The Scheme community is still in flux on the macro issue, and we're also waiting and watching to see what happens there... The paper by Bawden and Rees in the Lisp & Functional Programming 1988 ACM conference should be very helpful in this respect. No, it hasn't been published yet, the conference is in September(I think), coterminous with an X3J13 meeting. You can probably get prepublication copies from them when they submit their final draft to the conference. I deliberately didn't cc the authors on this reply, as I did not want them to be deluged with any subsequent mail. ∂08-Mar-88 1712 CL-Cleanup-mailer [Now Macros, but formerly] Issue: LET-TOP-LEVEL (version 1) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Mar 88 17:10:11 PST Received: by labrea.Stanford.EDU; Tue, 8 Mar 88 17:10:24 PST Received: from bhopal.lucid.com by edsel id AA08997g; Tue, 8 Mar 88 16:28:52 PST Received: by bhopal id AA07195g; Tue, 8 Mar 88 16:35:29 PST Date: Tue, 8 Mar 88 16:35:29 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803090035.AA07195@bhopal.lucid.com> To: KMP@stony-brook.scrc.symbolics.com Cc: masinter.PA@xerox.com, cl-cleanup@sail.Stanford.EDU In-Reply-To: Kent M Pitman's message of Tue, 8 Mar 88 10:17 EST <880308101753.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Subject: [Now Macros, but formerly] Issue: LET-TOP-LEVEL (version 1) I generally agree with your comments (macros problems). It's conceivable to me that the best we can hope to do -- while still retaining Lisp's characteristic dynamic flexibility -- is to offer a coherent explanation of the "meaning" of macroexpansion times, with liberal use of "it is an error ..." -- JonL -- ∂09-Mar-88 1221 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1) Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Mar 88 12:19:19 PST Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa09711; 9 Mar 88 17:53 GMT Received: from m42 by mordell.maths.bath.AC.UK id aa10434; 9 Mar 88 17:50 GMT To: jonl <@labrea.stanford.edu:jonl@edsel.uucp> CC: masinter.PA@xerox.com, cl-cleanup@sail.stanford.edu In-reply-to: Jon L White's message of Mon, 7 Mar 88 21:41:38 PST Subject: Issue: [Not Really] LET-TOP-LEVEL (version 1) Date: Wed, 9 Mar 88 17:51:45 GMT From: jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK Sender: jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK In fact, I spent some time at YKT last summer working *for* Mark on this. I did give a short, inconclusive, report about this at Fort Collins and you may have seen a very drafty note about it that I sent to the eulisp list - I did hear that it did get a wider physical distribution after the electronic one (which was a source of some embarassment to me). I have just got down to doing some further work on macros (whilst I was away during the last week) and had reached precisely the points that people are now discussing on CL-cleanup, which is all useful input for me. I doubt I will have anything finished for next week (it is presently unclear whether I will be at X3J13 either, because of airline reservation problems). I also doubt that the conclusions will be popular, since the one obvious remark is that Lisp macros are a terrible mess, are further compounded in Common Lisp and that "if I were you, I wouldn't start from here"! It is precisely because of the environment issue and the way that it has been attempted to finesse multiple environments in CL that we have been treated to examples of such subtlety on this mailing list of late. Of course, it is easy to criticise rather than making a proposal and laying oneself open to criticism...there might be something in a few weeks, I hope. --Julian. ∂09-Mar-88 1248 CL-Cleanup-mailer Re: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 9 Mar 88 12:47:31 PST Received: by multimax.ARPA (5.51/25-eef) id AA07987; Wed, 9 Mar 88 15:49:33 EST Received: from localhost by mist.UUCP (3.2/4.7) id AA09416; Wed, 9 Mar 88 15:49:03 EST Message-Id: <8803092049.AA09416@mist.UUCP> To: "David A. Moon" <Moon%STONY-BROOK.SCRC.Symbolics.COM@multimax> Cc: cl-cleanup%SAIL.STANFORD.EDU@multimax Subject: Re: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT In-Reply-To: Your message of Sun, 06 Mar 88 15:41:00 -0500. Date: Wed, 09 Mar 88 15:49:01 EST From: Dan L. Pierson <pierson@mist> Date: Sun, 6 Mar 88 15:41 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> I don't think so. For example, the proposal only mentions LET. This is obviously incomplete. It should at least mention LET*. But what about the LAMBDA combination that is almost equivalent to LET? What about other binding forms such as DO? What about other bindings besides variables, such as MACROLET, FLET, and BLOCK? I think the proposal needs much more careful attention to how narrow or broad its scope is supposed to be. Understand that I do not object to the change proposed by this proposal. I think that that change is going to be part of the real proposal; I just don't think it makes sense to do that one change by itself. I certainly agree with at least the first part of this; I should have covered at least LET* in the original proposal. While the next edition should include all of the areas mentioned above, I think that the it may be best to explicitly not support some of them if the current vague definition of "top level" stands. More generally, I think this proposal is patching Common Lisp's ill-defined notion of "top level" instead of fixing it. While there are some practical benefits to the patch, as it makes a small increase in the number of programs that are portable, I don't think it really solves the problem. In practical terms, I can't see asking my compiler people to spend time implementing this when it's obvious that this is an interim change and something better is, or should be, on its way. I'd rather they spend their energies elsewhere until Common Lisp has really got its act together on this "top level form" business, and then they can implement what is really the right thing. There seems to be a lot of general agreement on this. Is it a cleanup or compiler issue (or *the* compiler issue)? If this proposal were presented in its current form, I would oppose it. No amount of wording changes would change my position. I want to see a broader proposal. Does this mean that you would oppose anything that didn't include a fixed definition of "top level"? If so, do you think that such a fix is a required part of the standard we're working on or that standardizing the status quo is preferable to any halfway measures? ∂09-Mar-88 1710 CL-Cleanup-mailer Issue: [Not Really] LET-TOP-LEVEL (version 1) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 17:10:41 PST Received: by labrea.Stanford.EDU; Wed, 9 Mar 88 17:11:24 PST Received: from bhopal.lucid.com by edsel id AA14086g; Wed, 9 Mar 88 16:14:10 PST Received: by bhopal id AA09209g; Wed, 9 Mar 88 16:20:49 PST Date: Wed, 9 Mar 88 16:20:49 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803100020.AA09209@bhopal.lucid.com> To: PADGET@rand-unix.rand.org Cc: cl-cleanup@sail.Stanford.EDU In-Reply-To: jap%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK's message of Wed, 9 Mar 88 17:51:45 GMT <8803091808.AA12684@edsel.lucid.com> Subject: Issue: [Not Really] LET-TOP-LEVEL (version 1) My apologies for not remembering earlier your presentation at Fort Collins. [I may have even made some comment about the desirablity of documenting the notion of "lexical shielding" in some macro expansions -- such as for DEFSUBST -- while still permitting "lexical capturing" in more general cases. Also, last month, I privately sent you some macro examples wherein "lexical capturing" was put to productive use.] Yes indeed, I'd feel quite uncomfortable if the future of macros in the Lisp world were to be relegated to some kind of "pre-processor" status. Shades of C-level programing! But as I mentioned to Kent the other day, there has just got to be some theory of definition and use that makes it easy to understand what's reasonable and doable, and helps the naive user avoid troublesome situations. -- JonL -- ∂09-Mar-88 1711 CL-Cleanup-mailer PROCLAIM [and "lexical scoping"?] Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 9 Mar 88 17:11:37 PST Received: by labrea.Stanford.EDU; Wed, 9 Mar 88 17:12:21 PST Received: from bhopal.lucid.com by edsel id AA14195g; Wed, 9 Mar 88 16:42:42 PST Received: by bhopal id AA09327g; Wed, 9 Mar 88 16:49:12 PST Date: Wed, 9 Mar 88 16:49:12 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803100049.AA09327@bhopal.lucid.com> To: vanroggen@hudson.dec.com Cc: cl-compiler@sail.Stanford.EDU, cl-cleanup@sail.Stanford.EDU In-Reply-To: "AITG::VANROGGEN"'s message of 9 Mar 88 15:01:00 EDT <8803092111.AA13223@edsel.lucid.com> Subject: PROCLAIM [and "lexical scoping"?] I tend to agree with your feelings about non-DEFUN forms in a file -- that it's undesirable to have them all implicitly eval-when(eval compile). At worst, one might want to include PROCLAIM in with the 7-extremely-randoms -- perhaps as the eighth wonder of the randomness world. On the other hand, I see lots of need for a lexical file proclaim. This would be a good time to define something that has DECLARE syntax (i.e., isn't a function that "evaluates its arguments") but which also has PROCLAIM pervasiveness within a file. The reason I call it "lexical file proclaim" is that I want it to affect only the lexically-apparent code in the file in which it is found at top level (for whatever it means to be "at top level"). So unlike current PROCLAIM, it would not affect the evaluation of random Lisp forms during, say, macro expansion, or during a sub-recursive call to COMPILE-FILE, etc. On the other hand, unlike current semantics for (LOCALLY (DECLARE (SPECIAL ...)) ...), it's effect would be "pervasive". Would information from "lexical, file-proclaim" affect the code produced by macroexpansions? after all, such code isn't "lexically apparent" in the file? This issue is no different than the current controversy about whether macro-expansion produced code should be "captured" by the lexical environment surrounding it, or whether it should be insulated from it. Thus this controversy should be left to the macro committee, or whatever other body addresses it; it's independent of compile-file semantics. What is a file such that "lexical file-proclaim" makes sense. Again, I think the answer is to defer to COMPILE-FILE; whatever it thinks a "file" is, then that is what the scope of "lexical file-proclaim" is. -- JonL -- ∂11-Mar-88 1031 CL-Cleanup-mailer Issue: EVAL-OTHER (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 88 10:31:02 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 361116; 11 Mar 88 13:31:02 EST Date: Fri, 11 Mar 88 13:30 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: EVAL-OTHER (Version 1) To: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <19880307212550.8.MOON@EUPHRATES.SCRC.Symbolics.COM>, <19880307234416.7.MLY@Bullwinkle.Palladian.COM>, <8712181940.AA22225@tekchips.TEK.COM> Message-ID: <19880311183058.7.MOON@EUPHRATES.SCRC.Symbolics.COM> Here's the message I was thinking of (thanks, Richard). By the way, I don't buy Will's argument...I don't think making evaluating a function or a closure an error will detect a very large fraction of the errors typically made with backquote. I know it would detect almost none of the errors I make, which are usually to evaluate something at the wrong time rather than to evaluate something that should not have been evaluated at any time. Just some input. Date: Mon, 7 Mar 88 18:44 EST From: Richard Mlynarik <Mly@JASPER.Palladian.COM> Date: Mon, 7 Mar 88 16:25 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> I remember this issue being discussed only a few months ago on either Common-Lisp or CL-Cleanup. I think somebody had some reasons to oppose this proposal, but I don't remember finding them convincing. Sorry I don't remember any of the details, I mention it because perhaps this will stimulate someone else's memory. To: Fahlman@C.CS.CMU.EDU Cc: Moon@SCRC-STONY-BROOK.ARPA, CL-CLEANUP@SAIL.STANFORD.EDU, willc%tekchips.tek.com@RELAY.CS.NET Subject: whether random objects self-evaluate (was cleaup issues from Japan) In-Reply-To: Your message of Thu, 17 Dec 1987 21:12 EST. <FAHLMAN.12359327290.BABYL@C.CS.CMU.EDU> Date: 18 Dec 87 11:40:02 PST (Fri) From: willc%tekchips.tek.com@RELAY.CS.NET Let me report on the Scheme situation and my experience. As in Common Lisp, it is "an error" to evaluate a random object, but most implementations extend the language by allowing at least some random objects (notably the empty list, since only a few implementations yet distinguish the empty list from #f) to evaluate to themselves. MacScheme allows all random objects to evaluate to themselves, but unlike Symbolics I have found this to be a (minor) problem, and I recommend that implementors avoid my mistake. The problem: In writing a macro using backquote I sometimes leave out a quote mark, insert an extra comma, or put a comma in the wrong place. Then an expanded macro can look like (... #<PROCEDURE> ...) when I wanted it to look like (... '#<PROCEDURE foo> ...) or (... (lambda (...) ...) ...). I would like to get an error message from the incremental compiler, because I never deliberately write code with unquoted procedures, but with self-evaluating procedures no error will occur until the expression is executed, and then the values seen in the debugger can seem very strange. In my code, this kind of macro bug almost always shows up as a procedure that was closed in the wrong environment, but if I'm unlucky the incorrect procedure will pass control to an altogether unfamiliar part of the system before trapping on some unrelated error such as taking the car of the empty list. As better macro facilities become more universal, this is of course becoming less of a problem. Peace, Will ∂11-Mar-88 1039 CL-Cleanup-mailer Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 88 10:39:31 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361128; Fri 11-Mar-88 13:39:35 EST Date: Fri, 11 Mar 88 13:39 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: MAPPING-DESTRUCTIVE-INTERACTION (Version 1) To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880307162443.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880311183925.8.MOON@EUPHRATES.SCRC.Symbolics.COM> I favor the general idea of MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE, but I have two comments: Do we want to follow the lead of MAPHASH in explicitly defining that destructive operations are permissible on the entry currently being processed? For example, is (let ((l (list 0 1 2 3 4))) (dolist (x l) (when (oddp x) (setq l (delete x l)))) l) a valid program that returns (0 2 4)? Note that making this valid seems to imply a restriction on the implementation of DOLIST, that it must call CDR before evaluating the body, not after. Personally I don't care whether this practice is allowed or forbidden. Being consistent with MAPHASH might lead to a clearer language. The proposal needs to be expanded to include a complete list of the functions affected. It also needs a clearer definition of which destructive operations it covers. For example, I imagine your intention was to forbid SETF of CDR but to allow SETF of CAR, inside of DOLIST. However, you didn't say that explicitly. What about destructive operations on vectors? ∂11-Mar-88 1043 CL-Cleanup-mailer Issue: LAMBDA-LIST-DUPLICATES (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 88 10:42:52 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361130; Fri 11-Mar-88 13:43:10 EST Date: Fri, 11 Mar 88 13:43 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1) To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880307150614.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880311184311.9.MOON@EUPHRATES.SCRC.Symbolics.COM> I oppose LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE; I think Common Lisp should continue to forbid binding the same variable more than once in the same binding form. I have two reasons: 1. This is an unnecessary complication of the language rules. Allowing duplicated variable names doesn't make it possible to write programs that you couldn't write before, it just allows the programs to be written in a more obscure way. 2. This would result in an unnecessary complication of the scoping rules for DECLARE. Common Lisp would have to define what happens when a DECLARE of a variable is attached to a form that binds more than one variable with the declared name. ∂11-Mar-88 1045 CL-Cleanup-mailer Re: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 11 Mar 88 10:45:17 PST Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 237092; Fri 11-Mar-88 13:21:12 EST Date: Fri, 11 Mar 88 13:21 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Re: Issues: LET-TOP-LEVEL (version 1) vs DEFMACRO-BODY-LEXICAL-ENVIRONMENT To: Dan L. Pierson <pierson%mist@MULTIMAX.ARPA> cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8803092049.AA09416@mist.UUCP> Message-ID: <19880311182108.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 09 Mar 88 15:49:01 EST From: Dan L. Pierson <pierson@mist> Date: Sun, 6 Mar 88 15:41 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> If this proposal were presented in its current form, I would oppose it. No amount of wording changes would change my position. I want to see a broader proposal. Does this mean that you would oppose anything that didn't include a fixed definition of "top level"? I'm not sure. It may be that a broader proposal that was more explicit about its scope could still avoid precisely defining "top level", however it does not seem likely. I suppose that means the answer is a conditional yes. If so, do you think that such a fix is a required part of the standard we're working on or that standardizing the status quo is preferable to any halfway measures? I don't see how we could standardize the status quo, since nobody seems to be able to figure out what the status quo is. I'm not sure what "required" means in practice. I suspect a successful standard could continue to duck the issue of the meaning of "top level"; after all, ducking that issue hasn't killed the de facto Common Lisp standard. Obviously, though, it would be better to tackle the issue. I would have hoped that the compiler committee would have solved this issue six months ago, but unfortunately that committee doesn't seem to do much. ∂12-Mar-88 1527 CL-Cleanup-mailer New issue: STEP-ENVIRONMENT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Mar 88 15:27:18 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361805; Sat 12-Mar-88 18:27:05 EST Date: Sat, 12 Mar 88 18:26 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: New issue: STEP-ENVIRONMENT To: CL-Cleanup@SAIL.STANFORD.EDU Message-ID: <19880312232651.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Issue: STEP-ENVIRONMENT References: STEP (CLtL p.441) TIME (CLtL p.441) Category: CLARIFICATION Edit history: Version 1, 12-Mar-88, Moon Problem description: CLtL does not specify in what lexical environment the form given to STEP is evaluated. Some people think it's supposed to be evaluated in the null environment, others think it is supposed to be evaluated in the current environment, the one in which the STEP form was evaluated. The same considerations apply to TIME. An additional problem is that CLtL says that STEP is a macro. However, it is unclear what portable expression the macro could expand into, especially if STEP evaluates the form in the current environment. STEP is really a variation of the Lisp interpreter, which makes it more like a special form than like a macro. The interaction of STEP with the compiler is not specified. Proposal (STEP-ENVIRONMENT:CURRENT): 1. Clarify that STEP and TIME evaluate the form in the current environment. 2. Change STEP from a macro to a special form. 3. Clarify that it is an error to compile a STEP form. Test Cases/Examples: ;Assuming X is not a special variable (setq x 1) (let ((x 2)) (step (print x))) This should print and return 2, not 1, when interpreted. Rationale: 1. It is more useful for the lexical environment to pass transparently through STEP and TIME than to reset to the null environment. 2. STEP is really a variation of the Lisp interpreter, which makes it more like a special form than like a macro. 3. As a debugging TOOL, STEP forms do not need to be compiled. It would be difficult to specify precisely what should happen when a STEP form is compiled (which parts of the form are to be executed interpretively), so it's easier to duck the issue. Use "is an error" rather than "signals an error" so that compile-only implementations are permitted to compile STEP forms. Current practice: Symbolics Common Lisp behaves as proposed. Cost to Implementors: 1 requires passing an environment around, which should be easy. 2 and 3 are just restrictions, so they should cost nothing. Cost to Users: None. Cost of non-adoption: These debugging tools will continue to have vague specifications. Benefits: Slightly more preicse specification of Common Lisp. Esthetics: Slightly improved. Discussion: None yet. ∂12-Mar-88 1600 CL-Cleanup-mailer New issue: DEFPACKAGE Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Mar 88 15:59:58 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361817; Sat 12-Mar-88 19:00:11 EST Date: Sat, 12 Mar 88 19:00 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: New issue: DEFPACKAGE To: CL-Cleanup@SAIL.STANFORD.EDU Message-ID: <19880313000007.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Issue: DEFPACKAGE References: CLtL section 11.7. Category: ADDITION Edit history: Version 1, 12-Mar-88, Moon Problem description: The package functions included in CLtL encourage a programming style that tends to evoke the worst aspects of the package system. The problem is that if the definition of a package is scattered through a program, as a number of individual forms, it is very easy to read a symbol before the package setup needed to read that symbol correctly has been accomplished. Three examples: an inherited symbol that should have been shadowed might be accessed; a single-colon prefix might be used for a symbol that will later be exported, causing an error; a local symbol might be accessed where a symbol that will later be imported or inherited was intended. These problems can be difficult to understand or even to recognize, are difficult to recover from without completely restarting the Lisp, and give Common Lisp a bad name. Proposal (DEFPACKAGE:ADDITION): Add a DEFPACKAGE macro to the language. It encourages putting the entire definition of a package in a single place. It also encourages putting all the package definitions of a program in a single file, which can be loaded before loading or compiling anything that depends on those packages. In addition, it allows a programming environment to process the whole package setup as a unit, providing better error-checking and more assistance with package problems, by dint of global knowledge of the package setup. Also expand MAKE-PACKAGE and IN-PACKAGE to take all the same keyword arguments as DEFPACKAGE, for consistency. The syntax of DEFPACKAGE is (DEFPACKAGE package-name {option}*) where each option is either a keyword or a list of a keyword and arguments. A keyword standing by itself is an abbreviation for a list (keyword T). Nothing in a DEFPACKAGE form is evaluated. package-name is a symbol or a string; if a symbol, only its name matters. Standard options for DEFPACKAGE are as follows; additional options might be present in an implementation, and each implementation must signal an error if an option not recognized by that implementation is present. Each option may appear at most once. (:EXPORT {symbol/string}*) Create symbols with the specified names and export them. (:IMPORT {symbol}*) Import the specified symbols. (:IMPORT-FROM {(package-name {symbol/string}*)}*) (:IMPORT-FROM package-name {symbol/string}*) Find the specified symbols in the specified packages and import them into the package being defined. The second syntax is a convenient abbreviation when only one package is specified. (:NICKNAMES {package-name}*) Set the package's nicknames to the specified strings. (:SHADOW {symbol/string}*) Create the specified symbols in the package and place them on the shadowing list. (:SHADOWING-IMPORT {symbol}*) Import the specified symbols into the package and make them shadow any inherited symbols. (:SIZE integer) Declare the approximate number of symbols expected in the package. (:USE {package}*) Inherit from the specified packages. Example: (DEFPACKAGE MY-PACKAGE (:USE LISP) (:SHADOW CAR CDR CONS) (:NICKNAMES MP MYPKG) (:PREFIX-NAME MYPKG)) Rationale: See first paragraph of Proposal section. Current practice: Symbolics Common Lisp has always had this, and uses it in preference to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL version of DEFPACKAGE has quite a few additional options, but none of them appear to be necessary to propose for Common Lisp at this time. Cost to Implementors: Should be small as the macro can be implemented simply as a bunch of calls to existing functions. Cost to Users: No cost, this is upward compatible. Cost of non-adoption: Packages continue to be difficult to use correctly. Benefits: Guide users away from using packages in ways that get them into trouble. Esthetics: Neutral. Discussion: The "Put in seven extremely random user interface commands" business described at the end of chapter 11 could be removed, and the special compiler handling of these functions necessary to support that could be removed. As this would be an incompatible change, it is not part of this proposal. ∂12-Mar-88 1614 CL-Cleanup-mailer New issue: DEFPACKAGE Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Mar 88 16:14:22 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361822; Sat 12-Mar-88 19:14:43 EST Date: Sat, 12 Mar 88 19:14 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: New issue: DEFPACKAGE To: Moon@STONY-BROOK.SCRC.Symbolics.COM cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU References: <19880313000007.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <880312191420.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I support the general idea of this proposal, but have a few nits to pick... * I think IN-PACKAGE is broken for being able to demand-create a package. It serves two unrelated roles, one of which being selection and the other being creation. Extending it to allow more keywords will worsen the problem. Given DEFPACKAGE, I would rather see IN-PACKAGE incompatibly changed to NOT allow demand creation. This would fix a lot of bugs. * There might should be a :SHADOWING-IMPORT-FROM. * I think that all options listed as symbol/string should be string-only. People should be discouraged from naming symbols before the package structure is fully in place. I'll stop short of suggesting that :IMPORT-FROM and :SHADOWING-IMPORT-FROM completely replace :IMPORT and :SHADOWING-IMPORT, which still muck with symbols. * I'm surprised you left out the Genera :INCLUDE feature, but I guess that could always be added later if it was seen to be desired so it's ok. * :PREFIX-NAME is mentioned only in the same. To have it in an integrated fashion, you'd need a PACKAGE-PREFIX-NAME function and some discussion of that it was automatically a nickname if not explicitly in the list of names or nicknames. I'm in a hurry so didn't write much on each of these. I can elaborate on any that are found to be not clear. ∂12-Mar-88 1646 CL-Cleanup-mailer New issue: DEFPACKAGE Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 12 Mar 88 16:46:24 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Sat 12 Mar 88 19:47:02-EST Date: Sat, 12 Mar 1988 19:46 EST Message-ID: <FAHLMAN.12381856106.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: CL-Cleanup@SAIL.STANFORD.EDU Subject: New issue: DEFPACKAGE In-reply-to: Msg of 12 Mar 1988 19:00-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM> In response to David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM> This looks good, as far as it goes, and the fact that it has actually been tested in practice is a big plus -- it tends to give one confidence that nothign critical has been overlooked. I'm a bit uneasy about the syntax that you propose for the options. It would be more compatible with the rest of Common Lisp to use alternating keywords and arguments. Some users may find the odd syntax of your DEFPACKAGE to be confusing. Is there some real advantage to the syntax you propose, or is this just a bit of Zetalisp culture peeking through? -- Scott ∂12-Mar-88 1702 CL-Cleanup-mailer Issue: SETF-FUNCTION-VS-MACRO (version 3) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Mar 88 17:02:51 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361839; Sat 12-Mar-88 20:03:09 EST Date: Sat, 12 Mar 88 20:02 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: SETF-FUNCTION-VS-MACRO (version 3) To: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880214-134110-1441@Xerox> Message-ID: <880312200240.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> [X3J13 removed.] I support many ideas of this proposal, but I have two gripes which make me have to oppose it: * I can't deal with the idea of generalizing SYMBOL-FUNCTION. I would like to see FDEFINITION introduced and SYMBOL-FUNCTION left alone. * I'm also a little leary about TRACE being extended this way because (TRACE (a list)) might later want to be interpreted as options rather than as a function spec and I'd rather not have to risk heuristic resolution. I would rather someone right now introduce a generalized syntax for TRACE with syntactic space for trace options, such as (TRACE (fn . options) (fn . options) (fn . options)) and then allow the generalized (non-symbol) fn to only occur within that syntax so that no ambiguity results. ∂12-Mar-88 1808 CL-Cleanup-mailer Issue: LAST-N (Version 2) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Mar 88 18:07:58 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 361856; Sat 12-Mar-88 21:08:14 EST Date: Sat, 12 Mar 88 21:07 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: LAST-N (Version 2) To: CL-Cleanup@SAIL.Stanford.EDU cc: KMP@STONY-BROOK.SCRC.Symbolics.COM In-Reply-To: <871204164910.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <880312210753.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Issue: LAST-N References: LAST (p267) Category: ENHANCEMENT Edit history: 04-Dec-87, Version 1 by Pitman, 12-Mar-88, Version 2 by Pitman Status: For Internal Discussion Problem Description: People always ask why LAST returns a cons and not an element. BUTLAST takes an argument N but LAST does not. Proposal (LAST-N:ALLOW-OPTIONAL-ARGUMENT): Allow LAST to take an optional argument N, saying how many cells to return. The default for N would be 1. It is an error if N is negative or L is circular. If N is zero, then the atom that terminates the list L is returned. If N is greater than or equal to the number of cons cells in the list L, then the result is L. Test Cases: (LAST '(A B C) 0) => () (BUTLAST '(A B C) 0) => (A B C) (LAST '(A B C) 1) => (C) (BUTLAST '(A B C) 1) => (A B) (LAST '(A B C) 2) => (B C) (BUTLAST '(A B C) 2) => (A) (LAST '(A B C) 3) => (A B C) (BUTLAST '(A B C) 3) => () (LAST '(A B C) 4) => (A B C) (BUTLAST '(A B C) 4) => () (LAST '(A B C)) => (C) (BUTLAST '(A B C)) => (A B) (LAST '(A . B) 0) => B (LAST '(A . B) 1) => (A . B) (LAST '(A . B) 2) => (A . B) Rationale: BUTLAST and LAST would select complementary parts of a list in general. That is (EQUAL L (APPEND (BUTLAST L N) (LAST L N))) would be T for N >= 0 and L being a proper list. This would make it more obvious why LAST should return a list and not an element. ie, it would return the "last N elements" where N=1 by default. Current Practice: Probably nobody does this. Adoption Cost: Very slight. The following code would suffice: (DEFUN LAST (LIST &OPTIONAL (N 1)) (CHECK-TYPE N (INTEGER 0)) (DO ((L LIST (CDR L)) (R LIST) (I 0 (+ I 1))) ((ATOM L) R) (IF (>= I N) (POP R)))) Some implementations might want to provide compiler optimizations for the N=1 case. Benefits: This utility is probably needed often enough to warrant its inclusion. It's present (as a separate function called NLEFT) in Symbolics Common Lisp and Interlisp. Conversion Cost: None. This is an upward compatible extension. Aesthetics: This would make things a little prettier. Discussion: This suggestion came up recently on a Symbolics design discussion list. Symbolics is contemplating offering it as an extension, but it seemed like the rest of the CL community might want to adopt it, too. Pitman thinks it's a nice idea. Masinter opposes this extension as gratuitous. Moon and Daniels think this is very low priority but have expressed a lack of major objection to this proposal. ∂13-Mar-88 1637 CL-Cleanup-mailer Re: New issue: DEFPACKAGE Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Mar 88 16:37:12 PST Received: from Salvador.ms by ArpaGateway.ms ; 13 MAR 88 16:31:47 PST Date: Sun, 13 Mar 88 16:31:26 PST From: Pavel.pa@Xerox.COM Subject: Re: New issue: DEFPACKAGE In-reply-to: <19880313000007.3.MOON@EUPHRATES.SCRC.Symbolics.COM> To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Cc: CL-Cleanup@SAIL.STANFORD.EDU Message-ID: <880313-163147-1810@Xerox> Just a nit for the moment: A keyword standing by itself is an abbreviation for a list (keyword T).'' This doesn't appear to be very useful, since none of the options will commonly want to have an option-argument of T. Pavel ∂14-Mar-88 0007 CL-Cleanup-mailer Re: the array type mess.... Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 88 00:07:20 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 88 00:08:03 PST Date: 14 Mar 88 00:07 PST From: Masinter.pa@Xerox.COM Subject: Re: the array type mess.... In-reply-to: various To: cl-cleanup@Sail.stanford.edu Message-ID: <880314-000803-1132@Xerox> This issue is now called "ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS", i.e., the semantics of element types in ARRAY type descriptors. It is listed as "needs volunteer". I think we understand the problem sufficiently to attempt a writeup, and we've heard several different proposals, discarded some but not all. ∂14-Mar-88 0013 CL-Cleanup-mailer Current issue status Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 88 00:12:49 PST Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 88 00:13:30 PST Date: 14 Mar 88 00:13 PST From: Masinter.pa@Xerox.COM Subject: Current issue status to: CL-CLEANUP@Sail.Stanford.EDU cc: Masinter.pa@Xerox.COM Message-ID: <880314-001330-1136@Xerox> This is my updated list of issue status. ! This is the list of issues distributed for the March 1988 X3J13 meeting: - ADJUST-ARRAY-DISPLACEMENT (Version 4, 23-Nov-87) (Interaction of ADJUST-ARRAY and displaced arrays) - APPEND-DOTTED (Version 5, 14-Jan-88) (What happens to CDR of last CONS? in other than last arg?) - AREF-1D (Version 7, 14-Nov-87) (Add a new function for accessing arrays with row-major-index) Version 5 conditionally passed X3J13/Jun87 Version 7 passed X3j13/Nov87 - ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87) (Extend ASSOC-IF, etc. to allow :KEY) - COLON-NUMBER (Version 1, 22-oct-87) (Is :1 a number, a symbol, or undefined?) Version 1 passed X3J13/Nov87 - COMPILER-WARNING-BREAK (Version 4,23-Nov-87 ) (Does *BREAK-ON-WARNING* affect the compiler?) <<<Too vague, current opposition.>>> - DECLARE-MACROS (Version 3, 5-FEB-88) (Disallow macros expanding into declarations.) - DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87) (Documentation string is not evaluated.) - DISASSEMBLE-SIDE-EFFECT (version 3, 21 Jan 88) (DISASSEMBLE doesn't smash the def if not compiled) <<<VAXLisp Current Practice wrong.>>> - DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87) ( DO-SYMBOLS can the same symbol twice?) <<<The rationale contains a typo: DO-PACKAGE for DO-SYMBOLS>>> - DRIBBLE-TECHNIQUE (Version 2, 14-Feb-88) (dribble can't be used programmatically) <<<VAXLisp Current Practice wrong.>>> - FLET-DECLARATION (Version 2, 2 Feb 88) (Allow declarations in FLET, MACROLET) - FORMAT-COMMA-INTERVAL (Version 2, 15 June 87) (paramerize number of digits between commas) Version 2 passed X3J13/Nov87 <<<example is bogus; that example was one of the better uses for the facility, too>>> - FORMAT-COLON-UPARROW-SCOPE (Version 3, 5 Feb 88) (what iteration does ~:↑ exit from?) - FUNCTION-TYPE-KEY-NAME (Version 3, 5 Feb 88) (allow &KEY (:KEYNAME type)) in FUNCTION decls ) - FUNCTION-TYPE-REST-LIST-ELEMENT (Version 3, 13-Feb-88) (allow &rest <type> in function types to refer to element type) <<<Discussion, objections, etc.>>> - FUNCTION-TYPE (Version 9, 13-Feb-88) (Change definition of FUNCTIONP, function type ...) <<<STRICT-REDEFINITION has typo, 1a 6 PROCEDURE => FUNCTION. COMPILED-FUNCTION optional subtype "compiled" implementation-dependent.>>> - GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87) (Environment argument for GET-SETF-METHOD) Version 4 conditionally passed X3J13/Jun87. Version 5 passed X3J13/Nov87. - KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87) (&KEY arguments not in keyword package?) Version 6 conditionally passed X3J13/Jun87. Version 8 passed X3J13/Nov87 - PATHNAME-STREAM (Version 6, 14-Nov-87) (PATHNAME only works on file streams) Version 2 conditionally passed X3J13/Jun 87 Version 6 passed X3J13/Nov 87 - PATHNAME-SYMBOL (Version 5, 5-Feb-88) (Do symbols automaticly coerce to pathnames?) - PUSH-EVALUATION-ORDER (Version 5,25-Nov-87) (What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?) - REDUCE-ARGUMENT-EXTRACTION (version 3, 13-Feb-88) (Add :KEY to REDUCE) - SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87) (Allow (DEFUN (SETF FOO) ..)) <<<Don't like SYMBOL-FUNCTION, TRACE extension.>>> - SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5, 5-Feb-88) (let FIND, SUBSTITUTE etc work on multi-dimensional arrays) <<<VanRoggen opposes as stands.>>> - SHADOW-ALREADY-PRESENT (Version 4, 10-Nov-87 23:59:43) (What does SHADOW do if symbol is already there?) - SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87) (*FEATURES* are in the keyword package) ! The following issues were mailed prior to the June 1987 meeting and passed at that meeting; they will not be distributed again except by request. - COMPILER-WARNING-STREAM (Version 6, 5-Jun-87) (Compiler warnings are printed on *ERROR-OUTPUT*) Version 6 passed X3J13/Jun87 - DEFVAR-INIT-TIME (Version 2, 29-May-87) (DEFVAR initializes when evaluated, not later.) Version 2 passed X3J13/Jun87. - DEFVAR-INITIALIZATION (Version 4, Jun-87) ((DEFVAR var) doesn't initialize) Version 4 pased X3J13, Jun87. - FLET-IMPLICIT-BLOCK (Version 6, 5-Jun-87) (do FLETs have implicit named blocks around them?) Version 6 passed X3J13/Jun87. - FORMAT-ATSIGN-COLON (Version 4, 5-jun-87) (@: == :@ in format) Version 4 passed X3J13/Jun87. - FORMAT-OP-C (Version 5, 11-Jun-87) (What does ~C do?) Version 5 passed X3J13/Jun87. - IMPORT-SETF-SYMBOL-PACKAGE (Version 5, 11-Jun-87) (Does IMPORT affect home package?) Version 5 passed X3J13/Jun87. - PRINC-CHARACTER (Version 3) (PRINC behavior on character objections) Version 3 passed X3J13/Jun87. ! For your information only, the following issues are still under consideration by the cleanup committee. Volunteers to help out with the preparation of issue writeups are welcome. If you would like to review the mail discussion on a given topic, please let me know and I will forward it to you. - ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (What does (ARRAY FROB) mean?) In discussion, needs volunteer - ADJUST-ARRAY-FILL-POINTER (Interaction of Adjust-ARRAY and fill pointers.) Need volunteer to write up. - COERCE-INCOMPLETE (Version 1, 28-Feb-88) (Extend COERCE to handle default coercions.) - CONSTANT-SIDE-EFFECTS (not yet submitted) (It is an error to do destructive operations on constants in code, defconstant.) Discussed 12/86 - 1/87 Will take on if no compiler proposal - DATA-TYPES-HIERARCHY-UNDERSPECIFIED (not yet submitted) (Should STREAM, PACKAGE, PATHNAME, READTABLE, RANDOM-STATE be required to be disjoint from other types?) From CLOS committee, not yet submitted - DECLARATION-SCOPE (Version 2, 2-Feb-88) (What is the scope of SPECIAL declarations? INLINE declarations? where can declarations be placed?) Ready for release? - DECLARE-TYPE-EXACT (from Kempf as EXACT-CLASS) (Want to be able to declare (EQ (TYPE-OF X) 'Y), i.e., not a subclass.) Useful after CLOS - DEFINITION-FUNCTIONS (not yet submitted) JonL will submit, really "definition-delete" or some such - DEFMACRO-BODY-LEXICAL-ENVIRONMENT (not yet submitted) What is the lexical environment of DEFTYPE, DEFINE-SETF bodies? Mail 11-12 Oct 87 on common-lisp Interacts with compiler proposal? - DEFPACKAGE (Version 1) (Add DEFPACKAGE form.) - DEFSTRUCT-SLOTS-CONSTRAINTS (not yet submitted/issues file) (p 307) "Allow a call to DEFSTRUCT to have no slot-descriptions. Specify that it is an error for two slots in a single DEFSTRUCT to have the same name. If structure A includes structure B, then no additional slot of A may have the same name as any slot of B." Need volunteer to sort out DEFSTRUCT issues post-CLOS. - DEFSTRUCT-DEFAULT-VALUE-EVALUATION (not yet submitted/issues file) (p 305) "The default value in a defstruct slot is not evaluated unless it is needed in the creation of a particular structure instance. If it is never needed, there can be no type-mismatch error, even if the type of the slot is specified, and no warning should be issued." Need volunteer to sort out DEFSTRUCT issues post-CLOS. - EQUAL-STRUCTURE (not yet submitted) (Mail Nov 87 on Common Lisp: EQUAL on DEFSTRUCT structures.) What do EQUAL EQUALP and friends do on structures? (Need volunteer. ALarson@HI-MULTICS.Arpa, edsel!jonl@labrea.stanford.edu, Okuno@SUMEX-AIM.STANFORD.EDU, goldman@vaxa.isi.EDU?) - EVAL-OTHER (Version 1, 07-Mar-88) (Allow other data types to self-evaluate.) - EXPORT-IMPORT (Version 2, ?) ??? Status, opinions? - FILE-LENGTH-PATHNAME (not submitted, from ISSUES.TXT) (P 425) "Generalize FILE-LENGTH to accept any filename, not just an open file-stream. Let it take a keyword argument :ELEMENT-TYPE, defaulting to STRING-CHAR for non-stream arguments and to the element-type of the stream for a stream argument." Need volunteer to write up. - FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no formal proposal) (What does FILE-WRITE-DATE do if no such file?) "there should not be a formal proposal for fixing the file-write-date ambiguity until we are at the point where we can make proposals that discuss signalling named conditions. " Need volunteer. - FORMAT-NEGATIVE-PARAMETERS (mail 19 May 87, no formal proposal) "format parameters are assumed to be non-negative integers except as specifically stated" Need volunteer. - FUNCTION-ARGUMENT-TYPE-SEMANTICS (not yet submitted) (Change semantics of argument types in function declarations.) - FUNCTION-SPECS (not yet submitted) (add "function specs" for defun, trace etc) beyond SETF-FUNCTION-VS-MACRO. (SMH!franz@ucbarpa.berkeley.edu, JonL, RWK) - GC-MESSAGES (version 1) (Control over unsolicited GC messages in typescript) merge with other controls for unsolicited messages? - LAMBDA-LIST-DUPLICATES (Version 1, 07-Mar-88) (allow sequential non-iterative.) Moon opposes - LAST-N (version 2, 12-Mar-88) (Extend LAST to take an optional N) Ready for release? - LET-TOP-LEVEL (version 1) (clarification, not change?) - LISP-SYMBOL-REDEFINITION (no formal proposal yet) Is it legal to redefine symbols in the LISP package? Mail 14-Aug-87 Merge with SPECIAL-FORM-SHADOW Needs volunteer - LOAD-TIME-EVAL (Versin 4, 2 Feb 88) (evaluation when compiled file is loaded) - MACRO-FUNCTION-ENVIRONMENT (Add environment argument to MACRO-FUNCTION?) re-extracted from ENVIRONMENT-ARGUMENTS CLOS committee to submit? - MAPPING-DESTRUCTIVE-INTERACTION (Version 1, 08-Mar-88) ([don't] define interaction of DELETE on MAPCAR'd list.) (? extended, needs list of fns & operations covered.) - PATHNAME-SUBDIRECTORY-LIST (Version 1, 18-Jun-87) How to deal with subdirectory structures in pathname functions? make :DIRECTORY a list? Need volunteer to rewrite. - PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted) Mail Aug 87 discussion How to deal with logical devices, :unspecific components, etc in pathname functions RWK@YUKON.SCRC.Symbolics.COM may submit proposal. - PEEK-CHAR-READ-CHAR-ECHO (Version 1, 3 March 87) (interaction between PEEK-CHAR, READ-CHAR and streams made by MAKE-ECHO-STREAM) "Fixing echo streams is fine, but I don't think that it is appropriate for the standard to specify how terminal interaction must or even ought to work." - PROCLAIM-LEXICAL (Version 5, 14-Nov-87) (add LEXICAL, GLOBAL, CONSTANT proclaimation) some serious problems - PROMPT-FOR (Version 1) (add new function which prompts) Tabled until re-submitted. - REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87 ) (Specification of side-effect behavior in CL) DEFINED, VAGUE and IN-BETWEEN - REMF-MULTIPLE (Version 1, 26 Jan 88) (What does REMF do if it sees more than one INDICATOR?) - REQUIRE-PATHNAME-DEFAULTS (Version 1, 15-Oct-87) (where does REQUIRE look for files?) - REST-LIST-ALLOCATION (not yet submitted) (APPLY #'LIST X) == (COPY-LIST X)? need volunteer - SETF-METHOD-FOR-SYMBOL (Version 3, 11-Nov-87) (Change recommendation for (get-setf-method symbol)?) - SETF-SUB-METHODS (version 1, 12-Feb-88) (more careful definition of order of evaluation inside (SETF (GETF ...) ...) ) - SHARPSIGN-PLUS-MINUS-NUMBER (Is #+68000, #-3600 allowed?) Mild disagreement: it is an error? - SHARPSIGN-BACKSLASH-BITS (What does C-META-H-X mean?) Forwarded to character committee. - SPECIAL-FORM-SHADOW (no formal proposal) (Is it OK to shadow a special form with FLET, LABELS, MACROLET?) In discussion, no formal proposal submitted. - SPECIAL-VARIABLE-TEST (Version 1, 7-Mar-88) (Add SPECIALP) - STANDARD-INPUT-INITIAL-BINDING (Version 2, 29 Feb 88) (Change CLtL's wording about requirements for *ERROR-OUTPUT*, etc.) Moon comments appropriate. - STEP-PACKAGE (Version 1) (STEP isn't a macro, its a special form.) - STREAM-CLASS-ACCESS (No formal proposal) (Originally FOLLOW-SYNONYM-STREAM 19-DEC-86) Define stream accessors as if synonym-stream two-way-stream etc were CLOS classes? Allow stream to be specializable class? (MMcM mail.) Need volunteer - STRUCTURE-DEFINITION-ACCESS (No formal proposal) (access to slot accessors for DEFSTRUCT etc.) Need volunteer to write up - SUBSEQ-OUT-OF-BOUNDS (from ISSUES file, no formal proposal) (p 246) "Specify that it is an error for the SUBSEQ indices or any :START or :END argument have a negative index or point past the end of the sequence in question. (With respect to whether signalling is required, this error will be treated the same as array out-of-bounds.)" Need volunteer to write up - TAILP-NIL (no formal proposal yet) (Operation of TAILP given NIL) Needs writeup in current format. - TRACE-FUNCTION-ONLY (Version 5, 9-NOV-87) (Allow trace for SETF functions, macros, etc.) Environment extension? - UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3, 27-Oct-87) (What happens with non-local exits out of UNWIND-PROTECT cleanup clauses?) - VECTOR-PUSH-EXTEND-DEFAULT (no proposal yet) CLtL says that vectors are extended by a "reasonable" amount. What's that? ∂14-Mar-88 0110 CL-Cleanup-mailer New issue: STEP-ENVIRONMENT Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 01:09:55 PST Received: by labrea.Stanford.EDU; Mon, 14 Mar 88 01:10:35 PST Received: from kent-state.lucid.com by edsel id AA11298g; Mon, 14 Mar 88 00:57:17 PST Received: by kent-state id AA00535g; Mon, 14 Mar 88 01:06:06 PST Date: Mon, 14 Mar 88 01:06:06 PST From: Eric Benson <edsel!eb@labrea.Stanford.EDU> Message-Id: <8803140906.AA00535@kent-state.lucid.com> To: Moon@stony-brook.scrc.symbolics.com Cc: CL-Cleanup@sail.stanford.edu In-Reply-To: David A. Moon's message of Sat, 12 Mar 88 18:26 EST <19880312232651.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: New issue: STEP-ENVIRONMENT For Current Practice or an Implementation Note, this is the definition of TIME in Lucid Common Lisp: (defmacro time (form) (time-internal #'(lambda () ,form))) The function TIME-INTERNAL looks something like: (defun time-internal (thunk) (let ((before-time (get-time-state))) (unwind-protect (funcall thunk) (print-time-information before-time (get-time-state))))) The definition of STEP is similar. This is just to show that it is easy to get the right lexical environment even though TIME and STEP are macros. ∂14-Mar-88 0115 CL-Cleanup-mailer New issue: DEFPACKAGE Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 01:14:20 PST Received: by labrea.Stanford.EDU; Mon, 14 Mar 88 01:15:04 PST Received: from kent-state.lucid.com by edsel id AA11326g; Mon, 14 Mar 88 01:02:08 PST Received: by kent-state id AA00538g; Mon, 14 Mar 88 01:10:57 PST Date: Mon, 14 Mar 88 01:10:57 PST From: Eric Benson <edsel!eb@labrea.Stanford.EDU> Message-Id: <8803140910.AA00538@kent-state.lucid.com> To: Fahlman@c.cs.cmu.edu Cc: CL-Cleanup@sail.stanford.edu In-Reply-To: "Scott E. Fahlman"'s message of Sat, 12 Mar 1988 19:46 EST <FAHLMAN.12381856106.BABYL@C.CS.CMU.EDU> Subject: New issue: DEFPACKAGE Date: Sat, 12 Mar 1988 19:46 EST Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> In response to David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM> This looks good, as far as it goes, and the fact that it has actually been tested in practice is a big plus -- it tends to give one confidence that nothign critical has been overlooked. I'm a bit uneasy about the syntax that you propose for the options. It would be more compatible with the rest of Common Lisp to use alternating keywords and arguments. Some users may find the odd syntax of your DEFPACKAGE to be confusing. Is there some real advantage to the syntax you propose, or is this just a bit of Zetalisp culture peeking through? -- Scott This syntax resembles that used for DEFSTRUCT options, so it does have a precedent in CLtL. ∂14-Mar-88 0559 CL-Cleanup-mailer New issue: DEFPACKAGE Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 05:59:06 PST Received: from KLYTEMNESTRA.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 98596; Mon 14-Mar-88 08:59:27 EST Date: Mon, 14 Mar 88 08:59 EST From: Richard Mlynarik <MLY@AI.AI.MIT.EDU> Subject: New issue: DEFPACKAGE To: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <FAHLMAN.12381856106.BABYL@C.CS.CMU.EDU> Message-ID: <880314085910.1.MLY@KLYTEMNESTRA.AI.MIT.EDU> Date: Sat, 12 Mar 1988 19:46 EST From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> I'm a bit uneasy about the syntax that you propose for the options. It would be more compatible with the rest of Common Lisp to use alternating keywords and arguments. Some users may find the odd syntax of your DEFPACKAGE to be confusing. Is there some real advantage to the syntax you propose, or is this just a bit of Zetalisp culture peeking through? DEFSTRUCT (which nobody has ever accused of having non-odd' syntax) also suffers from the same non-&KEY-style. The saddest things is that this type of syntactical lossage has infected CLOS DEFxxx, probably because of the precedent in DEFFLAVOR. I personally dislike the whole style; unfortunately it seems that few others feel strongly enough about this issue to raise objections. [As an aside, I generally prefer not to use macros whose syntax I can't describe with destructuring lambda-list technology. Unfortunately, LET doesn't fit into this class, which I hope says something about missing &rest-destructuring functionality rather than about my own inconsistency.] When I implemented DEFPACKAGE some time ago I preferred and advertised &KEY-style, but also allowed "(:keyword option)"-style for compatibility. ∂14-Mar-88 0637 CL-Cleanup-mailer DEFPACKAGE syntax Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Mar 88 06:37:36 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Mon 14 Mar 88 09:38:01-EST Date: Mon, 14 Mar 1988 09:37 EST Message-ID: <FAHLMAN.12382269523.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: cl-cleanup@SAIL.STANFORD.EDU Subject: DEFPACKAGE syntax Yes, DEFSTRUCT has a syntax similar to what is proposed for DEFPACKAGE. In that case, people can see that DEFSTRUCT is so complex that the simple alternating keyword/value style wouldn't cut it. In DEFSTRUCT, the structure has its set of keyword values and each slot does as well. I see no such complexity in DEFPACKAGE, so the question is whether there is any reason we have to go to a less-familiar syntax in this case. I'm not going to fight to the death over this. I just thought it was needlessly confusing and thought I'd raise the issue while there was still time. On the other side of the balance is the convenience to part of the Common Lisp community of adopting a syntax compatible with the DEFPACKAGE they are already using. -- Scott ∂18-Mar-88 1405 CL-Cleanup-mailer Issue: ADJUST-ARRAY-FILL-POINTER (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Mar 88 14:05:00 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 366029; Fri 18-Mar-88 17:05:20 EST Date: Fri, 18 Mar 88 17:05 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: ADJUST-ARRAY-FILL-POINTER (Version 1) To: CL-Cleanup@SAIL.STANFORD.EDU Message-ID: <880318170509.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I wasn't quite sure what to write, so just kind of made something up. Is this what people were looking for? ----- Issue: ADJUST-ARRAY-FILL-POINTER References: ADJUST-ARRAY (p297) Category: CLARIFICATION Edit history: 15-Mar-88, Version 1 by Pitman Status: For Internal Discussion Problem Description: CLtL does not specify clearly the effect of ADJUST-ARRAY on the fill pointer. Proposal (ADJUST-ARRAY-FILL-POINTER:MINIMAL): Clarify that the :FILL-POINTER keyword argument to ADJUST-ARRAY is treated as follows... If :FILL-POINTER argument is not given, then the fill-pointer of the array to be adjusted (if any) is left alone. It is an error to adjust an array to a size smaller than its fill pointer without specifying the :FILL-POINTER option so that its fill-pointer is properly adjusted in the process. If supplied, the :FILL-POINTER argument must be either an integer between 0 and the new size of the array, the symbol T (indicating that the new size of the array should be used), or the symbol NIL (indicating that the fill pointer should left as it is -- as if the :FILL-POINTER option had not been specified). An error is signalled if a non-NIL value for :FILL-POINTER is supplied and the array to be adjusted does not already have a fill pointer. Test Case: (SETQ A1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T)) (SETQ A2 (ADJUST-ARRAY A1 4)) (FILL-POINTER A1) => 3 (FILL-POINTER A2) => 3 (SETQ B1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T)) (SETQ B2 (ADJUST-ARRAY B1 2 :FILL-POINTER 1)) (FILL-POINTER B1) => 1 (FILL-POINTER B2) => 1 (SETQ C1 (MAKE-ARRAY 5 :FILL-POINTER 3 :ADJUSTABLE T)) (SETQ C2 (ADJUST-ARRAY C1 2 :FILL-POINTER T)) (FILL-POINTER C1) => 2 (FILL-POINTER C2) => 2 (SETQ D1 (MAKE-ARRAY 5 :ADJUSTABLE T)) (SETQ D2 (ADJUST-ARRAY D1 2 :FILL-POINTER 2)) signals an error. (SETQ E1 (MAKE-ARRAY 5 :FILL-POINTER T :ADJUSTABLE T)) (SETQ E2 (ADJUST-ARRAY E1 4)) is an error. Rationale: This behavior must be more clearly defined if portable programs are going to be able to depend on it. Current Practice: Symbolics Lisp implements the proposal. In case "E", it does not signal an error. It simply leaves the illegal fill-pointer in place so that the programmer can correct it using (SETF (FILL-POINTER E2) ...) Cost to Implementors: Probably most implementations do not deviate significantly from the proposed behavior. The cost to implementors is probably very slight. Cost to Users: None. This clarifies a fuzzy area in the manual which users cannot currently depend upon. Cost of Non-Adoption: The interaction between ADJUST-ARRAY and fill-pointers would continue to be hazy, and portable programs would not be able to rely upon that behavior being consistent across implementations. Benefits: The cost of non-adoption would be avoided. Aesthetics: There is little if any aesthetic impact of this change. Discussion: Pitman volunteered to write this issue up for the Cleanup committee. He's not very passionate about the details one way or another, but figures it's a good idea that they be clarified. ∂18-Mar-88 1439 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Mar 88 14:39:05 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 366054; Fri 18-Mar-88 17:39:30 EST Date: Fri, 18 Mar 88 17:39 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: EQUAL-STRUCTURE (Version 1) To: CL-Cleanup@SAIL.STANFORD.EDU Message-ID: <880318173922.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> This is somewhat sketchy, but I thought I'd get it on the table as is and people could flesh it out as the discussion evolves... -kmp ----- Issue: EQUAL-STRUCTURE References: EQUAL (p80), EQUALP (p81) Category: CHANGE Edit history: 18-Mar-88, Version 1 by Pitman Status: For Internal Discussion Problem Description: The behavior of EQUAL and EQUALP on structures is a subject of controversy. At issue are whether these functions should descend the slots of structures or use simply the structure's primitive identity (i.e., EQ) to test for equivalence. Proposal (EQUAL-STRUCTURE:RADICAL): Remove EQUAL and EQUALP from the language. (Naturally, they could be retained as implementation-dependent extensions.) Rationale: The name "EQUAL" suggests something very generic. It conjures in the mind of the naive user the notion that there is a single, uniquely selected predicate which is always good for equality testing. In fact, there is a large space of useful equality predicates, each good for different applications, and the choice of the current definition of EQUAL is exceedingly arbitrary. Although the function chosen is sometimes quite useful and some work is occassionally saved by having it be defaultly available, confusion frequently results from its presence. Users for whom the operator is not appropriate are inclined to describe it as broken, rather than to recognize that it does a useful thing but that the application they have does not call for that useful thing. The thing which would be useful to them would not be useful in other situations. There is simply no unique solution. The absence of the operator EQUAL would cause people to think explicitly about what kind of equivalence is appropriate to their application, and to write something better suited to that application. As an aside, this same notion of uniqueness carries over to COPY. People have been observed to assert that a generic COPY function should be present for copying arbitrary objects. A single COPY function is not provided because there are many kinds of copying and no single function is entitled to the generic name COPY. This argument does not sit well with programmers who assert that if this is true, there should be no unique EQUAL operator. We could solve that problem two ways -- one by creating a COPY operator; another by eliminating the embarrassment of EQUAL and friends. Proposal (EQUAL-STRUCTURE:STATUS-QUO): Leave things as is. Rationale: The intent of a structure is different than the intent of an array. A list is an anonymous entity which makes sense only in terms of its length and contents, and is not rightly compared just by object identity (EQ); a structure, on the other hand, has an identity of its own and is appropriately compared with EQ. Proposal (EQUAL-STRUCTURE:DESCEND): Change EQUAL and EQUALP to descend structure slots. Rationale: A structure is a container and, like many other containers in Lisp, should be compared by recursing into the contents of that container. Proposal (EQUAL-STRUCTURE:ADD-KEYWORDS): Add :TEST and :TEST-NOT keywords to EQUAL saying what comparison operator to use at the leaves. [This will need more details if anyone decides they want to push this line of reasoning. I don't claim to have done an adqeuate job of laying the issue out, though I could imagine someone doing so. -kmp] Rationale: There's ample precedent for resolving sticky situations like this in Common Lisp by just adding a keyword option. :-) Proposal (EQUAL-STRUCTURE:ADD-OPERATOR) Introduce new operator(s) like EQUAL (and/or EQUALP) which descends structures. Rationale: If people don't want to make EQUAL more complicated, but still like the idea of a keyword-driven EQUAL, this is the only way to get it. Current Practice: There is no particular ambiguity in CLtL right now, so presumably everyone agrees. The only question is whether what CLtL says is sufficiently useful in practice. Cost to Implementors: The cost to implementors of most of these options is generally small. The exception is that the ADD-KEYWORDS option may require hairy compiler optimizations in order to get back the efficiency that a keyword would lose. Cost to Users: Writing an EQUAL or EQUALP function which is like the one that Common Lisp now has would not be that hard to do as a compatibility measure in case EQUAL or EQUALP were changed or removed. So the cost to users is technically small. Cost of Non-Adoption: Ongoing controversy about whether EQUAL and EQUALP "do the right thing". Benefits: A feeling that EQUAL and EQUALP exist and/or do what they do because serious consideration was given and we consciously decided on a particular resolution to the numerous questions that have come up about them. Aesthetics: Aesthetic considerations vary widely. Different people model structures differently. Sometimes the same person models structures differently in different situations. The question of which should be descended and which should not is a very personal one, and the aesthetic attractiveness of any of these options will vary from person to person or application to application. The ADD-KEYWORDS option will be the most controversial because some people don't like keywords and some compiler writers will not like having to optimize the keywords. Discussion: Pitman strongly supports EQUAL-STRUCTURE:RADICAL as the correct choice from a purely language design standpoint, but acknowledges that it may not ultimately be deemed practical for pragmatic reasons. ∂18-Mar-88 1611 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 1) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Mar 88 16:11:40 PST Received: by labrea.Stanford.EDU; Fri, 18 Mar 88 15:53:07 PST Received: from kent-state.lucid.com by edsel id AA08362g; Fri, 18 Mar 88 15:37:18 PST Received: by kent-state id AA03234g; Fri, 18 Mar 88 15:46:22 PST Date: Fri, 18 Mar 88 15:46:22 PST From: Eric Benson <edsel!eb@labrea.Stanford.EDU> Message-Id: <8803182346.AA03234@kent-state.lucid.com> To: KMP@stony-brook.scrc.symbolics.com Cc: CL-Cleanup@sail.stanford.edu In-Reply-To: Kent M Pitman's message of Fri, 18 Mar 88 17:39 EST <880318173922.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Subject: Issue: EQUAL-STRUCTURE (Version 1) Here's one more to add to your list. Kent, I will merge this and create Version 2 if you like, otherwise I expect that you will include these with any other changes you might have. (I actually prefer EQUAL-STRUCTURE:RADICAL myself, but I'm trying to be practical.) Proposal (EQUAL-STRUCTURE:CHANGE-EQUALP): Change EQUALP so that it descends structures, is case sensitive, and never considers numbers of different types to be equal. Rationale: Several users have independently inquired why there is no predicate with this definition in Common Lisp. Also, use of EQUALP is not widespread. Rather than invent a new name for a predicate, it would be preferable to take an existing name which is not being heavily used and give it a more useful definition. It would also be useful to have EQUALP type hashtables, given this new definition for EQUALP. EQUALP did not exist in Lisp dialects preceding Common Lisp. There are few programs that make use of EQUALP and only those depending on case insensitivity or numeric coercion (or lack of structure descending) would be affected. Discussion: Eric Benson supports EQUAL-STRUCTURE:CHANGE-EQUALP. He has never used EQUALP in a "serious" program, but in every "casual" use he has wished that it was case sensitive. ∂18-Mar-88 2051 CL-Cleanup-mailer Issue: ADJUST-ARRAY-FILL-POINTER (Version 1) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Mar 88 20:51:22 PST Received: by labrea.Stanford.EDU; Fri, 18 Mar 88 20:51:25 PST Received: from bhopal.lucid.com by edsel id AA09410g; Fri, 18 Mar 88 20:31:09 PST Received: by bhopal id AA24393g; Fri, 18 Mar 88 20:38:24 PST Date: Fri, 18 Mar 88 20:38:24 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803190438.AA24393@bhopal.lucid.com> To: KMP@stony-brook.scrc.symbolics.com Cc: CL-Cleanup@sail.stanford.edu In-Reply-To: Kent M Pitman's message of Fri, 18 Mar 88 17:05 EST <880318170509.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Subject: Issue: ADJUST-ARRAY-FILL-POINTER (Version 1) Lucid Common Lisp implements the described behaviour, including the signalling of errors in both error cases. -- JonL -- ∂18-Mar-88 2128 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 1) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 18 Mar 88 21:28:27 PST Received: by labrea.Stanford.EDU; Fri, 18 Mar 88 21:28:55 PST Received: from bhopal.lucid.com by edsel id AA09699g; Fri, 18 Mar 88 21:14:33 PST Received: by bhopal id AA24439g; Fri, 18 Mar 88 21:21:51 PST Date: Fri, 18 Mar 88 21:21:51 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803190521.AA24439@bhopal.lucid.com> To: KMP@stony-brook.scrc.symbolics.com Cc: CL-Cleanup@sail.stanford.edu In-Reply-To: Kent M Pitman's message of Fri, 18 Mar 88 17:39 EST <880318173922.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Subject: Issue: EQUAL-STRUCTURE (Version 1) Generally ok write-up of the issues. You left out the option of adding a jillion-skillion new functions -- one for each conceivable kind of equivalence relation between s-expressions. But that's ok; I want to focus on just one of your proposals. re: Proposal (EQUAL-STRUCTURE:DESCEND): Change EQUAL and EQUALP to descend structure slots. EQUALP is already documented to descend structures (CLtL, p81). So this proposal should just say "Change EQUAL ...". Had all the negative arguments against this particular proposal -- the one you call (EQUAL-STRUCTURE:DESCEND) -- been thought of 6 years ago, CL could not even have an EQUALP function. The logical conclusion of these "technical details" arguments is that EQUAL cannot be defined either. These arguments go roughly as follows: (1) The equivalence which EQUAL implements is not graph-isomorphism -- which *is* uniquely defined -- but rather an ill-defined one making reference to the underspecified notion of "printing". Attempts to make it more precise are merely arbitrary. (2) EQUAL is not a total function since it is permitted to run amok on circular structures. In fact, it is much more "likely" that defstruct instances will contain ultimately circular links than that cons cells will; hence one will "probably" lose more much often if EQUAL were to descend structures. The more "wizard", or "theorist" one is, the more compelling the above arguments seem. On the other hand, the more a "user" one is, the more likely he will argue as follows: I've used the EQUAL function for over 15 years, and have almost never been dissatisfied with it, as the Doctors of Technology say I should be; and every instance of dissatisfaction was due to its failue to descend through pointer vectors. I keep my house in order, and know exactly how my data pyramids are built up; so why should I be punished just because some Conehead somewhere got lost playing around with his Klein bottles and Moebius strips? All the problems alleged for EQUALP's descent into structures also apply to EQUAL's descent into lists; it's only a matter of probabilities. Hence, I don't believe this issue can be settled by technical discussion. The only non-time-wasting effort I can see to do from now on is to look for some way to present our dilemma to a broad "user" community. We could try to tell them, in cursory terms and few words, of the technical arguments that show EQUAL (and EQUALP) to be ill-behaved functions. Then let them decide (by straw vote?) if the extra functionality provided by this proposal is worth the extra risk. Related Issues: -- Are DEFSTRUCT-defined types and CONS, ARRAY, HASH-TABLE, PACKAGE, READTABLE, STREAM, etc. pairwise disjoint? -- Will CLOS require EQUAL to be "generic"? Also, what about COPY? -- JonL -- ∂19-Mar-88 1521 CL-Cleanup-mailer FUNCTION-TYPE proposal Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Mar 88 15:21:15 PST Received: by cs.utah.edu (5.54/utah-2.0-cs) id AA12899; Sat, 19 Mar 88 16:22:01 MST From: sandra@cs.utah.edu (Sandra J Loosemore) Message-Id: <8803192322.AA12899@cs.utah.edu> Date: Sat, 19 Mar 88 16:22:00 MST Subject: FUNCTION-TYPE proposal To: cl-cleanup@sail.stanford.edu I just wanted to clarify the question about item 5 of the FUNCTION-TYPE proposal that I brought up at the meeting. The current language in CLtL *requires* FBOUNDP to return true for a symbol naming a macro or special form. The proposal says that *it is permissible* for FBOUNDP to return true in this situation, which in my mind leaves open the possibility that it might not return true, and seems to be just the opposite of a clarification. Assuming that FBOUNDP must be true of macros and special forms, the implication of item 5b is that SYMBOL-FUNCTION must *not* return a function if the symbol names a macro or special form. In particular, the language on p. 144 of CLtL makes it clear that macro functions are ordinary functions of two arguments and that macro-ness is a property of the symbol they are attached to, not the function which is used to produce the expansion of the macro. Since item 5a says that SYMBOL-FUNCTION must return *something* if its argument names a macro or special form, and since that something can't be a function, is there any reason why we couldn't say exactly what it should return in those situations? For example, if it returned T, one could use a bit of code like (AND (FBOUNDP f) (SYMBOL-FUNCTION f)) to test whether the symbol "f" has some interpretation when it appears as the CAR of a list. A return value of NIL would also have its uses. Certainly either one would be more useful than wimping out and saying it's not well-defined. -Sandra ------- ∂21-Mar-88 1121 CL-Cleanup-mailer Pending issue status Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Mar 88 11:21:45 PST Received: from Cabernet.ms by ArpaGateway.ms ; 21 MAR 88 11:16:22 PST Date: 21 Mar 88 11:12 PST From: Masinter.pa@Xerox.COM Subject: Pending issue status To: cl-cleanup@sail.stanford.edu Message-ID: <880321-111622-3697@Xerox> These are my notes from the subcommittee meeting. I know that I've made some mistakes, so please send any corrections (or just questions) if you have any different recollection. We should have *all* of these issues ready for release by the June meeting, which means that we need to get started immediately. ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS JonL will submit a proposal, based on discussion of "The array type mess". ADJUST-ARRAY-FILL-POINTER KMP (has already submitted) a proposal COERCE-INCOMPLETE Pierson & Moon have comments and will mail them to CL-CLEANUP with cc to Ida. CONSTANT-SIDE-EFFECTS To be deferred to compilation semantics committee; Walter Vanroggen has some comments. DATA-TYPES-HIERARCHY-UNDERSPECIFIED Guy will send a proposal. DECLARATION-SCOPE JonL has a comment to send, none other. DECLARE-TYPE-EXACT I will mail the issue out (again?) for comment DEFINITION-DELETE (Renamed from DEFINITION-FUNCTIONS). JonL will submit. DEFMACRO-BODY-LEXICAL-ENVIRONMENT Defer to the compilation committee; Pavel will make his suggestion there. DEFPACKAGE Haflich mentions that the compilation committee is looking at some of the same issues. I will mail the DEFPACKAGE discussion to Haflich, and we should cc him on mail. DEFSTRUCT-SLOTS-CONSTRAINTS DEFSTRUCT-DEFAULT-VALUE-EVALUATION Skona will write up. EQUAL-STRUCTURE KMP (has already) submitted proposal. EVAL-OTHER Guy will mail opposition. EXPORT-IMPORT (really withdrawn) FILE-LENGTH-PATHNAME I have two notes, one is "withdrawn" and the other is "may return NIL". I think the first is correct. FILE-WRITE-DATE-IF-NOT-EXISTS KMP will incorporate in the list-of-signals part of the signal proposal FORMAT-NEGATIVE-PARAMETERS KMP will incorporate in the list-of-signals part of the signal proposal FUNCTION-ARGUMENT-TYPE-SEMANTICS Eric Benson and Walter Vanroggen will submit a proposal based on current practice. FUNCTION-SPECS Defer to the definition-specs subcommittee GC-MESSAGES Withdrawn for good this time LAMBDA-LIST-DUPLICATES Agree to outlaw in all cases. May need a clarification, depending on what CLtL says. LAST-N Ready for release LET-TOP-LEVEL Defer to compilation committee LISP-SYMBOL-DEFINITION Masinter to write-up, it is an error to redefine Lisp symbols. LOAD-TIME-EVAL KMP and Moon will wrangle out. The compilation committee is also looking at this issue so coordination is required. MACRO-FUNCTION-ENVIRONMENT Pavel will write up MAPPING-DESTRUCTIVE-INTERACTION KMP will mail new version PATHNAME-SUBDIRECTORY-LIST PATHNAME-UNSPECIFIC-COMPONENT Moon and Pierson will work out a proposal. (I will send back mail to Pierson.) PEEK-CHAR-READ-CHAR-ECHO I will remail issue and discussion to this list. PROCLAIM-LEXICAL JonL will submit a new proposal. prompt-for Withdrawn, this time for good. REMF-DESTRUCTION-UNSPECIFIED I will send back mail to Dussud REMF-MULTIPLE Yes, needs clarification REQUIRE-PATHNAME-DEFAULTS Moon will send proposal to remove REQUIRE from language REST-LIST-ALLOCATION Moon will send proposal SETF-METHOD-FOR-SYMBOL Withdrawn, subsumed by SETF-SUB-METHODS SETF-SUB-METHODS Continue mail discussion SHARPSIGN-PLUS-MINUS-NUMBER Codify current practice: allowed, read in base 10. SHARPSIGN-BACKSLASH-BITS Withdrawn (defer to character committee). SPECIAL-FORM-SHADOW To be merged with LISP-SYMBOL-REDEFINITION SPECIAL-VARIABLE-TEST JonL has a comment, but a nit. STANDARD-INPUT-INITIAL-BINDING Pierson will send a new version STEP-ENVIRONMENT Moon will separate into STEP-ENVIRONMENT and TIME-ENVIRONMENT. STREAM-CLASS-ACCESS I will revive FOLLOW-SYNONYM-STREAM as a separate proposal. Walter will mail comments on current practice in VaxLisp STRUCTURE-DEFINITION-ACCESS I will revive, mail comments SUBSEQ-OUT-OF-BOUNDS Steele will send proposal TAILP-NIL I will mail again TRACE-FUNCTION-ONLY I will send a proposal to make TRACE undefined UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT JonL and Moon have comments. Moon has a description of stack model and unwind as atomic. VECTOR-PUH-EXTEND-DEFAULT Withdrawn My notes also have that we would entertain (again) adding EXIT and GC as common names to the implementation dependent operations of "leave Lisp" and "initiate garbage collection". ∂21-Mar-88 1628 CL-Cleanup-mailer Issue: MACRO-FUNCTION-ENVIRONMENT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Mar 88 16:28:28 PST Received: from Salvador.ms by ArpaGateway.ms ; 21 MAR 88 16:06:28 PST Date: Mon, 21 Mar 88 16:05:12 PST From: Pavel.pa@Xerox.COM Subject: Issue: MACRO-FUNCTION-ENVIRONMENT To: CL-Cleanup@SAIL.Stanford.Edu Message-ID: <880321-160628-1159@Xerox> Issue: MACRO-FUNCTION-ENVIRONMENT References: MACRO-FUNCTION, p. 144 MACROLET, pp. 113-4 &ENVIRONMENT, pp. 145-6 MACROEXPAND and MACROEXPAND-1, pp. 151-2 Category: ADDITION Edit history: Pavel, March 21, 1988 (Version 1) Problem description: The &ENVIRONMENT argument to a macro-expansion function may only be used as the second argument to the functions MACROEXPAND and MACROEXPAND-1. It is sometimes more convenient, however, to be able to work directly with the more primitive function MACRO-FUNCTION, on which MACROEXPAND and MACROEXPAND-1 are presumably based. However, since MACRO-FUNCTION does not take an environment argument, it cannot be used in situations in which that environment must be taken into account. Proposal (MACRO-FUNCTION-ENVIRONMENT:YES): Add an optional second argument to MACRO-FUNCTION, that argument being an environment that was passed as the &ENVIRONMENT argument to some macro expansion function. If the argument is not passed, then it defaults to the null environment. MACRO-FUNCTION will now consider macro definitions from that environment in preference to ones in the global environment. It is an error to supply the environment argument in a use of MACRO-FUNCTION as a SETF location specifier. Examples: (macrolet ((foo (&environment env) (if (macro-function 'bar env) ''yes ''no))) (list (foo) (macrolet ((bar () :beep)) (foo)))) => (no yes) Rationale: Intuitively, the more primitive operation in macro expansion is MACRO-FUNCTION, not MACROEXPAND or MACROEXPAND-1, yet the environment argument can only be supplied to the latter functions and not to the former one. By changing this state of affairs, the model of macro expansion becomes somewhat simpler. Also, more flexible use of the facility is enabled. Current practice: Xerox Common Lisp already implements this proposal. Symbolics Common Lisp, Lucid/Sun Common Lisp and Kyoto Common Lisp do not. Cost to Implementors: This is presumably a simple change to make, a small matter of moving the environment-searching code from MACROEXPAND-1 to MACRO-FUNCTION. Cost to Users: The change is upward-compatible and so poses no cost to users. Cost of non-adoption: One more (small) semantic wart on the language. Benefits: The function that users think of as being more primitive really is. Aesthetics: This slightly cleans up the language. Discussion: Pavel is strongly in favor of the proposal. ∂21-Mar-88 1726 CL-Cleanup-mailer RE: Issue: MACRO-FUNCTION-ENVIRONMENT Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 21 Mar 88 17:26:32 PST Date: 21 Mar 88 20:09:00 EDT From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> Subject: RE: Issue: MACRO-FUNCTION-ENVIRONMENT To: "cl-cleanup" <cl-cleanup@sail.stanford.edu> cc: vanroggen Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> Looks pretty good, but how about explicitly allowing NIL as the environment, indicating the null lexical environment? This is just as in GET-SETF-METHOD- ENVIRONMENT, which you might as well add to the list of references. BTW, VAX LISP already implements the proposed behavior. I'm receiving CL-CLEANUP mail now (thank you, rpg), so there's no need to CC to me. Also, please note that my real name is different from my account/user name: "Walter van Roggen", and thus should never be spelled "Walter Vanroggen" except by blind use of DELETE and STRING-CAPITALIZE. ---Walter ------ ∂21-Mar-88 1743 CL-Cleanup-mailer Issue: MACRO-FUNCTION-ENVIRONMENT Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 21 Mar 88 17:43:04 PST Received: by labrea.Stanford.EDU; Mon, 21 Mar 88 17:43:30 PST Received: from kent-state.lucid.com by edsel id AA04493g; Mon, 21 Mar 88 17:41:27 PST Received: by kent-state id AA01518g; Mon, 21 Mar 88 17:41:12 PST Date: Mon, 21 Mar 88 17:41:12 PST From: Eric Benson <edsel!eb@labrea.Stanford.EDU> Message-Id: <8803220141.AA01518@kent-state.lucid.com> To: Pavel.pa@xerox.com Cc: CL-Cleanup@sail.stanford.edu In-Reply-To: Pavel.pa@Xerox.COM's message of Mon, 21 Mar 88 16:05:12 PST <880321-160628-1159@Xerox> Subject: Issue: MACRO-FUNCTION-ENVIRONMENT Lucid Common Lisp 3.0 implements this proposal. ∂21-Mar-88 1748 CL-Cleanup-mailer Re: Issue: MACRO-FUNCTION-ENVIRONMENT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Mar 88 17:48:49 PST Received: from Salvador.ms by ArpaGateway.ms ; 21 MAR 88 17:40:35 PST Date: Mon, 21 Mar 88 17:40:32 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: MACRO-FUNCTION-ENVIRONMENT In-reply-to: "Your message of 21 Mar 88 20:09:00 EDT" To: cl-cleanup@sail.stanford.edu Message-ID: <880321-174035-1359@Xerox> Walter says: how about explicitly allowing NIL as the environment, indicating the null lexical environment? This is just as in GET-SETF-METHOD-ENVIRONMENT'' I thought of that, but didn't put it in because I couldn't find a reference to it being allowed. I now have one, but did we ever also say that NIL could be passed as the second argument to MACROEXPAND and MACROEXPAND-1? Pavel ∂22-Mar-88 0633 CL-Cleanup-mailer cleanup for equal ? Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 88 06:33:29 PST Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 22 Mar 88 09:35-EST Received: from ACORN.Gold-Hill.DialNet.Symbolics.COM by MIT-LIVE-OAK.DialNet.Symbolics.COM via DIAL with SMTP id 84952; 22 Mar 88 09:31:38-EST Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 97300; Tue 22-Mar-88 08:58:02-EST Date: Tue, 22 Mar 88 08:59 est From: mike%acorn@oak.lcs.mit.edu (mike@gold-hill.com after 1-April-88) COMMENTS: NOTE %acorn@oak... CHANGES TO @GOLD-HILL.COM ON 1-April-88 To: cl-cleanup@sail.stanford.edu Subject: cleanup for equal ? Is there already a cleanup item for EQUAL? The definition on page 80 of CLtL is very loose. If there is not, I will compose one. ...mike beckerle Gold Hill ∂22-Mar-88 0955 CL-Cleanup-mailer stream-access background information Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 22 Mar 88 09:55:33 PST Date: 22 Mar 88 12:44:00 EDT From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> Subject: stream-access background information To: "cl-cleanup" <cl-cleanup@sail.stanford.edu> cc: vanroggen Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> Here's a summary of some of the extensions we've added to VAX LISP to make the functionality of CLtL more "complete". Instead of a new LISTEN2 function, perhaps we should modify LISTEN to just return a second value as well. ---Walter ----------------------------------------------------------------------- VAX LISP provides access to more detailed information about streams than is called for in COMMON LISP: The Language. VAX LISP provides a separate data type for each stream type, a predicate for each stream type, functions to retrieve elements that were used to construct streams, and several new I/O functions. Stream Data Types and Predicates BROADCAST-STREAM BROADCAST-STREAM-P object CONCATENATED-STREAM CONCATENATED-STREAM-P object DRIBBLE-STREAM DRIBBLE-STREAM-P object ECHO-STREAM ECHO-STREAM-P object FILE-STREAM FILE-STREAM-P object STRING-STREAM STRING-STREAM-P object SYNONYM-STREAM SYNONYM-STREAM-P object TERMINAL-STREAM TERMINAL-STREAM-P object TWO-WAY-STREAM TWO-WAY-STREAM-P object Stream Informational Functions BROADCAST-STREAM-STREAMS broadcast-stream ==> list of streams CONCATENATED-STREAM-STREAMS concatenated-stream ==> list of streams ECHO-STREAM-INPUT-STREAM echo-stream ==> stream ECHO-STREAM-OUTPUT-STREAM echo-stream ==> stream SYNONYM-STREAM-SYMBOL synonym-stream ==> symbol TWO-WAY-STREAM-INPUT-STREAM two-way-stream ==> stream TWO-WAY-STREAM-OUTPUT-STREAM two-way-stream ==> stream LINE-POSITION &OPTIONAL output-stream Returns the number of characters that have been output on the current line if that number can be determined and NIL otherwise. Output-stream defaults to *STANDARD-OUTPUT*. If a value of T is supplied, the value of *TERMINAL-IO* is used. LISTEN2 &OPTIONAL input-stream Returns two values. The first is identical to the value returned by the COMMON LISP LISTEN function; the second is T if end-of-file was encountered on the input stream, and NIL otherwise. You can use this function wherever you would normally use LISTEN. Input-stream defaults to *STANDARD-INPUT*. If a value of T is supplied, the value of *TERMINAL-IO* is used. OPEN-STREAM-P stream Returns T if a stream is open, NIL if it is closed. It is an error if the argument is not a stream. ------ ∂22-Mar-88 1025 CL-Cleanup-mailer Re: stream-access background information Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Mar 88 10:25:01 PST Received: from Cabernet.ms by ArpaGateway.ms ; 22 MAR 88 10:15:47 PST Date: 22 Mar 88 10:15 PST From: Masinter.pa@Xerox.COM Subject: Re: stream-access background information In-reply-to: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>'s message of 22 Mar 88 12:44:00 EDT To: vanroggen%aitg.decnet@hudson.dec.com cc: cl-cleanup@sail.stanford.edu Message-ID: <880322-101547-1877@Xerox> Of the ones in your list, DRIBBLE-STREAM, FILE-STREAM, TERMINAL-STREAM are the ones that seem questionable. We've managed to evicerate DRIBBLE; we've had trouble in the past defining what a "file" is (one that can be coerced to a pathname?), and TERMINAL-STREAM is true of *TERMINAL-IO* sometimes? What is a "terminal"? On LISTEN2, how do you define "end-of-file"? On OPEN-STREAM-P, how do you define "open"? ∂22-Mar-88 1324 CL-Cleanup-mailer RE: stream-access background information Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 22 Mar 88 13:24:10 PST Date: 22 Mar 88 16:17:00 EDT From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> Subject: RE: stream-access background information To: "cl-cleanup" <cl-cleanup@sail.stanford.edu> cc: vanroggen Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com> I just presented the types and functions we've publicized; it doesn't mean they all have to be part of Common Lisp. I'd be quite happy if they weren't part of any cleanup proposal; but I did want to make sure that if people did want certain functionality, that the names agree with what we chose (unless there's a good reason to the contrary). I believe "end-of-file" for LISTEN2 is defined the same way as for other input functions which deal with "end-of-file". The need for OPEN-STREAM-P is because there's no way in Common Lisp to tell if it's OK to do I/O to a stream; i.e., there's no way to tell if a stream has been CLOSEd already. If your question was would (open-stream-p (make-string-output-stream)) be true, then yes, for any stream that hadn't been CLOSEd. Which reminds me of another issue I don't recall having seen recently. What does CLOSE do on compound streams? I believe we close that stream and don't do anything with the component streams. ---Walter ------ ∂22-Mar-88 1630 CL-Cleanup-mailer New "issue" and proposal Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 22 Mar 88 16:29:52 PST Received: from relay2.cs.net by RELAY.CS.NET id aa26807; 22 Mar 88 18:49 EST Received: from tektronix.tek.com by RELAY.CS.NET id ac05018; 22 Mar 88 18:39 EST Received: by tektronix.TEK.COM (5.51/6.24) id AA20128; Tue, 22 Mar 88 12:59:24 PST Received: by tekchips.CRL.TEK.COM (5.51/6.24) id AA25927; Tue, 22 Mar 88 12:58:15 PST Message-Id: <8803222058.AA25927@tekchips.CRL.TEK.COM> To: Masinter.pa@XEROX.COM Cc: cl-cleanup@SAIL.STANFORD.EDU, willc@tekchips.crl.tek.com Subject: New "issue" and proposal Date: 22 Mar 88 12:58:12 PST (Tue) From: willc%tekchips.CRL@tektronix.tek.com Issue: FUNCTION-CALL-EVALUATION-ORDER References: none Category: CLARIFICATION Edit history: Version 1 by Clinger (22 March 1988) Problem Description: CLtL does not say whether the function expression of a call is evaluated before or after the argument expressions. Proposal (FUNCTION-CALL-EVALUATION-ORDER:UNSPECIFIED): Common Lisp does not specify whether the function expression of a call is evaluated before or after the argument expressions. Programs that rely on a particular order of evaluation are in error. Example: (defun foo (x) (+ x 3)) (defun bar () (setf (symbol-function 'foo) #'(lambda (x) (+ x 4)))) (foo (progn (bar) 20)) ; may return 23 or 24 Rationale: This makes the status quo explicit. Current Practice: TI and Symbolics evaluate the function expression last. Lucid and Coral sometimes evaluate the function expression first and at other times evaluate the function expression last. Cost to implementors: None. Cost to users: None. Benefits: Codifies an ambiguity. Aesthetics: Since Common Lisp evaluates argument expressions from left to right, it would be more consistent for the function expression to be evaluated before the argument expressions. On the other hand, the evaluation rules for function expressions are already quite different from the rules for argument expressions, and nobody in their right mind would write code that depends on the order of evaluation, so aesthetics should not count for much in this case. Requiring left to right evaluation would force some implementations to consume an extra register for many function calls. The efficiency argument seems more important than the aesthetic argument. ∂22-Mar-88 1649 CL-Cleanup-mailer Re: New "issue" and proposal Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Mar 88 16:48:55 PST Received: from Cabernet.ms by ArpaGateway.ms ; 22 MAR 88 16:42:15 PST Date: Tue, 22 Mar 88 16:41:16 PST From: Pavel.pa@Xerox.COM Subject: Re: New "issue" and proposal In-reply-to: <8803222058.AA25927@tekchips.CRL.TEK.COM> To: cl-cleanup@SAIL.STANFORD.EDU Cc: willc@tekchips.crl.tek.com Message-ID: <880322-164215-2817@Xerox> I support this proposal. Pavel ∂22-Mar-88 2030 CL-Cleanup-mailer Strings as streams Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 22 Mar 88 20:29:56 PST Received: by labrea.Stanford.EDU; Tue, 22 Mar 88 20:30:35 PST Received: from bhopal.lucid.com by edsel id AA09780g; Tue, 22 Mar 88 20:24:51 PST Received: by bhopal id AA04807g; Tue, 22 Mar 88 20:24:36 PST Date: Tue, 22 Mar 88 20:24:36 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803230424.AA04807@bhopal.lucid.com> To: cl-cleanup@sail.stanford.edu Subject: Strings as streams Does anyone know whether the following point has been "clarified" at all? say, in Guy's previous notes about clarifications and corrections? CLtL p386 says that formatting to a fill-pointer'd string should add characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that with-outuput-to-string will work "as if using VECTOR-PUSH-EXTEND if the string is adjustable, and otherwise as if using VECTOR-PUSH". Possibly the description of FORMAT merely needs the additional wording? -- JonL -- ∂23-Mar-88 1006 CL-Cleanup-mailer Strings as streams Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 88 10:05:58 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 368588; Wed 23-Mar-88 11:28:13 EST Date: Wed, 23 Mar 88 11:28 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Strings as streams To: Jon L White <edsel!jonl@labrea.Stanford.EDU> cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8803230424.AA04807@bhopal.lucid.com> Message-ID: <19880323162809.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 22 Mar 88 20:24:36 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Does anyone know whether the following point has been "clarified" at all? say, in Guy's previous notes about clarifications and corrections? I don't recall this point coming up before. It's not in 86-003. CLtL p386 says that formatting to a fill-pointer'd string should add characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that with-outuput-to-string will work "as if using VECTOR-PUSH-EXTEND if the string is adjustable, and otherwise as if using VECTOR-PUSH". Possibly the description of FORMAT merely needs the additional wording? I think FORMAT is right and WITH-OUTPUT-TO-STRING is wrong. If more characters are output than will fit in the string, VECTOR-PUSH-EXTEND either does the right thing or signals an error, depending on whether the string is adjustable, whereas VECTOR-PUSH just throws away the excess characters. It seems clear to me that throwing away some characters without signalling an error is not desirable behavior. I suspect the mention of VECTOR-PUSH under WITH-OUTPUT-TO-STRING was just a mistake, perhaps a momentary thought that VECTOR-PUSH-EXTEND always signalled an error if handed a non-adjustable vector, even when it wasn't full. JonL, would you like to write up a cleanup proposal for this, or should I? ∂23-Mar-88 1048 CL-Cleanup-mailer Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 88 10:48:06 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 368716; Wed 23-Mar-88 13:48:39 EST Date: Wed, 23 Mar 88 13:48 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1) To: willc%tekchips.CRL@tektronix.tek.com, cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8803222058.AA25927@tekchips.CRL.TEK.COM> Message-ID: <19880323184829.5.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: 22 Mar 88 12:58:12 PST (Tue) From: willc%tekchips.CRL@tektronix.tek.com Problem Description: CLtL does not say whether the function expression of a call is evaluated before or after the argument expressions. It also does not say in what order the argument expressions are evaluated! Shouldn't we deal with that first, or at the same time? As far as I know current practice is always to evaluate the argument expressions in a function call from left to right, and I would certainly support a proposal to mandate that in the language. Someone please tell me that I am confused and have overlooked the place in CLtL that specifies the order of evaluation of function arguments. Proposal (FUNCTION-CALL-EVALUATION-ORDER:UNSPECIFIED): Common Lisp does not specify whether the function expression of a call is evaluated before or after the argument expressions. Programs that rely on a particular order of evaluation are in error. I support this proposal. Current Practice: TI and Symbolics evaluate the function expression last. Lucid and Coral sometimes evaluate the function expression first and at other times evaluate the function expression last. Actually Symbolics is in the same camp as Lucid and Coral here, although right now the answer is usually last. Whether TI evaluates the function first or last depends on which release of TI software you're using. ∂23-Mar-88 1102 CL-Cleanup-mailer Issue: MACRO-FUNCTION-ENVIRONMENT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:01:46 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 368731; Wed 23-Mar-88 14:01:36 EST Date: Wed, 23 Mar 88 14:01 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: MACRO-FUNCTION-ENVIRONMENT To: Pavel.pa@Xerox.COM cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880321-160628-1159@Xerox> Message-ID: <19880323190138.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No I support this proposal, with the modification to allow NIL as a synonym for the global environment. ∂23-Mar-88 1105 CL-Cleanup-mailer Issue: ADJUST-ARRAY-FILL-POINTER (Version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:05:30 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 368735; Wed 23-Mar-88 14:06:06 EST Date: Wed, 23 Mar 88 14:06 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: ADJUST-ARRAY-FILL-POINTER (Version 1) To: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880318170509.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880323190609.0.MOON@EUPHRATES.SCRC.Symbolics.COM> I support ADJUST-ARRAY-FILL-POINTER:MINIMAL. ∂23-Mar-88 1110 CL-Cleanup-mailer Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1) Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:10:41 PST Received: from Salvador.ms by ArpaGateway.ms ; 23 MAR 88 11:01:31 PST Date: Wed, 23 Mar 88 11:01:26 PST From: Pavel.pa@Xerox.COM Subject: Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1) In-reply-to: <19880323184829.5.MOON@EUPHRATES.SCRC.Symbolics.COM> To: willc%tekchips.CRL@tektronix.tek.COM, cl-cleanup@SAIL.STANFORD.EDU Message-ID: <880323-110131-1794@Xerox> Dave says: [CLtL] also does not say in what order the argument expressions are evaluated! Shouldn't we deal with that first, or at the same time?'' The closest thing I could find in CLtL to a statement about argument evaluation order is the statement in the description of LET that the bound expressions are evaluated in order. Since a number of implementations (including Lucid) macro-expand LET into a called LAMBDA, they are clearly depending upon this behavior. While I would prefer, as a compiler writer and language designer, to leave the order of argument evaluation unspecified, as in Scheme, I fear that so many user programs critically depend upon the status quo (assumed always to be left-to-right) that we can do nothing but reaffirm that officially. Pavel ∂23-Mar-88 1117 CL-Cleanup-mailer Issue: LAST-N (Version 2) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:17:16 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 368759; Wed 23-Mar-88 14:17:52 EST Date: Wed, 23 Mar 88 14:17 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: LAST-N (Version 2) To: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880312210753.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880323191752.1.MOON@EUPHRATES.SCRC.Symbolics.COM> I support LAST-N:ALLOW-OPTIONAL-ARGUMENT on the basis that "This would make it more obvious why LAST should return a list and not an element. ie, it would return the "last N elements" where N=1 by default." I certainly support releasing it to X3J13 and letting them decide what they think of it. ∂23-Mar-88 1150 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:49:49 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 368796; Wed 23-Mar-88 14:49:59 EST Date: Wed, 23 Mar 88 14:49 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: DEFPACKAGE (version 2) To: CL-Cleanup@SAIL.STANFORD.EDU References: <19880313000007.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <19880323194958.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Issue: DEFPACKAGE References: CLtL section 11.7. Category: ADDITION Edit history: Version 1, 12-Mar-88, Moon Version 2, 23-Mar-88, Moon, changes based on discussion Problem description: The package functions included in CLtL encourage a programming style that tends to evoke the worst aspects of the package system. The problem is that if the definition of a package is scattered through a program, as a number of individual forms, it is very easy to read a symbol before the package setup needed to read that symbol correctly has been accomplished. Three examples: an inherited symbol that should have been shadowed might be accessed; a single-colon prefix might be used for a symbol that will later be exported, causing an error; a local symbol might be accessed where a symbol that will later be imported or inherited was intended. These problems can be difficult to understand or even to recognize, are difficult to recover from without completely restarting the Lisp, and give Common Lisp a bad name. Proposal (DEFPACKAGE:ADDITION): Add a DEFPACKAGE macro to the language. It encourages putting the entire definition of a package in a single place. It also encourages putting all the package definitions of a program in a single file, which can be loaded before loading or compiling anything that depends on those packages. This file can be read in the USER package, avoiding any package bootstrapping issues. In addition, DEFPACKAGE allows a programming environment to process the whole package setup as a unit, providing better error-checking and more assistance with package problems, by dint of global knowledge of the package setup. Also expand MAKE-PACKAGE and IN-PACKAGE to take all the same keyword arguments as DEFPACKAGE, for consistency. The syntax of DEFPACKAGE is (DEFPACKAGE package-name {option}*) where each option is a list of a keyword and arguments. Nothing in a DEFPACKAGE form is evaluated. package-name is a symbol or a string; if a symbol, only its name matters, not what package it is in. If a string, capitalization matters, normally uppercase is used. Standard options for DEFPACKAGE are listed below. Additional options might be present in an implementation, and each implementation must signal an error if an option not recognized by that implementation is present. Additional implementation-dependent options might take the form of a keyword standing by itself as an abbreviation for a list (keyword T); this syntax should be properly reported as an unrecognized option in implementations that do not support it. Each option may appear at most once. If duplicate options are present, DEFPACKAGE signals an error. (:EXPORT {symbol}*) Create symbols with the specified names and export them. Note that only the name of each argument symbol is used. The symbol that gets exported is not necessarily the one given as an argument; it's a symbol with that name but in the package being defined. (:IMPORT {symbol}*) Import the specified symbols. (:IMPORT-FROM {(package-name {symbol}*)}*) (:IMPORT-FROM package-name {symbol}*) Find the specified symbols in the specified packages and import them into the package being defined. The second syntax is a convenient abbreviation when only one package is specified. Note that only the name of each argument symbol is used. The actual symbol that gets imported is not necessarily the one given as an argument; it's a symbol with that name accessible in the named package. (:NICKNAMES {package-name}*) Set the package's nicknames to the specified strings. (:SHADOW {symbol}*) Create the specified symbols in the package and place them on the shadowing list. Note that only the name of each argument symbol is used. (:SHADOWING-IMPORT {symbol}*) Import the specified symbols into the package and make them shadow any inherited symbols. (:SHADOWING-IMPORT-FROM {(package-name {symbol}*)}*) (:SHADOWING-IMPORT-FROM package-name {symbol}*) Find the specified symbols in the specified packages and import them into the package being defined, making them shadow any inherited symbols. The second syntax is a convenient abbreviation when only one package is specified. Note that only the name of each argument symbol is used. The actual symbol that gets imported is not necessarily the one given as an argument; it's a symbol with that name accessible in the named package. (:SIZE integer) Declare the approximate number of symbols expected in the package. (:USE {package}*) Inherit from the specified packages. Example: (DEFPACKAGE MY-PACKAGE (:USE LISP) (:SHADOW CAR CDR CONS) (:NICKNAMES MYPKG MY-PKG)) Rationale: See first paragraph of Proposal section. Current practice: Symbolics Common Lisp has always had this, and uses it in preference to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL version of DEFPACKAGE has quite a few additional options, but none of them appear to be necessary to propose for Common Lisp at this time. Cost to Implementors: Should be small as the macro can be implemented simply as a bunch of calls to existing functions. Cost to Users: No cost, this is upward compatible. Cost of non-adoption: Packages continue to be difficult to use correctly. Benefits: Guide users away from using packages in ways that get them into trouble. Esthetics: Neutral. Discussion: The "Put in seven extremely random user interface commands" business described at the end of chapter 11 could be removed, and the special compiler handling of these functions necessary to support that could be removed. As this would be an incompatible change, it is not part of this proposal. KMP suggests that IN-PACKAGE should be incompatibly changed only to recognize existing packages, not to create them, which would fix a lot of bugs. IN-PACKAGE would then not accept any keyword arguments. Moon thinks this is a reasonable idea but should be the subject of a separate proposal. ∂23-Mar-88 1151 CL-Cleanup-mailer New issue: DEFPACKAGE Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:50:50 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 368789; 23 Mar 88 14:45:34 EST Date: Wed, 23 Mar 88 14:45 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: New issue: DEFPACKAGE To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>, Pavel.pa@Xerox.COM, Eric Benson <edsel!eb@labrea.Stanford.EDU>, Richard Mlynarik <MLY@AI.AI.MIT.EDU> cc: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <880312191420.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>, <FAHLMAN.12381856106.BABYL@C.CS.CMU.EDU>, <880313-163147-1810@Xerox>, <8803140910.AA00538@kent-state.lucid.com>, <880314085910.1.MLY@KLYTEMNESTRA.AI.MIT.EDU>, <FAHLMAN.12382269523.BABYL@C.CS.CMU.EDU> Message-ID: <19880323194526.2.MOON@EUPHRATES.SCRC.Symbolics.COM> Line-fold: No Here are my responses to comments received. My next message will be a revised version of the proposal. Date: Sat, 12 Mar 88 19:14 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> I support the general idea of this proposal, but have a few nits to pick... * I think IN-PACKAGE is broken for being able to demand-create a package. It serves two unrelated roles, one of which being selection and the other being creation. Extending it to allow more keywords will worsen the problem. Given DEFPACKAGE, I would rather see IN-PACKAGE incompatibly changed to NOT allow demand creation. This would fix a lot of bugs. Agreed, but I think that should be a separate proposal. Added to the discussion section. * There might should be a :SHADOWING-IMPORT-FROM. Agreed. * I think that all options listed as symbol/string should be string-only. People should be discouraged from naming symbols before the package structure is fully in place. I'll stop short of suggesting that :IMPORT-FROM and :SHADOWING-IMPORT-FROM completely replace :IMPORT and :SHADOWING-IMPORT, which still muck with symbols. I disagree because of alphabetic case issues in strings. Note that in these symbol/string arguments, the symbol is being used only for its name, so there are never any package issues. For instance, in :EXPORT, if a symbol is given, the symbol that is exported from the package is not necessarily that same symbol. It's a symbol with that name in the package being defined. After looking at CLtL's writeup of SHADOW again, I changed all of these to be symbol-only. * I'm surprised you left out the Genera :INCLUDE feature, but I guess that could always be added later if it was seen to be desired so it's ok. I was not trying to propose any extensions to the semantics of packages. (:INCLUDE is a Zetalisp release 4 compatibility feature that allows using package A to automatically imply using package B as well.) * :PREFIX-NAME is mentioned only in the same. To have it in an integrated fashion, you'd need a PACKAGE-PREFIX-NAME function and some discussion of that it was automatically a nickname if not explicitly in the list of names or nicknames. This was an editing error. I didn't mean to propose the prefix-name extension. (Prefix-name provides control over which name or nickname of a package the printer uses when printing a symbol.) Date: Sun, 13 Mar 88 16:31:26 PST From: Pavel.pa@Xerox.COM Just a nit for the moment: A keyword standing by itself is an abbreviation for a list (keyword T).'' This doesn't appear to be very useful, since none of the options will commonly want to have an option-argument of T. Right. This should have been in the part about implementation-dependent options. I seem to have been pretty careless in the editing of this proposal. Date: Sat, 12 Mar 1988 19:46 EST From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> This looks good, as far as it goes, and the fact that it has actually been tested in practice is a big plus -- it tends to give one confidence that nothign critical has been overlooked. Thanks. I'm a bit uneasy about the syntax that you propose for the options. It would be more compatible with the rest of Common Lisp to use alternating keywords and arguments. Some users may find the odd syntax of your DEFPACKAGE to be confusing. Is there some real advantage to the syntax you propose, or is this just a bit of Zetalisp culture peeking through? Symbolics has a very large number of macros that work this way, and we have found it to be easier to use and less confusing than alternating keywords and arguments. For one thing, it decreases the common confusion among both naive and experienced users, in which they think they are supposed to put in a ' in front of an argument when invoking a macro, as they would when calling a function. Another point is that the semantics of duplicated keywords is different. In a function call, Common Lisp specifies that duplicate appearances of a keyword argument after the first are to be ignored. In a macro, duplicate options should certainly not be ignored; either the options should be combined in some way or an error should be signalled, depending on the semantics of the particular option. I really believe that a list of option name and arguments is the best syntax for macros that take a bunch of options that are really a special-purpose language for describing something. With CLOS, Common Lisp will acquire several more macros that use this syntax for options, which should make it less of a surprise to users who have not seen this before. Date: Mon, 14 Mar 88 01:10:57 PST From: Eric Benson <edsel!eb@labrea.Stanford.EDU> This syntax resembles that used for DEFSTRUCT options, so it does have a precedent in CLtL. Right. Date: Mon, 14 Mar 88 08:59 EST From: Richard Mlynarik <MLY@AI.AI.MIT.EDU> DEFSTRUCT (which nobody has ever accused of having non-odd' syntax) also suffers from the same non-&KEY-style. The saddest things is that this type of syntactical lossage has infected CLOS DEFxxx, probably because of the precedent in DEFFLAVOR. I personally dislike the whole style; unfortunately it seems that few others feel strongly enough about this issue to raise objections. I have to strongly disagree with you here, for the reasons alluded to earlier. ∂23-Mar-88 1156 CL-Cleanup-mailer New issue: DEFPACKAGE Received: from C.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 23 Mar 88 11:56:42 PST Received: ID <FAHLMAN@C.CS.CMU.EDU.#Internet>; Wed 23 Mar 88 14:57:11-EST Date: Wed, 23 Mar 1988 14:57 EST Message-ID: <FAHLMAN.12384686921.BABYL@C.CS.CMU.EDU> Sender: FAHLMAN@C.CS.CMU.EDU From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU> To: CL-Cleanup@SAIL.STANFORD.EDU Subject: New issue: DEFPACKAGE In-reply-to: Msg of 23 Mar 1988 14:45-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM> OK, Moon's arguments for the proposed syntax are persuasive, to me at least. Objection withdrawn. It would be a good idea to put that part of Moon's message into the discussion section of the proposal. -- Scott ∂23-Mar-88 1330 CL-Cleanup-mailer Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1) Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 23 Mar 88 13:29:49 PST Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa09557; 23 Mar 88 21:26 GMT From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK> Date: Wed, 23 Mar 88 21:25:42 gmt Message-Id: <18525.8803232125@aiva.ed.ac.uk> To: cl-cleanup@sail.stanford.edu Subject: Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1) Cc: willc <@NSS.Cs.Ucl.AC.UK,@tektronix.tek.com:willc@tekchips.crl> Pavel says: The closest thing I could find in CLtL to a statement about argument evaluation order is the statement in the description of LET [...] Actually, CLtL *does* say what the order of argument evaluation is. It's on page 194, in the chapter on numbers: ... This does not affect the order in which argument forms are evaluated, of course; that order is always left to right, as in all Common Lisp function calls. Cheers, Jeff ∂24-Mar-88 0849 CL-Cleanup-mailer Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1) Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Mar 88 08:49:30 PST Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 369322; Thu 24-Mar-88 11:19:40 EST Date: Thu, 24 Mar 88 11:19 EST From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Re: Issue: FUNCTION-CALL-EVALUATION-ORDER (version 1) To: CL-Cleanup@SAIL.STANFORD.EDU In-Reply-To: <18525.8803232125@aiva.ed.ac.uk>, <880323-110131-1794@Xerox> References: <8803222058.AA25927@tekchips.CRL.TEK.COM> Message-ID: <880324111926.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I support FUNCTION-CALL-EVALUATION-ORDER:UNSPECIFIED. From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK> Date: Wed, 23 Mar 88 21:25:42 gmt Pavel says: The closest thing I could find in CLtL to a statement about argument evaluation order is the statement in the description of LET [...] Actually, CLtL *does* say what the order of argument evaluation is. It's on page 194, in the chapter on numbers: ... This does not affect the order in which argument forms are evaluated, of course; that order is always left to right, as in all Common Lisp function calls. Cheers, Jeff Also, p97 (in the description of SETF): "SETF carefully arranges to preserve the usual left-to-right order in which the various subforms are evaluated." and again on p102 (in the description of DEFSETF): "The implementation of DEFSETF takes care of ensuring that the subforms of the reference are evaluated exactly once and in the proper left-to-right order." I will be happy to draft a separate proposal for the argument evaluation order if people prefer to discuss that issue independently of the function position. Certainly there is likely to be less (or different) controversy on that issue, so separating them might not be unreasonable. ∂24-Mar-88 1052 CL-Cleanup-mailer Issue SUBSEQ-OUT-OF-BOUNDS Received: from Think.COM by SAIL.Stanford.EDU with TCP; 24 Mar 88 10:52:25 PST Return-Path: <gls@Think.COM> Received: from kali.think.com by Think.COM; Thu, 24 Mar 88 13:51:39 EST Received: by kali.think.com; Thu, 24 Mar 88 13:51:34 EST Date: Thu, 24 Mar 88 13:51:34 EST From: gls@Think.COM Message-Id: <8803241851.AA10588@kali.think.com> To: cl-cleanup@sail.stanford.edu Subject: Issue SUBSEQ-OUT-OF-BOUNDS Issue: SUBSEQ-OUT-OF-BOUNDS References: :START and :END arguments (246-247), SUBSEQ (248) Category: CLARIFICATION Edit history: 24-Mar-88, Version 1 by Steele Problem description: The descriptions of :START and :END arguments, and of SUBSEQ, do not explicitly address the question of out-of-bounds indices. (The language on page 246, "These arguments should be integer indices into the sequence," is considered too vague on this point.) Proposal (SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR): Specify that it is an error for the :START argument of any standard function, or the second argument to SUBSEQ, to be less than zero. Specify that it is an error for the :END argument of any standard function, or the third argument to SUBSEQ, to be greater than the length of the sequence in question (as returned by LENGTH). (Note that there is already a requirement that a start argument not be greater than an end argument.) Test Cases/Examples: (SUBSEQ "Where's the beef?" -1 5) might be assumed to be "Where" or " Where". (SUBSEQ "Where's the beef?" -3 -3) might be assumed to be "". (SUBSEQ "Where's the beef?" 16 18) might be assumed to be "?" or "? ". (SUBSEQ "Where's the beef?" 10000 10000) might be assumed to be "". Under this proposal each of these situations is an error, and portable programs may not rely on their behavior. Rationale: We don't want code indexing off the ends of arrays. Current practice: KCL interpreted and compiled code signals an error. Symbolics Common Lisp interpreted and compiled code signals an error; the compiler also issued an out-of-range warning (possible because the arguments were all constant). Lucid Common Lisp interpreted and compiled code signals an error. Cost to Implementors: None. Cost to Users: Users who depended on some specific implementation behavior in these cases may find that their pragmatically unportable code is not officially unportable. Cost of non-adoption: Confusion. Benefits: Removal of a small but important ambiguity in the spec. Esthetics: It seems cleaner not to allow indexing off the end of an array, and by extension not allow it for any sequence. Discussion: This merely clarifies the original intent of the passage on page 246. ∂24-Mar-88 1438 CL-Cleanup-mailer Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED Received: from Think.COM by SAIL.Stanford.EDU with TCP; 24 Mar 88 14:38:30 PST Return-Path: <gls@Think.COM> Received: from kali.think.com by Think.COM; Thu, 24 Mar 88 17:37:52 EST Received: by kali.think.com; Thu, 24 Mar 88 17:37:48 EST Date: Thu, 24 Mar 88 17:37:48 EST From: gls@Think.COM Message-Id: <8803242237.AA10817@kali.think.com> To: cl-cleanup@sail.stanford.edu Subject: Issue DATA-TYPES-HIERARCHY-UNDERSPECIFIED Issue: DATA-TYPES-HIERARCHY-UNDERSPECIFIED References: CLtL 33-35 (data types) CLtL 312 (DEFSTRUCT :INCLUDE option) Category: CHANGE Edit history: 24-Mar-88, version 1 by Steele Problem description: The types HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, and RANDOM-STATE currently are not required to be disjoint from CONS, SYMBOL, ARRAY, NUMBER, or CHARACTER. The same is true of DEFSTRUCT types. With the arrival of CLOS, lack of disjointness will be inconvenient because one cannot reliably use generic function dispatch on these types. Proposal (DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT): Remove the third and antepenultimate bulleted items from section 2.15 is CLtL and replace with the following: * The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, RANDOM-STATE, and any single other type created by DEFSTRUCT [or DEFCLASS] are pairwise disjoint. Also, in the discussion of the DEFSTRUCT :INCLUDE option, explicitly forbid the type given to the :INCLUDE option to be CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, HASH-TABLE, READTABLE, PACKAGE, PATHNAME, STREAM, or RANDOM-STATE. Test Cases/Examples: Rationale: It would be useful to extend sequence functions to operate on streams or hash tables, for example, through the CLOS generic function mechanism. This is not possible under the current specification. Current practice: Some implementations in effect use DEFSTRUCT to define data structures such as hash tables and random-states. Cost to Implementors: Small or nonexistent. The main reason this disjointness was not specified in CLtL was the possibility that structures might not be easily distinguishable: a stupid concern over a slight efficiency. This implementation freedom apparently has not been exploited in practice. Cost to Users: None. Cost of non-adoption: CLOS will be less useful. Benefits: CLOS will be more useful. Esthetics: This makes the type system simpler and easier to understand. Discussion: This suggestion originated in the CLOS committee. ∂25-Mar-88 1411 CL-Cleanup-mailer Issue SUBSEQ-OUT-OF-BOUNDS Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Mar 88 14:11:42 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 370425; Fri 25-Mar-88 17:10:54 EST Date: Fri, 25 Mar 88 17:10 EST From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue SUBSEQ-OUT-OF-BOUNDS To: gls@Think.COM cc: cl-cleanup@SAIL.STANFORD.EDU In-Reply-To: <8803241851.AA10588@kali.think.com> Message-ID: <19880325221052.9.MOON@EUPHRATES.SCRC.Symbolics.COM> I support SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR, however I think we need to be clearer about whether the upper bound is the fill-pointer or the actual array length. I remember that this was controversial before. Your rationale and esthetics could be taken as arguments for using the actual array length. A close reading of your proposal shows that it proposes using the fill pointer. Current practice in Symbolics Genera is to use the fill pointer; I didn't check whether your other current practice entries referred to the fill pointer or the actual array length. Also be clearer that the start must less than or equal to the end even if the end was defaulted or NIL. In the cost to users section, I believe you have a typo, "not" where you mean "now". This is one of those commonly made unfortunate typos that reverses the meaning of a sentence. ∂25-Mar-88 1456 CL-Cleanup-mailer Issue SUBSEQ-OUT-OF-BOUNDS Received: from Think.COM by SAIL.Stanford.EDU with TCP; 25 Mar 88 14:55:58 PST Return-Path: <gls@Think.COM> Received: from kali.think.com by Think.COM; Fri, 25 Mar 88 17:54:38 EST Received: by kali.think.com; Fri, 25 Mar 88 17:54:32 EST Date: Fri, 25 Mar 88 17:54:32 EST From: gls@Think.COM Message-Id: <8803252254.AA12274@kali.think.com> To: Moon@stony-brook.scrc.symbolics.com Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu In-Reply-To: David A. Moon's message of Fri, 25 Mar 88 17:10 EST <19880325221052.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: Issue SUBSEQ-OUT-OF-BOUNDS Date: Fri, 25 Mar 88 17:10 EST From: David A. Moon <Moon@stony-brook.scrc.symbolics.com> I support SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR, however I think we need to be clearer about whether the upper bound is the fill-pointer or the actual array length. I remember that this was controversial before. Your rationale and esthetics could be taken as arguments for using the actual array length. A close reading of your proposal shows that it proposes using the fill pointer. Current practice in Symbolics Genera is to use the fill pointer; I didn't check whether your other current practice entries referred to the fill pointer or the actual array length. Right. The reference to LENGTH was intended to establish that the fill pointer governs. Also be clearer that the start must less than or equal to the end even if the end was defaulted or NIL. Good point, thank you. In the cost to users section, I believe you have a typo, "not" where you mean "now". This is one of those commonly made unfortunate typos that reverses the meaning of a sentence. OOPS. I will double-check that. ∂25-Mar-88 2152 CL-Cleanup-mailer Issue: WITH-OPEN-STRING-APPEND-STYLE Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 25 Mar 88 21:52:08 PST Received: by labrea.Stanford.EDU; Fri, 25 Mar 88 21:52:42 PST Received: from bhopal.lucid.com by edsel id AA25619g; Fri, 25 Mar 88 21:49:38 PST Received: by bhopal id AA00832g; Fri, 25 Mar 88 21:49:33 PST Date: Fri, 25 Mar 88 21:49:33 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803260549.AA00832@bhopal.lucid.com> To: cl-cleanup@sail.stanford.edu Subject: Issue: WITH-OPEN-STRING-APPEND-STYLE Issue: WITH-OPEN-STRING-APPEND-STYLE References: CLtL, pages 331, 386 Category: CLARIFICATION Edit history: Version 1, 25-Mar-88 JonL Problem description: CLtL p386 says that FORMATting to a fill-pointer'd string should add characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that WITH-OUTUPUT-TO-STRING will work "as if using VECTOR-PUSH-EXTEND if the string is adjustable, and otherwise as if using VECTOR-PUSH". It's very unlikely that the original authors of these parts intended differing semantics for these two cases. Furthermore, the semantics for WITH-OUTUPUT-TO-STRING permit the inconspicuous loss of characters written to the string, since VECTOR-PUSH will just "drop on the floor" any characters that would go beyond the end. Proposal (WITH-OPEN-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND): Change the documentation of WITH-OPEN-STRING-APPEND-STYLE to be like that under FORMAT. That is, replace the first sentence of the next-to-last paragraph on CLtL p331 by: "If *string* is specified, it must be a string with a fill pointer; the output is incrementally appended to the string (as if by use of VECTOR-PUSH-EXTEND)." Test Case: (let ((str (make-array 4 :element-type 'string-char :fill-pointer 0))) (with-output-to-string (s str) (princ "You Luz, Bunkie!" s)) str) CLtL behaviour will return "You "; proposed behaviour will signal an error. Rationale: It's unlikely that the mention of VECTOR-PUSH in CLtL p331 was intended to suggest that characters could be quietly "dropped on the floor". In any case, there is no practical or theoretical reason to make FORMAT and WITH-OUTPUT-TO-STRING act differently on non-adjustable strings. Current Practice: VaxLisp 2.2 and Lucid 3.0 implement the proposal; Lucid 2.1 and earlier versions implement CLtL. The question is entirely moot for Symbolics since it is impossible to create a non-adjustable string, even upon demand. Adoption cost: Zilch. Benefits: Less special-casing in the semantics of "printing" to strings. More conformity with current practice. Estehtics: To quote The Great Quux: "Hey, come'on guys, this is FORMAT; there is no esthetics". Discussion: Implementations may want to actually call VECTOR-PUSH, rather than VECTOR-PUSH-EXTEND, on non-adjustable string in order to test the result -- nil means an overflow of the total length of the string; thus they may signal an error more directly related to the problem, rather than permitting VECTOR-PUSH-EXTEND to complain about a non- adjustable array. But either way, the semantics is still that of VECTOR-PUSH-EXTEND: when you get to the end of the string, adjustable strings are extended, and non-adjustable strings cause error signals. ∂29-Mar-88 0759 CL-Cleanup-mailer Issue SUBSEQ-OUT-OF-BOUNDS, version 2 Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Mar 88 07:59:37 PST Return-Path: <gls@Think.COM> Received: from kali.think.com by Think.COM; Tue, 29 Mar 88 10:57:02 EST Received: by kali.think.com; Tue, 29 Mar 88 10:56:55 EST Date: Tue, 29 Mar 88 10:56:55 EST From: gls@Think.COM Message-Id: <8803291556.AA17475@kali.think.com> To: cl-cleanup@sail.stanford.edu Subject: Issue SUBSEQ-OUT-OF-BOUNDS, version 2 Issue: SUBSEQ-OUT-OF-BOUNDS References: :START and :END arguments (246-247), SUBSEQ (248) Category: CLARIFICATION Edit history: 24-Mar-88, Version 1 by Steele 29-Mar-88, Version 2 by Steele, in response to Moon's comments Problem description: The descriptions of :START and :END arguments, and of SUBSEQ, do not explicitly address the question of out-of-bounds indices. (The language on page 246, "These arguments should be integer indices into the sequence," is considered too vague on this point.) Also, the language on page 246 does not make clear whether the prohibition against "start > end" applies to defaulted values as well as explicit values, and does not specify clearly whether the default value for the end argument is the allocated length or the active length. Proposal (SUBSEQ-OUT-OF-BOUNDS:IS-AN-ERROR): Specify that it is an error for the :START argument of any standard function, or the second argument to SUBSEQ, to be less than zero. Specify that it is an error for the :END argument of any standard function, or the third argument to SUBSEQ, to be greater than the active length of the sequence in question (as returned by LENGTH). Specify that the start value, after defaulting, must not be greater than the end value, after defaulting. Specify that the default value for the end argument is the active length of the sequence in question. This may be summarized as follows: Let X be the sequence within which indices are to be considered. Let S be the :START argument of any standard function, or the second argument to SUBSEQ, whether explicitly specified or defaulted, through omission, to zero. Let E be the :END argument of any standard function, or the third argument to SUBSEQ, whether explicitly specified or defaulted, through omission or an explicitly passed NIL value, to the active length of X, as returned by LENGTH. It is an error if the condition (<= 0 S E (LENGTH X)) is not true. Test Cases/Examples: (SUBSEQ "Where's the beef?" -1 5) might be assumed to be "Where" or " Where". (SUBSEQ "Where's the beef?" -3 -3) might be assumed to be "". (SUBSEQ "Where's the beef?" 16 18) might be assumed to be "?" or "? ". (SUBSEQ "Where's the beef?" 10000 10000) might be assumed to be "". Under this proposal each of these situations is an error, and portable programs may not rely on their behavior. Rationale: We don't want code indexing off the ends of arrays. Current practice: KCL interpreted and compiled code signals an error. Symbolics Common Lisp interpreted and compiled code signals an error; the compiler also issued an out-of-range warning (possible because the arguments were all constant). Lucid Common Lisp interpreted and compiled code signals an error. Cost to Implementors: None. Cost to Users: Users who depended on some specific implementation behavior in these cases may find that their pragmatically unportable code is now officially unportable. Cost of non-adoption: Confusion. Benefits: Removal of a small but important ambiguity in the spec. Esthetics: It seems cleaner not to allow indexing off the end of an array, and by extension not allow it for any sequence. Discussion: This merely clarifies the original intent of the passage on page 246. ∂29-Mar-88 1153 CL-Cleanup-mailer Re: Issue: WITH-OPEN-STRING-APPEND-STYLE Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Mar 88 11:53:38 PST Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAR 88 11:47:52 PST Date: 29 Mar 88 11:47 PST From: Daniels.pa@Xerox.COM Subject: Re: Issue: WITH-OPEN-STRING-APPEND-STYLE In-reply-to: Jon L White <edsel!jonl@labrea.Stanford.EDU>'s message of Fri, 25 Mar 88 21:49:33 PST To: edsel!jonl@labrea.Stanford.EDU cc: cl-cleanup@sail.stanford.edu Message-ID: <880329-114752-1361@Xerox> In the first paragraph under "Proposal" WITH-OPEN-STRING-APPEND-STYLE should be WITH-OUTUPUT-TO-STRING. Xerox Common Lisp implements CLtL for WITH-OUTPUT-TO-STRING, but treats FORMAT consistently, i.e., doesn't complain if you FORMAT off the end of a fill-pointered, non-adjustable string. I support this proposal. -- Andy. -- ∂29-Mar-88 1608 CL-Cleanup-mailer Re: Issue SUBSEQ-OUT-OF-BOUNDS, version 2 Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Mar 88 16:08:53 PST Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAR 88 16:06:52 PST Date: 29 Mar 88 16:06 PST From: Daniels.pa@Xerox.COM Subject: Re: Issue SUBSEQ-OUT-OF-BOUNDS, version 2 In-reply-to: gls@Think.COM's message of Tue, 29 Mar 88 10:56:55 EST To: gls@Think.COM cc: cl-cleanup@sail.stanford.edu Message-ID: <880329-160652-1908@Xerox> Xerox Common Lisp implements the proposal, signalling an error in all cases. I support it. -- Andy. -- ∂29-Mar-88 2140 CL-Cleanup-mailer Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2) Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Mar 88 21:39:01 PST Received: by labrea.Stanford.EDU; Tue, 29 Mar 88 21:37:36 PST Received: from bhopal.lucid.com by edsel id AA11804g; Tue, 29 Mar 88 21:32:48 PST Received: by bhopal id AA01840g; Tue, 29 Mar 88 21:32:59 PST Date: Tue, 29 Mar 88 21:32:59 PST From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8803300532.AA01840@bhopal.lucid.com> To: cl-cleanup@sail.stanford.edu Subject: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2) Issue: WITH-OPEN-STRING-APPEND-STYLE References: CLtL, pages 331, 386 Category: CLARIFICATION Edit history: Version 1, 25-Mar-88 JonL Version 2, 29-Mar-88 JonL (fix typos; comments by Daniels) Problem description: CLtL p386 says that FORMATting to a fill-pointer'd string should add characters "as if by use of VECTOR-PUSH-EXTEND"; but CLtL p331 says that WITH-OUTPUT-TO-STRING will work "as if using VECTOR-PUSH-EXTEND if the string is adjustable, and otherwise as if using VECTOR-PUSH". It's very unlikely that the original authors of these parts intended differing semantics for these two cases. Furthermore, the semantics for WITH-OUTPUT-TO-STRING permit the inconspicuous loss of characters written to the string, since VECTOR-PUSH will just "drop on the floor" any characters that would go beyond the end. Proposal (WITH-OPEN-STRING-APPEND-STYLE:VECTOR-PUSH-EXTEND): Change the documentation of WITH-OUTPUT-TO-STRING to be like that under FORMAT. That is, replace the first sentence of the next-to-last paragraph on CLtL p331 by: "If *string* is specified, it must be a string with a fill pointer; the output is incrementally appended to the string (as if by use of VECTOR-PUSH-EXTEND)." Test Case: (let ((str (make-array 4 :element-type 'string-char :fill-pointer 0))) (with-output-to-string (s str) (princ "You Luz, Bunkie!" s)) str) CLtL behaviour will return "You "; proposed behaviour will signal an error. Rationale: It's unlikely that the mention of VECTOR-PUSH in CLtL p331 was intended to suggest that characters could be quietly "dropped on the floor". In any case, there is no practical or theoretical reason to make FORMAT and WITH-OUTPUT-TO-STRING act differently on non-adjustable strings. Current Practice: VaxLisp 2.2 and Lucid 3.0 implement the proposal; Lucid 2.1 and earlier versions implement CLtL. For WITH-OUTPUT-TO-STRING, Xerox Common Lisp implements CLtL. The question is entirely moot for Symbolics since it is impossible to create a non-adjustable string, even upon demand. Adoption cost: Zilch. Benefits: Less special-casing in the semantics of "printing" to strings. More conformity with naive expectations about printing to strings. Esthetics: To quote The Great Quux: "Hey, come'on guys, this is FORMAT; there is no esthetics". Discussion: Implementations may want to actually call VECTOR-PUSH, rather than VECTOR-PUSH-EXTEND, on non-adjustable string in order to test the result -- nil means an overflow of the total length of the string; thus they may signal an error more directly related to the problem, rather than permitting VECTOR-PUSH-EXTEND to complain about a non- adjustable array. But either way, the semantics is still that of VECTOR-PUSH-EXTEND: when you get to the end of the string, adjustable strings are extended, and non-adjustable strings cause error signals. The proposal is supported by by Andy Daniels of Xerox; and by JonL and other senior staff at Lucid. ∂08-Apr-88 0951 CL-Cleanup-mailer special var type decls Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Apr 88 09:51:19 PDT Received: by ti.com id AA28559; Fri, 8 Apr 88 11:49:24 CDT Received: from dsg by tilde id AA20789; Fri, 8 Apr 88 11:29:46 CDT Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 4 Apr 88 13:55:55 CDT Message-Id: <2785172148-710565@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Mon, 4 Apr 88 13:55:48 CDT From: David N Gray <Gray@DSG.csc.ti.com> To: CL-Cleanup@SAIL.Stanford.edu Subject: special var type decls Here's something that the Common Lisp clean-up committee might want to consider for clarification: Is the following legal? (PROCLAIM '(TYPE NUMBER *X*)) (DEFVAR *X*) (DEFUN FOO () (LET ((*X* T)) (DECLARE (TYPE SYMBOL *X*)) (BAR))) Page 156 of Steele says that a proclamation is "always in force unless locally shadowed" and page 158 says type declarations "only affect variable bindings", which might be interpreted to mean that the DECLARE locally shadows the PROCLAIM. However, that interpretation would make the global type proclamation useless because it could not be relied on when compiling a function such as BAR. Consequently I would be inclined to say that the above example is an error. That still leaves a question of whether local type declarations for special bindings should be permitted if they specify a subtype of the globally proclaimed type, or whether (DECLARE (TYPE ...)) is only meaningful for lexical variables. Another example of ambiguity regarding global versus local declarations is that section 9.2 of Steele begins "Here is a list of valid declaration specifiers for use in DECLARE." What about PROCLAIM? Does that imply that FTYPE cannot be used in a PROCLAIM since it is not explicitly mentioned under the PROCLAIM function? On the other hand, IGNORE doesn't make sense in a PROCLAIM, but it doesn't explicitly say that it can't be used there. -- David Gray ∂08-Apr-88 0951 CL-Cleanup-mailer special var type decls Received: from ti.com by SAIL.Stanford.EDU with TCP; 8 Apr 88 09:51:30 PDT Received: by ti.com id AA28563; Fri, 8 Apr 88 11:49:29 CDT Received: from dsg by tilde id AA20827; Fri, 8 Apr 88 11:30:21 CDT Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Mon, 4 Apr 88 13:55:55 CDT Message-Id: <2785172148-710565@Kelvin> Sender: GRAY@Kelvin.csc.ti.com Date: Mon, 4 Apr 88 13:55:48 CDT From: David N Gray <Gray@DSG.csc.ti.com> To: CL-Cleanup@SAIL.Stanford.edu Subject: special var type decls Here's something that the Common Lisp clean-up committee might want to consider for clarification: Is the following legal? (PROCLAIM '(TYPE NUMBER *X*)) (DEFVAR *X*) (DEFUN FOO () (LET ((*X* T)) (DECLARE (TYPE SYMBOL *X*)) (BAR))) Page 156 of Steele says that a proclamation is "always in force unless locally shadowed" and page 158 says type declarations "only affect variable bindings", which might be interpreted to mean that the DECLARE locally shadows the PROCLAIM. However, that interpretation would make the global type proclamation useless because it could not be relied on when compiling a function such as BAR. Consequently I would be inclined to say that the above example is an error. That still leaves a question of whether local type declarations for special bindings should be permitted if they specify a subtype of the globally proclaimed type, or whether (DECLARE (TYPE ...)) is only meaningful for lexical variables. Another example of ambiguity regarding global versus local declarations is that section 9.2 of Steele begins "Here is a list of valid declaration specifiers for use in DECLARE." What about PROCLAIM? Does that imply that FTYPE cannot be used in a PROCLAIM since it is not explicitly mentioned under the PROCLAIM function? On the other hand, IGNORE doesn't make sense in a PROCLAIM, but it doesn't explicitly say that it can't be used there. -- David Gray ∂08-Apr-88 2242 CL-Cleanup-mailer floating point questions Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Apr 88 22:42:47 PDT Received: by labrea.Stanford.EDU; Fri, 8 Apr 88 21:42:13 PST Received: from bhopal.lucid.com by edsel id AA10628g; Fri, 8 Apr 88 22:35:20 PDT Received: by bhopal id AA08201g; Fri, 8 Apr 88 22:36:11 PDT Date: Fri, 8 Apr 88 22:36:11 PDT From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8804090536.AA08201@bhopal.lucid.com> To: chapman%lisp.DEC@decwrl.dec.com Cc: edsel!jonl@labrea.Stanford.EDU, cl-cleanup@sail.stanford.edu In-Reply-To: chapman%lisp.DEC@decwrl.dec.com's message of Fri, 8 Apr 88 07:23:21 PDT <8804081423.AA17359@decwrl.dec.com> Subject: floating point questions re: Dick reviewed my snapshot draft of the standard and suggested I talk to you about floating point number representation. . . . Do you have other thoughts on how floating point data types should be specified/implemented? I don't see any clean-up proposals that have to do with this topic, just the LEAST-POSITIVE-<mumble>-FLOAT communication. There are three problems of concern that I know about: First, for purposes of CLOS, it is very inconvenient to have sub-range types for any numerical type. In one sense, the short-float, single-float, double-float, and long-float types are sub-ranges of float; and the thorny issue is that that there are three possible variations one how they are merged. I don't know how to solve this one, except by ignoring the existence of differing float types [and there is probably at least one or two manufactures who will fight that to the hilt, since they have optimized one extreme end or the other and perhaps see this distinction as a "competitive edge"]. I *could* make a case for having only FLOAT as a Common Lisp type, leaving to the vendors the issue of foisting distinctions off on to the user [since in many cases, the distinctions will be irrelevant]. Very briefly, the three main points of this case are (1) As a standard, CLtL p16-17 guarantees virtually nothing about what single-float, double-float etc. mean; in one implementation, single could mean a 23-bit mantissa, and in another it could mean a 96-bit mantissa. Hence there is no guarantee of portability, so why bother? (2) A recent survey of some numerical analysts, in a company dedicated to selling Fortran engines, discovered the all-too-obvious fact that many many algorithms are numerically unstable when run under the IEEE 32-bit format, but are quite well-behaved under the 64-bit format; but interestingly, it turned up *no* cases of ill behaviour in the 64-bit mode that were correctible by going to a 128 bit format. [Now, this is not the same as an "ill conditioned" problem]. In short, there is a "good enough" size -- larger isn't needed, and smaller could be justified only ocasionally by savings in space and/or time. (3) On most machines, there seems to be a "preferred" format. In fact, I'm aware of some hardware where single-float operations are a tad slower than double-float ones; the driving motivation is that the numerical analysts wanted the fastest possible floating point of "good enough" size, and the other sizes were supported only for "compatibility". Also, compact representations inside arrays provide the only intesting space savings; this is quite analogous to packed arrays of integers [e.g., an array element-type of (signed-byte 8)] [Since a larger group is being cc'd, I'd like to appeal to that group *not* to flood the mailing list with lots of trivial counterexamples to each of the above generalizations. I'm sure they've all been thought of before; and since the status quo will remain until an actual proposal is made, there is no need to argue against a non-proposal. If anyone would like to contact me privately about pursuing such a proposal, I will respond; but so far, I haven't seen much interest]. Second, some implementations permit "extremals" to be representable numbers, and others don't; e.g., the IEEE standard allows for "denormalized" and "infinity" numbers, while VAX and IBM/370 don't. So the question arises as to just what "least-positive-<mumble>-float" means; is it the smallest possible representation, or is it the smallest "normal" representation? Paul Hilfinger (at Berkeley) feels rather strongly that is should be the smallest possible representation; but now that raises the issue that on some implementatons, "least-positive-<mumble>-float" is a perfectly normal number causing no exceptions whatsoever, while on others it will cause an "underflow" type trap whenever it is produced (unless you turn off trapping, and yes, "gradual underflow" really is "underflow"). About the best consensus I could get was to follow Symbolics lead and add the names "least-positive-normalized-<mumble>-float", so that there would be a portable way of dealing with the smallest reasonable number. Also: (eql least-positive-<mumble>-float least-positive-normalized-<mumble>-float) could be used as a test to determine whether or not the implementation supports denormalized numbers. A possible third trouble is with "most-positive-<mumble>-float" -- should this be the largest reasonable number, or the largest possible representation? If the latter, then in the IEEE format, the positive infinity should be "most-positive-<mumble>-float" since it certainly is larger than any other float. By analogy with the difference between "least-positive-..." and "least-positive-normalized-...", I would have liked to see "most-positive-..." and "most-positive-normalized-..."; that way, the test (= most-positive-<mumble>-float most-positive-normalized-<mumble>-float) could be used to determine whether or not the implementation supports infinities. But alas, I couldn't convince QUUX (Guy Steele) about this one, so I'm not sure it's worth wasting any more time over. -- JonL -- ∂10-Apr-88 1509 CL-Cleanup-mailer Issue: REST-ARGUMENT-EXTENT Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Apr 88 15:09:34 PDT Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 379386; Sun 10-Apr-88 18:09:16 EDT Date: Sun, 10 Apr 88 18:09 EDT From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM> Subject: Issue: REST-ARGUMENT-EXTENT To: CL-Cleanup@SAIL.STANFORD.EDU cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM, Hornig@ALDERAAN.SCRC.Symbolics.COM, PRobertson@MEAD.SCRC.Symbolics.COM, Laddaga@MEAD.SCRC.Symbolics.COM Message-ID: <880410180905.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> I wrote the following "straw man" proposal mostly because I'm tired of seeing the incessant mail on Common-Lisp about this topic and I'm hoping we can quickly work toward having something to push back at the Common-Lisp community to appease them on this obviously important issue. I expect that this will go through a few iterations before the form and content settle down, but I just wanted to get something concrete (straw?) on our table... ----- Issue: REST-ARGUMENT-EXTENT References: 5.2.2 Lambda Expressions (pp59-66) Category: ADDITION Edit history: 10-Apr-88, Version 1 by Pitman Status: For Internal Discussion Problem Description: Currently, all lists created for use with the &REST syntax in lambda lists have indefinite extent. Many users have complained that this is not always necessary and often creates unnecessary garbage. Proposal (REST-ARGUMENT-EXTENT:GENERAL) Introduce a DYNAMIC-EXTENT declaration such that (DECLARE (DYNAMIC-EXTENT variable)) would permit the implementation to make the list held by the indicated VARIABLE to have only dynamic extent. Example: (DEFUN FOO (&REST L) (DECLARE (DYNAMIC-EXTENT L)) (APPLY #'BAR L)) Rationale: This would allow the programmer to declare general information about data flow which it might be difficult or impossible for a compiler to obtain mechanically. Proposal (REST-ARGUMENT-EXTENT:CONSERVATIVE) Introduce a DYNAMIC-EXTENT declaration such that (DECLARE (DOWNWARD-REST-ARGUMENT)) would permit the implementation to make the list held by the rest argument to the immediately containing binding form have only dynamic extent. It would be an error if the immediately containing binding form did not have an &REST specifier to which this declaration could apply. Example: (DEFUN FOO (&REST L) (DECLARE (DOWNWARD-REST-ARGUMENT)) (APPLY #'BAR L)) Rationale: This would allow the programmer to declare specific information about rest argument data flow which it might be difficult or impossible for a compiler to obtain mechanically, but would not attempt to treat the more general issue of how this related to other kinds of data flow. Current Practice: Lucid implements REST-ARGUMENT-EXTENT:GENERAL [at least for rest arguments; I don't know if they attach a meaning to its use for any other arguments. -kmp] Symbolics Cloe implements REST-ARGUMENT-EXTENT:CONSERVATIVE. Cost to Implementors: Since implementations are only allowed (and not required) to make any use of this declaration, there is no forced cost. In practice, though, some users will probably get irritated if implementations fail to do something useful with this declaration, so some implementors may end up having to pay even if they don't technically have to. Fully implementing even dynamic rest lists (let alone dynamic objects of all kinds or for other data flow paths, whatever that may mean) may not be a small change in some implementations. There is possible interaction with garbage collection, possible implications on hidden assumptions in code generation for stack winding and unwinding, TYPEP, etc. depending on how the details of how dynamic lists end up being implemented. Cost to Users: None. This is an upward-compatible change for users. Many users are already exploiting this feature in an implementation-dependent way, so this change will improve the maintainability of code for those implementations and may encourage some new implementations to offer equivalent functionality. Cost of Non-Adoption: Some users will continue to be discouraged with implementations that do "gratuitous heap consing" of rest lists. Benefits: Many implementors claim that large improvements in the performance of programs (and their associated garbage collection) are to be had from adopting some form of proposal such as this. Aesthetics: Debugging program errors involving dynamic extent objects can be very tricky. This feature should be strongly discouraged for naive programmers. Discussion: The example above is perhaps not the best example because APPLY is something the compiler can have primitive knowledge about, and good compilers may in fact already optimize this case even without the need for a user declaration. Nevertheless, if the function were MY-APPLY rather than APPLY, the case would be made because (non-block) compilers cannot make assumptions about what MY-APPLY would do without violating the normal rules for modular compilation. KMP supports REST-ARGUMENT-EXTENT:CONSERVATIVE pending discussion of why REST-ARGUMENT-EXTENT:GENERAL is not overkill. ∂11-Apr-88 0831 CL-Cleanup-mailer Issue: REST-ARGUMENT-EXTENT Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 11 Apr 88 08:31:32 PDT Received: from WINTER.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 184615; Mon 11-Apr-88 11:31:03 EDT Date: Mon, 11 Apr 88 11:31 EDT From: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM> Subject: Issue: REST-ARGUMENT-EXTENT To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, CL-Cleanup@SAIL.STANFORD.EDU cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, PRobertson@MEAD.SCRC.Symbolics.COM, Laddaga@MEAD.SCRC.Symbolics.COM In-Reply-To: <880410180905.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> Message-ID: <19880411153115.5.HORNIG@WINTER.SCRC.Symbolics.COM> I favor REST-ARGUMENT-EXTENT:GENERAL. In its current form it can replace use of WITH-STACK-LIST, which I consider a major improvement. Extended slightly to apply to other aggregates, it could replace STACK-LET, another simplification. Things to consider: Should there be a form of this that makes the same guarantees about all levels of structure? This would allow building trees with dynamic extent. It might be nice to have a form analogous to the use of THE with type declarations for this declaration. ∂11-Apr-88 1032 CL-Cleanup-mailer Re: Issue: REST-ARGUMENT-EXTENT Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Apr 88 10:32:11 PDT Received: from Salvador.ms by ArpaGateway.ms ; 11 APR 88 10:24:35 PDT Date: 11 Apr 88 10:23 PDT From: masinter.pa@Xerox.COM Subject: Re: Issue: REST-ARGUMENT-EXTENT In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of Sun, 10 Apr 88 18:09 EDT To: KMP@STONY-BROOK.SCRC.Symbolics.COM cc: CL-Cleanup@SAIL.STANFORD.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM, Hornig@ALDERAAN.SCRC.Symbolics.COM, PRobertson@MEAD.SCRC.Symbolics.COM, Laddaga@MEAD.SCRC.Symbolics.COM Message-ID: <880411-102435-11763@Xerox> I find the distinction between parameters and arguments useful enough to want to change the name of this issue. The &REST parameter is bound to a list containing the rest of the arguments; the issue is not the extent of the argument but rather REST-PARAMETER-VALUE-EXTENT, or, more concicely although more ambiguously, REST-LIST-EXTENT. As a feature to be added to the standard, this proposal is fairly weak: it adds an optional declaration which exists in some implementations. For implementations that do not already have this feature, is this the "optimal" feature to add? For example, should it instead be the case that we might allow the rest parameter to be bound to a vector (as JonL has suggested?). Note that there is a related issue, currently named REST-LIST-ALLOCATION, which addresses the ambiguity over whether rest lists are shared in the case where APPLY is used. I think we do have some obligation to resolve ambiguities in the current specification before going on to add (optional) features. ∂12-Apr-88 0347 CL-Cleanup-mailer Issue: REST-ARGUMENT-EXTENT Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 12 Apr 88 03:47:35 PDT Received: by labrea.Stanford.EDU; Tue, 12 Apr 88 02:47:03 PST Received: from bhopal.lucid.com by edsel id AA23917g; Tue, 12 Apr 88 03:36:41 PDT Received: by bhopal id AA18246g; Tue, 12 Apr 88 03:37:44 PDT Date: Tue, 12 Apr 88 03:37:44 PDT From: Jon L White <edsel!jonl@labrea.Stanford.EDU> Message-Id: <8804121037.AA18246@bhopal.lucid.com> To: masinter.pa@xerox.com Cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu, Moon@stony-brook.scrc.symbolics.com, Hornig@alderaan.scrc.symbolics.com, PRobertson@mead.scrc.symbolics.com, Laddaga@mead.scrc.symbolics.com In-Reply-To: masinter.pa@Xerox.COM's message of 11 Apr 88 10:23 PDT <880411-102435-11763@Xerox> Subject: Issue: REST-ARGUMENT-EXTENT I generally agree with your assessment, Larry, although I am pessimistic about bringing up &rest vectors again -- a *lot* of code already exists in the Common Lisp world which assumes that the &rest parameter is bound to a list. On the other hand, while Kent may have noticed the large number of messages sent recently to Common-Lisp@sail on this topic, but I wonder if he read them? The overwhelming majority of them concerned user disatisfaction with the unexpected "sharing" of rest lists -- our issue REST-LIST-ALLOCATION. As Gail Z put it so succinctly -- if the CL spec can't get its act together to guarantee non-sharing in &rest lists, then there *must* be some construct added to the language so that the discerning user can prevent it. In my message to Common-Lisp@sail of 8 Apr 88 01:00:38 PDT I quoted her: Gail Zacharias talked about the common idiom of simply doing a COPY-LIST on every &rest argument, to insure some normalcy. Her reasoning seems, to me, to bolster the case for those who claim that that CL semantics are deficient Subject: &REST Lists Date: 24 Mar 88 12:23:15 EST (Thu) From: gz@spt.entity.com (Gail Zacharias) . . . If Common Lisp doesn't require unshared &rest lists, then I think it must provide a declarative version of this idiom so the COPY-LIST can be portably avoided when it's redundant. Seems to me that the fact that this is a common case where users find a need for conditionalization indicates a real deficiency in Common Lisp's specification. . . . Of course, the problem isn't only the sharing of &rest lists, but the more common flaw that they may, unannouncedly, have dynamic extent. By this, I mean the bug where a stack-allocated &rest list can creep out into global data structures, even though it will surely disappear when the frame that created it returns. Allegedly, Symbolics is going to fix this bug in their next release (and TI may have already fixed it?); but we are now five years beyond the first CL specification! So as you say, we have a responsibility to resolve the very thorny issue of REST-LIST-ALLOCATION. On the other hand, since CL semantics already requires indefinite extent for &rest values, and since Symbolics has been in violation of this part for so many years, *** and because a subset of users find dynamic extent extremely userful *** then I don't think it would hurt all that much to bless the effort to standardize the syntax for asking for it. -- JonL -- P.S.: When I questioned whether Kent read the messages sent to Common-Lisp mailing list, there was no intent to question his mental compotence. Some months back he defended the dumping of a Symbolics internal discussion onto the CL-Cleanup mailing list by saying that he refused to read the allegedly voluminous Common-Lisp mails, and thus couldn't carry on the discussion there. ∂13-Apr-88 1331 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 1) Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 13 Apr 88 13:31:19 PDT Received: by multimax.ARPA (5.51/25-eef) id AA03781; Wed, 13 Apr 88 16:31:20 EDT Received: from localhost by mist.UUCP (3.2/4.7) id AA00868; Wed, 13 Apr 88 16:32:28 EDT Message-Id: <8804132032.AA00868@mist.UUCP> To: cl-cleanup%sail.stanford.edu@multimax Subject: Issue: FORMAT-PRETTY-PRINT (version 1) Date: Wed, 13 Apr 88 16:32:26 EDT From: Dan L. Pierson <pierson%mist@multimax.ARPA> Sorry, I've been sitting on this one for a while. Issue: FORMAT-PRETTY-PRINT References: FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83), WRITE (p. 382), *PRINT-PRETTY* (p. 371) Category: CLARIFICATION Edit history: Version 1 by Pierson 3/4/88 Status: For Internal Discussion Problem description: The FORMAT operators, ~A and ~S are defined to print their argument as PRINC and PRIN1 respectively. The text does not say whether or not these FORMAT operators must obey the *PRINT-PRETTY* flag. Proposal (FORMAT-PRINT-PRETTY:YES): The ~A and ~S FORMAT operators (and the ~B, ~D, ~E, ~F, ~G, ~, ~O,
~R, and ~X FORMAT operators when they encounter a non-numeric value)
are required to treat all *PRINT-foo* variables the same as PRINC and
PRIN1 respectively.  [[ Yes, this is a bit broader than the title, but
if we're going to clarify this we might as well do the whole job.  I
don't think any of the other variables are likely to be controversial.]]

Test Cases/Examples:

(LET ((TEST '(LAMBDA (X)
(LET ((*PRINT-PRETTY* T))
(PRINT X)
(FORMAT T "~%~S " X)
(TERPRI) (PRINC X) (PRINC " ")
(FORMAT T "~%~A " X)))))
(FUNCALL TEST TEST))

This should print four copies of the above lambda expression.  The
first pair should appear identical and the second pair should appear
identical.  The only difference between the two pairs should be the
absence of string quotes in the second pair.  Note that this example
won't work as written if the proposal FUNCTION-TYPE:STRICT-REDEFINITION
is accepted.

Rationale:

FORMAT should interact with the *PRINT-foo* variables in a predictable
way.  This proposal is one of the two simplest possible definitions
and provides the most flexibility to the user.

Current practice:

Ibuki Lisp obeys the binding of *PRINT-PRETTY*.  Lucid Common Lisp
always applies ~A and ~S with *PRINT-PRETTY* bound to NIL.

Cost to Implementors:

While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications.  How does a pretty-printing ~A
interact with MINCOL, etc?  How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?

Cost to Users:

Truely portable code shouldn't be affected because existing
implementations are inconsistent.  Despite this, there are probably a
number of user programs in non-complying which will have to change
whichever way this is decided.

The interaction of FORMAT and the *PRINT-foo* variables (especially
pretty printing) will remain undefined.  This will continue to make
portable Common Lisp programming harder than it need be.

Benefits:

Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.

Aesthetics:

The interaction between two related parts of output will be clarified
in a simple way.

Discussion:

Pierson feels that this is important because the ease of implementing
major system interfaces with FORMAT can unintentionally lead to less
flexibility for the user compared to an old-style PRIN1/PRINC/TERPRI
implementation.  This clarification would generate some up front work
but would make it harder for people to accidentally create restrictive
interfaces.

∂13-Apr-88  1334	CL-Cleanup-mailer 	[Jim McDonald: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)]
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 13 Apr 88  13:34:39 PDT
id AA03790; Wed, 13 Apr 88 16:34:43 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA00898; Wed, 13 Apr 88 16:35:51 EDT
Message-Id: <8804132035.AA00898@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: [Jim McDonald: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)]
Date: Wed, 13 Apr 88 16:35:45 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

Jim asked me to forward this to the cleanup committee a while ago.  I
think that it has some interesting ideas, but delves too much into
specifying implmentation for standards proposal.

------- Forwarded Message

Return-Path: @multimax.ARPA:edsel!jlm@labrea.Stanford.EDU
Received: from multimax.ARPA by mist.UUCP (3.2/4.7)
id AA23038; Wed, 2 Mar 88 10:00:47 EST
id AA15330; Wed, 2 Mar 88 10:00:47 EST
Received: by labrea.Stanford.EDU; Tue, 1 Mar 88 12:37:31 PST
Received: from bhopal.lucid.com by edsel id AA06372g; Tue, 1 Mar 88 11:47:41 PST
Received: by bhopal id AA05626g; Tue, 1 Mar 88 11:53:43 PST
Date: Tue, 1 Mar 88 11:53:43 PST
From: Jim McDonald <edsel!jlm@labrea.Stanford.EDU>
Message-Id: <8803011953.AA05626@bhopal.lucid.com>
To: pierson@multimax.arpa
In-Reply-To: Dan L. Pierson's message of Mon, 29 Feb 88 18:55:14 EST <8802292355.AA19855@mist.UUCP>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 2)
Cc: edsel!eb@labrea.Stanford.EDU, edsel!jonl@labrea.Stanford.EDU,
edsel!lnz@labrea.Stanford.EDU, edsel!kdo@labrea.Stanford.EDU

Dan -- you might want to consider these comments I drafted a few weeks
ago.  They're not quite in proposal format (the header is just for
your reference), but if you like the sense of this I can clean it up.
I think this is basically a generalization of your proposal (or at
least is more open-ended):

- -----

Issue:         STANDARD-INPUT-INITIAL-BINDING
References:    Standard streams (pp. 327-329)
Category:      CHANGE
Edit history:  Version 1 by Pierson and Haflich 1/19/87
Version 2 by Pierson 2/29/88
Version 3 by McDonald 3/01/88
Status:        For Internal Discussion

A number of primitive streams are instantiated when lisp starts
(via the function primitive-streams), and the results of that
function are then used to build the higher level streams seen by
users.

- ------

primitive-streams &optional create-streams-p [function]

If create-streams-p is true, creates and opens primitive streams in
an implementation-dependant manner.  Data associated with any
previously existing streams may be lost, and the effects of previous
calls to add-primitive-stream and delete-primitive-stream may be
lost.  Normally, create-streams-p will be true for just a single

Always returns a list of triples of the form:

(<keyword> <input-stream or nil> <output-stream or nil>).

The following triples must be included in this list, but more are
allowed, and various of the stream objects may be eq:

((:terminal-input   #<input-stream>  nil)
(:terminal-output  nil              #<output-stream>)
(:standard-input   #<input-stream>  nil)
(:standard-output  nil              #<output-stream>)
(:error-output     nil              #<output-stream>)
(:query-input      #<input-stream>  nil)
(:query-output     nil              #<output-stream>))

It is an error to destructively modify this list or any of the
triples within it.  Different calls to primitive-streams are free to
return eq lists or not, as convenient.

- ------

Causes a three element list of the arguments to be prepended to the
list of triples returned by subsequent calls to (primitive-streams).

Signals an error if the first argument is not a keyword, if the
second argument is not nil or an input-stream, or if the third
argument is not nil or an output-stream.

Returns NIL.

Note that this can be used to "shadow" :terminal-input, etc.

- ------

delete-primitive-stream (keyword)

The first triple starting with keyword which would otherwise have
been returned by (primitive-streams) will no longer appear in the
list of triples returned by (primitive-streams).

Signals an error if the argument is not a keyword.

Returns the triple which is deleted, or NIL if none existed, or
:ERROR if the triple selected may not be removed.

Note that this can be used to remove shadowing triples for
:terminal-input, e.g., but not all triples for it.

- ------

During lisp startup, two forms are executed:

(primitive-streams t)
(initialize-stream-variables)

Initialize-stream-variables is defined by default as follows, but
implementations and/or users, applications, etc., can redefine it or
simply reset or rebind the stream variables as they choose.

(defun initialize-stream-variables ()
(let ((primitive-streams (primitive-streams)))
(setq *terminal-io*
(make-two-way-stream
(second (assoc :terminal-input  primitive-streams))
(third  (assoc :terminal-output primitive-streams))))
(setq *standard-input*
(second (assoc :standard-input  primitive-streams)))
(setq *standard-output*
(third  (assoc :standard-output primitive-streams)))
(setq *error-output*
(third  (assoc :error-output    primitive-streams)))
(setq *query-io*
(make-two-way-stream
(second (assoc :query-input  primitive-streams))
(third  (assoc :query-output primitive-streams))))
))

- ------

Rather than mandating portability via some least common denominator,
this proposal makes stream initialization more of an open system, easy
to tailor to individual situations.

The rules are also intended to enable user code to be able to restore
*terminal-io*, *standard-input*, *standard-output*, *error-output*,
and *query-io* to reasonable values, even if all of them have been
set to NIL or other undesirable values.

The functional interface to the triples is designed to discourage
random tampering with sensitive data.

------- End of Forwarded Message

∂17-Apr-88  1740	CL-Cleanup-mailer 	FORMAT-PRETTY-PRINT
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 17 Apr 88  17:39:58 PDT
Date: 17 Apr 1988 20:38-EDT
Sender: MATHIS@A.ISI.EDU
Subject: FORMAT-PRETTY-PRINT
From: MATHIS@A.ISI.EDU
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]17-Apr-88 20:38:31.MATHIS>

we should include Dick Waters at MIT on this one, but I don't
have his address in front of me right now.  -- Bob

∂26-Apr-88  2114	CL-Cleanup-mailer 	miscellaneous questions about declarations and type specfiers
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 26 Apr 88  21:14:34 PDT
Received: by labrea.Stanford.EDU; Tue, 26 Apr 88 21:14:38 PDT
Received: from bhopal.lucid.com by edsel id AA12440g; Tue, 26 Apr 88 19:57:24 PDT
Received: by bhopal id AA03767g; Tue, 26 Apr 88 19:59:27 PDT
Date: Tue, 26 Apr 88 19:59:27 PDT
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8804270259.AA03767@bhopal.lucid.com>
To: goldman@vaxa.isi.edu
Cc: common-lisp@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: goldman@vaxa.isi.edu's message of Tue, 26 Apr 88 13:27:25 PDT <8804262027.AA08691@vaxa.isi.edu>
Subject: miscellaneous questions about declarations and type specfiers

re: 1)is there any portable way to obtain the expansion of a type
specifier (FOO ...), given that FOO was defined by
(deftype FOO  ...)

I don't think so.  Sounds reasonable enough though -- I'll put it on my
personal list of items which ought to be submitted to the X3J13 Cleanup
committee for consideration.  [I already have 7 or 8 issues relating
to the type system]

2) is there any portable way to ask if DEC is a legitimate declaration
specifier in an implementation (including the possibility that DEC
has been legitimized with
(PROCLAIM '(DECLARATION DEC))

Again I don't think so.  Maybe this ought to go in with a proposal for some
functions that will query the global database relevant to proclamations and
declarations (e.g., has a particular variable been proclaimed special?  what
is the current global settings of the OPTIMIZE qualities? and so on.)

3) is there any portable way to ask if a symbol or list S is a legitimate
type specifier in an implementation?

Guy Steele circulated several pages of "Clarifications" in December 1985,
in which he proposed adding a function TYPE-SPECIFIER-P.  I don't see it
on the current agenda of the X3J13 Cleanup committee; consequently it has
been on my personal list of items that ought to be submitted "soon"

-- JonL --

∂13-May-88  0236	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 13 May 88  02:36:31 PDT
Received: by labrea.stanford.edu; Fri, 13 May 88 02:23:56 PDT
Received: from bhopal.lucid.com by edsel id AA11362g; Fri, 13 May 88 02:15:28 PDT
Received: by bhopal id AA25649g; Fri, 13 May 88 02:18:34 PDT
Date: Fri, 13 May 88 02:18:34 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805130918.AA25649@bhopal.lucid.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS

Issue:         ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS

References:    Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
ARRAY-ELEMENT-TYPE, CLtL p. 291

Category:      CHANGE

Edit history:  Version 1, 13-May-88, JonL

Problem description:

The distinction between type-specifiers "for declaration" and "for
discrimination" is made only for array type specifiers -- those that are
subtypes of ARRAY.  Discussion on the Common Lisp electronic mailing list
in late 1987 and January 1988 shows that many people are confused by this
one-of-a-kind situation.  This may be one of the more insidious flaws
in the current CL design.

A consequence of this "flaw" is that a variable declared to be of type
<certain-type>
and all of whose assigned objects are created in accord with that type,
still may have *none* of its values ever satisfied by the TYPEP predicate
with that type-specifier.  One type-specifier with this property in most
implementations of CL is  <certain-type>  =  (ARRAY (SIGNED-BYTE 5)).
An array created with this type specifier will, depending on the vendor,
either be of typep (ARRAY (SIGNED-BYTE 8)) or (ARRAY T); but (almost)
never of typep (ARRAY (SIGNED-BYTE 5)).

It would be much simpler if the real source of the problem that led to
this split up could be resolved.  Two proposals will be offered, each
rejecting this odd distinction, but in different ways.  Because there
are two proposals, some of the common discussion has been moved up
into the problem description part.

No one seems to remember just exactly why this "warp" was put into Common
Lisp in the first place; possibly it was added in a mistaken belief that
it would promote portability. ["Mistaken", because the source of non-
portability is the permission to upgrade; if two different implementations
do any upgrading differently, then the effect will be the same kind of
non-portability that results when two different implementations set the
boundary between fixnums and bignums differently.]

A common feeling among Common Lisp users is that the set of type-specifiers
forms a mathematical language, and the SUBTYPEP relation is generated by some
basic, generating set of relations between these names.  People want to see
this language actually describing the implementation in which it is running
-- that the objects of the implementation are a model for that language --
rather than seeing it be limited to some theoretical model which no vendor
bothers to implement.   Hence, typep and subtypep should be changed to
reflect what kinds of arrays get built; alternatively, make-array should
be changed to exhibit the distinctions that typep makes.

One possibility for unification arises from focusing on type specifiers
as names for collections of objects, and on SUBTYPEP as a kind of "subsetp"
for collections of objects.

-- The second paragraph of page 11 makes it clear that "data types" are
just sets of objects; subsequent discussion makes it clear that the
second argument to TYPEP (a type specifier) is a name for some such
set, and that there may be several distinct names specifying the same
set (or type).  The first paragraph of section 6.2.1 on page 72 says
that TYPEP is a set membership test, and SUBTYPEP is a subset test.

-- The first two paragraphs of section 4.5, on page 45, describe a
permission for what may be called "element-type upgrading" on arrays;
the  documentation for ARRAY-ELEMENT-TYPE on page 291 also makes it
clear that a conforming implementation is permitted to "collapse"
array element types into some more limited set of types, providing
that the array returned by make-array is at most an "upgrade".  The
array types STRING and BIT-ARRAY are excluded from upgrading.

For example, depending on how primitive arrays are actually implemented,

(make-array <dims> :element-type '(signed-byte 5))

and

(make-array <dims> :element-type '(signed-byte 8))

might legitimately create arrays specialized to hold exactly the same set of
objects.  The only constraint seems to be that that (array (signed-byte 8))
be the most specific type  *** in that implementation *** which can hold
all the arrays made by (make-array <dims> :element-type '(signed-byte 5) ...).
In this case, we say that the array element type has been upgraded from
(signed-byte 5) to (signed-byte 8), and we imply that there is no particular
special provisions for arrays of element type, say, (signed-byte 6).

By the bulletted paragraphs above, (array (signed-byte 5)) and
(array (signed-byte 8)) are in fact names for exactly the same
set of objects.

However pages 45 and 46 go at length to specify that these two different
names for the same set of objects must be treated differently by TYPEP
and SUBTYPEP.  This seems to "warp" the utility of TYPEP since it puts
it at variance with the fundamental principle: "SUBTYPEP means subsetp".

To get a sense of how the community is "confused", see the arpanet
mailing list for Common Lisp, in a series of exchanges started on
Thu, 17 Dec 87 10:48:05 PST by Jeff Barnett <jbarnett@nrtc.northrop.com>
under the subject line of "Types in CL".  Also see the exchange started
Wed, 6 Jan 88 23:21:16 PST by Jon L White <edsel!jonl@labrea.stanford.edu>
under the subject line of "TYPEP warp implications"

[Notation: because of the inability to show meta- or linguistic variables
in a different typeface, some code examples will use a backquote format;
a form like ",x" will simply mean "substitute the value of x here".
and a form like (...) will simply mean "evaluate this first, doing
the indicated comma substitutions."  Also, the term "type-equivalent"
will be used to denote two types which are each subtypes of the other;
this relation establishes a partition on the set of type-specifiers
into disjoint sets, and members of the same equivalence class are
simply different names for the same type.]

One interesting krinkle in this issue is the question as to whether two
non-EQ but type-equivalent type-specifiers ,aet-x and ,aet-y could give
rise to different array types.  Remember that (array ,aet-x) and
(array ,aet-y) are type-equivalent only if ,aet-x is type-equivalent
to ,aet-y.  But this doesn't say anything about the reverse implication:
does ,aet-x being type-equivalent to ,aet-y necessarily imply that
(array ,aet-x) is type-equivalent to (array ,aet-y)?  For example,
consider SHORT-FLOAT and SINGLE-FLOAT in an implementation where these
are type-equivalent (because only one internal float type is provided for
Lisp objects -- see CLtL section 2.1.3).  One may desire to implement
(ARRAY SHORT-FLOAT) and (ARRAY SINGLE-FLOAT) differently; say, for example
that the former is packed into 16-bit half-words, whereas the latter is
packed into 32-bit words.  But for either kind of packing, the result of
AREF is an ordinary "single-float"; the whole point is merely to specify
a packing technique for "packed float" arrays.

Test case:

Let aet-x and aet-y be two distinct type specifiers that are definitely
not type-equivalent in a given implementation, but for which make-array
will return an object of the same primitive type; let this primitive
type be described by (array ,aet-y).  This will be an implementation
dependent search, but in every implementation that the present writer
(JonL) has tested, there will be some such types; often, (signed-byte 5)
and (signed-byte 8) will work.  Thus in each case, it should be true that:

(array-element-type (make-array 0 :element-type ',aet-x))  ==> ,aet-y
(array-element-type (make-array 0 :element-type ',aet-y))  ==> ,aet-y

and if such a function exists, then:

Now for a first set of tests; to eliminate the distinction between "for
declaration" and "for discrimination" both of the following should be true:

[A]
(typep (make-array 0 :element-type ',aet-x)
'(array ,aet-x))
(typep (make-array 0 :element-type 'aet-y)
'(array ,aet-y))

Since (array ,aet-x) and (array ,aet-y) are different names for exactly
the same set of objects -- those arrays specialized to hold elements of
type aet-y -- then if the correlation between type-names and sets of objects
is being observed, these names should be type-equivalent.  That means that
both of the following tests should be true:

[B]
(subtypep '(array ,aet-x) '(array ,aet-y))
(subtypep '(array ,aet-y) '(array ,aet-x))

to the same "element type" should be equivalent as element-type specifiers,
then both the following type tests should be true:

[C]
(typep (make-array 0 :element-type ',aet-y)
'(array ,aet-x))
(typep (make-array 0 :element-type ',aet-x)
'(array ,aet-y))

-- Delete all the documentation that suggests the :element-type argument
to make-array might not be a satisfactory element-type in the type
specifier for the kind of array produced.  Particularly, delete the
documentation that permits a difference between type-specifiers "for
declaration" and "for discrimination;  primarily this means parts
of the discussion in CLtL, section 4.5, p. 45 and 46.  Include a
statement that (array ,aet) is a suitable type-specifier for the
array made by (make-array <dims> :element-type ',aet ...).

-- Change the documentation of ARRAY-ELEMENT-TYPE, CLtL p. 291 by deleting
the sentence begining "This set may be larger than the set requested
when the array was created; for example . . ."

-- Introduce a function UPGRADE-ARRAY-ELEMENT-TYPE, which will reveal how
a particular :element-type argument to make-array will be treated.
Semantically, this would be equivalent to:
(array-element-type (make-array 0 :element-type element-type)))
but it wouldn't have to cons up the 0-element array first.  Also,
the presence of this name, as a documented function in the language,
would serve notice that "upgrading" is an important aspect of any real
implementation of CL arrays.

-- Change TYPEP (and SUBTYPEP) so that (typep x '(array ,aet)) is true
if and only if (typep x '(array ,(upgrade-array-element-type aet)))
is true.

Rationale:

This proposal legitimizes current practice, and removes the obscure and
un-useful distinction  between type-specifiers "for declaration" and "for
discrimination".

Current Practice:

Every vendor's implementation that the present writer has queried does
some amount of non-trivial "upgrading" [generally, using (signed-byte 5)
as an :element-type argument to make-array will show it]; this includes
LUCID, VAXLISP, SYMBOLICS, FRANZ, and XEROX. Most implementations fail
tests [A] and [C] part 1, but pass tests [A] and [C] part 2; this is a
consequence of implementing the distinction between "for declaration" and
"for discrimination".  Lucid and Xerox both pass test [B], and the other
vendors fail it [it may be that these two vendors have implemented a
partial solution for subtypep, with a view to future extensions.]

Typically, a small amount of work will be required in every vendor's
implementation of TYPEP and SUBTYPEP; some vendors may have already
done the work, but not fully integrated it.

Benefits:

It will greatly reduce confusion in the user community; the fact that
(make-array <n> :element-type '<aet>) frequently is not of type (array <aet>)
has been very confusing to almost everyone.   That is, in practice,
the distinction between "for declaration" and "for discrimination" has
been a disaster.

Conversion Cost:

Because of the prevalence of confusion in this area, it seems that no
user code will have to be changed.  In fact, it is more likely that
some of the vendors will cease to get bug reports about some array
that didn't seem to be of "the obvious type".

Esthetics:

Discussion:

Many persons are in favor of the permission to upgrade; but they would not
like to see CL become a language like C where there are a prescribed set of
kinds of arrays that must be implemented (e.g, "int", "long int", "single",
"double" etc), and no others can exist.  In short, no one would not want to
gain portability at the expense of limiting the language to the architectural
features of the hardware on which it was first implemented.

Many senior implementors at Lucid favor this proposal.  In network mail
"Date: Sat, 9 Jan 1988  15:54 EST" Rob McLaughlin favored the gist of this
proposal -- namely that upgrading should be continued, and that TYPEP should
be fixed.  Here is an excerpt of his words:
There are two obvious solutions, one of which has already been proposed:
-- Make the mapping more direct.  Eliminating "array element type
upgrading" would be an instance of this.
-- Make the mapping explicitly ill-defined in a more useful way.
I think we need to do the latter because the former won't work.  I don't
see how to eliminate "array element type upgrading" without creating
more problems [than] we solve.  . . .

My conclusion is that it isn't array types that are wrong, it is the
understanding of the meaning of TYPEP that is wrong.

One possible criticism of this proposal is that it hinders portability by
exposing an implementation dependent facet, namely the "upgrading" function.
But the kind of portabililty achieved by a programmer ignorant of the
realities of array implementations -- that only a finite number of
type classes are really implemented efficiently in any particular
CL implementation -- would be a very pyrrhic victory to say the least.
The kinds of attention a programmer would have to pay to these array type
boundaries is the same kind of attention he now has to pay to the
fixnum/bignum boundary (i.e., arithmetic that is doable in unit time,
and that which requires tens to hundreds of units of time).

-- Delete all the documentation that suggests the :element-type argument
to make-array might not be a satisfactory element-type in the type
specifier for the kind of array produced.  Particularly, delete the
documentation that permits a difference between type-specifiers "for
declaration" and "for discrimination;  primarily this means parts
of the discussion in CLtL, section 4.5, p. 45 and 46.  Include a
statement that (array ,aet) is a suitable type-specifier for the
array made by (make-array <dims> :element-type ',aet ...).  Include
also a statement that if (array ,aet-x) and (array ,aet-y)	 are
type-equivalent, then it must be the case that ,aet-x and ,aet-y are
also type-equivalent.

-- Change the documentation of ARRAY-ELEMENT-TYPE, CLtL p. 291 by deleting
the sentence begining "This set may be larger than the set requested
when the array was created; for example . . ."

-- Change the implementation of arrays so that a canonical member of
the equivalence class around the :element-type argument is always
remembered; ARRAY-ELEMENT-TYPE should return this canonical member.

Rationale:

This makes for maximum portability; type specifiers are "remembered"
exactly as the user typed them in (up to type-equivalence transformations).

Current Practice:

No vendor implements this.

Array implementations would have to be changed in every vendor; for some,
this could be an enormous amount of work.  In some implementations, the
"cheapest" primitive arrays might become considerably more costly.  Since
arrays seem to be at the base of every Common Lisp system, the effects of
this change could be widespread, and costly to fix.

Benefits:

Being in love with portability means never having to say you're sorry

Conversion Cost:

Because of the prevalence of confusion in this area, it seems that no
user code will have to be changed.  However, knowing what :element-type
specifiers are implemented efficiently will likely still be of concern to
most vendor's clients.

Esthetics:

Discussion:

The test case is, unfortunately, not relevant to this proposal, since it
presumes that some non-trivial upgrading is going on.  In particular,
there will be no "two, distinct type specifiers ,aet-x and ,aet-x that are
definitely not type-equivalent, but for which
(array-element-type (make-array 0 :element-type ',aet-x))  ==> ,aet-y"

Many people are in favor of this proposal, at least initially.  See the
arpanet interchanges mentioned above.

One (or more) senior implementor(s) at Lucid favor(s) this proposal.

It may be desirable to introduce a new function CANONICAL-TYPE of one
argument, which takes a type-specifier into a canonical type-specifier
for that type-equivalence class.

∂17-May-88  0213	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 17 May 88  02:11:55 PDT
Received: by labrea.stanford.edu; Tue, 17 May 88 02:12:11 PDT
Received: from bhopal.lucid.com by edsel id AA29539g; Tue, 17 May 88 02:02:32 PDT
Received: by bhopal id AA03785g; Tue, 17 May 88 02:05:55 PDT
Date: Tue, 17 May 88 02:05:55 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805170905.AA03785@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 23 Mar 88 14:49 EST <19880323194958.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 2)

There is one very dangerous loophole in this proposal, which could be
trivially plugged up.  The issue is whether symbols are a critical
arugment to any of the options, or whether "names" would be satisfactory.
What would you say to the following alterations:

(1) Change most uses of the meta-variable {symbol} to {name}, with
an explicit statement that such a {name} must be either a string,
or a symbol.  Thus the description of :IMPORT-FROM would go from
(:IMPORT-FROM {(package-name {symbol}*)}*)
to
(:IMPORT-FROM {(package-name {name}*)}*)
or maybe even
(:IMPORT-FROM {(package-name {symbol-name}*)}*)
Change also the phrase "Note that only the name of each argument symbol
is used." to something like "Note that only the name of each argument
is used; if a symbol is passed, its symbol-name is used".

(2) Flush the two options that require symbols, as opposed to names --
namely :IMPORT and :SHADOWING-IMPORT.  Note that these are the only
two that don't have the phrase "Note that only the name of each
argument symbol is used." in their description.  These two options
are superfluous since their functionality is completely covered by

The :IMPORT option as currently specified makes it all too easy to violate
reasonable package modularity rules -- e.g. (:IMPORT foo::bar) -- without
considering the warning given on CLtL p175 (top of page) "... since
accessing an internal symbol of some other package is usually a mistake".
Much worse, I've seen even very experienced hackers (more than 10 years
experience) fall into the trap of thinking that FOO::BAR means "access
the internal symbol BAR in the FOO package", or "access the symbol BAR
present in the FOO package, regardless of whether it is external or not".
The disaster that occurs once in a long while is that merely reading in
FOO::BAR creates some imposter symbol in the BAR package that shouldn't
be there at all; but the poor loser who does this doesn't find that out
until a much later time, when a USE-PACKAGE or EXPORT is done.  And of
course by the time he finds it out, there is little hope of ferreting
out all the structures already read-in that point to the bogon symbol.

It may be too much to ask that the :IMPORT-FROM option signal an error
if no symbol of the requested name is available in the specified package.
This would (desirably, I think) differ from the reader's action when
parsing a double-colon notation.  But at the very least, why add the
:IMPORT and :SHADOWING-IMPORT options that *require* symbols as opposed to
names?  Why, when there are perfectly good alternatives that don't have
the modularity-violating implications described above?

If these two alterations are made, then a DEFPACKAGE can be written with
all data specified as strings; and in the cases when symbols are actually
are supplied, then the compiler can convert them to strings as they are
put out into the fasl file. (Essentially the same compiler conversion
takes place now in Symbolics treatment of SHADOW, and in Lucid's 3.0

-- JonL --

∂19-May-88  0042	CL-Cleanup-mailer 	Features
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 19 May 88  00:42:42 PDT
Received: by labrea.stanford.edu; Thu, 19 May 88 00:43:03 PDT
Received: from bhopal.lucid.com by edsel id AA09223g; Thu, 19 May 88 00:11:16 PDT
Received: by bhopal id AA11771g; Thu, 19 May 88 00:14:48 PDT
Date: Thu, 19 May 88 00:14:48 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805190714.AA11771@bhopal.lucid.com>
To: Gumby@mcc.com
Cc: common-lisp@sail.stanford.edu
In-Reply-To: David Vinayak Wallace's message of Wed, 18 May 88 20:58 CDT <880518205815.3.GUMBY@BRAHMA.ACA.MCC.COM>
Subject: Features

re: What do you do if you encounter #+nasa:hyperdrive but you don't have the
nasa package defined?

If an alleged feature name "doesn't exist", that means that the feature
isn't present [and it can fail to "exist" in several different ways].

This is the behaviour Lucid implements, and I'm sure I saw some network
mail a long time ago agreeing to this meaning.  But I don't see any
SHARPSIGN-PLUS-MINUS-PACKAGE.  Kent? Larry?

-- JonL --

∂19-May-88  1125	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Received: from hub.ucsb.edu by SAIL.Stanford.EDU with TCP; 19 May 88  11:24:57 PDT
Received: from csilvax.ucsb.edu by hub.ucsb.edu (5.59) id AA15596; Thu, 19 May 88 11:26:00 PDT
Received: from  by csilvax.ucsb.CSNET (5.51) id AA27191; Thu, 19 May 88 11:20:30 PDT
Date: Thu, 19 May 88 11:20:30 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Thu, 19 May 88 11:20:30 PDT
To: cl-cleanup@sail.stanford.edu
Subject: ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION

Issue:          DEFSTRUCT-DEFAULT-VALUE-EVALUATION
References:     CLtL p.308-10 & 86-003 p.4
Category:       CLARIFICATION
Edit history:   Revision 1 by Skona Brittain 05/13/88

Problem Description:

There is some confusion over whether default initialization
forms for defstruct slots get evaluated, when they are not needed
because a keyword argument was supplied to the constructor function.
As a consequence of this confusion, there is confusion over whether
there can be a type-mismatch error between the specified type of the slot
and the type of the default value.

On page 308, it says "The default-init is a form that is evaluated
each time a structure is to be constructed; the value is used as the
initial value of the slot.  If no default-init is specified, then the
initial contents of the slot are undefined and implementation-dependent."

On the next page, however, it says that the default-init is evaluated if
the keyword argument is not supplied and the converse, although not stated,
is intended and informally implied.

Proposal (DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED):

Clarify that the converse is true. i.e that the default-init is not evaluated
if the keyword argument is supplied.

In the quote from page 308, delete the second sentence and replace
"a structure is to be constructed; the value is" by "its value is to be".

To section 19.3, add a clarification,
such as the following from Guy's issues file:
"The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance.  If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."

Test Case:

In the following sequence, only the last call is an error.

(defstruct person (name 007 :type string))
(make-person :name "James")
(make-person)

Rationale:

It is inefficient, and inconsistent with the rest of the language, for the
default initialization form to be evaluated when it is not needed.
Consequently, when it's not needed, such type-mismatch errors should not be
detectable in general.

Any existing confusion should be clarified by this proposal.

Current Practice:

KCL does not evaluate the default initialization form unless it is needed;
even when it is needed, the type checking is not done at all.

Cost to Implementors:

If there are any implementations that currently behave differently from
the proposed way, then they need some slight modification.

Cost to Users:

None.

Benefits:

Clarity and portability.  In particular, clarifying that the unaesthetic
situation mentioned in the next section is allowed should be reassuring.

Aesthetics:

It appears slightly unaesthetic to have a default value that violates a
type specification.

Discussion:

Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.

∂19-May-88  1126	CL-Cleanup-mailer 	When is the Cambridge cleanup meeting?????
Received: from hub.ucsb.edu (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 19 May 88  11:26:23 PDT
Received: from csilvax.ucsb.edu by hub.ucsb.edu (5.59) id AA15623; Thu, 19 May 88 11:27:57 PDT
Received: from  by csilvax.ucsb.CSNET (5.51) id AA27212; Thu, 19 May 88 11:22:27 PDT
Date: Thu, 19 May 88 11:22:27 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Thu, 19 May 88 11:22:27 PDT
To: cl-cleanup@sail.stanford.edu
Subject: When is the Cambridge cleanup meeting?????
Cc: skona@csilvax.ucsb

Is there a cleanup subcommittee meeting scheduled for the day or two
before the Boston meeting in June, and, if so, when and where is it?

∂19-May-88  1136	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
Received: from hub.ucsb.edu (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 19 May 88  11:34:33 PDT
Received: from csilvax.ucsb.edu by hub.ucsb.edu (5.59) id AA15701; Thu, 19 May 88 11:35:49 PDT
Received: from  by csilvax.ucsb.CSNET (5.51) id AA27124; Thu, 19 May 88 11:18:53 PDT
Date: Thu, 19 May 88 11:18:53 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Thu, 19 May 88 11:18:53 PDT
To: cl-cleanup@sail.stanford.edu
Subject: ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS

I have divided the issue DEFSTRUCT-SLOTS-CONSTRAINTS into 2 issues,
DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER and DEFSTRUCT-SLOTS-CONSTRAINTS-NAME,
even though they are both trivial, because otherwise practically every
section of the proposal had 2 parts, and also it seemed reasonable to
separate a change from a clarification, for approval purposes (actually the
main reason is that I couldn't think of a name for the joint proposal).

Issue:          DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
References:     CLtL p.307 & 86-003 p.4
Category:       CHANGE
Edit history:   Revision 1 by Skona Brittain 05/13/88

Problem Description:

Structures defined by defstruct currently are required to have at least
one slot.  This seems to have been a mistake in the design of the language.

Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER:ALLOW-ZERO):

Allow a call to defstruct to have zero slot-descriptions.
i.e. change the + to a * in the syntax of calls to defstruct
given at the bottom of page 307 of CLtL.

Test Case:

(defstruct s), which is not allowed according to CLtL, would be allowed.

Rationale:

The current restriction is in marked contrast to the generality allowed
elsewhere in the language.  And removing it slightly increases the
usefulness of defstruct - by allowing the zero slot case when it may be
deemed useful and by not requiring a check for it when it doesn't matter.

Current Practice:

KCL allows zero slots.

Cost to Implementors:

None for implementations that currently allow zero slots.
Very slight for others.

Cost to Users:

None.

Benefits:

Slightly increases the usefulness of defstruct and is aesthetic.

Aesthetics:

In general, it is more aesthetic to allow for generality rather than to
specifically prohibit a particular case.  And the generality in this case
is consistent with that of many other features of the language, such as
that arrays can be empty, functions like + and list can take zero arguments,
etc.

Discussion:

Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.

Issue:          DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References:     CLtL p.308 & 86-003 p.4
Category:       CLARIFICATION
Edit history:   Revision 1 by Skona Brittain 05/13/88

Problem Description:

The case of two slots of a structure having the same name is not
discussed in CLtL.

Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):

It is an error for two slots in a structure type to have the same name.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.

Test Cases:

(defstruct struc slot slot) would be an error.  So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).

Rationale:

Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error.  Checking for it
would be costly so signaling this error is not required.

Current Practice:

In KCL, if 2 slots have the same name, no warning message is
given but mysterious behavior ensues.  (Their default values are
both whatever is given for the second one, neither can be given a
different value via a call to the constructor function, only the
second one's value can be changed by setf...)

Cost to Implementors:

None.

Cost to Users:

None.

Possible confusion.

Benefits:

Clarity.

Aethetics:

Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.

Discussion:

Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.

∂19-May-88  1152	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
Received: from hub.ucsb.edu (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 19 May 88  11:52:42 PDT
Received: from csilvax.ucsb.edu by hub.ucsb.edu (5.59) id AA15559; Thu, 19 May 88 11:24:25 PDT
Received: from  by csilvax.ucsb.CSNET (5.51) id AA27124; Thu, 19 May 88 11:18:53 PDT
Date: Thu, 19 May 88 11:18:53 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Thu, 19 May 88 11:18:53 PDT
To: cl-cleanup@sail.stanford.edu
Subject: ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS

I have divided the issue DEFSTRUCT-SLOTS-CONSTRAINTS into 2 issues,
DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER and DEFSTRUCT-SLOTS-CONSTRAINTS-NAME,
even though they are both trivial, because otherwise practically every
section of the proposal had 2 parts, and also it seemed reasonable to
separate a change from a clarification, for approval purposes (actually the
main reason is that I couldn't think of a name for the joint proposal).

Issue:          DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
References:     CLtL p.307 & 86-003 p.4
Category:       CHANGE
Edit history:   Revision 1 by Skona Brittain 05/13/88

Problem Description:

Structures defined by defstruct currently are required to have at least
one slot.  This seems to have been a mistake in the design of the language.

Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER:ALLOW-ZERO):

Allow a call to defstruct to have zero slot-descriptions.
i.e. change the + to a * in the syntax of calls to defstruct
given at the bottom of page 307 of CLtL.

Test Case:

(defstruct s), which is not allowed according to CLtL, would be allowed.

Rationale:

The current restriction is in marked contrast to the generality allowed
elsewhere in the language.  And removing it slightly increases the
usefulness of defstruct - by allowing the zero slot case when it may be
deemed useful and by not requiring a check for it when it doesn't matter.

Current Practice:

KCL allows zero slots.

Cost to Implementors:

None for implementations that currently allow zero slots.
Very slight for others.

Cost to Users:

None.

Benefits:

Slightly increases the usefulness of defstruct and is aesthetic.

Aesthetics:

In general, it is more aesthetic to allow for generality rather than to
specifically prohibit a particular case.  And the generality in this case
is consistent with that of many other features of the language, such as
that arrays can be empty, functions like + and list can take zero arguments,
etc.

Discussion:

Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.

Issue:          DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References:     CLtL p.308 & 86-003 p.4
Category:       CLARIFICATION
Edit history:   Revision 1 by Skona Brittain 05/13/88

Problem Description:

The case of two slots of a structure having the same name is not
discussed in CLtL.

Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):

It is an error for two slots in a structure type to have the same name.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.

Test Cases:

(defstruct struc slot slot) would be an error.  So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).

Rationale:

Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error.  Checking for it
would be costly so signaling this error is not required.

Current Practice:

In KCL, if 2 slots have the same name, no warning message is
given but mysterious behavior ensues.  (Their default values are
both whatever is given for the second one, neither can be given a
different value via a call to the constructor function, only the
second one's value can be changed by setf...)

Cost to Implementors:

None.

Cost to Users:

None.

Possible confusion.

Benefits:

Clarity.

Aethetics:

Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.

Discussion:

Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.

∂19-May-88  1301	CL-Cleanup-mailer 	Re: When is the Cambridge cleanup meeting?????
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 May 88  13:01:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAY 88 13:00:08 PDT
Date: 19 May 88 13:00 PDT
From: masinter.pa@Xerox.COM
Subject: Re: When is the Cambridge cleanup meeting?????
In-reply-to: Skona Brittain <skona%csilvax@hub.ucsb.edu>'s message of Thu, 19
May 88 11:22:27 PDT
To: skona%csilvax@hub.ucsb.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880519-130008-6484@Xerox>

I fell into a hole. I haven't scheduled a meeting. When would you like one?

∂19-May-88  1354	CL-Cleanup-mailer 	PASSED X3J13 March 1988
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 May 88  13:53:57 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAY 88 13:47:40 PDT
Date: 19 May 88 13:47 PDT
From: masinter.pa@Xerox.COM
Subject: PASSED X3J13 March 1988
To: CL-CLEANUP@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
Message-ID: <880519-134740-6575@Xerox>

I have a breather, and can get back to cl-cleanup work. It is late, but lets do
what we can in the remaining time. First are a couple of status lists.

These issues passed at X3J13, March 1988. They will not be distributed again.

(Interaction of ADJUST-ARRAY and displaced arrays)

- APPEND-DOTTED (Version 5, 14-Jan-88)
(What happens to CDR of last CONS? in other
than last arg?)

- AREF-1D (Version 7, 14-Nov-87)
(Add a new function for accessing arrays with row-major-index)
Version 5 conditionally passed X3J13/Jun87
Version 7 passed X3j13/Nov87

- ASSOC-RASSOC-IF-KEY (Version 4, 23-Nov-87)
(Extend ASSOC-IF, etc.  to allow :KEY)

- COLON-NUMBER (Version 1, 22-oct-87)
(Is :1 a number, a symbol, or undefined?)
Version 1 passed X3J13/Nov87

- DECLARE-MACROS (Version 3,  5-FEB-88)
(Disallow macros expanding into declarations.)

- DEFVAR-DOCUMENTATION (Version 2, 23-Nov-87)
(Documentation string is not evaluated.)

- DISASSEMBLE-SIDE-EFFECT (version 3, 21 Jan 88)
(DISASSEMBLE doesn't smash the def if not compiled)

- DO-SYMBOLS-DUPLICATES (Version 3, 23-Nov-87)
( DO-SYMBOLS can the same symbol twice?)
<<<The rationale contains a typo: DO-PACKAGE for DO-SYMBOLS>>>

-  DRIBBLE-TECHNIQUE (Version 2, 14-Feb-88)
(dribble can't be used programmatically)
<<<VAXLisp Current Practice wrong.>>>

- FLET-DECLARATION (Version 2, 2 Feb 88)
(Allow declarations in FLET, MACROLET)

- FORMAT-COLON-UPARROW-SCOPE (Version 3, 5 Feb 88)
(what iteration does ~:↑ exit from?)

- FORMAT-COMMA-INTERVAL (Version 2, 15 June 87)
(paramerize number of digits between commas)
Version 2 passed X3J13/Nov87
<<<example is bogus; that example was one of the better uses
for the facility, too>>>

- FUNCTION-TYPE-KEY-NAME (Version 3, 5 Feb 88)
(allow &KEY (:KEYNAME type)) in FUNCTION decls )

- GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
(Environment argument for GET-SETF-METHOD)
Version 4 conditionally passed X3J13/Jun87.
Version 5 passed X3J13/Nov87.

- KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8, 8-Nov-87)
(&KEY arguments not in keyword package?)
Version 6 conditionally passed X3J13/Jun87.
Version 8 passed X3J13/Nov87

- PATHNAME-STREAM (Version 6, 14-Nov-87)
(PATHNAME only works on file streams)
Version 2 conditionally passed X3J13/Jun 87
Version 6 passed X3J13/Nov 87

- PATHNAME-SYMBOL (Version 5, 5-Feb-88)
(Do symbols automaticly coerce to pathnames?)

- PUSH-EVALUATION-ORDER (Version 5,25-Nov-87)
(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)

- REDUCE-ARGUMENT-EXTRACTION (version 3, 13-Feb-88)

- SHARPSIGN-PLUS-MINUS-PACKAGE (version 3, 14-Nov-87)
(*FEATURES* are in the keyword package)

- - - - - - - - - - - - - - - - - - - - - - - - - - -

These issues were rejected at X3J13 March 1988. They will not be distributed
again.

- COMPILER-WARNING-BREAK (Version 4,23-Nov-87 )
(Does *BREAK-ON-WARNING* affect the compiler?)

- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 5,  5-Feb-88)
(let FIND, SUBSTITUTE etc work on multi-dimensional arrays)

∂19-May-88  1500	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE (version 10)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 May 88  15:00:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 MAY 88 14:46:30 PDT
Date: 19 May 88 14:23 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 10)
To: CL-CLEANUP@Sail.stanford.edu
CC: Masinter.pa@Xerox.COM
LINE-FOLD: NO
Message-ID: <880519-144631-1033@Xerox>

Here is my attempt to rewrite FUNCTION-TYPE as per the discussion at the March X3J13 meeting. I added a comment at the end.

!
Issue:        FUNCTION-TYPE
References:   functions (p32), types (p33), FUNCTIONP (p76),
SYMBOL-FUNCTION (p90), APPLY (p107), COERCE (pp51-52)
Category:     CHANGE
Edit History: 26-Feb-87, Version 1 by Gabriel
15-Mar-87, Version 2 by Cleanup Committee
10-May-87, Version 3 by Fahlman
29-May-87, Version 4 by Masinter (incorporate comments)
15-Jun-87, Version 5 by Fahlman (include two options)
23-Oct-87, Version 6 by Masinter (only STRICT-REDEFINITION)
09-Nov-87, Version 7 by Masinter (minor cleanup)
14-Nov-87, Version 8 by Pitman (major restructuring)
13-Feb-88, Version 9 by Masinter, (add back 2nd option)
19-May-88, Version 10 by Masinter, (modify as per X3J13)

Problem Description:

The definition of the term function'' in CLtL includes all symbols and
many lists in addition to true' functions.

Also, page 47 of CLtL states that the FUNCTION type specifier can only
be used for declaration and not for discrimination. Some of the original
Common Lisp designers maintain that this restriction on the use of the
FUNCTION specifier was meant to apply only to long-form FUNCTION
specifiers, but since this intent was not explicitly stated, the status
of FUNCTION as a type is blurred.

A consequence of the p47 confusion is that (FUNCTIONP x) cannot portably
be relied upon to be equivalent to (TYPEP x 'FUNCTION).

Proposal FUNCTION-TYPE:X3J13-MARCH-88

This proposal is basically the STRICT-REDEFINITION proposal of version 9
of this issue, with a few typos corrected and changes to section 2E as
agreed upon at X3J13, March 1988.

1.  Redefine the type FUNCTION so that it can be used for discrimination
as well as declaration.

1a. The types CONS, SYMBOL, ARRAY, NUMBER, CHARACTER, and FUNCTION
are pairwise disjoint.  In particular, a list may not be used
to implement any FUNCTION subtype.

1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.

2. Define that a function'' as used throughout the CLtL is restricted
to be exactly those objects of type FUNCTION.

2a. This type no longer includes objects of type SYMBOL or lists
with CAR = LAMBDA.

2b. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)).  This is an incompatible
change.

2c. Clarify that the list form of the FUNCTION type specifier may
still only be used for declaration.

2d. Clarify that the symbol form of the FUNCTION type specifier may
be used for type discrimination.

2e. Clarify that, under this definition of the FUNCTION type,
the functions FUNCALL and APPLY, and, by extension, any
function that takes a "functional" argument, will accept
any object that can be coerced to a FUNCTION, including
objects of type FUNCTION, symbols, and lists that begin
with lambda. (This is a clarification because it is a
restatement of the current meaning of CLtL using the new
terminology.)

3. Clarify that the result of a FUNCTION special form must be a function.

3a. This implies that some (FUNCTION name) may be implicitly interpreted
as (THE FUNCTION (FUNCTION name)).

4. Clarify that it is an error to use the special form FUNCTION on a
symbol that does not denote a function in the lexical environment in
which the special form appears. Specifically, it is an error to use the
FUNCTION special form on a symbol that denotes a macro or special form.

4a. Some implementations may choose not to signal this error for
performance reasons, but implementations are forbidden from
defining the failure to signal an error as a useful' behavior.

5. Clarify that it is permissible for FBOUNDP to return true for a macro
or special form, and that it is permissible to call SYMBOL-FUNCTION
on any symbol for which FBOUNDP returns true.

5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.

5b. Assuming that symbol is fbound,
(FUNCTIONP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).

5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error.

5d.  The motivation for this distinction between FUNCTION and
SYMBOL-FUNCTION is that FUNCTION is intended for day-to-day
use within programs while SYMBOL-FUNCTION is a data structure
accessor used primarily for meta-level applications and not
recommended for general use. It is provided primarily to
complete the set of accessors on symbols.

6. COERCE is extended to allow objects to be coerced to type FUNCTION.

6a. (COERCE symbol 'FUNCTION) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.

6b. (COERCE lambda-expression 'FUNCTION) is equivalent to
(EVAL (FUNCTION ,lambda-expression)).

7. Clarify that the value of *MACROEXPAND-HOOK* is first coerced to a
function before being called as the
expansion interface hook by MACROEXPAND-1.

Rationale:

The fuzzy definition of function'' has descended from older dialects of
Lisp, such as Maclisp. Many places in existing code make assumptions about
the current meaning, making any change painful.

It is very important both for documentation clarity and for program type
discrimination (such as CLOS) to have a clear term which denotes a
true function.''

This proposal is a compromise between a CONSERVATIVE proposal (which left
FUNCTION alone and introduced a new type), and STRICT-REDEFINITION proposal,
which incompatibility changed not only the FUNCTION type and SYMBOL-FUNCTION,
but also the behavior of FUNCALL, APPLY and functions with functional arguments.

Current Practice:

In some implementations, (TYPEP x 'FUNCTION) signals an error.
In some implementations, (TYPEP x 'FUNCTION) is true for values
returned by FUNCTION, symbols that are FBOUNDP, and lambda expressions.
In some implementations, (TYPEP x 'FUNCTION) is true only for values
returned by FUNCTION.

Implementations vary on what my go into the function cell, depending on
how much error checking they want to have to do at function call time, and
depending on whether they store other kinds of information (such as special
form information) in the function cell.

Few current Common Lisp implementations have exactly the
semantics described in this proposal.

Cost to Implementors:

Bringing type predicates (FUNCTIONP, etc.) and higher order functions
(APPLY, etc.) into compliance should require little effort in most
implementations.

Compiled functions are true functions in almost all current
implementations, but in many implementations, interpreted functions and
closures stored in the function cell of a symbol are represented as lists.
Under this proposal, this representation would have to be different
(implemented either as structures or to some special internal data type).
The behavior of COMPILE, STEP, TRACE, and possibly ED would have to be
modified to deal with functions that are not lists (but from which the
list form can be reconstructed if necessary).

Cost to Users:

The changes to FUNCTIONP and the FUNCTION type declaration are relatively easy
to deal with.

Because CLtL's language was somewhat fuzzy about what might go into the
function cell of a symbol, some code that explicitly deposited symbols
or lists in a symbol's function cell, or expected lists back, will
have to change. Such code was already not portable, however, since some
implementations signal an error  when this is done.

Benefits:

The term function'' would be given a useful and precise meaning.
The FUNCTION datatype would be useful for type discrimination in CLOS.

The type hierarchy would be simplified.

This proposal brings Common Lisp slightly closer to Scheme and
the work of the EuLisp committee. Scheme, for example, also has the concept
of a procedure'' which is compatible with the FUNCTION type.

Aesthetics:

This proposal improves the aesthetics of the language.

Discussion:

This issue has been discussed at great length; this section attempts
only to summarize the important points.

There is general agreement that the definition of the FUNCTION data type
must be clarified or revised. The cleanup of the type hierarchy is important
to the CLOS group.

The description of COMPILE must be changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression".  We believe this is a subject for a separate
proposal, as the behavior of COMPILE needs additional clarification.

Many different alternatives have been discussed both in the cleanup committee
and X3J13. Two proposals were circulated at the March 1988 meeting of X3J13;
this version is the result of discussions at that meeting. It is a compromise
between the conflicting goals of backward compatibility, flexibility in the
language, and simple semantics.

This proposal does not address the issue of when coercion to functions occur.
For example, it is allowed to write

(MAPCAR 'FROB my-list)

It is not specified when the coercion of FROB to its SYMBOL-FUNCTION
occurs. For example,

(DEFUN FROB (X)
(WHEN (> X 0) (SETF (SYMBOL-FUNCTION 'FROB) #'(LAMBDA (X) NIL)))
T)

(MAPCAR 'FROB '(-1 -1 1 1))

may return different results if MAPCAR coerces its functional argument
once rather than for each element. This may require a separate
cleanup issue.

∂20-May-88  1914	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 20 May 88  19:14:40 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191384; Fri 20-May-88 22:12:41 EDT
Date: Fri, 20 May 88 22:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 2)
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <19880521021246.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

Date: Tue, 17 May 88 02:05:55 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>

There is one very dangerous loophole in this proposal, which could be
trivially plugged up.  The issue is whether symbols are a critical
arugment to any of the options, or whether "names" would be satisfactory.
What would you say to the following alterations:

(1) Change most uses of the meta-variable {symbol} to {name}, with
an explicit statement that such a {name} must be either a string,
or a symbol.  Thus the description of :IMPORT-FROM would go from
(:IMPORT-FROM {(package-name {symbol}*)}*)
to
(:IMPORT-FROM {(package-name {name}*)}*)
or maybe even
(:IMPORT-FROM {(package-name {symbol-name}*)}*)
Change also the phrase "Note that only the name of each argument symbol
is used." to something like "Note that only the name of each argument
is used; if a symbol is passed, its symbol-name is used".

Saying symbol-name instead of symbol is a reasonable change to the
presentation.

(2) Flush the two options that require symbols, as opposed to names --
namely :IMPORT and :SHADOWING-IMPORT.  Note that these are the only
two that don't have the phrase "Note that only the name of each
argument symbol is used." in their description.  These two options
are superfluous since their functionality is completely covered by

The :IMPORT option as currently specified makes it all too easy to violate
reasonable package modularity rules -- e.g. (:IMPORT foo::bar) -- without
considering the warning given on CLtL p175 (top of page) "... since
accessing an internal symbol of some other package is usually a mistake".
....
The disaster that occurs once in a long while is that merely reading in
FOO::BAR creates some imposter symbol in the BAR package that shouldn't
be there at all; but the poor loser who does this doesn't find that out
until a much later time, when a USE-PACKAGE or EXPORT is done.  And of
course by the time he finds it out, there is little hope of ferreting
out all the structures already read-in that point to the bogon symbol.

It may be too much to ask that the :IMPORT-FROM option signal an error
if no symbol of the requested name is available in the specified package.
This would (desirably, I think) differ from the reader's action when
parsing a double-colon notation.  But at the very least, why add the
:IMPORT and :SHADOWING-IMPORT options that *require* symbols as opposed to
names?  Why, when there are perfectly good alternatives that don't have
the modularity-violating implications described above?

Well, wait a minute.  Either :IMPORT-FROM does exactly the same thing as
:IMPORT in terms of creating symbols that did not already exist, in
which case removing :IMPORT doesn't solve anything, or else :IMPORT-FROM
refuses to create symbols, which as you say ("it may be too much to
ask") is likely to cause problems because things will only work if done
in a certain order so that the symbols get created before they are
needed.  In Symbolics Common Lisp, :IMPORT-FROM will create symbols if
they don't already exist, it's exactly like a double-colon package
prefix.

People who use double-colon-prefix are either confused and asking for
trouble, or know exactly what they're doing.  Either way, your suggested
change to DEFPACKAGE isn't going to help them, as far as I can see.

Thus if people feel that having both :IMPORT and :IMPORT-FROM is redundant,
I'd prefer removing :IMPORT-FROM.  However, I think current practice shows
it's better to have both.  Do you think :IMPORT-FROM should be changed
to be like single-colon package prefix?

∂20-May-88  1921	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE (version 10)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 20 May 88  19:21:28 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 191385; Fri 20-May-88 22:21:02 EDT
Date: Fri, 20 May 88 22:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (version 10)
To: masinter.pa@Xerox.COM
cc: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <19880521022111.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

Approved, except for one thing.  The word "procedure" appears
three times without being defined.  One occurrence is legitimate,
but I believe these two are typos for "function".

5c. The effect of
(SETF (SYMBOL-FUNCTION symbol) non-procedure)
is not defined. Implementations are permitted to signal an error.

6a. (COERCE symbol 'FUNCTION) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.

∂20-May-88  2102	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 May 88  21:02:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 408141; 20 May 88 23:59:59 EDT
Date: Fri, 20 May 88 23:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <19880521035951.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

beginning of a reasonable proposal.  There are a few problems with it:

You don't list what type specifiers it applies to.  I assume you mean
COMPLEX?

Your proposal assumes without stating it explicitly that

(array-element-type (make-array dimensions :element-type element-type
options...))

is independent of the values of dimensions and options.  I believe this
to be true of most implementations, but see nothing in CLtL that requires
it.  I can easily imagine an implementation that offers more specialized
arrays of rank 1 than of other ranks, more specialized adjustable than
non-adjustable arrays, or size-dependent specializations (why bother with
packed formats for very small arrays?).  This could seriously impact the
adoption cost.  I think I have mentioned this before; do I have to drag
out all the other comments I made last time this issue came up?

You should specify more clearly that you are incompatibly changing the
meaning of (typep array '(array <element-type>)) from "(aref array i)
is guaranteed to result in an object of type <element-type>" to "(setf
(aref array i) x) is type-valid if and only if x is of type
<element-type>."

I don't understand the justification for introducing the function
UPGRADE-ARRAY-ELEMENT-TYPE.  There are plenty of other type operators
missing from Common Lisp, why put in just this one?

In the discussion section, "In short, no one would not want to
gain portability at the expense of limiting the language to the architectural
features of the hardware on which it was first implemented." does
not say what I think you meant it to say, unless you've suddenly

The proposal is much too long and contains too many digressions.  It
should be extensively pared down before it is presented to X3J13.  You
can judge from my 1-week delay in response how difficult I found it to
read all the way through this proposal.  I haven't noticed any other
responses, so others may have found it very difficult also.

∂21-May-88  0207	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE (version 10)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88  02:07:48 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 02:08:07 PDT
Received: from bhopal.lucid.com by edsel id AA19226g; Sat, 21 May 88 01:58:30 PDT
Received: by bhopal id AA07793g; Sat, 21 May 88 02:02:10 PDT
Date: Sat, 21 May 88 02:02:10 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805210902.AA07793@bhopal.lucid.com>
To: CL-CLEANUP@sail.stanford.edu
Subject: Issue: FUNCTION-TYPE (version 10)

re: 5a. The value returned by SYMBOL-FUNCTION when FBOUNDP returns true
but the symbol denotes a macro or special form is not well-defined,
but SYMBOL-FUNCTION will not signal an error.
5b. Assuming that symbol is fbound[sic],
(FUNCTIONP (SYMBOL-FUNCTION symbol))
implies
(AND (NOT (MACRO-FUNCTION symbol))
(NOT (SPECIAL-FORM-P symbol))).

I don't understand the motivation behind this point (5b).  Since (5a) says
that SYMBOL-FUNCTION is permitted to return "something", and is not
"well-defined" in the case when the symbol names a macro or special form,
then what is the advantage of preventing it from returning a function?

I've seen lots of CL code like:

(defun foo-expander (x) (QUOTE ,x))
(setf (macro-function 'FOO) #'foo-expander)

How will one fetch the current "expander function" for this macro?

Is the issue merely that some implementations will have to cons in order to
return a value for MACRO-FUNCTION?  In that case, maybe we need a predicate
MACRO-P, just as there is a predicate SPECIAL-FORM-P.

-- JonL --

∂21-May-88  0247	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88  02:47:32 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 02:47:00 PDT
Received: from bhopal.lucid.com by edsel id AA19314g; Sat, 21 May 88 02:35:44 PDT
Received: by bhopal id AA07861g; Sat, 21 May 88 02:39:21 PDT
Date: Sat, 21 May 88 02:39:21 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805210939.AA07861@bhopal.lucid.com>
To: skona%csilvax@hub.ucsb.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Skona Brittain's message of Thu, 19 May 88 11:20:30 PDT <8805191831.AA11226@edsel.lucid.com>
Subject: ISSUE: DEFSTRUCT-DEFAULT-VALUE-EVALUATION

You can add to the "Current Practice:" section:

LUCID does not evaluate the default initialization form unless it is
needed; even when it is needed, the type checking is not done at all.
However, at structure definition time, if an initial value form is
constanp and doesn't satisfy the :type specification, a warning message
is printed.

Oddly enough, Lucid's interpreter ensures that SETF's of slots obey the
:type specifier, even though init-forms aren't checked.  Furthermore, in
safety levels 2 or higher, the compiled code will do minimal "memory-
integrity" type checking for SETF's (which is what I suspect the various
special-purpose microcoded machines do); however except for low-level numeric
types, this is rarely equivalent to what a full type check would do.

I have long suggested that there should be at least one mode of operation
such that all :type information is checked when setting values into structure
slots (setf as well as initialization).  Some have suggested that this mode
could be "when running interpretively, or when when compiled with the highest
degree of SAFETY and lower degrees of SPEED."  However, since the wording of
CLtL p310 suggests that the :type slot options is merely a DECLARE, and since
some vendors effectively ignore any and all declarations [except for SPECIAL],
then this suggestion hasn't reached proposal stage yet.

-- JonL --

∂21-May-88  0248	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88  02:48:07 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 02:48:23 PDT
Received: from bhopal.lucid.com by edsel id AA19322g; Sat, 21 May 88 02:36:28 PDT
Received: by bhopal id AA07864g; Sat, 21 May 88 02:40:05 PDT
Date: Sat, 21 May 88 02:40:05 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805210940.AA07864@bhopal.lucid.com>
To: skona%csilvax@hub.ucsb.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Skona Brittain's message of Thu, 19 May 88 11:18:53 PDT <8805191852.AA11302@edsel.lucid.com>
Subject: ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS

You can add to the "Current Practice:" section:

LUCID allows zero slots.

-- JonL --

∂21-May-88  0520	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88  05:20:44 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 05:21:08 PDT
Received: from bhopal.lucid.com by edsel id AA19658g; Sat, 21 May 88 05:10:11 PDT
Received: by bhopal id AA08230g; Sat, 21 May 88 05:13:49 PDT
Date: Sat, 21 May 88 05:13:49 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805211213.AA08230@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 20 May 88 22:12 EDT <19880521021246.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 2)

re: Well, wait a minute.  Either :IMPORT-FROM does exactly the same thing as
:IMPORT in terms of creating symbols that did not already exist, in
which case removing :IMPORT doesn't solve anything, . . .

That isn't quite right.  :IMPORT explicitly requires you to put symbols
in the source code, and it is the reading in of that code (with its
liklihood of having bogon-producing :: syntax) that causes the lossage.

(defpackage my-package (:import 'uluz::bunkie))

then the damage to the ULUZ package is done by the reader long before
defpackage or :import ever has a chance to muck things up.

I suggest removing :IMPORT because the :IMPORT-FROM format can be made
to work given only the symbol-name (not the symbol itself, with it's home
package known);  there would be no other way to indicate the package
information for :IMPORT if you used only symbol-names as arguments.

Oddly enough, looking back over the mail on this issue, it seems as though
KMP wanted to suggest exactly the same thing, in a messaged dated
Sat, 12 Mar 88 19:14 EST.  Your disagreement with him was phrased as
follows:

I disagree because of alphabetic case issues in strings.  Note that in
these symbol/string arguments, the symbol is being used only for its
name, so there are never any package issues.  . . .

but this argument fails to account for the fact that the damage is done
by the reader, when it is required to read in symbols, rather than by
any action of defpackage itself.

re:   Do you think :IMPORT-FROM should be changed
to be like single-colon package prefix?

Well, only in that it not create an entry *** in some other package *** where
one doesn't already exist; I wouldn't necessarily want it to require the
symbol to be external.  Yes, I think it would be a tremendous step forward
in helping to prevent one of the most obscure nits that even an experienced
package user can fall into.

-- JonL --

∂21-May-88  0613	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 May 88  06:13:23 PDT
Received: by labrea.stanford.edu; Sat, 21 May 88 06:13:50 PDT
Received: from bhopal.lucid.com by edsel id AA19922g; Sat, 21 May 88 06:02:08 PDT
Received: by bhopal id AA08320g; Sat, 21 May 88 06:05:42 PDT
Date: Sat, 21 May 88 06:05:42 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8805211305.AA08320@bhopal.lucid.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 20 May 88 23:59 EDT <19880521035951.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS

You raise a number of good points here.  I'm going to reply to several
of them out-of-order, to do the "easier" ones first.

re: In the discussion section, "In short, no one would not want to
gain portability at the expense of limiting the language . . .
Take out a "not."

Yes, several persons here at Lucid noted the typo too.  Take out a "not".

re: I don't understand the justification for introducing the function
UPGRADE-ARRAY-ELEMENT-TYPE.  There are plenty of other type operators
missing from Common Lisp, why put in just this one?

this gives him a reasonable query mechanism for a very common problem.  It
also, quite likely, reflects a functionality that each implementation will
have to provide for itself anyway.

re: You don't list what type specifiers it applies to.  I assume you mean
COMPLEX?

I didn't think that explicit mention of SIMPLE-ARRAY and VECTOR was
necessary, as they are subtypes of ARRAY.   However, it can't hurt to
put in the one sentence clarification.  I did not mean COMPLEX; I only
meant to cover arrays.  Perhaps COMPLEX could be "swept under the same
rug"; do you think it is a good idea to do so?

re: Your proposal assumes without stating it explicitly that
(array-element-type (make-array dimensions :element-type element-type
options...))
is independent of the values of dimensions and options.  I believe this
to be true of most implementations, but see nothing in CLtL that requires
it.  . . . This could seriously impact the adoption cost.  I think I
have mentioned this before; do I have to drag out all the other comments
I made last time this issue came up?

Yes, I think this assumption about independence is right. I don't remember
your bringing out any such discussion on cl-cleanup before; the only note
I can find is just a statement of this same assumption sent out to the
common-lisp mailing list:

Date: Fri, 11 Mar 88 16:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: the array type mess....
To: Ram@C.CS.CMU.EDU
Cc: Jon L White <edsel!jonl@LABREA.STANFORD.EDU>,
common-lisp@SAIL.STANFORD.EDU, sandra%orion@CS.UTAH.EDU
. . .
An interesting comment on all this is that we are implicitly assuming
that an implementation's spectrum of specialized array types is independent
of the size, number of dimensions, indirectness, or adjustability of the
array.  This seems unlikely to be true of all implementations.  I don't
know how to fix this deficiency.

Someone should write this up in Cleanup form and thus give us all
a chance to think about it more deeply.

But the grim file reaper seems to have put on temporarily inaccessible
back-up tape my cl-cleanp archives prior to Mar 4, 1988.  So I may have
just missed all the commentary about it before.

On the other hand, if this assumption is violated, the I'd be curious
to know how an implementation can do, say, displacement of a vector to
a multi-dimensional array with conformal element type, and vice-versa.
I've heard that Symbolics users frequently do this in order to run
sequence-like functions over 2-dimensional arrays.

re: The proposal is much too long and contains too many digressions.

There are two proposals here, you know; the verbal discussion in Palo Alto
on March 13 suggested we would need two (and maybe this was a first?).  I
have had commentary on it from folks at Lucid, but I note that CL-CLEANUP
has been effectively moribund for the six weeks prior to the submission of
this proposal.  So I don't think the lack of other public replies means it
is any more difficult to comprehend than the other long proposals (such as,
"setf-function-vs-macro").

On the other hand, I agree that is is unfortunately long; I don't easily see
what can be deleted without opening up loopholes for someone to argue against.
Do you have some specific suggestions as to what could be elided without
inviting more criticism?

-- JonL --

∂23-May-88  0828	CL-Cleanup-mailer 	HASH-TABLE-PRINTED-REPRESENTATION
Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 23 May 88  08:28:27 PDT
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 23 May 88 11:28:12 EDT
To: cl-cleanup@sail.stanford.edu
Subject: HASH-TABLE-PRINTED-REPRESENTATION
Date: Mon, 23 May 88 11:27:58 EDT
Message-ID: <361.580404478@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU

Here's the draft of my hash table proposal.

Issue:		HASH-TABLE-PRINTED-PREPRESENTATION

Category:	ENHANCEMENT

Edit history:	23-May-88, Version 1 by Touretzky

Description:

Hash tables are currently second-class data structures when compared to
lists, vectors, and structures, because they have no READable printed
representation.  This proposal introduces a #H reader syntax for hash
tables and a switch to control when hash tables will be printed this way.

Proposal (HASH-TABLES-PRINTED-REPRESENTATION:#H-NOTATION) :

1) Introduce the following reader notation for hash tables:

#nH(type (k1 v1) (k2 v2) ...)

"n" is the size of the table; it is analagous to the :size argument to
MAKE-HASH-TABLE.  If omitted, the system picks some reasonable size.

"type" is one of EQ, EQL, or EQUAL.  If omitted it defaults to EQL.

The (ki vi) pairs consist of a key and a value.  There may be any number of
such pairs, including zero.  Order is not significant.  It is an error for
two keys to be identical (using the EQ, EQL, or EQUAL test, as
appropriate.)

2) Introduce a switch called *PRINT-HASH* whose initial value is
implementation-dependent.  If *PRINT-HASH* is T, hash tables are printed
using the #H syntax (with all optional components supplied), subject to the
usual limits imposed by *PRINT-LEVEL* and *PRINT-LENGTH*.  If *PRINT-HASH*
is NIL, hash tables are printed using the current #<HASH-TABLE ...> syntax.

Rationale:  this is a useful upward compatible extension (except in
implementations that have usurped #H for other purposes), with very

Adoption Cost: A simple change to PRIN1 and the pretty printer.  Most of
the code will be similar to existing routines for printing vectors in #()
notation and arrays in #nA() notation.

Benefits: this proposal makes hash tables first class objects.  If
*PRINT-HASH* is T, their contents become visible in all the normal ways,
e.g., if FOO is bound to a hash table object, then typing FOO to a
read-eval-print loop will display the contents of the hash table.  Hash
table contents may also be displayed by TRACE if the table is passed as an
argument; they may also be displayed by the debugger.  Finally, hash tables
may be appear as literal objects in programs and be read or written to files.

Current practice: we know of no current implementations of this proposal.
Although some implementations allow the user to see hash table contents
with DESCRIBE or INSPECT, not all do.  CMU Common Lisp's DESCRIBE, for
example, does not show hash table contents.  This reinforces the need for
a standard #H notation to guarantee that users can manipulate a hash table
as easily as a vector, array, or structure.

Discussion:

Several alternatives have been suggested for the syntax of #H.

- preferred notation:    #H(EQL (FOO 37) (BAR 42))

- dotted pair notation:  #H(EQL (FOO . 37) (BAR . 42))

- property list:         #H(EQL FOO 37 BAR 42)

- pseudo-structure:      #S(HASH-TABLE TYPE EQL SIZE 20 INITIAL-CONTENTS ((FOO 37) (BAR 42)))

One problem with the currently proposed #H notation is that it provides no
way to specify a rehash-size or rehash-threshold.  This should not be a
fatal flaw, though.  The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T.  The latter problem is also
shared by #nA notation.

-- Dave

∂23-May-88  1306	CL-Cleanup-mailer 	Re: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88  13:05:50 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 13:04:54 PDT
Date: 23 May 88 13:04 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: WITH-OPEN-STRING-APPEND-STYLE (Version 2)
In-reply-to: Jon L White <edsel!jonl@labrea.Stanford.EDU>'s message of Tue, 29
Mar 88 21:32:59 PST
To: edsel!jonl@labrea.Stanford.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880523-130454-5166@Xerox>

Two nits:

Aesthetics:

This is a bit silly, but I'm wondering if you are reconstructing QUUX's quote
accurately. The quote I can find (from format-colon-uparrow-scope), is
Absolutely none.  We're talking about FORMAT here.'' -- Guy L. Steele Jr. In
any case, the proposal is to change WITH-OPEN-STRING, not FORMAT. I'd be happier
if it said that this was a minor improvement to the aesthetics of the language
because it made it more consistent.

Proposal format:

The preferred format is to use "Cost to Users" and "Cost to Implementors" rather
than "Adoption Cost" and "Implementation Cost" because people were confused by
them.

Thanks,

Larry

∂23-May-88  1329	CL-Cleanup-mailer 	Re: issue FUNCTION-TYPE
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 23 May 88  13:29:22 PDT
Date: 23 May 88 16:09:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: Re: issue FUNCTION-TYPE
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen

A couple of concerns:

It seems to me that the combination of #2e:
... the functions FUNCALL and APPLY ... will accept any object that
can be coerced to a FUNCTION ...
and #6a:
(COERCE symbol 'FUNCTION) extracts the symbol-function of the
given symbol, signalling an error if SYMBOL is not fbound or if
the contents of the symbol-function cell is not a procedure.
requires implementations to signal errors for any undefined symbol.
I don't think the standard should require such error checking, for
reasons of efficiency in some implementations.  (Of course it should
be encouraged.)

Perhaps the reason for this language is that COERCE is expected to
signal an error.  That may be another issue; but for this issue I
don't think we should imply COERCE is actually used for every FUNCALL
or APPLY.

The other concern I had was that unlike the earlier FUNCTION-TYPE:
STRICT-REDEFINITION proposal, both symbols and lambda-expressions
(i.e., lists whose car is LAMBDA and whose cadr is a list) are
assumed to be acceptable to FUNCALL or APPLY.  I had thought that
at the meeting we had agreed that #2e should refer to whatever
coerceable to a FUNCTION, but that what was coerceable was still
an issue.

In particular, I'd very much like to see lists not be FUNCALLable or
APPLYable.  I think there are too many aesthetic and efficiency
reasons against continuing to allow lambda-expressions be treated as
"functions".

So far I haven't seen some of those reasons written down.

Here's an aesthetic/counter-intuitive-to-the-novice one:
Lambda-expressions don't obey the normal, apparent scoping rules because
free variables can't refer to lexical bindings.  This is because
coercing a list to a function means (EVAL (FUNCTION ,list)).

The following code does -not- count the number of nodes in a graph:
...
(let ((counter 0))
(traverse-thing '(lambda (node) (incf counter))
(thing-root)))
...
since it is not the same as
...
(let ((counter 0))
(traverse-thing #'(lambda (node) (incf counter))
(thing-root)))
...
which does pass around a closure incrementing the LET variable.
(This assumes COUNTER wasn't DEFVAR'd.)

Here's an efficiency reason:
At run-time FUNCALL or APPLY must check to see if its first argument
is a list, so that it can decide to call EVAL (or internal-equivalent).
In some implementations, this is deemed to be too expensive.

Of course some implementations may decide to handle lists for
compatibility reasons.

Anyway, these kinds of arguments really ought to be in this proposal
so everyone is aware of the issues.  I'd rather make sure this proposal
resolves the question than postpone it with yet another proposal,
especially since that was what the original proposal was about.

---Walter
------

∂23-May-88  1340	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 May 88  13:39:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAY 88 13:35:28 PDT
Date: 23 May 88 13:35 PDT
From: masinte`