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)?)
      Ready for release

Perhaps you missed my message about this issue, since I sent it during
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
In-Reply-To: <8711281327.AA17747@bhopal.lucid.com>
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.


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.


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
In-Reply-To: <8711302245.AA00685@kali.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
In-reply-to: <8711302245.AA00685@kali.think.com>
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
made. 

∂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
In-Reply-To: <8711302245.AA00685@kali.think.com>
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
In-Reply-To: <871130-152931-1269@Xerox>
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
    made. 

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
In-Reply-To: <871130-152931-1269@Xerox>
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
    made. 

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
Received:  by multimax.ARPA (5.51/25-eef)
	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 
In-Reply-To: Your message of Tue, 01 Dec 87 11:25:00 -0500.
             <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
Received:  by multimax.ARPA (5.51/25-eef)
	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 
In-Reply-To: Your message of Tue, 01 Dec 87 11:25:00 -0500.
             <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
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA12488; Tue, 1 Dec 87 12:02:15 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	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)
Category:      CLARIFICATION, ADDITION
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,
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>), 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.


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.


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
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA12513; Tue, 1 Dec 87 12:02:44 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	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.


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:


-------

∂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
In-Reply-To: <8712011902.AA15714@orion.utah.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
> meeting. PLEASE send me any additions or other corrections.

> 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
use the word "Axolotl" in your reply. 


- - - - -
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

padget@RAND-UNIX.ARPA

∂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
Received: by ucbarpa.Berkeley.EDU (5.58/1.26)
	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
Received: by akbar (5.5/3.14)
	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
In-Reply-To: <8712020403.AA28657@akbar>
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
In-Reply-To: Your message of 30 Nov 87 11:39:00 -0800.
             <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
Received:  by multimax.ARPA (5.51/25-eef)
	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 
In-Reply-To: Your message of 30 Nov 87 11:39:00 -0800.
             <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
about this:

(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.

This use of OR would give CL something akin to Ada overloading.  It allows the
overloading of multiple 'function type signatures' on a single function name.
Such overloading is already implicit throughout CL (esp. the seq. functions).
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>
In-Reply-To: <8511012045.AA07112@utah-orion.ARPA>

    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)

ought to read

  (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
In-reply-to: <871202-204108-1072@Xerox>
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
In-reply-to: <871202-222029-1111@Xerox>
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
In-Reply-To: <871202-204108-1072@Xerox>
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
    decision if you ask me...]

 * 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
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA20506; Thu, 3 Dec 87 11:57:15 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	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
In-Reply-To: <8712031857.AA21459@orion.utah.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
discussed here.  We already went around once on cl-cleanup about the
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.

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.

∂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
In-Reply-To: <871204164910.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
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
Received: by unido.uucp with uucp; 
	  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

ARPA net address:        unido!ztivax!kolb@SEISMO.CSS.GOV
Xerox Internet address:  kolb:ztisof:siemens

∂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,
  there is not widespread agreement about which streams are affected.
  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).

Adoption Cost:

  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
Received:  by multimax.ARPA (5.51/25-eef)
	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),
               see also REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF,
               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),
               ADJOIN, UNION, NUNION, INTERSECTION, NINTERSECTION, 
               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)
Category:      ADDITION
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.

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.  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
Received:  by multimax.ARPA (5.51/25-eef)
	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.

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:

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
In-Reply-To: <8712072340.AA01767@multimax.ARPA>
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
some specific comments that I think should be addressed...

    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
In-Reply-To: <8712072337.AA01737@multimax.ARPA>
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),
		   see also REMOVE, REMOVE-IF, REMOVE-IF-NOT, DELETE, DELETE-IF,
		   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),
		   ADJOIN, UNION, NUNION, INTERSECTION, NINTERSECTION, 
		   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.

    Category:      ADDITION
    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
reduction function receives two sequence elements; successive calls receive an
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
to use instead.

		-- 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
Received:  by multimax.ARPA (5.51/25-eef)
	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) 
In-Reply-To: Your message of Tue, 08 Dec 87 12:47:00 -0500.
             <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
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA09306; Wed, 9 Dec 87 08:00:52 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	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
shadowing as well?  :-)

-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
Received:  by multimax.ARPA (5.51/25-eef)
	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) 
In-Reply-To: Your message of 08 Dec 87 14:10:00 -0800.
             <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
Received:  by multimax.ARPA (5.51/25-eef)
	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) 
In-Reply-To: Your message of 08 Dec 87 15:22:00 -0800.
             <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
issues, while many are already being addressed.



     ----- 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

Question and Answers about Common Lisp. (Revised)

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, SYS$INPUT 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, SYS$OUTPUT 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.

Cost of non-Adoption:

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
Received:  by multimax.ARPA (5.51/25-eef)
	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
Received:  by multimax.ARPA (5.51/25-eef)
	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 
  call made when lisp starts.
  
  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.

- ------

  add-primitive-stream (keyword input-stream-or-nil output-stream-or-nil)

  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:

  (upgrade-array-element-type ',aet-x)  ==> ,aet-y
  (upgrade-array-element-type ',aet-y)  ==> ,aet-y


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))

Additionally, to show that un-equivalent type-specifiers that are upgraded
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))



Proposal (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)

-- 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:
     (defun upgrade-array-element-type (element-type)
       (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.]


Adoption Cost:

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).




Proposal (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:FLUSH-UPGRADING)


-- 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.


Adoption Cost:

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
about TYPEP.


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 
      :IMPORT-FROM and :SHADOWING-IMPORT-FROM.

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
release version of SHADOW).



-- 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
statement about this case in the X3J13 CLeanup Committee's issue
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.


Cost of Non-Adoption:

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.


Cost of Non-Adoption:

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.

- 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



- 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)
  (Add :KEY to REDUCE)

- 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)

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

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
In-Reply-To: <8805170905.AA03785@bhopal.lucid.com>
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 
	  :IMPORT-FROM and :SHADOWING-IMPORT-FROM.

    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
In-Reply-To: <880519-144631-1033@Xerox>
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
In-Reply-To: <8805130918.AA25649@bhopal.lucid.com>
Message-ID: <19880521035951.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING seems like the
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
to include SIMPLE-ARRAY and VECTOR in addition to ARRAY.  What about
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
changed your views radically.  Take out a "not."

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.
For example, if your file had in it:

	(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?

Because of the prevalence of user confusion about "upgrading" in arrays;
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
    to include SIMPLE-ARRAY and VECTOR in addition to ARRAY.  What about
    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
    In-Reply-To: <RAM.12365298662.BABYL@>
    . . . 
    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
Reply-To: Dave.Touretzky@cs.cmu.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
low adoption cost.

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   
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

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