perm filename CLCLEA.1[COM,LSP] blob sn#849844 filedate 1987-11-27 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00606 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00087 00002	
C00088 00003	∂23-Apr-87  1359	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue DEFVAR-INIT-TIME (Version 1)
C00093 00004	∂23-Apr-87  1432	gls@Think.COM 	AREF-1D   
C00095 00005	∂23-Apr-87  1447	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue GC-MESSAGES (Version 1)
C00101 00006	∂23-Apr-87  1453	Moon@STONY-BROOK.SCRC.Symbolics.COM 	AREF-1D 
C00104 00007	∂23-Apr-87  2031	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue GC-MESSAGES (Version 1)    
C00107 00008	∂23-Apr-87  2150	Moon@STONY-BROOK.SCRC.Symbolics.COM 	UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT 
C00110 00009	∂23-Apr-87  2157	Moon@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY-NOT-ADJUSTABLE 
C00113 00010	∂23-Apr-87  2209	edsel!bhopal!jonl@navajo.stanford.edu 	AREF-1D    
C00115 00011	∂23-Apr-87  2255	KMP@STONY-BROOK.SCRC.Symbolics.COM 	AREF-1D  
C00118 00012	∂24-Apr-87  1326	masinter.PA@Xerox.COM 	Re: Issue DEFVAR-INIT-TIME (Version 1)    
C00120 00013	∂24-Apr-87  1846	edsel!bhopal!jonl@navajo.stanford.edu 	ADJUST-ARRAY-NOT-ADJUSTABLE    
C00125 00014	∂25-Apr-87  0021	gls@think.com 	DELETE, SORT, ADJUST-ARRAY considered harmful
C00128 00015	∂27-Apr-87  1151	Masinter.pa@Xerox.COM 	Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS 
C00130 00016	∂27-Apr-87  1312	Masinter.pa@Xerox.COM 	status 
C00139 00017	∂28-Apr-87  1114	KMP@STONY-BROOK.SCRC.Symbolics.COM 	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)    
C00159 00018	∂28-Apr-87  1334	JAR@AI.AI.MIT.EDU 	Issue: PROCLAIM-LEXICAL   
C00173 00019	∂28-Apr-87  1916	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PROCLAIM-LEXICAL 
C00178 00020	∂28-Apr-87  2204	masinter.PA@Xerox.COM 	Re: Issue: PROCLAIM-LEXICAL
C00181 00021	∂29-Apr-87  0641	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Re: Issue: PROCLAIM-LEXICAL  
C00187 00022	∂29-Apr-87  0938	KMP@STONY-BROOK.SCRC.Symbolics.COM 	FORMAT-OP-C (Version 2) 
C00196 00023	∂29-Apr-87  0943	KMP@STONY-BROOK.SCRC.Symbolics.COM 	status of DEFVAR-INIT-TIME   
C00199 00024	∂29-Apr-87  1024	JAR@AI.AI.MIT.EDU 	Issue: PROCLAIM-LEXICAL   
C00201 00025	∂29-Apr-87  1025	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Procedure for Steele's proposed clarifications   
C00204 00026	∂29-Apr-87  1131	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS   
C00208 00027	∂29-Apr-87  1234	Pavel.pa@Xerox.COM 	Re: FORMAT-OP-C (Version 2)   
C00210 00028	∂29-Apr-87  1246	KMP@STONY-BROOK.SCRC.Symbolics.COM 	PRINC-CHARACTER (Version 2)  
C00217 00029	∂29-Apr-87  1337	KMP@STONY-BROOK.SCRC.Symbolics.COM 	IF-BODY (Version 5)
C00235 00030	∂29-Apr-87  1404	gls@Think.COM 	AREF-1D   
C00237 00031	∂29-Apr-87  1406	gls@think.com 	AREF-1D   
C00239 00032	∂29-Apr-87  1501	Masinter.pa@Xerox.COM 	Re: status of DEFVAR-INIT-TIME  
C00241 00033	∂29-Apr-87  1722	edsel!bhopal!jonl@navajo.stanford.edu 	Issue: PROCLAIM-LEXICAL   
C00246 00034	∂29-Apr-87  1744	Moon@STONY-BROOK.SCRC.Symbolics.COM 	PRINC-CHARACTER (Version 2) 
C00248 00035	∂29-Apr-87  1744	Moon@STONY-BROOK.SCRC.Symbolics.COM 	FORMAT-OP-C (Version 2)
C00250 00036	∂29-Apr-87  1844	Masinter.pa@Xerox.COM 	Re: FORMAT-OP-C (Version 2)
C00253 00037	∂29-Apr-87  1926	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PROCLAIM-LEXICAL
C00258 00038	∂29-Apr-87  1951	JAR@AI.AI.MIT.EDU 	Issue: PROCLAIM-LEXICAL   
C00263 00039	∂30-Apr-87  0053	edsel!bhopal!jonl@navajo.stanford.edu 	Issue: PROCLAIM-LEXICAL   
C00267 00040	∂30-Apr-87  1425	Masinter.pa@Xerox.COM 	Re: status of DEFVAR-INIT-TIME  
C00269 00041	∂30-Apr-87  1429	Masinter.pa@Xerox.COM 	Re: Procedure for Steele's proposed clarifications  
C00271 00042	∂30-Apr-87  1459	Masinter.pa@Xerox.COM 	Re: Status of IGNORE-ERRORS
C00273 00043	∂30-Apr-87  1502	Masinter.pa@Xerox.COM 	Re: IF-BODY (Version 5)    
C00275 00044	∂30-Apr-87  1638	edsel!bhopal!jonl@navajo.stanford.edu 	Issue: PROCLAIM-LEXICAL   
C00280 00045	∂30-Apr-87  1818	Masinter.pa@Xerox.COM 	Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00283 00046	∂30-Apr-87  1901	JAR@AI.AI.MIT.EDU 	Issue: PROCLAIM-LEXICAL   
C00288 00047	∂01-May-87  1536	edsel!bhopal!jonl@navajo.stanford.edu 	Issue: PROCLAIM-LEXICAL   
C00292 00048	∂01-May-87  1656	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)  
C00303 00049	∂01-May-87  1933	FAHLMAN@C.CS.CMU.EDU 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)    
C00306 00050	∂01-May-87  1947	FAHLMAN@C.CS.CMU.EDU 	ADJUST-ARRAY-NOT-ADJUSTABLE 
C00308 00051	∂01-May-87  2030	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00312 00052	∂01-May-87  2037	FAHLMAN@C.CS.CMU.EDU 	UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT 
C00316 00053	∂01-May-87  2115	FAHLMAN@C.CS.CMU.EDU 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)    
C00319 00054	∂01-May-87  2128	FAHLMAN@C.CS.CMU.EDU 	Issue DEFVAR-INIT-TIME (Version 1)    
C00321 00055	∂01-May-87  2145	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
C00325 00056	∂02-May-87  0707	FAHLMAN@C.CS.CMU.EDU 	DELETE, SORT, ADJUST-ARRAY considered harmful   
C00328 00057	∂02-May-87  1143	FAHLMAN@C.CS.CMU.EDU 	IF-BODY (Version 5)    
C00335 00058	∂02-May-87  1220	FAHLMAN@C.CS.CMU.EDU 	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)   
C00338 00059	∂02-May-87  1313	FAHLMAN@C.CS.CMU.EDU 	Issue: PROCLAIM-LEXICAL
C00344 00060	∂02-May-87  1324	FAHLMAN@C.CS.CMU.EDU 	FORMAT-OP-C (Version 2)
C00346 00061	∂02-May-87  1340	FAHLMAN@C.CS.CMU.EDU 	PRINC-CHARACTER (Version 2) 
C00347 00062	∂02-May-87  1616	JAR@AI.AI.MIT.EDU 	Is JAR on CL-CLEANUP now?  Yes.
C00348 00063	∂02-May-87  1655	JAR@AI.AI.MIT.EDU 	Issue: PROCLAIM-LEXICAL   
C00354 00064	∂02-May-87  1720	FAHLMAN@C.CS.CMU.EDU 	Is JAR on CL-CLEANUP now?  Yes.  
C00356 00065	∂02-May-87  1855	FAHLMAN@C.CS.CMU.EDU 	Issue: PROCLAIM-LEXICAL
C00362 00066	∂04-May-87  1056	Masinter.pa@Xerox.COM 	Issue priority   
C00364 00067	∂04-May-87  1423	KMP@STONY-BROOK.SCRC.Symbolics.COM 	UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT  
C00375 00068	∂04-May-87  1919	FAHLMAN@C.CS.CMU.EDU 	Issue priority    
C00378 00069	∂05-May-87  1416	pedersen.pa@Xerox.COM 	Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2) 
C00382 00070	∂10-May-87  1154	FAHLMAN@C.CS.CMU.EDU 	[RAM: exiting from unwind protects]   
C00389 00071	∂11-May-87  1051	RPG   	Draft of revised FUNCTION-TYPE   
C00403 00072	∂11-May-87  1256	FAHLMAN@C.CS.CMU.EDU 	Issue: FUNCTION-TYPE (version 3) 
C00415 00073	∂11-May-87  1420	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: FUNCTION-TYPE (version 3) 
C00422 00074	∂11-May-87  1443	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-STREAM 
C00426 00075	∂11-May-87  1502	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-SYMBOL 
C00431 00076	∂11-May-87  1803	FAHLMAN@C.CS.CMU.EDU 	Issue: PATHNAME-SYMBOL 
C00433 00077	∂11-May-87  1807	FAHLMAN@C.CS.CMU.EDU 	Issue: PATHNAME-STREAM 
C00434 00078	∂11-May-87  1901	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
C00445 00079	∂11-May-87  1907	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-SYMBOL 
C00447 00080	∂11-May-87  1940	FAHLMAN@C.CS.CMU.EDU 	Issue: PATHNAME-SYMBOL 
C00448 00081	∂12-May-87  0728	FAHLMAN@C.CS.CMU.EDU 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
C00452 00082	∂12-May-87  0930	Gregor.pa@Xerox.COM 	Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)  
C00453 00083	∂12-May-87  1158	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
C00459 00084	∂12-May-87  1258	gls@Think.COM 	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
C00461 00085	∂12-May-87  1430	gls@Think.COM 	Issue: FUNCTION-TYPE (version 3)   
C00462 00086	∂12-May-87  1456	gls@Think.COM 	Issue: PATHNAME-SYMBOL   
C00463 00087	∂12-May-87  1457	gls@Think.COM 	Issue: PATHNAME-STREAM   
C00464 00088	∂12-May-87  2104	Moon@STONY-BROOK.SCRC.Symbolics.COM 	[RAM: exiting from unwind protects]   
C00479 00089	∂12-May-87  2124	Moon@STONY-BROOK.SCRC.Symbolics.COM 	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)   
C00482 00090	∂13-May-87  0012	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: FUNCTION-TYPE (version 3)  
C00490 00091	∂13-May-87  0914	RPG  	FUNCTION-TYPE and Archives   
C00493 00092	∂13-May-87  1133	@ALLEGHENY.SCRC.Symbolics.COM:File-Server@QUABBIN.SCRC.Symbolics.COM 	FUNCTION-TYPE, archives, and Macsyma    
C00497 00093	∂13-May-87  1626	Moon@STONY-BROOK.SCRC.Symbolics.COM 	FUNCTION-TYPE and Archives       
C00500 00094	∂13-May-87  2121	edsel!bhopal!jonl@navajo.stanford.edu 	looping in unwind-protect cleanups  
C00508 00095	∂13-May-87  2158	Moon@STONY-BROOK.SCRC.Symbolics.COM 	looping in unwind-protect cleanups    
C00513 00096	∂14-May-87  1039	edsel!bhopal!jonl@navajo.stanford.edu 	looping in unwind-protect cleanups  
C00517 00097	∂14-May-87  1046	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-SYMBOL  
C00520 00098	∂14-May-87  1051	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-STREAM  
C00522 00099	∂15-May-87  2144	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PROCLAIM-LEXICAL
C00540 00100	∂16-May-87  0302	edsel!bhopal!jonl@navajo.stanford.edu 	Issue: PROCLAIM-LEXICAL   
C00542 00101	∂17-May-87  1447	FAHLMAN@C.CS.CMU.EDU 	Issue: PROCLAIM-LEXICAL
C00549 00102	∂17-May-87  1931	FAHLMAN@C.CS.CMU.EDU 	Issue: FUNCTION-TYPE (version 3) 
C00561 00103	∂17-May-87  1944	FAHLMAN@C.CS.CMU.EDU 	FUNCTION-TYPE and Archives       
C00564 00104	∂18-May-87  1344	gls@Think.COM 	Issue: PROCLAIM-LEXICAL  
C00566 00105	∂18-May-87  1529	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PROCLAIM-LEXICAL
C00568 00106	∂19-May-87  1316	KMP@STONY-BROOK.SCRC.Symbolics.COM 	FORMAT-NEGATIVE-PARAMETERS   
C00572 00107	∂19-May-87  1739	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PROCLAIM-LEXICAL
C00580 00108	∂19-May-87  1801	FAHLMAN@C.CS.CMU.EDU 	Issue: PROCLAIM-LEXICAL
C00588 00109	∂19-May-87  1812	FAHLMAN@C.CS.CMU.EDU 	Issue: PROCLAIM-LEXICAL
C00594 00110	∂26-May-87  1431	Masinter.pa@Xerox.COM 	administrative   
C00597 00111	∂28-May-87  2233	JAR,KMP@AI.AI.MIT.EDU 	Issue: PROCLAIM-LEXICAL    
C00602 00112	∂29-May-87  2113	Masinter.pa@Xerox.COM 	barrage of mail coming
C00604 00113	∂29-May-87  2114	Masinter.pa@Xerox.COM 	Issue ADJUST-ARRAY-DISPLACEMENT 
C00612 00114	∂29-May-87  2116	Masinter.pa@Xerox.COM 	Issue DEFVAR-INIT-TIME (Version 2)   
C00617 00115	∂29-May-87  2118	Masinter.pa@Xerox.COM 	Issue: DO-SYMBOLS-DUPLICATES (Version 2)  
C00624 00116	∂29-May-87  2118	Masinter.pa@Xerox.COM 	Issue: FLET-IMPLICIT-BLOCK (Version 5)    
C00632 00117	∂29-May-87  2119	Masinter.pa@Xerox.COM 	Re: FORMAT-OP-C (Version 2)
C00634 00118	∂29-May-87  2119	Masinter.pa@Xerox.COM 	Issue: FUNCTION-TYPE (version 4)
C00649 00119	∂29-May-87  2121	Masinter.pa@Xerox.COM 	Re: Issue GC-MESSAGES (Version 1)    
C00653 00120	∂29-May-87  2121	Masinter.pa@Xerox.COM 	Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1  
C00658 00121	∂29-May-87  2122	Masinter.pa@Xerox.COM 	IGNORE-ERRORS (Version 4)  
C00664 00122	∂29-May-87  2123	Masinter.pa@Xerox.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)    
C00677 00123	∂29-May-87  2124	Masinter.pa@Xerox.COM 	Issue: PATHNAME-STREAM (Version 2)   
C00681 00124	∂29-May-87  2125	Masinter.pa@Xerox.COM 	Issue: PATHNAME-SYMBOL (Version 2)   
C00687 00125	∂29-May-87  2127	Masinter.pa@Xerox.COM 	Status [Part 1]  
C00694 00126	∂29-May-87  2128	Masinter.pa@Xerox.COM 	***BALLOT *** PART 1 *** BALLOT *** PART 1 *** 
C00698 00127	∂29-May-87  2133	Masinter.pa@Xerox.COM 	Issue: COMPILER-WARNING-STREAM (Version 5)
C00703 00128	∂29-May-87  2214	Masinter.pa@Xerox.COM 	Issue: REMF-DESTRUCTURING-UNSPECIFIED (Version 1)   
C00711 00129	∂29-May-87  2310	Masinter.pa@Xerox.COM 	Issue: TAILP-NIL 
C00714 00130	∂29-May-87  2310	Masinter.pa@Xerox.COM 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 1)
C00716 00131	∂29-May-87  2310	Masinter.pa@Xerox.COM 	Status, Part 2   
C00719 00132	∂29-May-87  2310	Masinter.pa@Xerox.COM 	***BALLOT *** PART 2 *** BALLOT *** PART 2 *** 
C00721 00133	∂30-May-87  0715	MATHIS@ADA20.ISI.EDU 	Re: barrage of mail coming  
C00723 00134	∂31-May-87  2051	masinter.pa@Xerox.COM 	ballots, meeting, etc.
C00725 00135	∂01-Jun-87  1217	JAR@AI.AI.MIT.EDU 	Status, Part 2  
C00727 00136	∂01-Jun-87  1449	edsel!kent-state!eb@navajo.stanford.edu 	AREF-1D  
C00729 00137	∂01-Jun-87  1450	edsel!kent-state!eb@navajo.stanford.edu 	PATHNAME-SYMBOL    
C00731 00138	∂01-Jun-87  1450	edsel!kent-state!eb@navajo.stanford.edu 	***BALLOT *** PARTS 1 AND 2 *** BALLOT *** PARTS 1 AND 2 ***    
C00736 00139	∂01-Jun-87  1650	Gregor.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE (version 4)   
C00738 00140	∂01-Jun-87  1715	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Issue: FUNCTION-TYPE (version 4)  
C00741 00141	∂01-Jun-87  1810	Pavel.pa@Xerox.COM 	AREF-1D   
C00742 00142	∂01-Jun-87  1822	Pavel.pa@Xerox.COM 	DO-SYMBOLS-DUPLICATES    
C00745 00143	∂01-Jun-87  1830	Pavel.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE (version 4)    
C00747 00144	∂01-Jun-87  2041	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: TAILP-NIL  
C00749 00145	∂01-Jun-87  2047	KMP@STONY-BROOK.SCRC.Symbolics.COM 	IGNORE-ERRORS (Version 4)    
C00754 00146	∂01-Jun-87  2050	Moon@STONY-BROOK.SCRC.Symbolics.COM 	PATHNAME-SYMBOL   
C00758 00147	∂01-Jun-87  2055	KMP@STONY-BROOK.SCRC.Symbolics.COM 	People's names
C00761 00148	∂01-Jun-87  2121	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: FUNCTION-TYPE (version 4) 
C00764 00149	∂01-Jun-87  2122	Moon@STONY-BROOK.SCRC.Symbolics.COM 	AREF-1D 
C00766 00150	∂01-Jun-87  2121	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-SYMBOL (Version 2)
C00769 00151	∂01-Jun-87  2126	Moon@STONY-BROOK.SCRC.Symbolics.COM 	***BALLOT ***
C00776 00152	∂01-Jun-87  2137	KMP@STONY-BROOK.SCRC.Symbolics.COM 	FORMAT-OP-C (Version 3) 
C00786 00153	∂01-Jun-87  2151	Moon@STONY-BROOK.SCRC.Symbolics.COM 	IGNORE-ERRORS (Version 4)   
C00788 00154	∂01-Jun-87  2152	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-SYMBOL (Version 2)    
C00792 00155	∂01-Jun-87  2209	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue ADJUST-ARRAY-DISPLACEMENT   
C00797 00156	∂01-Jun-87  2221	KMP@STONY-BROOK.SCRC.Symbolics.COM 	AREF-1D (Version 2)
C00803 00157	∂02-Jun-87  0041	masinter.pa@Xerox.COM 	schedule    
C00805 00158	∂02-Jun-87  0226	KMP@STONY-BROOK.SCRC.Symbolics.COM 	*** BALLOT ***
C00813 00159	∂02-Jun-87  1016	RPG  	Issue: FUNCTION-TYPE (version 4)  
C00815 00160	∂02-Jun-87  1148	Gregor.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE (version 4)   
C00820 00161	∂02-Jun-87  1219	edsel!kent-state!eb@navajo.stanford.edu 	PATHNAME-SYMBOL    
C00823 00162	∂03-Jun-87  0729	gls@Think.COM 	***BALLOT *** PART 1 ***   My reply
C00827 00163	∂03-Jun-87  0731	gls@Think.COM 	DO-SYMBOLS
C00829 00164	∂03-Jun-87  0733	gls@Think.COM 	***BALLOT *** PART 2 *** BALLOT *** PART 2 ***    
C00830 00165	∂03-Jun-87  0749	gls@Think.COM 	June X3J13 meeting  
C00831 00166	∂03-Jun-87  0809	gls@think.com 	Transitivity of coercions
C00833 00167	∂03-Jun-87  0926	gls@Think.COM 	People's names :-)  
C00838 00168	∂03-Jun-87  1101	Moon@STONY-BROOK.SCRC.Symbolics.COM 	DO-SYMBOLS   
C00840 00169	∂03-Jun-87  1154	KMP@STONY-BROOK.SCRC.Symbolics.COM 	People's names :-} 
C00843 00170	∂03-Jun-87  1332	gls@Think.COM 	DO-SYMBOLS
C00846 00171	∂03-Jun-87  1906	Moon@STONY-BROOK.SCRC.Symbolics.COM 	DO-SYMBOLS   
C00850 00172	∂03-Jun-87  2038	FAHLMAN@C.CS.CMU.EDU 	PATHNAME-SYMBOL   
C00852 00173	∂03-Jun-87  2104	FAHLMAN@C.CS.CMU.EDU 	General strategy  
C00856 00174	∂03-Jun-87  2124	FAHLMAN@C.CS.CMU.EDU 	Ballot, parts 1 and 2  
C00862 00175	∂03-Jun-87  2135	FAHLMAN@C.CS.CMU.EDU 	Issue ADJUST-ARRAY-DISPLACEMENT  
C00865 00176	∂03-Jun-87  2145	FAHLMAN@C.CS.CMU.EDU 	Issue: DO-SYMBOLS-DUPLICATES (Version 2)   
C00868 00177	∂03-Jun-87  2201	FAHLMAN@C.CS.CMU.EDU 	IF-BODY 
C00871 00178	∂03-Jun-87  2232	FAHLMAN@C.CS.CMU.EDU 	Issue: FUNCTION-TYPE (version 4) 
C00876 00179	∂03-Jun-87  2238	FAHLMAN@C.CS.CMU.EDU 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
C00878 00180	∂04-Jun-87  0852	RPG  	FUNCTION-TYPE 
C00880 00181	∂04-Jun-87  1742	Masinter.pa@Xerox.COM 	Format revisited 
C00886 00182	∂04-Jun-87  1742	Masinter.pa@Xerox.COM 	AREF-1D (Version 3)   
C00892 00183	∂04-Jun-87  1742	Masinter.pa@Xerox.COM 	Merging of committees 
C00896 00184	∂04-Jun-87  1856	MATHIS@ADA20.ISI.EDU
C00897 00185	∂04-Jun-87  1925	Moon@STONY-BROOK.SCRC.Symbolics.COM 	AREF-1D (Version 3)    
C00899 00186	∂04-Jun-87  1933	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Merging of committees   
C00903 00187	∂05-Jun-87  1808	Masinter.pa@Xerox.COM 	FORMAT-OP-C (Version 4)    
C00912 00188	∂05-Jun-87  1809	Masinter.pa@Xerox.COM 	Re: ASSOC-RASSOC-IF-KEY (Version 1)  
C00914 00189	∂05-Jun-87  1809	Masinter.pa@Xerox.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)    
C00926 00190	∂05-Jun-87  2113	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Sigh -- More procedure  
C00934 00191	∂05-Jun-87  2209	Masinter.pa@Xerox.COM 	Re: Sigh -- More procedure 
C00938 00192	∂05-Jun-87  2209	Masinter.pa@Xerox.COM 	Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)    
C00947 00193	∂05-Jun-87  2209	Masinter.pa@Xerox.COM 	AREF-1D (Version 4)   
C00953 00194	∂05-Jun-87  2209	Masinter.pa@Xerox.COM 	proposal format (version 10)    
C00959 00195	∂05-Jun-87  2210	Masinter.pa@Xerox.COM 	Issue: FLET-IMPLICIT-BLOCK (Version 6)    
C00968 00196	∂05-Jun-87  2235	Masinter.pa@Xerox.COM 	Re: proposal format (version 10)
C00970 00197	∂05-Jun-87  2250	Masinter.pa@Xerox.COM 	Issue: COMPILER-WARNING-STREAM (Version 6)
C00975 00198	∂05-Jun-87  2250	Masinter.pa@Xerox.COM 	Issue: DEFVAR-INITIALIZATION (Revision 3) 
C00980 00199	∂05-Jun-87  2250	Masinter.pa@Xerox.COM 	Issue: DEFVAR-INITIALIZATION (Version 4)  
C00985 00200	∂05-Jun-87  2349	Masinter.pa@Xerox.COM 	Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3  
C00992 00201	∂06-Jun-87  0000	Masinter.pa@Xerox.COM 	***READ ME FIRST ***Status 
C01005 00202	∂06-Jun-87  1412	RPG  	A Hole in Common Lisp   
C01013 00203	∂06-Jun-87  1630	RPG  	FUNCTION-TYPE 
C01015 00204	∂06-Jun-87  1802	FAHLMAN@C.CS.CMU.EDU 	A Hole in Common Lisp       
C01022 00205	∂07-Jun-87  0826	FAHLMAN@C.CS.CMU.EDU 	Rules   
C01025 00206	∂07-Jun-87  1150	KMP@STONY-BROOK.SCRC.Symbolics.COM 	FUNCTION-TYPE 
C01032 00207	∂07-Jun-87  1259	FAHLMAN@C.CS.CMU.EDU 	FUNCTION-TYPE     
C01035 00208	∂07-Jun-87  1318	KMP@STONY-BROOK.SCRC.Symbolics.COM 	FUNCTION-TYPE 
C01038 00209	∂07-Jun-87  1348	FAHLMAN@C.CS.CMU.EDU 	FUNCTION-TYPE
C01041 00210	∂07-Jun-87  1603	FAHLMAN@C.CS.CMU.EDU 	FORMAT-OP-C (Version 4)
C01043 00211	∂07-Jun-87  1612	FAHLMAN@C.CS.CMU.EDU 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
C01045 00212	∂07-Jun-87  1622	RPG  	Hole
C01047 00213	∂07-Jun-87  1630	FAHLMAN@C.CS.CMU.EDU 	Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
C01051 00214	∂07-Jun-87  1632	RPG  	FUNCTION-TYPE 
C01053 00215	∂07-Jun-87  1648	RPG  	FUNCTION-TYPE and EuLisp
C01055 00216	∂07-Jun-87  1753	FAHLMAN@C.CS.CMU.EDU 	AREF-1D (Version 4)    
C01056 00217	∂07-Jun-87  1755	FAHLMAN@C.CS.CMU.EDU 	Issue: FLET-IMPLICIT-BLOCK (Version 6)
C01057 00218	∂07-Jun-87  1756	FAHLMAN@C.CS.CMU.EDU 	Issue: COMPILER-WARNING-STREAM (Version 6) 
C01058 00219	∂07-Jun-87  1756	FAHLMAN@C.CS.CMU.EDU 	Issue: DEFVAR-INITIALIZATION (Version 4)   
C01059 00220	∂07-Jun-87  1756	FAHLMAN@C.CS.CMU.EDU 	Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3   
C01060 00221	∂08-Jun-87  0646	gls@Think.COM 	FORMAT-OP-C (Version 4)  
C01061 00222	∂08-Jun-87  0727	gls@Think.COM 	Hole 
C01065 00223	∂08-Jun-87  0802	FAHLMAN@C.CS.CMU.EDU 	Hole    
C01067 00224	∂08-Jun-87  1128	Masinter.pa@Xerox.COM 	Issue: LOAD-TIME-EVAL (Version 1)    
C01075 00225	∂08-Jun-87  1240	RPG  	Hole
C01077 00226	∂08-Jun-87  1342	FAHLMAN@C.CS.CMU.EDU 	Hole    
C01080 00227	∂08-Jun-87  2001	FAHLMAN@C.CS.CMU.EDU 	Issue: LOAD-TIME-EVAL (Version 1)
C01083 00228	∂08-Jun-87  2126	KMP@STONY-BROOK.SCRC.Symbolics.COM 	LOAD-TIME-EVAL
C01086 00229	∂09-Jun-87  1732	Masinter.pa@Xerox.COM 	procedural, errors.   
C01089 00230	∂09-Jun-87  1822	Masinter.pa@Xerox.COM 	Issue: FUNCTION-TYPE  
C01091 00231	∂09-Jun-87  1835	KMP@STONY-BROOK.SCRC.Symbolics.COM 	procedural, errors.
C01093 00232	∂09-Jun-87  1838	Pavel.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE 
C01095 00233	∂09-Jun-87  2015	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: LOAD-TIME-EVAL (Version 1)
C01102 00234	∂09-Jun-87  2029	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Hole    
C01105 00235	∂09-Jun-87  2113	Moon@STONY-BROOK.SCRC.Symbolics.COM 	A Hole in Common Lisp       
C01109 00236	∂09-Jun-87  2336	Masinter.pa@Xerox.COM 	Re: Issue: LOAD-TIME-EVAL, SHARP-COMMA-SPECIAL-FORM (Version 1)    
C01114 00237	∂10-Jun-87  1212	Pavel.pa@Xerox.COM 	Issue: FORMAT-COMMA-INTERVAL  
C01120 00238	∂10-Jun-87  1357	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Issue: FORMAT-COMMA-INTERVAL  
C01122 00239	∂10-Jun-87  1650	FAHLMAN@C.CS.CMU.EDU 	Issue: FORMAT-COMMA-INTERVAL
C01124 00240	∂10-Jun-87  1906	Pavel.pa@Xerox.COM 	Re: Issue: FORMAT-COMMA-INTERVAL   
C01126 00241	∂10-Jun-87  2127	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
C01130 00242	∂10-Jun-87  2129	Moon@STONY-BROOK.SCRC.Symbolics.COM 	FUNCTION-TYPE     
C01134 00243	∂10-Jun-87  2130	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3   
C01136 00244	∂10-Jun-87  2131	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue ADJUST-ARRAY-DISPLACEMENT  
C01139 00245	∂10-Jun-87  2325	RPG  	Put Up or Shut Up  
C01142 00246	∂11-Jun-87  0958	kempf%hplabsc@hplabs.HP.COM 	Re:  Issue: LOAD-TIME-EVAL (Version 1)   
C01153 00247	∂11-Jun-87  1619	Masinter.pa@Xerox.COM 	Re: Issue ADJUST-ARRAY-DISPLACEMENT  
C01155 00248	∂11-Jun-87  1621	Masinter.pa@Xerox.COM 	Re: Issue: FORMAT-COMMA-INTERVAL
C01156 00249	∂11-Jun-87  1623	Masinter.pa@Xerox.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)    
C01169 00250	∂11-Jun-87  1623	Masinter.pa@Xerox.COM 	Re: IF-BODY (Version 5)    
C01171 00251	∂11-Jun-87  1726	KMP@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY-DISPLACEMENT    
C01175 00252	∂11-Jun-87  1842	Masinter.pa@Xerox.COM 	Status 
C01188 00253	∂11-Jun-87  1842	Masinter.pa@Xerox.COM 	Re: SHARPSIGN-PLUS-MINUS-NUMBER, -PACKAGE 
C01190 00254	∂11-Jun-87  1846	Masinter.pa@Xerox.COM 	Issue: FUNCTION-TYPE  
C01192 00255	∂11-Jun-87  2045	edsel!bhopal!jonl@navajo.stanford.edu 	AREF-1D (Version 2)  
C01195 00256	∂11-Jun-87  2121	FAHLMAN@C.CS.CMU.EDU 	Status  
C01197 00257	∂12-Jun-87  0939	Masinter.pa@Xerox.COM 	Re: Hm      
C01199 00258	∂12-Jun-87  1040	Masinter.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE   
C01204 00259	∂12-Jun-87  1906	FAHLMAN@C.CS.CMU.EDU 	Issue: FUNCTION-TYPE   
C01206 00260	∂12-Jun-87  1943	edsel!bhopal!jonl@navajo.stanford.edu 	ADJUST-ARRAY-DISPLACEMENT 
C01209 00261	∂12-Jun-87  2255	Masinter.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE   
C01212 00262	∂12-Jun-87  2256	Masinter.pa@Xerox.COM 	Issue: EVAL-DEFEATS-LINKER 
C01223 00263	∂13-Jun-87  0042	edsel!bhopal!jonl@navajo.stanford.edu 	Hm    
C01226 00264	∂14-Jun-87  1136	KMP@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY-DISPLACEMENT    
C01231 00265	∂15-Jun-87  1919	Masinter.pa@Xerox.COM 	Re: ASSOC-RASSOC-IF-KEY (Version 1)  
C01233 00266	∂15-Jun-87  1920	Masinter.pa@Xerox.COM 	READ TODAY: Cover letter for mailing to X3J13  
C01246 00267	∂15-Jun-87  1938	FAHLMAN@C.CS.CMU.EDU 	READ TODAY: Cover letter for mailing to X3J13   
C01250 00268	∂15-Jun-87  2042	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: EVAL-DEFEATS-LINKER  
C01259 00269	∂15-Jun-87  2140	Moon@STONY-BROOK.SCRC.Symbolics.COM 	READ TODAY: Cover letter for mailing to X3J13   
C01262 00270	∂16-Jun-87  0159	Masinter.pa@Xerox.COM 	Re: READ TODAY: Cover letter for mailing to X3J13   
C01266 00271	∂16-Jun-87  0608	FAHLMAN@C.CS.CMU.EDU 	Issue: FUNCTION-TYPE (version 5) 
C01292 00272	∂16-Jun-87  1338	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Re: ASSOC-RASSOC-IF-KEY (Version 1)    
C01299 00273	∂16-Jun-87  1945	edsel!bhopal!jonl@navajo.stanford.edu 	READ TODAY: Cover letter for mailing to X3J13 
C01301 00274	∂16-Jun-87  2040	FAHLMAN@C.CS.CMU.EDU 	Issue: EVAL-DEFEATS-LINKER  
C01307 00275	∂16-Jun-87  2336	Masinter.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE (version 5) 
C01309 00276	∂17-Jun-87  0844	barmar@AQUINAS.THINK.COM 	Issue: FUNCTION-TYPE (Version 5)  
C01313 00277	∂17-Jun-87  1312	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: FUNCTION-TYPE (Version 5) 
C01316 00278	∂17-Jun-87  1535	DLW@ALDERAAN.SCRC.Symbolics.COM 	Issue: IF-BODY (Version 7) 
C01320 00279	∂17-Jun-87  1941	edsel!bhopal!jonl@navajo.stanford.edu 	Issue: EVAL-DEFEATS-LINKER
C01325 00280	∂18-Jun-87  1126	RPG  	FUNCTION-TYPE (Version 5)    
C01326 00281	∂18-Jun-87  1132	RPG  	FUNCTION-TYPE  (Version 5)   
C01327 00282	∂19-Jun-87  1429	@RELAY.CS.NET:willc@tekchips.tek.com 	Re: Issue: EVAL-DEFEATS-LINKER  
C01336 00283	∂19-Jun-87  1737	FAHLMAN@C.CS.CMU.EDU 	Issue: EVAL-DEFEATS-LINKER  
C01341 00284	∂22-Jun-87  2236	NGALL@G.BBN.COM 	Re: Issue: FUNCTION-TYPE (Version 5)  
C01347 00285	∂23-Jun-87  0809	FAHLMAN@C.CS.CMU.EDU 	Issue: FUNCTION-TYPE (Version 5) 
C01350 00286	∂23-Jun-87  0948	edsel!kent-state!eb@navajo.stanford.edu 	Issue: FUNCTION-TYPE (Version 5)  
C01354 00287	∂23-Jun-87  1145	NGALL@G.BBN.COM 	Re: Issue: FUNCTION-TYPE (Version 5)  
C01359 00288	∂23-Jun-87  1538	RAM@C.CS.CMU.EDU 	Issue: FUNCTION-TYPE (Version 5)
C01366 00289	∂25-Jun-87  2333	Moon@STONY-BROOK.SCRC.Symbolics.COM 	FUNCTION-TYPE: not allowing symbols to be used as functions    
C01368 00290	∂26-Jun-87  1104	@MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM 	Issue: IF-BODY (Version 7)
C01370 00291	∂29-Jun-87  2239	KMP@STONY-BROOK.SCRC.Symbolics.COM 	DEFVAR-DOCUMENTATION (Version 1)  
C01374 00292	∂06-Jul-87  1658	Masinter.pa@Xerox.COM 	AREF-1D (Version 6)   
C01381 00293	∂13-Jul-87  1257	Masinter.pa@Xerox.COM 	Issue: FUNCTION-TYPE  
C01383 00294	∂13-Jul-87  1321	Masinter.pa@Xerox.COM 	Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5) 
C01391 00295	∂13-Jul-87  1344	Masinter.pa@Xerox.COM 	Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5) 
C01399 00296	∂13-Jul-87  1415	Masinter.pa@Xerox.COM 	Status 
C01413 00297	∂15-Jul-87  1329	Masinter.pa@Xerox.COM 	Issue: Pathname-subdirectory-list    
C01419 00298	∂16-Jul-87  1714	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: Pathname-subdirectory-list
C01426 00299	∂16-Jul-87  1730	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)  
C01428 00300	∂20-Jul-87  2130	edsel!bhopal!jonl@labrea.stanford.edu 	Apropos case sensitive?   
C01433 00301	∂23-Jul-87  1735	Masinter.pa@Xerox.COM 	Issue: LOAD-TIME-EVAL (Version 2)    
C01441 00302	∂23-Jul-87  1735	Masinter.pa@Xerox.COM 	Status, clarification list, members  
C01443 00303	∂24-Jul-87  1024	KMP@STONY-BROOK.SCRC.Symbolics.COM 	OPEN-KEYWORDS 
C01447 00304	∂24-Jul-87  1038	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Mail from Skona Brittain
C01453 00305	∂27-Jul-87  1005	KMP@STONY-BROOK.SCRC.Symbolics.COM 	APPEND-DOTTED 
C01458 00306	∂27-Jul-87  1754	FAHLMAN@C.CS.CMU.EDU 	APPEND-DOTTED
C01459 00307	∂27-Jul-87  1802	FAHLMAN@C.CS.CMU.EDU 	[Fahlman: Iteration standard]    
C01464 00308	∂30-Jul-87  1129	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue KEYWORD-ARGUMENT-NAME-PACKAGE   
C01467 00309	∂30-Jul-87  1145	FAHLMAN@C.CS.CMU.EDU 	Issue KEYWORD-ARGUMENT-NAME-PACKAGE   
C01469 00310	∂30-Jul-87  1717	Masinter.pa@Xerox.COM 	Re: Issue KEYWORD-ARGUMENT-NAME-PACKAGE   
C01472 00311	∂31-Jul-87  1833	edsel!bhopal!jonl@labrea.stanford.edu 	Issue KEYWORD-ARGUMENT-NAME-PACKAGE 
C01474 00312	∂05-Aug-87  1931	Moon@STONY-BROOK.SCRC.Symbolics.COM 	APPEND-DOTTED
C01475 00313	∂14-Aug-87  1651	unido!ztivax!kolb@seismo.CSS.GOV 	Redefinition of system functions    
C01479 00314	∂14-Aug-87  2055	FAHLMAN@C.CS.CMU.EDU 	Redefinition of system functions 
C01482 00315	∂24-Aug-87  1138	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: SHADOW-ALREADY-PRESENT (version 1)  
C01488 00316	∂24-Aug-87  1808	FAHLMAN@C.CS.CMU.EDU 	Issue: SHADOW-ALREADY-PRESENT (version 1)  
C01490 00317	∂27-Aug-87  1429	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: SHADOW-ALREADY-PRESENT (version 2)  
C01499 00318	∂29-Aug-87  1337	Masinter.pa@Xerox.COM 	[Dan Carnese <Carnese@SPAR-20.ARPA>: proposal] 
C01504 00319	∂29-Aug-87  1439	RAM@C.CS.CMU.EDU 	[Dan Carnese <Carnese@SPAR-20.ARPA>: proposal] 
C01509 00320	∂02-Sep-87  1926	CARNESE@SPAR-20.ARPA 	Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]   
C01511 00321	∂02-Sep-87  1952	FAHLMAN@C.CS.CMU.EDU 	[Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]  
C01514 00322	∂03-Sep-87  1118	RAM@C.CS.CMU.EDU 	[Dan Carnese <Carnese@SPAR-20.ARPA>: proposal] 
C01517 00323	∂04-Sep-87  1030	edsel!bhopal!jonl@labrea.stanford.edu 	[Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
C01521 00324	∂04-Sep-87  1047	CARNESE@SPAR-20.ARPA 	Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]   
C01526 00325	∂21-Sep-87  1436	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: SETF-METHOD-FOR-SYMBOLS (version 1) 
C01532 00326	∂21-Sep-87  1957	FAHLMAN@C.CS.CMU.EDU 	Issue: SETF-METHOD-FOR-SYMBOLS (version 1) 
C01536 00327	∂22-Sep-87  0756	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: SETF-METHOD-FOR-SYMBOLS (version 1) 
C01543 00328	∂22-Sep-87  0854	FAHLMAN@C.CS.CMU.EDU 	Issue: SETF-METHOD-FOR-SYMBOLS (version 1) 
C01547 00329	∂22-Sep-87  0905	FAHLMAN@C.CS.CMU.EDU 	Issue: SETF-METHOD-FOR-SYMBOLS (version 1) 
C01549 00330	∂22-Sep-87  1253	Masinter.pa@Xerox.COM 	Re: APPEND-DOTTED
C01551 00331	∂22-Sep-87  1254	Masinter.pa@Xerox.COM 	[remailed] Re: APPEND-DOTTED    
C01553 00332	∂22-Sep-87  1300	dcm%hpfclp@hplabs.HP.COM 	Re: Issue: SETF-METHOD-FOR-SYMBOLS (version 1)   
C01556 00333	∂22-Sep-87  1303	Masinter.pa@Xerox.COM 	Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]  
C01558 00334	∂22-Sep-87  1306	Masinter.pa@Xerox.COM 	Re: Issue: EVAL-DEFEATS-LINKER  
C01560 00335	∂22-Sep-87  1347	FAHLMAN@C.CS.CMU.EDU 	[remailed] Re: APPEND-DOTTED
C01562 00336	∂22-Sep-87  1434	Masinter.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE   
C01565 00337	∂22-Sep-87  1434	Masinter.pa@Xerox.COM 	Status 
C01586 00338	∂22-Sep-87  1434	Masinter.pa@Xerox.COM 	Status 
C01607 00339	∂22-Sep-87  1513	Masinter.pa@Xerox.COM 	status: remaining ISSUES.TXT file    
C01663 00340	∂22-Sep-87  1929	CARNESE@SPAR-20.ARPA 	Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]   
C01668 00341	∂26-Sep-87  1740	Masinter.pa@Xerox.COM 	reply to yuasa message
C01671 00342	∂26-Sep-87  2000	gls@Think.COM 	reply to yuasa message   
C01672 00343	∂26-Sep-87  2030	FAHLMAN@C.CS.CMU.EDU 	reply to yuasa message 
C01673 00344	∂28-Sep-87  0910	Moon@STONY-BROOK.SCRC.Symbolics.COM 	reply to yuasa message 
C01675 00345	∂08-Oct-87  1655	Masinter.pa@Xerox.COM 	Issue: PATHNAME-STREAM (Version 4)   
C01680 00346	∂09-Oct-87  0927	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-STREAM (Version 4)    
C01682 00347	∂09-Oct-87  0927	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-STREAM (Version 4)    
C01684 00348	∂09-Oct-87  1408	Masinter.pa@Xerox.COM 	Re: Issue: PATHNAME-STREAM (Version 4)    
C01687 00349	∂09-Oct-87  1419	Masinter.pa@Xerox.COM 	Re: Issue: PATHNAME-STREAM (Version 4)    
C01690 00350	∂09-Oct-87  1457	Masinter.pa@Xerox.COM 	Issue: STREAM-CLASS-ACCESS 
C01693 00351	∂09-Oct-87  1524	Masinter.pa@Xerox.COM 	Issue: DEFINITION-FUNCTIONS
C01701 00352	∂09-Oct-87  1524	Masinter.pa@Xerox.COM 	Issue Status (reply solicited)  
C01724 00353	∂15-Oct-87  1411	@STONY-BROOK.SCRC.Symbolics.COM,@EUPHRATES.SCRC.Symbolics.COM:Moon@STONY-BROOK.SCRC.Symbolics.COM 	SETF-FUNCTION-VS-MACRO (Version 1)  
C01741 00354	∂15-Oct-87  1725	FAHLMAN@C.CS.CMU.EDU 	SETF-FUNCTION-VS-MACRO (Version 1)    
C01745 00355	∂15-Oct-87  1738	Moon@STONY-BROOK.SCRC.Symbolics.COM 	SETF-FUNCTION-VS-MACRO (Version 1)    
C01749 00356	∂15-Oct-87  1746	FAHLMAN@C.CS.CMU.EDU 	SETF-FUNCTION-VS-MACRO (Version 1)    
C01751 00357	∂16-Oct-87  0107	peck@Sun.COM 	Re: Issue: PUSH-EVALUATION-ORDER    
C01761 00358	∂16-Oct-87  0936	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Issue: PUSH-EVALUATION-ORDER 
C01764 00359	∂16-Oct-87  1106	sandra%orion@cs.utah.edu 	compile-time effects of top-level forms
C01778 00360	∂16-Oct-87  1107	sandra%orion@cs.utah.edu 	proposal for modifying behavior of REQUIRE  
C01787 00361	∂18-Oct-87  1959	FAHLMAN@C.CS.CMU.EDU 	Issue: DEFINITION-FUNCTIONS 
C01789 00362	∂18-Oct-87  2021	FAHLMAN@C.CS.CMU.EDU 	compile-time effects of top-level forms    
C01791 00363	∂19-Oct-87  0731	sandra%orion@cs.utah.edu 	Re: compile-time effects of top-level forms 
C01794 00364	∂19-Oct-87  0801	FAHLMAN@C.CS.CMU.EDU 	compile-time effects of top-level forms    
C01797 00365	∂20-Oct-87  1208	KMP@STONY-BROOK.SCRC.Symbolics.COM 	:1  
C01799 00366	∂20-Oct-87  1224	RAM@C.CS.CMU.EDU 	:1
C01801 00367	∂20-Oct-87  1240	KMP@STONY-BROOK.SCRC.Symbolics.COM 	:1  
C01803 00368	∂20-Oct-87  1247	Masinter.pa@Xerox.COM 	Re: :1 
C01805 00369	∂20-Oct-87  1350	gls@Think.COM 	:1   
C01809 00370	∂20-Oct-87  1424	Moon@STONY-BROOK.SCRC.Symbolics.COM 	:1 
C01813 00371	∂21-Oct-87  1444	Masinter.pa@Xerox.COM 	Issue: TRACE-FUNCTION-ONLY 
C01823 00372	∂21-Oct-87  1741	FAHLMAN@C.CS.CMU.EDU 	Issue: TRACE-FUNCTION-ONLY  
C01828 00373	∂21-Oct-87  1752	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: TRACE-FUNCTION-ONLY  
C01834 00374	∂22-Oct-87  0741	KMP@STONY-BROOK.SCRC.Symbolics.COM 	DECLARE-MACROS (Version 1)   
C01845 00375	∂22-Oct-87  1150	Pavel.pa@Xerox.COM 	Re: DECLARE-MACROS (Version 1)
C01847 00376	∂22-Oct-87  1224	FAHLMAN@C.CS.CMU.EDU 	DECLARE-MACROS (Version 1)  
C01849 00377	∂22-Oct-87  1259	KMP@STONY-BROOK.SCRC.Symbolics.COM 	COLON-NUMBER (Version 1)
C01854 00378	∂22-Oct-87  1303	FAHLMAN@C.CS.CMU.EDU 	COLON-NUMBER (Version 1)    
C01856 00379	∂22-Oct-87  1358	Moon@STONY-BROOK.SCRC.Symbolics.COM 	COLON-NUMBER (Version 1)    
C01858 00380	∂22-Oct-87  1631	Masinter.pa@Xerox.COM 	administrivia    
C01860 00381	∂22-Oct-87  1645	Masinter.pa@Xerox.COM 	Re: DECLARE-MACROS (Version 1)  
C01862 00382	∂22-Oct-87  1716	Masinter.pa@Xerox.COM 	Re: Issue: TRACE-FUNCTION-ONLY  
C01866 00383	∂22-Oct-87  1716	Masinter.pa@Xerox.COM 	Re: COLON-NUMBER (Version 1)    
C01868 00384	∂22-Oct-87  1732	Masinter.pa@Xerox.COM 	Re: Issue: DEFINITION-FUNCTIONS 
C01871 00385	∂22-Oct-87  1738	Masinter.pa@Xerox.COM 	Issue: REQUIRE-PATHNAME-DEFAULTS
C01873 00386	∂22-Oct-87  1757	Masinter.pa@Xerox.COM 	Re: SETF-FUNCTION-VS-MACRO (Version 1)    
C01876 00387	∂22-Oct-87  1840	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: SETF-FUNCTION-VS-MACRO (Version 1)
C01878 00388	∂22-Oct-87  1900	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: REQUIRE-PATHNAME-DEFAULTS 
C01882 00389	∂22-Oct-87  2136	sandra%orion@cs.utah.edu 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS   
C01885 00390	∂23-Oct-87  0709	gls@Think.COM 	COLON-NUMBER (Version 1) 
C01887 00391	∂23-Oct-87  0717	gls@Think.COM 	DECLARE-MACROS (Version 1)    
C01889 00392	∂23-Oct-87  0829	@Score.Stanford.EDU:kempf%hplabsz@hplabs.HP.COM 	Re: Issue: TRACE-FUNCTION-ONLY 
C01897 00393	∂23-Oct-87  0957	Masinter.pa@Xerox.COM 	Issue: PATHNAME-STREAM (Version 5)   
C01904 00394	∂23-Oct-87  1036	Masinter.pa@Xerox.COM 	Issue: PUSH-EVALUATION-ORDER (Version 2)  
C01914 00395	∂23-Oct-87  1046	RAM@C.CS.CMU.EDU 	Issue: PATHNAME-STREAM (Version 5)   
C01919 00396	∂23-Oct-87  1134	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Issue: PATHNAME-STREAM (Version 4)
C01924 00397	∂23-Oct-87  1147	Masinter.pa@Xerox.COM 	Issue: FUNCTION-TYPE (Version 6)
C01946 00398	∂23-Oct-87  1153	Masinter.pa@Xerox.COM 	Issue: FUNCTION-TYPE (Version 6)
C01968 00399	∂23-Oct-87  1201	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-STREAM (Version 5)    
C01975 00400	∂23-Oct-87  1205	Masinter.pa@Xerox.COM 	Re: Issue: PATHNAME-STREAM (Version 4)    
C01977 00401	∂23-Oct-87  1219	@Score.Stanford.EDU:dcm%hpfclp@hplabs.HP.COM 	Re: Issue: FUNCTION-TYPE (Version 6)   
C01979 00402	∂23-Oct-87  1359	Masinter.pa@Xerox.COM 	Format for proposals to the cleanup committee (Version 12)    
C01986 00403	∂23-Oct-87  1411	Masinter.pa@Xerox.COM 	registry of *features* names    
C01988 00404	∂23-Oct-87  1436	Gregor.pa@Xerox.COM 	SETF-FUNCTION-VS-MACRO (Version 1)
C01993 00405	∂23-Oct-87  1514	Moon@STONY-BROOK.SCRC.Symbolics.COM 	SETF-FUNCTION-VS-MACRO (Version 1)    
C01999 00406	∂23-Oct-87  1526	Masinter.pa@Xerox.COM 	Issue: SETF-METHOD-FOR-SYMBOLS (version 2)
C02009 00407	∂23-Oct-87  1635	Masinter.pa@Xerox.COM 	Issue: PATHNAME-SYMBOL (Version 3)   
C02018 00408	∂23-Oct-87  1700	Masinter.pa@Xerox.COM 	Re: Issue: PUSH-EVALUATION-ORDER (Version 2)   
C02020 00409	∂23-Oct-87  1716	Masinter.pa@Xerox.COM 	Environment-arguments, MACRO-FUNCTION-ENVIRONMENT   
C02023 00410	∂23-Oct-87  1728	Masinter.pa@Xerox.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 7)    
C02036 00411	∂23-Oct-87  1748	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 7)
C02038 00412	∂24-Oct-87  1730	Masinter.pa@Xerox.COM 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2) 
C02058 00413	∂24-Oct-87  1752	Masinter.pa@Xerox.COM 	Issue Status     
C02082 00414	∂24-Oct-87  1757	Pavel.pa@Xerox.COM 	Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
C02084 00415	∂25-Oct-87  1331	RAM@C.CS.CMU.EDU  	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
C02091 00416	∂25-Oct-87  1350	FAHLMAN@C.CS.CMU.EDU  	Issue: REQUIRE-PATHNAME-DEFAULTS
C02093 00417	∂25-Oct-87  1430	FAHLMAN@C.CS.CMU.EDU  	Issue: TRACE-FUNCTION-ONLY 
C02099 00418	∂25-Oct-87  1502	FAHLMAN@C.CS.CMU.EDU  	Issue: FUNCTION-TYPE (Version 6)
C02102 00419	∂25-Oct-87  1639	FAHLMAN@C.CS.CMU.EDU  	registry of *features* names    
C02106 00420	∂25-Oct-87  1650	FAHLMAN@C.CS.CMU.EDU  	SETF-FUNCTION-VS-MACRO (Version 1)   
C02109 00421	∂25-Oct-87  1728	FAHLMAN@C.CS.CMU.EDU  	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2) 
C02111 00422	∂26-Oct-87  0935	Moon@ALLEGHENY.SCRC.Symbolics.COM  	SETF-FUNCTION-VS-MACRO (Version 1)
C02113 00423	∂26-Oct-87  0939	EWeaver.pa@Xerox.COM  	[Moon: Issue: Pathname-subdirectory-list] 
C02117 00424	∂26-Oct-87  1050	gls@Think.COM  	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)   
C02120 00425	∂26-Oct-87  1157	Masinter.pa@Xerox.COM  	Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2) 
C02123 00426	∂26-Oct-87  1413	Masinter.pa@Xerox.COM  	Issue: PATHNAME-SUBDIRECTORY-LIST   
C02125 00427	∂26-Oct-87  1413	Masinter.pa@Xerox.COM  	Re: registry of *features* names    
C02127 00428	∂26-Oct-87  1458	Daniels.pa@Xerox.COM  	Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)  
C02129 00429	∂26-Oct-87  1459	Masinter.pa@Xerox.COM  	Re: Issue: TRACE-FUNCTION-ONLY 
C02131 00430	∂26-Oct-87  1616	RAM@C.CS.CMU.EDU  	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 2)
C02134 00431	∂26-Oct-87  1637	Masinter.pa@Xerox.COM  	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3) 
C02147 00432	∂26-Oct-87  1655	Masinter.pa@Xerox.COM  	SETF-FUNCTION-VS-MACRO (Version 2)  
C02166 00433	∂26-Oct-87  1701	Masinter.pa@Xerox.COM  	Issue: SHADOW-ALREADY-PRESENT (version 3)
C02175 00434	∂26-Oct-87  1721	Masinter.pa@Xerox.COM  	*FEATURES*, system package name
C02178 00435	∂26-Oct-87  1738	FAHLMAN@C.CS.CMU.EDU  	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)  
C02180 00436	∂26-Oct-87  1738	FAHLMAN@C.CS.CMU.EDU  	Issue: SHADOW-ALREADY-PRESENT (version 3) 
C02182 00437	∂26-Oct-87  1741	FAHLMAN@C.CS.CMU.EDU  	Issue: SHADOW-ALREADY-PRESENT (version 3) 
C02183 00438	∂26-Oct-87  1742	@Score.Stanford.EDU:kempf%hplabsz@hplabs.HP.COM  	Re: Issue: TRACE-FUNCTION-ONLY     
C02192 00439	∂26-Oct-87  1831	Pedersen.pa@Xerox.COM  	Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3)  
C02195 00440	∂27-Oct-87  0933	CL-Cleanup-mailer  	TRACE Proposal (Version 2)    
C02205 00441	∂27-Oct-87  1307	CL-Cleanup-mailer  	TRACE Proposal (Version 2)    
C02212 00442	∂27-Oct-87  1334	CL-Cleanup-mailer  	Re: TRACE Proposal (Version 2)     
C02215 00443	∂27-Oct-87  1342	CL-Cleanup-mailer  	Issue: PROCLAIM-LEXICAL (Version 4)     
C02236 00444	∂27-Oct-87  1450	CL-Cleanup-mailer  	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)    
C02251 00445	∂27-Oct-87  1901	CL-Cleanup-mailer  	Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
C02253 00446	∂27-Oct-87  2015	CL-Cleanup-mailer  	Issue: PROCLAIM-LEXICAL (Version 4)     
C02258 00447	∂28-Oct-87  0705	CL-Cleanup-mailer  	Issue: PROCLAIM-LEXICAL (Version 4)     
C02263 00448	∂28-Oct-87  0926	CL-Cleanup-mailer  	TRACE Proposal (Version 3)    
C02275 00449	∂28-Oct-87  1307	CL-Cleanup-mailer  	Issue: TRACE-FUNCTION-ONLY    
C02278 00450	∂28-Oct-87  1321	CL-Cleanup-mailer  	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)    
C02280 00451	∂28-Oct-87  1413	CL-Cleanup-mailer  	My silence
C02282 00452	∂28-Oct-87  2111	CL-Cleanup-mailer  	SETF-FUNCTION-VS-MACRO (Version 2) 
C02287 00453	∂29-Oct-87  0814	CL-Cleanup-mailer  	Re: Issue: TRACE-FUNCTION-ONLY     
C02292 00454	∂29-Oct-87  1048	CL-Cleanup-mailer  	SETF-FUNCTION-VS-MACRO (Version 2) 
C02297 00455	∂29-Oct-87  1200	CL-Cleanup-mailer  	Issue names    
C02300 00456	∂29-Oct-87  1241	CL-Cleanup-mailer  	SETF-FUNCTION-VS-MACRO (Version 2) 
C02308 00457	∂29-Oct-87  2102	CL-Cleanup-mailer  	APPEND-DOTTED (Version 2)
C02315 00458	∂29-Oct-87  2203	CL-Cleanup-mailer  	APPEND-DOTTED (Version 2)
C02316 00459	∂30-Oct-87  0820	CL-Cleanup-mailer 	Issue: TRACE-FUNCTION-ONLY (Version 4)   
C02329 00460	∂30-Oct-87  0932	CL-Cleanup-mailer 	REMF-DESTRUCTION-UNSPECIFIED (Version 2) 
C02358 00461	∂30-Oct-87  1117	CL-Cleanup-mailer 	Re: APPEND-DOTTED (Version 2)  
C02359 00462	∂30-Oct-87  1150	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02363 00463	∂30-Oct-87  1154	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02365 00464	∂30-Oct-87  1206	CL-Cleanup-mailer 	APPEND-DOTTED (Version 2) 
C02367 00465	∂30-Oct-87  1307	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02369 00466	∂30-Oct-87  1854	CL-Cleanup-mailer 	Issue: TRACE-FUNCTION-ONLY (Version 4)   
C02371 00467	∂30-Oct-87  1917	CL-Cleanup-mailer 	REMF-DESTRUCTION-UNSPECIFIED (Version 2) 
C02374 00468	∂31-Oct-87  1653	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02378 00469	∂02-Nov-87  1241	CL-Cleanup-mailer 	visit, Professor Takayasu Ito  
C02380 00470	∂02-Nov-87  1714	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02398 00471	∂02-Nov-87  1918	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02403 00472	∂02-Nov-87  1953	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02410 00473	∂03-Nov-87  0859	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02417 00474	∂03-Nov-87  1106	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02425 00475	∂03-Nov-87  1315	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02435 00476	∂03-Nov-87  1909	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS    
C02437 00477	∂03-Nov-87  1938	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS    
C02439 00478	∂04-Nov-87  0907	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02446 00479	∂04-Nov-87  1125	CL-Cleanup-mailer 	SETF-FUNCTION-VS-MACRO (Version 2)  
C02458 00480	∂04-Nov-87  1126	CL-Cleanup-mailer 	SETF-FUNCTION-VS-MACRO (version 3)  
C02478 00481	∂04-Nov-87  1138	CL-Cleanup-mailer 	SETF-FUNCTION-VS-MACRO (Version 2)  
C02490 00482	∂04-Nov-87  1148	CL-Cleanup-mailer 	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 3) 
C02497 00483	∂04-Nov-87  1449	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02501 00484	∂04-Nov-87  2045	CL-Cleanup-mailer 	Issue: SETF-METHOD-FOR-SYMBOLS (version 2)    
C02504 00485	∂08-Nov-87  1119	CL-Cleanup-mailer 	Issue: SHADOW-ALREADY-PRESENT (version 3)
C02506 00486	∂08-Nov-87  1133	CL-Cleanup-mailer 	Issue: TRACE-FUNCTION-ONLY (Version 4)   
C02509 00487	∂08-Nov-87  1154	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
C02512 00488	∂08-Nov-87  1207	CL-Cleanup-mailer 	Re: Issue: PUSH-EVALUATION-ORDER (Version 2)  
C02516 00489	∂08-Nov-87  1220	CL-Cleanup-mailer 	Issue: PUSH-EVALUATION-ORDER (Version 2) 
C02522 00490	∂08-Nov-87  1242	CL-Cleanup-mailer 	Issue: PUSH-EVALUATION-ORDER (Version 3) 
C02534 00491	∂08-Nov-87  1307	CL-Cleanup-mailer 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)   
C02549 00492	∂08-Nov-87  1334	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE (Version 6)    
C02552 00493	∂08-Nov-87  1351	CL-Cleanup-mailer 	Issue: PATHNAME-STREAM (Version 5)  
C02556 00494	∂09-Nov-87  0900	CL-Cleanup-mailer 	Issue Status    
C02564 00495	∂09-Nov-87  1032	CL-Cleanup-mailer 	Issue: SHADOW-ALREADY-PRESENT (version 3)
C02566 00496	∂09-Nov-87  1045	CL-Cleanup-mailer 	Issue: PATHNAME-SYMBOL (Version 3)  
C02568 00497	∂09-Nov-87  1055	CL-Cleanup-mailer 	DECLARE-MACROS (Version 1)
C02571 00498	∂09-Nov-87  1058	CL-Cleanup-mailer 	DECLARE-MACROS (Version 1)
C02574 00499	∂09-Nov-87  1109	CL-Cleanup-mailer 	OPEN-KEYWORDS   
C02579 00500	∂09-Nov-87  1122	CL-Cleanup-mailer 	DECLARE-MACROS (Version 1)
C02583 00501	∂09-Nov-87  1153	CL-Cleanup-mailer 	Re: OPEN-KEYWORDS    
C02585 00502	∂09-Nov-87  1313	CL-Cleanup-mailer 	Re: Issue: PATHNAME-STREAM (Version 5)   
C02589 00503	∂09-Nov-87  1317	CL-Cleanup-mailer 	Re: OPEN-KEYWORDS    
C02591 00504	∂09-Nov-87  1412	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE (Version 7)    
C02613 00505	∂09-Nov-87  1412	CL-Cleanup-mailer 	Issue Status    
C02615 00506	∂09-Nov-87  1557	CL-Cleanup-mailer 	Issue: TRACE-FUNCTION-ONLY (Version 5)   
C02629 00507	∂09-Nov-87  1558	CL-Cleanup-mailer 	DECLARE-MACROS (Version 2)
C02640 00508	∂09-Nov-87  1622	CL-Cleanup-mailer 	Re: Issue: PUSH-EVALUATION-ORDER (Version 3)  
C02643 00509	∂09-Nov-87  1711	CL-Cleanup-mailer 	Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3)
C02646 00510	∂09-Nov-87  1720	CL-Cleanup-mailer 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)   
C02649 00511	∂09-Nov-87  1738	CL-Cleanup-mailer 	Issue: PATHNAME-SYMBOL (Version 3)  
C02651 00512	∂09-Nov-87  1903	CL-Cleanup-mailer 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 8)   
C02654 00513	∂09-Nov-87  1918	CL-Cleanup-mailer 	OPEN-KEYWORDS   
C02661 00514	∂09-Nov-87  1955	CL-Cleanup-mailer 	DECLARE-MACROS (Version 2)
C02665 00515	∂10-Nov-87  1220	CL-Cleanup-mailer 	Re: Issue: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 3) 
C02669 00516	∂10-Nov-87  1255	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SYMBOL (Version 3)   
C02672 00517	∂10-Nov-87  1320	CL-Cleanup-mailer 	Re: Issue: TRACE-FUNCTION-ONLY (Version 5)    
C02675 00518	∂10-Nov-87  2348	CL-Cleanup-mailer 	Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 2)    
C02683 00519	∂10-Nov-87  2359	CL-Cleanup-mailer 	Issue: SHADOW-ALREADY-PRESENT (version 4)
C02692 00520	∂11-Nov-87  0133	CL-Cleanup-mailer 	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4) 
C02706 00521	∂11-Nov-87  0133	CL-Cleanup-mailer 	Issue: SETF-METHOD-FOR-SYMBOLS (version 3)    
C02715 00522	∂11-Nov-87  0149	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02721 00523	∂11-Nov-87  0207	CL-Cleanup-mailer 	Re: Issue: LOAD-TIME-EVAL (Version 2)    
C02723 00524	∂11-Nov-87  0217	CL-Cleanup-mailer 	Re: Issue: LOAD-TIME-EVAL (Version 2)    
C02725 00525	∂11-Nov-87  0249	CL-Cleanup-mailer 	Issue status    
C02746 00526	∂11-Nov-87  0618	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02751 00527	∂11-Nov-87  0844	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 3)   
C02766 00528	∂11-Nov-87  0929	CL-Cleanup-mailer 	Issue status    
C02789 00529	∂11-Nov-87  1020	CL-Cleanup-mailer 	Re: Issue: TRACE-FUNCTION-ONLY (Version 5)    
C02793 00530	∂11-Nov-87  1213	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02795 00531	∂11-Nov-87  1224	CL-Cleanup-mailer 	Re: Issue status
C02796 00532	∂11-Nov-87  1245	CL-Cleanup-mailer 	Re: REMF-DESTRUCTION-UNSPECIFIED (Version 2)  
C02800 00533	∂11-Nov-87  1338	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS
C02802 00534	∂11-Nov-87  1549	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS    
C02804 00535	∂11-Nov-87  1644	CL-Cleanup-mailer 	meeting time    
C02806 00536	∂11-Nov-87  1701	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS     
C02809 00537	∂12-Nov-87  1520	CL-Cleanup-mailer 	meeting time    
C02811 00538	∂12-Nov-87  1537	CL-Cleanup-mailer 	Re: Issue: PATHNAME-STREAM (Version 5)   
C02814 00539	∂12-Nov-87  1704	CL-Cleanup-mailer 	Re: Issue: PUSH-EVALUATION-ORDER (Version 3)  
C02819 00540	∂12-Nov-87  1705	CL-Cleanup-mailer 	Re: Issue: TRACE-FUNCTION-ONLY (Version 5)    
C02822 00541	∂12-Nov-87  1705	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 3)   
C02825 00542	∂12-Nov-87  1815	CL-Cleanup-mailer 	Re: Issue: TRACE-FUNCTION-ONLY (Version 5)    
C02828 00543	∂12-Nov-87  1815	CL-Cleanup-mailer 	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4) 
C02832 00544	∂12-Nov-87  1815	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 3)   
C02835 00545	∂12-Nov-87  1815	CL-Cleanup-mailer 	Re: Issue: PUSH-EVALUATION-ORDER (Version 3)  
C02840 00546	∂12-Nov-87  1843	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 3)   
C02845 00547	∂12-Nov-87  1845	CL-Cleanup-mailer 	Issue: SHARPSIGN-PLUS-MINUS-PACKAGE (Version 2)    
C02847 00548	∂12-Nov-87  1845	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SYMBOL (Version 3)   
C02850 00549	∂12-Nov-87  1845	CL-Cleanup-mailer 	Issue: SETF-METHOD-FOR-SYMBOLS (version 3)    
C02851 00550	∂12-Nov-87  1848	CL-Cleanup-mailer 	Re: meeting time
C02853 00551	∂14-Nov-87  0301	CL-Cleanup-mailer 	Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)  
C02856 00552	∂14-Nov-87  1340	CL-Cleanup-mailer 	Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)  
C02861 00553	∂14-Nov-87  1539	CL-Cleanup-mailer 	Issue: APPEND-DOTTED (Version 3)    
C02868 00554	∂14-Nov-87  1600	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE (Version 8)    
C02886 00555	∂14-Nov-87  1606	CL-Cleanup-mailer 	Issue Status -- Summary of KMP's positions    
C02894 00556	∂14-Nov-87  1616	CL-Cleanup-mailer 	Issue COMPILER-WARNING-BREAK (Version 3) 
C02900 00557	∂15-Nov-87  0305	CL-Cleanup-mailer 	Issue: PATHNAME-STREAM (Version 6)  
C02908 00558	∂15-Nov-87  0306	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 5) 
C02924 00559	∂15-Nov-87  0306	CL-Cleanup-mailer 	Issue: PUSH-EVALUATION-ORDER (Version 4) 
C02938 00560	∂15-Nov-87  0306	CL-Cleanup-mailer 	Issue status    
C02961 00561	∂15-Nov-87  1239	CL-Cleanup-mailer 	Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)  
C02966 00562	∂15-Nov-87  1853	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE (Version 8)    
C02968 00563	∂15-Nov-87  1926	CL-Cleanup-mailer 	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4) 
C02970 00564	∂15-Nov-87  2257	CL-Cleanup-mailer 	Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)  
C02974 00565	∂16-Nov-87  0723	CL-Cleanup-mailer 	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4) 
C02978 00566	∂17-Nov-87  1237	CL-Cleanup-mailer 	Issue: SETF-METHOD-FOR-SYMBOLS (version 3)    
C02982 00567	∂19-Nov-87  1340	CL-Cleanup-mailer 	Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)  
C02985 00568	∂19-Nov-87  1425	CL-Cleanup-mailer 	Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)  
C02989 00569	∂19-Nov-87  1807	CL-Cleanup-mailer 	Issue: DECLARATION-SCOPE  
C03048 00570	∂19-Nov-87  2102	CL-Cleanup-mailer 	Re: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 4)  
C03051 00571	∂20-Nov-87  1114	CL-Cleanup-mailer 	Issue: CONSTANT-SIDE-EFFECTS   
C03060 00572	∂20-Nov-87  1148	CL-Cleanup-mailer 	meeting report, Issue status   
C03062 00573	∂20-Nov-87  1149	CL-Cleanup-mailer 	Issue: CONSTANT-SIDE-EFFECTS   
C03063 00574	∂20-Nov-87  1220	CL-Cleanup-mailer 	Issue: ASSOC-RASSOC-IF-KEY (Version 2)   
C03068 00575	∂20-Nov-87  1235	CL-Cleanup-mailer 	Proposal Format (Version 13)   
C03075 00576	∂20-Nov-87  1311	CL-Cleanup-mailer 	Re: Issue: ASSOC-RASSOC-IF-KEY (Version 2)    
C03076 00577	∂20-Nov-87  1331	CL-Cleanup-mailer 	Issue: ASSOC-RASSOC-IF-KEY (Version 3)   
C03081 00578	∂23-Nov-87  1205	CL-Cleanup-mailer 	Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)   
C03090 00579	∂23-Nov-87  1227	CL-Cleanup-mailer 	Issue: APPEND-DOTTED (Version 4)    
C03098 00580	∂23-Nov-87  1227	CL-Cleanup-mailer 	Issue: APPEND-DOTTED (Version 4)    
C03106 00581	∂23-Nov-87  1245	CL-Cleanup-mailer 	Issue: ASSOC-RASSOC-IF-KEY (Version 4)   
C03112 00582	∂23-Nov-87  1300	CL-Cleanup-mailer 	Issue COMPILER-WARNING-BREAK (Version 4) 
C03117 00583	∂23-Nov-87  1306	CL-Cleanup-mailer 	Re: DECLARE-MACROS (Version 2) Volunteer wanted.   
C03120 00584	∂23-Nov-87  1319	CL-Cleanup-mailer 	Re: DECLARE-MACROS (Version 2) Volunteer wanted.   
C03122 00585	∂23-Nov-87  1326	CL-Cleanup-mailer 	Issue: DEFVAR-DOCUMENTATION (Version 2)  
C03127 00586	∂23-Nov-87  1403	CL-Cleanup-mailer 	Issue: DO-SYMBOLS-DUPLICATES (Version 3) 
C03133 00587	∂23-Nov-87  1442	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE (Version 8)
C03136 00588	∂23-Nov-87  1443	CL-Cleanup-mailer 	Issue: DO-SYMBOLS-DUPLICATES (Version 3) 
C03138 00589	∂23-Nov-87  1602	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION
C03141 00590	∂23-Nov-87  1740	CL-Cleanup-mailer 	Issue: PATHNAME-SYMBOL (Version 4)  
C03151 00591	∂23-Nov-87  1803	CL-Cleanup-mailer 	Issue COMPILER-WARNING-BREAK (Version 4) 
C03153 00592	∂23-Nov-87  1811	CL-Cleanup-mailer 	Issue ADJUST-ARRAY-DISPLACEMENT (Version 4)   
C03155 00593	∂23-Nov-87  1815	CL-Cleanup-mailer 	Issue: APPEND-DOTTED (Version 4)    
C03157 00594	∂23-Nov-87  1818	CL-Cleanup-mailer 	Issue: ASSOC-RASSOC-IF-KEY (Version 4)   
C03158 00595	∂23-Nov-87  1824	CL-Cleanup-mailer 	Issue: CONSTANT-SIDE-EFFECTS   
C03161 00596	∂23-Nov-87  1825	CL-Cleanup-mailer 	Issue: DEFVAR-DOCUMENTATION (Version 2)  
C03162 00597	∂23-Nov-87  1830	CL-Cleanup-mailer 	Issue: PATHNAME-SYMBOL (Version 4)  
C03164 00598	∂23-Nov-87  1839	CL-Cleanup-mailer 	Issue: DO-SYMBOLS-DUPLICATES (Version 3) 
C03165 00599	∂24-Nov-87  1244	CL-Cleanup-mailer 	Issue: KEYWORD-KEYWORDS (Version 1) 
C03173 00600	∂24-Nov-87  1337	CL-Cleanup-mailer 	Re: Issue: DEFVAR-DOCUMENTATION (Version 2)   
C03175 00601	∂24-Nov-87  1920	CL-Cleanup-mailer 	Issue: KEYWORD-KEYWORDS (Version 1) 
C03177 00602	∂25-Nov-87  0917	CL-Cleanup-mailer 	Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT 
C03182 00603	∂25-Nov-87  1547	CL-Cleanup-mailer 	Re: Issue: PROCLAIM-LEXICAL (Version 5)  
C03185 00604	∂25-Nov-87  1745	CL-Cleanup-mailer 	Issue: PUSH-EVALUATION-ORDER (Version 5) 
C03200 00605	∂25-Nov-87  1750	CL-Cleanup-mailer 	Issue status    
C03222 00606	∂27-Nov-87  0751	CL-Cleanup-mailer 	Re: Issue: PROCLAIM-LEXICAL (Version 5)  
C03225 ENDMK
C⊗;
∂23-Apr-87  1359	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue DEFVAR-INIT-TIME (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87  13:59:21 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123216; Thu 23-Apr-87 16:59:34 EDT
Date: Thu, 23 Apr 87 16:59 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue DEFVAR-INIT-TIME (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870423165916.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        DEFVAR-INIT-TIME
References:   DEFVAR (p68)
Category:     CLARIFICATION
Edit history: 23-Apr-87, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  The description of DEFVAR is not completely clear about the time at
  which the initialization occurs.

  On p68 it says ``VARIABLE is initialized to the result of evaluating
  the form INITIAL-VALUE unless it already has a value. The INITIAL-VALUE
  form is not evaluated unless it is used; this fact is useful if
  evaluation of the INITIAL-VALUE form does something expensive like 
  create a large data structure.''

  Although I think the original CL designers all knew what this wording
  was intended   to mean, I have discovered people who have misinterpreted
  the "unless it is used" to mean "unless the variable is used" rather 
  than "unless the initial-value is to be used". The problem is that the
  "it" is ambiguous.

  Having made this false assumption, the people I talked to thought -- 
  and understandably (if lamentably) so -- that they wouldn't know if 
  the variable was to be used until the code ran, so they had the model 
  that the intention was to provide a kind of lazy initialization that
  happened upon the variable's first unbound reference. This confusion
  appears to have been further supported by the additional verbiage about
  not creating expensive structures that are not needed.

Proposal (DEFVAR-INIT-TIME:NOT-DELAYED):

  Clarify that the evaluation of the initial value and the initialization
  happen at DEFVAR execution time (if at all).

Rationale:

  I think it was clear at design time that this was intended. The manual
  should therefore be clear.

Current Practice:

  Nearly all implementations implement the proposed interpretation.

Adoption Cost:

  The misinterpretation is much harder to implement than the proposed
  interpretation. Adoption of the changes should be straightforward.

Benefits:

  This clarification makes the semantics of an important primitive 
  more well-defined.

Conversion Cost:

  Most users presumably expect the behavior currently in practice in most
  dialects. There's not a lot of code where the difference comes into play
  anyway. Presumably the conversion cost is fairly trivial.

Aesthetics:

  Being a clarification, this really doesn't have much aesthetic effect.

Discussion:

  KMP thinks this clarification is important.

∂23-Apr-87  1432	gls@Think.COM 	AREF-1D   
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 23 Apr 87  14:32:25 PDT
Received: from johannes-scotus-erigena by Think.COM via CHAOS; Thu, 23 Apr 87 16:36:10 EST
Date: Thu, 23 Apr 87 17:33 EDT
From: Guy Steele <gls@Think.COM>
Subject: AREF-1D
To: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870422164300.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870423173318.9.GLS@JOHN-THE-SCOT.THINK.COM>

Note that I had proposed something like this to be called
AREF-ROW-MAJOR-ORDER.  It may be that that proposal had
some relevant material that KMP might want to take into account.
Then again, maybe he already did.  That name is too long,
but I feel that the row-majorness should be part of the name.
How about ROW-MAJOR-AREF?  But I don't feel strongly about it.
Otherwise I support the proposal.

Ah.  I recall that perhaps I had suggested having also
a function ROW-MAJOR-INDEX that takes an array and a bunch
of subscripts, just like AREF, and returns the row-major
index of that element.

--Guy

∂23-Apr-87  1447	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue GC-MESSAGES (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87  14:47:28 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123309; Thu 23-Apr-87 17:46:56 EDT
Date: Thu, 23 Apr 87 17:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870423174645.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        GC-MESSAGES
References:   None
Category:     ENHANCEMENT
Edit history: 23-Apr-87, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  Although there is no standard interface to the garbage collector,
  it is common for there to be a garbage collector in nearly every system.
  In many systems, these do unsolicited typeout which obstructs program 
  typeout in unpredictable ways.

Proposal (GC-MESSAGES:FLAG-VARIABLE):

  Make a variable called *GC-MESSAGES* which controls GC message typeout.
  Possible values of this stream include:
    T		Standard notifications (typically to *TERMINAL-IO*).
    NIL		No notifications.

  Since not all implementations could allow an arbitrary user-supplied
  stream for use as a value of *GC-MESSAGES* (because streams might cons
  and consing might be illegal at the time of the message), this cannot
  be offered as an option. However, this would be a reasonable 
  implementation-dependent extension in some systems, so we should offer
  it as an option.

  In multi-processed, shared-address space implementations, if the GC is
  going to type a message on a stream that belongs to some other process
  (or otherwise ``notify'' the process, to use Lisp Machine terminology),
  the value of *GC-MESSAGES* in the process being notified should be used
  rather than the value in the current process so that this variable can
  be usefully bound by user programs.

  Permit that as an act of desperation, shortly before running completely
  out of space when *GC-MESSAGES* is NIL, the GC may notify the user
  that he is about to lose (in spite of the fact that he has seemingly 
  asked to lose). This permission is important so that people don't feel
  afraid to bind *GC-MESSAGES* to NIL to suppress frequent messages 
  only for fear that they might not get critical last minute information 
  that says it's time to do drastic cleanup action.

Rationale:

  Application programs which do display (especially display which conses)
  need a way of deferring GC warnings that might ruin the display.

Current Practice:

  This functionality is provided in some form or another by a number of
  implementations.

  Zetalisp currently offers SI:GC-REPORT-STREAM which can be set to T, NIL,
  or a stream. It provides useful flexibility and is used by quite a number
  of users.

  Other systems provide ways of enabling or disabling the messages, or of
  customizing the message which is typed out.

Adoption Cost:

  The set of places in which the GC does typeout is probably very 
  restricted, so finding them and changing them to be appropriately
  conditionalized is probably not a lot of work.

Benefits:

  This would allow the user some portable control over a common feature which
  cannot currently be controlled in a portable way.

Conversion Cost:

  This is an upward compatible change.

Aesthetics:

  No significant impact.

Discussion:

  MACSYMA needs this (so it can bind it to NIL). Its display often does
  consing. In some implementations this can cause a GC, which can in turn
  spoil the carefully crafted display.

∂23-Apr-87  1453	Moon@STONY-BROOK.SCRC.Symbolics.COM 	AREF-1D 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87  14:53:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123312; Thu 23-Apr-87 17:50:35 EDT
Date: Thu, 23 Apr 87 17:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D
To: Guy Steele <gls@Think.COM>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: <870423173318.9.GLS@JOHN-THE-SCOT.THINK.COM>
Message-ID: <870423175014.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 23 Apr 87 17:33 EDT
    From: Guy Steele <gls@Think.COM>

    Note that I had proposed something like this to be called
    AREF-ROW-MAJOR-ORDER.  It may be that that proposal had
    some relevant material that KMP might want to take into account.
    Then again, maybe he already did.  That name is too long,
    but I feel that the row-majorness should be part of the name.
    How about ROW-MAJOR-AREF?  But I don't feel strongly about it.
    Otherwise I support the proposal.

row-major-aref or aref-row-major would be good names.  I think
KMP's suggested function is sufficiently specialized that it does
not need an especially short name.

    Ah.  I recall that perhaps I had suggested having also
    a function ROW-MAJOR-INDEX that takes an array and a bunch
    of subscripts, just like AREF, and returns the row-major
    index of that element.

array-row-major-index is already in the language.

∂23-Apr-87  2031	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue GC-MESSAGES (Version 1)    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87  20:31:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123639; Thu 23-Apr-87 23:31:18 EDT
Date: Thu, 23 Apr 87 23:31 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870423174645.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870423233110.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

This seems a little short-sighted.  GC messages aren't necessarily the
only unsolicited messages.  In the example application you gave, there
is no reason to treat GC messages differently from other messages.

Also, a simple on/off switch may be a bit too simple.  Not all systems
have windows, but for the ones that do a three-state switch could be
defined in an implementation-independent way: (1) turn the messages off,
(2) put them in the typescript, (3) make them visible to the user in a
way that doesn't interfere with the typescript.  Even some
teletype-oriented systems are able to implement option 3.

In some systems it may not be possible to implement this with a variable,
since changing the state of the switch may have to communicate with an
operating system written in some horrible language.  The safest thing would
be a macro, whose expansion is system-dependent, and within the dynamic
extent of the macro's body unsolicited messages are controlled.

I'm not very optimistic about the possibility of standardizing on this kind
of environmental issue, but perhaps some very simple facility to prevent
messing up of the screen can be agreed on.

∂23-Apr-87  2150	Moon@STONY-BROOK.SCRC.Symbolics.COM 	UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87  21:50:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123691; Fri 24-Apr-87 00:49:23 EDT
Date: Fri, 24 Apr 87 00:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
To: CL-Cleanup@sail.stanford.edu
cc: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>
In-Reply-To: <870423123259.1.HORNIG@WINTER.SCRC.Symbolics.COM>
Message-ID: <870424004910.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

Here's an opinion on this issue from one of our developers, with an
interesting rationale.  I agree with the rationale, which is why I
support either the mentioned proposal or the one that signals an error
and allows the outer THROW to be completed from the debugger.


Date: Thu, 23 Apr 87 12:32 EDT
From: Charles Hornig <Hornig@ALDERAAN.SCRC.Symbolics.COM>

I found KMP's proposal for this and I can now comment effectively.  My
personal feelings are that the right proposal for 1 is the one below.  I
agree with KMP that 2C is correct for 2.


Proposal (UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT:1?):

  Some may believe that the throw to BAR is suppressed,
  the THROW to FOO should somehow complete, but that XXX would 
  never be printed.


The important factor here is that I believe that whenever there are two
THROW's in competition, that we should always proceed to the outermost
CATCH.  This rule permits a programmer to assume that if he does a THROW
out of a computation that that computation will be exited, one way or
another.  This is related to Moon's comment about the programming
environment and aborting.

∂23-Apr-87  2157	Moon@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY-NOT-ADJUSTABLE 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87  21:57:36 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123694; Fri 24-Apr-87 00:57:35 EDT
Date: Fri, 24 Apr 87 00:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-NOT-ADJUSTABLE
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870422165116.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870424005727.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

The wording of your proposal is such that it implies that implementations
that ignore the :ADJUSTABLE argument and simply make all arrays adjustable
would no longer be valid.  I doubt that you intended this.  Implementations
should not be required to implement the non-adjustability complexity if
they don't need it.

Your comment about dead arrays is too obscure.

Having ADJUST-ARRAY sometimes adjust the original array and sometimes
make a copy is dangerous.  I suppose it's no more dangerous than
NREVERSE and SORT, but we know that programmers from all walks of life
consistently have trouble using NREVERSE and SORT correctly.  I'd like
to see some thought given to improving the proposal to make it less
dangerous.

∂23-Apr-87  2209	edsel!bhopal!jonl@navajo.stanford.edu 	AREF-1D    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Apr 87  22:09:05 PDT
Received: by navajo.stanford.edu; Thu, 23 Apr 87 21:08:20 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
	id AA25436; Thu, 23 Apr 87 20:39:17 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
	id AA06857; Thu, 23 Apr 87 21:36:52 PDT
Date: Thu, 23 Apr 87 21:36:52 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704240436.AA06857@bhopal.edsel.com>
To: navajo!gls%Think.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%sail@navajo.stanford.edu
In-Reply-To: Guy Steele's message of Thu, 23 Apr 87 17:33 EDT
Subject: AREF-1D

Your "clarifications" of 6-Dec-85 (distributed at the Boston Meeting
of what eventually became X3J13) added a function named ROW-MAJOR-AREF.

Since CLtL already specified ARRAY-ROW-MAJOR-INDEX, this addition seemed 
very natural and "called for".  So Lucid Common Lisp has had it available
since shortly thereafter.


-- JonL --

∂23-Apr-87  2255	KMP@STONY-BROOK.SCRC.Symbolics.COM 	AREF-1D  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 23 Apr 87  22:52:33 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 123714; Fri 24-Apr-87 01:52:42 EDT
Date: Fri, 24 Apr 87 01:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8704240436.AA06857@bhopal.edsel.com>
Message-ID: <870424015232.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

The reason for the name clash is that I wasn't looking at Steele's 
corrections list at the time I generated the proposal. It was on an
independent list of Macsyma-related issues of my own. Sorry for the
confusion.

The fact that the row-major feature is built into more functions than
just those which have the phrase "ROW-MAJOR" in them (eg, displaced
arrays) leads me to believe that the phrase ROW-MAJOR is just redundant. 
Also, I don't like the phrase "ROW-MAJOR" because it feels very 2d
because the term row seems to apply to 2d matrices. I know it's got a
perfectly well-defined way of generalizing, but...

Also, I thought a name with "1D" in it would emphasize that this was
a non-standard access. I guess "ROW-MAJOR" does that, too, though.

In any case, although I did have reasons for the choice of name, I'm
not passionate about them. Since there's already a precedent for the
other name, I'm happy to go with that. ROW-MAJOR-AREF is fine.

By the way, I think an inverse to ARRAY-ROW-MAJOR-INDEX might nicely
round out the set of operations which took an offset and either a list
of dimensions or an array and returned the standard reference pattern
might nicely round out the set of operations in this family...

∂24-Apr-87  1326	masinter.PA@Xerox.COM 	Re: Issue DEFVAR-INIT-TIME (Version 1)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 24 Apr 87  13:26:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 APR 87 13:17:43 PDT
From: masinter.PA@Xerox.COM
Date: 24 Apr 87 13:17:31 PDT
Subject: Re: Issue DEFVAR-INIT-TIME (Version 1)
In-reply-to: KMP@STONY-BROOK.SCRC.Symbolics.COM's message of Thu, 23 Apr
 87 16:59 EDT, <870423165916.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870424-131743-2546@Xerox>

Kent,

Perhaps you could hold off submitting more issues until we get some of
the open ones out of the way?

∂24-Apr-87  1846	edsel!bhopal!jonl@navajo.stanford.edu 	ADJUST-ARRAY-NOT-ADJUSTABLE    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 24 Apr 87  18:46:54 PDT
Received: by navajo.stanford.edu; Fri, 24 Apr 87 17:46:11 PST
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
	id AA29466; Fri, 24 Apr 87 17:09:51 pst
Received: by bhopal.edsel.com (3.2/SMI-3.2)
	id AA07893; Fri, 24 Apr 87 18:07:26 PDT
Date: Fri, 24 Apr 87 18:07:26 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704250107.AA07893@bhopal.edsel.com>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 24 Apr 87 00:57 EDT
Subject: ADJUST-ARRAY-NOT-ADJUSTABLE

The complexity of this discussion about adjust-array makes me wonder 
if this function isn't striving for too much generality.   Virtually all 
usages I've seen or heard of are really for adjust-array-size.  KMP's 
proposal sounds like he's trying to avoid simply makeing a new array and 
copying (after some fashion) the old into the new.  Maybe it's a simpler 
language design not to try to cover every possible base, but to provide the 
primitives that permit end-users to "roll their own".  In line with 
your remarks:

    Having ADJUST-ARRAY sometimes adjust the original array and sometimes
    make a copy is dangerous.  I suppose it's no more dangerous than
    NREVERSE and SORT, but we know that programmers from all walks of life
    consistently have trouble using NREVERSE and SORT correctly.  I'd like
    to see some thought given to improving the proposal to make it less
    dangerous.

How about the following simplification for adjust-array:
  (1) a new function shall be added which will copy parts of the contents
      of one array into another; MacLisp's FILLARRAY is a base-level start
      for such a function, but one would like something for multi-dimensional 
      arrays that is more meaningful than simple linear, row-wise fill.
  (2) adjust array will only "mess" with the size (or dimensions) and with
      the displacement (i.e., to a new target array, or new index-offset).
      Fill-pointers can already be modified with setf.  Getting new contents
      into a displaced, "adjusted" array can be done by first calling the 
      function ARRAY-DISPLACED-P (as specified in GLS's "clarifications" of
      6-Dec-85) and then using the function called for in (1) to copy parts
      of the original displaced-to array into the newly-displaced one.

-- JonL --

∂25-Apr-87  0021	gls@think.com 	DELETE, SORT, ADJUST-ARRAY considered harmful
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 25 Apr 87  00:21:31 PDT
Received: by Think.COM; Sat, 25 Apr 87 02:25:34 EST
Date: Sat, 25 Apr 87 02:25:34 EST
From: Guy Steele <gls@think.com>
Message-Id: <8704250725.AA21198@Think.COM>
To: cl-cleanup@sail.stanford.edu
Subject: DELETE, SORT, ADJUST-ARRAY considered harmful

Here is an idea that is only two-thirds whimsical:  since 90% of all
people who use DELETE, SORT, etc. lose because they fail to put a setq
around it (as in (SETQ X (DELETE ITEM X)), etc.), why not make it
impossible for them to lose?  Remove these primitives from the language,
and introduce their inverses as SETF places.  For example, instead of
writing (SORT BREAKFAST) or (SETF X (SORT BREAKFAST)), write
	(SETF (SCRAMBLE X) BREAKFAST)
; that is, the variable X is changed so as to make the value of
BREAKFAST a scrambled version of it.  SCRAMBLE would not be a function
itself; you could use it only within a SETF, thereby guaranteeing you
don't lose.  Similarly (SETF (UNDELETE ITEM Z) Z),
(SETF (UNADJUST-ARRAY Z) Z), and so on.

Well, maybe the proposed syntax stinks, but perhaps some way of
idiot-proofing destructive operations should nevertheless be found.

--Yours for a safer language,
  Quux

P.S. I thought you'd never ask: haven't you ever had
scrambled X for breakfast?

∂27-Apr-87  1151	Masinter.pa@Xerox.COM 	Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Apr 87  11:51:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 27 APR 87 11:43:07 PDT
Date: 27 Apr 87 11:51 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Thu, 23 Apr 87 17:50 EDT
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870427-114307-1095@Xerox>

How does this (new) proposal relate to the (old) proposal by Touretsky?

I'm uncomfortable leaving SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS unfinished
while going ahead with a separate proposal which seems to relate to
similar concerns.

Comments?

∂27-Apr-87  1312	Masinter.pa@Xerox.COM 	status 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 27 Apr 87  13:12:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 27 APR 87 13:07:08 PDT
Date: 27 Apr 87 13:15 PDT
From: Masinter.pa@Xerox.COM
Subject: status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870427-130708-1239@Xerox>

This is my status file. Please mail any corrections you have. 

 I don't think we've made very good progress. The only issue that I've
seen resolution on since our meeting before X3J13 is
FLET-IMPLICIT-BLOCK.

I think we can re-release COMPILER-WARNING-STREAM ( Version 3),
DEFVAR-INITIALIZATION (Version 3), FORMAT-ATSIGN-COLON (Revision 3),
IMPORT-SETF-SYMBOL-PACKAGE (Revision 3)

I think we are near completion on these, but they need writing work
*SOON*: 
DEFVAR-INIT-TIME, DO-SYMBOLS-DUPLICATES (Revision 1),
GET-SETF-METHOD-ENVIRONMENT, FORMAT-OP-C (revision 1), FUNCTION-TYPE
(revision 2), IF-BODY (Version 4), KEYWORD-ARGUMENT-NAME-PACKAGE
(Version 1), PRINC-CHARACTER:WRITE-CHAR

The rest seem further from general agreement of the form of the
proposal.


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

ADJUST-ARRAY-NOT-ADJUSTABLE
	Submitted by KMP 22-Apr-87
	comment from Moon, JonL 24-Apr

ADJUST-ARRAY-DISPLACEMENT (revision 1)
	Revision 1 by SEF, 18-Apr-87  
	Comment by Moon 21 Apr 87

AREF-1D
	Submitted 22-Apr-87 by KMP
	Discussion about name of function, addition of ROW-MAJOR-INDEX
function, etc.
	ROW-MAJOR-AREF in clarifications

ASSOC-RASSOC-IF-KEY
	Submitted 22-Apr-87 by KMP

COMPILER-WARNING-BREAK (revision 2)
	not Released.
	Questions on interaction with condition proposal.
	remailed 7-apr-87
	SEF suggested KMP should work on.

COMPILER-WARNING-STREAM (Revision 4)
	Rev 3 was released
	Version 4, submittted by SEF 
	Decided to revert to previous version, 
	  consider DRIBBLE as a separate item. 
	  Need to add DRIBBLE note in Discussion.

DEFVAR-INITIALIZATION (Revision 3)
	Released
	remailed 7-apr-87
	(final form)

DEFVAR-INIT-TIME
	Submitted 23-Apr-87, Version 1 by Pitman

DO-SYMBOLS-DUPLICATES (Revision 1)
	mailed 7-apr-87
	Revision 1 by SEF 17-apr
	Not released, in discussion
	Questions "is it really inefficient to require non-duplicates?" Add
more arguments?

ENVIRONMENT-ARGUMENTS (revision 1)
	SEF summarized issues 18-Apr
	Decided to separate again and:
	 Approve GET-SETF-METHOD-ENVIRONMENT
	 drop MACRO-FUNCTION-ENVIRONMENT
		 ("merely adding an optional argument to macro-function is not
enough")
	 discuss SPECIAL-FORM-SHADOW


FLET-IMPLICIT-BLOCK (Revision 5)
	Discussion & agreement on cl-cleanup.
	revision by Fahlman, 17-Apr-87 to cl-cleanup

FORMAT-ATSIGN-COLON (Revision 3)
	Released.
	(final form, mailed 17-Apr-87)

FORMAT-OP-C (revision 1)
	Discussed and agreed, final form not yet available
	(with Moon's amendment)
	Need volunteer.

FUNCTION-TYPE (revision 2)
	General agreement on basic proposal.
	Wording to be worked out.
	Mailed 17-Apr-87
	Fahlman volunteered to revise & run by RPG

GC-MESSAGES (version 1)
	Submitted by Pitman 23-Apr-87
	Discussion "a little short-sighted"?

IF-BODY (Version 4)
	General agreement to recommend against.
	Final form not yet available.
	Version 4 mailed by KMP , 19-Apr-87
	KMP to produce a new version which Scott will think is balanced


IGNORE-ERRORS
	Discussed and agreed, final form not yet available
	(LMM: Some objections, defer to error/signal committee?)
	Need volunteer.

IMPORT-SETF-SYMBOL-PACKAGE (Revision 3)
	Released
	Should remove confusing "To further clarify: " which is
	about INTERN and not IMPORT.

KEYWORD-ARGUMENT-NAME-PACKAGE (Version 1)
	Submitted by Moon 20 Apr 87.
	Discussion: justification with examples or reference needed before
		releasing to X3J13
		"I'm sure you've got a good reason for proposing this, 
		and I'd like some indication of what it is."

 
PEEK-CHAR-READ-CHAR-ECHO
	Agreed to be controversial
	Need volunteer to summarize positions.


PRINC-CHARACTER:WRITE-CHAR
	Discussed and agreed, final form not yet available
	(write-char choice)
	Need volunteer.

PROMPT-FOR
	Agreed to be controversial
	Need volunteer to summarize positions.

REMF-DESTURCTION-UNSPECIFIED
	Not discussed
	Need volunteer to check over, lead discussion.

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
	(Should FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
	Tabled, a subset which deals with only those functions that
	don't work in positions will be separated out.
	Need volunteer.

SHARPSIGN-BACKSLASH-BITS
	No general agreement (the meeting notes read "we cringed")
	Need volunteer to summarize positions.

SHARPSIGN-PLUS-MINUS-NUMBER
	Discussed, without general agreement.
	Need volunteer to summarize positions.

SHARPSIGN-PLUS-MINUS-PACKAGE
	Discussed, without general agremenet.
	Need volunteer to summarize positions.

TAILP-NIL
	Received but not discussed
	Need volunteer to lead discussion, summarize positions.

UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
	Discussed and agreed at meeting, final form not yet available
	Moon forwards Hornig msg pointing some problems 23-Apr-87

∂28-Apr-87  1114	KMP@STONY-BROOK.SCRC.Symbolics.COM 	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Apr 87  11:13:54 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126277; Tue 28-Apr-87 14:13:26 EDT
Date: Tue, 28 Apr 87 14:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <12276526020.28.TOURETZKY@C.CS.CMU.EDU>,
            <870315-164404-1975@Xerox>
Message-ID: <870428141313.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References:   Sequences (pp245-261), COERCE (p51)
Category:     ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky
	      28-Apr-87, Version 2 by Pitman (variations on the theme)
Status:	      For Internal Discussion

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.

Notes about Voting:

  Select one of:
    SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE (by Touretzky)
    SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED   (by Pitman)
    SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:UNCHANGED  (status quo)
  [See also notes in the discussion about the possibility of a fourth
   way to go if you're not satisfied with any of these.]

Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE):

  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.
  Emphasize this as a way of explaining the behavior of sequence 
  functions on arbitrary arrays.

  Modify the definition of COERCE to allow the coercion of an array to
  a vector and vice versa. In keeping with p51 of CLtL, it should be an
  error if the result type has a different number of elements than the
  object being coerced.

  Modify the definition of MAKE-SEQUENCE to accept array descriptions as
  well as vector descriptions.

  Extend the definitions of sequence functions that either return their
  argument sequences or return non-sequences so that they also allow arrays.
  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, NSUBSTITUTE, NREVERSE, SORT.

  For example, suppose A is a 3x2x7 array. (LENGTH A) should return 42,
  and (ELT A 7) should return A[0,1,0].  :START and :END keywords would
  be interpreted relative to the vector, as would the results returned
  by POSITION and SEARCH.

  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. The affected functions are SUBSTITUTE, REVERSE, and MAP.

  Expressly forbid arrays as arguments to sequence functions that modify
  the number of elements in the array because the shape would be undefined.
  These 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 would write:
	(AND (= (LENGTH A) (LENGTH B)) (EVERY #'EQL A B)).

  Rationale:
  
    This proposal would expand rather than interfere with existing practice.
  
    Since displaced arrays are already part of Common Lisp, the cost of the
    proposed changes would be very low.
  
    If the change is not adopted, Common Lisp programmers who wish to use
    arrays will have two choices.  Either they must write nested DO loops
    every time they want to perform an array operation equivalent to FILL,
    REPLACE, REDUCE, etc., or else they can build displaced vectors by
    hand and pass them to the sequence functions when necessary.
  
  Adoption Cost:
  
    This would involve a lot of changes to functions, but all of them
    presumably 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.
  
    Note that simply extending COERCE, MAKE-SEQUENCE, LENGTH, ELT, and
    the SETF expander for ELT would have the side effect of extending
    the remaining functions if they are written in the obvious way.
    For example:
  
	  (DEFUN SUBSTITUTE (NEW-ITEM OLD-ITEM SEQUENCE &KEY ...)
	    (LET ((RESULT (MAKE-SEQUENCE (TYPE-OF SEQUENCE))))
	      (DOTIMES (I (LENGTH SEQUENCE) RESULT)
		(SETF (ELT RESULT I)
		      (IF (EQL (ELT SEQUENCE I) OLD-ITEM) 
			  NEW-ITEM
			  (ELT SEQUENCE I))))))
  
  Benefits:
  
    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.
  
  Conversion Cost:
  
    This change is `upward compatible.' User code should run unmodified.
  
  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.
  
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED):

  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.
  Emphasize this as a way of explaining the behavior of sequence 
  functions on certain arrays.

  Modify the definition of COERCE to allow the coercion of an array to
  a vector and vice versa. In keeping with p51 of CLtL, it should be an
  error if the result type has a different number of elements than the
  object being coerced.

  Extend the definitions of sequence functions that either return their
  argument sequences, return sequences which are the same shape as their
  argument, or return non-sequences so that they also allow arrays iff
  their action is conceptually independent of the shape of the array.
  The affected functions are COUNT, SOME, EVERY, NOTANY, NOTEVERY,
  FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP.

  Expressly forbid arrays as arguments to other sequence functions. These
  unaffected functions are LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH,
  MISMATCH, REVERSE, NREVERSE, SORT, MAP, SUBSEQ, COPY-SEQ, CONCATENATE,
  MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.

  Rationale:
  
    This proposal would expand rather than interfere with existing practice.
  
    Since displaced arrays are already part of Common Lisp, the cost of the
    proposed changes would be very low.
  
    If the change is not adopted, Common Lisp programmers who wish to use
    arrays will have two choices.  Either they must write nested DO loops
    every time they want to perform an array operation equivalent to FILL,
    REPLACE, etc., or else they can build displaced vectors by hand and
    pass them to the sequence functions when necessary.
  
    This proposal extends certain sequence functions in some interesting
    ways without committing us to a theory of how arrays and sequences
    relate that everyone may not be happy with right now.

  Adoption Cost:
  
    This would involve a lot of changes to functions, but all of them
    presumably 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.
  
  Benefits:
  
    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.
  
  Conversion Cost:
  
    This change is `upward compatible.' User code should run unmodified.
  
  Aesthetics:
  
    This extends certain existing sequence functions to allow arrays
    as arguments in a fairly non-controversial way, leaving aside the
    larger issue of whether and how to generalize the other sequence
    functions.
  
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:UNCHANGED):

  This is the null proposal for the sake of voting clarity. Vote for this
  if you think things should not change.

Current Practice:

  Neither SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE nor
  SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED are likely to be implemented
  anywhere since they are only very recently proposed.

Discussion:

  Touretzky supports SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE.
  He's been building displaced vectors to pass to sequence functions when
  necessary and really dislikes it.

  The members of the Cleanup committee expressed interest in the ideas 
  behind this proposal but weren't sure they could accept it in the
  proposed form. A rewrite to separate some of the issues more clearly
  was solicited.

  Rees suggested that if people are not sure about this a proposal, it might
  be possible to make fly a modified version of the proposal which extended
  only those functions which did not deal with positional information.
  Pitman wrote SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED based on this idea
  and supports at least that much extension, and is sympathetic to (but not
  yet fully committed to the idea of the full proposal).

  Note that in the SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED proposal,
  the function REDUCE is in a grey area. Many of its uses are not
  position-dependent, but some are. The same argument might be made about
  FIND. If people felt strongly, these too could be extended either by
  fudging the conservative rule or by explicit special case(s).

  [It's also possible that a still-more-general proposal might be
   interesting. For example, one that introduced and inverse to 
   ARRAY-ROW-MAJOR-INDEX called ARROW-ROW-MAJOR-SUBSCRIPTS, and have
   functions like POSITION that returned position information or things
   that take :START and :END arguments use subscript (rather than offset)
   information. eg,
    (SETQ A (MAKE-ARRAY '(2 2) :INITIAL-ELEMENT 0))
    (SETF (AREF A 1 0) '1)
    (POSITION 1 A) => (1 0) ;Rather than 2 as suggested above
   This might ease some people's minds if they're just worried that
   returning a 1-d index will feel funny for an any-d array. On the
   other hand, the linear ordering must still be well defined so it'll
   be clear what the search order is, what range is being selected when
   :START and/or :END is used, etc. so you can't hide the issue
   completely. Still, if anyone's interested in a full-blown proposal
   along these lines, they should ask me and I'll write it. --KMP]

∂28-Apr-87  1334	JAR@AI.AI.MIT.EDU 	Issue: PROCLAIM-LEXICAL   
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 Apr 87  13:34:01 PDT
Date: Tue, 28 Apr 87 16:35:56 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Issue: PROCLAIM-LEXICAL
To: cl-cleanup@SAIL.STANFORD.EDU
cc: KMP@AI.AI.MIT.EDU
Message-ID: <192342.870428.JAR@AI.AI.MIT.EDU>

Issue:        PROCLAIM-LEXICAL
References:   variables (p55), scope/extent (p37), global variables (p68),
	      declaration specifiers (p157)
Category:     CLARIFICATION/ENHANCEMENT
Edit history: Revision 2 by JAR 04/28/87
Status:       Very preliminary.

Description of problem:

  CLtL pp. 55-56 implies that if a name (symbol) is not proclaimed or
  declared special, then a free reference to that name is a reference to
  the special variable of that name, while a LAMBDA-binding of that name
  indicates a binding of the lexical variable of that name.  This would
  mean that the following program is legal and that (TST) => 4:

    (defun tst ()
      (setq x 3)
      (funcall (let ((x 4)) #'(lambda () x))))

  However, if you feed this program to many Common Lisp compilers
  (including Symbolics's and DEC's), a warning message will be
  produced for the SETQ, saying something like "Warning: X not
  declared or bound, assuming special."

  These warnings, unlike the annotations of undefined functions (which
  occur only at the end of a compilation), are presented so
  prominently that a user would be hard put to say that a program
  which elicited such warning messages was "correct" in that
  implementation.  Unlike the situation with unused variables, there is
  no possible declaration one can write which suppresses the warning
  messages.

  This disagreement between theory and practice should be mended
  somehow.

Proposal (PROCLAIM-LEXICAL:CURRENT-PRACTICE):

  Change the language definition (page 55?) to say that it is an error
  for there to be a free reference or assignment to a name unless a
  SPECIAL proclamation or declaration is in effect for that name.

  This would legitimize the behavior of current implementations.

Proposal (PROCLAIM-LEXICAL:BY-THE-BOOK):

  Shame implementors into going by the book.  Implementations should
  simply stop intimidating users who want to write code like this.
  "Apparently unbound variable" warnings should be given the same
  purely advisory status that "apparently undefined function" warnings
  now enjoy.  The exact meaning of this is of course implementation-
  dependent.

Proposal (PROCLAIM-LEXICAL:GENERAL):

  Introduce a new declaration specifier, LEXICAL, which is dual to the
  SPECIAL declaration specifier; it may appear in proclamations and
  declarations.

  A name may be proclaimed either lexical or special, but not both.

  A free reference or assignment to a name is an error if there is
  neither a SPECIAL nor a LEXICAL proclamation or declaration in
  effect for the name.  A LAMBDA-binding in the absence of a
  declaration or proclamation binds the lexical variable.

  The global lexical environment and the global dynamic environment
  are identical.  I.e. an assignment to the global binding of a
  lexical variable will be reflected in the observed global value of
  the dynamic variable of the same name, and vice versa.

  Example:

    (proclaim '(lexical x))
    (proclaim '(special y))
    (setq x 1 y 2)

    (defun tst ()
      (let ((x 3) (y 4))
	(locally (declare (special x) (lexical y))
	  (list x y
	        (funcall (let ((x 5) (y 6))
			   #'(lambda () (list x y))))))))

    (tst) => (1 2 (5 4))

Proposal (PROCLAIM-LEXICAL:RESTRICTED):

  Same as PROCLAIM-LEXICAL:GENERAL, but with the following restriction:
  If a name is proclaimed lexical, then it is an error for there to be
  a special declaration of the same name.  For example, the special
  declaration of X in the example is an error.


Cost of adopting change:

  CURRENT-PRACTICE: Ostensibly none, although implementations which
  don't signal this as an error should be explicitly encouraged
  to do so.  It ought to be signalled in interpreted code as well.

  BY-THE-BOOK: This would be an easy fix to the error reporting and
  bookkeepping components of existing compilers.  Of course it is not
  a change to the language, so there is no impact on portable code.

  GENERAL: This would be straightforward to implement, and is perhaps even
  already present, in implementations that use deep binding for
  special variables.  In shallow bound implementations there's a
  problem because two "global" value cells are needed: one for the
  current dynamic binding, and one for the global lexical binding;
  and when no dynamic binding is in effect, they must somehow be
  "coalesced" so that SETQ's are reflected in both.

  RESTRICTED: This is specifically designed to address the
  implementation problems of GENERAL.  Having a dynamic binding and
  having a global lexical binding are mutually exclusive.

Benefits:

  CURRENT-PRACTICE is incompatible with Scheme, which explicitly
  allows a program to have both a global binding and LAMBDA bindings
  of the same variable.  Therefore, adopting any of the other three
  proposals would be a major step towards reducing the
  incompatibilities between the two languages, since both code
  conversion and embedded scheme implementations would be made easier
  and more graceful.

  GENERAL and RESTRICTED have the additional advantage that, in an
  implementation that uses deep binding for dynamic variables, a
  lexical proclamation can be used to achieve significant performance
  gains on references and assignments to global variables.  A LEXICAL
  proclamation would also allow some desirable redundancy, both
  for documentation and for error checking.

Cost of converting existing code:

  CURRENT-PRACTICE: Some programs may rely on the CLtL semantics;
  these would have to be changed if what they're doing now becomes
  officially erroneous.  People might find consistent enforcement
  of this rule rather surprising and frustrating.

  GENERAL and RESTRICTED are both upwards compatible.  Of course,
  code-walking utilities would have to be taught about the new
  feature, since it affects the basic semantics of the language.

Aesthetics:

  The special/lexical business is generally one of CL's most insidious
  and disgusting aspects, and really needs a much more thorough
  overhaul than is proposed above (e.g. there ought to be a separate
  DYNAMIC-LET or SPECIAL-LET which does dynamic binding).  But this is
  probably practically and politically infeasible.  Given that, I
  don't think any of these proposals has clear advantages or
  disadvantages from the point of view of simplicity or elegance of
  description, except that GENERAL is somewhat easier to describe
  than RESTRICTED.

Discussion:

  The four proposals indicate the range of possibilities.  After some
  discussion, we ought to be able to prune this down, of course.

  JAR thinks that CURRENT-PRACTICE is unacceptable, BY-THE-BOOK is
  unsatisfying but somewhat better, and GENERAL has unsolved implementation
  problems, even though it seems the most powerful, symmetric, and elegant.
  Thus RESTRICTED seems preferable.

  This proposal ignores the question of what to do about an analogue
  of DEFVAR or DEFPARAMETER for global lexicals.  Interlisp and PSL both
  have something along these lines (DEFGLOBAL), don't they?

  Given the presence of lexical proclamations in the language, it's
  still not clear whether a free, undeclared, unproclaimed reference
  should be an error, and if it's not an error, whether it should refer
  to the lexical binding or the special binding.  I suggest that it not
  be an error, and I don't really care what its meaning should be (since
  in the situation I care about I'm not going to be dynamically binding
  the variable anyhow, so it doesn't matter).  The RESTRICTED semantics
  would imply that such a reference would have to be to the special
  variable.

  [By the way, I don't like this use of the term "variable," but I'm
  trying to be consistent with CLtL p. 55.  Note that according to this
  it doesn't make any sense to talk about "declaring a variable to be
  special" since any variable is already either special or lexical; it
  is names which can be so declared.  The book is definitely NOT
  consistent about this, and ought to be fixed.]

∂28-Apr-87  1916	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PROCLAIM-LEXICAL 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Apr 87  19:16:42 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126601; Tue 28-Apr-87 18:52:26 EDT
Date: Tue, 28 Apr 87 18:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL 
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, JAR@AI.AI.MIT.EDU
Message-ID: <870428185220.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I support PROCLAIM-LEXICAL:GENERAL if the implementation issues can
be worked out, which I think they can.

I spoke with Jonathan briefly about these problems and I think he
agrees with me that they're not really a problem if you just keep
the global lexical value cells someplace other than the SYMBOL-VALUE
of the symbol.

For example, you might write:

 (DEFVAR SYSTEM:*THE-GLOBAL-LEXICAL-VALUE-CELLS* (MAKE-HASH-TABLE))

 (DEFUN SYSTEM:GLOBAL-LEXICAL-VALUE-CELL (SYMBOL)
   (OR (GETHASH SYMBOL SYSTEM:*THE-GLOBAL-LEXICAL-VALUES-CELLS*)
       (SETF (GETHASH SYMBOL SYSTEM:*THE-GLOBAL-LEXICAL-VALUES-CELLS*)
	     (CONS SYMBOL ;For debugging
		   SYSTEM:*UNBOUND-MARKER*))))

 (DEFMACRO SYSTEM:GLOBAL-LEXICAL-VALUE (SYMBOL)
   `(CDR (EVALUATE-AT-LOAD-TIME (SYSTEM:GLOBAL-LEXICAL-VALUE-CELL ',SYMBOL))))

Of course (as stated above), this changes his proposal slightly to
make the global lexical and dynamic environments disjoint. That is,
programs like
 (DEFUN MAYBE-EVEN-BUT-SURELY-ODD ()
   (+ (LOCALLY (DECLARE (LEXICAL X) (INTEGER X)) X)
      (LOCALLY (DECLARE (SPECIAL X) (INTEGER X)) X)))
could return odd numbers (since lexical X and special X might denote
different quantities).

The contract of the compiler would be to turn global lexical
references to a symbol into (SYSTEM:GLOBAL-LEXICAL-VALUE 'symbol).
The call to SYSTEM:GLOBAL-LEXICAL-VALUE-CELL (ie, the GETHASH) need
happen only once (at load time) so its speed is not important.

If the above code wanted to be portable, of course, you'd have to have
an S-expression equivalent to #, called EVALUATE-AT-LOAD-TIME. Most
implementations have such a thing, I think, they just don't let it out
for users to play with. In fact, I think CL should have such a thing
since this isn't the first case where people have wanted it.
In any case, portability isn't relevant to this message since all
that's needed is to demonstrate that it would be feasible to implement
this in all systems, which I think the above code demonstrates.

∂28-Apr-87  2204	masinter.PA@Xerox.COM 	Re: Issue: PROCLAIM-LEXICAL
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 28 Apr 87  22:04:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 APR 87 22:04:03 PDT
From: masinter.PA@Xerox.COM
Date: 28 Apr 87 22:02:51 PDT
Subject: Re: Issue: PROCLAIM-LEXICAL
In-reply-to: KMP@STONY-BROOK.SCRC.Symbolics.COM's message of Tue, 28 Apr
 87 18:52 EDT, <870428185220.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU, JAR@AI.AI.MIT.EDU
Message-ID: <870428-220403-2039@Xerox>

Jonathan left out the alternative that I thought most natural, namely
that otherwise undeclared
variables were not an error, but would default lexical. E.g.,

(setq x 3)

(defun frob () (incf x))

would not be an error, but would always refer to the lexically global x.

This would bring variable scoping in line with function scoping when
there were no declarations. (A state of grace.)

I presume that Kent didn't really mean to propose that the global
lexical environment be different from the global dynamic environment,
but that was just an awkward artifact of his sample implementation.
Right Kent?

The only idiom which might have portability problems are dynamic calls
to EVAL that get the dynamic binding, e.g., instead of using
SYMBOL-VALUE, e.g., user has a data base of permutations of variables &
values, and also of expressions, binds the variables with PROGV and then
evaluates the expressions.

While current practice is that compilers will warn about undeclared free
references, I know of no interpreter that does, do you?

∂29-Apr-87  0641	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Re: Issue: PROCLAIM-LEXICAL  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87  06:35:52 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 126932; Wed 29-Apr-87 09:35:59 EDT
Date: Wed, 29 Apr 87 09:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PROCLAIM-LEXICAL
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM,
    JAR@AI.AI.MIT.EDU
In-Reply-To: <870428-220403-2039@Xerox>
Message-ID: <870429093550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I'm sympathetic to the idea that undeclared free variables should
default lexical. Certainly if we had lexical globals I'd expect that
some compilers would start defaulting free variables lexical while
others would continue to default them special, so perhaps we should
just go ahead and make it well-defined.

Anyway, the separation of global lexical environment from global special
environment seems to me important. After all, you can already do:
 (DEFUN F (X) (+ X (LOCALLY (DECLARE (SPECIAL X)) X)))
and see two different variables X without any intervening rebinding.
I was just assuring that this effect was properly carried through.

Also, this assures that people cannot muck with the lexical binding
of any variable. Special variables are kind of 3lispy in nature because
we're told how they're represented and we have primitives for manipulating
them either as variables or as data. I think this makes program proofs
more difficult. The feature of lexical variables is that all of their
uses are statically detectable; this would not be so for global lexicals
if their homes were something that users were permitted to read in a 
non-statically-detectable way (eg, using SYMBOL-VALUE) or set (using SETF
of same). By making the lexical bindings totally isolated, you ensure
the right of the compiler to do much better compilation of global lexicals
in some cases than it might be able to do for global specials, and at the
same time you don't make any unpleasant changes to the mechanisms already
in place and in use for specials.

And finally, if you separate the two spaces, then you can go back and
forth between declaring variables special or not without it having strange
effect on things already compiled. eg, if you needed:

(DEFGLOBAL Y 3)
(DEFUN F (X) (+ X Y))
...
(PROCLAIM '(SPECIAL Y))
(DEFUN FOO (Y) (BAR))
(DEFUN BAR () ... (SETQ Y ...) ...)
(PROCLAIM '(LEXICAL Y))

without worrying that the global lexical Y=3 binding was in danger
of getting modified (which it seems intuitive to me that it should
not have been).

MACSYMA, for example, needs an UNSPECIAL declaration because on a
per-file basis it goes back and forth between using the same name either
special or lexical. Alternating back and forth between default LEXICAL
and default SPECIAL would serve it as well if we made that legal.
If such alternation meant that programs previously compiled using the
other semantics were now in error or might behave differently than I
intended at time-of-definition, then you've defeated the purpose of my
doing the alternation. I think the separation of namespaces ensures
intuitive behavior.

∂29-Apr-87  0938	KMP@STONY-BROOK.SCRC.Symbolics.COM 	FORMAT-OP-C (Version 2) 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87  09:38:26 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127175; Wed 29-Apr-87 12:38:42 EDT
Date: Wed, 29 Apr 87 12:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-OP-C (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870429123832.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:	      FORMAT-OP-C
References:   WRITE-CHAR (p384), ~C (p389)
Category:     CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
	      29-Apr-87, Version 2 by Pitman (merge Moon's suggestion)
Status:	      For Internal Discussion

Problem Description:

  The manual is not adequately specific about the function of the format
  operation ~C. The description on p389 says that "~C prints the character 
  in an implementation-dependent abbreviated format. This format should
  be culturally compatible with the host environment." This description
  is not very useful in practice.

  Presumably the authors intended the `cultural compatibility' part to
  gloss issues like how the SAIL character set printed, but unfortunately
  another completely reasonable (albeit unplanned) interpretation arose
  that wasn't planned on:
    (FORMAT NIL "~C" #\Space) might "Space" rather than " ".
  [Anyone who would argue that the word `abbreviated' in the definition
  was supposed to prevent this should just be happy that some implementors 
  didn't choose to interpret that word to mean that "Sp" should come back.]

  Some implementations have (FORMAT NIL "~C" #\Space) => "Space".
  Others have the same form return " ".

  Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
  It seems as if the implementations which return "Space" treat ~C and
  ~:C equivalently or very similarly, which seems like a waste of a FORMAT op.

  Since the behavior of ~A is also vague on characters (a separate 
  proposal will address this), the only way to safely output a literal
  character is to WRITE-CHAR; FORMAT does not suffice (unless you use
  ~Q of #'WRITE-CHAR -- which is generally neither pretty nor convenient).

Proposal (FORMAT-OP-C:WRITE-CHAR):

  Change the description of ~C on p389 to say:

       ~C prints the character using WRITE-CHAR if it has zero bits.
     Characters with bits are not necessarily printed as WRITE-CHAR
     would do, but are displayed in an implementation-dependent
     abbreviated format that is culturally compatible with the host
     environment.

  Add the following to the description of WRITE-CHAR on p384:

     Note: The glyphs used to present characters which are not in
     the standard character set may vary from implementation to
     implementation or output device to output device. WRITE-CHAR
     will always output a single character to the indicated stream.
     On some streams, super-quoting, character substitution, or
     substitution of a string for a single character may be 
     necessary; it is appropriate for the stream to decide to do
     this, but WRITE-CHAR itself will never do this.

Rationale:

  This was probably the intent of the authors. 

  It makes things clear enough that programmers can know what to
  expect in the normal case (standard characters with zero bits)
  while leaving some flexibility to implementors about what to do in
  the case of bits (which are not particularly well-defined across
  different implementations anyway).

Current Practice:

  Implementations are divided. Some implementations have
     (FORMAT NIL "~C" #\Space) => "Space".
  Others have the same form return " ".

Adoption Cost:

  Those implementations which did not already implement ~C as WRITE-CHAR
  would suffer an incompatible change.

Benefits:

  User code that uses ~C would have a chance of being portable.
  As things stand, users who use ~C can't reliably port their code.

  ~C and ~:C would perform usefully distinct operations.

Conversion Cost:

  Standard ``Query Replace'' technology for finding occurrences of
  "~C" and changing them to "~:C" semi-automatically should suffice.

Aesthetics:

  Making ~C do something well-defined will probably be perceived as
  a simplification.

Discussion:

  Pitman thinks it's important to get this cleared up as soon as possible.

  Moon's comment on Version 1 (which tried to make WRITE-CHAR and ~C
  identical in all cases) was:
    I believe the error in CLtL is that it was not stated explicitly
    that the "implementation-dependent abbreviated format" applies only
    to characters with non-zero char-bits. Thus instead of removing the
    mumbling about cultural compatibility, I suggest simply adding a
    sentence saying that ~C is the same as write-char for characters
    with zero char-bits.  I don't think we want to require ~C and
    write-char to do the same thing for characters with bits.

  Steele and Fahlman seemed to like the idea of the proposal if amended
  as Moon suggested. Pitman did the merge, creating Version 2. If he didn't
  blow it somehow, they should now be happy.

∂29-Apr-87  0943	KMP@STONY-BROOK.SCRC.Symbolics.COM 	status of DEFVAR-INIT-TIME   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87  09:43:37 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127180; Wed 29-Apr-87 12:43:47 EDT
Date: Wed, 29 Apr 87 12:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: status of DEFVAR-INIT-TIME
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <870427-130708-1239@Xerox>
Message-ID: <870429124341.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 27 Apr 87 13:15 PDT
    From: Masinter.pa@Xerox.COM

    This is my status file. Please mail any corrections you have.
    ...

    I think we are near completion on these, but they need writing work
    *SOON*: 
    DEFVAR-INIT-TIME, ...

I saw no reply at all to DEFVAR-INIT-TIME (other than your mail saying
to please hold off on new proposals until the ones we have get cleaned up).

In the absence of any comments on what might be wrong with this proposal
(which I personally think is pretty non-controversial), I'm not able to
produce an update. If anyone has objections (or just wants to second it
as-is), they should voice them.

∂29-Apr-87  1024	JAR@AI.AI.MIT.EDU 	Issue: PROCLAIM-LEXICAL   
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87  10:24:34 PDT
Date: Wed, 29 Apr 87 13:26:40 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Issue: PROCLAIM-LEXICAL
To: masinter.PA@XEROX.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@SCRC-STONY-BROOK.ARPA
In-reply-to: Msg of 28 Apr 87 22:02:51 PDT from masinter.PA at Xerox.COM
Message-ID: <192793.870429.JAR@AI.AI.MIT.EDU>

    Date: 28 Apr 87 22:02:51 PDT
    From: masinter.PA at Xerox.COM

    While current practice is that compilers will warn about undeclared free
    references, I know of no interpreter that does, do you?

The VAX LISP interpreter will generate such warnings if an internal,
unreleased switch is set non-nil.  Its default value is nil.  For a week
or two when the feature first appeared (only inside DEC, of course) the
switch was defaultly true.  Some people liked the immediate feedback,
but overall the warnings were judged too radical and disconcerting, so
the default was changed.

∂29-Apr-87  1025	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Procedure for Steele's proposed clarifications   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87  10:25:44 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127203; Wed 29-Apr-87 13:08:07 EDT
Date: Wed, 29 Apr 87 13:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Procedure for Steele's proposed clarifications
To: Masinter.PA@Xerox.COM, Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
References: <870427-130708-1239@Xerox>
Message-ID: <870429130801.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

If something is in Steele's clarifications (X3J13/86-003), do we
still need to write it up in full blown form for vote?

In particular, does the fact that my AREF-1D proposal overlaps
with the proposal for ROW-MAJOR-AREF mean that I should modify
my proposal to use the new name (which I'm certainly content to
do) or that I should retract my proposal since the same proposal
is already on the floor.

I certainly think that full-blown forms of all the things in
the clarifications would be nice because it would save a lot of
time at meetings answering obvious questions, but some of the
things in that document are pretty simple and straightforward
in their one-liner form and I just want to clarify before doing
a lot of work that expanding them is what is intended.

∂29-Apr-87  1131	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87  11:30:54 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127310; Wed 29-Apr-87 14:18:24 EDT
Date: Wed, 29 Apr 87 14:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@sail.stanford.edu, Dave.Touretzky@C.CS.CMU.EDU
In-Reply-To: <870427-114307-1095@Xerox>
Message-ID: <870429141817.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 27 Apr 87 11:51 PDT
    From: Masinter.pa@Xerox.COM
    Re:   AREF-1D, SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS

    How does this (new) proposal relate to the (old) proposal by Touretsky?

[For Touretzky's context, the "new" proposal being referred to was one to
 introduce a function AREF-1D (later renamed to ROW-MAJOR-AREF to correspond
 to a name chosen earlier by Steele in a suggested clarifications document
 he distributed).]

    I'm uncomfortable leaving SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS unfinished
    while going ahead with a separate proposal which seems to relate to
    similar concerns.

    Comments?

At first I wondered if the omission of a proposal to generalize AREF so
that if you gave it a single index it (implicitly asserting it to be a 
vector, and hence a sequence), then it should just do a 1-d AREF (as ELT
would do). In fact, however, I think this would decrease error checking
in an undesirable way and my guess is that Touretzky was being very
deliberate in not including a proposal to do this.

Moreover, although some compilers might treat
 (ELT (THE ARRAY X) 3)
as efficiently as
 (ROW-MAJOR-AREF X 3)
I don't think anyone would be willing to require such efficient treatment.
In compilers which didn't optimize this (and in most interpreters, too)
you'd still have to do the LISTP check before getting around to the
implicit ROW-MAJOR-AREF. Although it isn't suggested that ROW-MAJOR-AREF
is needed only for efficiency, it is true that most applications where it's
likely to be used need maximal efficiency, so I think making it a separate
primitive is appropriate.

All this being said, I think it's safe to make these two proposals proceed
in parallel without worrying that they conflict in some way. If you're not
convinced, please let me know.

∂29-Apr-87  1234	Pavel.pa@Xerox.COM 	Re: FORMAT-OP-C (Version 2)   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87  12:34:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 APR 87 11:53:00 PDT
Date: 29 Apr 87 11:52 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: FORMAT-OP-C (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 29 Apr 87 12:38 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870429-115300-2626@Xerox>

The mention of the non-standard format directive ~Q should be removed
from the proposal.  Other than that, I favor it.

	Pavel

∂29-Apr-87  1246	KMP@STONY-BROOK.SCRC.Symbolics.COM 	PRINC-CHARACTER (Version 2)  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87  12:46:08 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127412; Wed 29-Apr-87 15:46:19 EDT
Date: Wed, 29 Apr 87 15:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PRINC-CHARACTER (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870429154611.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I removed the FORMAT-OP-C proposal from this since no one seemed to be
championing it. As far as I know, this was the only simplification anyone
had asked for. -kmp

========================================================================
Issue:        PRINC-CHARACTER
References:   PRINC (p383)
Category:     CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
	      29-Apr-87, Version 2 by Pitman (removed FORMAT-OP-C)
Status:       For Internal Discussion

Problem Description:

  The manual is not adequately specific about the function of PRINC
  when given a character as an argument. 

  For example, does (PRINC #\Space) print ``Space'' or `` ''? 

  The advice that "the general rule is that output from PRINC is
  intended to look good to people" is the root of a lot of the problem.
  The truth is that what looks good varies with context. viz,

   * For (FORMAT NIL "Foo~ABar" #\Space)
     Pretty result: "Foo Bar"
     Ugly result:   "FooSpaceBar"
     In other words, " " looks better here.

   * For (FORMAT T "Type ~C to continue" #\Space)
     Pretty result: "Type Space to continue"
     Ugly result:   "Type   to continue"
     In other words, "Space" looks better here.

Proposal (PRINC-CHARACTER:WRITE-CHAR):

  (PRINC char stream) should be defined to be equivalent to
  (WRITE-CHAR char stream).

Rationale:

  The behavior of (PRINC char) should be well-defined even if a
  completely arbitrary decision had to be made.

  In fact, though, we can get some advice by appealing to history.
  The only data type which corresponds to characters in most old
  lisps was symbols. For example, in Maclisp,
    (PRINC char-symbol) == (TYO (GETCHARN char-symbol 1))

  In Common Lisp, it would make sense in the absence of arguments
  to the contrary to preserve an analagous relation, namely:
    (PRINC char) == (WRITE-CHAR char)

Current Practice:

  Vaxlisp, Symbolics, Spice Lisp, and Lucid all print " " and not
  "Space" for (PRINC #\Space).

  Symbolics and Spice are known to use the WRITE-CHAR strategy.
  Vaxlisp and Lucid might be using it, too, or they might be
  using ~C in FORMAT; no one familiar with their internals has
  commented.

  In any case, some other implementations are believed to differ
  (ie, to output "Space" when you PRINC a #\Space), but a specific
  reference is not currently available. In any case, the wording
  in CLtL is not clear enough to preclude such a differing
  implementation from `legitimately' emerging.

Adoption Cost:

  Any implementations which did not already implement this proposal
  decided upon would suffer an incompatible change.

Benefits:

  User code that uses PRINC (and presumably ~A) on characters would
  have a chance of being portable.

Conversion Cost:

  It's easy to search for occurrences of PRINC and ~A in code, but
  it may not always be apparent when the argument is a character.
  Automatic conversion is unlikely to succeed.

Aesthetics:

  Making PRINC do something well-defined for as many primitive data
  types as possible will probably be perceived as a simplification.

Discussion:

  KMP thinks this is moderately important because it is embarrassing
  to have commonly used functions like this vary so widely in behavior
  between implementations. He doesn't think it is critical because
  (if nothing else) it is only one of many problems with the vague
  contract of PRINC.

  There was an alternate proposal PRINC-CHARACTER:FORMAT-OP-C which
  suggested making PRINC work like ~C in FORMAT, but no one seemed
  to think that was useful and the proposal was removed for Version 2
  to keep from muddying what's likely to be a very straightforward 
  vote in favor of PRINC-CHARACTER:WRITE-CHAR.

∂29-Apr-87  1337	KMP@STONY-BROOK.SCRC.Symbolics.COM 	IF-BODY (Version 5)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87  13:37:18 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127499; Wed 29-Apr-87 16:37:14 EDT
Date: Wed, 29 Apr 87 16:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IF-BODY (Version 5)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <870427182129.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
Message-ID: <870429163704.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I hope this draft manages to merge the IF-BODY:NO stuff in
a relatively fair way. -kmp

 ``... looks reasonably balanced to me, and represents my
   own opinions adequately.  I see no objection to releasing
   it to the world at large ...''

	-- Guy L. Steele, Jr.
	   author of ``Common Lisp: The Language''

==============================================================================
Issue:        IF-BODY
References:   IF (p115)
Category:     ENHANCEMENT
Edit history: 27-Feb-87, Version 1 by Pitman   (IF-BODY:YES)
	       3-Mar-87, Version 2 by Fahlman  (added IF-BODY:NO)
	      17-Apr-87, Version 3 by Masinter (merged v1 and v2)
	      19-Apr-87, Version 4 by Pitman   (misc editing to v3)
	      27-Apr-87, Version 5 by Pitman   (reworked for balance)
Status:       Not for release

Problem Description:

  CLtL defines the meaning of an IF expression only in the case of two or
  three arguments. Some implementations extend the meaning to allow more
  arguments.

  Typically, using the extended IF syntax will not generate a warning in
  environments which support it. Code developed where these features are
  available is not typically discovered to be in error until a port to
  some other implementation is attempted. At that point, which is 
  typically inconveniently late in the development cycle, the developer
  may notice that code either does not compile (generates syntax errors)
  or does not compile correctly (the additional forms are quietly ignored
  and the code generated is not what the writer intended).

  The problem is rightly due to the user, but users typically expect that
  they should be warned about such problems. Unfortunately, however, both
  the Lisp which allows the extended syntax and that which fails to signal
  an error about the invalid syntax are within their rights as currently
  stated.

  This phenomenon is a barrier to Common Lisp's portability goals.

Test Case:
 
  (IF NIL 'THEN 'ELSE 'MORE)

  According to CLtL, this is an error.
  In some implementations, this returns ELSE.
  In some implementations, this returns MORE.
  In some implementations, this signals an error at syntax analysis time.

Notes about Voting:

  Select one of IF-BODY:ILLEGAL, IF-BODY:LEGAL, or IF-BODY:UNCHANGED.

Proposal (IF-BODY:ILLEGAL):

  Restrict IF, making it expressly illegal to supply more than three
  argument forms. Require that implementations signal an error at
  syntax analysis time.

  Rationale:

    As long as some implementations provide this extension while
    others do not, the portability goals of Common Lisp will suffer.
    It is not adequate to encourage implementors to warn about 
    non-standard uses since the only implementations which will
    implement the extension are ones who think it is a good idea to
    use the feature, and people are not inclined to warn about things
    they think are a good idea to use.

    Although some implementations offer extended definitions and
    this would be an incompatible change, the cost of that change
    would be offset by the improvement in code portability.

  Adoption Cost:

    The direct act of making this restriction is trivial, but there
    are nth order effects which may be non-trivial...

    In Symbolics implementations the SCL package contains Symbolics'
    extensions to LISP. Currently, for any symbol LISP:xxx, the
    expression (EQ 'LISP:xxx 'SCL:xxx) => T. This change would force
    as a second order effect a decision about whether to make
    (EQ 'LISP:IF 'SCL:IF) => NIL or to rewrite all code (user and 
    system) using the extended IF.

    Since there are currently no cases where LISP symbols are not
    shared by SCL, a decision to break the sharing would force us
    to do a complicated re-evaluate our position on the nature of
    compatibility between Common Lisp and the extensions we provide.

    The cost of this option is therefore potentially large.

  Conversion Cost:

    Uses of IF in correct Common Lisp code are technically unaffected
    by this change, although it should be clear from the discussion
    of Adoption Cost that viewing things this way may be just a word
    game. In practice, there might be non-trivial effects on 
    code that is not technically `Common Lisp' but which is thought to
    be `Common Lisp compatible.' The importance of this must be weighed
    in context, but should not be discounted altogether.

  Benefits:

    Code portability between certain dialects would be improved.

  Aesthetics:

    The (IF test then else) syntax is neatly symmetric and this
    symmetry should be preserved.

    Some people find the asymmetry of the (IF test then {else}*)
    syntax to be visually confusing.

    IF is supposed to be the simplest conditional form, from which
    all the others are built.

Proposal (IF-BODY:LEGAL):

  Extend IF, making it expressly legal to supply an implicit-PROGN of
  `else' forms using the syntax (IF test then {else}*).

  Rationale:

    As long as some implementations provide this extension while
    others do not, the portability goals of Common Lisp will suffer.
    It is not adequate to encourage implementors to warn about 
    non-standard uses since the only implementations which will
    implement the extension are ones who think it is a good idea to
    use the feature, and people are not inclined to warn about things
    they think are a good idea to use.

    Although some implementations offer extended definitions and
    this would be an incompatible change, the cost of that change
    would be offset by the improvement in code portability.

  Adoption Cost:

    In most implementations, making this syntax legal is a matter of
    a fairly localized change to a finite number of utilities which
    reason about programs (compiler, interpreter, code walkers). No
    changes to code which does not reason about programs would be 
    necessary.

    In some implementations which have incompatible extension 
    strategies, such as keyword-driven facilities, the cost is higher
    because this is an incompatible change. The cost of adoption in
    such cases is hard to estimate; implementors who feel they have
    severe concerns about this should raise those concerns and we'll
    modify this proposal to reflect them.

  Benefits:

    Code portability between certain dialects would be improved.

  Aesthetics:

    The resolution of this controversial programming style issue
    is left to the user rather than being forced by the language
    designer. Those who prefer the symmetry of the (IF test then else)
    syntax are free to use it exclusively without infringing on the
    desires of others to use the extended syntax.

    Some people find the alternatives to (IF test then {else}*) to
    be too visually cumbersome.

    Although IF was supposed to be a simple conditional form, usage
    patterns suggest that this is not uppermost in many users' minds.
    Experience in user communities where extended IF is available 
    show that few users object to its presence; most are happy for
    the syntactic flexibility it provides.

Proposal (IF-BODY:UNCHANGED):

  Leave IF as currently specified in CLtL.

  Implicit in this proposal is that it would be valid for any
  implementation to extend IF as long as such an extension was done
  in a way that was `upward compatible' with Common Lisp.

  Rationale:

    The other two proposals are inadequately motivated.

    Since some implementations already support extensions, it would
    be disruptive to those implementations to require that the
    extensions be removed. Not altering the current definition is
    maximally conservative with regard to existing code.

  Adoption Cost:

    Making this syntax legal is trivial since everyone is
    presumably already compatible with the existing standard.

    Implicit in the acceptance of this proposal, however is the
    incremental cost of late debugging of programs which are in error
    but for which no diagnostic has been generated because we have 
    not required such a diagnostic.

  Benefits:

    The current state of the world would be unaffected.

  Aesthetics:

    The (IF test then else) syntax is neatly symmetric and this
    symmetry should be preserved.

    Some people find the asymmetry of the (IF test then {else}*)
    syntax to be visually confusing.

    IF is supposed to be the simplest conditional form, from which
    all the others are built.

Current Practice:

  Some implementations already provide this feature.

  A few implementations provide alternate keyword-driven extensions
  that are incompatible with the IF-BODY:LEGAL extension.
   
  Some implementations signal an error if other than two or three
  arguments are passed.

  Some implementations quietly ignore additional arguments to IF (making
  it hard to detect errors in code that was developed on systems with
  the extended syntax).

Discussion:

  MACSYMA ran into this problem.

  KMP supports IF-BODY:LEGAL.
  Steele and Fahlman support IF-BODY:UNCHANGED.
  Moon has no strong opinion.

  Fahlman expressed strong concern about the potential precedent which 
  could be set by using compatibility concerns as a lever to introduce
  all kinds of unwanted idiosyncratic extensions present in only one
  implementation and no other.

  Moon suggested that the mere fact that some people like an extension
  is not sufficient reason to put it into the language, but is
  sufficient reason to -discuss- putting it into the language.

  Steele notes that one of the reasons for including IF in the language
  is to have a simple primitive that can easily be recognized, by people
  and by program-walkers alike, as being the simplest conditional and
  not having implicit PROGNs as do WHEN, UNLESS, and COND.

  KMP thinks the language is already so cluttered that worrying about
  such a tiny change to IF is unwarranted. He thinks that if the only
  concern was primitive simplicity, we should just redefine the layer
  at which simplicity is achieved by letting LISP:IF be a macro that
  expands into PRIMITIVE:IF which has simpler semantics but which no
  one has to be stuck programming with (if they don't want to). You
  could argue that users should make their own JDOE:IF macro that has
  this extension, but since this is likely to be a common extension, it's
  our place to consider it for adoption as part of the standard.

∂29-Apr-87  1404	gls@Think.COM 	AREF-1D   
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87  14:04:18 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 29 Apr 87 15:19:45 EDT
Date: Wed, 29 Apr 87 15:16 EDT
From: Guy Steele <gls@Think.COM>
Subject: AREF-1D
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870424015232.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870429151657.4.GLS@BOETHIUS.THINK.COM>

    Date: Fri, 24 Apr 87 01:52 EDT
    From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>

    In any case, although I did have reasons for the choice of name, I'm
    not passionate about them. Since there's already a precedent for the
    other name, I'm happy to go with that. ROW-MAJOR-AREF is fine.

I am not passionate either.  AREF-1D has the advantage of brevity.

    By the way, I think an inverse to ARRAY-ROW-MAJOR-INDEX might nicely
    round out the set of operations which took an offset and either a list
    of dimensions or an array and returned the standard reference pattern
    might nicely round out the set of operations in this family...

This is a good idea.

--Guy

∂29-Apr-87  1406	gls@think.com 	AREF-1D   
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87  14:05:52 PDT
Received: from THINK.COM by navajo.stanford.edu with TCP; Wed, 29 Apr 87 14:04:23 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 29 Apr 87 15:20:50 EDT
Date: Wed, 29 Apr 87 15:17 EDT
From: Guy Steele <gls@think.com>
Subject: AREF-1D
To: edsel!bhopal!jonl@navajo.stanford.edu,
        navajo!gls%Think.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%sail@navajo.stanford.edu, gls@think.com
In-Reply-To: <8704240436.AA06857@bhopal.edsel.com>
Message-Id: <870429151757.5.GLS@BOETHIUS.THINK.COM>

    Date: Thu, 23 Apr 87 21:36:52 PDT
    From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)

    Since CLtL already specified ARRAY-ROW-MAJOR-INDEX, this addition seemed 
    very natural and "called for".  So Lucid Common Lisp has had it available
    since shortly thereafter.

Foo.  It just goes to show that I can't remember what's in the book either.

∂29-Apr-87  1501	Masinter.pa@Xerox.COM 	Re: status of DEFVAR-INIT-TIME  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87  15:01:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 APR 87 14:17:27 PDT
Date: 29 Apr 87 14:17 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: status of DEFVAR-INIT-TIME
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 29 Apr 87 12:43 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <870429-141727-2814@Xerox>

I put DEFVAR-INIT-TIME in the "we can release this soon" because I
presumed that it was so trivial there would be no objection. Usually its
a mistake to make any such presumptions, but one can always hope....


∂29-Apr-87  1722	edsel!bhopal!jonl@navajo.stanford.edu 	Issue: PROCLAIM-LEXICAL   
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87  17:22:30 PDT
Received: by navajo.stanford.edu; Wed, 29 Apr 87 17:22:02 PDT
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
	id AA01519; Wed, 29 Apr 87 16:33:45 pdt
Received: by bhopal.edsel.com (3.2/SMI-3.2)
	id AA13102; Wed, 29 Apr 87 16:30:59 PDT
Date: Wed, 29 Apr 87 16:30:59 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704292330.AA13102@bhopal.edsel.com>
To: navajo!KMP%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: Kent M Pitman's message of Wed, 29 Apr 87 09:35 EDT
Subject: Issue: PROCLAIM-LEXICAL

In a deep-bound Lisp, it is critically important to be able to distinguish 
"global" access/update from "special", or "fluid" access/update.  A note 
I sent to the CL mailing list about a year ago stressed this point; it
explained the semantic differences and showed some performance consequences.
There were not many replies about it since almost all Common Lisps are 
currently shallow-bound [the upcoming Xerox effort will be an exception, 
and some parallel research versions of Common Lisp are also an exception]

Since none of these proposals for clarifying the semantics of undeclared
variables propose to do away with "special" variables, then the question 
of global/fluid distinction for "specials" is still relevant.  So I'm a 
bit concerned about the proposal to add yet a third environment, the 
"global lexical", which doesn't address this concern.

Consider, for a moment, the example:
   (let ((x 1))
     (declare (special x))
     (load "some-file"))
where the contents of "some-file" are
   (setq x (+ x 3))
The historic interpretation is that this SETQ applies to the special
binding of x.  To get the effect of setting the global "fluid" binding,
one would have to say something like 
  (proclaim '(global x))
  (setq x (+ x 3))
or like
  (locally (declare (global x)) (setq x (+ x 3)))
or use functions like Interlisp's "topval" functions:
   (settopval 'x (+ (gettopval 'x) 3))
In this example, it would/should be illegal to lambda-bind x if it were 
declared "global"; thus it is quite satisfactory to use the shallow-binding 
value cell as both the "global" cell and the "special" cell;  For many 
reasons, it is very convenient to have the "top-level" fluid environment 
be the same as the global environment.  

That's why I'm a bit taken aback by your proposal that the "global lexical" 
could not share with the global dynamic (fluid) environment.  Whereas there 
is the demonstrated need for a declaration which distinguishes special 
variables from global variables, where is the need for a distinct, yet 
parallel, global lexical environment?


-- JonL --

∂29-Apr-87  1744	Moon@STONY-BROOK.SCRC.Symbolics.COM 	PRINC-CHARACTER (Version 2) 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87  17:44:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127770; Wed 29-Apr-87 20:26:29 EDT
Date: Wed, 29 Apr 87 20:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PRINC-CHARACTER (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870429154611.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870429202621.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

I favor PRINC-CHARACTER:WRITE-CHAR.

∂29-Apr-87  1744	Moon@STONY-BROOK.SCRC.Symbolics.COM 	FORMAT-OP-C (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87  17:44:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127778; Wed 29-Apr-87 20:29:19 EDT
Date: Wed, 29 Apr 87 20:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-OP-C (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870429123832.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870429202910.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

I favor FORMAT-OP-C:WRITE-CHAR.

∂29-Apr-87  1844	Masinter.pa@Xerox.COM 	Re: FORMAT-OP-C (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Apr 87  18:44:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 APR 87 18:45:08 PDT
Date: 29 Apr 87 18:46 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: FORMAT-OP-C (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 29 Apr 87 12:38 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870429-184508-3208@Xerox>

Kent, I'll point out again that the proposal should not say "Change the
wording on p. 3241 to say...". The proposal should describe what ANSI
Standard Lisp should do, not what Guy Steele's second edition should
say. The words you use can be pretty much the same, but a number of
folks expressed some sensitivity that the cleanup committee not dictate
wording.

E.g., rather than

"  Change the description of ~C on p389 to say:

       ~C prints the character using WRITE-CHAR if it has zero bits.
     Characters with bits are not necessarily printed as WRITE-CHAR
     would do, but are displayed in an implementation-dependent
     abbreviated format that is culturally compatible with the host
     environment."


Proposal (FORMAT-OP-C:WRITE-CHAR):

The ~C option of format, when given a character with zero bits, will
perform the same action as WRITE-CHAR. (The behavior of FORMAT with the
~C directive given a character with non-zero bits attributes remains
unspecified.)

∂29-Apr-87  1926	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Apr 87  19:26:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127905; Wed 29-Apr-87 22:26:18 EDT
Date: Wed, 29 Apr 87 22:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <192342.870428.JAR@AI.AI.MIT.EDU>
Message-ID: <870429222608.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

I remember some of this being discussed before, and there being some
reason for not doing it that I couldn't remember, so I went back
through some old Common Lisp documents I have held onto.  Here's
what I found:

21 Dec 1981 Issue #70 - we discussed the issue of what undeclared
free variable references mean, but couldn't decide.  The alternatives
offered weren't very deep:
  (a) interpreter and compiler warn
  (b) interpreter never warns, compiler is permitted to warn
  (c) "status quo" [it said] the interpreter never warns, but the compiler
      never warns for top level forms, but is permitted to warn inside functions

21 Dec 1981 Issue #72 - we tentatively introduced a LOCAL declaration,
meaning not SPECIAL.  This was by analogy with the UNSPECIAL declaration
of Maclisp and Zetalisp, but we decided to change the name.  I don't
think we had completely understood the DECLARE/PROCLAIM distinction
at that time (although we were discussing it) so I'm not sure what
LOCAL meant as a proclamation; I think the idea was just that as a
declaration it could be used to shadow a SPECIAL proclamation.

8/14/82 I found a note of mine saying "there is no way to declare
a variable not special.  I guess this got taken out when special was
changed not to be pervasive.  This needs to be fixed."

8/21/82 Common Lisp meeting Issue #78: Need some kind of declaration to
locally shadow a globally pervasive special declaration [I think that's
a special proclamation in current terminology].  I have written down that
"the vote was yes, GLS will propose, read JonL's paper".  I don't have a
clue which JonL paper this refers to.

In all later documents, there is special but no unspecial nor local.

This confirmed my memory that a lexical declaration had been put in and
then taken out, but I was unable to find any written rationale for the
decisions, which is what I was really looking for.  I didn't go so far
as to search the electronic mail archives (but I don't think they go
back all the way to 1981).

∂29-Apr-87  1951	JAR@AI.AI.MIT.EDU 	Issue: PROCLAIM-LEXICAL   
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 29 Apr 87  19:51:22 PDT
Date: Wed, 29 Apr 87 22:53:15 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Issue: PROCLAIM-LEXICAL
To: edsel!bhopal!jonl@NAVAJO.STANFORD.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@MX.LCS.MIT.EDU
In-reply-to: Msg of Wed 29 Apr 87 16:30:59 PDT from edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
Message-ID: <193127.870429.JAR@AI.AI.MIT.EDU>

    Date: Wed, 29 Apr 87 16:30:59 PDT
    From: edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)

    So I'm a bit concerned about the proposal to add yet a third
    environment, the "global lexical", which doesn't address this
    concern.

I'm having trouble understanding how you count environments.  I count a
total of four:

       1. lexical LAMBDA-bindings
       2. global lexical
       3. dynamic LAMBDA-bindings
       4. global dynamic

KMP doesn't suggest ADDING a global lexical environment; the global
lexical environment is already there in the GENERAL and RESTRICTED
proposals.  He merely suggests making it not be identical to the global
dynamic environment.  This would make a total of 4 environments, not 3.

I tend to think of 2 and 4 as being part of 1 and 3.  This is consistent
if you imagine that there's an immense cosmic LAMBDA surrounding all
the programs in the world; this LAMBDA binds all possible names.

I have no opinion at this point on the virtues of KMP's amendment.

    In this example, it would/should be illegal to lambda-bind x if it were
    declared "global"; thus it is quite satisfactory to use the
    shallow-binding value cell as both the "global" cell and the "special"
    cell...

This proposal is even more restrictive than RESTRICTED.  I see no reason
to impose this restriction, and I see Scheme compatibility as a big
reason that we SHOULD allow lambda-binding variables which have global
bindings.  The RESTRICTED proposal seems to give you everything you want
-- it allows you to have a single global value cell in
shallow-dynamic-binding implementations, and it allows the desired
performance advantages in deep-dynamic-binding implementations.  Why do
you want to rule out lexically lambda-binding global variables?  Does
this have something to do with shallow lexical binding?

If I have told you something you didn't already know, or if you still
don't understand what I'm getting at, how can I make the proposals
clearer?

Jonathan

∂30-Apr-87  0053	edsel!bhopal!jonl@navajo.stanford.edu 	Issue: PROCLAIM-LEXICAL   
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87  00:53:24 PDT
Received: by navajo.stanford.edu; Thu, 30 Apr 87 00:52:55 PDT
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
	id AA03157; Wed, 29 Apr 87 23:47:27 pdt
Received: by bhopal.edsel.com (3.2/SMI-3.2)
	id AA13625; Wed, 29 Apr 87 23:44:42 PDT
Date: Wed, 29 Apr 87 23:44:42 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704300644.AA13625@bhopal.edsel.com>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 29 Apr 87 22:26 EDT
Subject: Issue: PROCLAIM-LEXICAL

Re :8/21/82 Common Lisp meeting Issue #78: Need some kind of declaration to
    locally shadow a globally pervasive special declaration [I think that's
    a special proclamation in current terminology].  I have written down that
    "the vote was yes, GLS will propose, read JonL's paper".  I don't have a
    clue which JonL paper this refers to.
This "Common Lisp meeting" was held at CMU just after the 1982 Lisp
Conference.  The "JonL paper" in question could hardly be anything 
other than my contribution to that conference.  It had a long title
something like "Constant Time Interpretation for Variables, in the
Presence of Mixed SPECIAL/LOCAL Declarations".  It described the VAX/NIL
interpreter, and how it processed "special" and "unspecial" declarations
by pushing a block similar to what a lambda-binding would do, and
how the interpretation of a variable reference was resolved by comparing
"declarational level number" with "binding level number".  It was full
of cute little acronyms, for which I can blame GLS.

I vaguely remember some flaming about LOCAL declaration being unnecessary
because, unlike in MacLisp, the SPECIAL declaration of Common Lisp wasn't
to be pervasive.  As you say, I think the "flamers" totally blew it because 
of not understanding the difference between DECLARE and PROCLAIM.


-- JonL --



P.S. The technique described in the above-mentioned paper was strictly
     for a shallow-bound, non-parallel implementation.  I don't think
     I see how to generalize it otherwise.

∂30-Apr-87  1425	Masinter.pa@Xerox.COM 	Re: status of DEFVAR-INIT-TIME  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87  14:25:21 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 14:26:24 PDT
Date: 30 Apr 87 14:26 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: status of DEFVAR-INIT-TIME
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 29 Apr 87 12:43 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <870430-142624-4291@Xerox>

I support DEFVAR-INIT-TIME as submitted.

If there is no objection, we can release it as is.


∂30-Apr-87  1429	Masinter.pa@Xerox.COM 	Re: Procedure for Steele's proposed clarifications  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87  14:29:41 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 30 APR 87 14:29:41 PDT
Date: 30 Apr 87 14:31 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Procedure for Steele's proposed clarifications
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 29 Apr 87 13:08 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <870430-142941-4301@Xerox>

Many of the issues that are before us occured in Steele's list of
proposed clarifications, and, even though simple at first glance, seemed
to require the full-blown form.

If there is a subset of the clarifications which we can agree on without
discussion, then I'd be happy to proceed with them; if we all agree, we
can just submit them as a set of "obvious clarifications". I'm a little
skeptical that there are many like that. Do you have some candidates in
mind?




∂30-Apr-87  1459	Masinter.pa@Xerox.COM 	Re: Status of IGNORE-ERRORS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87  14:59:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 15:00:12 PDT
Date: 30 Apr 87 14:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Status of IGNORE-ERRORS
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 29 Apr 87 16:25 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu, Daniels.pa@Xerox.COM
Message-ID: <870430-150012-4352@Xerox>


The only thing hanging up the signalling proposal is that that committee
(and mainly Kent Pitman) needs to bring it up before the next X3J13. It
is an excellent proposal  and we should adopt it and get on with it.
There's no point in adopting IGNORE-ERRORS when we could get the whole
thing.

This was originally my paraphrase of Pavel's comments, but I've really
written what I think. At the meeting before X3J13 you were pretty
mysterious about your reasons for thinking the error proposal would take
too long, or longer than this committee would take. 

Comments?



∂30-Apr-87  1502	Masinter.pa@Xerox.COM 	Re: IF-BODY (Version 5)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87  15:01:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 15:00:55 PDT
Date: 30 Apr 87 14:53 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: IF-BODY (Version 5)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 29 Apr 87 16:37 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <870430-150055-4353@Xerox>

In the interest of getting this out of our hair, I think we could
release it as is. As a point for future proposals, I would like to
discourage "status quo" alternatives in enhancement proposals, since
every proposal has an implicit "status quo" alternative, and some of the
arguments are redundant.  I had expected you would just elaborate in the
Discussions section, but ... whatever ...

Sometimes this process seems so mind-numbingly bureaucratic...

∂30-Apr-87  1638	edsel!bhopal!jonl@navajo.stanford.edu 	Issue: PROCLAIM-LEXICAL   
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87  16:38:24 PDT
Received: by navajo.stanford.edu; Thu, 30 Apr 87 16:37:55 PDT
Received: from bhopal.edsel.com by edsel.uucp (2.2/SMI-2.0)
	id AA06279; Thu, 30 Apr 87 16:13:47 pdt
Received: by bhopal.edsel.com (3.2/SMI-3.2)
	id AA01123; Thu, 30 Apr 87 16:11:01 PDT
Date: Thu, 30 Apr 87 16:11:01 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8704302311.AA01123@bhopal.edsel.com>
To: navajo!JAR%AI.AI.MIT.EDU@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu,
        navajo!KMP%MX.LCS.MIT.EDU@navajo.stanford.edu
In-Reply-To: Jonathan A Rees's message of Wed, 29 Apr 87 22:53:15 EDT
Subject: Issue: PROCLAIM-LEXICAL


Re: KMP doesn't suggest ADDING a global lexical environment; the global
    lexical environment is already there in the GENERAL and RESTRICTED
    proposals.  He merely suggests making it not be identical to the global
    dynamic environment.  This would make a total of 4 environments, not 3.
Since this "global lexical" environment isn't to be identical with the
"global fluid" environment, then it's a "new" environment as far as
Common Lisp is concerned;  that's why I said he was "adding" something.
With respect to environments for a "free variable" reference, there are3, 
not 4, possibilities.  A lexically-bound variable isn't free, and hence 
not, I thought, of concern to this discussion [which was opened up by your 
attempt to clarify the semantics of free variables].

Have I misread anything here?  Your proposals were clearly worded enough; 
I only wanted to bring up an objection to the idea of having two totally 
distinct global environments.  I think calling it an "addition" or not
is a really minor point.


Re: . . .   I see no reason
    to impose this restriction, and I see Scheme compatibility as a big
    reason that we SHOULD allow lambda-binding variables which have global
    bindings.   . . . 
I think you misread this completely backwards.  It WASN'T that you couldn't 
lambda-bind anything that had a binding in the global environment.  It WAS 
that you couldn't lambda-bind anything that was explicitly declared or
proclaimed GLOBAL rather than SPECIAL (or LOCAL?).  

In an implementation where the global fluid environment is the same as 
the top-level environment (the standard state for virtually all deep 
and shallow bound Lisps -- but not for Lisp 1.5), then a SETting
of any variable without a dynamically intervening lambda-binding would
just make a global/top-level binding.  This would happen independently 
of whether the variable was proclaimed GLOBAL or SPECIAL.  But a variable
delcared GLOBAL would only affect the top-level binding; not any 
intermediate SPECIAL lambda-bindings.

Do you see the difference here? or does this point need more explication?


-- JonL --

∂30-Apr-87  1818	Masinter.pa@Xerox.COM 	Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Apr 87  18:18:19 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 APR 87 16:46:05 PDT
Date: 30 Apr 87 16:48 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: cl-cleanup@sail.stanford.edu, Dave.Touretzky@C.CS.CMU.EDU
Message-ID: <870430-164605-4496@Xerox>

fyi, this is the reaction from our local array expert...


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

Date: 30 Apr 87 15:07 PDT
From: Pedersen.pa
Subject: Re: [Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>:
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)]
In-reply-to: Masinter.pa's message of 30 Apr 87 14:17 PDT
To: Masinter.pa
cc: pedersen.pa

	Don't really like either proposal -- because they seem like hacks
rather than a serious approach to the problem. Also, Common Lisp is
already over-bloated, it just doesn't need creeping featurism -- but
rather a trimming down. After all -- these proposals simply relieve the
user of the very minor chore of making displaced arrays for the rare
instances where that is the natural thing to do -- no real value is
added, but there is a cost in complexity, and possibly performance.
	The truth is that if you really want to do multi-dimensioned array
manipulation, you really do want something like APL, or close to it.
Implementing an array calculus -- like APL -- is quite doable (I have
something close to that floating around), and is the right way to go for
heavy array users, but I don't think that functionality needs to be
built into the language.

					J.P.

     ----- End Forwarded Messages -----

∂30-Apr-87  1901	JAR@AI.AI.MIT.EDU 	Issue: PROCLAIM-LEXICAL   
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 30 Apr 87  19:01:20 PDT
Date: Thu, 30 Apr 87 22:03:41 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Issue: PROCLAIM-LEXICAL
To: edsel!bhopal!jonl@NAVAJO.STANFORD.EDU
cc: KMP@AI.AI.MIT.EDU, CL-Cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of Thu 30 Apr 87 16:11:01 PDT from edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)
Message-ID: <193809.870430.JAR@AI.AI.MIT.EDU>

    Date: Thu, 30 Apr 87 16:11:01 PDT
    From: edsel!bhopal!jonl at navajo.stanford.edu (Jon L White)

    With respect to environments for a "free variable" reference, there are3, 
    not 4, possibilities.  A lexically-bound variable isn't free, and hence 
    not, I thought, of concern to this discussion [which was opened up by your 
    attempt to clarify the semantics of free variables].

OK, I see.  "Free" means lexically free.

    Re: . . .   I see no reason
        to impose this restriction, and I see Scheme compatibility as a big
        reason that we SHOULD allow lambda-binding variables which have global
        bindings.   . . . 

    I think you misread this completely backwards.  It WASN'T that you
    couldn't lambda-bind anything that had a binding in the global
    environment.  It WAS that you couldn't lambda-bind anything that was
    explicitly declared or proclaimed GLOBAL rather than SPECIAL (or
    LOCAL?).

Since you are implicitly proposing a third kind of declaration (GLOBAL,
in addition to SPECIAL and my proposed LEXICAL), I take this as an
implicit criticism of the proposal; you must consider it inadequate or
else you wouldn't be suggesting this new and different idea.  I'm
wondering what
  (PROCLAIM '(GLOBAL ...))
gives you that
  (PROCLAIM '(LEXICAL ...))
doesn't.  Forgetting our differences in conceptual model and terminology
for the moment, the ONLY difference I see between these (assuming the
RESTRICTED proposal), either semantically and pragmatically, is that a
variable that proclaimed GLOBAL cannot be lexically lambda-bound.
Therefore I don't see what GLOBAL adds to my proposal or why you are
suggesting that it's a good idea.  (Certainly in the absence of
(PROCLAIM '(LEXICAL ...)), it is a good idea.)

I.e. I don't see how your "global" variables are different from my
"global lexical" variables.

Getting back to terminology: why do you think LOCAL is a better name
than LEXICAL?  LEXICAL seems more general and more descriptive to me, as
long as you buy the idea that there is such a thing as a top-level
(global) environment, which serves as BOTH the top-level lexical
environment and as the top-level dynamic environment (unless KMP has his
way).

Jonathan

∂01-May-87  1536	edsel!bhopal!jonl@navajo.stanford.edu 	Issue: PROCLAIM-LEXICAL   
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87  15:36:11 PDT
Received: by navajo.stanford.edu; Fri, 1 May 87 15:35:37 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA09971; Fri, 1 May 87 13:15:07 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA00639; Fri, 1 May 87 13:12:21 PDT
Date: Fri, 1 May 87 13:12:21 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705012012.AA00639@bhopal.edsel.uucp>
To: navajo!JAR%AI.AI.MIT.EDU@navajo.stanford.edu
Cc: navajo!KMP%AI.AI.MIT.EDU@navajo.stanford.edu,
        navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: Jonathan A Rees's message of Thu, 30 Apr 87 22:03:41 EDT
Subject: Issue: PROCLAIM-LEXICAL

I believe that the deep-binders would be satisfied with top-level 
environment being called "global lexical", providing that the "global 
special" (or, "global fluid" if you will) is the same.  The main issue 
is: What does a special reference mean when there is no dynamically 
intervening special binding?   Is it ok for it to access the "global
lexical" binding?  I wouldn't want to go so far as to make an alternative 
proposal, providing you agree that this is no problem with the single
top-level environment.   [Larry -- could you volunteer some opinion?
This issue will probably affect Xerox's Lisp the most?].  

Re: Getting back to terminology: why do you think LOCAL is a better name
    than LEXICAL?  LEXICAL seems more general and more descriptive ...
To me, "lexical" means "lexically apparent", or "lexically constrained".
In the example:
     (DEFUN FOO (X) (DECLARE (SPECIAL X))  (LIST (BAR X) (BAR X)))
both instances of "X" in the calls to "BAR" are "lexical" with respect
to its binding;  but "X" isn't lexically bound, it is dynamically bound.
[Note also; it is not "free".]   Consider the (free) occurances of "X" in 
some other module, which in fact might access the value of this binding; 
they are not "lexically apparent".  For this reason -- wanting to talk 
about lexical context and not imply anything about the bindings of 
variables therein -- I tend to prefer another term for the opposite of 
SPECIAL.  But I'm not at all enamored with the term LOCAL, or even
UNSPECIAL;  LEXICAL would be ok as long as the documentation clearly 
stressed this point.  


-- JonL --




∂01-May-87  1656	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87  16:56:31 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130001; Fri 1-May-87 19:56:58 EDT
Date: Fri, 1 May 87 19:56 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu, Dave.Touretzky@C.CS.CMU.EDU,
    Pedersen.pa@Xerox.COM
In-Reply-To: <870430-164605-4496@Xerox>
Message-ID: <870501195646.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 30 Apr 87 16:48 PDT
    From: Masinter.pa@Xerox.COM

    fyi, this is the reaction from our local array expert...
    ...
    Date: 30 Apr 87 15:07 PDT
    From: Pedersen.pa

    ... they seem like hacks rather than a serious approach to
    the problem. ...

My guess is that it looks hackish more from a historical perspective
than it would if you just saw a new edition of the manual that didn't
refer to these as sequence functions. Surely if you were just told from
scratch that arrays were valid arguments to MAP or COUNT, you wouldn't
have thought it even remotely hackish. You'd likely say: "Of course."

I think your view may be skewed by feeling like we'll still have a sequence
functions chapter that will say "Oh, by the way, as a special case, MAP
and count will treat arrays as sequences displaced to their storage."
The argument about displacement is the rationale for the argument (and
for why it won't be efficient) more than advice for how the result might
be presented in the manual.

    Pedersen: ... these proposals simply relieve the user of the very 
    minor chore of making displaced arrays for the rare instances where
    that is the natural thing to do -- no real value is added, ...

Actually, I bet some people don't ever used displaced-arrays because
they seem like excess hair and/or because the side-effect consequences
are hard to learn about. RPLACA and RPLACD are hard to learn, but they
are taught about in lots of classes and lots of books so people
eventually catch on.  Displaced arrays may be taught in some thorough
courses and one or two advanced books, but I bet are largely overlooked.

Not to mention the fact that they inherently seem to violate an
abstraction and some people might avoid them because of some feel that
programs which use them are not clean.  On the other hand, there's
nothing even remotely unclean about using an operator like MAP or COUNT
on an array if that operator is willing to do the work for you. It's
not the machine instructions that count, it's what the program has to
say in order to make the machine instructions get executed that's of
interest.

    Pedersen: ... but there is a cost in complexity, ...

I'd find it easier to remember a rule saying that "SUBSTITUTE does 
top-level substitution in aggregate quantities" than one that says
"SUBSTITUTE does top-level substitution in vectors" because
"aggregate quantities" is a natural concept that I've been dealing
with for much longer than programming and "vector" is a domain 
specialized (and in this case very arbitrary) restriction on that
natural concept. I'd consider it a simplification if SUBSTITUTE worked
on arrays.

    Pedersen: ... and possibly performance. ...

I bet the performance hit is not remarkably large...
 * I'd think compilers which can optimize these function calls
   based on declarations could optimize this new case just as easily.
 * Some implementations do microcode dispatch, so they don't have to
   worry. Of the others, though, I'd bet most do a sequential type
   dispatch that falls through to an error clause. If you put the
   general array case right before the error clause, it's not costing
   anyone but the people who want it (because they have to wade through
   the other cases).
 * Even so, since it's a constant-time operation to do this algorithm
   selection and since all of these operations involve loops, the
   performance hit even if you took one would be likely to get lost
   in the dust.
 * Touretzky effectively argues that there may be a speed improvement
   because you can just check for type ARRAY and not check that it's
   only a 1d array and go straight to business playing with its 
   elements. In some cases, this can speed things up by making it
   possible to remove code that did what he is suggesting are
   "gratuitous" error checks.

    Pedersen: ... The truth is that if you really want to do 
    multi-dimensioned array manipulation, you really do want something
    like APL, or close to it. Implementing an array calculus -- like APL
    -- is quite doable ... and is the right way to go for heavy array users ...
    
Well, of course, Touretzky says outright in the proposal that he realizes
this is a harder problem and that he doubts that we would be interested 
in solving that, but that the solution to the simpler problem would be
significantly interesting to him certainly and perhaps to others (a 
claim that I think he gives a credible case for).

Moreover, the more interesting case is for people who are -not- heavy
array users. They just have one array and they're in some place where they
want to count certain elements. Having to write a routine to do this can
distract from the true purpose of the function, which may be unrelated
to the array issue.

I was recently looking back over a lot of old Maclisp code I wrote
around 1979-80. I was struck by the number of times I'd written utility
functions that got used only once -- many things that now are (fortunately)
available in the system. Getting up to a conversational level with Lisp
took most of the effort -- the programs were trivial by modern standards.
I had friends who wrote shorter (but I'd say less intelligible) programs
where they didn't take the time to abstract things out and so in the
middle of some program there'd be a couple of nested DO loops taking the
MAX of something which was not very relevant in the grand scale of things,
but which took up a lot of syntactic space.

I think it's reasonable for us to consider minor extensions that aid
this end of just making certain utilities be common so that they needn't
be written be written time and time again unnecessarily. I think this is
what Common Lisp is about.

∂01-May-87  1933	FAHLMAN@C.CS.CMU.EDU 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87  19:33:01 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 May 87 22:34:05-EDT
Date: Fri, 1 May 1987  22:34 EDT
Message-ID: <FAHLMAN.12299038089.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: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
In-reply-to: Msg of 21 Apr 1987  15:51-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


    I have had applications which for various reasons I can't go
    into in detail where I needed to have a keyword which no one
    but myself would use.

Come on, doesn't anyone have a short, coherent example that demonstrates
the need for a non-keyword as a "keyword" argument?  If the goal is to
have publically accessible functions that take hidden arguments, I'd
like to see an explanation of the need for this.  Seems to me like a
pretty bogus way to do encapsulation, but maybe I'm missing something.

Testimonials are fine, but it's going to be hard to sell this proposal
without a coherent explanation.

-- Scott

∂01-May-87  1947	FAHLMAN@C.CS.CMU.EDU 	ADJUST-ARRAY-NOT-ADJUSTABLE 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87  19:47:18 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 May 87 22:48:23-EDT
Date: Fri, 1 May 1987  22:48 EDT
Message-ID: <FAHLMAN.12299040692.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: ADJUST-ARRAY-NOT-ADJUSTABLE
In-reply-to: Msg of 22 Apr 1987  16:51-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


I don't like this proposed extension.  It seems confusing and dangerous
to do the destructive operation in some cases and a copy in other cases.

I think that I would be more comfortable with some sort of COPY-ARRAY
function, though I'd need to see the details in order to be sure.

-- Scott

∂01-May-87  2030	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87  20:29:55 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130098; Fri 1-May-87 23:30:18 EDT
Date: Fri, 1 May 87 23:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
    Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12299038089.BABYL@C.CS.CMU.EDU>
Message-ID: <870501233004.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I have a Version 2 of this issue waiting for Moon to look it over before sending it
out. The following text is excerpted from that proposal. Does it look any better
to you?

Rationale:

  By allowing symbols other than keyword symbols as keywords, we provide
  a more private communication channel between functions.

  Also, applications such as the emerging object-oriented standard which
  must reliably merge keywords coming from different sources (some internal
  and some user-supplied) can work more reliably by exploting this new
  partitioning of keyword names. For example, a public routine MAKE-FOO
  might need to accept arbitrary keywords from the caller and might want
  to pass those keywords along to an internal routine using keywords of
  its own.

  For example,
   (IN-PACKAGE 'SYSTEM)
   (DEFUN MAKE-INSTANCE (TYPE &REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
     (APPLY #'MAKE-INSTANCE-INTERNAL TYPE 'EXPLICIT T KEYWORD-VALUE-PAIRS))
  This could be done without fear that the use of EXPLICIT T would override
  some keyword in keyword-value-pairs since the only way that could happen
  is if someone had done (MAKE-INSTANCE 'ZEBRA 'SYSTEM::EXPLICIT NIL), or
  if the user was programming explicitly in the SYSTEM package, either of 
  which is an implicit admission of willingness to violate SYSTEM's modularity.

∂01-May-87  2037	FAHLMAN@C.CS.CMU.EDU 	UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87  20:37:07 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 1 May 87 23:26:54-EDT
Date: Fri, 1 May 1987  23:26 EDT
Message-ID: <FAHLMAN.12299047704.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: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
In-reply-to: Msg of 23 Apr 1987  02:07-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


    Larry's status report says that this issue has been agreed...
    I never agreed to this, and I think you are overlooking something.

Well, it should have been "agreed by those present at the pre-X3J13
meeting", I guess.

    Therefore I propose that case 1, transfer to a point inside the point to
    which control would have transferred, not do the second throw.  There
    are two things we could require it to do instead (or we could just
    wimping out and say it "is an error").  It could signal an error, or
    it could resume the original throw, just as if the cleanup handler had
    exited normally.  I prefer signalling an error, because I firmly believe
    that the program is ill-formed.

I think you've spotted a case that the rest of us missed.  At least, it
didn't come up in earlier discussion.  I'm not completely sure what is
right, but I'm inclined to agree that "signals an error" is the right
thing here, rather than just allowing the throw whose tag is outermost
to win.  I've got a hunch that trying to do the latter would just
introduce another layer of subtle problems.

    Note that signalling an error must
    avoid the following pitfall once an error-handling facility is added to
    Common Lisp:

      (loop
        (ignore-errors
          (unwind-protect (loop)
            (error))))

    The illegal-nested-throw error must not be caught by ignore-errors or
    nothing will have been solved.

I guess we need a class of errors that don't get ignored, despite the
user's instructions.  There are probably some other members of this
class.  Some asynchronous things that have nothing to do with the code
inside the IGNORE-ERRORS form might qualify: system almost out of
memory, memory error, and stuff like that.

-- Scott

∂01-May-87  2115	FAHLMAN@C.CS.CMU.EDU 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87  21:15:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 00:16:48-EDT
Date: Sat, 2 May 1987  00:16 EDT
Message-ID: <FAHLMAN.12299056786.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: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
In-reply-to: Msg of 1 May 1987  23:30-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


Yeah, that's the sort of example I was looking for.  I see what you're
driving at now, but the example of Make-Instance doesn't seem terribly
compelling.  One might question whether this is the best way, or even a
reasonable way, to pass this collection of stuff on to
Make-Instance-Internal.  Why pass Explicit as a keyword at all?  Why not
as a required arg, since the target function has to be ready to handle
Explicit in any event.  Seems like you're just muddling things together
and that the callee will have to un-muddle them again.

In any event, I suppose that this is a legitimate style, even though I
think it is ugly and probably inefficient.  Since the proposed change is
fairly harmless, this example probably provides enough motivation for it.

-- Scott

∂01-May-87  2128	FAHLMAN@C.CS.CMU.EDU 	Issue DEFVAR-INIT-TIME (Version 1)    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 1 May 87  21:27:55 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 00:29:01-EDT
Date: Sat, 2 May 1987  00:28 EDT
Message-ID: <FAHLMAN.12299059010.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 DEFVAR-INIT-TIME (Version 1)
In-reply-to: Msg of 23 Apr 1987  16:59-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


This looks OK to me.

I believe that the cause of the confusion is really the statement that
the initial value form is not evaluated unless "it is used".  Better to
say that INITIAL-VALUE is evaluated if and only if the variable does not
already have a value.  Then I think that there would be no confusion
about the time of evaluation, though it can't hurt to spell this out
explicitly.

-- Scott

∂01-May-87  2145	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 May 87  21:44:57 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 130133; Sat 2-May-87 00:45:09 EDT
Date: Sat, 2 May 87 00:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Revision 1)
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12299056786.BABYL@C.CS.CMU.EDU>
Message-ID: <870502004454.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Sat, 2 May 1987  00:16 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    ... One might question whether this is the best way, or even a
    reasonable way, to pass this collection of stuff on to 
    Make-Instance-Internal.  Why pass Explicit as a keyword at all?  Why not
    as a required arg ...

What if MAKE-INSTANCE-INTERNAL takes 47 such internal keywords? Just
because I only used one in the call doesn't mean that's all it receives.
Would you have me pass all 47 internal arguments on every call?

Also, the caller of MAKE-INSTANCE might be within package SYSTEM and so
it might not be an abstraction violation for him to pass other packaged
symbols. That means that more keywords than those you see might be being
received in the main arglist, though presumably none that the caller
worries are going to be overridden by MAKE-INSTANCE.

Or there might be other situations in which keyword-style calling is
more important than in the particular call that you have there.

I could add some of these issues to the add rationale, too, if you like.
Almost by definition, any two-line example is not going to leave you
feeling satisfied about something which is claimed to be useful in
complex situations involving modularity boundaries.

Anyway, the fact that you can figure out what is being hinted at by the
small example makes me feel like the example did its job.

∂02-May-87  0707	FAHLMAN@C.CS.CMU.EDU 	DELETE, SORT, ADJUST-ARRAY considered harmful   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87  07:07:29 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 10:08:35-EDT
Date: Sat, 2 May 1987  10:08 EDT
Message-ID: <FAHLMAN.12299164519.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Guy Steele <gls@THINK.COM>
Cc:   cl-cleanup@SAIL.STANFORD.EDU
Subject: DELETE, SORT, ADJUST-ARRAY considered harmful
In-reply-to: Msg of 25 Apr 1987  03:25-EDT from Guy Steele <gls at think.com>


    Well, maybe the proposed syntax stinks, but perhaps some way of
    idiot-proofing destructive operations should nevertheless be found.

Nothing is foolproof because fools are so ingenious.  (Who said that?)

I don't think that it is a good idea to go back and diddle with these
old problems at this point.  Destructive operations on lists are tricky
in N other ways as well, so you've got to stop and think.  I wouldn't
mind a "chatty" compiler mode that warns of a possible problem whenever
it sees a DELETE not in a setting form, but this is not a standards-type
issue.

Since you signed this "Quux", I'll assume that you don't really want to
push it.

-- Scott

∂02-May-87  1143	FAHLMAN@C.CS.CMU.EDU 	IF-BODY (Version 5)    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87  11:42:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 14:43:57-EDT
Date: Sat, 2 May 1987  14:43 EDT
Message-ID: <FAHLMAN.12299214648.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: IF-BODY (Version 5)
In-reply-to: Msg of 27 Apr 1987  18:21-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


I hate to keep beating on this, but we're working on developing internal
procedures for handling controversial cases, and it probably is worth
trying to debug these procedures on a stupid case like this before
something really hard comes along.  I think we've got the wrong model
here for dealing with controversial things.  It is unreasonable to ask
one person to produce a balanced presentation that fairly summarizes all
points of view, including views that he disagrees with.

KMP's latest version of the IF-BODY proposal is a case in point.  It
represents a good-faith attempt on his part to present a balanced
discussion of the issues, but the result is nevertheless unbalanced in
subtle ways toward his point of view.  I'm not trying to dump on KMP
here -- if I had written the summary, I'm sure it would be even more
biased the other way.

KMP states at the outset that some implementations, if allowed to, will
implement this extension, and that these extended implementations will
"typically" not generate a warning.  Later he argues that encouraging
(but not requiring) a warning is inadequate, because an implementation
that adds this feature must think it is a good idea, and you don't warn
about good ideas.  This ignores the possibility of a "warn me about any
non-portable code" compilation mode, which is the right solution
(assuming this IF-BODY problem is troublesome enough that it is worth
fixing at all).  If an implementor doesn't choose to support such a
mode, fine; that's between him and his customers.  But don't ask the
rest of us to mess up the language in order to make that
implementation's users more comfortable -- if the vendor doesn't want to
employ the obvious simple technique for solving this problem, then it
presumably isn't worth solving.  I've stated this view N times before
and this "somebody prepare a summary" process keeps eviscerating the
argument.  Again, it is the process that is at fault, not the people
doing the summarizing.

It seems to me that the process should go something like this: Person X
proposes a compatible extension.  If, after some discussion, consensus
is reached on some (possibly amended) version of the extension, we put
that version forward as a proposal, with some sort of joint rationale in
the discussion section.  If the committee doesn't like the proposal and
can talk the proposer into dropping it, fine, we drop it.  If there is
no consensus in favor of the change, but the proposer wants to present
the matter to the full X3J13, then he should prepare the most persuasive
argument he can muster -- none of this "balance" stuff.  Then, in the
discussion section, the opposition gets to have its say.  The point is
that each side of the case must be argued by someone who believes in it.
Just like the lawyers.  I suppose that in some cases, there might be
more than one dissenting opinion: various people might dislike a
proposal for different reasons.

There remains the question of who gets the last word.  We could iterate
until quiescence or exhaustion is reached, flip a coin, or establish
some arbitrary guideline.  I guess I'd say that the proposer gets his
say, then the negative voices, and finally the proposer gets a short
rebuttal (confining himself to answering what the opposition said,
rather than introducing new arguments).  The result is concatenated, not
summarized, for presentation to the outside world.

The above assumes that the question is whether or not we should adopt
some change.  In a situation where there are N positive proposals to
choose from, all with their advocates, then a FOO:A, FOO:B, FOO:C
approach is appropriate.  The arguments in favor of each position should
be presented by the advocates of that position, if any exist.  In the
case of a yes/no question, it is silly to have separate FOO:YES and
FOO:NO proposals.

-- Scott

∂02-May-87  1220	FAHLMAN@C.CS.CMU.EDU 	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87  12:20:46 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 15:21:49-EDT
Date: Sat, 2 May 1987  15:21 EDT
Message-ID: <FAHLMAN.12299221539.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: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
In-reply-to: Msg of 28 Apr 1987  14:13-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


I have no strong opinion on this proposal.  It doesn't look to me like
it would add much confusion, it wouldn't be too hard to implement, and
apparently some people would find it useful.  So I guess I'm mildly in
favor of either the GENERALIZE or the MODIFIED version.

I would not like to see this leave committee in the current format.
Maybe KMP, Touretzky, Rees, and anyone else who cares can work out a
single proposal that they all like.  The paths not taken can be
mentioned in the discussion section.

I would like to encourage KMP to go ahead with a separate proposal for
ROW-MAJOR-SUBSCRIPTS (or whatever we end up calling it).  Given that, I
think a version of POSITION that returns a single number for arrays is
probably the way to go, and users can then turn this into a subscript
list if they like.  I have a mild aversion to getting a list from some
function that has heretofore always returned a number or NIL.

In choosing issues to introduce in the future, we probably should lean
toward doing clarifications first and saving extension for later.

-- Scott

∂02-May-87  1313	FAHLMAN@C.CS.CMU.EDU 	Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87  13:13:03 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 16:13:50-EDT
Date: Sat, 2 May 1987  16:13 EDT
Message-ID: <FAHLMAN.12299231012.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: PROCLAIM-LEXICAL
In-reply-to: Msg of 28 Apr 1987  16:35-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>


<Is JAR on CL-CLEANUP now?  If not, we should all include him in the
address list while discussing this.>

I think that this proposal is confused.  The current rule for handling a
reference to a variable that is neither bound nor declared is
unambiguous: the variable is assumed to be special.  There is no
ambiguity and no need for clarification.  Whether we want to change this
is another question, and an interesting one.

      However, if you feed this program to many Common Lisp compilers
      (including Symbolics's and DEC's), a warning message will be
      produced for the SETQ, saying something like "Warning: X not
      declared or bound, assuming special."

      These warnings, unlike the annotations of undefined functions (which
      occur only at the end of a compilation), are presented so
      prominently that a user would be hard put to say that a program
      which elicited such warning messages was "correct" in that
      implementation.  Unlike the situation with unused variables, there is
      no possible declaration one can write which suppresses the warning
      messages.

Not true.  You can suppress this warning by saying (proclaim '(special
<var>)) or (defvar <var>).

In my view (the manual doesn't spell this out, so we rely on shared
culture) a Common Lisp compiler is free to issue a warning any time it
spots anything suspicious, even though the code may be legal.  The more
of this a compiler does, the better it is as a debugging aid (up to the
point where the "crying wolf" effect sets in because too many spurious
warnings are being generated).  The use of an undeclared variable is
legal because users like to do this in the interpreter; in a code file,
on the other hand, it is either very unstylish or, more likely, the
result of a typo.  In the latter case, I want to see a warning.  If you
tell me that I can can't use a warning here because it looks too much
like an error, then I'll have to create yet another kind of compiler
output ("mild suggestion?") with which I can report these things.
I prefer to retain the term warning for this, and to use the term "error"
when there really is an error.

If a fix really is needed here, it should probably be a compiler
declaration that suppresses all warnings in a certain stretch of code.
Then people who hate to see any warnings can get rid of them, and those
of use who use them for debugging can have them.  But I see nothing
unacceptable or even uncomfortable about the status quo.  Probably the
spec should explaint he difference between an error and a warning rather
than leaving this to the reader's imagination.

As a separate issue, we might want to try to hammer out a proposal for
what people have called "global lexicals", and we might even want to
make this the default for undeclared symbols used free.  But we should
not muddle this into a discussion of the current rules or the difference
between warnings and errors in the compiler.

-- Scott

∂02-May-87  1324	FAHLMAN@C.CS.CMU.EDU 	FORMAT-OP-C (Version 2)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87  13:24:02 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 16:25:02-EDT
Date: Sat, 2 May 1987  16:24 EDT
Message-ID: <FAHLMAN.12299233050.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: FORMAT-OP-C (Version 2)
In-reply-to: Msg of 29 Apr 1987  12:38-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


I support this proposl.  I think that the presentation should be
simplified before it goes out.  Most of the lengthy discussion in the
problem description is unnecessary.  This is a simple clarification.

-- Scott

∂02-May-87  1340	FAHLMAN@C.CS.CMU.EDU 	PRINC-CHARACTER (Version 2) 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87  13:30:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 16:31:09-EDT
Date: Sat, 2 May 1987  16:31 EDT
Message-ID: <FAHLMAN.12299234147.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: PRINC-CHARACTER (Version 2)
In-reply-to: Msg of 29 Apr 1987  15:46-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


I favor PRINC-CHARACTER:WRITE-CHAR.

-- Scott

∂02-May-87  1616	JAR@AI.AI.MIT.EDU 	Is JAR on CL-CLEANUP now?  Yes.
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87  16:16:03 PDT
Date: Sat,  2 May 87 19:18:40 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Is JAR on CL-CLEANUP now?  Yes.
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of Sat 2 May 1987  16:13 EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <194617.870502.JAR@AI.AI.MIT.EDU>

I'm on CL-CLEANUP.

∂02-May-87  1655	JAR@AI.AI.MIT.EDU 	Issue: PROCLAIM-LEXICAL   
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87  16:55:26 PDT
Date: Sat,  2 May 87 19:58:08 EDT
From: Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Subject:  Issue: PROCLAIM-LEXICAL
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of Sat 2 May 1987  16:13 EDT from Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>
Message-ID: <194629.870502.JAR@AI.AI.MIT.EDU>

    Date: Sat, 2 May 1987  16:13 EDT
    From: Scott E. Fahlman <Fahlman at C.CS.CMU.EDU>

    Not true.  You can suppress this warning by saying (proclaim '(special
    <var>)) or (defvar <var>).

*Not* not true!  Look again at the example.  If you declare the variable
special, you will change the semantics of the program.  In this example
you would also have to rename every X that's lexically bound; being an
extremely non-local transformation, this is unacceptable.

    In my view (the manual doesn't spell this out, so we rely on shared
    culture) a Common Lisp compiler is free to issue a warning any time it
    spots anything suspicious, even though the code may be legal.

I basically agree with this, but you should note that every other sort
of warning is avoidable.  E.g. an unreferenced bound variable is often a
result of a program error, but when it's not it can be dealt with by
(DECLARE (IGNORE ...)); an OR with only one subform can be a symptom of
a misplaced parenthesis, but where it's the right thing there are ways
to get around the problem (make your macros smarter...).  But in this
case the only way to get rid of the warning is either by
alpha-converting or by making the program possibly incorrect, which is
definitely unfriendly.

I don't know how you develop code, but I like to get my programs into
a condition where they do not elicit warnings from the compiler.

    The use of an undeclared variable is
    legal because users like to do this in the interpreter; in a code file,
    on the other hand, it is either very unstylish or, more likely, the
    result of a typo.  

Why is this any different from an undefined function, which is not
similarly warned about?  I believe these two situations (forward
reference to a variable and to a function) should be treated
symmetrically.

    If a fix really is needed here, it should probably be a compiler
    declaration that suppresses all warnings in a certain stretch of code.

Unacceptable in this case (unless we adopt BY-THE-BOOK); many warnings
are quite desirable.  I would say a warning is OK if either it indicates
that an error will happen at run time, or if the code is truly is dubious
style AND there is an easy way to fix or annotate the code so that the
warning goes away.

    As a separate issue, we might want to try to hammer out a proposal for
    what people have called "global lexicals", and we might even want to
    make this the default for undeclared symbols used free.

If you look at the proposal carefully you'll see that it contains
exactly this; namely, in the GENERAL and RESTRICTED alternatives, you
can do (PROCLAIM '(LEXICAL ...)).  I'm wondering how you missed it,
although if you only looked at the summary at the top and not the rest
of the message, that would explain it; the introduction is admittedly
misleading.  I'll fix that next time around.

Like I said in the "Status:" line, this is very preliminary.

Jonathan

∂02-May-87  1720	FAHLMAN@C.CS.CMU.EDU 	Is JAR on CL-CLEANUP now?  Yes.  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87  17:20:01 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 20:20:35-EDT
Date: Sat, 2 May 1987  20:20 EDT
Message-ID: <FAHLMAN.12299275925.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Jonathan A Rees <JAR@AI.AI.MIT.EDU>
Cc:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Is JAR on CL-CLEANUP now?  Yes.
In-reply-to: Msg of 2 May 1987  19:18-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>


Good.  Wasn't sure if you were seeing things routinely or if KMP was
just passing you selected tidbits.

-- Scott

∂02-May-87  1855	FAHLMAN@C.CS.CMU.EDU 	Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 May 87  18:55:47 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 2 May 87 21:56:52-EDT
Date: Sat, 2 May 1987  21:56 EDT
Message-ID: <FAHLMAN.12299293460.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: PROCLAIM-LEXICAL
In-reply-to: Msg of 2 May 1987  19:58-EDT from Jonathan A Rees <JAR at AI.AI.MIT.EDU>


In reply to JAR:

        Not true.  You can suppress this warning by saying (proclaim '(special
        <var>)) or (defvar <var>).

    *Not* not true!  Look again at the example.
    ...
    I don't know how you develop code, but I like to get my programs into
    a condition where they do not elicit warnings from the compiler.

OK, if you really want to use the same names for your specials and your
lexicals, then indeed there is no good way to get rid of the warning.  I
hardly ever do this, so I missed your point.  When I see that warning in
a case like your example program, it tells me that it's time to rename
something, not that I should find some way to inhibit the warning with a
declaration.

I assume that we're not going to consider any radical proposals for the
handling of specials, such as separating the name spaces by making the
*foo* syntax mandatory for specials.  If we stay close to the status
quo, it seems to me that we really should go ahead and add a LEXICAL
declaration and a LEXICAL proclamation so that those pervasive special
proclamations can be cancelled or shadowed.  I haven't heard any good
arguments against this in the last N years.  The need to eliminate
spurious "not declared or bound" warnings is one argument in favor of
this change, but it would be a useful change for other reasons in any
case.

    Why is this any different from an undefined function, which is not
    similarly warned about?  I believe these two situations (forward
    reference to a variable and to a function) should be treated
    symmetrically.

No difference in principle.  Both conditions are suspicious and worth a
warning, in my view, but how such warnings are handled is up to the
implementor.  It is desirable to emit these warnings when the suspicious
condition is noticed; that way the location of the problem is marked and
the user has the option of aborting the compilation.  In the case of
undefined functions, forward references are particularly common, so most
implementations wait till the end of the compilation before emitting the
warning.  In the case of undeclared specials, there does not seem to be
a good reason to wait, so we warn at once.

        As a separate issue, we might want to try to hammer out a proposal for
        what people have called "global lexicals", and we might even want to
        make this the default for undeclared symbols used free.

    If you look at the proposal carefully you'll see that it contains
    exactly this; namely, in the GENERAL and RESTRICTED alternatives, you
    can do (PROCLAIM '(LEXICAL ...)).  I'm wondering how you missed
    it...

I didn't miss it.  Your GENERAL and RESTRICTED proposals seem to re-open
a debate that we had some time ago on "global" or "global lexical"
variables and what their semantics should be.  A lot of hairy issues
came up in that discussion, and I didn't see those issues being
addressed here.  So my suggestion was that we ought to separate this
issue from the business about inhibiting warnings and try to come up
with a comprehensive proposal on global variables -- comprehensive in
the sense that we try to deal with all the issues raised in the earlier
discussion.

-- Scott

∂04-May-87  1056	Masinter.pa@Xerox.COM 	Issue priority   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 May 87  10:56:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 MAY 87 10:54:17 PDT
Date: 4 May 87 10:56 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue priority
to: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870504-105417-2905@Xerox>

We've been asked by some members of the object proposal to quickly
address the issues that they are waiting on. 

Those issues include:

KEYWORD-ARGUMENT-NAME-PACKAGE

FUNCTION-TYPE

and an issue, currently not written up, on whether the types STREAM,
PACKAGE, PATHNAME,  READTABLE and RANDOM-STATE can be required to be
disjoint from other types (e.g., as if they had been created with
DEFSTRUCT.)


I didn't see any strong objections to these proposals, except for the
way in which they were worded. 

If you'd like to discuss any of these issues, you will make my life
simpler if you will send separate messages about each.


∂04-May-87  1423	KMP@STONY-BROOK.SCRC.Symbolics.COM 	UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 May 87  14:23:05 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 131431; Mon 4-May-87 17:22:42 EDT
Date: Mon, 4 May 87 17:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
To: Fahlman@C.CS.CMU.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12299047704.BABYL@C.CS.CMU.EDU>
References: The message of 23 Apr 1987 02:07-EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
            The message of 29 Apr 1980 16:09-EDT from Jon L White <JONL at MIT-MC>
Message-ID: <870504172241.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Fri, 1 May 1987  23:26 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    In-reply-to: Msg of 23 Apr 1987 02:07-EDT
	         from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>

	...
	Note that signalling an error must
	avoid the following pitfall once an error-handling facility is added to
	Common Lisp:

	  (loop
	    (ignore-errors
	      (unwind-protect (loop)
		(error))))

	The illegal-nested-throw error must not be caught by ignore-errors or
	nothing will have been solved.

Personally, I consider the meaning of this to be well-formed. It'd be
sad for a programmer to get into this, but I think that in this case
the user has pretty clearly asked to have a loop that cannot be exited
and deserves to have that request carried out. 

Consider how ridiculous it would have looked on Star Trek when they
needed to divert the computer's attention and said "Computer, compute to
the last digit the value of pi".  If I recall, Spock makes a remark like
"As you know, the value of pi is a transcendental number without
resolution. ... The computer will work on this problem to the exclusion
of all else ...". Imagine how frustrated he'd have been if the computer
had refused to execute the command because it didn't seem like he really
meant what he said.

Well, ok, so this isn't the most likely scenario. But the truth is,
as Prof. Bill Martin said once in a linguistics class I took from him --
We create syntax in a language not to allow us to say the things that
are obvious, but so that we can say things that are not obvious. If we
didn't need to say things that were not obvious, we'd just jumble all
the words together and assume people would figure out some uniquely 
determined, obviously useful interpretation. In fact, we make careful
rules to allow us to say bizarre things not so we can say bizarre things
all the time, but so that if there comes a time to say such things, we
won't be at a loss for words.

By the way, I did once write a CL program that wanted the semantics that
Moon claims are implausible. In Common Lisp, there was no portable way to
make a Lisp have a Macsyma toplevel (ie, where the vendor's abort character
would return me to Macsyma and not to Lisp). So I wrote something which did
effectively:
 (DEFUN MACSYMA-TOPLEVEL ()
   (PROG ()
     LOOP (UNWIND-PROTECT (REALLY-MACSYMA-TOPLEVEL)
			  (GO LOOP))))
so that people who'd invoked Macsyma toplevel couldn't get back to toplevel
lisp. So while it might be rare, it's not unthinkable that someone could really
write this and mean what they said...

As such, I don't rate this desire to let the user intervene at the same
level of importance that Moon does. However, since I do find it an
interesting issue, I'm willing to entertain the issue for discussion
for now without prejudice to its ultimate importance.

    I guess we need a class of errors that don't get ignored, despite the
    user's instructions.  There are probably some other members of this
    class.  Some asynchronous things that have nothing to do with the code
    inside the IGNORE-ERRORS form might qualify: system almost out of
    memory, memory error, and stuff like that.

If we did make this illegal, I'm curious exactly what Moon would want to
have happen here. The most plausible scenario I can come up with that fits
in this hypothetical framework is the following (which is essentially like
what Scott is suggesting) ...

 THROW could notice that it was going to THROW to a point inside
 a THROW which was already active. At this point, it could signal
 a SERIOUS-CONDITION (some type which was not a subtype of ERROR),
 so that IGNORE-ERRORS did not catch the condition, but that did
 have a default handler that would force entry into the debugger.
 This would allow an opportunity for user-intervention.

 The debugger could offer options which should include:

   * Going ahead with the inner THROW (and discarding the outer
     THROW attempt).

   * Exiting from this UNWIND-PROTECT cleanup body and continuing
     the ongoing THROW.

   * Blowing away the process without running its UNWIND-PROTECT
     cleanups.

 This would allow for user intervention without precluding what
 I believe to be the clean semantics (choice C). I'm suspicious
 of any choice which doesn't even allow the user to get style-C
 semantics if that's what he wants.

Dave, is this the sort of thing you're proposing? If not, could
you please sketch what you are suggesting for contrast?

By the way, I ran across the following piece of mail the other day
while looking around for something else. I just thought you'd be
interested to know that this problem is as old as UNWIND-PROTECT
itself; the message is from only a few days after UNWIND-PROTECT
was first installed in Maclisp and although the bug is not like
the one we're discussing, the test scenario is a lot similar to
the code sketch Moon did above...

-----Forwarded Message Follows-----
Date: 29 April 1980 16:09-EDT
From: Jon L White <JONL at MIT-MC>
To: KMP at MIT-MC, RWK at MIT-MC
cc: BUG-LISP at MIT-MC
Subject: UNWIND-PROTECT

On the 15th of Feb, KMP sent out a bug notice about UNWIND-PROTECT
losing, for which I made the diagnosis that ERRSET was not saving
and restoring the UNREAL flag. The test case is
 (DEFUN KMP-LOSES () (ERRSET (UNWIND-PROTECT NIL (OPEN '((DSK BOO) BAR BZ)))))
Well, I found a way to fix ERRSET without taking more pdl locations,
and the assembled code (already initialized) is on LISP;BBLISP 995QIO.
...

∂04-May-87  1919	FAHLMAN@C.CS.CMU.EDU 	Issue priority    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 4 May 87  19:19:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 4 May 87 22:18:19-EDT
Date: Mon, 4 May 1987  22:18 EDT
Message-ID: <FAHLMAN.12299821653.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 priority
In-reply-to: Msg of 4 May 1987  13:56-EDT from Masinter.pa at Xerox.COM


    KEYWORD-ARGUMENT-NAME-PACKAGE

I believe that KMP is working on a version that explains why a change is
needed.  The lack of such an explanation was my only real objection.

    FUNCTION-TYPE

On my queue, but I've got a funding proposal to get out by the end of
the week, so this stuff won't get worked on until next weekend.  If
anyone else can grab it sooner, feel free.

    and an issue, currently not written up, on whether the types STREAM,
    PACKAGE, PATHNAME,  READTABLE and RANDOM-STATE can be required to be
    disjoint from other types (e.g., as if they had been created with
    DEFSTRUCT.)

I don't think we currently require structures to be a disjoint
type from vectors, etc., though this has been talked about.  So that
should be part of any proposal.

∂05-May-87  1416	pedersen.pa@Xerox.COM 	Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2) 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 May 87  14:15:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 MAY 87 14:15:02 PDT
Date: 5 May 87 14:14 PDT
From: pedersen.pa@Xerox.COM
Subject: Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 1 May 87 19:56 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: Masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu,
 Dave.Touretzky@C.CS.CMU.EDU, Pedersen.pa@Xerox.COM
Message-ID: <870505-141502-1099@Xerox>

Pitman: 
	"Actually, I bet some people don't ever used displaced-arrays because
	they seem like excess hair and/or because the side-effect consequences
	are hard to learn about. ... Displaced arrays may be taught in some
thorough
	courses and one or two advanced books, but I bet are largely
overlooked...
	Not to mention the fact that they inherently seem to violate an
	abstraction and some people might avoid them because of some feel that
	programs which use them are not clean."


I find a certain inconsistency in your argument that constructing
displaced-arrays is obtuse and unesthetic, while at the same time
stating that multi-dimensional arrays are naturally operated on as
vectors with elements laid out in row-major order. After all,
displaced-arrays are the only mechanism in common lisp that allows one
to adopt that view, and as such are indispensible. Indeed, one might
argue that for the inexperienced Lisp user, who has some knowledge of
"C" or "FORTRAN", displaced-arrays map directly into conventional use of
pointers into arrays.

On a more constructive note -- it seems like a small addition to the
array mechanism might address most of our concerns. Consider:

(defun flatten-array (array) 
	(cond ((vectorp array) array)
		((arrayp array) 
			(make-array (array-total-size array) 
				:element-type (array-element-type array)
				:displaced-to array))
		(t (error "Not an array: ~s" array))))

then "flatten-array" may be used in combination with sequence functions
to achieve the desired semantics, and would have the advantage of making
clear the intention of a code fragment. A primitive like "flatten-array"
is useful in other contexts as well, and would complement a
"row-major-aref" primitive.


							J.P.

∂10-May-87  1154	FAHLMAN@C.CS.CMU.EDU 	[RAM: exiting from unwind protects]   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 May 87  11:54:48 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 10 May 87 14:54:06-EDT
Date: Sun, 10 May 1987  14:54 EDT
Message-ID: <FAHLMAN.12301313646.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: [RAM: exiting from unwind protects]


I find the following pretty persuasive...

Date: Saturday, 2 May 1987  11:16-EDT
From: Rob MacLachlan <RAM>
To:   fahlman
Re:   exiting from unwind protects
ReSent-Date: Sun 10 May 87 10:56:56-EDT
ReSent-From: Rob.MacLachlan@C.CS.CMU.EDU
ReSent-To: fahlman@C.CS.CMU.EDU
ReSent-Message-ID: <12301270482.15.RAM@C.CS.CMU.EDU>

I don't really agree with Moon about this thing.  I certainly knew about
about the feature of being about to write something that you can't exit
from using any common lisp facility, but I don't see this as a
"serious environment bug".  Our system has always has this property.
When someone first pointed out this property of Common Lisp way back
when, I did in fact write the pathological example and it did in fact
behave in the pathological fashion.  After a while I got bored of
trying to throw out of the break loop, and I quit.

If I had really been doing anything, I could always have skipped over
the losing frame using debug-return.  Environment problems can have
environment solutions.  In any case, I could have saved work I was
doing from the break loop.  This feature certainly isn't a big deal;
there are lots of ways a malicious Lisp user can blow the system out
of the water.  What happened the last time you did 
(makunbound '*terminal-io*)?

In contrast, it seems to me that all the "fixes" for this problem
result in substantial increases in the complexity of the language
defintion for no gain.  It seems that Moon has already introduced
three new things into the language:
 1] The concept of "throwing out of an unwind protect cleanup".  When
    are you in an unwind protect?  What does it mean to throw out of
    it?  Does this apply to lexical exits too?  Does this signal an
    error?
      (block block
        (unwind-protect <foo>
          (return-from block)))
    Does this?
      (unwind-protect <foo>
        (block block
          (return-from block)))

 2] The concept of errors that aren't errors, which we need so that
    users can't screw themselves with this feature no matter how hard
    they try.

 3] The implicit requirement that an implementation have some exit
    mechanism other than throw so that it can unwind out of cleanup
    forms even if the user can't.  What does the system do when you
    are running in an unwind protect and the user types an interrupt?
    In fact, it seems that Moon is being inconsistent here, since he
    has already assumed that interrupts do throw.  If the user
    interrupts when running in a cleanup do you signal an error, and
    then signal an error whenever the user tries to abort out of the
    debugger?

If I had ever been screwed by this, I would think differently.  I'm
sure that most of the reason that this problem doesn't happen is that
people usually don't write code that aborts from unwind protect
cleanups.  There is a big difference between saying that something is
rarely needed and possibly dangerous and saying that it must signal an
error.

I am convinced that the simplest evaluation model is to say that the
unwind-protect cleanup is evaluated in the lexical and dynamic
environment of the unwind-protect form.  Any alternative must somehow
introduce an "in an unwind protect cleanup" marker into the dynamic
environment of the cleanup forms.

  Rob

∂11-May-87  1051	RPG   	Draft of revised FUNCTION-TYPE   
 ∂10-May-87  1852	FAHLMAN@C.CS.CMU.EDU 	Draft of revised FUNCTION-TYPE   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 May 87  18:52:19 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 10 May 87 21:51:36-EDT
Date: Sun, 10 May 1987  21:51 EDT
Message-ID: <FAHLMAN.12301389651.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   rpg@SAIL.STANFORD.EDU
Cc:   masinter.pa@XEROX.COM
Subject: Draft of revised FUNCTION-TYPE


Dick,

I said I'd give you a shot at this before sending it to the whole
Cleanup list.  Want to make a pass and see if this captures what we all
agreed to.  I'm not too confident of my ability to use the right terms
for these lexical variables and things, so please keep an eye out for
that.  I'm CC'ing Masinter just so he'll know that progress is
progressing progressively.  It would be good to get thsi out within a
few days, since the CLOS people seem to need this to be settled.

-- Scott
---------------------------------------------------------------------------
To:   cl-cleanup at SAIL.STANFORD.EDU
Re:   Issue: FUNCTION-TYPE (version 3)

Status:		Revised by SEF to reflect intensive discussions prior to the
		last X3J13 meeting.

Issue:		FUNCTION-TYPE
References:   	functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
	      	APPLY (pg 107).
Category:     	CHANGE/CLARIFICATION
Edit History: 	Version 1 by RPG 02/26/87
		Version 2 by cleanup committee 15-Mar-87
		Version 3 by SEF 10-May-83

Problem Description:

The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions.  The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner.  This would also make it easier
to integrate the function type into the CLOS class hierarchy.

The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.

Proposal FUNCTION-TYPE:REDEFINE

1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination.  The list form of the
FUNCTION type specifier may still be used only for declaration.

Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.

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.

No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION.  Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE, and so on.

2. The behvior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)).  In particular, FUNCTIONP is no
longer true of symbols and lambda lists.

3. The descriptions of FUNCALL, APPLY, MAPCAR and all functions in
Common Lisp which take functional arguments are modified to clarify that
they will take either functions, symbols, or lists that represent
lambda-expressions.  A symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used.  Note that this leaves the behavior of FUNCALL, APPLY, MAPCAR,
et al. unchanged, but that their descriptions must be changed to
accommodate the new definition of the FUNCTION type.

4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION.  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.  (Some implementations may
choose not to signal this error for performance reasons.)

5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION).  It is an error to call SYMBOL-FUNCTION on anything
else.  In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.

It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value).  Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.

6. 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".  Change this to the following:

If COMPILE is called with no definition supplied, then it will attempt
to compile the current global definition of the symbol <name>, and will
signal an error if it is unable to do so.  In some implementations, an
interpeted function can be compiled individually only if it contains no
references to lexical context outside the function definition.  If the
symbol's definition is already compiled, no error is signalled.  An
implemenation may choose to recompile the function if the original
interpreted form is available; otherwise, this is a no-op.

Rationale:

This change gives a clean, useful definition to the FUNCTION data type in
Common Lisp and the related type predicates.  Under the current
definition, FUNCTIONP is nearly useless, since it is defined to be true
of all symbols, including those that do not have functional definitions.

Current Practice:

Many programmers find it necessary to write their own predicate
corresponding to the new form of FUNCTIONP.

Adoption Cost:

The type predicates would of course have to be brought into compliance
with this proposal, but that should require little effort.

Compiled functions are true functions in almost all implementations,
but, in some implementations, interpreted functions and closures are
represented as lists.  This would have to be changed in the interpreter,
FUNCALL, APPLY, and other places.

Benefits:

By resurrecting FUNCTION as a useful concept, this proposed change will
eliminate a lot of confusion and will make it easier to talk about
situations in which (true) functions are passed around as Lisp objects.

By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes.  It
also brings Common Lisp into closer alignment with Scheme and other
Lisp-1 dialects.

Conversion Cost:

This proposal attempts to minimize the impact on user code by allowing
APPLY, FUNCALL, and related functions to accept symbols and lambda
lists, as they currently do.  The only impact on user-level code should
be a change in the operation of certain type predicates, and such cases
should be relatively easy to find and fix.

Aesthetics:

Making the concept of a function well-defined will probably be perceived
as a simplification.

It would be cleaner to require all functional arguments to be true
functions, eliminating the use of symbols and lambda-lists in this
context.  However, in this case we felt that the simplification was not
worth a major incompatible change.

Discussion:

The original form of this proposal suggested that APPLY and friends
should take only true functions as the functional argument.  The
current proposal was agreed to after a discussion of the conversion
problems that such an incompatible change might entail.

Some committee members have argued for an APPLICABLE-P predicate that
would be true of all objects that can be passed as the functional
argument to APPLY and friends: true functions, lambda lists, and symbols
that are FBOUNDP.  I (sef) believe that this is not terribly useful and
can easily be defined by any user who wants it (or something similar).
In any event, this can be handled in a separate proposal.

fahlman@c.cs.cmu,masinter.pa@xerox/su
Function Type Proposal

I think it looks good as you have it. Fire away.
			-rpg-

∂11-May-87  1256	FAHLMAN@C.CS.CMU.EDU 	Issue: FUNCTION-TYPE (version 3) 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87  12:56:41 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 15:55:55-EDT
Date: Mon, 11 May 1987  15:55 EDT
Message-ID: <FAHLMAN.12301587043.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-TYPE (version 3)


Status:		Revised by SEF to reflect intensive discussions prior to the
		last X3J13 meeting.

Issue:		FUNCTION-TYPE
References:   	functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
	      	APPLY (pg 107).
Category:     	CHANGE/CLARIFICATION
Edit History: 	Version 1 by RPG 02/26/87
		Version 2 by cleanup committee 15-Mar-87
		Version 3 by SEF 10-May-83

Problem Description:

The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions.  The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner.  This would also make it easier
to integrate the function data type into the CLOS class hierarchy.

The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.

Proposal FUNCTION-TYPE:REDEFINE

1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination.  The list form of the
FUNCTION type specifier may still be used only for declaration.

Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.

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.

No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION.  Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE, and so on.

2. The behvior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)).  In particular, FUNCTIONP is no
longer true of symbols and lambda lists.

3. The descriptions of FUNCALL, APPLY, MAPCAR and all functions in
Common Lisp which take functional arguments are modified to clarify that
they will take either functions, symbols, or lists that represent
lambda-expressions.  A symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used.  Note that this leaves the behavior of FUNCALL, APPLY, MAPCAR,
et al. unchanged, but that their descriptions must be changed to
accommodate the new definition of the FUNCTION type.

4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION.  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.  (Some implementations may
choose not to signal this error for performance reasons.)

5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION).  It is an error to call SYMBOL-FUNCTION on anything
else.  In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.

It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value).  Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.

6. 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".  Change this to the following:

If COMPILE is called with no definition supplied, then it will attempt
to compile the current global definition of the symbol <name>, and will
signal an error if it is unable to do so.  In some implementations, an
interpeted function can be compiled individually only if it contains no
references to lexical context outside the function definition.  If the
symbol's definition is already compiled, no error is signalled.  An
implemenation may choose to recompile the function if the original
interpreted form is available; otherwise, this is a no-op.

Rationale:

This change gives a clean, useful definition to the FUNCTION data type in
Common Lisp and the related type predicates.  Under the current
definition, FUNCTIONP is nearly useless, since it is defined to be true
of all symbols, including those that do not have functional definitions.

Current Practice:

Many programmers find it necessary to write their own predicate
corresponding to the new form of FUNCTIONP.

Adoption Cost:

The type predicates would of course have to be brought into compliance
with this proposal, but that should require little effort.

Compiled functions are true functions in almost all implementations,
but, in some implementations, interpreted functions and closures are
represented as lists.  This would have to be changed in the interpreter,
FUNCALL, APPLY, and other places.

Benefits:

By resurrecting FUNCTION as a useful concept, this proposed change will
eliminate a lot of confusion and will make it easier to talk about
situations in which (true) functions are passed around as Lisp objects.

By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes.  It
also brings Common Lisp into closer alignment with Scheme and other
Lisp-1 dialects.

Conversion Cost:

This proposal attempts to minimize the impact on user code by allowing
APPLY, FUNCALL, and related functions to accept symbols and lambda
lists, as they currently do.  The only impact on user-level code should
be a change in the operation of certain type predicates, and such cases
should be relatively easy to find and fix.

Aesthetics:

Making the concept of a function well-defined will probably be perceived
as a simplification.

It would be cleaner to require all functional arguments to be true
functions, eliminating the use of symbols and lambda-lists in this
context.  However, in this case we felt that the simplification was not
worth a major incompatible change.

Discussion:

The original form of this proposal suggested that APPLY and friends
should take only true functions as the functional argument.  The
current proposal was agreed to after a discussion of the conversion
problems that such an incompatible change might entail.

Some committee members have argued for an APPLICABLE-P predicate that
would be true of all objects that can be passed as the functional
argument to APPLY and friends: true functions, lambda lists, and symbols
that are FBOUNDP.  I (sef) believe that this is not terribly useful and
can easily be defined by any user who wants it (or something similar).
In any event, this can be handled in a separate proposal.

∂11-May-87  1420	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: FUNCTION-TYPE (version 3) 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87  14:20:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137159; Mon 11-May-87 17:18:50 EDT
Date: Mon, 11 May 87 17:18 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (version 3)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Message-ID: <870511171840.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 11 May 1987  15:55 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    Edit History:   Version 1 by RPG 02/26/87
		    Version 2 by cleanup committee 15-Mar-87
		    Version 3 by SEF 10-May-83

I (apparently somewhat belatedly!) approve of FUNCTION-TYPE:REDEFINE
except with the following two caveats:

    No sub-types of FUNCTION are defined in Common Lisp, but implementations
    are free to define subtypes of FUNCTION.  Examples might be
    COMPILED-FUNCTION, INTERPRETED-FUNCTION, COMPILED-CLOSURE, and so on.

Common Lisp currently defines a type-specifier named COMPILED-FUNCTION.
Is this a proposal to remove it?  I would probably support such a proposal,
but it should be explicit.

    If COMPILE is called with no definition supplied, then it will attempt
    to compile the current global definition of the symbol <name>, and will
    signal an error if it is unable to do so.  In some implementations, an
    interpeted function can be compiled individually only if it contains no
    references to lexical context outside the function definition.  If the
    symbol's definition is already compiled, no error is signalled.  An
    implemenation may choose to recompile the function if the original
    interpreted form is available; otherwise, this is a no-op.

The phrase "signal an error if it is unable to do so" is new.  My
problem is that the concept of "unable to compile" is not defined and is
open to varying interpretations.  For example, does this mean that if
any compiler warnings are issued, COMPILE should signal an error at the
conclusion of the compilation?  Also, if we assume that the word
"should" used on CLtL p.439 is covered by the discussion of "must" on
CLtL p.6, then right now this "is an error" rather than "signals an
error."  Also, the specification that COMPILE is a no-op if called with
one argument and the symbol's definition is already compiled appears to
be a change from CLtL, although CLtL is so ambiguous it's hard to be
sure.

Unless there are reasons that these changes to COMPILE must be
incorporated into this proposal, I think it would be better to deal with
them as a separate proposal.  For this proposal, I suggest confining the
discussion to how COMPILE defaults its second argument.  I would say
that if the second argument is not supplied, the first argument "should"
be a symbol that is FBOUNDP and for which the implementation is able to
reconstruct the lambda-expression corresponding to its definition.  So
the only change from CLtL would be to change "a definition that is a
lambda-expression" to "a definition from which the implementation is
able to reconstruct a lambda-expression".  Possibly we should try to state
some necessary conditions under which the implementation is required to
be able to recover the lambda-expression.  Possibly we shouldn't; this
only points out the inherent uselessness of 1-argument COMPILE in
portable programs.

Alternatively, we could take the coward's way out and make both
arguments to COMPILE be required, or, even better, make COMPILE take
only one argument, which must be a lambda expression, and neither read
nor write SYMBOL-FUNCTION.

∂11-May-87  1443	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-STREAM 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87  14:41:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137185; Mon 11-May-87 17:39:09 EDT
Date: Mon, 11 May 87 17:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-STREAM
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870511173900.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

Issue:		PATHNAME-STREAM

Status:		New issue, but easy to agree on

References:   	PATHNAME (p.413), also the introductory text right above
		it on the same page.
		Derived references: PARSE-NAMESTRING (p.414),
		MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
		OPEN (p.418), WITH-OPEN-FILE (p.422),
		RENAME-FILE (p.423), DELETE-FILE (p.424)

Category:     	CHANGE/CLARIFICATION

Problem Description:

The PATHNAME function as documented in CLtL is impossible to implement.
The book says that a stream can be used as an argument and converted to
a pathname, but pathnames only name files, not other sources or sinks
of data that streams might be connected to.

Proposal PATHNAME-STREAM:FILES-ONLY:

Specify that if a stream is used as a pathname, it must be a stream
that is or was open to a file.

Rationale:

This is probably what the designers of Common Lisp intended.
This is the only thing that can be implemented without large changes to
the language such as extending pathnames to things other than files. 

Current Practice:

Some systems signal an error if a non-file stream is used as a pathname.
Others may do something else, but since the proposal is to define this
to be "is an error", current practice seems irrelevant.

Adoption Cost:

Since I didn't say "signals an error", no implementations need change.

Benefits: Description of pathname functions will make more sense.

Conversion Cost: None.

Aesthetics: Makes language a little cleaner.

Discussion: None yet.

∂11-May-87  1502	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-SYMBOL 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87  15:02:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137213; Mon 11-May-87 18:01:19 EDT
Date: Mon, 11 May 87 18:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870511180110.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

Issue:		PATHNAME-SYMBOL
		[Note that this is not the same issue as PATHNAME-STREAM]

Status:		New issue

References:   	PATHNAME (p.413), also the introductory text right above
		it on the same page.
		Derived references: PARSE-NAMESTRING (p.414),
		MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
		NAMESTRING etc. (p.417).

Category:     	INCOMPATIBLE CHANGE

Problem Description:

Some Common Lisp functions are specified to accept a symbol where a 
pathname is expected.  Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE,
and RENAME-FILE) are not specified to accept a symbol.

Proposal PATHNAME-SYMBOL:NO

Never allow symbols where pathnames are expected.

Rationale:

The feature of accepting a symbol was copied by Common Lisp from Zetalisp,
which in turn copied it from Maclisp.  The reason Maclisp allowed a symbol
here was that it did not have strings at all.  However, the feature has been
long since removed from Zetalisp, since it was found to be a source of bugs
and not to be useful.  I suspect this feature was removed from Zetalisp
before Common Lisp was defined, but due to the poor state of Zetalisp
documentation at the time the change was overlooked by the designers of
Common Lisp.

One example of the type of bug caused by this occurs when NIL is erroneously
substituted for a pathname, perhaps because GETHASH or ASSOC didn't find a
table entry that was expected to exist and returned -false-.  In systems
that accept symbols as pathnames, this causes a reference to a file named
"nil" on some perhaps unexpected directory.

Current Practice:

Varies.  Some implementations allow symbols here, some don't.  Symbolics
doesn't allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES,
and allowing them there is probably a bug in the implementation.

Adoption Cost:

It's easy to change implementations to stop accepting symbols.  Since this
appears to be an "is an error" rather than "signals an error" situation,
no implementation change is actually necessary.

Benefits:

Pathname functions will be more consistent.  In implementations that check
the type of this argument, program error checking will be improved.

Conversion Cost:

Some users might be using symbols as pathnames, in implementations where
that works, and they would have to switch to using strings.

Aesthetics: Improved by the change.

Discussion:

The only user feedback on this issue I've seen was a bug report that
MERGE-PATHNAMES was in error because it accepted symbols.

∂11-May-87  1803	FAHLMAN@C.CS.CMU.EDU 	Issue: PATHNAME-SYMBOL 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87  18:03:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 21:02:25-EDT
Date: Mon, 11 May 1987  21:02 EDT
Message-ID: <FAHLMAN.12301642842.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: PATHNAME-SYMBOL
In-reply-to: Msg of 11 May 1987  18:01-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


I favor PATHNAME-SYMBOL:NIL.

It would be nice if someone would undertake a complete review of the
pathname situation.  Seems to me that many problems lurk in here.  But
the desire for a comprehensive solution shouldn't prevent us from
patching things that need to be patched.

-- Scott

∂11-May-87  1807	FAHLMAN@C.CS.CMU.EDU 	Issue: PATHNAME-STREAM 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87  18:05:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 21:04:29-EDT
Date: Mon, 11 May 1987  21:04 EDT
Message-ID: <FAHLMAN.12301643218.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: PATHNAME-STREAM
In-reply-to: Msg of 11 May 1987  17:39-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


I favor PATHNAME-STREAM:FILES-ONLY.

-- Scott

∂11-May-87  1901	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87  19:01:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137484; Mon 11-May-87 21:59:47 EDT
Date: Mon, 11 May 87 21:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870511215932.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

Issue:        KEYWORD-ARGUMENT-NAME-PACKAGE
References:   Lambda Expressions (pp60-64)
Category:     CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
	      29-Apr-87, Version 2 by Pitman
              11-May-87, Version 3 by Moon
Status:	      Revised after discussion

Problem Description:

  CLtL says that only keyword symbols can be used as non-positional argument
  names in &key parameter specifiers.

Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)

  Remove restrictions on the package of non-positional argument names;
  allow any symbol, including NIL.

Rationale:

  As Common Lisp is currently defined, if someone wants to define a function
  that accepts named (rather than positional) arguments whose names are
  symbols in packages other than the KEYWORD package, they cannot use &KEY.
  Instead, they have to duplicate the &KEY mechanism using &REST, GETF,
  and (if they want error checking of argument names) DO.  This suggests that
  the restriction of &key to only keyword symbols is arbitrary and unnecessary.

  Note that the "rationale" box on p.62 of Common Lisp: the Language is an
  argument in favor of requiring non-positional argument names to be symbols,
  and not allowing numbers, but does not speak to the issue of whether or not
  those symbols should be further restricted to be keywords.

  The desire for non-positional arguments whose names are not keyword symbols
  arises when the set of non-positional arguments accepted by a function is
  the union of the sets of non-positional arguments accepted by several other
  functions, rather than being enumerated in a single place.  In this case,
  it becomes desirable to use packages to prevent accidental name clashes
  among non-positional argument names of different functions.

  One example of a Common Lisp application that requires this capability is
  the draft proposal for an object-oriented programming standard.  It will
  have generic functions that accept non-positional arguments and pass them on
  to one or more applicable methods, with each method defining its own set of
  arguments that it is interested in.  If this proposal is not adopted, either
  the non-positional argument names will be required to be keywords, which
  will require the methods to have non-modular knowledge of each other in
  order to avoid name clashes, or the methods will have to be defined with an
  ad hoc mechanism that duplicates the essential functionality of &key but
  removes the restriction.

  A second example of a Common Lisp application that requires this capability
  is private communication channels between functions.  Suppose a public
  routine MAKE-FOO needs to accept arbitrary keywords from the caller and
  passes those keywords along to an internal routine using keywords of its
  own.
   (IN-PACKAGE 'FOOLAND)
   (DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
     (APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))
  This could be done without fear that the use of EXPLICIT T would override
  some keyword in keyword-value-pairs, since the only way that could happen is
  if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL), or if the user was
  programming explicitly in the FOOLAND package, either of which is an implicit
  admission of willingness to violate FOOLAND's modularity.

Documentation Impact:

  The following outlines the changes that would have to be made to Common
  Lisp: the Language if this proposal were adopted, to aid in understanding
  the impact of the proposal.

  Change wording which refers to non-positional arguments as being introduced
  by keyword symbols to simply refer to those arguments being introduced by
  symbols. For example, in the middle of p.60, the sentence:
    ... each -keyword- must be a keyword symbol, such as :start.
  would become
    ... each -keyword- must be a symbol.
  Also, the word "keyword" in the first complete sentence on p.62 would
  be changed to "symbol" for similar reasons.

  Add extra wording on p.60 to explain that by convention keyword symbols
  are normally used as non-positional argument names, and that all functions
  built into the Common Lisp language follow that convention.  A language
  manual might or might not choose to describe the circumstances in which
  it is appropriate not to follow this convention.

  Add examples to illustrate this behavior. For example, on p.64 the
  following examples might be added:

    ((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
    => (1 2 6 NIL)

    ((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
    => (1 2 6 NIL)

Current Practice:

  We do not currently know of an implementation that enforces the restriction
  that this proposal seeks to remove.

  Some implementations have bugs that prevent NIL from working as a keyword
  argument name, but allow all non-NIL symbols. (One Symbolics version that
  was checked had this bug.)

Adoption Cost:

  No existing programs will stop working.  Some implementors might have to
  rearrange their error checking slightly, but it should be very easy.

  Moon was under the impression that this proposal was actually adopted
  around December 1985 (although no formal mechanism for adopting
  proposals existed at that time), but isn't 100% sure.

Benefits:

  This will help with the object-oriented programming standard, among other
  things.

Conversion Cost:

  None.

Aesthetics:

  There will probably be an argument about whether the restriction is
  more esthetic or less esthetic than the freedom, but in either case
  the aesthetic effect is slight.

  In any case, users who do not want to use the extended functionality
  can generally avoid it.

Discussion:

  Moon generated the original version of this proposal and supports it.
  He thinks that if Common Lisp truly has a restriction that only keyword
  symbols can be used as keyword names in calls to functions that take
  keyword arguments, it will be more difficult to come up with an
  object-oriented programming standard that fits within Common Lisp.

  Pitman supports this proposal.

  There was some question in the committee about whether the rationale
  for the proposal was believable.  I hope this version of the proposal
  has resolved any doubts.

∂11-May-87  1907	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-SYMBOL 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 May 87  19:07:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 137493; Mon 11-May-87 22:05:42 EDT
Date: Mon, 11 May 87 22:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301642842.BABYL@C.CS.CMU.EDU>
Message-ID: <870511220522.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 11 May 1987  21:02 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    I favor PATHNAME-SYMBOL:NIL.

To avoid any confusion: do you mean PATHNAME-SYMBOL:NO, or is
PATHNAME-SYMBOL:NIL a different proposal?

∂11-May-87  1940	FAHLMAN@C.CS.CMU.EDU 	Issue: PATHNAME-SYMBOL 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 May 87  19:40:23 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 11 May 87 22:39:37-EDT
Date: Mon, 11 May 1987  22:39 EDT
Message-ID: <FAHLMAN.12301660525.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: PATHNAME-SYMBOL
In-reply-to: Msg of 11 May 1987  22:05-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


Clarification:

I favor PATHNAME-SYMBOL:NO.

-- Scott

∂12-May-87  0728	FAHLMAN@C.CS.CMU.EDU 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 May 87  07:28:09 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 12 May 87 10:27:27-EDT
Date: Tue, 12 May 1987  10:27 EDT
Message-ID: <FAHLMAN.12301789389.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: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
In-reply-to: Msg of 11 May 1987  21:59-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


The rationale is now sufficient, and I support
KEYWORD-ARGUMENT-NAME-PACKAGE:ANY in general.

To prevent confusion, thr proposal should address the lambda-list syntax
explicitly.  In order to write the next paragraph without going
insane, I will use the term "keyword-symbol" for a symbol whose home is
the keyword package, and "keyword-indicator" for the thing (which may or
may noit be a keyword-symbol) that appears in a function call to
specify a not-by-position argument.

If, following an &key, a variable appears alone and not as part of a
(keyword-indicator variable) pair, the behavior specified in CLtL is
unchanged: a keyword-symbol with the same print name as the variable is
created and is used as the keyword-indicator in function calls.  The
only way to get a keyword-indicator that is not a keyword-symbol is to
use the (keyword-indicator variable) syntax in the function's lambda
list.  Note that the variable must not be a constant, but that the
keyword-indicator may be.

Obviously, if we had anticpated this change, we should have called
keyword arguments something else, but it is too late now.

One last comment: if it were up to me, I would exclude NIL as a legal
keyword-indicator.  Nobody would ever want to use this -- it doesn't
help at all in solving the kinds of encapsulation problems discussed in
the rationale -- and allowing this is particularly likely to mask errors
made by the user.  If it screws some current implementations, that's
another (weak) reason to disallow this.  I don't want to fight about
this, but if NIL is allowed, I might fix our compiler to warn
about this as being "technically correct but probably a bug".

-- Scott

∂12-May-87  0930	Gregor.pa@Xerox.COM 	Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 May 87  09:30:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 MAY 87 09:26:41 PDT
Date: 12 May 87 09:24 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 11 May 87 21:59 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@sail.stanford.edu
Message-ID: <870512-092641-3405@Xerox>

I support KEYWORD-ARGUMENT-NAME-PACKAGE:ANY.

∂12-May-87  1158	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87  11:58:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138111; Tue 12-May-87 14:56:28 EDT
Date: Tue, 12 May 87 14:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301789389.BABYL@C.CS.CMU.EDU>
Message-ID: <870512145619.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 12 May 1987  10:27 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    The rationale is now sufficient, and I support
    KEYWORD-ARGUMENT-NAME-PACKAGE:ANY in general.

Thanks.

    To prevent confusion, thr proposal should address the lambda-list syntax
    explicitly.  In order to write the next paragraph without going
    insane, I will use the term "keyword-symbol" for a symbol whose home is
    the keyword package, and "keyword-indicator" for the thing (which may or
    may not be a keyword-symbol) that appears in a function call to
    specify a not-by-position argument.

I was using "non-positional-argument-name" where you used "keyword-indicator".
We have to do something about the terminology.  I like "argument name" a little
better than "keyword indicator", although the former has the problem that people
might confuse it with "parameter name", since experience has shown that it's
virtually impossible for anyone to remember which are the arguments and which
are the parameters.

    If, following an &key, a variable appears alone and not as part of a
    (keyword-indicator variable) pair, the behavior specified in CLtL is
    unchanged: a keyword-symbol with the same print name as the variable is
    created and is used as the keyword-indicator in function calls.  The
    only way to get a keyword-indicator that is not a keyword-symbol is to
    use the (keyword-indicator variable) syntax in the function's lambda
    list.  Note that the variable must not be a constant, but that the
    keyword-indicator may be.

I agree with this, except that the syntax actually has two parentheses,
i.e. ((keyword-indicator variable)), to distinguish it from (variable default).

    Obviously, if we had anticpated this change, we should have called
    keyword arguments something else, but it is too late now.

We can take "lambda-list-keywords", which aren't "keyword-symbols" either,
as a precedent.

    One last comment: if it were up to me, I would exclude NIL as a legal
    keyword-indicator.  Nobody would ever want to use this -- it doesn't
    help at all in solving the kinds of encapsulation problems discussed in
    the rationale -- and allowing this is particularly likely to mask errors
    made by the user.  If it screws some current implementations, that's
    another (weak) reason to disallow this.  I don't want to fight about
    this, but if NIL is allowed, I might fix our compiler to warn
    about this as being "technically correct but probably a bug".

I don't care about NIL being allowed or disallowed.  As a language
designer, it seems like a weird restriction to disallow it, even though
there is no earthly reason to use it.  As a commercial vendor, I won't
complain if we don't have to fix the bug that we currently disallow it.
I'll defer to anyone who has a strong opinion about this.

∂12-May-87  1258	gls@Think.COM 	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87  12:57:56 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 15:59:54 EDT
Date: Tue, 12 May 87 15:59 EDT
From: Guy Steele <gls@Think.COM>
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: Fahlman@c.cs.cmu.edu, CL-Cleanup@sail.stanford.edu
In-Reply-To: <FAHLMAN.12299221539.BABYL@C.CS.CMU.EDU>
Message-Id: <870512155947.2.GLS@BOETHIUS.THINK.COM>

    Date: Sat, 2 May 1987  15:21 EDT
    From: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
    ...
    I would like to encourage KMP to go ahead with a separate proposal for
    ROW-MAJOR-SUBSCRIPTS (or whatever we end up calling it).  Given that, I
    think a version of POSITION that returns a single number for arrays is
    probably the way to go, and users can then turn this into a subscript
    list if they like.  I have a mild aversion to getting a list from some
    function that has heretofore always returned a number or NIL.

In this instance, note that a NIL result could be confused with an
empty list of subscripts, the natural result in the case of a
zero-dimensional array.

--Guy

∂12-May-87  1430	gls@Think.COM 	Issue: FUNCTION-TYPE (version 3)   
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87  14:29:52 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 17:31:34 EDT
Date: Tue, 12 May 87 17:31 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: FUNCTION-TYPE (version 3)
To: Fahlman@c.cs.cmu.edu, cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Message-Id: <870512173129.7.GLS@BOETHIUS.THINK.COM>

I support FUNCTION-TYPE:REDEFINE.

∂12-May-87  1456	gls@Think.COM 	Issue: PATHNAME-SYMBOL   
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87  14:56:02 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 17:58:18 EDT
Date: Tue, 12 May 87 17:58 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: PATHNAME-SYMBOL
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870511180110.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870512175812.2.GLS@BOETHIUS.THINK.COM>

I favor PATHNAME-SYMBOL:NO.

∂12-May-87  1457	gls@Think.COM 	Issue: PATHNAME-STREAM   
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 12 May 87  14:56:55 PDT
Received: from boethius by Think.COM via CHAOS; Tue, 12 May 87 17:59:14 EDT
Date: Tue, 12 May 87 17:59 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: PATHNAME-STREAM
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870511173900.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870512175910.3.GLS@BOETHIUS.THINK.COM>

I favor PATHNAME-STREAM:FILES-ONLY.

∂12-May-87  2104	Moon@STONY-BROOK.SCRC.Symbolics.COM 	[RAM: exiting from unwind protects]   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87  21:04:19 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138596; Wed 13-May-87 00:02:53 EDT
Date: Wed, 13 May 87 00:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [RAM: exiting from unwind protects]
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12301313646.BABYL@C.CS.CMU.EDU>
Message-ID: <870513000235.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sun, 10 May 1987  14:54 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    I find the following pretty persuasive...

I don't.  Actually it seems to be mostly irrelevant to the issue at
hand.  Here's some commentary on it.  Feel free to show this to RAM if
you wish.

    Date: Saturday, 2 May 1987  11:16-EDT
    From: Rob MacLachlan <RAM>

    I don't really agree with Moon about this thing.  I certainly knew about
    about the feature of being about to write something that you can't exit
    from using any common lisp facility, but I don't see this as a
    "serious environment bug".  Our system has always has this property.
    When someone first pointed out this property of Common Lisp way back
    when, I did in fact write the pathological example and it did in fact
    behave in the pathological fashion.  After a while I got bored of
    trying to throw out of the break loop, and I quit.

    If I had really been doing anything, I could always have skipped over
    the losing frame using debug-return.  Environment problems can have
    environment solutions.  

I don't know what debug-return is (presumably something in the Spice
Lisp environment).  Unless it's something that bypasses unwind-protect
and deliberately doesn't evaluate the cleanup forms, I don't think it
solves the problem.  However, I agree that environment problems can have
environment solutions, and I think the issue is to make sure that the
language doesn't forbid the environment from solving this by trying to
enforce a particular semantics for the pathological construct, instead
of having it be an error.

			    In any case, I could have saved work I was
    doing from the break loop.  This feature certainly isn't a big deal;
    there are lots of ways a malicious Lisp user can blow the system out
    of the water.  What happened the last time you did 
    (makunbound '*terminal-io*)?

The second paragraph on p.329 appears to say that it is invalid for a
portable program to do that.  What I am arguing for is a similar
restriction on portable programs doing the similar thing with
unwind-protect and throw.  So I think this example actually supports my
position.

    In contrast, it seems to me that all the "fixes" for this problem
    result in substantial increases in the complexity of the language
    defintion for no gain.  It seems that Moon has already introduced
    three new things into the language:
     1] The concept of "throwing out of an unwind protect cleanup".  When
	are you in an unwind protect?  What does it mean to throw out of
	it?  Does this apply to lexical exits too?  Does this signal an
	error?
	  (block block
	    (unwind-protect <foo>
	      (return-from block)))
	Does this?
	  (unwind-protect <foo>
	    (block block
	      (return-from block)))

Most of this would be answered by re-reading the relevant proposal to
the cleanup committee (are these archived someplace public?), which
was not written by me.  I agree that we need a better-written version
of that proposal that is easier to understand and less ambiguous.  The
one I am looking at is
  Message-ID: <870227172152.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
  Issue:        UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
  Edit history: Revision 1 by KMP 02/27/87

My only contribution to the discussion was
in the message <870423020745.9.MOON@EUPHRATES.SCRC.Symbolics.COM>.
Here are some relevant excerpts from the referenced proposal:

  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:
  ...
  1. Transfer to a point inside the point to which control 
    would have transferred.

and what I proposed in answer to this was to do one of three
things in case 1, transfer to a point inside the point to
which control would have transferred.
  1. wimp out and say it "is an error"
  2. signal an error
  3. resume the original throw, just as if the cleanup handler had
     exited normally.
I prefer signalling an error, because I firmly believe that the program
is ill-formed.

Note that I have not introduced any new concepts here.  I don't think
the UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT proposal introduced new
concepts either; it just made explicit reference to concepts that
were already in Common Lisp.  The argument that these concepts make
the language definition too complex seems to be an argument that the
language definition should not attempt to define the semantics of throwing
precisely.

     2] The concept of errors that aren't errors, which we need so that
	users can't screw themselves with this feature no matter how hard
	they try.

Last time I read the "error proposal" it included this concept.  I don't
think I invented it, I just borrowed it from there while writing up the
discussion of throw vs. unwind-protect.  Certainly in the absence of the
error proposal this concept is not introduced into the language, since the
language currently does not contain an IGNORE-ERRORS construct, nor any
other construct that is sensitive to the issue.

     3] The implicit requirement that an implementation have some exit
	mechanism other than throw so that it can unwind out of cleanup
	forms even if the user can't.  What does the system do when you
	are running in an unwind protect and the user types an interrupt?
	In fact, it seems that Moon is being inconsistent here, since he
	has already assumed that interrupts do throw.  If the user
	interrupts when running in a cleanup do you signal an error, and
	then signal an error whenever the user tries to abort out of the
	debugger?

All of point 3 appears to be a misunderstanding of what was being
discussed and proposed.  "Transfer to a point inside the point to which
control would have transferred" is irrelevant to "the user types an
interrupt" (which I take to mean something like Maclisp's control-X
and control-G, i.e. abort the program and return to a read-eval-print
loop) since those would be transfers to a point outside of, or equal to,
any throw currently in progress.

    If I had ever been screwed by this, I would think differently.  

The inside-Symbolics component of this discussion originated with a
customer being screwed by this.

								    I'm
    sure that most of the reason that this problem doesn't happen is that
    people usually don't write code that aborts from unwind protect
    cleanups.  There is a big difference between saying that something is
    rarely needed and possibly dangerous and saying that it must signal an
    error.

    I am convinced that the simplest evaluation model is to say that the
    unwind-protect cleanup is evaluated in the lexical and dynamic
    environment of the unwind-protect form.  

Nobody ever proposed anything different as far as I am aware.

					     Any alternative must somehow
    introduce an "in an unwind protect cleanup" marker into the dynamic
    environment of the cleanup forms.

The issue is actually what happens you nest throws (throughout this
discussion "throw" has been understood to include all non-local exits,
not only the THROW function).  Thus the marker in question is "in throw",
not "in an unwind protect cleanup".

Yes, the dynamic state of a program that is throwing would need to
include an indication of where it was throwing to if we were to adopt
the proposal that misnested throws signal an error or the proposal that
they resume the outer throw.  In the "is an error" case, there are no
requirements on the implementation, and the requirement is only that
portable programs cannot assume any particular behavior.  However, I
can't imagine an implementation of throw that does -not- remember in its
dynamic state where it's going to throw to when it finishes evaluating
some unwind-protect cleanup forms.

To get back to earth after all this lofty flaming, remember that the
specific case mentioned in the UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT
proposal was

    (CATCH 'FOO
      (CATCH 'BAR
	(UNWIND-PROTECT (THROW 'FOO 3)
	  (THROW 'BAR 4)
	  (PRINT 'XXX))))

and the question is: what does the THROW to BAR do?  One possible answer
that many people seemed to favor is it throws to BAR and the throw to
FOO never happens.  The answer I prefer is that this is not a valid
Common Lisp program.  Does this make the issue clear?

∂12-May-87  2124	Moon@STONY-BROOK.SCRC.Symbolics.COM 	SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 12 May 87  21:24:37 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138606; Wed 13-May-87 00:23:14 EDT
Date: Wed, 13 May 87 00:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870428141313.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870513002305.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

Observation: some of the discussion appears to be assuming that
someone is proposing that

  (position 3 #2a((0 1 2)(3 4 5))) => (1 0)

As far as I can tell no one is proposing that.  My reading of
SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:GENERALIZE (by Touretzky)
is that it proposes

  (position 3 #2a((0 1 2)(3 4 5))) => 3

and the other two options propose that it remains an error.

Vote: I mildly favor SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:UNCHANGED as
being the least confusing to users, although either of the other two
proposals would be okay with me: if there is strong support for them,
I won't expend energy resisting it.

∂13-May-87  0012	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: FUNCTION-TYPE (version 3)  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May 87  00:12:36 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 138655; Wed 13-May-87 03:10:55 EDT
Date: Wed, 13 May 87 03:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (version 3)
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <FAHLMAN.12301587043.BABYL@C.CS.CMU.EDU>
Message-ID: <870513031041.0.KMP@TSUKUBA.SCRC.Symbolics.COM>

While I'm sympathetic to this proposal in some form, I can't support
it as currently drafted.

My main problem is that it tries to clarify too many things. The question of
what is a function is logically distinct from that of what may go in the
function cell. I am very excited about clarifying the type issues, but very
nervous about changing what can go in the function cell.

Here are my notes on the proposal...

 * I'd like to see the word COMPILED-CLOSURE struck. It adds nothing to
   the meaning and could provoke useless debate about what the difference
   might be between a function and a closure; currently CL has no such
   formal distinction.

 * It seems to me that we might as well go ahead and create types
   INTERPRETED-FUNCTION and COMPILED-FUNCTION since the combination of
   the FUNCTION type and the COMPILED-FUNCTION-P predicate already implements
   this distinction. Perhaps eventually COMPILED-FUNCTION-P could be flushed.

 * "behavior" is spelled "behvior" in one place.

 * I never realized that FUNCTIONP and (TYPEP x 'FUNCTION) were not
   synonymous. Please cite a page reference that suggests they are allowed
   to differ. I could not find a definition of the FUNCTION type specifier
   when I looked just now.

 * In item 3 of proposal, I'd say "the text of their description" to be
   completely clear. To me, the descriptions are the abstract entities
   which you've just noted don't need change.

 * Items 4 & 5 are a major incompatibility that I would like to see proposed
   and discussed separately so as not to bog down the type issues which this
   proposal should be about. Macsyma, for example, makes considerable use
   of symbols and lambda expressions in the function cell. Making sure it
   would be happy with this clause would be very non-trivial.

   For now, I would leave this essentially as you left APPLY, pending a
   separate proposal to change that; i.e., FUNCTION and SYMBOL-FUNCTION can
   return things which are non-functions if those objects can be coerced to
   functions. SETF of SYMBOL-FUNCTION can accept such a coercible object,
   and the value later retrieved will be the given object (not a coerced
   form of it), though obviously internally some encapsulation may want to
   go on for stock hardware to make function calling fast.

 * At the in-person meeting at Xerox in March, I suggested that COMPILE
   should not complain if it gets an already-compiled thing, and someone
   pointed out that this could be bad because some users might be wanting
   recompilation and others might want no action. I think we should consider
   a better fix, like something that lets the user say explicitly what
   action to take if the function is already compiled, but for now I would
   leave this an error.

 * The adoption cost does not mention STEP, TRACE, and ED. I think it should.

 * The benefits section should flush the reference to Lisp1, since the only
   criterion for being a Lisp-1 is that you have a unified namespace. In
   fact, this is not properly related to that and mentioning Lisp1 may
   provoke unnecessary worry. It is adequate to say it makes things more
   like Scheme.

 * I believe the conversion cost is potentially much greater than you
   have estimated unless you move items 4 & 5 to another proposal.

   The ability to say (SETF #'FOO 'BAR) rather than (SETF #'FOO #'BAR) has
   important consequences to do with the inheritance of new definitions of
   BAR if it is later defined. I think that some people exploit this a lot
   and it may not always be easy to detect.

   The impact on home-grown steppers, trace and advise facilities, and other
   functions which manipulate the contents of the function cell has also been
   underplayed.

Please don't let these comments get you down. It's clear that a lot of work
has gone into this and I'm hopeful that it will be resolved successfully.
I just want to keep the decision process as unencumbered as possible and
right now it's just too hard for me to reason clearly about the overall
impact of such a sweeping proposal.
 -kmp

∂13-May-87  0914	RPG  	FUNCTION-TYPE and Archives   
To:   cl-cleanup@SAIL.STANFORD.EDU    

First, the archives for CL-cleanup are in clclea.msg[com,lsp].
However, this archive was separated out from the main Common-Lisp
archive only recently.

Second, about the FUNCTION-TYPE proposal: I support it, but mildly.
I favor a much stronger change, and this proposal is just barely above
the level of acceptability to me.

KMP wonders

`` I never realized that FUNCTIONP and (TYPEP x 'FUNCTION) were not
   synonymous. Please cite a page reference that suggests they are allowed
   to differ. I could not find a definition of the FUNCTION type specifier
   when I looked just now.''

The suggestion is on the same pages that allows the following two to
differ:

	(let ((x '(or to-be (not to-be))))
         (assert `(is-a question ,x)))

	``To be or not to be: That is the question.''

KMP's third sentence is the answer: FUNCTION is a type name symbol
that corresponds to no type, and therefore (typep x 'function) is
not defined. This is what this proposal attempts to remedy.

However, to be slightly more serious, I am disturbed to always read
that Common Lisp must do this, that, or the other thing because otherwise
the effort to keep Macsyma up to date will suffer, or that the reason that
some feature must continue to exist is because it is reflected in 
Macsyma usage. I like Macsyma as well as the next guy, but not enough to
kill a language to keep its code legal.

			-rpg-

∂13-May-87  1133	@ALLEGHENY.SCRC.Symbolics.COM:File-Server@QUABBIN.SCRC.Symbolics.COM 	FUNCTION-TYPE, archives, and Macsyma    
Received: from [192.10.41.45] by SAIL.STANFORD.EDU with TCP; 13 May 87  11:33:01 PDT
Date: Wed, 13 May 87 14:23 EDT
From: KMP@QUABBIN.SCRC.Symbolics.COM
Sender: File-Server@QUABBIN.SCRC.Symbolics.COM
Subject: FUNCTION-TYPE, archives, and Macsyma
To: RPG@SAIL.STANFORD.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870513142303.6.FILE-SERVER@ALLEGHENY.SCRC.Symbolics.COM>

I spent well over a year converting Macsyma to what I believe is a good
faith reading of CLtL. At the outset, I was as tired as anyone of its
odd little needs that were unwritten parts of various languages and that
had to be supported only out of fear of breaking Macsyma.

I am trying to invoke no such fear now. Indeed, I don't even work for the
Macsyma project any more. I am sure that those who do work for it are
willing to do reasonable work to upgrade Macsyma into the next generation
Lisp.

However, those people (whoever they may be when it finally happens; my
grandchildren, I fear) will need to be able to adequately estimae the
impact of the various changes which we have made. And we ourselves must
adequately estimate the impact so that we can know how much work we are
asking people to absorb.

I said several times in my message that I might be willing to go along
with this change. I am not trying to "kill a language" as you put it.
I just want us to be honest. And when I read the text in this proposal
that said "... attempts to minimize the impact on user code ... the
only impact should be a change in the operation of certain type predicates
... relatively easy to find and fix" I knew we were not being honest.
The changes we're proposing may be good ones. They will not all be easy
to find and fix.

I do think that the part which simply involves types is fairly
non-controversial. I would like to see it separated so we can agree that
it is and leave a smaller issue to worry about.

∂13-May-87  1626	Moon@STONY-BROOK.SCRC.Symbolics.COM 	FUNCTION-TYPE and Archives       
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May 87  16:25:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 139430; Wed 13-May-87 19:24:13 EDT
Date: Wed, 13 May 87 19:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE and Archives   
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 13 May 87 12:14 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <870513192404.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 13 May 87  0914 PDT
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    First, the archives for CL-cleanup are in clclea.msg[com,lsp].
    However, this archive was separated out from the main Common-Lisp
    archive only recently.
    [Second part deleted]

This is very useful, but if this was in answer to my question of yesterday
about archiving, I was actually asking a different question.  I was wondering
if the current versions of the various proposals are archived somewhere,
such that one could retrieve a single proposal without first wading through
a bunch of mail.  This might be a directory with each proposal in a separate
file, for example.

∂13-May-87  2121	edsel!bhopal!jonl@navajo.stanford.edu 	looping in unwind-protect cleanups  
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 May 87  21:21:16 PDT
Received: by navajo.stanford.edu; Wed, 13 May 87 21:18:45 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA01380; Wed, 13 May 87 20:01:41 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA03441; Wed, 13 May 87 20:03:04 PDT
Date: Wed, 13 May 87 20:03:04 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705140303.AA03441@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 13 May 87 00:02 EDT <870513000235.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
Subject: looping in unwind-protect cleanups

I tend to agree with you that looping caused by UWP cleanup forms throwing 
back through the same cleanup forms is a serious error;  and that this 
situation not only ought to be "signalled" as an error, but also ought to
be recuperable (from the debugger, I suppose).   However, one or two loose 
ends need to be cleared up.  You mention the example from the original
proposal:

    (CATCH 'FOO
      (CATCH 'BAR
	(UNWIND-PROTECT (THROW 'FOO 3)
	  (THROW 'BAR 4)
	  (PRINT 'XXX))))

and you use the phrase "... this is not a valid Common Lisp program."  
I have trouble with that characterization, since it seems to imply 
some mechanically checkable property of programs.  The "serious error"
mentioned above is a dynamic condition, which could be caused by other 
programs that are not so clearly analyzable.  For example, consider just 
removing the (THROW 'BAR 4) out of the lexical context:

    (CATCH 'FOO
      (CATCH 'BAR
	(UNWIND-PROTECT (THROW 'FOO 3)
	  (DO-A-BIT-OF-WORK)
	  (PRINT 'XXX))))

    (DEFUN DO-A-BIT-OF-WORK () 
      (UNLESS (WINNINGP)
	(THROW 'BAR 4)))

I think you see how this could be extended to produce an example that could
not be mechanically proven invalid by the UWP-non-local-exit criterion,
even though it would get into the disastrous loop.

How about this characterization of the problem: for a given process, the
unwind-protect cleanup forms should be viewed as non-reentrant code.  An
attempt to execute such code reentrantly will signal an error, which will
probably enter the debugger (and entering the debugger won't, by itself,
cause another throw, so there is no fear of infinite looping from this
step).  In such a case, the user should have the choice of continuing with 
the re-entrant invocation, or of doing an "abort" which skips doing the
signalled UWP frame's cleanups.  In the first case, he may want to "try
again" at the cleanups, because it just might be that they were entered
"re-entrantly" only because he interrupted in the middle of some cleanups,
and then asked the debugger to "abort to toplevel"; or maybe entering the
"embrace" depends on some global data which he has just "fixed".  In the 
second case, he may recognize the "deadly embrace" as hopeless, and simply
wish to punt out of it.

There is some concern about "hairing up" the UWP/THROW mechanisms.  I
don't believe that this approach, or *** ones like it *** (which were
alluded to in previous messages) is really all that complex.  
Implementationally, it would seem to require at most:
  (1) For each UWP frame, the "cleanup forms" have an associated lock 
      (possibly a per-process lock) that is acquired upon entry [and 
      released upon exit?].  Failure to acquire the lock signals the 
      re-entrancy error.  The acquisition/release time could hardly
      be more than a few memory cycles time, and hence won't be a serious
      slowdown for THROWing.
  (2) The low-level part of THROW would admit a "skip me" argument, so
      that it could be told which UWP/CATCH frame to omit the cleanups
      on [but not the lock releasings?].  Only one "skip me" is needed, 
      since nested "deadly embraces"  could be undone one step at a time.
      [In fact there really only could be one frame to "skip" -- the one
       whose lock is already tied up.]

I don't mean to imply that this is the only, or the best, or even the
clearest implementation of such an idea; but I claim that non-re-entrancy 
isn't all that deep a concept here.  It's more to the point than saying
"non-interruptible" (which is wrong); and more succinct than some other
characterizations of how one might detect the "deadly embrace".


-- JonL --

∂13-May-87  2158	Moon@STONY-BROOK.SCRC.Symbolics.COM 	looping in unwind-protect cleanups    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May 87  21:58:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 139634; Thu 14-May-87 00:57:23 EDT
Date: Thu, 14 May 87 00:57 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: looping in unwind-protect cleanups
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8705140303.AA03441@bhopal.edsel.uucp>
Message-ID: <870514005708.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 13 May 87 20:03:04 PDT
    From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)

    ...you use the phrase "... this is not a valid Common Lisp program."  
    I have trouble with that characterization, since it seems to imply 
    some mechanically checkable property of programs.

I didn't mean to imply that.

    ...I think you see how this could be extended to produce an example that could
    not be mechanically proven invalid by the UWP-non-local-exit criterion,
    even though it would get into the disastrous loop.

Sure.  If you give me a few hours, I will mail you examples of programs
in Common Lisp, Ada, and Basic the determination of whose validity in
their respective languages is equivalent to the halting problem.  The
basic plan is to write a program where it cannot be mechanically proven
whether an array subscript is out of bounds.

    ....Implementationally, it would seem to require at most:
      (1) For each UWP frame, the "cleanup forms" have an associated lock ....

This is rather overcomplicated, so let me tell you how the versions of
Symbolics systems that implement my proposed checking do it.  None of
these are released yet.  This is from memory, I didn't write the code.

1. Every catch (including ones generated internally by tagbody and block
when nonlocal exits via go, return, or return-from are happening) contains
a validity bit, which is initially 1.

2. When throw plans to throw past a catch, it sets its validity bit to 0.
This happens after throw finds the target catch (since Common Lisp says if
there is no matching catch, the error is signalled in the dynamic environment
of the throw), and before throw starts removing state from the stack and
evaluating cleanup forms.  Here throw includes nonlocal go, return, and
return-from along with certain debugger commands.

3. An attempt to throw to a catch whose validity bit is 0 signals an error
that isn't caught by IGNORE-ERRORS.

4. The error in 3 is implemented by the Common Lisp function BREAK.

5. When throw evaluates an unwind-protect cleanup form, it first removes
it from the list of such forms, so that if you throw again it won't be
evaluated again.  (I'm pretty sure that a close reading of CLtL shows
that this is required.)

Note that the only data structure or dynamic state is one bit per catch,
the only overhead is in throw, and the error signalling is implemented
with an existing Common Lisp facility.

∂14-May-87  1039	edsel!bhopal!jonl@navajo.stanford.edu 	looping in unwind-protect cleanups  
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 14 May 87  10:39:24 PDT
Received: by navajo.stanford.edu; Thu, 14 May 87 10:36:48 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA03537; Thu, 14 May 87 10:23:10 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA03960; Thu, 14 May 87 10:24:36 PDT
Date: Thu, 14 May 87 10:24:36 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705141724.AA03960@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 14 May 87 00:57 EDT <870514005708.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: looping in unwind-protect cleanups


Re: . . . let me tell you how the versions of
    Symbolics systems that implement my proposed checking do it.  None of
    these are released yet.  This is from memory, I didn't write the code.
    . . . 
    Note that the only data structure or dynamic state is one bit per catch,
    the only overhead is in throw, and the error signalling is implemented
    with an existing Common Lisp facility.

A lock is effectively 1 bit per catch, and by storeing it in the catch
frame, it is process-specific; lock-acquisition would be done in THROW,
and is very low overhead.  I suspect these two proposed implementations
are isomorphic at a fundamental level, with your "validity bit" replaceing
my "lock".

The only thing that seems a bit peculiar in your review of the new Symbolics
code is that the error signalled by "failure to acquire the lock" has to be 
treated specially (not caught by IGNORE-ERRORS, goes directly to BREAK, 
"does not pass GO, lands in jail", whatever).  Maybe that is the reason RAM 
and some others were so upset by the original proposal.  I think I see the 
point of the special handling; but I don't like the singularity.


-- JonL --

∂14-May-87  1046	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-SYMBOL  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87  10:45:08 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 140100; Thu 14-May-87 13:43:48 EDT
Date: Thu, 14 May 87 13:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870511180110.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870514134332.1.KMP@TSUKUBA.SCRC.Symbolics.COM>

I support PATHNAME-SYMBOL:NO, but I have the following comments:

 * Please change the reference to filename "nil" to filename "NIL"
   since (STRING NIL) returns "NIL" and not "nil". This is a minor
   point, but I think worth doing.

 * Note that the biggest impact of this change on users is that
   they will not be able to say (LOAD'FOO) which they commonly type
   interactively to mean (LOAD "FOO"). One advantage, of course, is
   that in case-sensitive file systems, people won't do
   (load'foo) and wonder why file "FOO" (rather than "foo") is not
   found. Still, I think the fact that we're going to make it an
   error for people to type (LOAD 'FOO) is worth documenting as part
   of the cost of this proposal so that no one ends up surprised.

∂14-May-87  1051	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-STREAM  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 May 87  10:50:32 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 140111; Thu 14-May-87 13:49:01 EDT
Date: Thu, 14 May 87 13:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-STREAM
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870511173900.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870514134846.2.KMP@TSUKUBA.SCRC.Symbolics.COM>

I support PATHNAME-STREAM:FILES-ONLY.

Since string-streams are non-file streams that CL programmers
will be familiar with, it might be worth mentioning them explicitly
in the proposal as an example of something for which the indicated
functions do not have to work.

∂15-May-87  2144	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 May 87  21:44:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 141562; Sat 16-May-87 00:44:03 EDT
Date: Sat, 16 May 87 00:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <192342.870428.JAR@AI.AI.MIT.EDU>,
             <870428185220.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
             <870428-220403-2039@Xerox>,
             <870429093550.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
             <192793.870429.JAR@AI.AI.MIT.EDU>,
             <8704292330.AA13102@bhopal.edsel.com>,
             <870429222608.2.MOON@EUPHRATES.SCRC.Symbolics.COM>,
             <193127.870429.JAR@AI.AI.MIT.EDU>,
             <8704300644.AA13625@bhopal.edsel.com>,
             <8704302311.AA01123@bhopal.edsel.com>,
             <193809.870430.JAR@AI.AI.MIT.EDU>,
             <8705012012.AA00639@bhopal.edsel.uucp>,
             <FAHLMAN.12299231012.BABYL@C.CS.CMU.EDU>,
             <194629.870502.JAR@AI.AI.MIT.EDU>,
             <FAHLMAN.12299293460.BABYL@C.CS.CMU.EDU>
Message-ID: <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

I finally found the time to read this huge pile of mail carefully and think
clearly about it.  Here's my considered opinion, but before telling you
which proposal I support I'd like to clear away some underbrush.  I
apologize for the 200 line length, but I can't make all the concepts
unambiguously clear with a briefer speech.

We speak of cells, which are conceptual locations that remember a value and
can be read and written.  Sometimes these conceptual locations are
implemented by actual memory locations, and sometimes they aren't, but
that's an implementation detail and is irrelevant here.  (Sometimes these
are called variables, but other times the word "variable" means something
else, so for the sake of clarity I'm not going to use the word "variable".)

Right now, Common Lisp has two kinds of cells: global cells and local
cells.  Local cells have lexical extent, while global cells have global
extent and can be referenced from anywhere except where they are shadowed
by a local cell referenced by the same name.

Right now, Common Lisp has two kinds of binding:  Lexical binding creates a
new local cell.  Special binding saves the value of a global cell, gives it
a new value during the extent of the binding, and later restores the old
value.  We know that special binding saves and restores because of what
other functions see when they read the cell.  Please don't get confused
with issues of shallow-bound versus deep-bound implementation, which are
irrelevant here: I said cells are not the same thing as memory locations.

Note that I am carefully using different words for the two kinds of cells
from the words for the two kinds of binding; lack of differentiation here
has led to a lot of confusion, I think.

Right now, Common Lisp has a fairly complicated set of rules for how to
determine what cell is referenced when a program mentions a variable name.
(When I say "lexically free", I mean outside of all bindings of that name,
regardless of whether those bindings are special or lexical.)
  1. If the reference is lexically free, use the global cell.
  2. Otherwise, in the absence of a SPECIAL declaration use the cell that
     was affected by the innermost binding; if that binding was special,
     use the global cell; if it was lexical, use the local cell created
     by that binding.
  3. Otherwise, the SPECIAL declaration forces use of the global cell.

We certainly do not want to introduce a third kind of cell, because that
would lead to a great deal of confusion.  Nor do we want to introduce a
third kind of binding.  What we -are- trying to accomplish is to make the
primitive concepts orthogonally available.  An example of a problem we have
right now that needs to be fixed is that there is no way to say that a name
is not misspelled without simultaneously saying that bindings of that name
should be special rather than lexical.  These concepts should be available
as separate constructs.

There are four things that we would like to be able to proclaim about
a variable name (aside from TYPE):
 - the default kind of binding if no declaration specifies which kind
 - the name is not misspelled so don't warn about free references
 - it is illegal to specially bind the global cell, because it is
   a constant or because we want to optimize the performance of a
   deep-binding implementation
 - it is illegal to store into the global cell, because it is a constant

It is already possible in Common Lisp to proclaim all four of these things,
but some of them are mixed up with other concepts and not separately
available.  Let's pick names for the four kinds of proclamations, and let's
also agree that any proclamation serves the "not misspelled" purpose.  Let's
further agree that these four proclamations are mutually exclusive.

  LEXICAL  -- does nothing other than "not misspelled"
  SPECIAL  -- changes the default kind of binding from lexical to special
  GLOBAL   -- makes it illegal to specially bind the global cell
  CONSTANT -- makes it illegal to store into the global cell
              CONSTANT implies GLOBAL because special-binding is storing

SPECIAL exists now.  LEXICAL is Rees's proposal.  CONSTANT exists now
but only buried inside the DEFCONSTANT macro.  GLOBAL exists now but
only when implied by DEFCONSTANT.  I propose to make CONSTANT and
GLOBAL explicitly available.

It appears to be appropriate to make CONSTANT and GLOBAL proclamations
change the default kind of binding to "illegal", rather than leaving
it lexical.

Now we have to ask what these proclamations mean as declarations.
Let us agree that they have the same scoping rules as the SPECIAL
declaration, i.e. they can be attached to a binding and they can
also be wrapped around references, which they pervasively affect
until shadowed by the next declaration or binding.

LEXICAL attached to a binding forces the binding to be lexical even
if there is a SPECIAL, GLOBAL, or CONSTANT proclamation.  LEXICAL
shadows the effect of a special binding on references; therefore we
must add another rule to the "complicated set":
  4. Otherwise, a LEXICAL declaration forces use of the local cell
     created by the innermost lexical binding of the name, or if there
     is none, use of the global cell.

SPECIAL means the same as it has always meant in Common Lisp.

GLOBAL or CONSTANT attached to a binding makes the binding illegal.
GLOBAL or CONSTANT affects a reference by forcing it to use the global
cell, thus rule 3 in the "complicated set" must be modified to treat GLOBAL
and CONSTANT the same as SPECIAL.  We could also just make GLOBAL and
CONSTANT illegal as declarations.  Another idea would be to make CONSTANT
as a declaration allow you to create a new lexical constant.  I'm going to
take the path of least addition to the language and make them illegal.

Note that PROCLAIM-LEXICAL:RESTRICTED conflates LEXICAL and GLOBAL, which
seems undesirable to me.  We want to make each primitive concept separately
available.

Okay, so which proposal do I support?  Well, I support a slight modification
of PROCLAIM-LEXICAL:GENERAL, which I will now explicate (text mostly
copied from Rees):

Proposal (PROCLAIM-LEXICAL:GENERAL+GLOBAL):

  Introduce new declaration specifiers, LEXICAL, GLOBAL, and CONSTANT, which
  are mutually exclusive with the SPECIAL declaration specifier.  All four
  may be used as proclamations; only SPECIAL and LEXICAL may be used as
  declarations.

  A name may be proclaimed only one of LEXICAL, SPECIAL, GLOBAL, or
  CONSTANT.  A name is said to be unproclaimed if it has not been
  proclaimed to be any of these four.

  A free reference or assignment to a name is an error if it is
  unproclaimed and undeclared.

  A LAMBDA-binding in the absence of a declaration or proclamation binds
  the lexical variable.

  SPECIAL proclamations and declarations behave as defined in CLtL.

  LEXICAL proclamations have no effect other than to make the name
  cease to be unproclaimed.  LEXICAL declarations shadow all enclosing
  declarations and proclamation of any of these four types.  LEXICAL
  declarations have the same scoping rules as SPECIAL declarations.

  GLOBAL proclamations make it an error to bind the name.

  CONSTANT proclamations make it an error to bind the name and an
  error to assign to the name.

  DEFCONSTANT is defined in terms of SETQ and the CONSTANT proclamation.
  All keyword symbols are automatically proclaimed CONSTANT.

  A free reference or assignment accesses the same value regardless
  of the declaration or proclamation.  This is called the global value.
  SPECIAL binding alters the global value within its extent.
  (Multiple process and multiple processor systems will have to make
  their own definitions of the extent of a SPECIAL binding, as noted
  on p.38 of CLtL--this proposal is not a proposal to standardize that.)

  The preceding paragraph should be understood carefully.  There is only
  one global value for a name and it is used by all free references, all
  free assignments, and all SPECIAL bindings.

  Example:

    (proclaim '(lexical x))
    (proclaim '(special y))
    (setq x 1 y 2)

    (defun tst ()
      (let ((x 3) (y 4))
	(locally (declare (special x) (lexical y))
	  (list x y
	        (funcall (let ((x 5) (y 6))
			   #'(lambda () (list x y))))))))

    (tst) => (1 4 (5 4))

Note that the second element of the list is different from
the value, 2, it would have in PROCLAIM-LEXICAL:GENERAL.
That is because the special binding of y changes the global
value to 4, and the declared-lexical reference to y accesses
the global value, since there is no surrounding lexical binding.

Cost of adopting change:

  I believe this is the same as current practice as specified by CLtL,
  except that all of the primitive concepts have been made visible instead
  of being hidden inside other concepts.  Compilers and interpreters
  will need to support LEXICAL as a declaration.

  Referencing or assigning to an unproclaimed and undeclared name
  "is an error", not "signals an error", which allows but does not
  require an implementation to issue a warning.  This is a change from
  current language but does not mandate a change from current practice.

Benefits:

  LEXICAL proclamation enhances compatibility with Scheme.
  GLOBAL proclamation allows more efficient deep-bound implementations
  and enhances compatibility with Interlisp and VMLISP.

Cost of converting existing code:

  None, it's upward compatible.

Aesthetics:

  The "insidious and disgusting aspect" doesn't get any worse.  Making
  primitive concepts explicitly available can only enhance aesthetics.

Discussion:

  Let's hear it!

∂16-May-87  0302	edsel!bhopal!jonl@navajo.stanford.edu 	Issue: PROCLAIM-LEXICAL   
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 May 87  03:02:07 PDT
Received: by navajo.stanford.edu; Sat, 16 May 87 02:58:25 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
	id AA10964; Sat, 16 May 87 01:33:58 pdt
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA09180; Sat, 16 May 87 01:35:27 PDT
Date: Sat, 16 May 87 01:35:27 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8705160835.AA09180@bhopal.edsel.uucp>
To: navajo!Moon%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 16 May 87 00:43 EDT <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL

Your summary of the "proclamation" issue is excellent.  It delineates all
the separate issues very well, and also it incorporates all the points I 
have made in previous notes about these matters.   So I for one would be 
quite happy to see your revised proposal accepted.

-- JonL --

∂17-May-87  1447	FAHLMAN@C.CS.CMU.EDU 	Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87  14:47:28 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 17:46:49-EDT
Date: Sun, 17 May 1987  17:46 EDT
Message-ID: <FAHLMAN.12303180096.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: PROCLAIM-LEXICAL
In-reply-to: Msg of 16 May 1987  00:43-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


I think that Moon's analysis of this issue is right on the mark, and I
like his proposal except for two points:

First, it is made clear that only one of SPECIAL, LEXICAL, GLOBAL, or
DYNAMIC can be in effect for a variable at any one time, but the
proposal does not address the question of whether you can over-ride an
old proclamation in this set by issuing a new one.  We have to address
that, I think, and it is a moderately complex question.

It seems to me that we want to allow a variable to be re-proclaimed for
two reasons: to correct proclmations issued in error by the user,
without having to kill off the Lisp and start over, and to make it
easier to merge programs written by two different programmers.  (The
latter reason may be bogus -- these guys shouldn't be in the same
package anyway -- but there are times when a quick-and-dirty fix is
extremely handy.)  On that other hand, we want the compiler to be able
to wire certain things in tight as a result of these proclamations, so
we need to make clear that if you proclaim something to be GLOBAL,
compile some code, then proclaim it to be SPECIAL and then compile some
more code the rebinds this variable, you may not get what you expect.
Same with unconstantifying a constant.

If Rob's compiler proposal, or something like it, were in effect, we
could probably explain what the rules are within that framework.
However, given the current state of things, it might be best to say that
it "is an error" to re-proclaim a variable into a different class --
this says that portable code cannot do this and count on the result --
but that implementations are strongly urged to allow this
re-proclamation as a way of correcting erroneous proclamations, perhaps
issuing a warning or signalling a correctable error whenever a
proclamation actually gets changed.

The second problem is Moon's suggestion that it should be an error to
assign or reference an unproclaimed and undeclared variable.  The
problem I have with this is that most of us like to be able to do things
with undeclared variables in the interpreter -- stashing things in
made-up variables like FOO -- and I think that there will be blood in
the streets if we take this away from people or if the interpreter is
required to hassle them for not declaring the variable before using it.
And yet, when the compiler comes across an undeclared variable, I want
to get a warning, especially now that I can use a LEXICAL proclamation
to flush that warning with no other side effects.

I think that the right move is to say that accessing and referencing an
undeclared variable is legal, and that such references access the global
cell while leaving the variable in unproclaimed state.  We should then
encourage (require?) compiler writers to issue a warning in such cases.

Of course, if you believe that the compiler has no business warning
about anything that is technically legal (and some wording in Moon's
"cost of adoption" section suggests to me that he may be in this camp),
then the above proposal is a non-sequitur.  In my view, however, the
compiler may issue a warning about code that is legal but suspicious,
though I agree with Rees that in all such cases there should be
something you can put in a program to say, "Shut up, I know what I'm
doing here."  The LEXICAL proclamation gives us that.

-- Scott

∂17-May-87  1931	FAHLMAN@C.CS.CMU.EDU 	Issue: FUNCTION-TYPE (version 3) 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87  19:31:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 22:30:44-EDT
Date: Sun, 17 May 1987  22:30 EDT
Message-ID: <FAHLMAN.12303231779.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:   fahlman@C.CS.CMU.EDU
Subject: Issue: FUNCTION-TYPE (version 3)
In-reply-to: Msg of 13 May 1987  03:10-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


In reply to: Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>.

    My main problem is that it tries to clarify too many things. 

I agree with Moon that Compile can be split out of this proposal and
dealt with separately.  However, I feel that the other issues really
have to be dealt with all at once.  The issue of what constitutes the
FUNCTION type and whether function definitions have to be functions in
whatever sense we define are closely interconnected.  We'll ahve to
solve the latter issue sooner or later, so let's try to do it now.

     * I'd like to see the word COMPILED-CLOSURE struck. It adds nothing to
       the meaning and could provoke useless debate about what the difference
       might be between a function and a closure; currently CL has no such
       formal distinction.

No problem with eliminating any mention of this.  It was just a "for
instance" anyway.

     * It seems to me that we might as well go ahead and create types
       INTERPRETED-FUNCTION and COMPILED-FUNCTION since the combination of
       the FUNCTION type and the COMPILED-FUNCTION-P predicate already implements
       this distinction. Perhaps eventually COMPILED-FUNCTION-P could be flushed.

One possibility is not to define any of these and to eliminate
COMPILED-FUNCTION-P.  That's what I proposed in version 3.  The other
possibility is to define COMPILED-FUNCTION and INTERPRETED-FUNCTION as
subtypes of FUNCTION, but then we have to spell out what happens in
implementations that have only one internal representation or that have
more than two -- raw interpreted, transformed, and fully compiled, for
example.  Then there's the question of whether closures are, or can be,
a separate subtype.  In some sense, all true functions are closures,
since to get one you close a lambda expression in some lexical
environment.  However, we might want to reserve the word "closure" for
functions that actually capture some part of the lexical context outside
the function itself, and to create CLOSURE types based on this idea.

In my view, we are better off avoiding this whole thing and leaving it
to the individual implementations.

     * In item 3 of proposal, I'd say "the text of their description" to be
       completely clear. To me, the descriptions are the abstract entities
       which you've just noted don't need change.

I disagree with this use of "description", but there's no point in
arguing epistemology here.  I'll change the wording.

       Macsyma, for example, makes considerable use
       of symbols and lambda expressions in the function cell. Making sure it
       would be happy with this clause would be very non-trivial.

I don't understand this.  If your code expects to put random symbols and
lambda lists into function cells and to get them back later, unchanged,
this is not portable Common Lisp.  At least, the manual is so vague in
this area that you'd better not count on anything of this sort being
portable.  PCL was storing symbols in symbol-function cells for awhile,
but this broke lots of implementations and they finally gave up on this.

       For now, I would leave this essentially as you left APPLY, pending a
       separate proposal to change that; i.e., FUNCTION and SYMBOL-FUNCTION can
       return things which are non-functions if those objects can be coerced to
       functions. SETF of SYMBOL-FUNCTION can accept such a coercible object,
       and the value later retrieved will be the given object (not a coerced
       form of it), though obviously internally some encapsulation may want to
       go on for stock hardware to make function calling fast.

I know of several Common Lisps in which this is not the status quo.  So
either way we clarify this, it is an incompatible change for someone.  I
hate to see us take a step backwards here, just to make Macsyma more
portable than it currently is.

I agree that we should make a bit more of this issue in the "conversion
costs" section -- truth in advertising -- but I think that saying that a
function definition must be a function is an important part of the
rationalization we are trying to achieve.

Would it make life any easier for Macsyma (and other programs with this
same problem, if any exist) if we were to add a function that extracts
the lambda expression from a function if the function is uncompiled and
is not a closure (in the stronger sense mentioned above)?  In some
implementations this might be EQ or at least EQUAL to the original
Lambda, but in others it might have been macro-expanded or altered in
some way that preserves its essential behavior.  We could call the
function EXTRACT-LAMBDA-EXPRESSION or something like that.

     * At the in-person meeting at Xerox in March, I suggested that COMPILE
       should not complain if it gets an already-compiled thing, and someone
       pointed out that this could be bad because some users might be wanting
       recompilation and others might want no action. I think we should consider
       a better fix, like something that lets the user say explicitly what
       action to take if the function is already compiled, but for now I would
       leave this an error.

How about if we just adopt your earlier proposal: if the function is
already compiled, COMPILE is a no-op that returns the NAME.

     * The adoption cost does not mention STEP, TRACE, and ED. I think
       it should.

OK.

     * The benefits section should flush the reference to Lisp1, since the only
       criterion for being a Lisp-1 is that you have a unified namespace. In
       fact, this is not properly related to that and mentioning Lisp1 may
       provoke unnecessary worry. It is adequate to say it makes things more
       like Scheme.

OK.

     * I believe the conversion cost is potentially much greater than you
       have estimated unless you move items 4 & 5 to another proposal.

       The ability to say (SETF #'FOO 'BAR) rather than (SETF #'FOO #'BAR) has
       important consequences to do with the inheritance of new definitions of
       BAR if it is later defined. I think that some people exploit this a lot
       and it may not always be easy to detect.

       The impact on home-grown steppers, trace and advise facilities, and other
       functions which manipulate the contents of the function cell has also been
       underplayed.

Well, as I said, such code is currently not portable because nothing in
the book unambiguously requires that symbols and lambda expressions be
put into the SYMBOL-FUNCTION cell unchanged (or that such changes be
undone upon retrieval), and because many implementations currently do
not do this.  So there's a cost either way we clarify this.  Doing it
the way you suggest tends to put the burden on implementors rather than
on the maintainers of old code, but I still think it is a step
backwards.

-- Scott

∂17-May-87  1944	FAHLMAN@C.CS.CMU.EDU 	FUNCTION-TYPE and Archives       
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87  19:42:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 22:42:14-EDT
Date: Sun, 17 May 1987  22:42 EDT
Message-ID: <FAHLMAN.12303233875.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: FUNCTION-TYPE and Archives   
In-reply-to: Msg of 13 May 1987  12:14-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>


In reply to: Dick Gabriel <RPG at SAIL.STANFORD.EDU>.

    Second, about the FUNCTION-TYPE proposal: I support it, but mildly.
    I favor a much stronger change, and this proposal is just barely above
    the level of acceptability to me.

I assume that the "stronger proposal" you favor would require FUNCALL,
APPLY, and friends to accept only true functions.

I would go along with putting both options into the proposal we send to
X3J13 and let them vote on it.  My guess is that the conservatives would
prevail, but I personally would favor the "stronger proposal".  (That's
easy for me, because I have relatively little code to maintain.)  It
might be worth a try -- maybe truth and beauty would win.

However, there's a chance that if we put forward two options, the whole
thing will bog down for a while.  I wonder if it is worth the risk of
added delay.

-- Scott

∂18-May-87  1344	gls@Think.COM 	Issue: PROCLAIM-LEXICAL  
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 18 May 87  13:44:21 PDT
Received: from boethius by Think.COM via CHAOS; Mon, 18 May 87 16:46:47 EDT
Date: Mon, 18 May 87 16:44 EDT
From: Guy Steele <gls@Think.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870518164427.1.GLS@BOETHIUS.THINK.COM>

I am in agreement with everything Moon has said, except for the
following paragraph:

    Right now, Common Lisp has two kinds of cells: global cells and local
    cells.  Local cells have lexical extent, while global cells have global
    extent and can be referenced from anywhere except where they are shadowed
    by a local cell referenced by the same name.

I believe this paragraph confuses the notions of extent and scope.
In the terminology of CLTL chapter 3, both kinds of cell have
indefinite extent (but the bindings of a global cell have dynamic
extent).  The *names* used to refer to these cells have lexical
and <???> scope, respectively.

If this bit of language were to be cleaned up, I would favor something
like Moon's proposal.

--Guy

∂18-May-87  1529	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 18 May 87  15:29:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 142936; Mon 18-May-87 18:28:46 EDT
Date: Mon, 18 May 87 18:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <870518164427.1.GLS@BOETHIUS.THINK.COM>
Message-ID: <870518182849.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 18 May 87 16:44 EDT
    From: Guy Steele <gls@Think.COM>

    I am in agreement with everything Moon has said, except for the
    following paragraph:

	Right now, Common Lisp has two kinds of cells: global cells and local
	cells.  Local cells have lexical extent, while global cells have global
	extent and can be referenced from anywhere except where they are shadowed
	by a local cell referenced by the same name.

    I believe this paragraph confuses the notions of extent and scope.

Quite right.  I must have meant to say "scope", but spazzed.

∂19-May-87  1316	KMP@STONY-BROOK.SCRC.Symbolics.COM 	FORMAT-NEGATIVE-PARAMETERS   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87  13:16:02 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 143993; Tue 19-May-87 16:15:07 EDT
Date: Tue, 19 May 87 16:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-NEGATIVE-PARAMETERS
To: Fahlman@C.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12303677629.BABYL@C.CS.CMU.EDU>
Message-ID: <870519161434.8.KMP@TSUKUBA.SCRC.Symbolics.COM>

[Removed Berman, Common-Lisp; added CL-Cleanup]

    Date: Tue, 19 May 1987  15:19 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

	Date: 19 May 1987  14:38-EDT
	From: Richard Berman <berman at vaxa.isi.edu>

	... do you know what this should do?

	(FORMAT NIL "~-1%")

    ... there seem to be a number of places in the format directives where
    negative numbers would make no sense.  I don't think that all of these
    are explicitly flagged.  This should probably be fixed up in the
    standard, but until then it seems reasonable to assume non-negative
    integers unless there's some obvious meaning for the negative case.

This would be a reasonable topic for us to address in CL-Cleanup.

I agree that a reasonable approach for the interim, and in fact in the
next edition of the manual, is to say that format parameters are assumed
to be non-negative integers except as specifically stated. Of course, we'll
need to specify clearly whether signalling an error or assuming 0 or whatever
is the right thing otherwise, and that should perhaps be done by someone who
has surveyed all the ops to determine the likely impact on typical code of
assuming 0, etc.

Cases where some implementations signal an error and others quietly ignore
the error are what drive developers of portable code nuts.

By the way, I note that this case is most important where the user has
written ~V%, since it's not statically detectable in that case that a problem
has arisen. 

Obviously, someone should write this up as a formal proposal. I've picked
the issue name FORMAT-NEGATIVE-PARAMETERS above and this message can be used
to seed the proposal when someone has time to write it.

∂19-May-87  1739	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PROCLAIM-LEXICAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 19 May 87  17:39:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 144321; Tue 19-May-87 20:38:25 EDT
Date: Tue, 19 May 87 20:38 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12303180096.BABYL@C.CS.CMU.EDU>
Message-ID: <870519203829.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sun, 17 May 1987  17:46 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

I think I forgot to answer this, but if you're seeing it twice, I apologize.

    I think that Moon's analysis of this issue is right on the mark, and I
    like his proposal 

Thanks.
		      except for two points:

    First, it is made clear that only one of SPECIAL, LEXICAL, GLOBAL, or
    DYNAMIC 

CONSTANT, you mean.

	    can be in effect for a variable at any one time, but the
    proposal does not address the question of whether you can over-ride an
    old proclamation in this set by issuing a new one.  We have to address
    that, I think, and it is a moderately complex question.

I think this is an environment issue rather than a language issue.

    ....
    If Rob's compiler proposal, or something like it, were in effect, we
    could probably explain what the rules are within that framework.

I think Rob's proposal would only tell us how to compile a program that
proclaims a variable one way inside a Lisp that proclaims it another way,
but not what happens when the result of that compilation is loaded into
that Lisp.

    However, given the current state of things, it might be best to say that
    it "is an error" to re-proclaim a variable into a different class --
    this says that portable code cannot do this and count on the result --
    but that implementations are strongly urged to allow this
    re-proclamation as a way of correcting erroneous proclamations, perhaps
    issuing a warning or signalling a correctable error whenever a
    proclamation actually gets changed.

In other words, it's an environment issue.  I agree that it should be
"is an error" rather than "signals an error"; I think this is an excellent
example of something where program development environments should have
flexibility and, conversely, no portable program would rely on the error
being signalled and want to handle it (using conditions).

    The second problem is Moon's suggestion that it should be an error to
    assign or reference an unproclaimed and undeclared variable.  

Actually I just copied that from Rees.

								  The
    problem I have with this is that most of us like to be able to do things
    with undeclared variables in the interpreter -- stashing things in
    made-up variables like FOO -- and I think that there will be blood in
    the streets if we take this away from people or if the interpreter is
    required to hassle them for not declaring the variable before using it.

That's why it's "is an error" rather than "signals an error", isn't it?
Is using undeclared variables in the interpreter something for portable
programs to rely on being able to do, or just something for human users?

    And yet, when the compiler comes across an undeclared variable, I want
    to get a warning, especially now that I can use a LEXICAL proclamation
    to flush that warning with no other side effects.

    I think that the right move is to say that accessing and referencing an
    undeclared variable is legal, and that such references access the global
    cell while leaving the variable in unproclaimed state.  We should then
    encourage (require?) compiler writers to issue a warning in such cases.

That would be okay with me, however people in general might prefer that we
just say it's an error and not try to dictate what the compiler should do.
I have no strong opinion here.

    Of course, if you believe that the compiler has no business warning
    about anything that is technically legal (and some wording in Moon's
    "cost of adoption" section suggests to me that he may be in this camp),
    then the above proposal is a non-sequitur.  In my view, however, the
    compiler may issue a warning about code that is legal but suspicious,
    though I agree with Rees that in all such cases there should be
    something you can put in a program to say, "Shut up, I know what I'm
    doing here."  The LEXICAL proclamation gives us that.

True.


∂19-May-87  1801	FAHLMAN@C.CS.CMU.EDU 	Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87  18:01:09 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 19 May 87 21:00:27-EDT
Date: Tue, 19 May 1987  21:00 EDT
Message-ID: <FAHLMAN.12303739600.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: PROCLAIM-LEXICAL
In-reply-to: Msg of 19 May 1987  20:38-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


In reply to: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>

        However, given the current state of things, it might be best to say that
        it "is an error" to re-proclaim a variable into a different class --
        this says that portable code cannot do this and count on the result --
        but that implementations are strongly urged to allow this
        re-proclamation as a way of correcting erroneous proclamations, perhaps
        issuing a warning or signalling a correctable error whenever a
        proclamation actually gets changed.

    In other words, it's an environment issue.  I agree that it should be
    "is an error" rather than "signals an error"; I think this is an excellent
    example of something where program development environments should have
    flexibility and, conversely, no portable program would rely on the error
    being signalled and want to handle it (using conditions).

OK, I think we agree here, more or less.  I'd like to see some
indication in the proposal that this particular "is an error" is one
that many interpreters might choose to allow for the convenience of
programmers.  Some people equate "is an error" with "don't do it" rather
than "don't depend on it across implementations".

        The second problem is Moon's suggestion that it should be an error to
        assign or reference an unproclaimed and undeclared variable.  The
        problem I have with this is that most of us like to be able to do things
        with undeclared variables in the interpreter -- stashing things in
        made-up variables like FOO -- and I think that there will be blood in
        the streets if we take this away from people or if the interpreter is
        required to hassle them for not declaring the variable before using it.

    That's why it's "is an error" rather than "signals an error", isn't it?
    Is using undeclared variables in the interpreter something for portable
    programs to rely on being able to do, or just something for human
    users?

Well, you're right in saying that "is an error" would be the right thing
if our only concern were portable programs.  That's our main concern,
but not our only one.  I would still like to be able to do a few typical
interpreter things in any Common Lisp, and this is one of them.  So I am
strongly opposed to any proposal that says it is OK for (setq foo 27)

 this issue doesn't affect portable
programs, but that's not the only concern we should deal with.  I would
like to see 

        And yet, when the compiler comes across an undeclared variable, I want
        to get a warning, especially now that I can use a LEXICAL proclamation
        to flush that warning with no other side effects.

        I think that the right move is to say that accessing and referencing an
        undeclared variable is legal, and that such references access the global
        cell while leaving the variable in unproclaimed state.  We should then
        encourage (require?) compiler writers to issue a warning in such cases.

    That would be okay with me, however people in general might prefer that we
    just say it's an error and not try to dictate what the compiler should do.
    I have no strong opinion here.

        Of course, if you believe that the compiler has no business warning
        about anything that is technically legal (and some wording in Moon's
        "cost of adoption" section suggests to me that he may be in this camp),
        then the above proposal is a non-sequitur.  In my view, however, the
        compiler may issue a warning about code that is legal but suspicious,
        though I agree with Rees that in all such cases there should be
        something you can put in a program to say, "Shut up, I know what I'm
        doing here."  The LEXICAL proclamation gives us that.

    True.

∂19-May-87  1812	FAHLMAN@C.CS.CMU.EDU 	Issue: PROCLAIM-LEXICAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 May 87  18:12:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 19 May 87 21:11:08-EDT
Date: Tue, 19 May 1987  21:10 EDT
Message-ID: <FAHLMAN.12303741560.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: PROCLAIM-LEXICAL


Sorry, I hit the wrong key and shot that last message off before I was
done editing... 

In reply to: David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>

        However, given the current state of things, it might be best to say that
        it "is an error" to re-proclaim a variable into a different class --
        this says that portable code cannot do this and count on the result --
        but that implementations are strongly urged to allow this
        re-proclamation as a way of correcting erroneous proclamations, perhaps
        issuing a warning or signalling a correctable error whenever a
        proclamation actually gets changed.

    In other words, it's an environment issue.  I agree that it should be
    "is an error" rather than "signals an error"; I think this is an excellent
    example of something where program development environments should have
    flexibility and, conversely, no portable program would rely on the error
    being signalled and want to handle it (using conditions).

OK, I think we agree that "is an error" would be the best thing here.
I'd like to see some indication in the proposal (maybe down in the
discussion part) that this particular "is an error" is one that some
interpreters might choose to tolerate (preferably with some warning) for
the convenience of interactive users.  Some people equate "is an error"
with "don't do it" rather than "don't depend on it in portable code".

        The second problem is Moon's suggestion that it should be an error to
        assign or reference an unproclaimed and undeclared variable.  The
        problem I have with this is that most of us like to be able to do things
        with undeclared variables in the interpreter -- stashing things in
        made-up variables like FOO -- and I think that there will be blood in
        the streets if we take this away from people or if the interpreter is
        required to hassle them for not declaring the variable before using it.

    That's why it's "is an error" rather than "signals an error", isn't it?
    Is using undeclared variables in the interpreter something for portable
    programs to rely on being able to do, or just something for human
    users?

Well, you're right in saying that "is an error" would be the right thing
if our ONLY concern were portable programs.  That's our main concern,
but not our only one.  I would still like to be able to do a few typical
interpreter things in any legal Common Lisp, and this is one of those
things.  So I am strongly opposed to any proposal that says it is OK for
(setq foo 27) not to work in some Common Lisp interpreters.

So I feel pretty strongly that my earlier formulation was the
best one: references and assignments of undeclared/unproclaimed
variables refer to the global cell, but leave the variable undeclared.
And compilers are allowed (not required) to warn about such references.

-- Scott

∂26-May-87  1431	Masinter.pa@Xerox.COM 	administrative   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 May 87  14:31:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 26 MAY 87 14:26:31 PDT
Date: 26 May 87 14:26 PDT
From: Masinter.pa@Xerox.COM
Subject: administrative   
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870526-142631-1697@Xerox>

I've gotten way behind the last couple of weeks on my mail. 

I hope we are not too late to mail out the proposals we have ready for
voting at X3J13. I'll try to get a summary out this week and revised
versions.

I have a separate file of mail on each proposal, where the latest
version of each proposal is generally a recent message. However, these
are not on an externally available file server. I started to try to keep
the latest version of each proposal in a separate file on a public
server, but it was a lot of work with no percieved benefit.

Right now, I'll just offer the service that if anyone needs the latest
version of something , send me a personal message and I will mail it
out. (This may seem inconsistent with my being behind in my mail, but
personal mail gets priority.)

If anyone has any revised versions of any of the open proposals they
want to submit for consideration at the next X3J13 meeting, this is the
week to get them in.



∂28-May-87  2233	JAR,KMP@AI.AI.MIT.EDU 	Issue: PROCLAIM-LEXICAL    
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 28 May 87  22:32:46 PDT
Date: Fri, 29 May 87 01:34:10 EDT
From: JAR, KMP@AI.AI.MIT.EDU
Sender: JAR@AI.AI.MIT.EDU
Subject:  Issue: PROCLAIM-LEXICAL
To: Moon@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870516004312.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <206630.870529.JAR@AI.AI.MIT.EDU>

We feel that the exposition preceding Moon's proposal contains some
assumptions which lead him to conclusions with which we're somewhat
uncomfortable.

Although the proposal is coherent and we don't think it's technically
unworkable, we're not really happy with the conceptual model of
special binding which it seems to presuppose.

Apparently, I (JAR) have been hacking denotational semantics so long
that the way that Lisp hackers think is now completely foreign
to me.  Moon's notion of a "cell" feels very unnatural, for example.
Were I to write a Common Lisp EVAL in a less complicated language,
e.g. lambda calculus, Pascal, or Scheme, I would start as follows:

    (defun eval (exp lexical-env dynamic-env store cont)
      (cond ((symbolp exp)
	     ...)
	    ...))

In this notation, a DYNAMIC-ENV maps names to locations, and a STORE
(British word for memory) maps locations to values.  This makes clear the
exact manner in which the "meaning" of a variable depends on the context
(dynamic, lexical, and prior side-effects) in which it occurs.  It looks
like Moon's notion of a "cell" bundles these two mappings in some way,
but it's not completely clear how.  It would be interesting to see how
Moon would write EVAL (using UNWIND-PROTECT perhaps?) in a language that
had no side effects or dynamic binding.

The intent here is not to convince anyone that some particular
model is right or wrong, but to point out that there's more than one
valid way of modeling all this.  Moon's proposal follows neatly from
the exposition which precedes it, but since we're not happy with the
exposition, it's not surprising that we're not happy with the
proposal.

One particular point of contention: we're uneasy about Moon's suggestion
that binding a special variable can affect the evaluation of a lexical
variable.  This is an example of how a bias toward a shallow-binding model
shows through.

These remarks are too brief and we expect to have more to say on
this later, but since Larry's probably making up a status report for
presentation to X3J13, and since the comments on Moon's proposal have
thus far been non-critical, we wanted to get it into the record that
we think there's more work to be done here.

∂29-May-87  2113	Masinter.pa@Xerox.COM 	barrage of mail coming
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:13:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:13:17 PDT
Date: 29 May 87 21:13 PDT
From: Masinter.pa@Xerox.COM
Subject: barrage of mail coming
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870529-211317-1248@Xerox>

Stay tuned for a barrage of mail; I've been trying to get the open
proposals into a form that we can ship. I will send out new copies of
several proposals where I've made minor (or in a few cases major) edits
to incorporate comments on this list. 

You will get:

Revised versions of many of the proposals (at least up thru
PATHNAME-SYMBOL today)

A revised status report (ditto)

A ***BALLOT***.   Most of the ballot items are of the form:

[ ] Release as is  [ ] Comments follow in mail to cl-cleanup.

Most of this is just double checking to make sure that the silent
members of the committee really agree even if they haven't responded.

∂29-May-87  2114	Masinter.pa@Xerox.COM 	Issue ADJUST-ARRAY-DISPLACEMENT 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:14:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:13:54 PDT
Date: 29 May 87 21:13 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
Message-ID: <870529-211354-1250@Xerox>

Status: Minor edits for presentation. No disagreement in committee.
Ready for release? (use ballot).

Issue:        ADJUST-ARRAY-DISPLACEMENT
Reference:    Steele p.297
Category:     Clarification
Edit history: Revision 1 by SEF, 18-Apr-87 (from Steele's list)
              Revision 2 by Masinter (minor)

Problem Description:

The interaction of Adjust-Array and displacement is insufficiently
specified in the case where the array being adjusted is displaced.

Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES

Suppose we are adjusting array A, which is perhaps displaced to B before
the Adjust-Array call and perhaps to C after the call.

(1) A is not displaced before or after: The dimensions of A are altered,
and the contents rearranged as appropriate.  Additional elements of A
are taken from the :initial-element.  The use of :initial-contents
causes all old contents to be discarded.

(2) A is not displaced before, but is displaced to C after.  As
specified in CLtL, none of the original contents of A appears in A
afterwards; A now contains the contents of C, without any rearrangement
of C.

(3) A is displaced to B before the call, and is displaced to C after the
call.  As in case (2), the contents of B do not appear in A afterward
(unless such contents also happen to be in C).  If
:displaced-index-offset is not specified in the Adjust-Array call, it
defaults to zero; the old offset (into B) is not retained.

(4) A is displaced to B before the call, but not displaced afterward.  A
gets a new "data region", and contents of B are copied into it as
appropriate to maintain the existing old contents; additional elements
of A are taken from the :initial-element.  However, the use of
:initial-contents causes all old contents to be discarded.

Note that if array X is displaced to array Y, and array Y is displaced
to array Z, and array Y is altered by Adjust-Array, array X must now
refer to the adjusted contents of Y.  This means that an implementation
may not collapse the chain to make X refer to Z directly and forget that
the chain of reference passes through array Y.  (Cacheing techniques are
of course permitted, as long as they preserve the semantics specified
here and in CLtL.)

If X is displaced to Y, it is an error to adjust Y in such a way that it
no longer has enough elements to satisfy X.  This error may be signalled
at the time of the adjustment, but this is not required.

Rationale:

This interaction must be clarified.  This set of rules was proposed some
time ago, as a result of discussions on the Common Lisp mailing list,
and this model has been adopted by many Common Lisp implementations.

Current Practice:

Many implementations currently follow the model proposed here.  Others
may do something random.  [See discussion below.]

Adoption cost:

Some existing implementations may have to be changed, but adopting any
other model would be worse.  Public-domain code implementing this model
is available from CMU.

Benefits:

Clarification of a situation that is currently not addressed by the
standard.

Conversion Cost:

This is a relatively uncommon situation, which is the reason it didn't
occur to the original language designers to specify how it works.  Any
user code that cares about this issue probably already follows the
proposed model.

Discussion:

Discussed long ago on the Common Lisp mailing list.  This proposal
attempts to capture the overall consensus that emerged at that time.

Moon: We [Symbolics] implement what is proposed, except for 

    (4) A is displaced to B before the call, but not displaced
afterward.  A
    gets a new "data region", and contents of B are copied into it as
    appropriate to maintain the existing old contents; additional
elements
    of A are taken from the :initial-element.

We never copy the contents of B in this case; all elements are taken
from the :initial-element.

Either behavior seems equally justifiable to me.  One could say
"adjust-array never stores into the array if it ends up displaced" or
"adjust-array only preserves the elements of non-displaced arrays."  I
have no information as to whether it matters to users.

∂29-May-87  2116	Masinter.pa@Xerox.COM 	Issue DEFVAR-INIT-TIME (Version 2)   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:16:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:15:53 PDT
Date: 29 May 87 21:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue DEFVAR-INIT-TIME (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-211553-1257@Xerox>

Status:	      I worked over the wording on this one a little. Ready for
release?

Issue:        DEFVAR-INIT-TIME
References:   DEFVAR (p68)
Category:     CLARIFICATION
Edit history: 23-Apr-87, Version 1 by Pitman
              29-Mar-87, Revision 2 by Masinter


Problem Description:

The description of DEFVAR is not completely clear about the time at
which the initialization occurs.

On p68 it says ``VARIABLE is initialized to the result of evaluating the
form INITIAL-VALUE unless it already has a value. The INITIAL-VALUE form
is not evaluated unless it is used; this fact is useful if evaluation of
the INITIAL-VALUE form does something expensive like create a large data
structure.''

At least one implementation interpreted the "unless it is used" to mean
"unless the variable is used" rather than "unless the initial-value is
to be used". The problem is that the "it" is ambiguous. Thus, DEFVAR was
interpreted as a kind of lazy initialization that happened upon the
variable's first unbound reference. (This interpretation appears to have
been further supported by the additional wording in CLtL about not
creating expensive structures that are not needed.)

Proposal (DEFVAR-INIT-TIME:NOT-DELAYED):

Clarify that the evaluation of the initial value and the initialization
happen at DEFVAR execution time (if at all). The cause of the confusion
is the statement that the initial value form is not evaluated unless "it
is used".  Better to say that INITIAL-VALUE is evaluated if and only if
the variable does not already have a value.  Then there would be no
confusion about the time of evaluation.

Rationale:

This clarification follows the intent of the original Common Lisp
designers.

Current Practice:

Nearly all implementations implement the proposed interpretation.

Adoption Cost:

None, for most implementations; very small for any the implementation
that adopted delayed evaluation.

Benefits:

This clarification makes the semantics of an important primitive more
well-defined.

Conversion Cost:

Most users presumably expect the behavior currently in practice in most
dialects. There's not a lot of code where the difference comes into play
anyway. Presumably the conversion cost is fairly trivial.

Aesthetics:

Being a clarification, this really doesn't have much aesthetic effect.

Discussion:

The cleanup committee supports this clarification.

∂29-May-87  2118	Masinter.pa@Xerox.COM 	Issue: DO-SYMBOLS-DUPLICATES (Version 2)  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:17:37 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:17:05 PDT
Date: 29 May 87 21:16 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Issue: DO-SYMBOLS-DUPLICATES (Version 2)
CC: Masinter.pa@Xerox.COM
Message-ID: <870529-211705-1259@Xerox>


Status:  I merged in various comments. Ready for release? [use ballot]

Issue:        DO-SYMBOLS-DUPLICATES
References:   Do-Symbols, Page 187
Category:     Clarification
Edit history: Revision 1 by SEF 17-Apr-87
              Version 2 by Masinter, add other options

Problem Description:

CLtL specifies that Do-Symbols executes the body once for each symbol
accessible in the package.  It does not say whether it is permissible
for the body to be executed more than once for some accessible symbols.
The term "accessible" is defined on page 172 to include symbols
inherited from other packages (not including any symbols that may be
shadowed).  It is very expensive in some implementations to eliminate
duplications that occur because the same symbol is inherited from
multiple packages.

Proposal: DO-SYMBOLS-DUPLICATES:ALLOWED

Add to the specification of DO-SYMBOLS a note that it may execute the
body more than once for some symbols.

Rationale:

Most uses of DO-PACKAGE would not be harmed by the presence of
duplicates.  For these applications it is unreasonable to force users to
pay the high cost of filtering out the duplications.  Users who really
want the duplicates to be removed can add additional code to do this job.

Current Practice:

Many implementations have always produced duplicate values.

Adoption Cost:

None.  Implemenations would still be free to eliminate the duplications,
though code will not be assuming that this has been done.

Benefits:

Clarification of a situation that is currently ambiguous.

Conversion Cost:

Users who have been assuming that DO-SYMBOLS eliminates duplications
will have to be modified, but such code would run on few existing Common
Lisp systems.

Aesthetics:

It would be cleaner to present each symbol exactly once.  This is a
clear case of choosing efficiency over elegance.

Discussion:

This issue was discussed on the Common Lisp mailing list in 1985, and
the solution proposed here seems to have been informally agreed to at
the time -- there was no formal decision-making process in place then.

The need for do-symbols to be efficient is questionable, however; for 
many applications (e.g., global package manipulation), duplicate values
would create havoc. 

For some implementations, the performance penalty would be well over 
a factor of two.

Proposal: DO-SYMBOLS-DUPLICATES:ADD-KEYWORDS

Add a keyword argument to the DO-SYMBOLS macro :ALLOW-DUPLICATES (default
value T) which would make the choice explicit. E.g., 

 (DO-SYMBOLS (SYMBOL (FIND-PACKAGE "FRED") NIL
	       :ALLOW-DUPLICATES T
	       :EXTERNAL-ONLY NIL)
   ...)

Rationale:

This proposal allows applications which need to be careful the 
opportunity to do so.

Current Practice:

No current implementation has this feature.

Adoption Cost:

Implementations which currently can produce duplicates would have
to keep track of symbols which were previously in the macro expansion.

Benefits:

The default case would run efficiently, and yet users could also have
code that guaranteed that there were no duplicates.

Conversion Cost:

Users who have been assuming that DO-SYMBOLS eliminates duplications
would only have to add a :ALLOW-DUPLICATES T.

Aesthetics:

This proposal makes the language slightly more complex, but allows 
for both efficiency and accuracy. 

Discussion:

Should the default value of :allow-duplicates be nil instead?

∂29-May-87  2118	Masinter.pa@Xerox.COM 	Issue: FLET-IMPLICIT-BLOCK (Version 5)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:18:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:17:40 PDT
Date: 29 May 87 21:17 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Issue: FLET-IMPLICIT-BLOCK (Version 5)
Message-ID: <870529-211740-1263@Xerox>

Status:       Ready for release? [Use ballot]

Issue:        FLET-IMPLICIT-BLOCK
Reference:    CLtL p. 113, 67
Edit history: Revision 2 by cleanup committee 15-Mar-87 15:13:33
              Revision 3 by Masinter (reformatting) 7-Apr-87 17:49:12 
              Revision 4 by SEF 11-Apr-87
              Revision 5 by SEF 11-Apr-87

Problem Description:

Do Flet, Labels, Defmacro, Macrolet, Defsetf, Define-Setf-Method, and
Deftype have an implicit block around their bodies like the body of a
Defun?  CLtL is silent on this point.  Many users and some implementors
assume that such blocks should be established, since they view these
forms as analogous with Defun.

Test case:

(defun test ()
  (flet ((test (x) (if x (return-from test 4) 3)))
	(list (test nil) (test t))))

(test)

will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would return 4
in an implementation that did not add an implicit block around Flet.

Category: Ommission. 
Proposal: FLET-IMPLICIT-BLOCK:YES

Each function created by Flet and Labels and each macro created by
Defmacro and Macrolet has an implicit block around the body.  The name
of this block is that same as the (lexical) name of the function or
macro.  Similarly, the body code in Defsetf, Define-Setf-Method, and
Deftype is surrounded by a block with the same name as the accessor
or type.

Current Practice:

Current practice is mixed.  Several implementations do not add the
implicit block, others do, some add some of these blocks and not others.

Cost of adopting this change:

Some implementations will have to be modified.  This should be a
relatively easy modification.

Cost of not adopting the change:

If the issue is not clarified one way or another, continuing confusion
will result in portability problems.  Clarifying the issue in any other
way would also require modifications in some implementations.

Cost of converting existing code:

It is possible that some user code would break because it does a return
from within a code body to an outer block that has the same as the
newly-required block.  Such problems will be rare, and the code in
question would not run on all current Common Lisp systems because of the
diverse interpretations currently in effect.  It would be possible to
detect all such instances automatically, though it seems unlikely that
anyone will need to use this technique.

Discussion:

The goal is first to clean up an ambiguous situation and, second, to do
this in a way that provides consistent behavior between local and global
definitions.  The proposed change would allow a simple rule of thumb:
any named entity that takes a code body establishes an implicit block
with the obvious name.

There are two coherent alternatives to the proposal above:

The first would be to keep the implicit block in Defun, and to clearly
state that the other forms do not create implicit blocks.  This
violates the goal of consistency between lexical and global definitions,
and it seems to conflict with users' expectations.

The second alternative is to eliminate the implicit block from Defun
rather than adding such blocks to other forms.  There is some feeling
that specifying the implicit block in Defun was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself.  If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.

On the other hand, eliminating the implicit block in Defun would be a
significant incompatible change.  Some users find this implicit block to
be a great convenience for popping out of convoluted code, and some
existing code makes heavy use of this feature.  Such code could be
repaired automatically by searching for situations in which the user
returns from a function by name and by adding an appropriate explicit
block to any function containing such a forms, but it would still
require more more work on existing user code than the proposal made
above.

There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common (perhaps even required) in future
Common Lisp implementations.  The outcome of these discussions was
general agreement that a compiler could easily eliminate the implicit
block in any case where it is not actually used, and that the impact on
tail-recursion optimization in compiled code is therefore minimal.

∂29-May-87  2119	Masinter.pa@Xerox.COM 	Re: FORMAT-OP-C (Version 2)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:19:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:18:40 PDT
Date: 29 May 87 21:18 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: FORMAT-OP-C (Version 2)
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-211840-1264@Xerox>

Did I miss this?


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

Return-Path: <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
Xerox.COM ; 29 APR 87 18:52:14 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 127874; Wed
29-Apr-87 21:51:16 EDT
Date: Wed, 29 Apr 87 21:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: FORMAT-OP-C (Version 2)
To: Masinter.pa
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870429-184508-3208@Xerox>
Message-ID: <870429215106.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Sounds right. I'll edit that in to Version 3 with Pavel's
correction when the comments subside.


     ----- End Forwarded Messages -----

∂29-May-87  2119	Masinter.pa@Xerox.COM 	Issue: FUNCTION-TYPE (version 4)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:19:35 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:19:04 PDT
Date: 29 May 87 21:18 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE (version 4)
Message-ID: <870529-211904-1265@Xerox>


Status:        Ready to release? [Use ballot]

Issue:          FUNCTION-TYPE
References:     functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
                APPLY (pg 107).
Category:     	CHANGE/CLARIFICATION
Edit History:   Version 1 by RPG 02/26/87
                Version 2 by cleanup committee 15-Mar-87
                Version 3 by SEF 10-May-87
                Version 4 by Masinter 29-May-87 incorporate comments

Problem Description:

The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions.  The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner.  This would also make it easier
to integrate the function data type into the CLOS class hierarchy.

Even though there is a predicate FUNCTIONP, it is not synonomous to the
use
of the type FUNCTION; the FUNCTION type cannot be used for
discrimination.

The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.


Proposal FUNCTION-TYPE:REDEFINE

1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination.  The list form of the
FUNCTION type specifier may still be used only for declaration.

Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.

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.

No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION.  Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, and so on. Note that this
is a change from the current Common Lisp definition which explicitly
defines a COMPILED-FUNCTION type. This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.

2. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)).  In particular, FUNCTIONP is no
longer true of symbols and lambda lists.

3. The text descriptions of FUNCALL, APPLY, MAPCAR and other functions
in Common Lisp which take functional arguments should be to clarify that
they will take either functions, symbols, or lists that represent
lambda-expressions, where a symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used.  Note that this is not a change to the the behavior of Common 
Lisp; the descriptions must be changed to accommodate the new definition
of the FUNCTION type.

4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION.  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.  (Some implementations may
choose not to signal this error for performance reasons.)

5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION).  It is an error to call SYMBOL-FUNCTION on anything
else.  In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.

It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value).  Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.

6. The description of COMPILE is changed, since it is no longer
meaningful to speak of a symbol with a definition that "is a
lambda-expression". Where CLtL says "a definition that is a
lambda-expression" the behavior of COMPILE should be described as "a
definition from which the implementation is able to reconstruct a
lambda-expression". 

Rationale:

This change gives a clean, useful definition to the FUNCTION data type
in
Common Lisp and the related type predicates.  Under the current
definition, FUNCTIONP is nearly useless, since it is defined to be true
of all symbols, including those that do not have functional definitions.

Current Practice:

The definition of FUNCTIONP varies widely between Common Lisp
implementations. No current Common Lisp implementation has exactly the
semantics described here, however.

Adoption Cost:

The type predicates would of course have to be brought into compliance
with this proposal, but that should require little effort.

Compiled functions are true functions in almost all implementations,
but, in some implementations, interpreted functions and closures are
represented as lists.  Some implementations already always store special
types in function cells, but others, which currently store and return 
LAMBDA expressions in SYMBOL-FUNCTION, would be required to change the
behavior of (interpreted FUNCTION).

Some implementations will have to modify the behavior of COMPILE, STEP,
TRACE and (possibly) ED to deal with non-list values in symbol-function
cells.

Benefits:

By resurrecting FUNCTION as a useful concept, this proposed change will
eliminate a lot of confusion and will make it easier to talk about
situations in which (true) functions are passed around as Lisp objects.

By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes.  It
also brings Common Lisp into closer alignment with Scheme.

Conversion Cost:

This proposal attempts to minimize the impact on user code by allowing
APPLY, FUNCALL, and related functions to accept symbols and lambda
lists, as they currently do.  One impact on user-level code should
be a change in the operation of certain type predicates, and such cases
should be relatively easy to find and fix.

User code which relies on the fact that in some environments,
SYMBOL-FUNCTION returns a list in a well-known format for functions
defined in the lexical global environment will have to change. 

Similarly, some implementations currently allow users to say (SETF #'FOO
'BAR) and then subsequently have a redefinition of BAR affect the
behavior of FOO. This would no longer be allowed, and users of those
implementations would have to change their code.  Others with home-grown
steppers, trace and advise facilities which manipulated the contents of
function cells might have additional work to do.

User code which uses COMPILED-FUNCTION-P would no longer be valid or
portable.

Aesthetics:

Making the concept of a function well-defined will probably be perceived
as a simplification.

It would be cleaner to require all functional arguments to be true
functions, eliminating the use of symbols and lambda-lists in this
context.  However, in this case we felt that the simplification was not
worth a major incompatible change.

Discussion:

The original form of this proposal suggested that APPLY and friends
should take only true functions as the functional argument.  The
current proposal was written after a discussion of the conversion
problems that such an incompatible change might entail. Some cleanup
committee members would prefer the stronger proposal.  

Some committee members have argued for an APPLICABLE-P predicate that
would be true of all objects that can be passed as the functional
argument to APPLY and friends: true functions, lambda lists, and symbols
that are FBOUNDP.  Fahlman believes that this is not terribly useful and
can easily be defined by any user who wants it (or something similar).
In any event, this can be handled in a separate proposal.

Pitman believes that items 4 and 5 are major incopatibilities, and would
prefer if FUNCTION and SYMBOL-FUNCTION be allowed to return things which
are non-functions if those objects can be coerced to functions, and SETF
of SYMBOL-FUNCTION can accept such a coercible object,    and the value
later retrieved will be the given object (not a coerced form of it),
though obviously internally some encapsulation may want to go on for
stock hardware to make function calling fast.

The cleanup committee believes that the definition of COMPILE needs
clarification, but that it should be done in a separate proposal. The
change to COMPILE in this proposal is the minimum necessary.

∂29-May-87  2121	Masinter.pa@Xerox.COM 	Re: Issue GC-MESSAGES (Version 1)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:21:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:19:58 PDT
Date: 29 May 87 21:19 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue GC-MESSAGES (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Thu, 23 Apr 87 23:31 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870529-211958-1267@Xerox>


>Date: Thu, 23 Apr 87 23:31 EDT
>From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

>This seems a little short-sighted.  GC messages aren't necessarily the
>only unsolicited messages.  In the example application you gave, there
>is no reason to treat GC messages differently from other messages.

>Also, a simple on/off switch may be a bit too simple.  Not all systems
>have windows, but for the ones that do a three-state switch could be
>defined in an implementation-independent way: (1) turn the messages
off,
>(2) put them in the typescript, (3) make them visible to the user in a
>way that doesn't interfere with the typescript.  Even some
>teletype-oriented systems are able to implement option 3.

>In some systems it may not be possible to implement this with a
variable,
>since changing the state of the switch may have to communicate with an
>operating system written in some horrible language.  The safest thing
would
>be a macro, whose expansion is system-dependent, and within the dynamic
>extent of the macro's body unsolicited messages are controlled.

>I'm not very optimistic about the possibility of standardizing on this
kind
>of environmental issue, but perhaps some very simple facility to
prevent
>messing up of the screen can be agreed on.

I agree that the GC-MESSAGE issue should be somehow merged with a good
way of dealing with all unsolicited messages.

I can think of other alternatives to the solution proposed by David ("a
macro, whose expansion is system-dependent, and within the dynamic
extent of the macro's body unsolicited messages are controlled.").

I'd like to see the "current practice" section expanded. I know that
Xerox Common Lisp has no unsolicited GC messages, don't know about
Lucid, Gold Hill, Franz, etc.

Kent, since you apparently know what these other systems do ("Other
systems provide ways of enabling or disabling the messages, or
customizing the message which is typed out." perhaps you could
elaborate.)

∂29-May-87  2121	Masinter.pa@Xerox.COM 	Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:21:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:20:25 PDT
Date: 29 May 87 21:20 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT, Message 1
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Message-ID: <870529-212025-1274@Xerox>

Status:  ready for release? [Use ballot]      

Issue:          GET-SETF-METHOD-ENVIRONMENT
References:     GET-SETF-METHOD (CLtL p 187)
Category:       Change
Edit History:   9-Jan-87, Version 1 by Masinter (from Steele list) 
                7-Apr-87, merged with other environment argument issues
                29-May-87, Version 2 by Masinter, extracted again 
			
Problem Description:

If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,

(defmacro special-incf ... (get-setf-method ...) ...)

then  

(macrolet ((test (x) `(car ,x)))
	(special-incf (test z)))

would not "see" the test definition.

Proposal GET-SETF-METHOD-ENVIRONMENT:ADD-ARG:

Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. 

Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.

Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.

The language specification should be explicit on the point that
MACROLET, FLET and LABELS can shadow a SETF method; a SETF method
applies only when the global function binding of the name is lexically
visible.

Rationale:

This was an omission in the original definition of CLtL.

Current Practice:

Many Common Lisp implementations already have this extension, although
some do not.

Adoption Cost:

Some implementations will have to add this feature, although it is not a
major change.

Benefits:

This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.

Conversion Cost:

This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a users program is
very small.

Aesthetics:

SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct. 

Discussion:

The cleanup committee supports this change.

∂29-May-87  2122	Masinter.pa@Xerox.COM 	IGNORE-ERRORS (Version 4)  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:21:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:20:51 PDT
Date: 29 May 87 21:20 PDT
From: Masinter.pa@Xerox.COM
Subject: IGNORE-ERRORS (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-212051-1278@Xerox>


Status:   Ready for release? [Use ballot]

Issue:        IGNORE-ERRORS
References:   p428
Category:     ENHANCEMENT
Edit history: Revision 1 by KMP 02/26/87,
              Revision 2 by KMP 02/26/87 (fixed typo in sample code),
              Revision 3 by KMP 03/11/87 (change to 2nd return value).
              Revision 4 by Masinter 29-May-87 minor formatting

Problem Description:

Common Lisp has no way to trap an error inhibiting entry to the debugger.

Proposal (IGNORE-ERRORS:INTERIM):

Remove the apology for the absence of ERRSET (as on p428 of CLtL)

Introduce a new macro called IGNORE-ERRORS with the syntax

(IGNORE-ERRORS {form}*)
  IGNORE-ERRORS executes the given forms in order from left to right,
  returning all the values returned by the last form (or NIL if there
  are no forms).

  If an error occurs while executing the forms, however, no error
  message is printed; instead control is silently transfered to the
  IGNORE-ERRORS form, which immediately returns a principal value of NIL.
  (The return value convention for any other values besides the principal
  return value in the case of an error is expressly left undefined in order
  to leave room for the full error proposal to attach a useful meaning.)

Rationale:

It will make applications developers rest a bit easier to have an immediate
ironclad guarantee that at least this level of functionality will be in the
next CL spec.

The baroque return value convention used by Maclisp's ERRSET special form
(mentioned on p428 of CLtL) does not extend gracefully to situations multiple
values.

Current Practice:

Most implementations already offer ERRSET, IGNORE-ERRORS, or something similar
in some private package.

Adoption Cost:

We believe this is not difficult to implement in any current implementation.
E.g., IGNORE-ERRORS is trivially implemented in terms of ERRSET...

  (DEFMACRO IGNORE-ERRORS (&BODY FORMS)
    (LET ((TAG (GENSYM)))
      `(BLOCK ,TAG 
	 (ERRSET (RETURN-FROM ,TAG (PROGN ,@FORMS)) NIL)
	 NIL)))

Benefits:

An error proposal is in the works which will offer IGNORE-ERRORS and more.
In case of delays or problems in the acceptance of the spec, applications
developers will not have to worry that they'll end up with no way to trap
errors.

Conversion Cost:

User code currently cannot trap errors at all. Almost by definition, user
code cannot be affected adversely by this change.

Aesthetics:

This primitive is simple, clean, easily learnable, and hopefully very
non-controversial.

Discussion:

KMP thinks that in spite of the perceived optimism about the emerging error
proposal, it's wise to have a safe and credible interim position.
Masinter wonders why KMP isn't spending more time on the error proposal.

The cleanup committee endorses this extension.

∂29-May-87  2123	Masinter.pa@Xerox.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:23:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:22:29 PDT
Date: 29 May 87 21:22 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
To: CL-Cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-212229-1283@Xerox>

Status:	      I edited this to put some things in different sections
(Aesthetic arguments under aesthetics, cost of converting existing code
into that section) and added some wording to meet Scott's "to prevent
confusion".

		Ready for release? [Use ballot]

Issue:        KEYWORD-ARGUMENT-NAME-PACKAGE
References:   Lambda Expressions (CLtL pp60-64)
Category:     CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
	         29-Apr-87, Version 2 by Pitman
              11-May-87, Version 3 by Moon
              29-May-87, Version 4 by Masinter

Problem Description:

CLtL says that only keyword symbols can be used as non-positional
argument
names in &key parameter specifiers.

As Common Lisp is currently defined, if someone wants to define a
function that accepts named (rather than positional) arguments whose
names are symbols in packages other than the KEYWORD package, they
cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.  

Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]

 
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)

Remove restrictions on the package of non-positional argument names;
allow any symbol, including NIL.  That is: 

If, following an &key, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword-symbol with the same print name as the variable is created and
is used as the keyword-indicator in function calls.  The only way to get
a non-positional-argument-name that is not a keyword symbol is to use
the (indicator variable) syntax in the function's lambda list.  The
keyword-indicator can be any symbol, not just a keyword.

Test case:

(DEFUN RESULT (&KEY (((SECRET-KEYWORD SECRET) NIL) AMOUNT)
    (FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))

(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"


Rationale:

The "rationale" box on p.62 of CLtL is an argument in favor of requiring
non-positional argument names to be symbols, and not allowing numbers,
but does not speak to the issue of whether or not those symbols should
be further restricted to be keywords.

The desire for non-positional arguments whose names are not keyword
symbols
arises when the set of non-positional arguments accepted by a function
is
the union of the sets of non-positional arguments accepted by several
other
functions, rather than being enumerated in a single place.  In this
case,
it becomes desirable to use packages to prevent accidental name clashes
among non-positional argument names of different functions.

One example of a Common Lisp application that requires this capability
is
the draft proposal for an object-oriented programming standard (CLOS).
It will
have generic functions that accept non-positional arguments and pass
them on
to one or more applicable methods, with each method defining its own set
of
arguments that it is interested in.  If this proposal is not adopted,
either
the non-positional argument names will be required to be keywords, which
will require the methods to have non-modular knowledge of each other in
order to avoid name clashes, or the methods will have to be defined with
an
ad hoc mechanism that duplicates the essential functionality of &key but
removes the restriction.

A second example of a Common Lisp application that requires this
capability
is private communication channels between functions.  Suppose a public
routine MAKE-FOO needs to accept arbitrary keywords from the caller and
passes those keywords along to an internal routine using keywords of its
own.
   (IN-PACKAGE 'FOOLAND)
   (DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
     (APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))
This could be done without fear that the use of EXPLICIT T would
override
some keyword in keyword-value-pairs, since the only way that could
happen is
if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL), or if the user
was
programming explicitly in the FOOLAND package, either of which is an
implicit
admission of willingness to violate FOOLAND's modularity.

Documentation Impact:

The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in
understanding
the impact of the proposal.

  Change wording which refers to non-positional arguments as being
introduced
  by keyword symbols to simply refer to those arguments being introduced
by
  symbols. For example, in the middle of p.60, the sentence:
    ... each -keyword- must be a keyword symbol, such as :start.
  would become
    ... each -keyword- must be a symbol.
  Also, the word "keyword" in the first complete sentence on p.62 would
  be changed to "symbol" for similar reasons.

  Add extra wording on p.60 to explain that by convention keyword
symbols
  are normally used as non-positional argument names, and that all
functions
  built into the Common Lisp language follow that convention.  A
language
  manual might or might not choose to describe the circumstances in
which
  it is appropriate not to follow this convention.

  Add examples to illustrate this behavior. For example, on p.64 the
  following examples might be added:

    ((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
    => (1 2 6 NIL)

    ((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
    => (1 2 6 NIL)

Current Practice:

We do not currently know of an implementation that enforces the
restriction
that this proposal seeks to remove.

Some implementations have bugs that prevent NIL from working as a
keyword
argument name, but allow all non-NIL symbols. (One Symbolics version
that
was checked had this bug.)

Adoption Cost:

Some implementors might have to rearrange their error checking slightly,
but it should be very easy.

Benefits:

This will help with the object-oriented programming standard, among
other
things.

Conversion Cost:

None--no existing programs will stop working.  

Aesthetics:

The restriction of &key to only keyword symbols is arbitrary and
unnecessary.

There will probably be an argument about whether the restriction is
more esthetic or less esthetic than the freedom, but in either case
the aesthetic effect is slight.

In any case, users who do not want to use the extended functionality
can generally avoid it.

Discussion:

Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.

If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.

Some members of the cleanup committee would just as soon exclude NIL as
a legal keyword-indicator. It might catch some errors, but is possibly
otherwise an odd restriction. Disallowing NIL would reduce the adoption
cost for some implementations.

The cleanup committee supports this change.

∂29-May-87  2124	Masinter.pa@Xerox.COM 	Issue: PATHNAME-STREAM (Version 2)   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:24:43 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:23:17 PDT
Date: 29 May 87 21:23 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-STREAM (Version 2)
To: CL-Cleanup@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
Message-ID: <870529-212317-1288@Xerox>

Status:          Ready to release?

Issue:         PATHNAME-STREAM

References:    PATHNAME (p.413), also the introductory text right above
               it on the same page.
               Derived references: PARSE-NAMESTRING (p.414),
               MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
               OPEN (p.418), WITH-OPEN-FILE (p.422),
               RENAME-FILE (p.423), DELETE-FILE (p.424)

Edit History:  Version 1 by Moon 11-May-87
               Version 2 by Masinter 29-May-87 (minor editing)

Category:     	CHANGE/CLARIFICATION

Problem Description:

The PATHNAME function as documented in CLtL is impossible to implement.
CLtL says that a stream can be used as an argument and converted to a
pathname, but pathnames only name files, not other sources or sinks of
data that streams might be connected to.

Proposal PATHNAME-STREAM:FILES-ONLY:

Specify that if a stream is used as a pathname, it must be a stream that
is or was open to a file. For example, it is an error to attempt to
obtain a pathname from a two-way-stream or a string-stream.

Rationale:

This is probably what the designers of Common Lisp intended. This is the
only thing that can be implemented without large changes to the language
such as extending pathnames to things other than files. 

Current Practice:

Some systems signal an error if a non-file stream is used as a pathname.
Others may do something else, but since the proposal is to define this
to be "is an error", current practice seems irrelevant.

Adoption Cost:

Since the proposal says only "is an error" rather than "signals an
error", no implementations need change.

Benefits: Description of pathname functions will make more sense.

Conversion Cost: We believe no existing user code relies on any values.

Aesthetics: Makes language a little cleaner.

Discussion: The cleanup committee supports this clarification.


∂29-May-87  2125	Masinter.pa@Xerox.COM 	Issue: PATHNAME-SYMBOL (Version 2)   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:25:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:23:41 PDT
Date: 29 May 87 21:23 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-SYMBOL (Version 2)
To: CL-Cleanup@sail.stanford.edu
CC: Masinter.pa@Xerox.COM
Message-ID: <870529-212341-1290@Xerox>

Status:		Merged comments in. Ready for release? [Use ballot]

Issue:		PATHNAME-SYMBOL

References:   	PATHNAME (p.413),
                Derived references: PARSE-NAMESTRING (p.414),
                MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
                NAMESTRING etc. (p.417).

Edit History:  Version 1 by Moon 11-May-87
               Version 2 by Masinter 29-May-87


Category:     	(Incompatible) CHANGE

Problem Description:

Some Common Lisp functions are specified to accept a symbol where a 
pathname is expected.  Some others (OPEN, WITH-OPEN-FILE, DELETE-FILE,
and RENAME-FILE) are not specified to accept a symbol.


Proposal PATHNAME-SYMBOL:NO

Never allow symbols where pathnames are expected.

Rationale:

The feature of accepting a symbol was copied by Common Lisp from
Zetalisp,
which in turn copied it from Maclisp.  The reason Maclisp allowed a
symbol
here was that it did not have strings at all.  However, the feature has
been
long since removed from Zetalisp, since it was found to be a source of
bugs
and not to be useful.  I suspect this feature was removed from Zetalisp
before Common Lisp was defined, but due to the poor state of Zetalisp
documentation at the time the change was overlooked by the designers of
Common Lisp.

One example of the type of bug caused by this occurs when NIL is
erroneously
substituted for a pathname, perhaps because GETHASH or ASSOC didn't find
a
table entry that was expected to exist and returned -false-.  In systems
that accept symbols as pathnames, this causes a reference to a file
named
"NIL" on some perhaps unexpected directory.

Current Practice:

Varies.  Some implementations allow symbols here, some don't.  Symbolics
doesn't allow symbols except in PARSE-NAMESTRING and MERGE-PATHNAMES,
and allowing them there is probably a bug in the implementation.

Adoption Cost:

It's easy to change implementations to stop accepting symbols.  Since
this
appears to be an "is an error" rather than "signals an error" situation,
no implementation change is actually necessary.

Benefits:

Pathname functions will be more consistent.  In implementations that
check the type of this argument, program error checking will be
improved. In dealing with case-sensitive file systems, users won't do
(load'foo) and wonder why file "FOO" (rather than "foo") is not found.

Conversion Cost:

Some users might be using symbols as pathnames, in implementations where
that works, and they would have to switch to using strings. For example,
some users are used to type interactively (LOAD 'FOO) to mean (LOAD
"FOO").

Aesthetics: Improved by the change.

Discussion:

Some users have reported the "fact" that MERGE-PATHNAMES was in error
because it accepted symbols.

The Cleanup committee supports this change.

∂29-May-87  2127	Masinter.pa@Xerox.COM 	Status [Part 1]  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:27:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:26:19 PDT
Date: 29 May 87 21:26 PDT
From: Masinter.pa@Xerox.COM
Subject: Status [Part 1]
To: cl-cleanup@sail.stanford.edu
Message-ID: <870529-212619-1296@Xerox>

I wanted to get this part out; I haven't updated my status file for the
issues beyond PEEK-CHAR-READ-CHAR-ECHO. I will mail a ballot [Part 1]
separately.


ADJUST-ARRAY-DISPLACEMENT (revision 1)
	(Standardize interaction of adjust-array and displacement)
	Revision 1 by SEF, 18-Apr-87  
	Comment by Moon 21 Apr 87
	Ready for release?

ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
	(Extend adjust-array so its OK on non-adjustable arrays, just
	makes a new array.)
	Not ready for release
	Submitted by KMP 22-Apr-87
	comments from Moon, JonL, SEF generally against current form

AREF-1D (Version 1)
	(Add a new function for accessing arrays with row-major-index)
	Submitted 22-Apr-87 by KMP
	Some discussion, no strong objection
	Ready for release?

ASSOC-RASSOC-IF-KEY
	(Extend ASSOC-IF, RASSOC-IF, ASSOC-IF-NOT,  etc. 
	to have a :KEY keyword)
	Submitted 22-Apr-87 by KMP

COMPILER-WARNING-BREAK (revision 2)
	Not released.
	Questions on interaction with condition proposal.
	Needs volunteer to pursue.

COMPILER-WARNING-STREAM (Revision 3)
	(Compiler warnings are printed on *ERROR-OUTPUT*)
	Released.
	(Version 4, submittted by SEF was withdrawn --
	consider DRIBBLE as a separate issue) 

DEFVAR-INITIALIZATION (Revision 3)
	((DEFVAR var) doesn't initialize)
	Released
	remailed 7-apr-87

DEFVAR-INIT-TIME (Version 2)
	(DEFVAR initializes when evaluated, not later.)
	Submitted 23-Apr-87, Version 1 by Pitman
	Version 2 29-May-87 by Masinter
	Ready for release?
	
DO-SYMBOLS-DUPLICATES (Version 2)
	(can DO-SYMBOLS see the same symbol twice?)
	Version  2 by Masinter
	Ready for release?
	Question "is it really inefficient to require non-duplicates?"
	Add duplicates-allowed keyword?
	
ENVIRONMENT-ARGUMENTS (revision 1)
	SEF summarized issues 18-Apr
	Decided to separate again into
	GET-SETF-METHOD-ENVIRONMENT,
	MACRO-FUNCTION-ENVIRONMENT 
         SPECIAL-FORM-SHADOW
	Not released

FLET-IMPLICIT-BLOCK (Version 5)
	(do FLETs have implicit named blocks around them?)
	Discussion & agreement on cl-cleanup.
	ready for release?

FORMAT-ATSIGN-COLON (Version 3)
	Released.
	(final form, mailed 17-Apr-87)

FORMAT-NEGATIVE-PARAMETERS
	Not written up yet; mail 19-May by KMP

FORMAT-OP-C (Version 2)
	(What does ~C do?)
	Needs rewording to say "change CL" rather than "change CLtL"
	remove mention of ~Q 
	Not yet released

FUNCTION-TYPE (Version 4)
	(Change definition of FUNCTIONP, function type ...)
	By Masinter 29-May-87 
	Ready for release?

GET-SETF-METHOD-ENVIRONMENT (Version 2)
	(Environment argument for GET-SETF-METHOD)
	By Masinter 29-May-87 
	Ready for release?

GC-MESSAGES (version 1)
	(Control over unsolicited GC messages in typescript)
	Submitted by Pitman 23-Apr-87
	In discussion: merge with other controls for
	unsolicited messages?

IF-BODY (Version 5)
	(extend IF to implicit progn if more than one ELSE form?)
	General agreement to recommend against.
	Version 5 mailed by KMP , 29-Apr-87
	Awaiting a version which KMP and SEF agree
	is "fair"

IGNORE-ERRORS (Version 4)
	by Masinter 29-May-87
	Ready for release?

IMPORT-SETF-SYMBOL-PACKAGE (Version 4)
	Version 3 Released
	Removed confusing "To further clarify: " sentence
	re-release as Version 4

KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
	by Masinter 29-May-87
	Ready for release?

PATHNAME-STREAM (Version 2)
	by Masinter 29-May-87
	Ready for release?

PATHNAME-SYMBOL (Version 2)
	by Masinter 29-May-87
	Ready for release?

PEEK-CHAR-READ-CHAR-ECHO (Version 1)
	Agreed to be controversial
	Withdraw?

∂29-May-87  2128	Masinter.pa@Xerox.COM 	***BALLOT *** PART 1 *** BALLOT *** PART 1 *** 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:28:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:27:25 PDT
Date: 29 May 87 21:27 PDT
From: Masinter.pa@Xerox.COM
Subject: ***BALLOT *** PART 1 *** BALLOT *** PART 1 ***
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870529-212725-1304@Xerox>


Please vote on the following issues which are open. "Release" means to
release the document to X3J13 for discussion & voting.


ADJUST-ARRAY-DISPLACEMENT (revision 1)
[ ] Release as is [ ] Comments follow in mail to cl-cleanup

ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup


AREF-1D (Version 1)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup

ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup

DEFVAR-INIT-TIME (Version 2)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup

DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [ ] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [ ] Other:
comments follow in mail to cl-cleanup

FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup

FUNCTION-TYPE (Version 4)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup

GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup

IF-BODY (Version 5)
BALLOT: [ ] Release as is [ ] Wait for version that SEF and KMP agree is
"fair".

IGNORE-ERRORS (Version 3)
BALLOT: [ ] Release as is [ ] Wait for error proposal [ ] Comments
follow in mail to cl-cleanup

KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup

PATHNAME-STREAM (Version 2)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup

PATHNAME-SYMBOL (Version 2)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup

PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [ ] Withdraw from consideration, await new proposal [ ] Comments
follow in mail to cl-cleanup

∂29-May-87  2133	Masinter.pa@Xerox.COM 	Issue: COMPILER-WARNING-STREAM (Version 5)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  21:33:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 21:32:30 PDT
Date: 29 May 87 21:32 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: COMPILER-WARNING-STREAM (Version 5)
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-213230-1315@Xerox>

Status:  ready for re-release. (I almost called this Version 3, but with
the addition of the comments of DRIBBLE it really is different.)

Issue:        COMPILER-WARNING-STREAM
References:   COMPILE (p438), COMPILE-FILE (p439)
Category:     CLARIFICATION/CHANGE
Edit history: Revision 1 by KMP 02/27/87
              Revision 2 at committee meeting 15-Mar-87 14:18:56
              Revision 3 reformat by Masinter 15-Mar-87 17:42:10
              Revision 4 by Fahlman, incorporate Dribble
              Revision 5 by Masinter, 29-May-87
                revert to version 3 with comment about Dribble.

Problem Description:

The description of the COMPILE and COMPILE-FILE functions does not
explicitly permit them to print warnings. If this is to be allowed, it
should be an explicitly expressed part of the contract.

Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)

COMPILE and COMPILE-FILE are permitted to output warnings; warnings
should go to the stream that is the value of *ERROR-OUTPUT*.

Rationale:

Compiler warning output is a widely accepted extension to the
compilation. Warnings that come via the WARN function will go to the
stream that is the value of *ERROR-OUTPUT*.

Current Practice:

Some implementations send compiler warning output to *ERROR-OUTPUT*.
Other implementations send it to *STANDARD-OUTPUT*.

Adoption Cost:

In most cases, the change to the compiler to redirect output is expected
to be very slight.

Benefits:

Currently, it is difficult to redirect the output of COMPILE and
COMPILE-FILE because it isn't clear where it's directed.

Conversion Cost:

Most user programs that care are probably already tolerant of both
situations or naively expect that output will go to *ERROR-OUTPUT*. As
such, most users will probably perceive this as a clarification.

Aesthetics:

Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.

Discussion:

This was a problem in adapting MACSYMA to Common Lisp because Macsyma
provides alternate user interfaces to the compiler which it needs to be
able to control.

The committee considered extending the proposal to describe the
interaction with DRIBBLE on the warning output, but found that DRIBBLE
was so underspecified as to make the task impossible. DRIBBLE should be
considered in a separate proposal.

The cleanup committee supports this change as stated.

∂29-May-87  2214	Masinter.pa@Xerox.COM 	Issue: REMF-DESTRUCTURING-UNSPECIFIED (Version 1)   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  22:14:05 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:12:59 PDT
Date: 29 May 87 22:12 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: REMF-DESTRUCTURING-UNSPECIFIED (Version 1)
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870529-221259-1332@Xerox>

Status: I cannot find any discussion on this topic. 

Issue:     REMF-DESTRUCTION-UNSPECIFIED
References: GET (SETF), REMPROP, GETF (SETF), REMF, pp. 165-167.
	   NREVERSE, p. 248.
	   DELETE, DELETE-IF, DELETE-IF-NOT, DELETE-DUPLICATES,
	   NSUBSTITUTE, NSUBSTITUTE-IF, NSUBSTITUTE-IF-NOT, pp. 254-256.
	   NCONC, NRECONC, p. 269.
	   NBUTLAST, p. 271.
	   NSUBST, NSUBST-IF, NSUBST-IF-NOT, p. 274.
	   NUNION, NINTERSECTION, NSET-EXCLUSIVE-OR, p. 276-279.

Edit history:	Version 1 by DLA@SCRC-STONY-BROOK.SCRC.Symbolics.COM


Problem Description:

Currently, the exact nature of the list modification
performed by REMF and REMPROP is not specified.  Conversation on the
Common-Lisp mailing list has made it clear that this situation is not
good.  The list modification allowed should either be specified, or
explicitly documented as unspecified and up to the individual
implementation.  If the list modification is specified, then programmers
can rely on the specification.  If it is unspecified, then implementors
can take advantage of that to make their implementation more efficient.

This argument can be made for most of the destructive functions
specified above, and possibly others, so they are included as
references.

Category:  clarification

Proposal:  REMF-DESTRUCTION-UNSPECIFIED:DONT-SPECIFY

I propose that CLtL's documentation on each of the above functions
include a statement such as the following:  "This function performs a
modification to the top-level [list] structure of its argument(s). 
Different implementations may choose different modifications of the list
structure, as long as the function otherwise fulfills its contract.  It
is an error to rely on the list destruction being performed in any
particular way.  Any references to the list structure of the argument(s)
other than the value(s) returned are therefore undefined after the function
returns."

Rationale:  

Benefits: 

Implementations can improve performance of
many of the referenced functions when they are not under the constraint
to implement them in a specified fashion or "in the most logical
fashion".  For example, on the Symbolics 3600, DELETE of a cdr-coded
list could use the implementation primitive %CHANGE-LIST-TO-CONS rather
than RPLACD to avoid creating forwarding pointers.  As another example,
all of the destructive operations which remove objects could remove CAR
pointers to removed objects which are more volatile than the list
itself, assisting the garbage collector.

Most of the referenced functions implement abstract operations, for
example REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.

Aesthetics: 

This change would not affect programs coded with "good programming
practice".  That is, only programs which rely on currently undocumented
features would be in any danger of breaking.  In fact, those programs
are currently in such danger, and this change to the documentation would
just publicize it.  The clarification would ENCOURAGE good programming
practice by warning people to only obey the published contract of the
referenced functions.

Current practice:

Symbolics Common Lisp already implements some of the functions in a
non-obvious fashion.  For example, in Symbolics Common Lisp:

    (setq foo (list 'a 'b 'c))   ==> (a b c)
    (setq bar (cdr foo))         ==> (b c)
    (setq foo (delete 'b foo))   ==> (a c)
    bar                          ==> ((c)) ; most people would guess (b c).
    (eq (cdr foo) (car bar))     ==> t

Cost of adopting change: 
There is no cost of adopting this change to developers.
------------------------------------------------------------
Alternative proposal:  REMF-DESTRUCTION-UNSPECIFIED:DO-SPECIFY

Some or all of the functions could be documented to
perform the list destruction in a specified manner.

Rationale and Advantages:  (1) The "additional features" may be more
useful to some programmers.  (2) Programmers may expect the functions to
do the "expected" destructive operation.  (3) Compatibility with other
dialects.  For example, it may be easier to port a Zetalisp program to
Common-Lisp if REMPROP returns a sublist pointer as defined in Zetalisp.

If this alternative is pursued, then many implementations may be forced
to incompatibly change what their functions do.  This may break existing
programs and may cause the implementation to have poorer performance.


∂29-May-87  2310	Masinter.pa@Xerox.COM 	Issue: TAILP-NIL 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  23:09:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:36:59 PDT
Date: 29 May 87 22:36 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: TAILP-NIL
to: CL-cleanup@Sail.stanford.edu
Message-ID: <870529-223659-1341@Xerox>

I've been putting this issue in the status list, but had never mailed it
out. It is not yet in proper format. 

For the record:


Issue: TAILP-NIL
Reference: Steele p.275
Category: clarification
Description:
The description of tailp in Steele differs from current implementations
in the case where the first argument is NIL. In particular, the second
sentence "Another way to look at this is tailp is true if (nthcdr n
list) is sublist, for some value of n." does not accurately describe
current practice for the case where sublist is nil.
The behavior of TAILP on circular structures is also unspecified, e.g.,
is  (tailp '() '#0=(x . #0#)) meaningful?

Proposal: TAILP-NIL:RETURN-NIL

Clarify that (TAILP NIL X) returns NIL for all lists X, and that tailp
must be true-false-indeterminate equivalent to 
(defun tailp (x y)
   (and x y (or (eq x y) (tailp x (cdr y)))))

i.e., if the second argument is circular and the first argument is not a
"tail" of the non-circular part of it, tailp may loop indefinitely.

∂29-May-87  2310	Masinter.pa@Xerox.COM 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  23:10:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:45:46 PDT
Date: 29 May 87 22:45 PDT
From: Masinter.pa@Xerox.COM
Subject:  Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 1)
In-reply-to: Masinter.pa's message of 29 May 87 22:12 PDT
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <870529-224546-1347@Xerox>

I had written too many destructuring-bind's recently, and mistyped the
issue name as REMF-DESTRUCTURING-UNSPECIFIED.  Sorry.


∂29-May-87  2310	Masinter.pa@Xerox.COM 	Status, Part 2   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  23:10:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:42:28 PDT
Date: 29 May 87 22:42 PDT
From: Masinter.pa@Xerox.COM
Subject: Status, Part 2
To: cl-cleanup@sail.stanford.edu
Message-ID: <870529-224228-1344@Xerox>

This is part 2 of the status file. Please mail any corrections you have.
(I was closer to being done than I thought!)

PRINC-CHARACTER (Version 3)
	Mailed by KMP 29-Apr-87.
	Ready for release?

PROCLAIM-LEXICAL  (Version 1)
	In discussion
	Reaching convergence
	Need volunteer to merge comments into new version

PROMPT-FOR (Version 1)
	Agreed to be controversial
	Withdraw?

PUSH-EVALUATION-ORDER
	(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
	Not yet submitted.

REMF-DESTURCTION-UNSPECIFIED (Version 1)
	Submitted by DLA
	Discussion?
	Not ready for release.

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
	(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
	Version 2 by KMP 28 Apr 87 
	In discussion, no clear consensus

SHARPSIGN-BACKSLASH-BITS
	(What does C-META-H-X mean?)
	Mild for this proposal, but preference for
	removing FONT and BITS attribute 

SHARPSIGN-PLUS-MINUS-NUMBER
	Discussed, without general agreement.
	Withdraw?

SHARPSIGN-PLUS-MINUS-PACKAGE
	Seems like general agreement for :KEYWORD.
	Need to remove other options from proposal.

TAILP-NIL
	Not yet submitted.
	Needs volunteer to format.

UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
	In discussion
	Need volunteer to summarize issues.



∂29-May-87  2310	Masinter.pa@Xerox.COM 	***BALLOT *** PART 2 *** BALLOT *** PART 2 *** 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 May 87  23:10:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 MAY 87 22:42:47 PDT
Date: 29 May 87 22:42 PDT
From: Masinter.pa@Xerox.COM
Subject: ***BALLOT *** PART 2 *** BALLOT *** PART 2 ***
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870529-224247-1345@Xerox>

I found that I had fewer ballot items for the remaining issues on the
list -- just to liven it up, I stuck in a couple of ringers.


PUSH-EVALUATION-ORDER (not submitted)
BALLOT: [ ] (push first second) [ ] (push second first) [ ] unspecified
[ ] Proposal follows in mail to cl-cleanup

PROMPT-FOR (revision 1)
BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ]  GENERALIZE [ ] MODIFIED [ ] UNCHANGED [ ] Something else [
] Undecided

SHARPSIGN-BACKSLASH-BITS
BALLOT: [ ] Release as is [ ] Withdraw this proposal[ ] Want proposal
for removing BITS and FONT from standard [ ] Want fuller character
proposal [ ] Comments follows in mail to cl-cleanup

∂30-May-87  0715	MATHIS@ADA20.ISI.EDU 	Re: barrage of mail coming  
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 30 May 87  07:15:38 PDT
Date: 30 May 1987 07:15-PDT
Sender: MATHIS@ADA20.ISI.EDU
Subject: Re: barrage of mail coming
From: MATHIS@ADA20.ISI.EDU
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]30-May-87 07:15:01.MATHIS>
In-Reply-To: <870529-211317-1248@Xerox>

Larry,

How are we going to send this to the general membership of X3J13?
I can send you updated mailing labels.  I also think that
electronic mail would be good.

I was thinking about the following style agenda for Boston:

Tuesday Morning -- clean-up committee

Tuesday afternoon -- Japanese characters presentation, X windows
presentation, administrative work of committee

Wednesday Morning -- clean-up committee

Wednesday afternoon -- remaining stuff

How does that sound to you?

Also, is it useful to have a meeting of this committee on Monday.
We picked Tuesday and Wednesday for the main meeting so we could
use Monday for subcommittees if needed.

Bob

∂31-May-87  2051	masinter.pa@Xerox.COM 	ballots, meeting, etc.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 31 May 87  20:50:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 31 MAY 87 20:50:05 PDT
From: masinter.pa@Xerox.COM
Date: 31 May 87 20:49:38 PDT
Subject: ballots, meeting, etc.
To: cl-cleanup@sail.stanford.edu
Message-ID: <870531-205005-2070@Xerox>

I'd like to ask you, if you think you might have some opinions on some
or all of the issues, but don't have the time to respond now, to please
reply to that effect. I don't want to mail out proposals unless there is
consensus that they are ready for release.

MEETING:

I would like to get together Monday for a subcommittee meeting. I'd like
to discuss some of the more serious open issues and see how much
progress we can make. (PROCLAIM-LEXICAL seems like it might benefit from
a face-to-face discussion.) 

What do you think about taking some time to go over the ISSUES.TXT file
and getting some directions on them for us to proceed?

Other agenda items?

I expect to be flying in on Sunday, and so would be available all day
Monday. We probably will need to dig up a meeting room somewhere, too.

∂01-Jun-87  1217	JAR@AI.AI.MIT.EDU 	Status, Part 2  
Received: from AI.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87  12:17:39 PDT
Date: Mon,  1 Jun 87 15:19:35 EDT
From: "Jonathan A. Rees" <JAR@AI.AI.MIT.EDU>
Subject:  Status, Part 2
To: Masinter.pa@XEROX.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-reply-to: Msg of 29 May 87 22:42 PDT from Masinter.pa at Xerox.COM
Message-ID: <208084.870601.JAR@AI.AI.MIT.EDU>

    Date: 29 May 87 22:42 PDT
    From: Masinter.pa at Xerox.COM

    PROCLAIM-LEXICAL  (Version 1)
    	In discussion
    	Reaching convergence
    	Need volunteer to merge comments into new version

I think that "reaching convergence" is a little too optimistic.

∂01-Jun-87  1449	edsel!kent-state!eb@navajo.stanford.edu 	AREF-1D  
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87  14:49:34 PDT
Received: by navajo.stanford.edu; Mon, 1 Jun 87 14:47:00 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA09873; Mon, 1 Jun 87 14:11:32 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
	id AA07192; Mon, 1 Jun 87 14:11:22 PDT
Date: Mon, 1 Jun 87 14:11:22 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706012111.AA07192@kent-state.edsel.uucp>
To: navajo!cl-cleanup%sail@navajo.stanford.edu
Subject: AREF-1D

I agree with Version 1, with one exception.  I prefer the name
ROW-MAJOR-AREF to AREF-1D.  With this change I support releasing this
proposal.

∂01-Jun-87  1450	edsel!kent-state!eb@navajo.stanford.edu 	PATHNAME-SYMBOL    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87  14:50:09 PDT
Received: by navajo.stanford.edu; Mon, 1 Jun 87 14:47:14 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA09918; Mon, 1 Jun 87 14:27:22 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
	id AA07224; Mon, 1 Jun 87 14:27:11 PDT
Date: Mon, 1 Jun 87 14:27:11 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706012127.AA07224@kent-state.edsel.uucp>
To: navajo!cl-cleanup%sail@navajo.stanford.edu
Subject: PATHNAME-SYMBOL

If a symbol can be coerced into a string, and a string can be coerced
into a pathname, I see no reason why a symbol should not be coerced
into a pathname.  It has limited usefulness, but I believe that
coercions should be transitive.  I believe that the aesthetics of the
language will be harmed by disallowing symbols as pathnames.

I'm not going to put up a fight to stop this change, but I would like
to see the minority view stated in the proposal.

∂01-Jun-87  1450	edsel!kent-state!eb@navajo.stanford.edu 	***BALLOT *** PARTS 1 AND 2 *** BALLOT *** PARTS 1 AND 2 ***    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 1 Jun 87  14:50:41 PDT
Received: by navajo.stanford.edu; Mon, 1 Jun 87 14:47:45 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA09961; Mon, 1 Jun 87 14:39:45 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
	id AA07238; Mon, 1 Jun 87 14:39:33 PDT
Date: Mon, 1 Jun 87 14:39:33 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706012139.AA07238@kent-state.edsel.uucp>
To: navajo!cl-cleanup%sail@navajo.stanford.edu
In-Reply-To: navajo!Masinter.pa@Xerox.COM's message of 29 May 87 21:27 PDT <870529-212725-1304@Xerox>
Subject: ***BALLOT *** PARTS 1 AND 2 *** BALLOT *** PARTS 1 AND 2 ***

ADJUST-ARRAY-DISPLACEMENT (revision 1)
[x] Release as is [ ] Comments follow in mail to cl-cleanup

ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [x] Withdraw [ ] Comments follow in mail to cl-cleanup


AREF-1D (Version 1)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup

ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

DEFVAR-INIT-TIME (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [x] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [ ] Other:
comments follow in mail to cl-cleanup

FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

FUNCTION-TYPE (Version 4)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

IF-BODY (Version 5)
BALLOT: [ ] Release as is [x] Wait for version that SEF and KMP agree is
"fair".

IGNORE-ERRORS (Version 3)
BALLOT: [ ] Release as is [x] Wait for error proposal [ ] Comments
follow in mail to cl-cleanup

KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

PATHNAME-STREAM (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

PATHNAME-SYMBOL (Version 2)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup

PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [x] Withdraw from consideration, await new proposal [ ] Comments
follow in mail to cl-cleanup

PROMPT-FOR (revision 1)
BALLOT: [x] Withdraw [ ] Comments follow in mail to cl-cleanup

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ]  GENERALIZE [ ] MODIFIED [x] UNCHANGED [ ] Something else [
] Undecided

SHARPSIGN-BACKSLASH-BITS
BALLOT: [x] Release as is [ ] Withdraw this proposal[ ] Want proposal
for removing BITS and FONT from standard [ ] Want fuller character
proposal [ ] Comments follows in mail to cl-cleanup

∂01-Jun-87  1650	Gregor.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE (version 4)   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87  16:50:45 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 87 16:47:09 PDT
Date: 1 Jun 87 16:46 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE (version 4)
In-reply-to: Masinter.pa's message of 29 May 87 21:18 PDT
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870601-164709-3170@Xerox>

I don't like the current, 'concession to backward compatibility' which
allows apply, mapcar etc. to accept things which are not functionp.  I
bet the amount of code which would be affected by this change is small,
and if we decide to make it now, vendors can make their systems warn
about it for a while, so the transition should not be too painful.

Face it, more code is going to be written than has already been written,
lets look to the future, not the past.

Now if only this argument could sway the Lisp-1 issue...

∂01-Jun-87  1715	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Issue: FUNCTION-TYPE (version 4)  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  17:14:59 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161104; Mon 1-Jun-87 20:14:13 EDT
Date: Mon, 1 Jun 87 20:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-TYPE (version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870601-164709-3170@Xerox>
Message-ID: <870601201413.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 1 Jun 87 16:46 PDT
    From: Gregor.pa@Xerox.COM

    I don't like the current, 'concession to backward compatibility' which
    allows apply, mapcar etc. to accept things which are not functionp.  I
    bet the amount of code which would be affected by this change is small,
    and if we decide to make it now, vendors can make their systems warn
    about it for a while, so the transition should not be too painful.

This kind of warning strategy isn't very effective for things that cannot
be detected at compile time.  A run time warning tends to be a big annoyance
and may not tell you just where in your program was responsible for the
effect.

∂01-Jun-87  1810	Pavel.pa@Xerox.COM 	AREF-1D   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87  18:09:44 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 87 18:07:53 PDT
Date: 1 Jun 87 18:07 PDT
From: Pavel.pa@Xerox.COM
Subject: AREF-1D
To: cl-cleanup@sail.stanford.edu
Message-ID: <870601-180753-3283@Xerox>

I favor this proposal in principal, but would much rather use the more
mnemonic name ROW-MAJOR-AREF instead of AREF-1D.

	Pavel

∂01-Jun-87  1822	Pavel.pa@Xerox.COM 	DO-SYMBOLS-DUPLICATES    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87  18:22:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 87 18:21:57 PDT
Date: 1 Jun 87 18:21 PDT
From: Pavel.pa@Xerox.COM
Subject: DO-SYMBOLS-DUPLICATES
To: CL-Cleanup@SAIL.Stanford.Edu
Message-ID: <870601-182157-3303@Xerox>

I think that I favor something like the DO-SYMBOLS:ADD-KEYWORD proposal,
but I'm not willing to vote for it as it.  The problem is that the
example in the proposal contains a keyword not described by the
proposal, namely :EXTERNAL-ONLY.  Also, the proposal does not specify
which, if any, of the arguments following the return-value expression
are to be evaluated.  In short, it is not a complete proposal.

I like the idea of having a single package-iteration macro, flushing
ones like DO-EXTERNAL-SYMBOLS.  Probably the best way to do this is to
have some set of orthogonal attributes selectable by keyword.  It would
be nice if the same keywords were the arguments to some functional
interface to package-iteration, such as the MAPATOMS function in
Interlisp.  Then the flavor of the iterative macro would be more like
WITH-OPEN-FILE, whose options are just those available from OPEN.

In any case, I think that allowing the duplicates is probably the wrong
thing in general, so I can't vote in favor of either of the two
proposals.

	Pavel

∂01-Jun-87  1830	Pavel.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE (version 4)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 1 Jun 87  18:29:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 JUN 87 18:29:18 PDT
Date: 1 Jun 87 18:29 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE (version 4)
In-reply-to: Masinter.pa's message of 29 May 87 21:18 PDT
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870601-182918-3312@Xerox>

Typo in the proposal:

``it is not synonomous to the use of the type FUNCTION'' should be ``it
is not synonomous with the use of the type FUNCTION''.


∂01-Jun-87  2041	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: TAILP-NIL  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  20:41:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161243; Mon 1-Jun-87 23:36:32 EDT
Date: Mon, 1 Jun 87 23:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL
To: CL-cleanup@Sail.stanford.edu
In-Reply-To: <870529-223659-1341@Xerox>
Message-ID: <870601233632.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

I vote against releasing this issue until its writeup is in proper format.

When you write the current practice section, mention that Symbolics
follows the second of the two contradictory sentences in the tailp
writeup, hence (tailp nil <anything>) => t.  This may mean that current
practice is not uniform.

For history, you can mention that the unambiguous definition in the
MIT Lisp Machine Manual (I consulted the fourth edition) would require
(tailp nil <anything>) => nil.

I personally don't care which disambiguation is adopted.  If the writeup
includes a proposal to eliminate the function, I will vote for that, since
I've never understood what use tailp is.

∂01-Jun-87  2047	KMP@STONY-BROOK.SCRC.Symbolics.COM 	IGNORE-ERRORS (Version 4)    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  20:47:29 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161244; Mon 1-Jun-87 23:44:37 EDT
Date: Mon, 1 Jun 87 23:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IGNORE-ERRORS (Version 4)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870529-212051-1278@Xerox>
Message-ID: <870601234627.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 29 May 87 21:20 PDT
    From: Masinter.pa@Xerox.COM

    ...
    Issue:        IGNORE-ERRORS
    ...
    Discussion:

    KMP thinks that in spite of the perceived optimism about the emerging error
    proposal, it's wise to have a safe and credible interim position.
    Masinter wonders why KMP isn't spending more time on the error proposal.
    ...

I'd like to encourage you to remove this somewhat random comment, which may
be viewed by outsiders as being more critical than you hopefully meant. In 
fact, KMP is spending a -lot- of time on the error proposal.

The problem is that KMP has what he thinks is a clear understanding
both of the length of time it takes to get things of that size through
a political mechanism such as X3J13 even under ordinary circumstances,
and is -very- leary about potential last-minute snags due to the 
emergence of CLOS in parallel and the fact that people will likely 
want last-minute "small changes" to make it take more advantage of CLOS.

The presence of this item as a place-holder while all the business of
acceptance is in progress is particularly important to me. The more vendors
who provide this as a private extension in the very near term, the fewer
utterly random interfaces they'll conjure instead. Like it or not, existing
code has to interface to the private extensions until this standard is marked
approved, but we can do a lot to improve quality of life by at least hinting
that this is coming. In Macsyma, there's a definition of IGNORE-ERRORS that
does:

 #+LispM `(CONDITION-CASE (-ERROR-)
 	      (VALUES (PROGN ,@FORMS) NIL)
            (ZL:SYS:ERROR (VALUES NIL -ERROR-)))
 #+(OR ...other-systems...)
         `(LET ((RESULT (ERRSET (PROGN ,@FORMS) NIL)))
	    (IF RESULT
		(VALUES (CAR RESULT) NIL)
		(VALUES NIL T)))
 #+(OR ...more-other-systems...)
	  ...etc.

Each new case added requires careful study of the host error system to
figure out how to attach an IGNORE-ERRORS. If everyone had the idea that
at least IGNORE-ERRORS was worth latching onto, I think they'd at least
do that even if they weren't sure of the rest of the emerging error system,
and I think the resulting convergence would be very useful.

∂01-Jun-87  2050	Moon@STONY-BROOK.SCRC.Symbolics.COM 	PATHNAME-SYMBOL   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  20:50:11 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161246; Mon 1-Jun-87 23:45:22 EDT
Date: Mon, 1 Jun 87 23:45 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PATHNAME-SYMBOL
To: Eric Benson <edsel!kent-state!eb@navajo.stanford.edu>, Masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8706012127.AA07224@kent-state.edsel.uucp>
Message-ID: <870601234525.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Mon, 1 Jun 87 14:27:11 PDT
    From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)

    If a symbol can be coerced into a string, and a string can be coerced
    into a pathname, I see no reason why a symbol should not be coerced
    into a pathname.  It has limited usefulness, but I believe that
    coercions should be transitive.  I believe that the aesthetics of the
    language will be harmed by disallowing symbols as pathnames.

    I'm not going to put up a fight to stop this change, but I would like
    to see the minority view stated in the proposal.

Stating minority views in proposals is a good idea, but don't forget the
following point KMP made a couple of weeks ago.  I only mention this
because the point about alphabetic case doesn't appear explicitly in the
version 2 writeup.  I'd say the succinct form of this point is that
strings preserve the case that you type in, but symbols don't, they
force to uppercase.  This doesn't affect me, since I don't enjoy a file
system with case-sensitive file names, but it affects a lot of people.

 * Note that the biggest impact of this change on users is that
   they will not be able to say (LOAD'FOO) which they commonly type
   interactively to mean (LOAD "FOO"). One advantage, of course, is
   that in case-sensitive file systems, people won't do
   (load'foo) and wonder why file "FOO" (rather than "foo") is not
   found. Still, I think the fact that we're going to make it an
   error for people to type (LOAD 'FOO) is worth documenting as part
   of the cost of this proposal so that no one ends up surprised.

One note I had about KMP's remark:
Nothing in CLtL says that a symbol is allowed as an argument to LOAD,
unless we take all occurrences of the string "filename" in italics
to be typos for "pathname" in italics.  See pp.413,418,426.

∂01-Jun-87  2055	KMP@STONY-BROOK.SCRC.Symbolics.COM 	People's names
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  20:55:06 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161252; Mon 1-Jun-87 23:53:19 EDT
Date: Mon, 1 Jun 87 23:55 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: People's names
To: Masinter.PA@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870601235517.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I changed my name from KMP to Pitman in a bunch of proposals
because I thought it would be better for the X3J13 people who
aren't regular readers of net mail and might not put the two
together.

I notice in your summaries that sometimes I come out as KMP
and other times as Pitman. I'd appreciate if you could either
change the ones I missed to say Pitman or publish an index 
that says what a KMP is (in which case I'd like to be KMP
everywhere).

Presumably, the same reasoning should apply for SEF, etc. 
In fact, SEF doesn't even use the name SEF as his login name,
so that may be even more confusing to some.

Once we adopt a convention, we can just use it regularly and then
there need be no further last-minute touch-ups of this sort.

∂01-Jun-87  2121	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: FUNCTION-TYPE (version 4) 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  21:21:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161267; Tue 2-Jun-87 00:11:30 EDT
Date: Tue, 2 Jun 87 00:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870529-211904-1265@Xerox>
Message-ID: <870602001135.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 29 May 87 21:18 PDT
    From: Masinter.pa@Xerox.COM

    Even though there is a predicate FUNCTIONP, it is not synonomous to the
    use of the type FUNCTION; the FUNCTION type cannot be used for
    discrimination.

I don't think that's true.  I believe CLtL p.47 is meant to say that a
list type-specifier with FUNCTION in the car cannot be used for
discrimination, while Table 4-1 combined with CLtL p.72 indicates that
the symbol type-specifier FUNCTION can be used with TYPEP.  I would
simply remove this paragraph from the proposal.  Later in the proposal
you have an explicit statement that the symbol type-specifier FUNCTION
can be used for discrimination.

    This proposal removes the predicate
    COMPILED-FUNCTION-P from the standard language.

If it also removes the COMPILED-FUNCTION type-specifier, say so here.

∂01-Jun-87  2122	Moon@STONY-BROOK.SCRC.Symbolics.COM 	AREF-1D 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  21:22:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161269; Tue 2-Jun-87 00:12:38 EDT
Date: Tue, 2 Jun 87 00:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <870601-180753-3283@Xerox>
Message-ID: <870602001244.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 1 Jun 87 18:07 PDT
    From: Pavel.pa@Xerox.COM

    I favor this proposal in principal, but would much rather use the more
    mnemonic name ROW-MAJOR-AREF instead of AREF-1D.

I agree.


∂01-Jun-87  2121	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-SYMBOL (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  21:21:33 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161264; Tue 2-Jun-87 00:09:32 EDT
Date: Tue, 2 Jun 87 00:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL (Version 2)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870529-212341-1290@Xerox>
Message-ID: <870602001130.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

The grinding of the PATHNAME-SYMBOL proposal needs to be cleaned up.

It came through looking like this to me:

 ...
 Rationale:

 The feature of accepting a symbol was copied by Common Lisp from
 Zetalisp,
 which in turn copied it from Maclisp.  The reason Maclisp allowed a
 symbol
 here was that it did not have strings at all.  However, the feature has
 been
 long since removed from Zetalisp, since it was found to be a source of
 bugs
 ...

Also, I find the treatment of LOAD is not uniformly carried through.
For example, the proposal mentions LOAD at one point under conversion
cost. It may want to mention it under aesthetics, too. But in any case,
it should surely state definitively that LOAD is affected in the Proposal
and the References.

By the way, in the Symbolics release I'm using (7.1) allows (LOAD 'symbol)
so the comment saying we've long since flushed the feature is not completely
accurate. It may be that Moon didn't mean to include LOAD, in which case
the discussion should be phrased to make it clear that LOAD is not intended.

I think this will be a likely source of grumbling at X3J13; we might as
well head it off early. I won't vote to release this until the wording is
made to treat LOAD clearly.

∂01-Jun-87  2126	Moon@STONY-BROOK.SCRC.Symbolics.COM 	***BALLOT ***
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  21:26:07 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161284; Tue 2-Jun-87 00:25:41 EDT
Date: Tue, 2 Jun 87 00:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ***BALLOT ***
To: cl-cleanup@Sail.stanford.edu
In-Reply-To: The message of 30 May 87 00:27 EDT from Masinter.pa@Xerox.COM,
             <870529-212725-1304@Xerox>,
             The message of 30 May 87 01:42 EDT from Masinter.pa@Xerox.COM,
             <870529-224247-1345@Xerox>
Message-ID: <870602002546.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

Here are my votes on both part 1 and part 2 of the ballot:

ADJUST-ARRAY-DISPLACEMENT (revision 1)
[x] Release as is [ ] Comments follow in mail to cl-cleanup

AREF-1D (Version 1)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
	;Okay for release if name is changed to ROW-MAJOR-AREF

DEFVAR-INIT-TIME (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [x] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [ ] Other:
comments follow in mail to cl-cleanup
	;I don't have comments to offer on this, but it does seem
	;that there is some justification for not releasing it,
	;instead replacing it with a more complex proposal involving
	;lots of keyword options.  However I can't support
	;DO-SYMBOLS:ADD-KEYWORD in its present incomplete form.

FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

FUNCTION-TYPE (Version 4)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
	;Okay for release if the two comments I sent in mail are addressed

GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

IF-BODY (Version 5)
BALLOT: [ ] Release as is [x] Wait for version that SEF and KMP agree is
"fair".

IGNORE-ERRORS (Version 3)
BALLOT: [ ] Release as is [x] Wait for error proposal [ ] Comments
follow in mail to cl-cleanup

KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

PATHNAME-STREAM (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

PATHNAME-SYMBOL (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

PROMPT-FOR (revision 1)
BALLOT: [x] Withdraw [ ] Comments follow in mail to cl-cleanup


I cannot vote on the following, as I have not received copies of them.
Or if I have, it was so long ago that I have lost them, and even if
I hadn't lost them, I wouldn't trust them to be up to date.

ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup

ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup

PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [ ] Withdraw from consideration, await new proposal [ ] Comments
follow in mail to cl-cleanup
	;If those are the only two choices, "withdraw" always wins!

PUSH-EVALUATION-ORDER (not submitted)
BALLOT: [ ] (push first second) [ ] (push second first) [ ] unspecified
[ ] Proposal follows in mail to cl-cleanup
	;I support strict left to right evaluation order, which I believe
	;to be the current definition of Common Lisp.  I can't figure
	;out which checkbox means left-to-right.

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ]  GENERALIZE [ ] MODIFIED [ ] UNCHANGED [ ] Something else [
] Undecided

SHARPSIGN-BACKSLASH-BITS
BALLOT: [ ] Release as is [ ] Withdraw this proposal[ ] Want proposal
for removing BITS and FONT from standard [ ] Want fuller character
proposal [ ] Comments follows in mail to cl-cleanup

∂01-Jun-87  2137	KMP@STONY-BROOK.SCRC.Symbolics.COM 	FORMAT-OP-C (Version 3) 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  21:36:36 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161299; Tue 2-Jun-87 00:35:40 EDT
Date: Tue, 2 Jun 87 00:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FORMAT-OP-C (Version 3)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870602003737.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Changes since version 2:
 * Pavel's request to strike reference to ~Q at the end of the
   Problem Description field.
 * Masinter's request to reword proposal to not talk directly about
   modifying CLtL in the Proposal field.
 * The last paragraph of the Discussion field is new.
-kmp

-----Proposal Follows-----
Issue:	      FORMAT-OP-C
References:   WRITE-CHAR (p384), ~C (p389)
Category:     CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
	      29-Apr-87, Version 2 by Pitman (merge Moon's suggestion)
	      29-Apr-87, Version 3 by Pitman (misc editing)
Status:	      For Internal Discussion

Problem Description:

  The manual is not adequately specific about the function of the format
  operation ~C. The description on p389 says that "~C prints the character 
  in an implementation-dependent abbreviated format. This format should
  be culturally compatible with the host environment." This description
  is not very useful in practice.

  Presumably the authors intended the `cultural compatibility' part to
  gloss issues like how the SAIL character set printed, but unfortunately
  another completely reasonable (albeit unplanned) interpretation arose
  that wasn't planned on:
    (FORMAT NIL "~C" #\Space) might "Space" rather than " ".
  [Anyone who would argue that the word `abbreviated' in the definition
  was supposed to prevent this should just be happy that some implementors 
  didn't choose to interpret that word to mean that "Sp" should come back.]

  Some implementations have (FORMAT NIL "~C" #\Space) => "Space".
  Others have the same form return " ".

  Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
  It seems as if the implementations which return "Space" treat ~C and
  ~:C equivalently or very similarly, which seems like a waste of a FORMAT op.

  Since the behavior of ~A is also vague on characters (a separate 
  proposal will address this), the only way to safely output a literal
  character is to WRITE-CHAR; FORMAT does not suffice.

Proposal (FORMAT-OP-C:WRITE-CHAR):

  Change the behavior of ~C to say that, when given a character with zero
  bits, it will perform the same action as WRITE-CHAR. Leave the behavior
  of ~C with non-zero bits incompletely specified. For example, the
  description of ~C on p389 of CLTL might read:

       ~C prints the character using WRITE-CHAR if it has zero bits.
     Characters with bits are not necessarily printed as WRITE-CHAR
     would do, but are displayed in an implementation-dependent
     abbreviated format that is culturally compatible with the host
     environment.

  Clarify that WRITE-CHAR puts only one character on its argument stream,
  but which allows that stream to perform arbitrary destination-dependent
  actions based upon that character:

     Note: The glyphs used to present characters which are not in
     the standard character set may vary from implementation to
     implementation or output device to output device. WRITE-CHAR
     will always output a single character to the indicated stream.
     On some streams, super-quoting, character substitution, or
     substitution of a string for a single character may be 
     necessary; it is appropriate for the stream to decide to do
     this, but WRITE-CHAR itself will never do this.

Rationale:

  This was probably the intent of the authors. 

  It makes things clear enough that programmers can know what to
  expect in the normal case (standard characters with zero bits)
  while leaving some flexibility to implementors about what to do in
  the case of bits (which are not particularly well-defined across
  different implementations anyway).

Current Practice:

  Implementations are divided. Some implementations have
     (FORMAT NIL "~C" #\Space) => "Space".
  Others have the same form return " ".

Adoption Cost:

  Those implementations which did not already implement ~C as WRITE-CHAR
  would suffer an incompatible change.

Benefits:

  User code that uses ~C would have a chance of being portable.
  As things stand, users who use ~C can't reliably port their code.

  ~C and ~:C would perform usefully distinct operations.

Conversion Cost:

  Standard ``Query Replace'' technology for finding occurrences of
  "~C" and changing them to "~:C" semi-automatically should suffice.

Aesthetics:

  Making ~C do something well-defined will probably be perceived as
  a simplification.

Discussion:

  KMP and Pavel support this proposal.

  KMP thinks it's important to get this cleared up as soon as possible.

  Moon's comment on Version 1 (which tried to make WRITE-CHAR and ~C
  identical in all cases) was:
    I believe the error in CLtL is that it was not stated explicitly
    that the "implementation-dependent abbreviated format" applies only
    to characters with non-zero char-bits. Thus instead of removing the
    mumbling about cultural compatibility, I suggest simply adding a
    sentence saying that ~C is the same as write-char for characters
    with zero char-bits.  I don't think we want to require ~C and
    write-char to do the same thing for characters with bits.

  Steele and Fahlman seemed to like the idea of the proposal if amended
  as Moon suggested. Pitman did the merge, creating Version 2. If he didn't
  blow it somehow, they should now be happy.

  Moon and Fahlman voiced support for version 2.
  Fahlman thinks the problem description is too long.
  KMP isn't sure if he agrees that the problem description is too long,
  but doesn't think it's worth anyone's time to edit it.

∂01-Jun-87  2151	Moon@STONY-BROOK.SCRC.Symbolics.COM 	IGNORE-ERRORS (Version 4)   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  21:50:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161302; Tue 2-Jun-87 00:41:11 EDT
Date: Tue, 2 Jun 87 00:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: IGNORE-ERRORS (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870601234627.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870602004111.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    From: Kent M Pitman <KMP@STONY-BROOK>    
    The presence of this item as a place-holder while all the business of
    acceptance is in progress is particularly important to me.

In light of this, I'd like to modify my vote to say that I don't care
whether IGNORE-ERRORS is released in its present form (minus gratuitous
personal comments about how KMP spends his time) or withdrawn in
deference to the error proposal.

∂01-Jun-87  2152	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-SYMBOL (Version 2)    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  21:52:14 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161307; Tue 2-Jun-87 00:51:50 EDT
Date: Tue, 2 Jun 87 00:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYMBOL (Version 2)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870602001130.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870602005157.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 2 Jun 87 00:11 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    The grinding of the PATHNAME-SYMBOL proposal needs to be cleaned up.

This happens to most mail that passes through Xerox.  I don't think they
see it in their own mail reader, but in the outside world it gets
reformatted as alternating long and short lines if the lines are longer
than a small maximum.

    By the way, in the Symbolics release I'm using (7.1) allows (LOAD 'symbol)
    so the comment saying we've long since flushed the feature is not completely
    accurate. 

Try ZL:LOAD if you want to see what it does in Zetalisp.  But CL:LOAD doesn't
allow symbols in 7.1 for me, so maybe you've "fixed" it in your init file?
I don't think I've "fixed" it in mine.

	      It may be that Moon didn't mean to include LOAD, in which case
    the discussion should be phrased to make it clear that LOAD is not intended.

CLtL already does not say that LOAD accepts symbols as arguments, unless we
are to think that when it says "filename" it means "pathname", and when it
discusses what arguments named "pathname" mean 13 pages earlier, it means to
include LOAD.

I certainly didn't mean to propose to change the language to make LOAD allow
symbols.

Does this mean that we need to withdraw PATHNAME-SYMBOL in favor of a more
comprehensive proposal to fix all the ambiguities and incomplete specifications
in chapter 23?  That would be nice, but it's a big job.  Maybe we could just
cover every argument that is called pathname, filename, file, or new-name
and leave the rest of the ambiguities for another proposal?

∂01-Jun-87  2209	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Issue ADJUST-ARRAY-DISPLACEMENT   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  22:09:03 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161319; Tue 2-Jun-87 01:08:02 EDT
Date: Tue, 2 Jun 87 01:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
To: Masinter.pa@Xerox.COM, Fahlman@C.CS.CMU.EDU
cc: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <870529-211354-1250@Xerox>
Message-ID: <870602010958.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 29 May 87 21:13 PDT
    From: Masinter.pa@Xerox.COM

    Issue:        ADJUST-ARRAY-DISPLACEMENT

I'm happy with most of this clarification as far as it goes, but I have a
few other things that I'd like to see cleaned up before it goes out...

    ...
    (4) A is displaced to B before the call, but not displaced afterward.  A
    gets a new "data region", and contents of B are copied into it as
    appropriate to maintain the existing old contents; additional elements
    of A are taken from the :initial-element.  However, the use of
    :initial-contents causes all old contents to be discarded.

Hmm. I can almost get COPY-ARRAY out of this, couldn't I? Maybe...

(DEFUN COPY-ARRAY (ARRAY)
  (ADJUST-ARRAY (MAKE-ARRAY (ARRAY-DIMENSIONS ARRAY)
			    :ELEMENT-TYPE (ARRAY-ELEMENT-TYPE ARRAY)
			    :DISPLACED-TO ARRAY)
		:DISPLACED-TO NIL))

This isn't one of the things I necessarily think needs clarification. I just
thought it was curious. The rest of this message is of more significant interest.

    Note that if array X is displaced to array Y, and array Y is displaced
    to array Z, and array Y is altered by Adjust-Array, array X must now
    refer to the adjusted contents of Y. ...

I'm happy with this statement, but it sounds like it follows from one or
more of the four previous rules, and I'm not clear which. If it really
redundant, perhaps you could make the reason more clear. If not, it
shouldn't begin with "Note that...".

As nearly as I can tell, the discussion of ADJUST-ARRAY both here and in
CLtL does not say what happens if :DISPLACED-TO is omitted. Ie, is
 (ADJUST-ARRAY (MAKE-ARRAY ... :DISPLACED-TO A))
the same as 
 (ADJUST-ARRAY (MAKE-ARRAY ... :DISPLACED-TO A) :DISPLACED-TO NIL)
or the same as
 (ADJUST-ARRAY (MAKE-ARRAY ... :DISPLACED-TO A) :DISPLACED-TO A)
?

The current style of wording looks like the sort of clever :ADJUSTABLE 
wording that got us into such a frenzy. Even if there's intentional ambiguity,
we should be clear about that fact. My guess, though, is that no ambiguity
was intended here.

∂01-Jun-87  2221	KMP@STONY-BROOK.SCRC.Symbolics.COM 	AREF-1D (Version 2)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun 87  22:20:53 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161330; Tue 2-Jun-87 01:20:11 EDT
Date: Tue, 2 Jun 87 01:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870422164300.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870602012209.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I changed the name of the function from AREF-1D to ROW-MAJOR-AREF,
re-filled some of the text to fit better in 80-columns, and marked
KMP, GLS, Moon, JonL, Benson, and Pavel as supporting this amended
version in the Discussion field. Other than that, no changes.

-----Proposal Follows-----
Issue:        AREF-1D
References:   Arrays (pp286-298)
Category:     ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman,
	      02-Jun-87, Version 2 by Pitman (call it ROW-MAJOR-AREF)
Status:	      For Internal Discussion

Problem Description:

  It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
  efficiently in Common Lisp because they take arguments of varying
  arity. Currently, you have to make a displaced array to work with
  temporarily and then throw away the displaced array when you're done.
  In the case of FILLARRAY, I find this bothersome because there is no
  a priori reason why FILLARRAY should have to cons at all.

Proposal (AREF-1D:ROW-MAJOR-AREF):

  Introduce a new function ROW-MAJOR-AREF which allows 1D access to the
  storage backing up a given array assuming the normal row-major storage
  layout.

  This accessor should be valid for use with SETF.

Rationale:

  We already document the row-major storage layout and have a number of
  operators which allow users to exploit that order. This would be a 
  useful addition.

  LISTARRAY and FILLARRAY, for example, could be trivially defined by
  loops which had the following form:

    (DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
      ... (ROW-MAJOR-AREF ARRAY I) ...)

  Currently, the only really efficient way to write this involves
  something like:

    (ECASE (ARRAY-RANK ARRAY1)
      ((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
      ((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
	     (SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
      ((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
	     (DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
	       (SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
      ...some finite number of clauses...)

Current Practice:

  Many implementations have this primitive under some other name
  for use internally. In Symbolics systems, for example, it is 
  SYS:%1D-AREF.

Adoption Cost:

  This change is fairly localized. In implementations which already
  use this primitive internally, it's little more than a matter of
  changing the name of or otherwise releasing the existing primitive.
  In some implementations, it might involve writing a small amount of
  code (and associated compiler optimizers).

Benefits:

  This gives users efficient access to something which they already have
  inefficient access to.

Conversion Cost:

  This is an upward-compatible change.

Aesthetics:

  I think this allows certain programs to be written in a more aesthetic way.

Discussion:

  KMP and GLS support this proposal.

  Moon, JonL, Benson, and Pavel expressed conditional support of version 1,
  asking that the name be changed from AREF-1D to ROW-MAJOR-AREF. KMP and
  GLS did not oppose this change, so it was made for version 2.

∂02-Jun-87  0041	masinter.pa@Xerox.COM 	schedule    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Jun 87  00:41:40 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 02 JUN 87 00:41:13 PDT
From: masinter.pa@Xerox.COM
Date: 2 Jun 87 0:40:46 PDT
Subject: schedule
To: cl-cleanup@sail.stanford.edu
Message-ID: <870602-004113-3549@Xerox>

I've gotten several ballots, but by no means all.

I'll be out tomorrow and fairly busy on Wednesday, so I thought I could
summarize the ballots on Thursday, mail out revised versions of any of
the proposals that had only typographical corrections to this group and
a revised status. 

My target for mailing to X3J13 is next week. (Bob Mathis, if you are
listening, please send mailing labels!!!)

∂02-Jun-87  0226	KMP@STONY-BROOK.SCRC.Symbolics.COM 	*** BALLOT ***
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Jun 87  02:26:33 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161499; Tue 2-Jun-87 05:25:43 EDT
Date: Tue, 2 Jun 87 05:27 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: *** BALLOT ***
To: Masinter.PA@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870529-212725-1304@Xerox>,
             <870529-224247-1345@Xerox>
Message-ID: <870602052736.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

ADJUST-ARRAY-DISPLACEMENT (revision 1)
BALLOT: [ ] Release as is [x] Comments precede in mail to cl-cleanup

ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [ ] Withdraw [ ] Comments precede in mail to cl-cleanup
	[x] Place on hold pending resolution of comments already received.

AREF-1D (Version 1)
BALLOT: [ ] Release as is [ ] Comments follow in mail to cl-cleanup
	[x] Release version 2

ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

DEFVAR-INIT-TIME (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [ ] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD
        [x] Other: comments follow in mail to cl-cleanup

FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

FUNCTION-TYPE (Version 4)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup
 Note: I'd really be happiest if this was broken in two, so I could
       support the half I like and only grump about the parts I don't
       like. If we're going to deal with it all as one bundle, I feel
       obliged to hold up the whole thing for a bit because I believe
       there is useful progress still to be made amongst ourselves 
       prior to releasing this to the masses.

GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
 Note: I would like to see NIL be allowed to designate the null lexical
       environment, but I won't hold up the proposal for this if anyone
       disagrees.

IF-BODY (Version 5)
BALLOT: [x] Release as is
	[ ] Wait for version that SEF and KMP agree is "fair".
 Note: I'm not trying to be pushy; I just assume I must vote Yes to
       avoid a gentleman's deadlock. If SEF disagrees and wants to do
       further editing, I'm willing to have this put on hold for another
       round. I don't plan to let this fall victim to a pocket veto,
       however.

IGNORE-ERRORS (Version 3)
BALLOT: [ ] Release as is [ ] Wait for error proposal
        [ ] Comments follow in mail to cl-cleanup
        [x] Release with minor changes to discussion as mentioned in
	    recent mail.

KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
 Note: The copy of this which I received recently has been filled
       oddly and needs to be reformated if it looked that way before
       it went through someone's (Larry's?) mailer.

PATHNAME-STREAM (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

PATHNAME-SYMBOL (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [ ] Withdraw from consideration, await new proposal.
	[ ] Comments follow in mail to cl-cleanup
	[x] Place on hold pending resolution of comments already received.
 Note: This term "withdraw" really bugs me. These item names are the names
       of issues, not proposals. The proposal names have ":something"
       appended. Seems to me that issues oughtn't get withdrawn, they
       should just be placed on hold.

PUSH-EVALUATION-ORDER (not submitted)
BALLOT: [ ] (push first second) [ ] (push second first)
        [ ] unspecified         [ ] Proposal follows in mail to cl-cleanup
 Note: I'm not sure if this ballot item is for real. Clearly the topic
       warrants serious discussion, but I have no opinion right now so am
       not going to risk it.
        
PROMPT-FOR (revision 1)
BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup
	[x] Place on hold pending resolution of comments already received.

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ] GENERALIZE [ ] MODIFIED [ ] UNCHANGED
        [ ] Something else [x] Undecided
 Note: I am not clear on whether I support GENERALIZE or MODIFIED. I want to
       spend more time looking at this when I get a chance. I don't think we
       should propose anything firm yet.

SHARPSIGN-BACKSLASH-BITS
BALLOT: [ ] Release as is [ ] Withdraw this proposal
	[ ] Want proposal for removing BITS and FONT from standard
        [ ] Want fuller character proposal
        [ ] Comments follows in mail to cl-cleanup
	[x] Place on hold pending resolution of comments already received.

∂02-Jun-87  1016	RPG  	Issue: FUNCTION-TYPE (version 4)  
To:   cl-cleanup@SAIL.STANFORD.EDU    
Moon writes about Gregor's suggestion to warn on bad arguments to APPLY:

``This kind of warning strategy isn't very effective for things that cannot
be detected at compile time.  A run time warning tends to be a big annoyance
and may not tell you just where in your program was responsible for the
effect.''

This might be right, but I'd rather there be an annoyance during a
period when old code is fixed than have years of bad news simply because
of a sentimental attachment to MacLisp. Here's my proposal: Let the vendors
make the change and let the users fix their code.

			-rpg-

∂02-Jun-87  1148	Gregor.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE (version 4)   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 2 Jun 87  11:48:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 JUN 87 11:32:42 PDT
Date: 2 Jun 87 11:32 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE (version 4)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 1 Jun 87 20:14 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870602-113242-4179@Xerox>

    Date: Mon, 1 Jun 87 20:14 EDT
    From: David A. Moon

    This kind of warning strategy isn't very effective for things
    that cannot be detected at compile time.  A run time warning tends
    to be a big annoyance and may not tell you just where in your
    program was responsible for the effect.

True, but I think many of the cases could in fact be detected at run
time.  Of course I have not done an extensive search, and there may well
be large bodies of code for which this is not true.  Those large bodies
of code will require hand analysis and conversion.

Here is another point which I think is relevant to this discussion.
Define the Z of a lisp programmer to be their familiarity with the
subleties of Lisp programming.  This includes things like the history of
Lisp, what dynamically scoped Lisps are like, what Lisp-1s are like etc.
etc.  It seems to me that as time goes on, the average Z of lisp
programmers is going to go down.  In some sense, that is what it means
for Lisp to become a successful language.  An effect of this, is that in
most cases, it is going to be much easier for the people who have
written the existing code to deal with a change like the one I am
suggesting, than it will be for future programmers to deal with the
confusion caused by not making the change.  This is over and above the
fact that there will be much more code 5 years from now (we all hope!).

Take the example of Macsyma (or Spire or Kee or any other large 'old
time but still in use' Lisp program).  What if this change breaks one of
them?  We have to weigh that with the cost of propagating past confusion
by making apply and friends do conversion.  But the people who maintain
systems like Macsyma and KEE are likely much higher Z programmers than
people who are writing new code.  It probably won't be real hard for
these old time people to make this change.  It is more likely that the
new lisp programmers will get confused and write bad code.  I supect
people will write

(squirrel-function-away-1 '(lambda (x) ..))

(squirrel-function-away-2 #'(lambda (x) ..))

(funcall (fetch-function-1) (some-data))

(funcall (fetch-function-2) (some-data))

Since both 'functions', when they are fetched and funcalled will work,
people won't notice that the one isn't compiled.  When and if they do
notice, it may take them a long time to understand why they are losing
this way.

∂02-Jun-87  1219	edsel!kent-state!eb@navajo.stanford.edu 	PATHNAME-SYMBOL    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 2 Jun 87  12:19:07 PDT
Received: by navajo.stanford.edu; Tue, 2 Jun 87 12:14:59 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA13431; Tue, 2 Jun 87 11:53:27 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
	id AA08307; Tue, 2 Jun 87 11:53:18 PDT
Date: Tue, 2 Jun 87 11:53:18 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706021853.AA08307@kent-state.edsel.uucp>
To: navajo!cl-cleanup%sail@navajo.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 1 Jun 87 23:45 EDT <870601234525.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: PATHNAME-SYMBOL

   Date: Mon, 1 Jun 87 23:45 EDT
   From: David A. Moon <navajo!Moon@STONY-BROOK.SCRC.Symbolics.COM>
   Line-Fold: No

   I'd say the succinct form of this point is that
   strings preserve the case that you type in, but symbols don't, they
   force to uppercase.  This doesn't affect me, since I don't enjoy a file
   system with case-sensitive file names, but it affects a lot of people.

I don't enjoy a file system with case-sensitive names, but I seem to
be stuck with it!  Our VMS users like to be able to type (load 'foo),
though.

I think you've made a better case for eliminating the coercion of
symbols to strings, rather than making a special case restriction
against using a symbol as a string to be coerced to a pathname.  You
have also made a case for making the boolean falsehood value be
something other than a symbol.  Making this special case restriction
against symbols as pathnames is treating the symptom and not the
disease.

∂03-Jun-87  0729	gls@Think.COM 	***BALLOT *** PART 1 ***   My reply
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87  07:29:40 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 10:31:54 EDT
Date: Wed, 3 Jun 87 10:29 EDT
From: Guy Steele <gls@Think.COM>
Subject: ***BALLOT *** PART 1 ***   My reply
To: cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870529-212725-1304@Xerox>
Message-Id: <870603102930.2.GLS@BOETHIUS.THINK.COM>

    Date: 29 May 87 21:27 PDT
    From: Masinter.pa@xerox.com


    Please vote on the following issues which are open. "Release" means to
    release the document to X3J13 for discussion & voting.


    ADJUST-ARRAY-DISPLACEMENT (revision 1)
    [X] Release as is [ ] Comments follow in mail to cl-cleanup

    ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
    BALLOT: [ ] Withdraw [ ] Comments follow in mail to cl-cleanup

    AREF-1D (Version 1)
    BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup

    ASSOC-RASSOC-IF-KEY (Version 1)
    BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup

    DEFVAR-INIT-TIME (Version 2)
    BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup

    DO-SYMBOLS-DUPLICATES (Revision 1)
    BALLOT: [ ] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [X] Other:
    comments follow in mail to cl-cleanup

    FLET-IMPLICIT-BLOCK (Version 5)
    BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup

    FUNCTION-TYPE (Version 4)
    BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup

    GET-SETF-METHOD-ENVIRONMENT (Version 2)
    BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup

    IF-BODY (Version 5)
    BALLOT: [X] Release as is [ ] Wait for version that SEF and KMP agree is
    "fair".

    IGNORE-ERRORS (Version 3)
    BALLOT: [X] Release as is [ ] Wait for error proposal [ ] Comments
    follow in mail to cl-cleanup

    KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
    BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup

    PATHNAME-STREAM (Version 2)
    BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup

    PATHNAME-SYMBOL (Version 2)
    BALLOT: [X] Release as is [ ] Comments follow in mail to cl-cleanup

    PEEK-CHAR-READ-CHAR-ECHO (Version 1)
    BALLOT: [X] Withdraw from consideration, await new proposal [ ] Comments
    follow in mail to cl-cleanup

∂03-Jun-87  0731	gls@Think.COM 	DO-SYMBOLS
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87  07:31:42 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 10:34:03 EDT
Date: Wed, 3 Jun 87 10:31 EDT
From: Guy Steele <gls@Think.COM>
Subject: DO-SYMBOLS
To: cl-cleanup@sail.stanford.edu
Cc: gls@think.com
Message-Id: <870603103149.3.GLS@BOETHIUS.THINK.COM>

I favor DO-SYMBOLS:ALLOWED, except that I would like to have
the following issue addressed: if duplicates are allowed, it
may admit an implementation that would not terminate in the
situation where each of two packages USEd the other?  Do we
need a provision that DO-SYMBOLS must terminate, at least
for cases where the body does not aletr the packages involved?
--Guy

∂03-Jun-87  0733	gls@Think.COM 	***BALLOT *** PART 2 *** BALLOT *** PART 2 ***    
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87  07:33:21 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 10:35:51 EDT
Date: Wed, 3 Jun 87 10:33 EDT
From: Guy Steele <gls@Think.COM>
Subject: ***BALLOT *** PART 2 *** BALLOT *** PART 2 ***
To: cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870529-224247-1345@Xerox>
Message-Id: <870603103338.4.GLS@BOETHIUS.THINK.COM>


∂03-Jun-87  0749	gls@Think.COM 	June X3J13 meeting  
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87  07:48:54 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 10:48:46 EDT
Date: Wed, 3 Jun 87 10:46 EDT
From: Guy Steele <gls@Think.COM>
Subject: June X3J13 meeting
To: MATHIS@ada20.isi.edu
Cc: cl-cleanup@sail.stanford.edu
Message-Id: <870603104633.8.GLS@BOETHIUS.THINK.COM>

I regret that for personal and business reasons I will
be out of town on the days of the June meeting, and
therefore cannot attend.  Thinking Machines will send
an alternate representative.
--Guy

∂03-Jun-87  0809	gls@think.com 	Transitivity of coercions
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87  08:09:29 PDT
Received: from THINK.COM by navajo.stanford.edu with TCP; Wed, 3 Jun 87 08:06:27 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 11:11:12 EDT
Date: Wed, 3 Jun 87 11:09 EDT
From: Guy Steele <gls@think.com>
Subject: Transitivity of coercions
To: edsel!kent-state!eb@navajo.stanford.edu,
        navajo!cl-cleanup%sail@navajo.stanford.edu
Cc: gls@think.com
In-Reply-To: <8706012127.AA07224@kent-state.edsel.uucp>
Message-Id: <870603110900.0.GLS@BOETHIUS.THINK.COM>

Note that an explicit decision was made early in the design of CL
not to make all coercions transitive.  For example, symbols
coerce to strings (for string functions), and strings are sequences
(and so can be mixed with other sequence types), but symbols are
not sequences.

If we cannot have consistency, let us then have consistency of
inconsistency.  (Also known as, "This screw-up was good enough
for grampa, and it's good enough for me!")

--Guy

∂03-Jun-87  0926	gls@Think.COM 	People's names :-)  
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87  09:26:28 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 12:29:08 EDT
Date: Wed, 3 Jun 87 12:26 EDT
From: Guy Steele <gls@Think.COM>
Subject: People's names :-)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <870601235517.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-Id: <870603122658.3.GLS@BOETHIUS.THINK.COM>

A proposed standard for establishing naming standards for CL-CLEANUP proposals

Any message sent to CL-CLEANUP whose subject line consists solely of the
word "AXOLOTL" (in all upper case, possibly with surrounding whitespace)
may contain lines of the form

#REWRITE "xxx" => "yyyyy" comment

where xxx and yyyyy may be any strings.  Such a line specifies that
henceforth in a CL-CLEANUP proposal any word-delimited substring "xxx"
of the proposal shall be replaced by "yyyyy".  The comment may be any text
(possibly empty).

Masinter can collect these strings and use a software tool to apply them
all to each proposal as it is sent out.  Rewrite rules shall be ordered,
first according to the timestamp of the message defining them (earliest
first), secondarily according to alphabetical order of sender (to break
timestamp ties), and lastly according to the order in which the rules
appear in the message (in case a message defines more than one rewrite
rule).  When each rule is applied to a message, the leftmost occurrence
of "xxx" is located and replaced by "yyyyy"; the rule is then applied
again only to the remaining unsearched text, not to "yyyyy" or the text
that precedes it.  This allows a rule that rewrites "loser" into
"incredible loser" to avoid infinite recursion.

A rule that rewrites a person's name into another form is automatically
adopted when proposed by that person unless vetoed by a 2/3 majority
of CL-CLEANUP.  When proposed by another person it can be adopted only
after a show of 2/3 support.  Any other rewrite rule is included or
not at the discretion of Masinter unless overridden by 2/3 vote.

For example (note that the following examples do not actually take
effect because the subject line of this message is not "AXOLOTL"):

#REWRITE "KMP" => "Pitman"   Needs 2/3 vote to take effect unless
			     KMP should propose it himself
#REWRITE "GLS" => "Steele"
#REWRITE "mantissa" => "significand"
#REWRITE "that bagbiter Quux" => "that remarkable fellow Steele"

--Quux

P.S. Other extensions suggest themselves.  For example, a line
of the form #FLUSH "xxx" in any message whose header contains
":-)" could mean that any message containing "xxx" should be
killed by the mailer at SAIL and not distributed to CL-CLEANUP
at all.

#FLUSH "#REWRITE"

∂03-Jun-87  1101	Moon@STONY-BROOK.SCRC.Symbolics.COM 	DO-SYMBOLS   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87  11:01:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 162940; Wed 3-Jun-87 14:00:15 EDT
Date: Wed, 3 Jun 87 14:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DO-SYMBOLS
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <870603103149.3.GLS@BOETHIUS.THINK.COM>
Message-ID: <870603140012.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 3 Jun 87 10:31 EDT
    From: Guy Steele <gls@Think.COM>

    I favor DO-SYMBOLS:ALLOWED, except that I would like to have
    the following issue addressed: if duplicates are allowed, it
    may admit an implementation that would not terminate in the
    situation where each of two packages USEd the other?  

I don't think this is a problem, since using a package does not
inherit symbols that are -accessible- to that package, only
symbols that are -exported- by that package.

∂03-Jun-87  1154	KMP@STONY-BROOK.SCRC.Symbolics.COM 	People's names :-} 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87  11:54:01 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 163006; Wed 3-Jun-87 14:53:19 EDT
Date: Wed, 3 Jun 87 14:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: People's names :-}
To: RPG@SAIL.STANFORD.EDU
cc: gls@Think.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
    CL-Cleanup@sail.stanford.edu
In-Reply-To: <870603122658.3.GLS@BOETHIUS.THINK.COM>
Message-ID: <870603145314.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

There seems to be some bug in the SAIL mailer. I received the following
piece of mail, which was apparently not intended for me (or anyone on
CL-Cleanup, for that matter).

Please fix the mailer to prescan the text of messages and to make any
suggested improvements in itself -prior- to sending the mail in which
it reads about said improvements so that it can take advantage of those
improvements at the earliest opportunity.

Please be sure the mailer does not try to re-read the suggestion after
improving itself, however. This will avoid embarrassing halting problems
that could result from the improvement changing its understanding of the
suggestion.
-----
    Date: Wed, 3 Jun 87 12:26 EDT
    From: Guy Steele <gls@Think.COM>
    Subject: People's names :-)
    To: CL-Cleanup@sail.stanford.edu
    In-Reply-To: <870601235517.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
    Message-Id: <870603122658.3.GLS@BOETHIUS.THINK.COM>

    [text of message omitted]

∂03-Jun-87  1332	gls@Think.COM 	DO-SYMBOLS
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 3 Jun 87  13:31:51 PDT
Received: from boethius by Think.COM via CHAOS; Wed, 3 Jun 87 16:31:30 EDT
Date: Wed, 3 Jun 87 16:29 EDT
From: Guy Steele <gls@Think.COM>
Subject: DO-SYMBOLS
To: Moon@stony-brook.scrc.symbolics.com, gls@think.com
Cc: cl-cleanup@sail.stanford.edu, gls@think.com
In-Reply-To: <870603140012.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <870603162917.0.GLS@BOETHIUS.THINK.COM>

    Date: Wed, 3 Jun 87 14:00 EDT
    From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>

	Date: Wed, 3 Jun 87 10:31 EDT
	From: Guy Steele <gls@Think.COM>

	I favor DO-SYMBOLS:ALLOWED, except that I would like to have
	the following issue addressed: if duplicates are allowed, it
	may admit an implementation that would not terminate in the
	situation where each of two packages USEd the other?  

    I don't think this is a problem, since using a package does not
    inherit symbols that are -accessible- to that package, only
    symbols that are -exported- by that package.

Right.  Sorry.  So suppose each of two packages uses the other,
and each happens to export the same symbol?

(SETQ A (MAKE-PACKAGE 'A))
(SETQ B (MAKE-PACKAGE 'B))
(EXPORT (INTERN "ASYM" A) A)
(USE-PACKAGE A B)
(EXPORT 'B:ASYM B)
(USE-PACKAGE B A)
(DO-ALL-SYMBOLS (X B) (PRINT X))  ;will this print ASYM once, twice,
				  ; an infinite number of times, or what?

--Guy

∂03-Jun-87  1906	Moon@STONY-BROOK.SCRC.Symbolics.COM 	DO-SYMBOLS   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 3 Jun 87  19:05:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 163448; Wed 3-Jun-87 22:04:49 EDT
Date: Wed, 3 Jun 87 22:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DO-SYMBOLS
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <870603162917.0.GLS@BOETHIUS.THINK.COM>
Message-ID: <870603220443.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 3 Jun 87 16:29 EDT
    From: Guy Steele <gls@Think.COM>

    So suppose each of two packages uses the other,
    and each happens to export the same symbol?

    (SETQ A (MAKE-PACKAGE 'A))
    (SETQ B (MAKE-PACKAGE 'B))
    (EXPORT (INTERN "ASYM" A) A)
    (USE-PACKAGE A B)
    (EXPORT 'B:ASYM B)
    (USE-PACKAGE B A)
    (DO-ALL-SYMBOLS (X B) (PRINT X))  ;will this print ASYM once, twice,
				      ; an infinite number of times, or what?

DO-SYMBOLS:ALLOWED proposes to allow it to print ASYM once or twice, the
way I read it.  I don't see how it could print it an infinite number of
times.  (package-use-list (find-package 'a)) has no effect on
(package-external-symbols (find-package 'a)), hence should have no effect
on (do-symbols (x b) ...).  Or are you saying that the specification
should be loosened up to the point where do-symbols is allowed to
recurse on packages used, and then only look at a subset of the symbols
in those packages?

Nit picking: I assume you meant (DO-SYMBOLS (X B) (PRINT X)) rather
than (DO-ALL-SYMBOLS (X B) (PRINT X)).  I have no idea how many times
the latter should print ASYM, before it returns the value of B, except
that it shouldn't be an infinite number.

package-external-symbols is missing from the Common Lisp language for
some unfathomable reason, but you can define it in terms of do-external-symbols.

The example didn't run until I changed B:ASYM to B::ASYM.

End of nit picking: Does this mean the DO-SYMBOLS issue file needs to be
beefed up to discuss these issues, or are you and I just rambling while
waiting for our Thinking Machines (TM) central nervous system prosthetics
to be installed?

∂03-Jun-87  2038	FAHLMAN@C.CS.CMU.EDU 	PATHNAME-SYMBOL   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87  20:38:15 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 3 Jun 87 23:37:15-EDT
Date: Wed, 3 Jun 1987  23:37 EDT
Message-ID: <FAHLMAN.12307700341.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   edsel!kent-state!eb@λnavajo.stanford.edu (Eric Benson)λ
Cc:   cl-cleanup@SAIL.STANFORD.EDU
Subject: PATHNAME-SYMBOL
In-reply-to: Msg of 2 Jun 1987  14:53-EDT from edsel!kent-state!eb at navajo.stanford.edu (Eric Benson)


    I think you've made a better case for eliminating the coercion of
    symbols to strings, rather than making a special case restriction
    against using a symbol as a string to be coerced to a pathname.  You
    have also made a case for making the boolean falsehood value be
    something other than a symbol.  Making this special case restriction
    against symbols as pathnames is treating the symptom and not the
    disease.

Treating the symptom rather than the disease is often the best way to
keep the patient alive.  Let's fix what we can and think about more
extensive redesigns later.

-- Scott

∂03-Jun-87  2104	FAHLMAN@C.CS.CMU.EDU 	General strategy  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87  21:04:35 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 3 Jun 87 23:56:39-EDT
Date: Wed, 3 Jun 1987  23:56 EDT
Message-ID: <FAHLMAN.12307703872.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: General strategy


Before I start voting and commenting on specific issues, I'd like to
raise a point about our general strategy.

On important issues, where there is real disagreement within the cleanup
committee or where the issue is so critical that all sides must be
carefully explained, it is important that we present the issue with
multiple proposals and that the choosing is done by X3J13 as a whole.

On the other hand, a lot of these issues are trivial little things that
need to be cleaned up one way or another.  I believe that X3J13 and the
Common Lisp community as a whole want these to be resolved without a lot
of needless agonizing, and they want this committee to provide the
leadership to get that job done.  If there are two or three solutions to
some issue that differ only in "aesthetics", we on the cleanup committee
should converge on one solution, propose it, and endorse it.

We shouldn't say, "Well, we could do A and then again we could B, but
someone suggeted C and that's OK too."  Instead, we should say, "We
propose A."  In the discussion section we should say, "Solutions B and C
were discussed, but the cleanup committee has settled on A as the best
solution."  If we send multiple-choice proposals to X3J13 on trivial
issues where it doesn't matter, the discussion will focus on those
stupid things and much more important issues will be neglected.

A number of the proposals currently offer useless options of this kind,
either as actual choices to be voted on or as variations suggested in
the discussion section.  We should try to resolve these among ourselves
rather than leaving them hanging.  I'm not worried about people
following us blindly -- X3J13 seems to have enough sharp and contentious
people on it to prevent any abuse of this power.

-- Scott

∂03-Jun-87  2124	FAHLMAN@C.CS.CMU.EDU 	Ballot, parts 1 and 2  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87  21:24:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 00:23:54-EDT
Date: Thu, 4 Jun 1987  00:23 EDT
Message-ID: <FAHLMAN.12307708833.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: Ballot, parts 1 and 2


ADJUST-ARRAY-DISPLACEMENT (revision 1)
[ ] Release as is [x] Comments follow in mail to cl-cleanup
; OK in substance, but I'd like an edit to the discussion section.

ADJUST-ARRAY-NOT-ADJUSTABLE (version 1)
BALLOT: [x] Withdraw [ ] Comments follow in mail to cl-cleanup
; Or, if whoever proposed it insists, bring it out with a negative
; recommendation and let it be defeated once and for all.

ROW-MAJOR-AREF (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
; I prefer KMP's version 2 with the name change.

ASSOC-RASSOC-IF-KEY (Version 1)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

DEFVAR-INIT-TIME (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
; But first proofread the "adoption cost" section.

DO-SYMBOLS-DUPLICATES (Revision 1)
BALLOT: [ ] DO-SYMBOLS:ALLOWED [ ] DO-SYMBOLS:ADD-KEYWORD [x] Other:
comments follow in mail to cl-cleanup

FLET-IMPLICIT-BLOCK (Version 5)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

FUNCTION-TYPE (Version 4)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup

GET-SETF-METHOD-ENVIRONMENT (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup
; Proofread "Conversion Cost" section.

IF-BODY (Version 5)
BALLOT: [ ] Release as is [ ] Wait for version that SEF and KMP agree is
"fair". [ ] Comment follows.

IGNORE-ERRORS (Version 3)
BALLOT: [x] Release as is [ ] Wait for error proposal [ ] Comments
follow in mail to cl-cleanup
; Eliminating the question about KMP's priorities.

KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
BALLOT: [ ] Release as is [x] Comments follow in mail to cl-cleanup

PATHNAME-STREAM (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

PATHNAME-SYMBOL (Version 2)
BALLOT: [x] Release as is [ ] Comments follow in mail to cl-cleanup

PEEK-CHAR-READ-CHAR-ECHO (Version 1)
BALLOT: [x] Table, pending possible new proposal [ ] Comments
follow in mail to cl-cleanup

PUSH-EVALUATION-ORDER (not submitted)
BALLOT: [ ] (push first second) [ ] (push second first) [ ] unspecified
[ ] Proposal follows in mail to cl-cleanup
; I'm not going to vote on anything not yet submitted or discussed.  I'm
; not likely to favor any proposal that deviates from deterministic
; left-to-right evaluation, however.

PROMPT-FOR (revision 1)
BALLOT: [x] Table, pending possible new proposal [ ] Comments follow in
mail to cl-cleanup

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
BALLOT: [ ]  GENERALIZE [ ] MODIFIED [ ] UNCHANGED [ ] Something else
[x] Undecided
; Someone needs to take the lead in boiling this down to a single
; coherent proposal.

SHARPSIGN-BACKSLASH-BITS
BALLOT: [ ] Release as is [ ] Withdraw this proposal[ ] Want proposal
for removing BITS and FONT from standard [ ] Want fuller character
proposal [ ] Comments follows in mail to cl-cleanup
; ??? I don't seem to have a recent version of this.  I'd like a
; redesign of the whole font/bits business, but might support a quick
; fix in the meantime.

∂03-Jun-87  2135	FAHLMAN@C.CS.CMU.EDU 	Issue ADJUST-ARRAY-DISPLACEMENT  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87  21:35:34 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 00:34:58-EDT
Date: Thu, 4 Jun 1987  00:34 EDT
Message-ID: <FAHLMAN.12307710848.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 ADJUST-ARRAY-DISPLACEMENT
In-reply-to: Msg of 30 May 1987  00:13-EDT from Masinter.pa at Xerox.COM


I support this proposal and have no problem with releasing it as-is,
except for the form in which Moon's comments are included at the end.
As it stands, this is one of those proposals that seems to say, "Let's
do A, but then again we might want to do B."

Unless Moon wants to push the alternative he raises, we should either
drop this comment or say something like the following:

"Moon pointed out that the Symbolics system currently does ..., and that
this is an equally viable alternative.  However, the committee has
decided to stick with the proposal as described above."

If Moon strongly favors the alternative he describes, I could support
that as well.  I just think we need to pick one or the other.  This is
one of those cases where a clear and definite stand by the
cleanup committee would prevent the larger committee from getting bogged
down in needless details.

∂03-Jun-87  2145	FAHLMAN@C.CS.CMU.EDU 	Issue: DO-SYMBOLS-DUPLICATES (Version 2)   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87  21:44:53 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 00:44:18-EDT
Date: Thu, 4 Jun 1987  00:44 EDT
Message-ID: <FAHLMAN.12307712547.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: DO-SYMBOLS-DUPLICATES (Version 2)
In-reply-to: Msg of 30 May 1987  00:16-EDT from Masinter.pa at Xerox.COM


I support DO-SYMBOLS-DUPLICATES:ALLOWED.

I don't think we should present X3J13 with two alterantives on a dumb
issue like this.  If someone really feels strongly about the keyword
version and wants to produce a correct and complete version of the
keyword proposal in the next couple of days, I would be willing to go
along with that instead.  But in any case, I think we should decide
among ourselves and only bring one proposal out of this committee.

If we do go with a keyword version, I feel rather strongly that the
default must be to allow duplicates.  In most cases, the issue of
duplicates really doesn't matter, and we don't want to saddle users with
a much more expensive default.

-- Scott

∂03-Jun-87  2201	FAHLMAN@C.CS.CMU.EDU 	IF-BODY 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87  22:01:18 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 01:00:44-EDT
Date: Thu, 4 Jun 1987  01:00 EDT
Message-ID: <FAHLMAN.12307715536.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: IF-BODY


I'm willing to go along with releasing KMP's latest revision of IF-BODY,
even though it doesn't properly argue the case that manufacturers should
provide reasonable portability tools before using non-portability as an
argument for changing the language.

I am confident that this proposal will be defeated and then we'll be
done with it.  If I am wrong, I can probably live with that.  (Of
course, any CMU programmers caught using extended-IF would get a "mild"
electric shock to remind them that legal Common Lisp is not necessarily
acceptable Common Lisp.)

What is important to me is not that we hold up this particular issue,
but that in the future we adopt an adversarial system for putting
together proposals on which we cannot reach a consensus.  Nobody should
be put in the position of having to summarize a position he doesn't
agree with; it's a very difficult, thankless task for the summarizer,
and the opposition is likely to feel screwed anyway.  Each side should
get some space in which to argue its case, and nobody should edit the
result.

-- Scott

∂03-Jun-87  2232	FAHLMAN@C.CS.CMU.EDU 	Issue: FUNCTION-TYPE (version 4) 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87  22:32:27 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 01:31:53-EDT
Date: Thu, 4 Jun 1987  01:31 EDT
Message-ID: <FAHLMAN.12307721211.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-TYPE (version 4)
In-reply-to: Msg of 30 May 1987  00:18-EDT from Masinter.pa at Xerox.COM


There seem to be three positions here:

1. The "maximally clean" proposal, in which FUNCALL, APPLY, and the
built-in functions that take functional args would take only true
functions and it would "be an error" to pass either of these a lambda
expression or a symbol.

2. The "maximally compatbile" proposal currently reflected by
FUNCTION-TYPE:REDEFINE.

3. The "maximally Macsyma" proposal, which is like 2 but would also
require that SYMBOL-FUNCTION take a symbol or lambda and return it
unchanged.

I actually favor option 1, though I think that we must be up-front about
the incompatibilities it introduces.  Several others seem to share this
view.

It might be hard to get the majority of X3J13 to agree to option 1,
however, since a lot of those people are more worried about preserving
existing code than about cleanliness and consistency.  If we want to
resolve this issue in a hurry, pushing option 2 might be the way to go.
Moon has been the most vocal advocate of option 2 within the cleanup
committee.  Personally, I could live with this, though I prefer option
1.

So far, only KMP has argued in favor of option 3.  This does not reflect
the status quo in many implementations, and some of us view it as a step
backwards.

It would be great if we could reach some internal consensus on this
issue and present a recommendation from the whole cleanup committee.  If
this is impossible, we should write this up as a two-option or
three-option proposal and let X3J13 fight it out.  I don't think we
should sit on this indefinitely waiting for someone's mind to change or
break it up into little pieces -- either move will just guarantee that
this remains unresolved for the forseeable future.

If people are comfortable with releasing the current version, I can go
along with that in priciple, but the presentation needs to be cleaned up.
I will be happy to do some of the work of redrafting this proposal, but
can't do this without understanding where the committee members stand:
what they favor, and what they would agree to.

-- Scott

∂03-Jun-87  2238	FAHLMAN@C.CS.CMU.EDU 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Jun 87  22:37:53 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 4 Jun 87 01:37:10-EDT
Date: Thu, 4 Jun 1987  01:37 EDT
Message-ID: <FAHLMAN.12307722170.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: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
In-reply-to: Msg of 30 May 1987  00:22-EDT from Masinter.pa at Xerox.COM


I support this proposal and support releasing it as-is, except for the
next to last paragraph about NIL.  Another dangling issue, and this time
it seems like the sentence, "The cleanup committee supports this change"
refers to the exclusion of NIL.

I don't care whether we decide that NIL should be allowed or disallowed,
but we should decide on one or the other and say so clearly, not just
mumble on both sides of the issue with no resolution.

-- Scott

∂04-Jun-87  0852	RPG  	FUNCTION-TYPE 
To:   cl-cleanup@SAIL.STANFORD.EDU    

When Clinger and I proposed this cleanup, it was the maximally clean
version, and that is the one I support. On the other hand, I believe that
there is little reason to actually press for the maximally clean version.

In some sense, all of us are trying to ``spread the word'' about Lisp,
trying to get currently non-Lisp programmers to switch. We could do this
if there were some way for mainstream computing to be done in Lisp.
With a language like Common Lisp this is not possible - it is too big
and it is growing. What we could have hoped to accomplish with this
cleanup is a first step towards establishing a continuum of Lisps from
Scheme up through Common Lisp. Even if we were to adopt this change, the
period until we had the continuum would be lengthy.

I don't think we can win this game quickly given the time constraints
and the current state of Common Lisp. We continue to argue about the
filigrees.

I believe that we ought to minimally clean up Common Lisp and rapidly
move on to the next great Lisp language design.

			-rpg-

∂04-Jun-87  1742	Masinter.pa@Xerox.COM 	Format revisited 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Jun 87  17:42:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 JUN 87 17:25:35 PDT
Date: 4 Jun 87 17:25 PDT
From: Masinter.pa@Xerox.COM
Subject: Format revisited
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870604-172535-1480@Xerox>

Summarizing the ballots is slow going. I hope to be done tomorrow and to
mail out some revisions.

Below is a minor revision of the style sheet which incorporates a couple
of suggestions.

Note that the hardcopy of the issues to x3j13 (and the internal copies I
deal with) have font and paragraph control, but I have no simple way of
mailing them out in that form. However, I'd suggest you not worry about
formatting or grinding of paragraphs.

!
Format for proposals to "clean up" Common Lisp.
Revision 9 -  4-Jun-87
 >>Replace the text in italics (double inverted angle-brackets). Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upcase all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.<<
Issue: >>A short descriptive label, which starts with a name which
occurs in the index of CLtL, and be a suitable symbol in the Common Lisp
style, e.g., CDR-TERMINATION.   .<<
References:  >>The pages of CLtL which describe the feature being
discussed, or other references..<<
Category:   >>One or more of: CLARIFICATION - proposal to resolve an
ambiguity or case of under-specified situation in CLtL, where this
ambiguity interferes with portability of code. CHANGE - Proposal for an
incompatible change to the language.  ADDITION - Proposal for a
compatible extension to the language. <<
Edit history: >>Author and date of submission, and author and date of
subsequent revisions.<<
Problem description:  >>Describe the problem being addressed -- why is
the current situation unclear or unsatisfactory? Avoid describing the
proposal here or arguing for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing.  Ideally, this should take the form of
text that could be dropped into CLtL or some new specification document.
If necessary, propose a set of labelled alternatives here, rather than a
single proposal. Each proposal must be a complete design; do not leave
out details.  Avoid arguing for the proposal here, just describe it.<<
Test Case: >>When possible, give a sample of Common Lisp code that
illustrates the issue.<<
Rationale:  >> A brief argument for the proposal. (If more than one
proposal is listed, discuss each issue separately here and in subsequent
sections.)<<
Current practice: >>Do some/many/no Common Lisp implementations already
work this way? Survey independent Common Lisp implementations -
preferably three or more.<<
Adoption Cost: >>What is the cost to implementors of adopting the
proposal?  How much implementation effort is required?  Is public-domain
code available? For pervasive changes, can the conversion be
automated?<<
Benefits: >>What is better if the proposal is adopted? How serious is
the problem if just left as it is? <<
Conversion Cost: >>For incompatible changes, what is the cost to users
of converting existing user code?  To what extent can the process be
automated? how?<<
Esthetics: >>How does this proposal affect the simplicity of the
language, ease of learning, etc.<<
Discussion: >> Additional arguments, discussions, endorsements,
testimonials, etc. should go here. A blow-by-blow account of debates is
not necessary. <<

∂04-Jun-87  1742	Masinter.pa@Xerox.COM 	AREF-1D (Version 3)   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Jun 87  17:42:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 JUN 87 17:25:58 PDT
Date: 4 Jun 87 17:25 PDT
From: Masinter.pa@Xerox.COM
Subject: AREF-1D (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870604-172558-1481@Xerox>


Status: Ready for release. 

I made the edits before seing Kent's revision, so I went ahead and
merged his version and mine. I will mail this version out to X3J13 next
week (unless I hear objections.)

!
Issue:        AREF-1D
References:   Arrays (pp286-298)
Category:     ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
              02-Jun-87, Version 2 by Pitman (call it ROW-MAJOR-AREF)
               4-Jun-87, Version 3 by Masinter (very minor editorial
work)

Problem Description:

It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying arity.
Currently, you have to make a displaced array to work with temporarily
and then throw away the displaced array when you're done. In many cases,
this is bothersome because there is no a priori reason why they should
have to cons at all.

Proposal (AREF-1D:ROW-MAJOR-AREF):

Introduce a new function ROW-MAJOR-AREF which allows one-dimensional
access to the storage backing up a given array assuming the normal
row-major storage layout.

ROW-MAJOR-AREF is valid for use with SETF.

Rationale:

Common Lisp requires row-major storage layout of arrays and has a number
of operators which allow users to exploit that order. ROW-MAJOR-AREF is
a useful, simple addition.

LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops which had the following form:

    (DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
      ... (ROW-MAJOR-AREF ARRAY I) ...)

Currently, the only really efficient way to write this would involve
something like:

    (ECASE (ARRAY-RANK ARRAY1)
      ((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
      ((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
	     (SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
      ((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
	     (DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
	       (SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
      ...some finite number of clauses...)

Current Practice:

Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.

Adoption Cost:

This change is fairly localized. In implementations which already use
this primitive internally, it's little more than a matter of changing
the name of or otherwise releasing the existing primitive. In some
implementations, it might involve writing a small amount of code or
compiler work to make ROW-MAJOR-AREF work efficiently.

Benefits:

This gives users efficient access to something which they already have
inefficient access to.

Conversion Cost:

This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely
to be used by any current program.

Aesthetics:

This allows certain programs to be written in a more aesthetic way.

Discussion:

The cleanup committee supports this enhancement.

∂04-Jun-87  1742	Masinter.pa@Xerox.COM 	Merging of committees 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 4 Jun 87  17:42:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 04 JUN 87 17:27:46 PDT
Date: 4 Jun 87 17:27 PDT
Sender: Masinter.pa@Xerox.COM
Subject: Merging of committees
To: cl-cleanup@Sail.stanford.edu
From: Larry Masinter <Masinter.PA@Xerox.COM>
Message-ID: <870604-172746-1483@Xerox>

On the subject of the possible merger of the cleanup committee and the
error or compiler committees:

I am very much opposed to merging other committees in with the Cleanup
Committee. Even if there is substantial, or even total, overlap of the
committees (e.g., even if everyone on the Compiler Committee is a member
of the Cleanup Committee), the committees have different charters, sets
of issues, etc. 

If the Error committee needs some help and the compiler committee needs
some new members, we individually can try to help fix those things.

I also am opposed to taking smaller issues which rightfully belong to
those other committees and putting them thru cl-cleanup.

For example, I am opposed to the CLEANUP committee releasing
Ignore-errors. If Kent thinks it is a good idea to get IGNORE-ERRORS
out, then let that be the report and proposal of the Error committee.
Kent can even report that the Cleanup committee likes the idea, but it
should come as a report and recommendation of the error committee. 

I would like to see separate committees (again, even if they
substantially or totally overlap with this one) deal with the issues of
compilation and declarations, the issue of signalling and also the
myriad set of changes where "is an error" might turn into "signals an
error" and where "signals an error" might turn into "signals a FROB
error". 

I'm willing to join the error committee and the compiler committee if
its necessary to help get them off the ground or they seem to lack
critical mass, although I'm not yet convinced that it is necessary.

Larry

∂04-Jun-87  1856	MATHIS@ADA20.ISI.EDU
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 4 Jun 87  18:56:05 PDT
Date: 4 Jun 1987 18:55-PDT
Sender: MATHIS@ADA20.ISI.EDU
From: MATHIS@ADA20.ISI.EDU
To: Masinter.pa@XEROX.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 4-Jun-87 18:55:20.MATHIS>

Larry, I just sent you a set of mailing labels for x3j13 as you
requested.  They should come by express mail on Friday.

To all of the committee -- keep up the good work.

Bob

∂04-Jun-87  1925	Moon@STONY-BROOK.SCRC.Symbolics.COM 	AREF-1D (Version 3)    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Jun 87  19:25:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 164454; Thu 4-Jun-87 22:24:02 EDT
Date: Thu, 4 Jun 87 22:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: AREF-1D (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870604-172558-1481@Xerox>
Message-ID: <870604222355.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

Change "arity" to "rank" to be consistent with standard Common Lisp
terminology.  Otherwise fine.

∂04-Jun-87  1933	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Merging of committees   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 4 Jun 87  19:32:24 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 164465; Thu 4-Jun-87 22:31:13 EDT
Date: Thu, 4 Jun 87 22:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Merging of committees
To: Masinter.PA@Xerox.COM
cc: cl-cleanup@Sail.stanford.edu
In-Reply-To: <870604-172746-1483@Xerox>
Message-ID: <870604223106.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 4 Jun 87 17:27 PDT
    From: Larry Masinter <Masinter.PA@Xerox.COM>

    ... I am opposed to the CLEANUP committee releasing IGNORE-ERRORS.
    If Kent thinks it is a good idea to get IGNORE-ERRORS out, then let
    that be the report and proposal of the Error committee. Kent can
    even report that the Cleanup committee likes the idea, but it should
    come as a report and recommendation of the error committee. ...

I disagree. The Error Committee is responsible for preparing a complete
proposal. The Cleanup is responsible for making minor patches. This is a
minor patch which is contingent on the Error Committee -not- doing something.
It would be inappropriate for the Error Committee to make conflicting
recommendations. It is not inappropriate for two groups with (as you
yourself said) different goals to make conflicting recommendations.

I completely agree that the committees should not be merged. Although
there is a gray area in all of this where X3J13 adopts various proposals
of other committees and it may be appropriate for the Cleanup committee
to then take over the job of minor corrections to what at that point
amounts to a normal part of the language. We can cross that bridge when
we come to it, though; it's certainly no relation to what's going on at
this point in any of the subcommittees I know of.

∂05-Jun-87  1808	Masinter.pa@Xerox.COM 	FORMAT-OP-C (Version 4)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  18:08:19 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 15:05:51 PDT
Date: 5 Jun 87 15:04 PDT
From: Masinter.pa@Xerox.COM
Subject: FORMAT-OP-C (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-150551-2556@Xerox>

I'm not sure it wouldn't be simpler to make the use of ~C on characters
with non-zero BITS (and FONT?!) an error, rather than attempting to
leave it unspecified. I suppose if we can get up a vote to remove BITS
and FONT from the standard, it is moot.

The discussion of the stream-dependent behavior confused bytes with
characters in an unfortunate way. I rewrote that part of it to be what I
believe the truth is; I'm not sure if you agree, however. My notion was
that write-char always writes a single character; writing a
single-character causes multiple bytes to be written. However, a
subsequent read-char of the same stream should produce EQL characters as
were given to write-char. The only thing which is
stream/operating-system dependent is the mapping of characters to bytes.

When I thought about *that* some more, I decided it was really a
clarification about WRITE-CHAR and not about FORMAT ~C, so I moved the
whole paragraph about clarifying WRITE-CHAR to the discussion section.
This proposal is now very short.


!
Issue:        FORMAT-OP-C
References:   WRITE-CHAR (p384), ~C (p389)
Category:     CHANGE/CLARIFICATION
Edit History: 23-Feb-87, Version 1 by Pitman
              29-Apr-87, Versions 2,3 by Pitman (merge in suggestions)
               5-Jun-87, Version 4 by Masinter, minor copy-editing

Problem Description:

The manual is not adequately specific about the function of the format
operation ~C. The description on p389 says that "~C prints the character
in an implementation-dependent abbreviated format. This format should be
culturally compatible with the host environment." This description is
not very useful in practice.

Presumably the authors intended the `cultural compatibility' part to
gloss issues like how the SAIL character set printed, but unfortunately
another completely reasonable (albeit unplanned) interpretation arose:
some implementations have (FORMAT NIL "~C" #\Space) => "Space" rather
than " ".

Since the behavior of ~A is also vague on characters (a separate
proposal addresses this), the only way to safely output a literal
character is to WRITE-CHAR; currently, FORMAT does not suffice.

Proposal (FORMAT-OP-C:WRITE-CHAR):

Change the behavior of ~C to say that, when given a character with zero
bits, it will perform the same action as WRITE-CHAR. (This proposal
leaves the behavior of ~C with non-zero bits incompletely specified.)
For example, the description of the ~C format directive on p389 of CLTL
might read:

       ~C prints the character using WRITE-CHAR if it has zero bits.
     Characters with bits are not necessarily printed as WRITE-CHAR
     would do, but are displayed in an implementation-dependent
     abbreviated format that is culturally compatible with the host
     environment.

Test Case:

(EQUAL (FORMAT NIL "~C" #\Space) " ")

Rationale:

This was probably the intent of the Common Lisp designers. 

It makes things clear enough that programmers can know what to expect in
the normal case (standard characters with zero bits).

Users can use (FORMAT NIL "~:C" #\Space) to get "Space" if they want it.
It seems as if the implementations which return "Space" treat ~C and ~:C
equivalently or very similarly.

Current Practice:

Implementations are divided. Some implementations have
     (FORMAT NIL "~C" #\Space) => "Space".
Others have the same form return " ".

Adoption Cost:

Those implementations which did not already implement ~C as WRITE-CHAR
would require an incompatible change.

Benefits:

User code that uses ~C would have a chance of being portable. As things
stand, users who use ~C can't reliably port their code.

~C and ~:C would perform usefully distinct operations.

Conversion Cost:

Standard ``Query Replace'' technology for finding occurrences of "~C"
and changing them to "~:C" semi-automatically should suffice.

Aesthetics:

Making ~C do something well-defined will probably be perceived as a
simplification.

Discussion:

The cleanup committee supports this clarification.


The original version of this proposal (which tried to make WRITE-CHAR
and ~C identical in all cases) prompted the following comment:

 I believe the error in CLtL is that it was not stated explicitly
 that the "implementation-dependent abbreviated format" applies only
 to characters with non-zero char-bits. Thus instead of removing the
 mumbling about cultural compatibility, I suggest simply adding a
 sentence saying that ~C is the same as write-char for characters
 with zero char-bits.  I don't think we want to require ~C and
 write-char to do the same thing for characters with bits.

It may be necessary to clarify that WRITE-CHAR puts only one character
on its argument stream, such that a subsequent READ-CHAR of the same
file would read only one character. (Of course, in some operating
systems or for some devices, WRITE-CHAR of a single character might
cause multiple bytes to be written, substituted, escaped, quoted or the
like.) 

∂05-Jun-87  1809	Masinter.pa@Xerox.COM 	Re: ASSOC-RASSOC-IF-KEY (Version 1)  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  18:08:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 15:30:08 PDT
Date: 5 Jun 87 15:30 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: ASSOC-RASSOC-IF-KEY (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 22 Apr 87 15:14 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870605-153008-2585@Xerox>

I think the reason that ASSOC-IF, RASSOC-IF and friends do not have :KEY
arguments is that  ASSOC-IF is equivalent to FIND-IF :KEY #'CAR and
RASSOC-IF is FIND-IF :KEY #'CDR. That is, the way I think of these
functions, they already have a KEY argument, it is just that the KEY is
already implicitly specified by the function name.

I don't see any substantial advantage of expressiveness in this
proposal. 

∂05-Jun-87  1809	Masinter.pa@Xerox.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  18:09:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 16:10:52 PDT
Date: 5 Jun 87 16:10 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
To: CL-Cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-161052-2627@Xerox>

I made the discussion less wishy-washy by saying we rejected disallowing
NIL.  I made some edits to fix typos various people pointed out. I fixed
the "grinding".

Status: Ready for release.

!
Issue:        KEYWORD-ARGUMENT-NAME-PACKAGE
References:   Lambda Expressions (CLtL pp60-64)
Category:     CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
	         29-Apr-87, Version 2 by Pitman
              11-May-87, Version 3 by Moon
              29-May-87, Version 4 by Masinter
               5-Jun-87, Version 5 by Masinter

Problem Description:

CLtL says that only keyword symbols can be used as non-positional
argument names in &key parameter specifiers.

As Common Lisp is currently defined, if someone wants to define a
function that accepts named (rather than positional) arguments whose
names are symbols in packages other than the KEYWORD package, they
cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.  

Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]

 
Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)

Remove restrictions on the package of non-positional argument names;
allow any symbol, including NIL.  That is: 

If, following an &key, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword-symbol with the same print name as the variable is created and
is used as the keyword-indicator in function calls.  The only way to get
a non-positional-argument-name that is not a keyword symbol is to use
the (indicator variable) syntax in the function's lambda list.  The
keyword-indicator can be any symbol, not just a keyword.

Test case:

(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
    (FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))

(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"


Rationale:

The "rationale" box on p.62 of CLtL is an argument in favor of requiring
non-positional argument names to be symbols, and not allowing numbers,
but does not speak to the issue of whether or not those symbols should
be further restricted to be keywords.

The desire for non-positional arguments whose names are not keyword
symbols arises when the set of non-positional arguments accepted by a
function is the union of the sets of non-positional arguments accepted
by several other functions, rather than being enumerated in a single
place.  In this case,
it becomes desirable to use packages to prevent accidental name clashes
among non-positional argument names of different functions.

One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS).  It will have generic functions that accept non-positional
arguments and pass them on to one or more applicable methods, with each
method defining its own set of arguments that it is interested in.  If
this proposal is not adopted, either the non-positional argument names
will be required to be keywords, which will require the methods to have
non-modular knowledge of each other in order to avoid name clashes, or
the methods will have to be defined with an ad hoc mechanism that
duplicates the essential functionality of &key but removes the
restriction.

A second example of a Common Lisp application that requires this
capability is private communication channels between functions.  Suppose
a public routine MAKE-FOO needs to accept arbitrary keywords from the
caller and passes those keywords along to an internal routine using
keywords of its own.
 (IN-PACKAGE 'FOOLAND)
 (DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
   (APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))

This could be done without fear that the use of EXPLICIT T would
override some keyword in keyword-value-pairs, since the only way that
could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL),
or if the user was programming explicitly in the FOOLAND package, either
of which is an implicit admission of willingness to violate FOOLAND's
modularity.

Documentation Impact:

The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in
understanding the impact of the proposal.

The wording which refers to non-positional arguments as being introduced
by keyword symbols wuuld change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
   ... each -keyword- must be a keyword symbol, such as :start.
 would become
   ... each -keyword- must be a symbol.

The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.

Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used as non-positional argument
names, and that all functions built into the Common Lisp language follow
that convention.

Examples would be useful. On p.64 the following examples might be added:

    ((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
    => (1 2 6 NIL)

    ((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
    => (1 2 6 NIL)

Current Practice:

We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.

Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)

Adoption Cost:

Some implementors might have to rearrange their error checking slightly,
but it should be very easy.

Benefits:

This will help with the object-oriented programming standard, among
other things.

Conversion Cost:

None--no existing programs will stop working.  

Aesthetics:

The restriction of &key to only keyword symbols is arbitrary and
unnecessary.

There will probably be an argument about whether the restriction is more
esthetic or less esthetic than the freedom, but in either case the
aesthetic effect is slight.

In any case, users who do not want to use the extended functionality can
generally avoid it.

Discussion:

Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.

If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.

The cleanup committee considered but rejected a proposal to exclude NIL
as a legal indicator. It might catch some errors, but is otherwise an
odd restriction.

The cleanup committee supports this change.

∂05-Jun-87  2113	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Sigh -- More procedure  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Jun 87  21:12:55 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 165549; Sat 6-Jun-87 00:12:11 EDT
Date: Sat, 6 Jun 87 00:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Sigh -- More procedure
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870606001157.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I'm sorry for the length of this message. It treats an issue which
I thought we'd settled before when Fahlman edited a proposal and
forgot to change its status back to internal, but in my view that
agreement has been violated again an I want to re-open the issue: 

My votes are significantly based on the wording of a proposal, not just
their spirit. My guess from their behavior is that many of the others on
this list do likewise. To me, no other choice is possible because this
same rigor is the manner in which CLtL gets interpreted by users and
we accept the fact that every word and punctuation mark could potentially
make a difference.

Earlier this week, I allocated a long evening to carefully re-read all
the relevant mail leading up to the proposals upon which we were asked
to vote. I allocated this time at your request, believing that this was
the final vote and that extreme care was in order. Now you've changed
the proposal and marked some things ready for release and/or falsely
claimed that the cleanup committee endorses this proposal, which in fact
the cleanup committee has not seen.

When I worked on the student newspaper at MIT, we had a policy that we
didn't reply to letters to the editor; the reason was that the paper
always had the opportunity to get in the last word and this wasn't fair
in a forum which was supposed to promote open discussion.  Likewise, we
have an informal rule that the moderator at X3J13 meetings should not
feel free to interject comments in between designating queued speakers
-- since he obviously has an unfair opportunity to say more than is
appropriate. I think it would be useful if we could agree that the
moderator here should follow the same conventions as everyone else in
either not being able to change things at the last minute.

I'm willing to be very liberal in my definition of "the last minute".  I
consider that the line was drawn when you yourself said we were making a
final vote and that if people had been hesitating that this was the time
they should say something. I think it is inconsiderate for you to then
make further changes that cause me to feel compelled to spend more time
when I've already gone for broke on my budgeted time at your own
suggestion. I feel that since you have the last contact with the documents
between now and when they are seen by X3J13, that you have a moral 
obligation to resist changing them in that interval or to explicitly admit
that another full round of voting is in order.

I was very hesitant to send out my change to AREF-1D and FORMAT-OP-C
proposals at the last minute, but it seemed clear that the vote was not
going to favor the existing versions so there seemed little harm in getting
an early start on the next voting cycle. In fact, even after making all
the desired changes, I carefully marked both of these to have been approved
only on previous passes so that people's votes would not be misconstrued.
This kind of care may seem silly, but I believe it to be important.

I would not have been and will not be disturbed if neither AREF-1D nor
FORMAT-OP-C is presented to X3J13 due to our having had too little time
to review the most recent proposals internally and re-vote.

I want it clear that I have expressed no opinion on:
 KEYWORD-ARGUMENT-NAME-PACKAGE (Version 4)
 FORMAT-OP-C (Version 4)
If either of these documents is distributed to X3J13 prior to my having
expressed an opinion that they are acceptable in their current form, I
will be upset. [If it is possible for me to accept either or both in the
current form, I'll try to do so to minimize work for all, but I can't
guarantee that.]

By the way, the top of your message about KEYWORD-ARGUMENT-NAME-PACKAGE
says:

  ``I made the discussion less wishy-washy by saying we rejected disallowing
    NIL.  I made some edits to fix typos various people pointed out. I fixed
    the "grinding".''

In fact, you changed more than just the "Discussion" field. You changed
the Proposal field. I'm sure you meant to use the term generically and not
to specifically mislead me into looking only in the Discussion field to
see what you'd changed, but perhaps this illustrates why every word is so
important to me. One little difference (eg, the difference between "discussion"
and "Discussion") can really have a big effect.

∂05-Jun-87  2209	Masinter.pa@Xerox.COM 	Re: Sigh -- More procedure 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  22:09:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:45:45 PDT
Date: 5 Jun 87 21:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Sigh -- More procedure
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Sat, 6 Jun 87 00:11 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870605-214545-2882@Xerox>

I'm sorry Kent. In my rush to get things out to X3J13 and to respond to
the rather massive number of minor typos and corrections and remarks
that I recieved, I've been a bit sloppy about recording which sections
got edited in response to which remarks. One problem is that, as you say
yourself, people had been hesitating to say anything about proposals now
open up (at the last minute) with lots of comments on them; in many
cases, they are relevant and useful comments, and the only reasonable
thing to do is to address the comments in the proposal. 


I will say that I don't (and didn't) intend to release documents to
X3J13 without there being some opportunity for objections by this
committee. 

The "the cleanup committee endorses this ..." statements are of course
provisional. However, if we want to say that we endorse something by
consensus then I need to write it in the proposal itself. If the
proposal says "FOO and JOE like this proposal." and then we all agree,
and I edit it to say "we all agree", then, by your own rules, I'd have
to send it out again for yet another ballot since the wording changed.)

I think we have a little more flexibility about wording than was
available CLtL because the wording of these proposals are in fact
subject to the interpretation of the committee that actually writes the
standards document. That is, we're specifying intent and not exact
wording. 

I will be more careful identifying the changes to proposals, and my use
of "Ready for release". (I don't expect to send out any documents to
CL-CLEANUP with the annotation "Ready for release" because, if you've
already seen it and voted on it, then I don't need to send it out again,
do I?)

I'm finally done going through all of the ballots and suggestions and
what have you. I will mail out a new status report shortly, and also
some revised versions of some of the proposals.

∂05-Jun-87  2209	Masinter.pa@Xerox.COM 	Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  22:09:17 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:48:23 PDT
Date: 5 Jun 87 21:48 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
Message-ID: <870605-214823-2885@Xerox>

(This was prepared before Kent's angry note.   I'm a little reluctant to
mail it out now, but I don't know what to do with it. I made the edits
in response to Kent's question, as well as changing the case of the lisp
words, changing revision to version, etc. I don't remember all of the
edits, but I spent quite a while on it.)

Rather than wait for some resolution of Kent's question about the
omission of the :DISPLACED-TO argument, I took the liberty of guessing
that adjusting a displaced-to array without setting the :displaced-to
meant that the result was displaced to the same place. I inserted rule 3
and renumbered the rules.

The previous version got lots of yes ballots. Any objections to this
one?

!
Issue:        ADJUST-ARRAY-DISPLACEMENT
Reference:    ADJUST-ARRAY (Steele p.297)
Category:     Clarification
Edit history: Version 1 by Fahlman, 18-Apr-87 (from Steele's list)
              Version 2 by Masinter
              Version 3 by Masinter, 5-Jun-87 (respond to comments)

Problem Description:

The interaction of ADJUST-ARRAY and displacement is insufficiently
specified in the case where the array being adjusted is displaced.

Proposal: ADJUST-ARRAY-DISPLAYCEMENT:RULES

Suppose we are adjusting array A, which is perhaps displaced to B before
the ADJUST-ARRAY call and perhaps to C after the call.

(1) A is not displaced before or after: The dimensions of A are altered,
and the contents rearranged as appropriate.  Additional elements of A
are taken from the :INITIAL-ELEMENT.  The use of :INITIAL-CONTENTS
causes all old contents to be discarded.

(2) A is not displaced before, but is displaced to C after.  As
specified in CLtL, none of the original contents of A appears in A
afterwards; A now contains the contents of C, without any rearrangement
of C.

(3) A is displaced to B before and after the call (A is displaced to B
before the call, and the :DISPLACED-TO argument of ADJUST-ARRAY either
is ommitted or is B.) The dimensions of A are altered, and the contents
rearranged as appropriate. If :DISPLACED-INDEX-OFFSET is not specified
in the ADJUST-ARRAY call, it defaults to zero; the old offset is not
retained. 

(4) A is displaced to B before the call, and is displaced to C after the
call.  As in case (2), the contents of B do not appear in A afterward
(unless such contents also happen to be in C).  If
:DISPLACED-INDEX-OFFSET is not specified in the ADJUST-ARRAY call, it
defaults to zero; the old offset (into B) is not retained.

(5) A is displaced to B before the call, but not displaced afterward.  A
gets a new "data region", and contents of B are copied into it as
appropriate to maintain the existing old contents; additional elements
of A are taken from the :INITIAL-ELEMENT.  However, the use of
:INITIAL-CONTENTS causes all old contents to be discarded.

If array X is displaced to array Y, and array Y is displaced to array Z,
and array Y is altered by ADJUST-ARRAY, array X must now refer to the
adjusted contents of Y.  This means that an implementation may not
collapse the chain to make X refer to Z directly and forget that the
chain of reference passes through array Y.  (Cacheing techniques are of
course permitted, as long as they preserve the semantics specified here
and in CLtL.)

If X is displaced to Y, it is an error to adjust Y in such a way that it
no longer has enough elements to satisfy X.  This error may be signalled
at the time of the adjustment, but this is not required.

Rationale:

This interaction must be clarified.  This set of rules was proposed some
time ago, as a result of discussions on the Common Lisp mailing list,
and this model has been adopted by many Common Lisp implementations.

Current Practice:

Many implementations currently follow the model proposed here.  Others
may do something random.  [See discussion below.]

Adoption cost:

Some existing implementations may have to be changed, but adopting any
other model would be worse.  Public-domain code implementing this model
is available from CMU.

Benefits:

Clarification of a situation that is currently not addressed by the
standard.

Conversion Cost:

This is a relatively uncommon situation, which is the reason it didn't
occur to the original language designers to specify how it works.  Any
user code that cares about this issue probably already follows the
proposed model.

Discussion:

The cleanup committee supports this clarification.

Moon pointed out that the Symbolics system currently does this, except
for case (5) above. The Symbolics system never copies the contents of B
in this case; all elements are taken from the :initial-element. However,
the behavior in the proposal seems as justifiable to him, and the
cleanup committee decided to stick with the proposal as described above.

∂05-Jun-87  2209	Masinter.pa@Xerox.COM 	AREF-1D (Version 4)   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  22:09:28 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:52:52 PDT
Date: 5 Jun 87 21:52 PDT
From: Masinter.pa@Xerox.COM
Subject: AREF-1D (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-215252-2889@Xerox>

Besides changing arity-> rank and various  whichs to thats, I think I
probably made some other minor edits, but didn't intentionally change
the meaning. However, I do remember trying to soften the feeling that
you had to know and want MacLisp's LISTARRAY and FILLARRAY for this to
be a good idea, and to take the blow-by-blow of who liked what in
previous versions out of the discussion. Note that the issue is still
called AREF-1D even those the proposal is ROW-MAJOR-AREF. 

Status: Ready for release?
 

!
Issue:        AREF-1D
References:   Arrays (pp286-298)
Category:     ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
              02-Jun-87, Version 2 by Pitman (call it ROW-MAJOR-AREF)
               6-Jun-87, Versions 3, 4 by Masinter (editorial work)

Problem Description:

It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying rank.
Currently, you have to make a displaced array to work with temporarily
and then throw away the displaced array when you're done. In many cases,
this is bothersome because there is no a priori reason why they should
have to cons at all.

Proposal (AREF-1D:ROW-MAJOR-AREF):

Introduce a new function ROW-MAJOR-AREF that allows one-dimensional
access to the storage backing up a given array assuming the normal
row-major storage layout.

ROW-MAJOR-AREF is valid for use with SETF.

Rationale:

Common Lisp requires row-major storage layout of arrays and has a number
of operators that allow users to exploit that order. ROW-MAJOR-AREF is a
useful, simple addition.

LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops that had the following form:

    (DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
      ... (ROW-MAJOR-AREF ARRAY I) ...)

Currently, the only really efficient way to write this would involve
something like:

    (ECASE (ARRAY-RANK ARRAY1)
      ((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
      ((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
	     (SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
      ((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
	     (DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
	       (SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
      ...some finite number of clauses...)

Current Practice:

Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.

Adoption Cost:

This change is fairly localized. In implementations that already use
this primitive internally, it's little more than a matter of changing
the name of or otherwise releasing the existing primitive. In some
implementations, it might involve writing a small amount of code or
compiler work to make ROW-MAJOR-AREF work efficiently.

Benefits:

This gives users efficient access to something to which they already
have inefficient access.

Conversion Cost:

This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely
to be used by any current program.

Aesthetics:

This allows certain programs to be written in a more aesthetic way.

Discussion:

The cleanup committee supports this enhancement.

∂05-Jun-87  2209	Masinter.pa@Xerox.COM 	proposal format (version 10)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  22:09:39 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:54:55 PDT
Date: 5 Jun 87 21:54 PDT
From: Masinter.pa@Xerox.COM
Subject: proposal format (version 10)
To: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-215455-2893@Xerox>

This version incorporates some minor comments.


!
Format for proposals to "clean up" Common Lisp.
Version 10 -   5-Jun-87
 Replace the text below in >> double inverted angle-brackets <<. Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upcase all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.
Issue: >>A short descriptive label, which starts with a name which
occurs in the index of CLtL, and be a suitable symbol in the Common Lisp
style, e.g., CDR-TERMINATION.   .<<
References:  >>The pages of CLtL which describe the feature being
discussed, or other references..<<
Category:   >>One or more of: CLARIFICATION -- proposal to resolve an
ambiguity or case of under-specified situation in CLtL, where this
ambiguity interferes with portability of code. CHANGE -- proposal for an
incompatible change to the language.  ADDITION -- proposal for a
compatible extension to the language. <<
Edit history: >>Author and date of submission (version 1), and author
and date of subsequent versions.<<
Problem description:  >>Describe the problem being addressed -- why is
the current situation unclear or unsatisfactory? Avoid describing the
proposal here or arguing for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing.  Ideally, this should take the form of
text that could be dropped into CLtL or some new specification document.
If necessary, propose a set of labelled alternatives here, rather than a
single proposal. Each proposal must be a complete design; do not leave
out details.  Avoid arguing for the proposal here, just describe it.<<
Test Case: >>When possible, give a sample of Common Lisp code that
illustrates the issue.<<
Rationale:  >> A brief argument for the proposal. (If more than one
proposal is listed, discuss each issue separately here and in subsequent
sections.)<<
Current practice: >>Do some/many/no Common Lisp implementations already
work this way? Survey independent Common Lisp implementations -
preferably three or more.<<
Adoption Cost: >>What is the cost to implementors of adopting the
proposal?  How much implementation effort is required?  Is public-domain
code available? For pervasive changes, can the conversion be
automated?<<
Cost of non-adoption: >>How serious is it if nothing is done? <<
Benefits: >>What is better if the proposal is adopted? How serious is
the problem if just left as it is? <<
Conversion Cost: >>For incompatible changes, what is the cost to users
of converting existing user code?  To what extent can the process be
automated? How?<<
Esthetics: >>How does this proposal affect the simplicity of the
language, ease of learning, etc.<<
Discussion: >> Additional arguments, discussions, endorsements,
testimonials, etc. should go here. A blow-by-blow account of debates is
not necessary. <<

∂05-Jun-87  2210	Masinter.pa@Xerox.COM 	Issue: FLET-IMPLICIT-BLOCK (Version 6)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  22:09:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 21:57:51 PDT
Date: 5 Jun 87 21:57 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Issue: FLET-IMPLICIT-BLOCK (Version 6)
Message-ID: <870605-215751-2896@Xerox>

I think all I did was minor formatting changes (e.g., Defun => DEFUN,
Revision -> Version, SEF -> Fahlman, etc.) although it was a long time
ago today and I'm not 100% sure.

Status: Ready for release?

!
Issue:        FLET-IMPLICIT-BLOCK
Reference:    CLtL p. 113, 67
Category:     Omission. 
Edit history: Version 2 by cleanup committee 15-Mar-87 15:13:33
              Version 3 by Masinter (reformatting) 7-Apr-87 17:49:12 
              Versions 4,5 by Fahlman 11-Apr-87
              Version 6 by Masinter  5-Jun-87


Problem Description:

Do FLET, LABELS, DEFMACRO, MACROLET, DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE have an implicit block around their bodies like the body of a
DEFUN?  CLtL is silent on this point.  Many users and some implementors
assume that such blocks should be established, since they view these
forms as analogous with DEFUN.

Test case:

(defun test ()
  (flet ((test (x) (if x (return-from test 4) 3)))
	(list (test nil) (test t))))

(test)

will return (3 4) if FLET-IMPLICIT-BLOCK:YES is adopted, and would
return 4 in an implementation that did not add an implicit block around
Flet.

Proposal: FLET-IMPLICIT-BLOCK:YES

Each function created by FLET and LABELS and each macro created by
DEFMACRO and MACROLET has an implicit block around the body.  The name
of this block is that same as the (lexical) name of the function or
macro.  Similarly, the body code in DEFSETF, DEFINE-SETF-METHOD, and
DEFTYPE is surrounded by a block with the same name as the accessor or
type.

Current Practice:

Current practice is mixed.  Several implementations do not add the
implicit block, others do, some add some of these blocks and not others.

Cost of adopting this change:

Some implementations will have to be modified.  This should be a
relatively easy modification.

Cost of not adopting the change:

If the issue is not clarified one way or another, continuing confusion
will result in portability problems.  Clarifying the issue in any other
way would also require modifications in some implementations.

Cost of converting existing code:

It is possible that some user code would break because it does a return
from within a code body to an outer block that has the same as the
newly-required block.  Such problems will be rare, and the code in
question would not run on all current Common Lisp systems because of the
diverse interpretations currently in effect.  It would be possible to
detect all such instances automatically, though it seems unlikely that
anyone will need to use this technique.

Discussion:

The goal is first to clean up an ambiguous situation and, second, to do
this in a way that provides consistent behavior between local and global
definitions.  The proposed change would allow a simple rule of thumb:
any named entity that takes a code body establishes an implicit block
with the obvious name.

Two alternatives to the proposal were considered and rejected:

The first would be to keep the implicit block in DEFUN, and to clearly
state that the other forms do not create implicit blocks.  This violates
the goal of consistency between lexical and global definitions, and it
seems to conflict with users' expectations.

The second alternative was to eliminate the implicit block from DEFUN
rather than adding such blocks to other forms.  There was some feeling
that specifying the implicit block in DEFUN was a poor design decision
in the first place, since it hides a reference to the name of a function
within the code of the function itself.  If a user decides to rename
some function, he must be careful to rename any return-from forms within
the body of the function as well.

However, eliminating the implicit block in DEFUN would be a significant
incompatible change.  Some users find this implicit block to be a great
convenience for popping out of convoluted code, and some existing code
makes heavy use of this feature.  While such code could be repaired
automatically by searching for situations in which the user returns from
a function by name and by adding an appropriate explicit block to any
function containing such a forms, it would still require more more work
on existing user code than this proposal made above.

There was considerable discussion in the cleanup committee about whether
these implicit blocks would interfere with tail-recursion optimization,
which we hope will become more common in future Common Lisp
implementations.  The outcome of these discussions was general agreement
that a compiler could easily eliminate the implicit block in any case
where it is not actually used, and that the impact on tail-recursion
optimization in compiled code is therefore minimal.

∂05-Jun-87  2235	Masinter.pa@Xerox.COM 	Re: proposal format (version 10)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  22:35:32 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 22:19:34 PDT
Date: 5 Jun 87 22:19 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: proposal format (version 10)
In-reply-to: Masinter.pa's message of 5 Jun 87 21:54 PDT
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <870605-221934-2920@Xerox>

The "proposal format" I mailed looks much better with fonts rather than
in plain ascii. However, since we prefer proposals in ascii rather than
formatted (or at least, I do) I am going to reformat it so that it looks
good with a simple fixed-pitch font, no italics, etc.

(I'm sorry to say that I looked at the without-formatting version for
the first time when I got the bounce back from the arpanet.)



∂05-Jun-87  2250	Masinter.pa@Xerox.COM 	Issue: COMPILER-WARNING-STREAM (Version 6)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  22:50:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 22:38:06 PDT
Date: 5 Jun 87 22:37 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: COMPILER-WARNING-STREAM (Version 6)
To: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-223806-2928@Xerox>

This one had just revision -> Version and KMP -> Pitman.

Status:  ready for re-release! No ? about it.

!
Issue:        COMPILER-WARNING-STREAM
References:   COMPILE (p438), COMPILE-FILE (p439)
Category:     CLARIFICATION/CHANGE
Edit history: Version 1 by Pitman 02/27/87
              Version 2 at committee meeting 15-Mar-87
              Version 3 Masinter 15-Mar-87
              Version 4 by Fahlman, incorporate Dribble
              Version 5 by Masinter, 29-May-87, revert to Version 3
              Version 6 by Masinter,  5-Jun-87, minor formatting
              

Problem Description:

The description of the COMPILE and COMPILE-FILE functions does not
explicitly permit them to print warnings. If this is to be allowed, it
should be an explicitly expressed part of the contract.

Proposal (COMPILER-WARNING-STREAM:ERROR-OUTPUT)

COMPILE and COMPILE-FILE are permitted to output warnings; warnings
should go to the stream that is the value of *ERROR-OUTPUT*.

Rationale:

Compiler warning output is a widely accepted extension to the
compilation. Warnings that come via the WARN function will go to the
stream that is the value of *ERROR-OUTPUT*.

Current Practice:

Some implementations send compiler warning output to *ERROR-OUTPUT*.
Other implementations send it to *STANDARD-OUTPUT*.

Adoption Cost:

In most cases, the change to the compiler to redirect output is expected
to be very slight.

Benefits:

Currently, it is difficult to redirect the output of COMPILE and
COMPILE-FILE because it isn't clear where it's directed.

Conversion Cost:

Most user programs that care are probably already tolerant of both
situations or naively expect that output will go to *ERROR-OUTPUT*. As
such, most users will probably perceive this as a clarification.

Aesthetics:

Most users will probably perceive this change as a simplification
because it will allow the kind of warning that comes from WARN and the
kind of warning that comes from compilation to be conceptually grouped.

Discussion:

This was a problem in adapting MACSYMA to Common Lisp because Macsyma
provides alternate user interfaces to the compiler which it needs to be
able to control.

The committee considered extending the proposal to describe the
interaction with DRIBBLE on the warning output, but found that DRIBBLE
was so underspecified as to make the task impossible. DRIBBLE should be
considered in a separate proposal.

The cleanup committee supports this change as stated.

∂05-Jun-87  2250	Masinter.pa@Xerox.COM 	Issue: DEFVAR-INITIALIZATION (Revision 3) 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  22:50:16 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 22:42:38 PDT
Date: 5 Jun 87 22:42 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-INITIALIZATION (Revision 3)
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-224238-2931@Xerox>



This version has revision => version, KMP => Pitman, removal of first
person by deleting "to me".

Status:  Version 3 released. Ready for re-release! (no ? about it).

!
Issue:        DEFVAR-INITIALIZATION
References:   DEFVAR (p68)
Category:     CLARIFICATION/CHANGE
Edit history: Version 1 by KMP 02/26/87
              Version 2 by cleanup committee 15-Mar-87
              Version 3 by Masinter (normalize format) 15-Mar-87
              Version 4 by Masinter  5-Jun-87

Problem description:

The description of DEFVAR on p.68 is not adequately clear on what
happens if an initialization value is not provided, as in (DEFVAR FOO).
Does this initialize the variable?

Proposal (DEFVAR-INITIALIZATION:CONSERVATIVE):

If the one-argument form of DEFVAR is used, the value (or lack of value)
of the variable is not changed.

Rationale:

In parent languages to CL, such behavior was documented. The omission of
clear documentation in CL is presumably an accident.

Current Practice:

Most implementations already do not initialize the variable. Some
implementations, however, assume that the missing initial value defaults
to NIL and assume that the variable is always to be initialized if
unbound.

Adoption Cost:

Some implementations suffer a minor incompatible change.  The
modification to systems is presumably trivial.

Benefits:

It's sometimes useful to have the ability to  initializing it. More
importantly, though, DEFVAR is used by lots of users in every
implementation and it deserves uniform treatment.

Conversion Cost:

It's stylistically poor to be relying on the variable to be initialized
without writing the initial value explicitly anyway. Except for very
rare situations where a conditional action is taken based on a BOUNDP
test of the variable, user programs are unlikely to be affected in
practice.

Very few user programs are likely to be affected. The incidence rate is
probably sufficiently low that the issue of automatic tools for
conversion is irrelevant.

Aesthetics:

No significant issues are obvious.

Discussion:

The cleanup committee supports this clarification.

∂05-Jun-87  2250	Masinter.pa@Xerox.COM 	Issue: DEFVAR-INITIALIZATION (Version 4)  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  22:50:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 22:43:39 PDT
Date: 5 Jun 87 22:43 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFVAR-INITIALIZATION (Version 4)
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870605-224339-2934@Xerox>

The subject of the previous message was wrong (it said Revision 3)

This version has revision => version, KMP => Pitman, removal of first
person by deleting "to me".

Status:  Version 3 released. Ready for re-release! (no ? about it).

!
Issue:        DEFVAR-INITIALIZATION
References:   DEFVAR (p68)
Category:     CLARIFICATION/CHANGE
Edit history: Version 1 by KMP 02/26/87
              Version 2 by cleanup committee 15-Mar-87
              Version 3 by Masinter (normalize format) 15-Mar-87
              Version 4 by Masinter  5-Jun-87

Problem description:

The description of DEFVAR on p.68 is not adequately clear on what
happens if an initialization value is not provided, as in (DEFVAR FOO).
Does this initialize the variable?

Proposal (DEFVAR-INITIALIZATION:CONSERVATIVE):

If the one-argument form of DEFVAR is used, the value (or lack of value)
of the variable is not changed.

Rationale:

In parent languages to CL, such behavior was documented. The omission of
clear documentation in CL is presumably an accident.

Current Practice:

Most implementations already do not initialize the variable. Some
implementations, however, assume that the missing initial value defaults
to NIL and assume that the variable is always to be initialized if
unbound.

Adoption Cost:

Some implementations suffer a minor incompatible change.  The
modification to systems is presumably trivial.

Benefits:

It's sometimes useful to have the ability to  initializing it. More
importantly, though, DEFVAR is used by lots of users in every
implementation and it deserves uniform treatment.

Conversion Cost:

It's stylistically poor to be relying on the variable to be initialized
without writing the initial value explicitly anyway. Except for very
rare situations where a conditional action is taken based on a BOUNDP
test of the variable, user programs are unlikely to be affected in
practice.

Very few user programs are likely to be affected. The incidence rate is
probably sufficiently low that the issue of automatic tools for
conversion is irrelevant.

Aesthetics:

No significant issues are obvious.

Discussion:

The cleanup committee supports this clarification.

∂05-Jun-87  2349	Masinter.pa@Xerox.COM 	Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  23:49:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 23:28:48 PDT
Date: 5 Jun 87 23:27 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Message-ID: <870605-232848-2962@Xerox>

Gregor said in his ballot that comments would follow, but I can't find
them. Did I miss them? I saw some notes about a more general facility
for accessors and constructors of lexical environments on the CLOS
mailing list, so I hoped I was on the mark by adding that to the
discussion section.

Kent asked that NIL be explicitly allowed for the null lexical
environment. I put that in. 

Version 2 got lots of yes ballots.

Status: Ready for release?

!
Issue:          GET-SETF-METHOD-ENVIRONMENT
References:     GET-SETF-METHOD (CLtL p 187)
Category:       Change
Edit History:   Version 1 9-Jan-87, Version 1 by Masinter (from Steele
list) 
                ...       7-Apr-87, merged with other environment
argument issues
                Version 2 29-May-87, by Masinter, extracted again 
                Version 3  5-Jun-87, by Masinter.
                
			
Problem Description:

If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,

 (defmacro special-incf ... (get-setf-method ...) ...)

then  

 (macrolet ((test (x) `(car ,x)))
         (special-incf (test z)))

would not "see" the test definition.

Proposal GET-SETF-METHOD-ENVIRONMENT:ADD-ARG:

Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. NIL can also be passed
explicitly to denote the null lexical environment.

Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.

Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.

Clarify that MACROLET, FLET and LABELS can shadow a SETF method; i.e., a
SETF method applies only when the global function binding of the name is
lexically visible.

Rationale:

This was an omission in the original definition of CLtL.

Current Practice:

Many Common Lisp implementations already have this extension, although
some do not.

Adoption Cost:

Some implementations will have to add this feature, although it is not a
major change.

Benefits:

This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.

Conversion Cost:

This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a users program is
very small.

Aesthetics:

SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct. 

Discussion:

The cleanup committee supports this change.

A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common
Lisp Object System) and should be addressed by a future proposal. For a
while, the cleanup committee attempted to deal with these issues
together, but decided to separate them out into their component parts.
This issue is the simplest.

∂06-Jun-87  0000	Masinter.pa@Xerox.COM 	***READ ME FIRST ***Status 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 5 Jun 87  23:59:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JUN 87 23:52:39 PDT
Date: 5 Jun 87 23:52 PDT
From: Masinter.pa@Xerox.COM
Subject: ***READ ME FIRST ***Status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870605-235239-2975@Xerox>

This is not meant to go outside of this committee, although it will be
the source for a status report. My belief is that, while we may want to
mail out proposals ahead of time, there is no need to mail out the
status report early, we might have more to report by the meeting anyway.

**** NOTE ***** I intend to mail the  proposals marked with a * (Ready
for release?) to mail to X3J13 by Wednesday of next week unless I hear
some objection.  (I think I'm a little upset that Kent is got so mad at
me.)  

If there is one issue we should debate about between now and the
meeting, I think it is FUNCTION-TYPE. We seem to have some agreement on
the core issue, and some disagreement on exactly how to proceed over the
issue of making FUNCALL (and MAPC) not take symbols.  I think this is
one where we should bring the debate to the whole X3J13 once the issues
are laid out.

Normally, before I send one of these out I double check all of the
entries against all of the mail files to make sure that I've left
something out. However, I'm tired and its late, and I've only checked
them out to GET-SETF-METHOD-ENVIRONMENT. 

In this document: EB = Benson, GLS = Steele, PC = Pavel Curtis, KMP =
Kent Pitman SEF = Scott Fahlman 
[name/initials] position => person identified by name/initials voted
position on ballot.
[all] position => everyone who voted on this issue voted this way
position on ballot.

Withdraw = Place on hold pending resolution of comments already
received.


Proposal format (Version 10)
	Needs re-formatting for non-fonted ascii
        ready for release otherwise?

* ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
	(Standardize interaction of adjust-array and displacement)
	Comments & edits after ballot.
	Ready for release?

ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
	(Extend adjust-array so its OK on non-adjustable arrays.)
	comments from Moon, JonL, SEF against current form
	[EB, PC, SEF] Withdraw
	Not ready for release

* AREF-1D (Version 4/5-jun-87)
	(Add a new function for accessing arrays with row-major-index)
	[all] Version 2 release as ROW-MAJOR-AREF
	Ready for release?

* ASSOC-RASSOC-IF-KEY (Version 1/22-Apr-87)
	(Extend ASSOC-IF, etc.  to allow :KEY)
	[EB, GLS, KMP] Release as is
	[LMM] ASSOC-IF has CAR for KEY?
	Ready for release?

COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
	Questions on interaction with condition proposal.
	Is this an environment issue?
	Not released.

* COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
	(Compiler warnings are printed on *ERROR-OUTPUT*)
	(Version 4, submittted by SEF was withdrawn --
	consider DRIBBLE as a separate issue) 
	Version 3 released.
	Version 6 ready for re-release!

* DEFVAR-INITIALIZATION (Version 4)
	((DEFVAR var) doesn't initialize)
	Version 3 Released
	Version 4 ready for re-release!

* DEFVAR-INIT-TIME (Version 2/29-May-87)
	(DEFVAR initializes when evaluated, not later.)
	Ready for release?
	
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
	(can DO-SYMBOLS see the same symbol twice?)
	[EB, GK] DO-SYMBOLS:ALLOWED
	[PC, Moon, LMM] something like :ADD-KEYWORD
	In discussion, not ready for release
	
ENVIRONMENT-ARGUMENTS (Version 1)
	Separated into other proposals.
	Withdrawn.

FILE-WRITE-DATE-IF-NOT-EXISTS 
	(What does FILE-WRITE-DATE do if no such file?)
	Not yet submitted.

* FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
	(do FLETs have implicit named blocks around them?)
	Ready for release?

* FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
	Version 3 released.
	Version 4 ready for re-release.

FORMAT-NEGATIVE-PARAMETERS
	Not yet submitted; mail 19-May by KMP

* FORMAT-OP-C (Version 4/ 5-Jun-87)
	(What does ~C do?)
	Ready for release?

FUNCTION-TYPE (Version 4/ 29-May-87)
	(Change definition of FUNCTIONP, function type ...)
	 [EB, GLS, PC] Release as is [GK] Stronger [Moon] OK after comments
addressed 
	[KMP] break in two, so I could
       support the half I like and only grump about the parts I don't
	want stronger warning
	[SEF] 2-option, 3-option version

GET-SETF-METHOD-ENVIRONMENT (Version 3, 5-jun-87)
	(Environment argument for GET-SETF-METHOD)
	[EB, GLS, PC, Moon, SEF] Release as is 
	[GK] Ballot says comments follow, but no comments?
	[KMP] NIL as null lexical environment


GC-MESSAGES (version 1)
	(Control over unsolicited GC messages in typescript)
	Submitted by Pitman 23-Apr-87
	In discussion: merge with other controls for
	unsolicited messages?

* IF-BODY (Version 5, 29 Apr 87)
	(extend IF to implicit progn if more than one ELSE form?)
	General agreement to recommend against.
	While EB, PC, Moon voted to wait for a version that KMP and SEF
		agreed was fair, SEF said 5 was fair enough.
	Ready for release

IGNORE-ERRORS (Version 4, 29-May-87)
	[EB, LMM, PC, Moon] Wait for error proposal
	[GLS, KMP, SEF] Release as is (but remove "Larry wonders ...") 
	LMM wants KMP to submit as proposal from Error committee


IMPORT-SETF-SYMBOL-PACKAGE (Version 4/ 29-May-87)
	Version 3 Released
	Version 4 ready for re-release after Revision->Version

KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5/5 Jun)
	[EB, GLS, PC, Moon] Release as is (some typos) [SEF] Comments

MACRO-FUNCTION-ENVIRONMENT 
	Not yet submitted (From ENVIRONMENT-ARGUMENTS)

PATHNAME-STREAM (Version 2)
	[EB, GK, PC, Moon, SEF] Release as is

PATHNAME-SYMBOL (Version 2)
	[GLS, PC, Moon, KMP, SEF] Release as is [eb] against, want minority
view (needs formatting)
	Moon " cover every argument that is called pathname, filename, file, or
new-name
         and leave the rest of the ambiguities for another proposal?"
	Not ready for release

PEEK-CHAR-READ-CHAR-ECHO (Version 1)
	Agreed to be controversial
	[EB, GLS, PC, KMP] Withdraw from consideration, await new proposal

PRINC-CHARACTER (Version 3)
	Mailed by KMP 29-Apr-87.
	Ready for release?

PROCLAIM-LEXICAL  (Version 1)
	In discussion
	Some progress
	Need volunteer to merge comments into new version

PROMPT-FOR (Version 1)
	Agreed to be controversial
	[EB, PC, Moon, SEF] Withdraw

PUSH-EVALUATION-ORDER
	(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
	Not yet submitted. [PC, SEF] (PUSH FIRST SECOND)

REMF-DESTURCTION-UNSPECIFIED (Version 1)
	Submitted by DLA
	Discussion?
	Not ready for release.

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
	(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
	Version 2 by KMP 28 Apr 87 
	In discussion, no clear consensus
	[EB] Unchanged [PC, KMP, SEF] Undecided

SHARPSIGN-BACKSLASH-BITS
	(What does C-META-H-X mean?)
	Mild for this proposal, but preference for
	removing FONT and BITS attribute 
	 [EB] Release as is  [pc, KMP] no, remove bits & font, fuller character
proposal

SHARPSIGN-PLUS-MINUS-NUMBER
	Discussed, without general agreement.
	Withdraw?

SHARPSIGN-PLUS-MINUS-PACKAGE
	Seems like general agreement for :KEYWORD.
	Need to remove other options from proposal.

SPECIAL-FORM-SHADOW
	Is it OK to shadow a special form with FLET, LABELS?
	Not yet submitted
	(From ENVIRONMENT-ARGUMENTS)

TAILP-NIL
	Not yet submitted.
	Needs volunteer to format.
	Notes from Moon

UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
	In discussion
	Need volunteer to summarize issues.

∂06-Jun-87  1412	RPG  	A Hole in Common Lisp   
To:   cl-cleanup@SAIL.STANFORD.EDU    

Consider the nature of arguments to functions. In Common Lisp we have
these two notions: positional arguments and named arguments. In the first
case values are associated with variables depending on the positions of
passed arguments.  In the latter case, the binding happens depending on
the names of the arguments, which are passed along with the arguments.

For example:

(defun f (x y &key a b) ...)

(f 1 2 :b 3 :a 4)

X and Y are positional, and A and B are named.

There is a second pair of notions: required arguments and optional arguments.

Does Common Lisp have all of the combinations of these notions?

         | positional |	named |
-------------------------------
required |    yes     |  no   |
-------------------------------
optional |    yes     |  yes  |
-------------------------------

It doesn't seem so. Keyword arguments combine named and optional.

Also there is no way to have a function with both required keyword and
truly optional positional arguments.

Suppose someone writes

(defun f (x y &optional a b &key foo bar baz ola)
 (list x y a b foo bar baz ola))

and this form is evaluated:

(f <a1> <a2> <a3> <a4> <a5> <a6> <a7> <a8>)

The binding of the variables in the function definition goes like this:

x is bound to <a1>, y is bound to <a2>, a is bound to <a3>, and b is
bound to <a4>. Now we lift our heads from the sand and look at what
<a5> is. It should be one of :foo, :bar, :baz, or :ola. Now suppose
we had written:

(f 1 2 :foo 4 :bar 5 :baz 6)

Did the user intend for a to be bound to :foo, or did he intend for
a and b to not be supplied?

Here is an off the wall proposal for lambda expressions; it includes
Moon's proposal for non-keyword package symbols to be names of arguments:

(lambda ({var}*
         [&optional {var | (var [initform [svar]])}*]
         [&required-key {var | (name var)}*]
	 [&rest var]
         [&key {var | (name var)} [initform [svar]])}*
               [&allow-other-keys]]
         [&aux {var | (var [initform])}*])
   {declaration | documentation-string}*
   {form}*)

where var, initform, svar are exactly as before, and name is the name of
a keyword argument, which can be a symbol in any package. Parsing an
argument list proceeds as follows:

Let nrp be the number of required positional parameters. The first nrp
supplied arguments are paired with the nrp required positional parameters.
The remaining supplied arguments are scanned left-to-right, starting with
scanning for positional optionals.  If a supplied argument is EQ to one of
the required named parameters names, the scanning for positional optionals
ends and all unpaired positional optionals are defaulted according to the
lambda-list specification; then named parameter parsing begins. If a
supplied argument is not EQ to any required named parameter name, it is
paired with the next positional optional parameter.

Once the scanning for optional positional parameters has ended, scanning
for named parameters begins.  Named parameter parsing is as in current
Common Lisp, except that if, at the end, there are unsupplied
required named arguments, an error is signaled.

The difference between this parsing algorithm and the current Common Lisp
one is that the occurrence of the first required named parameter stops
parsing of positional optionals. Therefore, the only way to pass the name
of required named parameter is as a required positional or required named
argument. Also, if optional named arguments appear to the left of all
required named arguments, they can be taken as positional optionals.

Examples:

(defun f (x y &optional a b &required-key foo bar &key baz ola)
 (list x y a b foo bar baz ola))

(f 1 2 3 4 :foo 5 :bar 6 :baz 7 :ola 8) 
 => (1 2 3 4 5 6 7 8)

(f 1 2 3 :bar 4 :baz 5 :foo 6 :ola 7)
 => (1 2 3 nil 6 4 5 7)

(f 1 2 :baz 3 :foo 4 :bar 5)
 => (1 2 :baz 3 4 5 nil nil)

(f 1 2 :baz :foo 3 :bar 4)
 => (1 2 :baz nil 3 4 nil nil)

This has the advantage that it could make some things in CLOS easier
to deal with. For example, we could define methods that discriminated
on the names of required named arguments:

(defmethod foo (x y &required-key foo bar) `(foobar ,x ,y ,foo ,bar))
(defmethod foo (x y &required-key baz ola) `(bazola ,x ,y ,foo ,bar))

(foo 1 2 :foo 3 :bar 4) => (foobar 1 2 3 4)
(foo 1 2 :baz 3 :ola 4) => (bazola 1 2 3 4)
(foo 1 2 :foo 3 :ola 4) => error

			-rpg-

∂06-Jun-87  1630	RPG  	FUNCTION-TYPE 
To:   cl-cleanup@SAIL.STANFORD.EDU    

I regard this issue as a put-up-or-shut-up affair. I prefer
the formulation that states that APPLY and FUNCALL take functions,
and you have to coerce symbols and lambda-expressions to be functions
before you can APPLY or FUNCALL them to more lenient formulations.

If we do not go with this formulation, then I would say an
important design criterion of the cleanup is:

Changes that introduce or retain inconsistencies which confuse new users
and which complicate the rules of the language are preferable to changes
that cause old programs to stop working.

I think Common Lisp is so messed up that the cleanest change to
function types will not effect major improvements. Our position
with respect to EuLisp will be more difficult.

Put up or shut up: I don't care which you choose.

			-rpg-

∂06-Jun-87  1802	FAHLMAN@C.CS.CMU.EDU 	A Hole in Common Lisp       
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 6 Jun 87  18:02:19 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 6 Jun 87 21:01:40-EDT
Date: Sat, 6 Jun 1987  21:01 EDT
Message-ID: <FAHLMAN.12308458446.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Cc:   cl-cleanup@SAIL.STANFORD.EDU
Subject: A Hole in Common Lisp   
In-reply-to: Msg of 6 Jun 1987  17:12-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>


Of course, it's too late for Common Lisp -- this would be a VERY
incompatible change for no very good reason.  And, of course, you can
get the effect of a required keyword argument by signalling an error in
the init form.  We could provide some conventional function for
signalling this error and CLOS could recognize this and treat that arg
as required.

Even if I were designing a new Lisp from scratch, I'm not sure that I
would want to fill in the fourth box in your matrix.  By-name arguments
are for functions that have so many arguments that you can't remember
the order, or so many that it is convenient just to type in the two or
three you need and not the twenty you don't need.  But if the by-name
arguments are required, you have to type them all.  Furthermore, you
must remember them all (or look them up to make sure you haven't
forgotten one), and in that case you may as well enter them in the
canonical order.

Even if I wanted to mix positional and named args in a single function,
I don't like your way of doing it -- it seems treacherous to me.  If the
value of certain arguments to a function happen to match the named
arguments, things get interpreted in an unintended and very mysterious
way.  This would only be a good scheme if there were absolute separation
between the space of legal arguments and the space of arg names.  We
would have to go back to saying that all keywords must be keywords, and
we would also have to eliminate the practice of using keywords for other
things.  Or else we would have to create a new kind of object that is
reserved for use in arg names.

I have sometimes thought that if I were designing a lisp-like language
from scratch, I would leave the question of by-postion or by-name
arguments to the caller of a function.  He's the one who can decide
whether he wants to remember the order of arguments or to do some extra
typing.  A lambda would have the following simple form (setting aside
&rest and &more arguments for now, and flushing &aux, which was a
mistake from the start):

(lambda ({var | (var intiform) | (var initform svar) }* )
   declarations, docs, body, etc. )

Variables with no initform are required.  They need not be at the head
of the list.

There are two forms of function calling, postional and by-arg-name
either of which can be used on any function.  They need to be
syntactically distinguished somehow.  I'll use square brackets to group
the name/argument pairs in the latter -- this might be a read macro that
turns into some three-element list with a reserved token in the car.

(function-name pos-arg-1 pos-arg-2 pos-arg-3 ...)

(function-name [nameX argX] [nameY argY] ...)

The latter form says to look up the argument names at the time of the
call and rearrange the call into the order the function is expecting;
cacheing of this step is encouraged.  The order of evaluation of a
function's args would be explicitly unpredictable in this language, so
the rearrangement is legal and not difficult.

Then the function gets called, unsupplied args get their initforms
evaluated, and if any of the required args does not have a value
assigned, an error is signaled.  If the lambda list has any optional
args before a required arg, the only way NOT to supply a value for the
optional args is to use the by-name form of call.

One can imagine versions of this in which the caller can mix positional
and named args -- some arguments and then some bracketed pairs -- but if
this is allowed, one would have to worry about what happens if the same
variable gets a positional value and a by-name value.  Signal an error,
I guess, or say that the result is indeterminate.

-- Scott

∂07-Jun-87  0826	FAHLMAN@C.CS.CMU.EDU 	Rules   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87  08:26:52 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 11:26:18-EDT
Date: Sun, 7 Jun 1987  11:26 EDT
Message-ID: <FAHLMAN.12308615853.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: Rules


I think that KMP is a bit out of line in complaining that he has now
blown his entire time budget for this stuff and that new versions are
somehow out of line.  When problems are spotted, even late in the
process, they have to be fixed, and then we need another round of
consideration.  Things only become final if we manage to come up with a
version that nobody objects to, or if we explicitly agree to disagree.
For those of us who insist upon having a say on the final form of every
issue, it is impossible to set an a priori limit on the time that will
be required.  We need some balance between the power of the chairman to
ram through a lot of unexamined changes at the last minute and the power
of any one member to block progress because he has some other commitments.

However, I agree with KMP that Masinter is at fault in several areas.
The most serious problem is that he has greatly increased the amount of
time the rest of us must spend in considering new versions by changing
things in gratuitous and unrecorded ways.  Larry also put a few of his
own ideas into the new versions without any prior discussion -- a
practice he used to complain bitterly about when I was chairman.
Finally, he has thrown everyone into a panic by making it look like a
modified proposal might go out with a statement of support by people who
stated support for the previous version and not necessarily the current
one.

-- Scott

∂07-Jun-87  1150	KMP@STONY-BROOK.SCRC.Symbolics.COM 	FUNCTION-TYPE 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 7 Jun 87  11:50:32 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 166143; Sun 7-Jun-87 14:50:04 EDT
Date: Sun, 7 Jun 87 14:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE 
To: RPG@SAIL.STANFORD.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 6 Jun 87 19:30 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <870607144946.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 06 Jun 87  1630 PDT
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    ... Changes that introduce or retain inconsistencies which confuse new
    users and which complicate the rules of the language are preferable to
    changes that cause old programs to stop working.

    I think Common Lisp is so messed up that the cleanest change to
    function types will not effect major improvements. Our position
    with respect to EuLisp will be more difficult. ...

I disagree with your claim that a change to the function types alone will
not make a major improvement in the language.

We can define any function to do anything we want. That in itself does
not make the language inconsistent. There is nothing inconsistent about
defining the functions FUNCALL and APPLY to take arguments which are
coercible to functions, especially if you also make it clear that you
can put things in function cells which are coercible to functions.
This is no more unreasonable than allowing any function to coerce its
argument. Consider STRING-DOWNCASE of a symbol, for example.

One of the great powers of types in a language is that you can tell when
you have one that is not quite suitable and define an interpretation for
it. If you require exactly one type as an argument to all functions, you
alienate the whole notion of generic functions and take us into a world
that more resembles CLU, where you need one function for every type.

If all we did was fix the types and not fix the business about what can go
in the cells or be given to APPLY or FUNCALL, we'd still have a lot.

Consider that if the EuLisp guys don't like our definition of the functions
and want to run EuLisp compatibility in our lisp, they can effectively do:

 (IN-PACKAGE "EULISP" :USE "CL")
 (SHADOW '(APPLY FUNCALL))
 ...
 (DEFUN APPLY (FUNCTION &REST SPREAD-ARGUMENTS)
   (CL:APPLY (THE FUNCTION #'CL:APPLY)
	     (THE FUNCTION FUNCTION) SPREAD-ARGUMENTS))
 (DEFUN FUNCALL (FUNCTION &REST ARGUMENTS)
   (CL:APPLY (THE FUNCTION FN) ARGUMENTS))

And as for us, we can do the following to win in theirs:

 (IN-PACKAGE "COMMONLISP" :USE "EU")
 (SHADOW '(APPLY FUNCALL))
 ...
 (PROCLAIM '(INLINE COERCE-TO-FUNCTION))
 (DEFUN COERCE-TO-FUNCTION (FN)
   (FLET ((FAIL () (ERROR "Not a function: ~S" FN)))
     (TYPECASE FN
       (FUNCTION FN)
       (SYMBOL (SYMBOL-FUNCTION FN))
       (LIST (IF (EQ (CAR LIST) 'LAMBDA)
		 (EVAL ,LIST)
		 (FAIL)))
       (OTHERWISE (FAIL)))))
 (DEFUN APPLY (FN &REST SPREAD-ARGUMENTS)
   (EU:APPLY #'EU:APPLY (COERCE-TO-FUNCTION FN) SPREAD-ARGUMENTS))
 (DEFUN FUNCALL (FN &REST ARGUMENTS)
   (EU:APPLY (COERCE-TO-FUNCTION FN) ARGUMENTS))

Not much code for either side.

The thing which makes this so easy going both directions is the agreement
on making the FUNCTION type something that you can get leverage out
of.

The issue of how you deal with that type in any given function is
interesting, but need not (and I think should not) be intimately tied
up with this much more important issue that we probably can and should
all agree upon.

You might say that this is so little code that we should go the extra
little bit and just agree to make the mechanisms the same, but I don't
think that would be wise. To go further for us would compromise large
bodies of existing code and built-in philosophies about Lisp and what
it can do for them. To go further for the Eulisp guys might compromise
their existing code and their philosophies. I think that either side
has a defensible reason for maintaining their ground and that it is
appropriate to agree not to agree on this issue.

∂07-Jun-87  1259	FAHLMAN@C.CS.CMU.EDU 	FUNCTION-TYPE     
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87  12:52:16 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 15:51:42-EDT
Date: Sun, 7 Jun 1987  15:51 EDT
Message-ID: <FAHLMAN.12308664162.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: FUNCTION-TYPE 
In-reply-to: Msg of 7 Jun 1987  14:49-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


I think the issues involved in FUNCTION-TYPE are now clearly drawn and
we may as well settle this whole package one way or the other, rather
than separating the issue into parts, settling the type cleanup now, and
letting the related questions hang in limbo for another six months.
It's a bit frightening to me personally to propose this, since I won't
be at the Boston meeting, but I'd rather have a clear decision in favor
of ANY of the three proposals than to let this hang indefinitely.

It is reasonable to let questions hang if we're waiting for some related
issues to be resolved or if technical work needs to be done (as in
solving the macro problem for Lisp-1) or if people really need time to
study the implications of a proposed change.  I don't see any of those
factors at work in the FUNCTION-TYPE issue -- it is a straightforward
question of whether we want to remove some ugly tangles from the
language at the expense of breaking some existing code.  This question
is not going to get any easier, and until it is decided we all have to
code defensively.

Shall I attempt to write up FUNCTION-TYPE as a three-option proposal
that can be debated and voted on in Boston?

-- Scott

∂07-Jun-87  1318	KMP@STONY-BROOK.SCRC.Symbolics.COM 	FUNCTION-TYPE 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 7 Jun 87  13:18:22 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 166175; Sun 7-Jun-87 16:17:14 EDT
Date: Sun, 7 Jun 87 16:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12308664162.BABYL@C.CS.CMU.EDU>
Message-ID: <870607161700.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I do not believe that all that can be usefully said about FUNCTION-TYPE
has been said. For example, I would like to discuss further this issue
you raised of providing a function to get the original s-expression from
a coerced function (of clean-type FUNCTION). T has such a function.
Its mere presence doesn't make everything ok, but it might contribute
to some overall theory. Before making a proposal, I need to study the
consequences of having it a bit more -- and I have no time to do that
right in the next couple of weeks. The details of this issue could
affect my view on the proposal currently on the table.

For reasons such as this, I feel that it would be premature to bring
FUNCTION-TYPE to the table at this meeting. I'd rather see this brought
to X3J13 only when we were sure we had things carefully thought out, to
preclude wasting valuable time in in-person meetings due to inadequate
preparation. The fact that Steele (and you?) will not be at the Boston
meeting is another good reason to wait.

Let's just keep this one on hold for two more months. I don't see how
that much time can hurt a lot, and I do see how it can help. It's not
like we don't have enough else to keep us all busy in the interim.

∂07-Jun-87  1348	FAHLMAN@C.CS.CMU.EDU 	FUNCTION-TYPE
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87  13:48:13 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 16:47:37-EDT
Date: Sun, 7 Jun 1987  16:47 EDT
Message-ID: <FAHLMAN.12308674344.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: FUNCTION-TYPE
In-reply-to: Msg of 7 Jun 1987  16:17-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


Well, I'll leave it to the others to decide whether it is reasonable to
delay the whole decision process for several months because you haven't
yet decided what your position is.  If several people on the committee
are uneasy about this FUNCTION-TYPE issue because of the points you have
raised (or because of other problems), we should probably wait and
discuss it some more; if it's just you, I don't think you have a veto
either over the proposal itself or over the decision that it's time to
vote on it.  (You may, however, have a legitimate parliamentary
objection if the proposal being voted on has not been on the table for a
sufficient time prior to a vote.)

It's possible that this can be discussed in Boston and settled by a
letter ballot shortly thereafter.  Unlike most of these "garbage"
issues, I think this one is worth some of our precious face-to-face
time.

By the way, I thought I had told people on Cleanup this, but I guess I
just told certain individuals: I will not be able to be at the Boston
meeting.  I had already made plans to be in England when this meeting's
date was settled in Palo Alto.  I'd like to be at the meeting, but I
trust the members of X3J13 not to do anything too horrible in my
absence.

-- Scott

∂07-Jun-87  1603	FAHLMAN@C.CS.CMU.EDU 	FORMAT-OP-C (Version 4)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87  16:02:56 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 19:02:22-EDT
Date: Sun, 7 Jun 1987  19:02 EDT
Message-ID: <FAHLMAN.12308698874.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: FORMAT-OP-C (Version 4)
In-reply-to: Msg of 5 Jun 1987  18:04-EDT from Masinter.pa at Xerox.COM


This version is OK by me except for the last paragraph of the
discussion.  I think you're introducing an entirely new topic in the
offhand comment about READ-CHAR always returning one charater for every
one WRITE-CHAR has written.  This might be worth a clarification of its
own, but it shouldn't be introduced here, especially as a
"clarification", which makes it sound like that interpretation is
obvious to the people who endorse FORMAT-OP-C.

Drop the last paragraph?

-- Scott

∂07-Jun-87  1612	FAHLMAN@C.CS.CMU.EDU 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87  16:12:45 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 19:12:08-EDT
Date: Sun, 7 Jun 1987  19:12 EDT
Message-ID: <FAHLMAN.12308700652.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: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 5)
In-reply-to: Msg of 5 Jun 1987  19:10-EDT from Masinter.pa at Xerox.COM


This looks good to me.

-- Scott

∂07-Jun-87  1622	RPG  	Hole
To:   cl-cleanup@SAIL.STANFORD.EDU    

Actually, I think I wrote things up so that if no one uses &required-key,
everything behaves as before. Possibly there is some definition of
``compatible'' with which I am not familiar such that this behavior is
``very incompatible?''

I suppose if someone wants to not have to remember twenty keywords, they
don't have to use &required-keys.

I ran through the exercise of inventing a new type of object for
names of arguments, but then when I considered the frequency of
this sort of checking and the ways I know type space is divided in
current implementations, it didn't seem worth it.

Of course, if CLOS needs required named arguments for discrimination
(not error signaling) it can be a feature of CLOS lambda-lists
not available in Common Lisp. The syntax of CLOS lambda-lists is an extension
already.

			-rpg+

∂07-Jun-87  1630	FAHLMAN@C.CS.CMU.EDU 	Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87  16:30:29 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 19:29:54-EDT
Date: Sun, 7 Jun 1987  19:29 EDT
Message-ID: <FAHLMAN.12308703889.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 ADJUST-ARRAY-DISPLACEMENT (Version 3)
In-reply-to: Msg of 6 Jun 1987  00:48-EDT from Masinter.pa at Xerox.COM


    Rather than wait for some resolution of Kent's question about the
    omission of the :DISPLACED-TO argument, I took the liberty of guessing
    that adjusting a displaced-to array without setting the :displaced-to
    meant that the result was displaced to the same place. I inserted rule 3
    and renumbered the rules.

The manual is pretty vague in this area, but my reading of
ADJUST-ARRAY (which says that the :DISPLACED-TO argument is the same as
in MAKE-ARRAY) is that if no :DISPLACED-TO argument is supplied, the
resulting array is never displaced, even if it had been originally.
That's what we implemented in Spice Lisp, and that's the interpretation
that seems to be consistent with the rest of this proposal (e.g. the rule
that if :DISPLACED-INDEX-ARG is not supplied, it defaults to zero rather
than the old index).

So I support the earlier version of the proposal, with the added
clarification that if no :DISPLACED-TO argument is supplied in a call to
ADJUST-ARRAY, the resulting array is not displaced, even if the original
array had been displaced.  That is clear, simple, and sufficient in my
view.

It might be argued that a displaced array should remain displaced unless
the user specifically specifies otherwise.  I can imagine some
modularity arguments for such a view, though I don't think they are
compelling.  If someone strongly prefers this interpretation, I wouldn't
object and would even arrange to fix the CMU code so that we can still
say that public-domain code is available.  However, this change will
surprise some people and it should be clearly stated, not hidden in a
parenthetical statement in point 3.  Also, we should probably go over
the whole proposal to make it consistent with this change.

-- Scott

∂07-Jun-87  1632	RPG  	FUNCTION-TYPE 
To:   cl-cleanup@SAIL.STANFORD.EDU    

I'm sorry I used the word ``inconsistency'' when I meant to use the phrase
``multiplicity of rules.'' To new users, an abundance of rules where one
would seem to be necessary is often viewed by such users as either an
inconsistency in design philosphy among the various parts of the language
or an inconsistency in the sanity of the designers of the language.

I rephrase my cynical design rule:

``Changes that introduce or retain a multiplicity of rules where a single
rule will do are preferable to changes that cause old programs to stop
working.''

			-rpg-

∂07-Jun-87  1648	RPG  	FUNCTION-TYPE and EuLisp
To:   cl-cleanup@SAIL.STANFORD.EDU    

I said in a message:

``Our position with respect to EuLisp will be more difficult....''

KMP goes on to argue various positions the EuLisp folks might have. I
suppose a reasonable way to proceed is to set up KMP and some other people
to simulate the EuLisp folks and assume positions they might have, and we
can see how well our arguments might apply to those positions, but what I
meant by my remark is that if we moved as far as the cleanest formulation
of the FUNCTION-TYPE issue, that would be seen as an act of good faith on
our part and would cause the two groups to move much closer together and
to proceed with a common design much more easily.

If, for example, we changed Common Lisp to be a Lisp1 dialect, the groups
would merge. By ``position'' I meant negotiation position. I don't expect
this group to understand the process of negotiating with the EuLisp folks,
so there is no point in arguing the merits here.

			-rpg-

∂07-Jun-87  1753	FAHLMAN@C.CS.CMU.EDU 	AREF-1D (Version 4)    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87  17:53:46 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:53:13-EDT
Date: Sun, 7 Jun 1987  20:53 EDT
Message-ID: <FAHLMAN.12308719055.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: AREF-1D (Version 4)
In-reply-to: Msg of 6 Jun 1987  00:52-EDT from Masinter.pa at Xerox.COM


Looks good to me.

-- Scott

∂07-Jun-87  1755	FAHLMAN@C.CS.CMU.EDU 	Issue: FLET-IMPLICIT-BLOCK (Version 6)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87  17:55:38 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:54:24-EDT
Date: Sun, 7 Jun 1987  20:54 EDT
Message-ID: <FAHLMAN.12308719270.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: FLET-IMPLICIT-BLOCK (Version 6)
In-reply-to: Msg of 6 Jun 1987  00:57-EDT from Masinter.pa at Xerox.COM


Looks good to me.

-- Scott

∂07-Jun-87  1756	FAHLMAN@C.CS.CMU.EDU 	Issue: COMPILER-WARNING-STREAM (Version 6) 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87  17:55:56 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:54:49-EDT
Date: Sun, 7 Jun 1987  20:54 EDT
Message-ID: <FAHLMAN.12308719347.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: COMPILER-WARNING-STREAM (Version 6)
In-reply-to: Msg of 6 Jun 1987  01:37-EDT from Masinter.pa at Xerox.COM


Looks good to me.

-- Scott

∂07-Jun-87  1756	FAHLMAN@C.CS.CMU.EDU 	Issue: DEFVAR-INITIALIZATION (Version 4)   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87  17:56:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:55:26-EDT
Date: Sun, 7 Jun 1987  20:55 EDT
Message-ID: <FAHLMAN.12308719458.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: DEFVAR-INITIALIZATION (Version 4)
In-reply-to: Msg of 6 Jun 1987  01:43-EDT from Masinter.pa at Xerox.COM


Looks good to me.

-- Scott

∂07-Jun-87  1756	FAHLMAN@C.CS.CMU.EDU 	Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 7 Jun 87  17:56:35 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 7 Jun 87 20:56:00-EDT
Date: Sun, 7 Jun 1987  20:55 EDT
Message-ID: <FAHLMAN.12308719561.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: GET-SETF-METHOD-ENVIRONMENT, Version 3
In-reply-to: Msg of 6 Jun 1987  02:27-EDT from Masinter.pa at Xerox.COM


Looks good to me.

-- Scott

∂08-Jun-87  0646	gls@Think.COM 	FORMAT-OP-C (Version 4)  
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 8 Jun 87  06:46:37 PDT
Received: from boethius by Think.COM via CHAOS; Mon, 8 Jun 87 09:48:58 EDT
Date: Mon, 8 Jun 87 09:46 EDT
From: Guy Steele <gls@Think.COM>
Subject: FORMAT-OP-C (Version 4)
To: Masinter.pa@xerox.com, CL-Cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <870605-150551-2556@Xerox>
Message-Id: <870608094647.1.GLS@BOETHIUS.THINK.COM>

I approve of FORMAT-OP-C:WRITE-CHAR, version 4.
Good work, Larry.
--Guy

∂08-Jun-87  0727	gls@Think.COM 	Hole 
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 8 Jun 87  07:27:00 PDT
Received: from boethius by Think.COM via CHAOS; Mon, 8 Jun 87 10:29:36 EDT
Date: Mon, 8 Jun 87 10:27 EDT
From: Guy Steele <gls@Think.COM>
Subject: Hole
To: RPG@sail.stanford.edu, cl-cleanup@sail.stanford.edu
Cc: gls@think.com
In-Reply-To: <8706072326.AA12046@Think.COM>
Message-Id: <870608102731.4.GLS@BOETHIUS.THINK.COM>

It strikes me that the interaction of &optional and &required-key
arguments is dicey at best.  It might be better to allow one or the
other kind of argument but not both in a single lambda-list.

I am also not crazy about the name &required-key; it is too obviously
the result of leaning over backwards to accommodate history.

An aesthetically more pleasing design that deals with both objections
is simply to use the existing keywords &key and &optional, with the
extension that &optional may occur *after* &key if desired.  That is, it
is still true that each of &optional and &key may appear at most once in
an argument list, but they may appear in either order.  Thus &key marks
the transition from by-position to by-name, and &optional marks the
transition from required to optional.  One may then have either of two
patterns:

(defun blah (x y z &optional p q r &key a b c) ...)
	     -----           -----      -----
	       |	       |          |
	       |	       |          optional named
	       |	       optional positional
	       required positional

(defun blee (x y z &key p q r &optional a b c) ...)
	     -----      -----           -----
	       |	  |               |
	       |	  |               optional named
	       |	  required named
	       required positional

Thus required named and optional positional cannot be mixed,
and no new keyword is needed.  The only unfortunate aspect of
this proposal is that it is incompatible with previous practice.
Currently

(defun blaw (x y z &key a b c) ...)

treats a, b, and c as optioal named parameters, whereas this
new proposal would treat them as required.

--Guy

∂08-Jun-87  0802	FAHLMAN@C.CS.CMU.EDU 	Hole    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Jun 87  08:01:57 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 8 Jun 87 11:00:42-EDT
Date: Mon, 8 Jun 1987  11:00 EDT
Message-ID: <FAHLMAN.12308873322.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: Hole
In-reply-to: Msg of 8 Jun 1987  10:27-EDT from Guy Steele <gls at Think.COM>


Well, I was wrong about this being incomaptible, but I still don't see
what problem you two think you are solving, unless an empty box in the
matrix of possible language constructs is considered to be a problem.
Does this make life any better for the user of Common Lisp?

-- Scott

∂08-Jun-87  1128	Masinter.pa@Xerox.COM 	Issue: LOAD-TIME-EVAL (Version 1)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Jun 87  11:28:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JUN 87 11:25:16 PDT
Date: 8 Jun 87 11:21 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: LOAD-TIME-EVAL (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: kempf%hplabsc@hplabs.HP.COM
Message-ID: <870608-112516-4180@Xerox>

This issue was just submitted by Jim Kempf. I made some minor edits to
his submission (e.g. fundef => function definition)  but it is otherwise
as submitted.

My comments:

I think the test case needs to be fixed up so that it can stand alone
(i.e., be a fragment of code that could, for example, become a part of a
diagnostic suite). 

Does this have any justification other than the Common Lisp Object
System? (I think it does, but they aren't mentioned here.) 

Other than that, I think it looks OK. What do you think?

!
Issue:           SHARP-COMMA-SPECIAL-FORM
References: #, (p. 356),  (EVAL-WHEN (LOAD) ...) (p. 69-70)
Category:     ADDITION
Edit history: Version 1 submitted 6/6/87, James Kempf.

Problem description:

The specification of #, (load time evaluation) in Common Lisp does not
provide a means of generating code using macros which can perform load
time evaluation within embedded forms. Load time evaluation at the top
level is possible using (EVAL-WHEN (LOAD) ... ), but there is no way
arrange for a form generated by a macro to be evaluated at load time
because #, is a reader macro and code generated by macros is not
processed by the reader.

Proposal (SHARP-COMMA-SPECIAL-FORM:LOAD-TIME-EVAL):

When interpreted or compiled in memory, LOAD-TIME-EVAL evaluates its
argument immediately. When being compiled as part of a file compilation,
LOAD-TIME-EVAL arranges for its argument to be evaluated when the file
is loaded. LOAD-TIME-EVAL can be used anywhere, and is not restricted to
being a top level form, nor to code being processed by the reader.

Test Case: 

(defmacro call-method (spec &rest args)
	  `(apply
	      (load-time-eval 
		(load-time-look-up-method ,spec))
	      ,args)))

This macro generates code which applies a function which is determined
at load time. It is a summary of some more complex code in the
CommonObjects object-oriented language extension built on the Common
Lisp Object System.

Rationale:

Currently, there is no way to arrange for load time evaluation within
macro generated code. This capability is required for object-oriented
extensions of Common Lisp, since often neither the name nor the function
definition object is known until load time. It is particularly useful
for optimizing calls to superclass methods.

Current practice:

Currently, every version of Common Lisp is required to implement
compiler hooks for #, so the primitives for implementing LOAD-TIME-EVAL
should exist. 

Adoption Cost: 

The cost to implementors should be relatively slight, considering
primitives for implementing #, can be resued. Many implementations of
Common Lisp may have LOAD-TIME-EVAL available as public domain code, if
they done it for Portable Common Loops.

Cost of non-adoption: 

Optimization of CALL-NEXT-METHOD in the Common Lisp Object System will
be implementation dependent, and other languages built on the metaclass
kernel wanting to optimize calls to superclass methods will have no
specified, portable way of doing so.

Benefits: 

Optimization of calls on superclass methods in the Common Lisp Object
System will have a portable hook, which will make transporting code
easier. If the problem is left as it is, each vendor could solve the
problem differently, encouraging nonportable code.

Conversion Cost:

Extremely low. Most users will be completely unaffected.

Esthetics:

The proposal fills a hole in the spectrum of alternatives for achieving
load time evaluation. 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 seems to be little disagreement on this, as far as can be
determined at this date. The Portable Common Loops implementation
encourages vendors to add this, to facilitate calling superclass methods
directly, and there has not been any negative reaction so far. It will
certainly help make the Common Lisp Object System easier to implement,
and easier to extend.

∂08-Jun-87  1240	RPG  	Hole
To:   cl-cleanup@SAIL.STANFORD.EDU    

The only problem that could be solved by filling in this hole is to
give people a way to supply fewer than all of the optional positionals
while supplying some of the named arguments. My suggestion doesn't help
with that much.

As I've mentioned before - but as I know I must mention again - the effect
of this might have some relevance to CLOS in which it might be useful (the
CLOS folks have not yet decided) to discriminate on the names of named 
arguments.

For example, writing this

(defmethod f ((x c1) (y c2) &required-key foo bar) <code1>)
(defmethod f ((x c1) (y c2) &required-key baz ola) <code2>)

is simpler to understand than this

(defmethod f ((x c1) (y c2) 
              &key (foo nil foo-p) (bar nil bar-p) 
	           (baz nil baz-p) (ola nil ola-p))
 (cond ((and foo-p bar-p) <code1>)
       ((and baz-p ola-p) <code2>)))

And when one writes instance initialization code in CLOS, you will be
writing lots of code like this.

			-rpg-

∂08-Jun-87  1342	FAHLMAN@C.CS.CMU.EDU 	Hole    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Jun 87  13:42:14 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 8 Jun 87 16:41:08-EDT
Date: Mon, 8 Jun 1987  16:40 EDT
Message-ID: <FAHLMAN.12308935290.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Cc:   cl-cleanup@SAIL.STANFORD.EDU
Subject: Hole
In-reply-to: Msg of 8 Jun 1987  15:40-EDT from Dick Gabriel <RPG at SAIL.STANFORD.EDU>


    The only problem that could be solved by filling in this hole is to
    give people a way to supply fewer than all of the optional positionals
    while supplying some of the named arguments. My suggestion doesn't help
    with that much.

    As I've mentioned before - but as I know I must mention again - the effect
    of this might have some relevance to CLOS in which it might be useful (the
    CLOS folks have not yet decided) to discriminate on the names of named 
    arguments.

Maybe this suggests that it is time to bite the bullet and let CLOS
methods discriminate on non-required args, keyword or otherwise.  The
last time I heard this discussed, it was more a matter of "we don't want
to think about how to extend the priority rules right now" than "we
can't discriminate on optional args for the following fundamental
reason".  Has that changed?

-- Scott

∂08-Jun-87  2001	FAHLMAN@C.CS.CMU.EDU 	Issue: LOAD-TIME-EVAL (Version 1)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Jun 87  20:01:37 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 8 Jun 87 23:00:16-EDT
Date: Mon, 8 Jun 1987  23:00 EDT
Message-ID: <FAHLMAN.12309004326.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, kempf%hplabsc@HPLABS.HP.COM
Subject: Issue: LOAD-TIME-EVAL (Version 1)
In-reply-to: Msg of 8 Jun 1987  14:21-EDT from Masinter.pa at Xerox.COM


This looks like a good proposal in general, and it is something I would
like to see adopted.  I think that this facility will be used for lots
of things besides CLOS metaclass hackery, and that a less arcane
justification would look better.  I seem to recall people asking for
this long before CommonLoops or CLOS appered on the scene.

I'll see if I can come up with some straightforward and self-contained
example that needs this facility.  The rest of you should do likewise.
If nobody can do better in the next day or two, I think that this
proposal could go out as is -- I don't think anyone will oppose it, even
if it is presented as an arcane hack needed only by CLOS wizards.

-- Scott

∂08-Jun-87  2126	KMP@STONY-BROOK.SCRC.Symbolics.COM 	LOAD-TIME-EVAL
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 8 Jun 87  21:26:11 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 167692; Mon 8-Jun-87 23:37:14 EDT
Date: Mon, 8 Jun 87 23:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: LOAD-TIME-EVAL
To: Fahlman@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12309004326.BABYL@C.CS.CMU.EDU>
Message-ID: <870608233713.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

In Maclisp, the SQUID (Self-Quoting Internal Datum) feature in the compiler
offered this same advantage. It was very useful in my Fortran->Lisp translator,
which needed to do the conceptual analog of relocation at load time. I had
one big array called FORTRAN$MEMORY and programs didn't know until load time
what their private data area's offset in that array would be.

I've run into other examples, too, but maybe this suffices to convince people
that CLOS is not the only potential consumer.

Anyway, I'm conceptually in favor of having this capability though I've not
had time to read the particular proposal in detail yet.

∂09-Jun-87  1732	Masinter.pa@Xerox.COM 	procedural, errors.   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jun 87  17:32:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 87 17:32:08 PDT
Date: 9 Jun 87 17:31 PDT
From: Masinter.pa@Xerox.COM
Subject: procedural, errors.
To: FAHLMAN@C.CS.CMU.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <870609-173208-1834@Xerox>

I spoke with Kent on the telephone yesterday. Briefly:

Kent will present ignore-errors. He can chose whether he wants to report
it out of the cleanup committee, the error committee, or both, but it
will be go out "under separate cover" so that it is at least apparent
that the error committee approves it.

It turns out that I didn't in fact make any unannounced edits to any
proposals. The wording that upset Kent was the inclusion of the phrase
"including NIL" in KEYWORD-ARGUMENT-NAME-PACKAGE, but the wording was
there (exactly) in the version that got voted on. However, when I fixed
up the line breaks, Kent's source compare didn't work. 

So perhaps there weren't any gratuitous and unrecorded changes, although
I admit there were a flurry of hurried ones. In any case, your concerns
have been noted, and I will redouble efforts to avoid any in the future.

I would like to start pipelining proposals out to X3J13, starting with
the ones that have had no discussion for quite a while. The messages to
X3J13 will be careful to say whether the committee voted on the exact
version or some previous one; if there's any doubt, I'll double check
with this mailing list first. 

I expect that mail to X3J13 may generate some discussion, questions,
etc. We may want to be prepared to make slight revisions. 

∂09-Jun-87  1822	Masinter.pa@Xerox.COM 	Issue: FUNCTION-TYPE  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jun 87  18:21:50 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 87 18:21:23 PDT
Date: 9 Jun 87 18:21 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE
To: cl-cleanup@sail.stanford.edu
Message-ID: <870609-182123-1906@Xerox>

Will Clinger mentioned to me at the last X3J13 one important reason for
the stronger interpretation which I hadn't thought of. The issue is
garbage collection of unused functions. The idea is to gc all functions
in the system which aren't called, at the point of building an
application. However, when funcall and friends can automatically coerce
symbols, then any funcall potentially becomes a reference to any
symbol-named function in the environment (without some really hairy and
impossible flow analysis.) If there is no automatic coercion, and there
aren't any explicit symbol-functions, then you can be guaranteed that if
you don't see a call to FOO or a #'FOO somewhere, then FOO isn't
referenced and its definition can be GC'd. 

∂09-Jun-87  1835	KMP@STONY-BROOK.SCRC.Symbolics.COM 	procedural, errors.
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87  18:35:37 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 168880; Tue 9-Jun-87 21:34:53 EDT
Date: Tue, 9 Jun 87 21:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: procedural, errors.
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Masinter.PA@Xerox.COM, Fahlman@C.CS.CMU.EDU,
    KMP@STONY-BROOK.SCRC.Symbolics.COM
References: <870609-173208-1834@Xerox>
Message-ID: <870609213452.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Larry's message accurately sums up the situation, I think.

I gather that some people worried I might be hopelessly irritated at
Larry, so I should say that I'm not. I was just concerned about a bad
situation which might recur and felt I should say something to keep
things in check. Had it not been so late, perhaps I'd have edited my
comments better.

Larry seems committed to making the documents accurately reflect whether
in fact we've seen or voted on or agreed upon a particular draft, and
that's what's important to this situation.

∂09-Jun-87  1838	Pavel.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jun 87  18:36:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 87 18:36:09 PDT
Date: Tue, 9 Jun 87 18:36:04 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE
In-reply-to: <870609-182123-1906@Xerox>
To: Masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Message-ID: <870609-183609-1934@Xerox>

  Date: 9 Jun 87 18:21 PDT
  From: Masinter.pa

  If there is no automatic coercion, and there
  aren't any explicit symbol-functions, then you can be guaranteed that
if
  you don't see a call to FOO or a #'FOO somewhere, then FOO isn't
  referenced and its definition can be GC'd.

One can always use manual coercion, via EVAL, so you'll also have to
outlaw any calls to thatt function in the application.  It starts
seeming like this isn't such a compelling argument.

	Pavel

∂09-Jun-87  2015	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: LOAD-TIME-EVAL (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87  20:14:54 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 168944; Tue 9-Jun-87 23:14:13 EDT
Date: Tue, 9 Jun 87 23:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: kempf%hplabsc@hplabs.HP.COM
In-Reply-To: <870608-112516-4180@Xerox>
Message-ID: <870609231403.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 8 Jun 87 11:21 PDT
    From: Masinter.pa@Xerox.COM
    Proposal (SHARP-COMMA-SPECIAL-FORM:LOAD-TIME-EVAL)

I'm generally in favor of something like this proposal, but there are
several problems with the details.

LOAD-TIME-EVAL is presented as if it did the same thing as sharp-comma,
but they are rather different.  #, must appear inside a quoted constant,
at least in any compiler implementation I am familiar with, whereas
load-time-eval is a form and must not appear inside a quoted constant. 
This is not a fundamental problem, it's just confusing.

The remark "Load time evaluation at the top level is possible using
(EVAL-WHEN (LOAD) ... )" does not make any sense, as what that EVAL-WHEN
special form actually does is to inhibit evaluation when loading a file
into the interpreter; it does not cause something to be evaluated at a
different time.  I think the real lesson to be learned from this little
slip is that "load time evaluation" is a poor way of describing the
feature we are trying to get at here; the feature we really want is
load-time construction of constants.

It's not crystal clear how many times LOAD-TIME-EVAL evaluates its
subform and what is done with the result.  I believe the intention is
that `(foo (load-time-eval (bar))) is roughly like
`(foo (quote ,(bar))), which explains what is done with the result.
I'm not happy with the way I just explained it, but can't think of a
better way.  Can the subform be evaluated more than once in interpreted
code?

There are also four typographical errors in the example, or else I am
even more confused by the way it was explained than I thought.

    (defmacro call-method (spec &rest args)
	      `(apply
		  (load-time-eval 
		    (load-time-look-up-method ,spec))
		  ,args)))
should be
    (defmacro call-method (spec &rest args)
      `(funcall (load-time-eval 
		  (load-time-look-up-method ',spec))
		,@args))

It might be worth discussing the obvious other way of doing this, which
would be a function called by a macro, instead of a special form
included in the expansion of a macro.  I think this would have a closer
analogy to #,; in fact you just write , in your macro's backquote where
you would have written #, when using the reader macro.  The above
example would be written as follows:

    (defmacro call-method (spec &rest args &environment env)
      `(funcall (quote ,(make-load-time-eval
			  `(load-time-look-up-method ',spec)
			  env))
		,@args))

This is more verbose than the special-form way, but it may be clearer
what's going on, since there aren't any special forms.  The environment
is passed to make-load-time-eval because I don't see how else it is
supposed to know whether the form resulting from the macro expansion is
going to be compiled into a file or evaluated right away.  I'm not sure
we really want to adopt the make-load-time-eval approach, but I think
it may be worth discussing.

I also happen not to believe the stated usefulness of this for object
oriented programming, but that's irrelevant except that I might want to
suggest removing that from the proposal.  Certainly we all know that this
type of feature is highly useful.

In conclusion, I support the general idea but cannot support the particular
wording of the current version of the proposal.  When I started writing
this message, I was going to include a complete revision of the proposal,
but I have run out of energy.

∂09-Jun-87  2029	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Hole    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87  20:29:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 168954; Tue 9-Jun-87 23:28:33 EDT
Date: Tue, 9 Jun 87 23:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Hole
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: Dick Gabriel <RPG@SAIL.STANFORD.EDU>, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12308935290.BABYL@C.CS.CMU.EDU>
Message-ID: <870609232830.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 8 Jun 1987  16:40 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    Maybe this suggests that it is time to bite the bullet and let CLOS
    methods discriminate on non-required args, keyword or otherwise.  The
    last time I heard this discussed, it was more a matter of "we don't want
    to think about how to extend the priority rules right now" than "we
    can't discriminate on optional args for the following fundamental
    reason".  Has that changed?

If I remember (I haven't consulted the archives), it wasn't a case of
"we don't want to think about it".  I think we came up with nine
different equally plausible extensions to provide for that case, and
couldn't find any compelling reason to choose one over the others.  I
think it would be better for the CLOS committee to concentrate on
finishing what we have tackled so far, and avoid piling on even more
ambitions.  These things can be added later.

∂09-Jun-87  2113	Moon@STONY-BROOK.SCRC.Symbolics.COM 	A Hole in Common Lisp       
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Jun 87  21:12:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 168977; Wed 10-Jun-87 00:11:34 EDT
Date: Wed, 10 Jun 87 00:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: A Hole in Common Lisp   
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12308458446.BABYL@C.CS.CMU.EDU>
Message-ID: <870610001126.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat, 6 Jun 1987  21:01 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    Even if I wanted to mix positional and named args in a single function,
    I don't like your way of doing it -- it seems treacherous to me.  If the
    value of certain arguments to a function happen to match the named
    arguments, things get interpreted in an unintended and very mysterious
    way.

Exactly.  If an argument can sometimes be a value for a parameter, and
other times be the name of a parameter, it can be very confusing.
Haven't we seen this same suggestion before and rejected it for that
reason?  I can't remember whether "we" was the Common Lisp committee a
few years ago or a bunch of hackers sitting around at MIT a few years
before that.  Anyway, my preference is to tread very cautiously on this.

    I have sometimes thought that if I were designing a lisp-like language
    from scratch, I would leave the question of by-postion or by-name
    arguments to the caller of a function....
    There [would be] two forms of function calling, positional and by-arg-name
    either of which can be used on any function.  They need to be
    syntactically distinguished somehow.  I'll use square brackets to group
    the name/argument pairs in the latter -- this might be a read macro that
    turns into some three-element list with a reserved token in the car.

    (function-name pos-arg-1 pos-arg-2 pos-arg-3 ...)

    (function-name [nameX argX] [nameY argY] ...)

This is very like the way Ada does it.  If we were redesigning Lisp, my
preference would be to do it this way too.  However, I'm sure we'd have
people screaming that we were destroying Lisp by introducing new syntax
and by eliminating the ability to understand keyword arguments in terms
of getf and &rest.  Maybe instead of fixing Lisp to be more like Ada, I
ought to be thinking of fixing Ada to be more like Lisp.

∂09-Jun-87  2336	Masinter.pa@Xerox.COM 	Re: Issue: LOAD-TIME-EVAL, SHARP-COMMA-SPECIAL-FORM (Version 1)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Jun 87  23:36:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JUN 87 23:35:24 PDT
Date: 9 Jun 87 23:35 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: LOAD-TIME-EVAL, SHARP-COMMA-SPECIAL-FORM (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Tue, 9 Jun 87 23:14 EDT
To: cl-cleanup@sail.stanford.edu
cc: kempf%hplabsc@hplabs.HP.COM
Message-ID: <870609-233524-2207@Xerox>

David, I agree with most of your sentiments and encourage you to attempt
a revision. The issue currently has two names, neither of which are
particularly appropriate. One is LOAD-TIME-EVAL, and the other is
SHARP-COMMA-SPECIAL-FORM.  Jim's message called it LOAD-TIME-EVAL. I
changed the proposal name to SHARP-COMMA-SPECIAL-FORM in the theory that
the *issue* was some programmatic way of getting at what sharp-comma did
(even if it isn't the same). 

#, is one of the stickier bits of Common Lisp, since, like compiler-let
and a few others, it opens a distinction between compiled and
interpreted code that is otherwise outside the execution model. For that
reason, this seems like an issue we might have some difficulty with.
- - - - - - - - - - - - - - -

For general interest, I'll pass along the following:  Interlisp has
something like this, in constant, deferredconstant and loadtimeconstant.

(constant x) can be implemented by 

  (defmacro constant (x) `',(eval x)).  

E.g., (constant (char-code #\Space)). Some uses were for those places
where the compiler didn't know enough to do constant folding.
Occasionally it was used for things like (constant (get-date-string))
which would return the date the form was compiled, if at all. Of course,
the interpreted behavior is possibly erratic depending on the mechanism
for macro-expansion caching.


(loadtimeconstant x) 

This is similar to constant, but the compiler recognized it specially,
and emitted a special coding so that the loader would evaluate x at load
time. Since it requires special processing by the loader to detect
(e.g., a special case in the fasl format) it is a "special form". I'm
not sure how one could implement this using only a function like
make-load-time-eval.  (loadtimeconstant (get-date-string)) would return
the date the compiled code was loaded. Interpreted behavior is similar
to constant, i.e., evaluation time is not specified.

(deferredconstant x)

This gets evaluated on first reference. It can be implemented by
self-modifying code, e.g.,

(defmacro deferred-constant (x)
   (let ((var (gentemp)))
    (proclaim (list 'special var))
    `(if (boundp ',var) ,var (setq ,var ,x))))


In Interlisp implementations that didn't provide load-time-constant, it
was permissible to emulate it using  deferred-constant. 



∂10-Jun-87  1212	Pavel.pa@Xerox.COM 	Issue: FORMAT-COMMA-INTERVAL  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Jun 87  12:12:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 87 12:09:45 PDT
Date: Wed, 10 Jun 87 12:09:40 PDT
From: Pavel.pa@Xerox.COM
Subject: Issue: FORMAT-COMMA-INTERVAL
To: CL-Cleanup@SAIL.Stanford.Edu
Message-ID: <870610-120945-2854@Xerox>

Issue: FORMAT-COMMA-INTERVAL
References:  FORMAT integer printing (p. 388-9)
Category:   ADDITION
Edit history: Version 1, Pavel, June 10, 1987

Problem description:  There are times when users would like to print out
numbers with some punctuation between groups of digits.  The "commachar"
argument to the ~D, ~B, ~O, ~X, and ~R FORMAT directives was introduced
to fill that need.  Unfortunately, the interval at which the commachar
should be printed is always every three digits.  This constraint is
annoying when a different interval would be more appropriate.

Proposal (FORMAT-COMMA-INTERVAL:YES): Add a fourth argument to the ~D,
~B, ~X, and ~O FORMAT directives, and a fifth argument to the ~R
directive, to be called the "comma-interval".  This value must be an
integer and defaults to 3.  When the : modifier is given to any of these
directives, the "commachar" is printed between groups of
"comma-interval" digits.

Test Cases: Under the proposal, the following forms return the indicated
values:
	(format nil "~,,' ,4:B" 13) => "1101"
	(format nil "~,,' ,4:B" 17) => "1 0001"
	(format nil "~19,0,' ,4:B" 3333) => "0000 1101 0000 0101"
	(format nil "~3,,,' ,2:R" 17) => "1 22"
	(format nil "~,,'|,2:D" #xFFFF) => "6|55|35"

Rationale: The current specification of FORMAT gives the user control
over almost all of the facets of printing integers.  Only the wired-in
constant for the comma-interval remains, even though there are uses for
varying that number.  For example, in many contexts, it would be
convenient to be able to print out numbers in binary with a space
between each group of four bits.  FORMAT does not currently allow
specification of the commachar printing interval so users needing this
functionality must write it themselves, duplicating much of the logic in
every implementation's integer printing code.  Other uses, requiring
other intervals, can be imagined.  For example, using a "commachar" of
#\Newline and a "comma-interval" of, say, 72, very large bignums could
be printed in such a way as to ensure line-breaks at appropriate places.

Current practice: No released implementations currently support this
feature.

Adoption Cost: The change in the implementation of FORMAT is reasonably
minor and,  in most cases, highly localized.  Usually, the change is as
simple as taking an extra parameter and using it instead of a wired-in
value of 3.

Cost of non-adoption: Users desiring this functionality will have to
write it themselves, duplicating much of the logic involved in printing
integers at all.

Benefits: The last inflexibility in integer printing is eliminated with
a net increase in user-visible functionality.

Conversion Cost: Since the proposal involves the addition of an argument
to certain directives, the change would be entirely upward-compatible.
No user code would need to be converted.

Esthetics: By parameterizing the final piece of wired-in behavior from
integer printing, this small part of the workings of FORMAT would be
perceived as having been cleaned up.

Discussion: Pavel supports this proposal.

∂10-Jun-87  1357	Moon@ELEPHANT-BUTTE.SCRC.Symbolics.COM 	Issue: FORMAT-COMMA-INTERVAL  
Received: from ELEPHANT-BUTTE.SCRC.SYMBOLICS.COM by SAIL.STANFORD.EDU with TCP; 10 Jun 87  13:57:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 183720; Wed 10-Jun-87 16:39:46 EDT
Date: Wed, 10 Jun 87 16:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-COMMA-INTERVAL
To: CL-Cleanup@SAIL.Stanford.Edu
In-Reply-To: <870610-120945-2854@Xerox>
Message-ID: <870610163929.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

This proposal sounds good to me.

∂10-Jun-87  1650	FAHLMAN@C.CS.CMU.EDU 	Issue: FORMAT-COMMA-INTERVAL
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 10 Jun 87  16:49:51 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 10 Jun 87 19:49:05-EDT
Date: Wed, 10 Jun 1987  19:49 EDT
Message-ID: <FAHLMAN.12309493814.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Pavel.pa@XEROX.COM
Cc:   CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: FORMAT-COMMA-INTERVAL
In-reply-to: Msg of 10 Jun 1987  15:09-EDT from Pavel.pa at Xerox.COM


Looks good to me too.

One could quibble about the repeated claim that this is "the last"
inflexibility wired into number printing.  I think this is an
overstatement, but not worth a revision, since it is not an important
part of the justification.

-- Scott

∂10-Jun-87  1906	Pavel.pa@Xerox.COM 	Re: Issue: FORMAT-COMMA-INTERVAL   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 10 Jun 87  19:06:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 JUN 87 18:03:54 PDT
Date: Wed, 10 Jun 87 18:03:40 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: FORMAT-COMMA-INTERVAL
In-reply-to: <FAHLMAN.12309493814.BABYL@C.CS.CMU.EDU>
To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870610-180354-1245@Xerox>

  Date: Wed, 10 Jun 87 19:49 EDT
  From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

  One could quibble about the repeated claim that this is "the last"
  inflexibility wired into number printing.  I think this is an
  overstatement, but not worth a revision, since it is not an important
  part of the justification.

Yeah, I felt a little funny about putting it in there, but I guess my
theatric side got the better of me.  I agree that it's not really worth
a revision.

	Pavel

∂10-Jun-87  2127	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87  21:27:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169942; Wed 10-Jun-87 22:40:50 EDT
Date: Wed, 10 Jun 87 22:40 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ADJUST-ARRAY-DISPLACEMENT (Version 3)
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12308703889.BABYL@C.CS.CMU.EDU>
Message-ID: <870610224048.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sun, 7 Jun 1987  19:29 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>


	Rather than wait for some resolution of Kent's question about the
	omission of the :DISPLACED-TO argument, I took the liberty of guessing
	that adjusting a displaced-to array without setting the :displaced-to
	meant that the result was displaced to the same place. I inserted rule 3
	and renumbered the rules.

    The manual is pretty vague in this area, but my reading of
    ADJUST-ARRAY (which says that the :DISPLACED-TO argument is the same as
    in MAKE-ARRAY) is that if no :DISPLACED-TO argument is supplied, the
    resulting array is never displaced, even if it had been originally.
    That's what we implemented in Spice Lisp, and that's the interpretation
    that seems to be consistent with the rest of this proposal (e.g. the rule
    that if :DISPLACED-INDEX-ARG is not supplied, it defaults to zero rather
    than the old index).

Scott, I think you're right.  Also I think the second paragraph on p.298
can only be interpreted as saying that if you don't specify :DISPLACED-TO,
it doesn't retain the old displacement.

    So I support the earlier version of the proposal, with the added
    clarification that if no :DISPLACED-TO argument is supplied in a call to
    ADJUST-ARRAY, the resulting array is not displaced, even if the original
    array had been displaced.  That is clear, simple, and sufficient in my
    view.

Agreed.

∂10-Jun-87  2129	Moon@STONY-BROOK.SCRC.Symbolics.COM 	FUNCTION-TYPE     
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87  21:29:12 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169946; Wed 10-Jun-87 22:54:29 EDT
Date: Wed, 10 Jun 87 22:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE 
To: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 6 Jun 87 19:30 EDT from Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Message-ID: <870610225426.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 06 Jun 87  1630 PDT
    From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>

    I regard this issue as a put-up-or-shut-up affair. I prefer
    the formulation that states that APPLY and FUNCALL take functions,
    and you have to coerce symbols and lambda-expressions to be functions
    before you can APPLY or FUNCALL them to more lenient formulations.

    If we do not go with this formulation, then I would say an
    important design criterion of the cleanup is:

[updated version of the following quote from a later message substituted
for the original]

    ``Changes that introduce or retain a multiplicity of rules where a single
    rule will do are preferable to changes that cause old programs to stop
    working.''

Perhaps I should just keep my mouth shut, but I think that quite a
plausible case can be made that requiring an explicit coercion before
calling APPLY or FUNCALL would be introducing an extra rule and would be
more confusing to new users than permitting the coercion.  I don't think
there is one "right" position on this issue, I think it is a matter of
taste and style.  I don't think incompatibility with existing programs
is the primary point of resistance on this issue.

I'd really prefer that this matter of taste not hold up agreement on the
important FUNCTION-TYPE proposal.  Can we separate out the coercion of
symbols and lambda expressions by function calling into a separate issue?
Dick, I don't know what you meant by "put-up-or-shut-up"; would treating
this as two separate issues be somehow unacceptable to you?

∂10-Jun-87  2130	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87  21:30:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169947; Wed 10-Jun-87 22:59:21 EDT
Date: Wed, 10 Jun 87 22:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT, Version 3
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870605-232848-2962@Xerox>
Message-ID: <870610225918.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

The adoption cost sentence about some implementations (Symbolics)
already using an optional argument to GET-SETF-METHOD for
something else seems to have disappeared in the latest revision.
I don't care a whole lot, but I don't think we want to cover up
any known adoption costs in proposals.

∂10-Jun-87  2131	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue ADJUST-ARRAY-DISPLACEMENT  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Jun 87  21:31:19 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 169951; Wed 10-Jun-87 23:09:08 EDT
Date: Wed, 10 Jun 87 23:09 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ADJUST-ARRAY-DISPLACEMENT
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12307710848.BABYL@C.CS.CMU.EDU>
Message-ID: <870610230906.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 4 Jun 1987  00:34 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    I support this proposal and have no problem with releasing it as-is,
    except for the form in which Moon's comments are included at the end.
    As it stands, this is one of those proposals that seems to say, "Let's
    do A, but then again we might want to do B."

    Unless Moon wants to push the alternative he raises, we should either
    drop this comment or say something like the following:

    "Moon pointed out that the Symbolics system currently does ..., and that
    this is an equally viable alternative.  However, the committee has
    decided to stick with the proposal as described above."

    If Moon strongly favors the alternative he describes, I could support
    that as well.  I just think we need to pick one or the other.

I don't strongly favor it.  I'm sure it was a case of our implementors doing
the best they could to slash their way through the ambiguities of the Common
Lisp book.  The way Larry dealt with this in version 3 of the proposal is
fine with me.  Note, however, that I cannot support version 3 of the proposal
because of the bug that was introduced in that version (discussed in
separate mail).

∂10-Jun-87  2325	RPG  	Put Up or Shut Up  
To:   cl-cleanup@SAIL.STANFORD.EDU    

I think a user has to put a multiplicity of rules in his mind when he
reads that FUNCALL calls the function..., when it really invokes the
function or coerces a symbol or a list with a LAMBDA CAR (though that
might fail) to a function and calls that. But a user has fewer rules in
mind when he knows that FUNCALL invokes the function and that there is a
standard way to coerce (COERCE).

What I mean by ``put up or shut up'' is very innocent: This is an issue in
which we either choose to make a true cleanup for aesthetic and political
reasons or we choose not to. If we choose the former, I feel we have
ammunition to use to gain a compromise with EuLisp and Scheme - this would
be fine with me. If we choose the latter, I feel we have to keep Common
Lisp away from being a Lisp (unmodified name) standard, and we must make
sure that ISO Lisp is really ISO EuLisp or some such - this would be fine
with me. Y'all get to put up or shut up, and I get to observe the outcome
and begin to act accordingly, assuming someone wishes me to act at all.

From my own standpoint, I prefer the cleaner formulation, but I am
perfectly happy with the one currently stated in the FUNCTION-TYPE
writeup; if either makes it to the floor of X3J13, I will vote for it.

I am happy to treat the important, undisputed part of the FUNCTION-TYPE
proposal as separate from the only-aesthetic, disputed part of the proposal.

			-rpg-

∂11-Jun-87  0958	kempf%hplabsc@hplabs.HP.COM 	Re:  Issue: LOAD-TIME-EVAL (Version 1)   
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87  09:57:17 PDT
Received: from hplabsc by hplabs.HP.COM with TCP ; Thu, 11 Jun 87 09:57:00 pdt
Received: by hplabsc ; Thu, 11 Jun 87 09:55:53 pdt
Date: Thu, 11 Jun 87 09:55:53 pdt
From: Jim Kempf <kempf%hplabsc@hplabs.HP.COM>
Message-Id: <8706111655.AA00196@hplabsc>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
Subject: Re:  Issue: LOAD-TIME-EVAL (Version 1)
Cc: kempf%hplabsc@hplabs.HP.COM

Well, let's see if I can speak to Dave's concerns about the
proposal.

>LOAD-TIME-EVAL is presented as if it did the same thing as sharp-comma,
>but they are rather different.  #, must appear inside a quoted constant,
>at least in any compiler implementation I am familiar with, whereas
>load-time-eval is a form and must not appear inside a quoted constant. 
>This is not a fundamental problem, it's just confusing.

The specification for the semantics of #, is found on pg. 356 of CLtL:

	#,FOO is read as the object resulting from the evaluation
	of the LISP object represented by FOO, which may be the
	printed representation of any LISP object. The
	evaluation is done during the READ process, unless the
	compiler is doing the reading, in which case it is
	arranged that FOO will be evauated when the file
	of compiled code is loaded. The #, syntax performs
	*load-time evaluation* (italics mine) of FOO. By
	contrast, #. (see above) performs a read-time
	evaluation. In a sense, #, is like specifying
	(EVAL LOAD) to EVAL-WHEN, whereas #. is more like
	specifying (EVAL COMPILE). It makes no difference
	when loading interpreted code; when code is to be
	compiled, however, #. specifies compile-time
	evaluation and #, specifies load time evaluation.

Since this description says nothing about having #, be inside quoted
code for the compiler, I guess I don't quite understand the confusion,
or, perhaps, am confused myself about how this fits with the model of #,.
I would agree, however, with the statement that LOAD-TIME-EVAL and
#, are different in that LOAD-TIME-EVAL is a form.

>The remark "Load time evaluation at the top level is possible using
>(EVAL-WHEN (LOAD) ... )" does not make any sense, as what that EVAL-WHEN
>special form actually does is to inhibit evaluation when loading a file
>into the interpreter; it does not cause something to be evaluated at a
>different time.  I think the real lesson to be learned from this little
>slip is that "load time evaluation" is a poor way of describing the
>feature we are trying to get at here; the feature we really want is
>load-time construction of constants.

I agree that a better description of the feature may be load-time
construction of constants; however, in phrasing the proposal, I
was trying to be consistent with CLtL's description of (EVAL-WHEN (LOAD) ...)
specifically (CLtL, pg. 69):

	LOAD specifies that the compiler should arrange to evaluate
	the forms in the body when the compiled file containing the
	EVAL-WHEN form is loaded.

The rest of this section describes Common Lisp's processing model,
into which I was trying to fit this addition.


>It's not crystal clear how many times LOAD-TIME-EVAL evaluates its
>subform and what is done with the result.  I believe the intention is
>that `(foo (load-time-eval (bar))) is roughly like
>`(foo (quote ,(bar))), which explains what is done with the result.
>I'm not happy with the way I just explained it, but can't think of a
>better way.  Can the subform be evaluated more than once in interpreted
>code?

The subform should be evaluated once and only once (i.e. never
not evaluated and never evaluated more than once) in interpreted
code.

>It might be worth discussing the obvious other way of doing this, which
>would be a function called by a macro, instead of a special form
>included in the expansion of a macro.  I think this would have a closer
>analogy to #,; in fact you just write , in your macro's backquote where
>you would have written #, when using the reader macro.  The above
>example would be written as follows:
>
>    (defmacro call-method (spec &rest args &environment env)
>      `(funcall (quote ,(make-load-time-eval
>			  `(load-time-look-up-method ',spec)
>			  env))
>		,@args))
>
>This is more verbose than the special-form way, but it may be clearer
>what's going on, since there aren't any special forms.  The environment
>is passed to make-load-time-eval because I don't see how else it is
>supposed to know whether the form resulting from the macro expansion is
>going to be compiled into a file or evaluated right away.  I'm not sure
>we really want to adopt the make-load-time-eval approach, but I think
>it may be worth discussing.

This would also be acceptable, though, as Dave noted, MAKE-LOAD-TIME-EVAL
would require some way of determining whether the form resulting from
the macro expansion will be compiled or evaluated right away. Since
environments are underspecified in CLtL, this information might not
be obtainable from the environment (though it probably would from special
variables or flags associated with the compiler, in an implementation
dependent way).


>I also happen not to believe the stated usefulness of this for object
>oriented programming, but that's irrelevant except that I might want to
>suggest removing that from the proposal.  Certainly we all know that this
>type of feature is highly useful.

The usefulness comes primarily in constructing optimizations removing
method lookup. There are a number of areas where this might be handy,
including direct invocation of less specific methods, declaration of
identifer names and generic function names so particular methods
rather than their generic functions are invoked, etc. To an extent,
these can be viewed as implementation and machine specific (conventional
architecture implementations would probably benefit more), or, more
precisely, implementation and machine optional. However, as pointed
out, the type of feature which the proposal was trying to get at
could be more generally useful.


>In conclusion, I support the general idea but cannot support the particular
>wording of the current version of the proposal.  When I started writing
>this message, I was going to include a complete revision of the proposal,
>but I have run out of energy.

If general feeling seems to indicate, I can reword the proposal along
the lines of MAKE-LOAD-TIME-EVAL, or clean up the existing proposal.
One additional problem with the existing proposal is the need and
desire to avoid introducing additional special forms into Common Lisp.

Any other comments?
			jak

∂11-Jun-87  1619	Masinter.pa@Xerox.COM 	Re: Issue ADJUST-ARRAY-DISPLACEMENT  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87  16:19:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 12:47:34 PDT
Date: 11 Jun 87 12:47 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue ADJUST-ARRAY-DISPLACEMENT
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 10 Jun 87 23:09 EDT
In-reply-to:  "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of
 Sun, 7 Jun 87 19:29 EDT
To: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <870611-124734-1571@Xerox>

I intend to revise and recirculate this issue before mailing to X3J13
(unless someone else volunteers to do the revision first.) 

Does anyone object to specifying that ADJUST-ARRAY, if no :DISPLACED-TO
argument is given, will always result in a non-displaced array, even if
the array was displaced before?




∂11-Jun-87  1621	Masinter.pa@Xerox.COM 	Re: Issue: FORMAT-COMMA-INTERVAL
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87  16:21:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 13:44:03 PDT
Date: 11 Jun 87 13:42 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FORMAT-COMMA-INTERVAL
In-reply-to: Pavel.pa's message of Wed, 10 Jun 87 18:03:40 PDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870611-134403-1660@Xerox>

If there are no objections, I propose releasing FORMAT-COMMA-INTERVAL to
X3J13, changing "the last" to "one of the last".   I'll hold off on this
one until Monday.


∂11-Jun-87  1623	Masinter.pa@Xerox.COM 	Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87  16:22:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:01:24 PDT
Date: 11 Jun 87 15:00 PDT
From: Masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6)
cc: Masinter.pa@Xerox.COM
Message-ID: <870611-150124-1787@Xerox>

Since the "including NIL" was inflammatory, and the proposal reads
nicely and unambiguously without it, I removed it from the Proposal. I
moved the "the cleanup committee generally supports" to the beginning of
the discussion rather than the end, to make sure that it is clear that
it refers to the proposal rather than some sentence of the discussion. I
changed "The cleanup committee considered, but rejected, a proposal to
exclude NIL ..."  to say "but did not adopt".

I intend to mail this to x3j13 on Monday unless I hear objections.


!
Issue:        KEYWORD-ARGUMENT-NAME-PACKAGE
References:   Lambda Expressions (CLtL pp60-64)
Category:     CLARIFICATION/CHANGE
Edit history: 20-Apr-87, Version 1 by Moon
	         29-Apr-87, Version 2 by Pitman
              11-May-87, Version 3 by Moon
              29-May-87, Version 4 by Masinter 
               5-Jun-87, Version 5 by Masinter
              11-Jun-87, Version 6 by Masinter

Problem Description:

CLtL says that only keyword symbols can be used as non-positional
argument names in &key parameter specifiers.

As Common Lisp is currently defined, if someone wants to define a
function that accepts named (rather than positional) arguments whose
names are symbols in packages other than the KEYWORD package, they
cannot use &KEY. Instead, they have to duplicate the &KEY mechanism
using &REST, GETF, and (if they want error checking of argument names)
DO.  

Some applications (including the draft proposal for the Common Lisp
Object System (CLOS)) require this capability. [See Rationale below.]

Proposal (KEYWORD-ARGUMENT-NAME-PACKAGE:ANY)

Remove restrictions on the package of non-positional argument names;
allow any symbol. That is: 

If, following an &KEY, a variable appears alone or in a (variable
default-value) pair, the behavior specified in CLtL is unchanged: a
keyword-symbol with the same print name as the variable is created and
is used as the keyword-indicator in function calls.  The only way to get
a non-positional-argument-name that is not a keyword symbol is to use
the (indicator variable) syntax in the function's lambda list.  The
keyword-indicator can be any symbol, not just a keyword.

Test case:

(DEFUN RESULT (&KEY ((SECRET-KEYWORD SECRET) NIL) AMOUNT)
    (FORMAT NIL "You ~A $~D" (if SECRET "win" "lose") AMOUNT))

(RESULT :AMOUNT 100) => "You lose $100"
(RESULT :AMOUNT 100 'SECRET-KEYWORD T) => "You win $100"


Rationale:

The "rationale" box on p.62 of CLtL is an argument in favor of requiring
non-positional argument names to be symbols, and not allowing numbers,
but does not speak to the issue of whether or not those symbols should
be further restricted to be keywords.

The desire for non-positional arguments whose names are not keyword
symbols arises when the set of non-positional arguments accepted by a
function is the union of the sets of non-positional arguments accepted
by several other functions, rather than being enumerated in a single
place.  In this case,
it becomes desirable to use packages to prevent accidental name clashes
among non-positional argument names of different functions.

One example of a Common Lisp application that requires this capability
is the draft proposal for an object-oriented programming standard
(CLOS).  It will have generic functions that accept non-positional
arguments and pass them on to one or more applicable methods, with each
method defining its own set of arguments that it is interested in.  If
this proposal is not adopted, either the non-positional argument names
will be required to be keywords, which will require the methods to have
non-modular knowledge of each other in order to avoid name clashes, or
the methods will have to be defined with an ad hoc mechanism that
duplicates the essential functionality of &key but removes the
restriction.

A second example of a Common Lisp application that requires this
capability is private communication channels between functions.  Suppose
a public routine MAKE-FOO needs to accept arbitrary keywords from the
caller and passes those keywords along to an internal routine using
keywords of its own.
 (IN-PACKAGE 'FOOLAND)
 (DEFUN MAKE-FOO (&REST KEYWORD-VALUE-PAIRS &KEY &ALLOW-OTHER-KEYS)
   (APPLY #'MAKE-FOO-INTERNAL 'EXPLICIT T KEYWORD-VALUE-PAIRS))

This could be done without fear that the use of EXPLICIT T would
override some keyword in keyword-value-pairs, since the only way that
could happen is if someone had done (MAKE-FOO 'FOOLAND::EXPLICIT NIL),
or if the user was programming explicitly in the FOOLAND package, either
of which is an implicit admission of willingness to violate FOOLAND's
modularity.

Documentation Impact:

The following outlines the changes that would have to be made to Common
Lisp: the Language if this proposal were adopted, to aid in
understanding the impact of the proposal.

The wording which refers to non-positional arguments as being introduced
by keyword symbols wuuld change to simply refer to those arguments being
introduced by symbols. For example, in the middle of p.60, the sentence:
   ... each -keyword- must be a keyword symbol, such as :start.
 would become
   ... each -keyword- must be a symbol.

The word "keyword" in the first complete sentence on p.62 would be
changed to "symbol" for similar reasons.

Extra wording would have to be added on p.60 to explain that by
convention keyword symbols are normally used as non-positional argument
names, and that all functions built into the Common Lisp language follow
that convention.

Examples would be useful. On p.64 the following examples might be added:

    ((lambda (a b &key ((:sea c)) d) (list a b c d)) 1 2 :sea 6)
    => (1 2 6 NIL)

    ((lambda (a b &key ((c c)) d) (list a b c d)) 1 2 'c 6)
    => (1 2 6 NIL)

Current Practice:

We do not currently know of an implementation that enforces the
restriction that this proposal seeks to remove.

Some implementations have bugs that prevent NIL from working as a
keyword argument name, but allow all non-NIL symbols. (One Symbolics
version that was checked had this bug.)

Adoption Cost:

Some implementors might have to rearrange their error checking slightly,
but it should be very easy.

Benefits:

This will help with the object-oriented programming standard, among
other things.

Conversion Cost:

None--no existing programs will stop working.  

Aesthetics:

The restriction of &key to only keyword symbols is arbitrary and
unnecessary.

There will probably be an argument about whether the restriction is more
esthetic or less esthetic than the freedom, but in either case the
aesthetic effect is slight.

In any case, users who do not want to use the extended functionality can
generally avoid it.

Discussion:

The cleanup committee generally supports this extension. 

Moon was under the impression that this proposal was actually adopted
around December 1985 (although no formal mechanism for adopting
proposals existed at that time), but isn't 100% sure.

If Common Lisp truly has a restriction that only keyword symbols can be
used as keyword names in calls to functions that take keyword arguments,
it will be more difficult to come up with an object-oriented programming
standard that fits within Common Lisp.

The cleanup committee considered, but did not adopt, a proposal to
exclude NIL as a legal indicator. It might catch some errors, but is
otherwise an odd restriction.

∂11-Jun-87  1623	Masinter.pa@Xerox.COM 	Re: IF-BODY (Version 5)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87  16:22:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 14:44:56 PDT
Date: 11 Jun 87 14:43 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: IF-BODY (Version 5)
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Sat,
 2 May 87 14:43 EDT
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870611-144456-1759@Xerox>

I am having difficulty releasing IF-BODY, because of its length and
form. I think it is an embarassment and will cause an uproar if
presented in its present form.

I wouldn't mind a proposal that contained all of the words and
discussions of this one, but in the discussion section. I think most of
the other issues can be summarized succinctly and fairly.

While I hate to do this (and possibly it is a mistake) I am going to
attempt to do the surgery to put Version 5 in a releasable form
(although we are all sick of it). You'll probably hate me for it, but
I'd rather not foist it in its current form on the community.


∂11-Jun-87  1726	KMP@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY-DISPLACEMENT    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 11 Jun 87  17:26:31 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 170782; Thu 11-Jun-87 20:17:58 EDT
Date: Thu, 11 Jun 87 20:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-DISPLACEMENT
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870611-124734-1571@Xerox>
Message-ID: <870611201753.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Unless there's a compelling reason not to, I think it's important to always
make ``keyword NIL'' mean the same as not having supplied the keyword. There's
only a few cases where we violate this and if anything we should be working
on reducing the number of cases.

I think :DISPLACED-TO NIL should copy into a new area and give back a 
non-displaced array, so I agree that this should be the behavior in the
case of omitting :DISPLACED-TO.

Since we're guaranteeing that levels of array displacement will never
be optimized out, it would seem to me reasonable to provide functions
to ask an array whether it is displaced, and if so to what at what index.
Perhaps:

ARRAY-DISPLACED-TO array				[Function]
 Returns the array to which the argument <array> is displaced, or
 NIL if the argument <array> is not displaced.

ARRAY-DISPLACED-INDEX-OFFSET array			[Function]
 Returns the displaced-index-offset of the argument <array>, or
 NIL if the argument <array> is not displaced. (If <array> has been
 displaced to another array, but no displaced-index-offset was specified,
 this function returns 0.)

Example:
 (ADJUST-ARRAY THE-ARRAY THE-NEW-DIMENSIONS
   :DISPLACED-TO (ARRAY-DISPLACED-TO THE-ARRAY)
   :DISPLACED-INDEX-OFFSET (ARRAY-DISPLACED-INDEX-OFFSET THE-ARRAY))

These operations might also be of use to certain people wanting to write
highly optimized array manipulation code that wanted to accept arguments
which might be displaced arrays, but which didn't want to have to incur the
displacement overhead internally.

∂11-Jun-87  1842	Masinter.pa@Xerox.COM 	Status 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87  18:42:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 16:05:20 PDT
Date: 11 Jun 87 16:05 PDT
From: Masinter.pa@Xerox.COM
Subject: Status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870611-160520-187@Xerox>

Please pay special attention to the issues marked *.  I believe these
are the ones where last-minute wording changes might have invalidated
consensus. I hope I was adequately cautious in my mailing to X3J13.

I am going to be on vacation starting next Wednesday until right before
the X3J13 meeting.

David Moon has kindly offered this group a meeting room at Symbolics on
Monday. I suggest we start at 10:00, with a break for lunch, and plan on
ending around 4:00 PM.  

We have a request from Skona Brittain (an X3J13 member from
Microcomputer Systems Consultants in Santa Barbara) to join the cleanup
committee. Unfortunately, she does not have mail access. While it seems
unlikely that anyone not on the net could usefully participate, I am
reluctant to turn down enthusiastic volunteers.


! 

In this file: EB = Benson, GLS = Guy Steele,
PC = Pavel Curtis, KMP = Kent Pitman,  SEF = Scott Fahlman,
LMM= Larry Masinter 

[name/initials] position => person had position on ballot.
[all] position => everyone who voted on this issue voted this way
position on ballot.

Withdraw = "Place on hold pending resolution of comments already
received."

! released
* nearly ready for release

! Proposal format (Version 11)
	Released 11-Jun-87 13:07:17

 * ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
	(Standardize interaction of adjust-array and displacement)
	Comments & edits after ballot.
	Not ready for release

ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
	(Extend adjust-array so its OK on non-adjustable arrays.)
	comments from Moon, JonL, SEF against current form
	[EB, PC, SEF] Withdraw
	Not ready for release

! AREF-1D (Version 5)
	(Add a new function for accessing arrays with row-major-index)
	[all] Version 2 with name => ROW-MAJOR-AREF
	Version 5 released 11-Jun-87 13:07:50
	

* ASSOC-RASSOC-IF-KEY (Version 1/22-Apr-87)
	(Extend ASSOC-IF, etc.  to allow :KEY)
	[EB, GLS, KMP] Release as is
	[LMM] ASSOC-IF has CAR for KEY?
	Reply?

COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
	Questions on interaction with condition proposal.
	Is this an environment issue?
	Not released.

! COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
	(Compiler warnings are printed on *ERROR-OUTPUT*)
	(Version 4, submittted by SEF was withdrawn --
	consider DRIBBLE as a separate issue) 
	Version 3 released.
	Version 6 released 11-Jun-87 13:15:29

! DEFVAR-INITIALIZATION (Version 4)
	((DEFVAR var) doesn't initialize)
	Version 3 Released
	Version 4 released 11-Jun-87 13:30:32

! DEFVAR-INIT-TIME (Version 2/29-May-87)
	(DEFVAR initializes when evaluated, not later.)
	Version 2 released 11-Jun-87 13:30:22
	
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
	(can DO-SYMBOLS see the same symbol twice?)
	[EB, GK] DO-SYMBOLS:ALLOWED
	[PC, Moon, LMM] something like :ADD-KEYWORD
	not ready for release
	
ENVIRONMENT-ARGUMENTS (Version 1)
	Separated into other proposals.
	Withdrawn.

FILE-WRITE-DATE-IF-NOT-EXISTS 
	(What does FILE-WRITE-DATE do if no such file?)
	Not yet submitted.

! FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
	(do FLETs have implicit named blocks around them?)
	Released 11-Jun-87 13:36:10

! FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
	Version 3 released.
	Version 4 released 11-Jun-87 13:44:27.

* FORMAT-COMMA-INTERVAL (Version 1/10 June)
	Ready for release?

FORMAT-NEGATIVE-PARAMETERS
	Not yet submitted; mail 19-May by KMP

! FORMAT-OP-C (Version 5/ 11-Jun-87 14:00:19)
	(What does ~C do?)
	Release to X3J13

FUNCTION-TYPE (Version 4/ 29-May-87)
	(Change definition of FUNCTIONP, function type ...)
	 [EB, GLS, PC] Release as is [GK] Stronger [Moon] OK after comments
	addressed 
	[KMP] break in two, so I could
       support the half I like and only grump about the parts I don't
	want stronger warning
	[SEF] 2-option, 3-option version
	Not ready for release

GC-MESSAGES (version 1)
	(Control over unsolicited GC messages in typescript)
	Submitted by Pitman 23-Apr-87
	In discussion: merge with other controls for
	unsolicited messages?


! GET-SETF-METHOD-ENVIRONMENT (Version 4, 11-Jun-87)
	(Environment argument for GET-SETF-METHOD)
	[EB, GLS, PC, Moon, SEF] Release as is 
	[GK] Ballot says comments follow, but no comments?
	[KMP] NIL as null lexical environment
	Released 11-Jun-87 14:18


* IF-BODY (Version 5, 29 Apr 87)
	(extend IF to implicit progn if more than one ELSE form?)
	General agreement to recommend against.
	While EB, PC, Moon voted to wait for a version that KMP and SEF
		agreed was fair, SEF said 5 was fair enough.
	LMM will reformat

IGNORE-ERRORS (Version 4, 29-May-87)
	[EB, LMM, PC, Moon] Wait for error proposal
	[GLS, KMP, SEF] Release as is (but remove "Larry wonders ...") 
	KMP will release as report from cleanup + error committee

! IMPORT-SETF-SYMBOL-PACKAGE (Version 4/ 29-May-87)
	Version 3 Released
	Version 5 released 11-Jun-87 14:48:33

* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun)
	[EB, GLS, PC, Moon] Release as is (some typos) [SEF] Comments
	Ready for release?

LOAD-TIME-EVAL (Version 1, 6 Jun 87)
	Moon may rewrite? (Please)
	Not ready for release

MACRO-FUNCTION-ENVIRONMENT 
	Not yet submitted (From ENVIRONMENT-ARGUMENTS)

! PATHNAME-STREAM (Version 2)
	[EB, GK, PC, Moon, SEF] Release as is
	Released 11-Jun-87 15:03:54

PATHNAME-SYMBOL (Version 2)
	[GLS, PC, Moon, KMP, SEF] Release as is
	[eb] against, want minority view (needs formatting)
	Moon " cover every argument that is called pathname,
         filename, file, or new-name
         and leave the rest of the ambiguities for another proposal?"
	Not ready for release

PEEK-CHAR-READ-CHAR-ECHO (Version 1)
	Agreed to be controversial
	[EB, GLS, PC, KMP] Withdraw from consideration, await new proposal
	Not ready for release

! PRINC-CHARACTER (Version 3)
	Released 11-Jun-87 15:35:59

PROCLAIM-LEXICAL  (Version 1)
	In discussion
	Some progress
	Need volunteer to merge comments into new version
	Not ready for release

PROMPT-FOR (Version 1)
	Agreed to be controversial
	[EB, PC, Moon, SEF] Withdraw
	Not ready for release


PUSH-EVALUATION-ORDER
	(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
	[PC, SEF] (PUSH FIRST SECOND)
	Not yet submitted. 

REQUIRED-KEYWORD-ARGUMENTS
	("A hole in Common Lisp: RPG/....")
	Not yet submitted

REMF-DESTURCTION-UNSPECIFIED (Version 1)
	Submitted by DLA
	Discussion?
	Not ready for release.

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
	(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
	Version 2 by KMP 28 Apr 87 
	In discussion, no clear consensus
	[EB] Unchanged [PC, KMP, SEF] Undecided
	Not ready for release

SHARPSIGN-BACKSLASH-BITS
	(What does C-META-H-X mean?)
	Mild for this proposal, but preference for
	removing FONT and BITS attribute 
	 [EB] Release as is
          [pc, KMP] no, remove bits & font
             want fuller character proposal
          not ready for release

SHARPSIGN-PLUS-MINUS-NUMBER
	Discussed, without general agreement.
	[RPG against, GLS for, SEF reluctant, etc.]
         not ready for release


SHARPSIGN-PLUS-MINUS-PACKAGE
	Seems like general agreement for :KEYWORD.
	Need to remove other options from proposal
         not ready for release


SPECIAL-FORM-SHADOW
	Is it OK to shadow a special form with FLET, LABELS?
	Not yet submitted
	(From ENVIRONMENT-ARGUMENTS)

TAILP-NIL
	Not yet submitted.
	Needs volunteer to format.
	Notes from Moon

UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
	In discussion
	Need volunteer to summarize issues

∂11-Jun-87  1842	Masinter.pa@Xerox.COM 	Re: SHARPSIGN-PLUS-MINUS-NUMBER, -PACKAGE 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87  18:42:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 15:45:14 PDT
Date: 11 Jun 87 15:43 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: SHARPSIGN-PLUS-MINUS-NUMBER, -PACKAGE
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870611-154514-183@Xerox>

At an earlier meeting, there was some discussion over registering the
list of "public" features and "system" packages so that different
implementations would not step over each other in their use of them.
(For example, Xerox uses XCL:, as did one of the X-in-Common-Lisp
modules. User code that explicitly referenced XCL:DRAW would have to be
edited explicitly.)

This seems actually to get more at the heart of the matter than the
current proposals for #+- and the like. 

Perhaps we could discuss this at our meeting?


∂11-Jun-87  1846	Masinter.pa@Xerox.COM 	Issue: FUNCTION-TYPE  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 11 Jun 87  18:46:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JUN 87 16:49:30 PDT
Date: 11 Jun 87 16:49 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE  
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 10 Jun 87
 23:25 PDT
To: RPG@SAIL.STANFORD.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870611-164930-206@Xerox>

I missed this message, sorry.

I think we have agreement to release the form of FUNCTION-TYPE which
allows implicit coercion in FUNCALL and APPLY.  Can someone produce a
new version of the proposal? It would be good if we could release it by
X3J13.

Richard, I think that your position about the EULisp community is
unnecessarily extreme, but I will address that in a separate message.

∂11-Jun-87  2045	edsel!bhopal!jonl@navajo.stanford.edu 	AREF-1D (Version 2)  
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 11 Jun 87  20:45:45 PDT
Received: by navajo.stanford.edu; Thu, 11 Jun 87 20:42:32 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA26428; Thu, 11 Jun 87 18:26:44 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA14620; Thu, 11 Jun 87 18:28:39 PDT
Date: Thu, 11 Jun 87 18:28:39 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706120128.AA14620@bhopal.edsel.uucp>
To: navajo!KMP%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL@navajo.stanford.edu
In-Reply-To: Kent M Pitman's message of Tue, 2 Jun 87 01:22 EDT <870602012209.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: AREF-1D (Version 2)


Your note of 2-Jun says that I "supported" the ammended version.  I don't
remember voting any issue, or even particularly arguing for one point of
view or the other.  The relevant comment from me was merely that GLS's
"clarifications" of 6-Dec-86 used ROW-MAJOR-AREF for the same thing your
proposal was using AREF-1D for, and that Lucid had already implemented it
under the 6-Dec-86 name.  Wouldn't it be better to mention the 6-Dec-86
"Clarifications" rather than deduce my (non-voting) support?

-- JonL --

∂11-Jun-87  2121	FAHLMAN@C.CS.CMU.EDU 	Status  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 11 Jun 87  21:21:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 12 Jun 87 00:21:02-EDT
Date: Fri, 12 Jun 1987  00:20 EDT
Message-ID: <FAHLMAN.12309805464.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: Status
In-reply-to: Msg of 11 Jun 1987  19:05-EDT from Masinter.pa at Xerox.COM


With regard to the request from Skona Brittain, I think we should see
what can be done to get her arpanet access via dialup to some nearby
machine.  However, as long as she is not able to receive and send
netmail, I don't think she should be considered part of this committee.
It means that someone would have to take the responsibility for sending
this stuff out in hardcopy, and it means that we would have to wait
around for arbitrarily long periods waiting for her input and votes.  I
don't think we can even invite her to the face-to-face meetings -- she
would be missing too much context.

She is of course welcome to submit issues and to participate in the
final votes -- all X3J13 members get to do that.

-- Scott

∂12-Jun-87  0939	Masinter.pa@Xerox.COM 	Re: Hm      
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Jun 87  09:39:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUN 87 09:38:06 PDT
Date: 12 Jun 87 09:37 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Hm  
In-reply-to: Dick Gabriel <RPG@SAIL.STANFORD.EDU>'s message of 12 Jun 87
 01:32 PDT
To: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
to: RPG@SAIL.STANFORD.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <870612-093806-1562@Xerox>


 JonL: regarding your support of ROW-MAJOR-AREF, I interpreted your
wording "Since CLtL already specified ARRAY-ROW-MAJOR-INDEX, this
addition seemed  very natural and `called for'. So Lucid Common Lisp has
had it available since shortly thereafter. " to be support.

If you don't intend to support this proposal and want to raise some
objection to it, I can send out an amended version of the proposal with
your objections contained in it.



Richard (and others): 

In the status report, the initials [rpg], [jonl] etc. were only my
summary of the ballots, e.g., if you answered the mail with
***BALLOT***.   They don't reflect any additional comments or positions
in separate mail. 

∂12-Jun-87  1040	Masinter.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Jun 87  10:40:44 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUN 87 10:24:45 PDT
Date: 12 Jun 87 10:24 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE  
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870612-102445-1632@Xerox>

My idea with FUNCTION-TYPE is to bring out a proposal which includes the
automatic coercion of symbols to functions, puts forward the removal of
the coercion in the discussion section (as possibly a new proposal) and
for this to be a discussion item at X3J13. It will be hard for it to be
a discussion item if it doesn't go out in the mail. The discussion
section of the proposal should say something like "The cleanup committee
generally supports this proposal, as far as it goes. Some members of the
committee feel strongly that it does not go far enough. We believe this
is an issue which deserves wider discussion in the community, since it
affects the position of X3J13 and Common Lisp with respect to the EuLisp
community."

Is that OK?

I'm trying hard to keep the administration of this uncolored by my own
opinion on the issues. 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Here's my opinion on the issue:


I promised a message on the issue of compatibility and our negotiating
position with EuLisp and ISO. I am finding it very difficult to compose.

The X3J13 statement clearly includes as one of the options we are able
to take is to propose a layered implementation strategy, i.e., that
there are simpler subsets of Common Lisp, full Common Lisp, and
supersets of full Common Lisp.

I believe that our current goal is to properly remove the ambiguities in
full Common Lisp and, where warrented, consider minor enhancements.

When dealing with subsets and supersets, I think that we also have
additional goals, that the layers properly nest (programs in a subset
will run in a superset), that it be possible (either by static analysis
or runtime) to tell whether a program in a superset would run in a
subset, etc.

I believe the proper position with regard to EuLisp and ISO's desire for
a simpler language as a standard is for it to be a subset. 

In the case of the FUNCTION-TYPE issue, it is critical that the FUNCTION
type be well specified in full Common Lisp, if it is a first-class type
in any subset. Otherwise, programs which depended on a clean dynamicly
accurate FUNCTIONP would not run in (arbitrary) full Common Lisp
implementations.

However, there is no need to remove the automatic coercion of symbols
and LAMBDA expressions in FUNCALL, APPLY and friends. It is certainly
possible to have a subset which does not include coercions which the
full language provides.

With regard to simplicity and coercions, the automatic coercion of
symbols and lambda expressions to their designated functions is not a
lot more complex than the coercion of (symbols?) and strings to
pathnames, or possibly even integers to complex floats.

∂12-Jun-87  1906	FAHLMAN@C.CS.CMU.EDU 	Issue: FUNCTION-TYPE   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 12 Jun 87  19:06:50 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 12 Jun 87 21:36:21-EDT
Date: Fri, 12 Jun 1987  20:12 EDT
Message-ID: <FAHLMAN.12310022293.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: FUNCTION-TYPE  
In-reply-to: Msg of 12 Jun 1987  13:24-EDT from Masinter.pa at Xerox.COM


I think that if we agree to settle on the coercing version of this
proposal now and to discuss the more radical version later, we almost
guarantee that the radical version will not be seriously considered in
our lifetimes.  We will have established a new status quo that is
tolerable, more or less, and it will be very hard to move away from that
to something better (if we decide it is indeed better).

I think that it would be best to present both plans to X3J13 and to
discuss the merits of each at the meeting, and then if the coercing
version is the best we can do, so be it; we shouldn't kid ourselves that
a more radical cleanup of this issue will be considered later.

-- Scott

∂12-Jun-87  1943	edsel!bhopal!jonl@navajo.stanford.edu 	ADJUST-ARRAY-DISPLACEMENT 
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 12 Jun 87  19:43:11 PDT
Received: by navajo.stanford.edu; Fri, 12 Jun 87 19:40:39 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA01678; Fri, 12 Jun 87 17:25:25 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA01339; Fri, 12 Jun 87 17:27:22 PDT
Date: Fri, 12 Jun 87 17:27:22 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706130027.AA01339@bhopal.edsel.uucp>
To: navajo!KMP%STONY-BROOK.SCRC.Symbolics.COM@navajo.stanford.edu
Cc: navajo!CL-Cleanup%SAIL.STANFORD.EDU@navajo.stanford.edu
In-Reply-To: Kent M Pitman's message of Thu, 11 Jun 87 20:17 EDT <870611201753.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-DISPLACEMENT

You suggest adding two new functions to Common Lisp:
	ARRAY-DISPLACED-TO array 		[function]
	ARRAY-DISPLACED-INDEX-OFFSET array	[Function]
Did you overlook the function specified in the 6-Dec-85 "Clarifications"?
	DISPLACED-ARRAY-P array 		[Function]
"which takes an array and returns NIL and 0 if it is not displaced or the
array displaced to and the displaced-index-offset if it is displaced."

Wouldn't it be much better to adopt the "Clarifications" approaches, where
appropriate, since some, if not several, implementations have already 
implemented them?

-- JonL --

∂12-Jun-87  2255	Masinter.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Jun 87  22:55:41 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUN 87 22:54:31 PDT
Date: 12 Jun 87 22:54 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE  
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Fri,
 12 Jun 87 20:12 EDT
To: Fahlman@C.CS.CMU.EDU
cc: Masinter.pa@Xerox.COM, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870612-225431-2538@Xerox>

Puerhaps I wasn't clear. I think that the discussion of the coercion of
FUNCALL and APPLY is a central, and very important to discuss, at this
X3J13. However, I think it is separable from the issue of the FUNCTION
type, and the changes to FUNCTIONP and TYPEP of FUNCTION.    And, it
seems valuable to separate them, since, while they are both compatible
changes, there is not necessarily any correlation between whether one
supports one and the other, since their justifications and motivations
are not identical. 

My proposal is to separate them. One issue is FUNCTION-TYPE.  What is
the other issue called? I had tentatively named it FUNCTION-COERCION. A
proposal just arrived from Will Clinger, with selective linking as the
central theme (I alluded to this in an earlier message.)   I will mail
this out in a separate message (EVAL-DEFEATS-LINKER).  If your sentiment
is that we should not release one issue without the other, I agree, it
seems poor form and might let one get lost in the face of the other. If
you would like to keep them together in the same proposal, please
explain.

Thanks,

Larry



∂12-Jun-87  2256	Masinter.pa@Xerox.COM 	Issue: EVAL-DEFEATS-LINKER 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 12 Jun 87  22:55:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUN 87 22:55:21 PDT
Date: 12 Jun 87 22:55 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: EVAL-DEFEATS-LINKER
To: cl-cleanup@Sail.stanford.edu
cc: willc%tekchips.tek.com@RELAY.CS.NET
Message-ID: <870612-225521-2539@Xerox>

Date: 12 Jun 87 15:36:10 PDT (Fri)


Issue:        EVAL-DEFEATS-LINKER
References:   Functions (p32); FUNCTIONP (p76); APPLY (pp107-108);
              FUNCALL (p108); #. (pp355-356); #, (p356)
Category:     CHANGE
Edit history: 12-Jun-87, Version 1 by Clinger

Problem description:

It appears to be impossible to write a selective linker for Common Lisp
that is both reliable and effective.  The reason is that most programs
must call APPLY, FUNCALL, or READ, which potentially call SYMBOL-FUNCTION
or EVAL, which must be regarded as potential references to any standard
or user-defined Common Lisp procedure.  At a minimum, therefore, the
entire Common Lisp library gets linked into the deliverable application.

Proposal (EVAL-DEFEATS-LINKER:FLUSH-GRATUITOUS-EVALS):

Change the definition of the function type to exclude symbols and lists.
Change the definition of FUNCTIONP to be false of symbols and lists.
Change the definitions of APPLY and FUNCALL so it is an error to pass
them a symbol or a list as their first argument.

Functions such as MAPCAR that are defined by reference to the concept of
function or by reference to APPLY and FUNCALL would be affected by these
changes as well, but it would not be necessary to change their
written specification.

Remove the #. and #, dispatching macro characters from the standard reader
syntax.  Require the interpreter, compiler, and interactive loader to use
a reader syntax that has been extended by adding the #. and #, dispatching
macro characters.

Test Case:

The executable file for the following program is comparable in size to
a complete Common Lisp system.

    (DEFUN MAIN ()
      (PRINT (EVAL (READ))))

A selective linker should, however, be able to link the following program
into a relatively small executable file.

    (DEFUN MAIN ()
      (PRINT (APPLY (FOO) (READ))))

    (DEFUN FOO ()
      (LET ((BIAS (RANDOM 1000)))
        #'(LAMBDA (&REST ARGS) (+ BIAS (APPLY #'+ ARGS)))))

Currently selective linkers have difficulty with the preceding program
because they must also make programs like the following work, where FOO
"computes" an arbitrary function.  Under the proposal, the only ways
to compute an arbitrary function would be through explicit use of EVAL
or SYMBOL-FUNCTION et cetera.

    (DEFUN MAIN ()
      (PRINT (APPLY (FOO) (READ))))

    (DEFUN FOO () (READ))

Rationale:

Selective linking is essential for most industrial applications.  Symbols
and lambda expressions are regarded as functions for historical reasons
only.  The description of the #, dispatching macro character on p356
suggests that both #. and #, are intended for use in code, not in data
to be read by an application program.

Current practice:

Hardly any implementations of Common Lisp attempt to remove unnecessary
code from a deliverable application.  Those that do appear to ignore the
problems posed by the third test case, and are therefore unreliable.
That is, they are incorrect because they behave as though this proposal
has been adopted when it has not.

Adoption Cost:

Implementations do not actually have to change APPLY and FUNCALL, since
they would not have to signal an error when passed a symbol or list.
Implementations that rely on #. and #, in non-code data would suffer
a conversion cost, but it seems unlikely that any implementations do this.

Cost of non-adoption:

Selective linking will continue to be unavailable or unreliable.

Benefits:

The availability of reliable selective linkers will make Common Lisp suitable
for a much braoder range of applications.

Conversion Cost:

Programs for which reliable selective linking is unimportant (that is,
essentially all current Common Lisp programs) can be converted by
redefining APPLY and FUNCALL and by defining the #. and #, dispatching
character macros.  This will be referred to below as the trivial conversion.

Programs for which reliable selective linking is important, if any exist,
are presumably written in a style that needs no conversion.

To convert an existing program into a style that can be linked selectively,
it is necessary to examine all calls to APPLY, FUNCALL, MAPCAR, and other
functions that take functions as arguments.  Where the argument expression
is of the form (FUNCTION f), no conversion is necessary.  Where the first
argument is of the form (QUOTE f), it should be changed to (FUNCTION f).
Where the first argument is of neither of these two forms, human intervention
will be necessary.  It seems likely that most calls will have first arguments
of the form (FUNCTION f) or (QUOTE f), so this conversion can be automated
substantially but not completely.

As with all conversions, arguments to EVAL must be analyzed specially.
Since uses of EVAL generally defeat selective linking, however, it is
clear that programs that make extensive use of EVAL were not intended
to be passed through a selective linker.  Hence the trivial conversion
should suffice for such programs.

If the program reads data from files, then it may be necessary to scan the
files for occurrences of #. and #,.  If any occurrences are found, they
will have to be removed.  It seems clear, however, that no program intended
for selective linking will rely on #. and #, in data files.

Esthetics:

This proposal simplifies Common Lisp by removing weird special cases that
contribute to the language's reputation for inefficiency.

Discussion:

This is a good example of the practical importance of aesthetics in language
design.  The difficulties implementors face in writing a selective linker
for Common Lisp are inherent in the current language definition.  It is
better to fix the language than to postulate sufficiently clever linkers.

While this proposal will make it possible to construct selective linkers,
it will not make it trivial.  In many implementations, for example, the
data structure for each symbol contains among other things a pointer to
the symbol's home package, a value cell, and a function cell.  In such an
implementation each symbol may represent a potential reference to the value
cell of any symbol accessible from its home package.  Implementations that
care about selective linking may have to break such links.

Scheme proves that it is possible to design a Lisp that can be linked
selectively.  Reliable selective linkers have been written for T and for
MacScheme, and possibly for other implementations as well.




∂13-Jun-87  0042	edsel!bhopal!jonl@navajo.stanford.edu 	Hm    
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 13 Jun 87  00:42:20 PDT
Received: by navajo.stanford.edu; Sat, 13 Jun 87 00:39:53 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA02160; Fri, 12 Jun 87 23:04:06 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA01882; Fri, 12 Jun 87 23:06:05 PDT
Date: Fri, 12 Jun 87 23:06:05 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706130606.AA01882@bhopal.edsel.uucp>
To: navajo!Masinter.pa%Xerox.COM@navajo.stanford.edu
Cc: navajo!RPG%SAIL.STANFORD.EDU@navajo.stanford.edu,
        navajo!cl-cleanup%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: navajo!Masinter.pa@Xerox.COM's message of 12 Jun 87 09:37 PDT <870612-093806-1562@Xerox>
Subject: Hm  


Goodness no, by no means do I want to raise an objection to the AREF-1D
proposal.  I only wanted to make it perfectly clear that my interest
was not so much "support" or "criticism" of the overall proposal, but
a reminder that the 6-Dec-85 "Clarifications" had already addressed the 
functional issue, and had already picked the name ROW-MAJOR-AREF.  I guess 
I wasn't so "perfectly clear".

Eric Benson has already cast the Lucid vote in support of the proposal.

-- JonL --

∂14-Jun-87  1136	KMP@STONY-BROOK.SCRC.Symbolics.COM 	ADJUST-ARRAY-DISPLACEMENT    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 14 Jun 87  11:36:04 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 172424; Sun 14-Jun-87 14:28:35 EDT
Date: Sun, 14 Jun 87 14:28 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ADJUST-ARRAY-DISPLACEMENT
To: edsel!bhopal!jonl@navajo.stanford.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8706130027.AA01339@bhopal.edsel.uucp>
Message-ID: <870614142825.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Fri, 12 Jun 87 17:27:22 PDT
    From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)

    You suggest adding two new functions to Common Lisp:
	    ARRAY-DISPLACED-TO array 		[function]
	    ARRAY-DISPLACED-INDEX-OFFSET array	[Function]
    Did you overlook the function specified in the 6-Dec-85 "Clarifications"?
	    DISPLACED-ARRAY-P array 		[Function]
    "which takes an array and returns NIL and 0 if it is not displaced or the
    array displaced to and the displaced-index-offset if it is displaced."

If you code up the same example as I sent in my last message using
the function DISPLACED-ARRAY-P, you'll see that it's a lot more clumsy.
To me, the presence of these two functions makes the need for 
DISPLACED-ARRAY-P seem unnecessary while at the same time making 
code that actually needs this information look a lot better.

    Wouldn't it be much better to adopt the "Clarifications" approaches, where
    appropriate, since some, if not several, implementations have already 
    implemented them?

I certainly admit that I didn't look in the clarifications before
sending that message. I should have.

Ultimately, however, the clarifications are just one person's opinion (albeit
the opinion of one who is very highly respected). They still have to get voted
on just as do anyone else's suggestions. And while I admit that we shouldn't
try to gratuitously perturb things that people have already implemented where
it is reasonable to avoid doing so, I don't think we are obliged to 
unconditionally support an implementation's decision to introduce these 
primitives `prematurely'.

As it happens, I don't like functions with predicate-sounding names being
used for non-predicate values, so I'm not sure that I would have really
wanted to go with this clarification if I had a choice. eg, whenever I
use DIGIT-CHAR-P for value, I do
 (DEFUN DIGIT-WEIGHT (&REST ARGS) (APPLY #'DIGIT-CHAR-P ARGS))
and use DIGIT-WEIGHT instead. I find that expressions like 
 (+ (* VALUE RADIX) (DIGIT-CHAR-P CHAR))
look really awful in practice and can't bring myself to write them.

∂15-Jun-87  1919	Masinter.pa@Xerox.COM 	Re: ASSOC-RASSOC-IF-KEY (Version 1)  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Jun 87  19:19:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUN 87 13:23:44 PDT
Date: 15 Jun 87 13:23 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: ASSOC-RASSOC-IF-KEY (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Wed, 22 Apr 87 15:14 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870615-132344-158@Xerox>

I've been unable to find any other implementation (outside of symbolics)
that has ASSOC-IF-KEY.  I looked at Spice, Xerox and VaxLisp. I'm uneasy
saying that the others are "split down the middle" if they aren't. 


I tried to generate a test case. Can you think of something more
illuminating than

(ASSOC-IF #'ZEROP '(("ABC" . 3) ("E"  . 4) ("" . 7)) :KEY #'LENGTH)

  => ("" . 7)








∂15-Jun-87  1920	Masinter.pa@Xerox.COM 	READ TODAY: Cover letter for mailing to X3J13  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Jun 87  19:20:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 JUN 87 14:44:09 PDT
Date: 15 Jun 87 14:29 PDT
From: Masinter.pa@Xerox.COM
Subject: READ TODAY: Cover letter for mailing to X3J13
To: cl-cleanup@sail.stanford.edu
Message-ID: <870615-144409-103@Xerox>

I want to mail this tomorrow, as I must get the hardcopy version out,
and I am leaving town. Please reply asap. Also, while there have been a
couple of NACKs, no ACKs on the Monday meeting, 10 AM at Symbolics. Who
will attend?

Scott is working on FUNCTION-TYPE, and Kent on IF-BODY. It seems
important to get those versions in the hands of X3J13 in advance of the
meeting, so that there can be some meaningful discussion. I have
tentatively put new version numbers down with today's date.  

If the versions can be distributed to cl-cleanup today, there's a chance
of mailing them with the other hardcopy versions tomorrow (and I will
change the cover letter.) Otherwise, they will have to be distributed at
the meeting.

!
Dear X3J13 members:

Enclosed are several proposals from the cleanup committee for your
examination.   The committee has been "meeting" via electronic mail. For
each proposal, there has been an average of 10-15 messages. 

In most cases, the cleanup committee has explicitly endorsed the
proposal -- i.e., we all think it is a good idea. In some cases, while
the committee has generally agreed that the proposal is a good idea,
there hasn't been sufficient time to obtain agreement about the exact
form of the proposal; in those cases, while an earlier version was
circulated among the cleanup committee. In most of these proposals, some
earlier version was circulated to the committee and explicitly voted on.
In a few cases (identified in the proposal) there has been a great deal
of disagreement, but that we generally thought that we should bring the
matter to the attention of the larger group, for discussion and
guidance. 

For your information, I have listed below all of the issues currently
under consideration, with an extremely brief description of the issue.
If anyone is interested in further details, or in joining the cleanup
committee, please let us know (CL-CLEANUP@Sail.stanford.EDU).  Those
issues which are included in this mailing (and were mailed electronicly)
are marked with a !. Those marked with * were nearly ready for release,
but a final version is not available. We hope to have final versions of
these at the meeting.


!


! Proposal format (Version 11)
	Format for proposals to the cleanup committee.

 * ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
	(Standardize interaction of adjust-array and displacement)
	Discussion about :displaced-to nil vs no :displaced-to.
	Not ready for release

ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
	(Extend adjust-array so its OK on non-adjustable arrays.)
	Several comments which need reply
	Not ready for release

! AREF-1D (Version 5/11 Jun 87)
	(Add a new function for accessing arrays with row-major-index)
	Version 5 released
	
 ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
	(Extend ASSOC-IF, etc.  to allow :KEY)
	Almost ready for release

COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
	(Does *BREAK-ON-WARNING* affect the compiler?)
	Questions on interaction with condition proposal.
	Is this an environment issue?
	Not released.

! COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
	(Compiler warnings are printed on *ERROR-OUTPUT*)
	Version 3 released.
	Version 6 released 11-Jun-87.

! DEFVAR-INITIALIZATION (Version 4)
	((DEFVAR var) doesn't initialize)
	Version 3 Released
	Version 4 released 11-Jun-87 13:30:32

! DEFVAR-INIT-TIME (Version 2/29-May-87)
	(DEFVAR initializes when evaluated, not later.)
	Version 2 released 11-Jun-87 13:30:22
	
DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
	(can DO-SYMBOLS see the same symbol twice?)
	Debate: extend so that both options are available
	not ready for release
	
EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
	("selective linking" means GC non-used symbols; 
	proposal to change #., #, and part of FUNCTION-TYPE)
	Not ready for release

FILE-WRITE-DATE-IF-NOT-EXISTS 
	(What does FILE-WRITE-DATE do if no such file?)
	Defer to condition system?
	Not yet submitted.

! FLET-IMPLICIT-BLOCK (Version 6/ 5-Jun-87)
	(do FLETs have implicit named blocks around them?)
	Released 11-Jun-87

! FORMAT-ATSIGN-COLON (Version 4/5-jun-87)
	( @: == :@ in format)
	Version 3 released.
	Version 4 (re-)released 11-Jun-87 13:44:27.

* FORMAT-COMMA-INTERVAL (Version 1/10 June)
	(Allow another argument to ~D etc to paramerize digits between commas)
	Almost ready for release

FORMAT-NEGATIVE-PARAMETERS
	Not yet submitted; mail 19-May by KMP

! FORMAT-OP-C (Version 5/ 11-Jun-87)
	(What does ~C do?)
	Released 11-Jun-87

* FUNCTION-TYPE (Version 4/ 15-Jun-87)
	(Change definition of FUNCTIONP, function type ...)
	Not quite ready for release

GC-MESSAGES (version 1)
	(Control over unsolicited GC messages in typescript)
	merge with other controls for unsolicited messages?
	Not ready for release

! GET-SETF-METHOD-ENVIRONMENT (Version 4, 11-Jun-87)
	(Environment argument for GET-SETF-METHOD)
	Version 4 released 11-Jun-87

* IF-BODY (Version 7, 15-Jun-87)
	(extend IF to implicit progn if more than one ELSE form?)
	Not quite ready for release

IGNORE-ERRORS (Version 4, 29-May-87)
	(Introduce error catcher) 
	Pitman will release as report from cleanup + error committee

! IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
	(Does IMPORT affect home package?)
	Version 3 Released
	Version 5 released 11-Jun-87

! KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun)
	( &KEY arguments not in keyword package?)
	Version 6 released 15-Jun-87

LOAD-TIME-EVAL (Version 1, 6 Jun 87)
	(New function/macro/special form for evaluation when 
	compiled file is loaded?)
	Not ready for release

MACRO-FUNCTION-ENVIRONMENT 
	(Add environment argument to MACRO-FUNCTION?)
	Not yet submitted (From ENVIRONMENT-ARGUMENTS)

! PATHNAME-STREAM (Version 2)
	(PATHNAME only works on file streams)
	Released 11-Jun-87 15:03:54

PATHNAME-SYMBOL (Version 2)
	(Do symbols automaticly coerce to pathnames?)
	Not ready for release

PEEK-CHAR-READ-CHAR-ECHO (Version 1)
	(character interaction with echoing on terminal)
	Not ready for release

! PRINC-CHARACTER (Version 3)
	(PRINC behavior on character objections)
	Released 11-Jun-87 15:35:59

PROCLAIM-LEXICAL  (Version 1)
	(add LEXICAL proclaimation, default binding type for
	 undeclared free variables)
	Not ready for release

PROMPT-FOR (Version 1)
	(add new function which prompts)
	Not ready for release

PUSH-EVALUATION-ORDER
	(What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
	[PC, SEF] (PUSH FIRST SECOND)
	Not yet submitted. 

REQUIRED-KEYWORD-ARGUMENTS
	(Syntax for keyword arguments which must be supplied?)
	In discussion, no proposal submitted

REMF-DESTURCTION-UNSPECIFIED (Version 1)
	(How does REMF affect its arguments?)
	Not ready for release

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
	(FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
	In discussion, no clear consensus
	Not ready for release

SHARPSIGN-BACKSLASH-BITS
	(What does C-META-H-X mean?)
          not ready for release

SHARPSIGN-PLUS-MINUS-NUMBER
	(Is #+68000, #-3600 allowed?)
         not ready for release

SHARPSIGN-PLUS-MINUS-PACKAGE
	(What package are *features* in?)
         not ready for release

SPECIAL-FORM-SHADOW
	(Is it OK to shadow a special form with FLET, LABELS?)
	In discussion, no proposal submitted yet

TAILP-NIL
	(Operation of TAILP given NIL)
	Not yet submitted.

UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
	(GO out of UNWIND-PROTECT clauses.)
	Not ready for release

∂15-Jun-87  1938	FAHLMAN@C.CS.CMU.EDU 	READ TODAY: Cover letter for mailing to X3J13   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Jun 87  19:38:04 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 15 Jun 87 22:37:15-EDT
Date: Mon, 15 Jun 1987  22:37 EDT
Message-ID: <FAHLMAN.12310835145.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: READ TODAY: Cover letter for mailing to X3J13
In-reply-to: Msg of 15 Jun 1987  17:29-EDT from Masinter.pa at Xerox.COM


The second sentence in this paragraph isn't a sentence, and I can't
figure out what it's trying to say.  Something got garbled.

    In most cases, the cleanup committee has explicitly endorsed the
    proposal -- i.e., we all think it is a good idea. In some cases, while
    the committee has generally agreed that the proposal is a good idea,
    there hasn't been sufficient time to obtain agreement about the exact
    form of the proposal; in those cases, while an earlier version was
    circulated among the cleanup committee. In most of these proposals, some
    earlier version was circulated to the committee and explicitly voted on.
    In a few cases (identified in the proposal) there has been a great deal
    of disagreement, but that we generally thought that we should bring the
    matter to the attention of the larger group, for discussion and
    guidance.

I'm not sure I'd mention the "not yet submitted" issues at all in this
list.  If the idea is to solicit proposals on these issues from outside
the cleanup committee, that's OK, but in that case we need to describe
the problem better, and I would argue that this should be done in a
separate communication.  I don't feel passionately about this, but I do
think it's a bit confusing.

Otherwise, this looks OK to me.

-- Scott

∂15-Jun-87  2042	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: EVAL-DEFEATS-LINKER  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Jun 87  20:42:36 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 173727; Mon 15-Jun-87 23:41:49 EDT
Date: Mon, 15 Jun 87 23:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EVAL-DEFEATS-LINKER
To: Masinter.pa@Xerox.COM, willc%tekchips.tek.com@RELAY.CS.NET
cc: cl-cleanup@Sail.stanford.edu
In-Reply-To: <870612-225521-2539@Xerox>
Message-ID: <870615234142.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 12 Jun 87 22:55 PDT
    From: Masinter.pa@Xerox.COM

    Proposal (EVAL-DEFEATS-LINKER:FLUSH-GRATUITOUS-EVALS):

I don't think this is a good choice of name, because only the third paragraph
of the proposal has anything to do with EVAL.  EVAL-DEFEATS-LINKER:CLOSED-SYSTEM
would be a better name, and EVAL-DEFEATS-LINKER:REMOVE-FUNCTION-COERCION would
be even better if the readtable part is dropped as I suggest below.  This is
nit-picking, of course.

    Change the definition of the function type to exclude symbols and lists.
    Change the definition of FUNCTIONP to be false of symbols and lists.

The above two lines are redundant with the FUNCTION-TYPE proposal.  I guess
that means that this proposal has FUNCTION-TYPE as a prerecquisite.

    Change the definitions of APPLY and FUNCALL so it is an error to pass
    them a symbol or a list as their first argument.

    Functions such as MAPCAR that are defined by reference to the concept of
    function or by reference to APPLY and FUNCALL would be affected by these
    changes as well, but it would not be necessary to change their
    written specification.

This is the first cogent argument I have seen for why APPLY and FUNCALL should
not coerce names of functions to functions.  I'm glad to see the discussion
getting real.

One way to address the conflict between compatibility with existing
programs and the proposed automated subsetting of Common Lisp by observing
what features are manifestly used by a given program, would be to note the
use of the phrase "is an error".  This allows all existing implementations
to agree on an extension to Common Lisp to support coercion of function
names to functions, i.e. to agree to continue to do what they do now, while
not requiring future implementations to support that.  Programs that exploit
that feature would no longer be portable in law, but would remain portable
in practice, which seems like a desirable state of affairs.

These existing implementations could also agree on a switch that disables
the extension, to facilitate portability to implementations that lack the
extension.  I have to caution, however, that implementing such switches as
dynamic variables generally does not work in implementations where the
operating system is written in Lisp; we have some distasteful experience
with that in the areas of case-sensitivity in string comparison and
NIL-sensitivity in CAR and CDR.  Implementing the switch in a lexical way,
for instance by providing a package containing alternate versions of
FUNCALL, APPLY, and every CL function that calls FUNCALL or APPLY, would
avoid this problem.  There may be other techniques that are more
appropriate than switches.  Unfortunately reliance on coercion from
function names to functions is not, in general, detectable at compile time.
If it was detectable at compile time, this whole linker issue would not
have arisen.

    Remove the #. and #, dispatching macro characters from the standard reader
    syntax.  Require the interpreter, compiler, and interactive loader to use
    a reader syntax that has been extended by adding the #. and #, dispatching
    macro characters.

I see no reason to include this third part in the proposal.  Common Lisp already
provides ways to make customized readtables, and applications that want to run
in stripped-down Lisps can use those mechanisms to make readtables that don't
contain #. and #, and can inform their linker that they are using those mechanisms.
The proposal should mention the existence of the #. loophole, of course.
Isn't #S a bit of a loophole, also, although not quite as bad?

I have thought of one additional loophole; perhaps the best way to describe it
is with an example.

(defvar *funcall-loophole*)
(deftype funcall ()
  `(satisfies ,*funcall-loophole*))
(defun funcall-the-old-way (symbol argument)
  (let ((*funcall-loophole* symbol))
    (typep argument 'funcall)))
(funcall-the-old-way '1+ 5) => 6

Perhaps a linker can be written to detect the presence of DEFTYPEs complex
enough that they could be this loophole.  I could have written this without
using any special variables, and without using DEFTYPE; I just put those in
to make it look more complicated and thus harder to detect at compile time.
The key point here is that the SATISFIES type-specifier is defined to call
SYMBOL-FUNCTION.  I don't think we want to change that.

∂15-Jun-87  2140	Moon@STONY-BROOK.SCRC.Symbolics.COM 	READ TODAY: Cover letter for mailing to X3J13   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Jun 87  21:40:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 173769; Tue 16-Jun-87 00:30:59 EDT
Date: Tue, 16 Jun 87 00:30 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: READ TODAY: Cover letter for mailing to X3J13
To: Masinter.pa@Xerox.COM, Masinter.pa%Xerox.COM@MC.LCS.MIT.EDU
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <870615-144409-103@Xerox>
Message-ID: <870616003052.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 15 Jun 87 14:29 PDT
    From: Masinter.pa@Xerox.COM

    I want to mail this tomorrow, as I must get the hardcopy version out,
    and I am leaving town. Please reply asap.

This didn't make it from Xerox to Stanford until 5 hours after you sent it,
so expect delayed replies.  The evidence of a network problem somewhere is
why I'm sending this in a way that should get you three copies.

    Also, while there have been a
    couple of NACKs, no ACKs on the Monday meeting, 10 AM at Symbolics. Who
    will attend?

I haven't heard of this meeting before.  Gee, did I arrange it in my sleep?
As far as I know now I can attend, although something might come up.

I have no comments on the letter to X3J13 members, other than seconding
Fahlman's comment on fractured English in one place.

∂16-Jun-87  0159	Masinter.pa@Xerox.COM 	Re: READ TODAY: Cover letter for mailing to X3J13   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87  01:59:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 01:50:08 PDT
Date: 16 Jun 87 01:49 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: READ TODAY: Cover letter for mailing to X3J13
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Tue, 16 Jun 87 00:30 EDT
To: cl-cleanup@sail.stanford.edu
Message-ID: <870616-015008-1540@Xerox>

Thanks for the note on the mail delay. They were tinkering with the
mail-server today (moved it to another net), unfortunately, and mail got
temporarily delayed while it was down.

I will fix up the brain-damaged paragraph. 

As for the meeting, maybe David was asleep after all? 


.....


From: masinter.pa
Date: 31 May 87 20:49:38 PDT
Subject: ballots, meeting, etc.
To: cl-cleanup@sail.stanford.edu
Message-ID: <870531-205005-2070@Xerox>


...

MEETING:

I would like to get together Monday for a subcommittee meeting. I'd like
to discuss some of the more serious open issues and see how much
progress we can make. (PROCLAIM-LEXICAL seems like it might benefit from
a face-to-face discussion.) 

What do you think about taking some time to go over the ISSUES.TXT file
and getting some directions on them for us to proceed?

Other agenda items?


...

Date: Tue, 2 Jun 87 00:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ballots, meeting, etc.
To: masinter.pa
In-Reply-To: <870531-205005-2070@Xerox>
Message-ID: <870602002903.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

...

We can get a small (12-person) conference room at Symbolics if a room
elsewhere doesn't materialize.  I would need to sign up for it a few
days in advance to be sure to have it all day Monday.  We're at the
opposite end of the MIT campus from the Marriot hotel where apparently
people are staying, but it's within walking distance unless the weather
is outrageously hot.



Date: 11 Jun 87 16:05 PDT
From: Masinter.pa
Subject: Status
To: cl-cleanup@sail.stanford.edu
Message-ID: <870611-160520-187@Xerox>

...

David Moon has kindly offered this group a meeting room at Symbolics on
Monday. I suggest we start at 10:00, with a break for lunch, and plan on
ending around 4:00 PM.  

...

∂16-Jun-87  0608	FAHLMAN@C.CS.CMU.EDU 	Issue: FUNCTION-TYPE (version 5) 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jun 87  06:08:12 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 16 Jun 87 09:07:25-EDT
Date: Tue, 16 Jun 1987  09:07 EDT
Message-ID: <FAHLMAN.12310949843.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-TYPE (version 5)


I have written up a version of this proposal that presents the two
options we have discussed the most as alternatives.  The idea is that we
can perhaps debug this proposal before the Boston meeting, and then have
something concrete and written-down to discuss with the whole X3J13
group.  Perhaps that discussion will lead to some consensus or at least
to a clear view of which way the majority of X3J13 wants to go.  A mail
ballot after the meeting could make things official in that case.  Of
course, it is also possible that people will decide to postpone the
difficult issues and just vote on the type cleanup, without deciding how
the resulting types may be used.

By writing up these two options, I do not mean to preclude others.
However, the only other proposal that has appeared is the one from KMP
that we require a symbol's function cell to accept symbols and lambda
expressions as well as true functions and to return unchanged whatever
was put there.  Kent has indicated some ambivalence about whether he
wants to press forward with this option, which has not received any
support from others on the committee.  If he does want to press this,
he should write up this option himself, since I don't really understand
the fine points of his position.

Since I won't be there, I have included my own vote at the end.  I have
also included what I believe to be RPG's position, since he has made his
views known repeatedly.  I'm not sure exactly where the rest of you
stand at present.

Many small things had to be changed to make this a two-option proposal,
so it is probably best for you to consider this a new proposal and read
it over carefully.  The major substantive change is in point 3 (now in
two distinct versions).  There are also some changes in "cost of
conversion" -- see if you believe my argument that mechanical conversion
of old code to adhere to the strict form of the proposal is possible
and that the result is not significantly less efficient than building
the coercions into FUNCALL and APPLY.  Also, look over the discussion
section and see if I have seriously misrepresented anyone's views.

-- Scott
---------------------------------------------------------------------------

Status:         To be discussed at X3J13 meeting (?).  This is a
                tough but important issue that involves some fundamental
                trade-offs, so discussion by the whole X3J13 committee
                is called for.

Issue:          FUNCTION-TYPE
References:     functions (pg 32), types (pg 33), FUNCTIONP (pg 76),
                SYMBOL-FUNCTION (pg 90), APPLY (pg 107).
Category:     	CHANGE/CLARIFICATION
Edit History:   Version 1 by Gabriel 02/26/87
                Version 2 by cleanup committee 15-Mar-87
                Version 3 by Fahlman 10-May-87
                Version 4 by Masinter 29-May-87 incorporate comments
                Version 5 by Fahlman 15-June-87 include two options

Problem Description:

The definition of the term `function' in CLtL includes all symbols and
many lists in addition to true functions.  The type named `function' is
therefore not a useful type, and its presence complicates the type
hierarchy. The language would be improved if functions were treated as a
type in a consistent and useful manner.  This would also make it easier
to integrate the function data type into the CLOS class hierarchy.

At present, it is not the case that (FUNCTIONP x) is equivalent to
(TYPEP x 'FUNCTION), because the latter form is illegal under a strict
reading of the manual.  On page 47 it is stated 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.  In any event, this issue blurs
the status of the FUNCTION data-type.

The current confused situation came about mostly because of a desire in
the original Common Lisp definition to retain compatibility with older
Lisp dialects, but in the context of Common Lisp some of these ancient
design decisions are inappropriate.

Two alternative proposals are presented here:

Proposal FUNCTION-TYPE:STRICT-REDEFINITION

1. Under this proposal FUNCTION is a full-fledged data type that can be
used both for declaration and discrimination.  The list form of the
FUNCTION type specifier may still be used only for declaration.

Symbols (whether or not the symbol is FBOUNDP) and lambda expressions
are not of type FUNCTION under this proposal.

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.

No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION.  Examples might be
COMPILED-FUNCTION and INTERPRETED-FUNCTION.  Note that this is a change
from the current Common Lisp definition which explicitly defines a
COMPILED-FUNCTION type.  This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.

2. The behavior of FUNCTIONP is defined to be exactly equivalent to
#'(LAMBDA (X) (TYPEP X 'FUNCTION)).  In particular, FUNCTIONP is no
longer true of symbols and lambda lists.

3. FUNCALL and APPLY will now accept only a true function as the
functional argument.  This restriction is inherited by MAPCAR and other
functions in Common Lisp that take a functional argument suitable for
FUNCALL or APPLY.  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".

4. In all non-error situations, the result of evaluating a FUNCTION
special form is required to be of type FUNCTION.  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.  (Some implementations may
choose not to signal this error for performance reasons.)

5. If SYMBOL-FUNCTION is called on a symbol that names a function in the
null lexical context, it returns that function (which, of course, is of
type FUNCTION).  It is an error to call SYMBOL-FUNCTION on anything
else.  In particular, it is an error to call SYMBOL-FUNCTION on a symbol
that names a macro or special form in the null lexical context; it is
unpredictable what will be returned in this case.

It is an error to pass anything other than a (true) function as the
value to (SETF (SYMBOL-FUNCTION symbol) value).  Some implementations
will signal an error in this case; others may accept the bogus object
and fail only when the supposed function is called.

6. 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".  Where CLtL says "a definition that is a
lambda-expression", substitute "a definition from which the
implementation is able to reconstruct a lambda-expression".

Proposal FUNCTION-TYPE:COERCING-REDEFINITION

This is identical to FUNCTION-TYPE:STRICT-REDEFINITION except for
section 3:

3. The text descriptions of FUNCALL, APPLY, MAPCAR and other functions
in Common Lisp which take functional arguments are modified to state
they will accept (true) functions, symbols, or lists that represent
lambda-expressions.  A symbol or lambda expression is coerced to a
function using the null lexical environment, and the resulting function
is used.  Note that this is not a change to the current behavior of
Common Lisp; the descriptions must be changed to accommodate the new
definition of the FUNCTION data type.

RATIONALE:

Both proposals provide a clean, useful definition for the FUNCTION
data-type in Common Lisp.  Under the current definition, FUNCTIONP is
nearly useless, since it is defined to be true of all symbols, including
those that do not have functional definitions.

The STRICT-REDEFINITION proposal consistently uses the new, strict
definition of FUNCTION in all of the obvious places.

The COERCING-REDEFINITION proposal cleans up the definition of the
FUNCTION data type, but attempts to minimize the impact on existing code
by providing implicit coercions in FUNCALL and APPLY.  

Current Practice:

Current Common Lisp implementations vary in the way they handle
FUNCTIONP and TYPEP of FUNCTION.  They also vary in what they will allow
to be put into a SYMBOL-FUNCTION cell.  No current Common Lisp
implementation has exactly the semantics described in either of these
proposals, however.

Adoption Cost:

For either proposal, the type predicates would have to be brought into
compliance, but that should require little effort.

Compiled functions are true functions in almost all current
implementations, but in some implementations interpreted functions and
closures are represented as lists.  Such lists would have to be changed
to 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 easily reconstructed if necessary).

If STRICT-REDEFINE is adopted, implementations may choose to convert
FUNCALL and APPLY to the new stricter form, but they are not required to
do so.  Since the use of a symbol or lambda expression in place of a
function "is an error", an implementation may handle these cases as a
local extension.  Most implementations that continue to provide the
coercion will at least want to install an optional warning in FUNCALL
and APPLY to flag the use of this non-portable feature in user code.

BENEFITS:

By resurrecting FUNCTION as a useful concept, this proposal (either
version) will eliminate a lot of confusion and will make it easier to
talk about situations in which (true) functions are passed around as
Lisp objects.

By eliminating some tangles in the type hierarchy, this proposal
simplifies the task of mapping Common Lisp types into CLOS classes.  It
also brings Common Lisp into closer alignment with Scheme.

CONVERSION COST:

The COERCING-REDEFINITION proposal attempts to minimize the impact on
user code by allowing APPLY, FUNCALL, and related functions to accept
symbols and lambda lists, as they currently do.  One impact on
user-level code would be a change in the operation of certain type
predicates.  Such cases should be relatively easy to find and fix.

The STRICT-REDEFINITION proposal would require some additional changes
to user code.  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.  One strategy for
automatic conversion is to replace every call to FUNCALL, APPLY, etc.
with a call to an equivalent function or macro that tests the functional
argument at runtime and coerces the argument to a true function if
necessary.  If implemented carefully, this should not cost significantly
more than doing a built-in coercion within FUNCALL and APPLY.

Users might also convert their code by running for a time in an
implementation that still does the coercion in FUNCALL and APPLY, but
that issues a warning message whenever the coercion is actually needed.
This will flag all of the non-portable situations in parts of the
program that have actually been executed during the test period.

In some current Common Lisp implementations, SETF of SYMBOL-FUNCTION
will accept a symbol or lambda expression and SYMBOL-FUNCTION will
return this item unchanged.  If a symbol FOO is used as the functional
definition of BAR, then any change to FOO will affect BAR as well.  Some
old code (MACSYMA is one example) depends on this behavior and would
have to be modified if either of these proposals is adopted.  However,
such code is not currently portable because many existing Common Lisp
implementations already violate these assumptions.  CLtL does not
clearly state what values SETF of SYMBOL-FUNCTION will accept and how
that object may be modified.

Under either proposal, user code which uses COMPILED-FUNCTION-P would no
longer be valid or portable.

AESTHETICS:

Making the concept of a function well-defined will probably be perceived
as a simplification.

The STRICT-REDEFINITION proposal is perceived by most members of the
cleanup committee as the simpler and cleaner of the two proposals.  The
COERCING-REDEFINITION proposal adds some complexity in the name of
compatibility.

DISCUSSION:

This has been discussed at great length within the cleanup committee.
All of us agree that the definition of the FUNCTION data type must be
revised, but there is no clear consensus on what to do about the
coercions.  Since the cleanup of the type hierarchy is important to the
CLOS group, there is some urgency to this part of the proposal, at
least.

Some committee members (Gabriel and Fahlman) have argued that the strict
form of the proposal is preferable because it is simpler: it defines a
FUNCTION data type and then requires every object used as a function to
be a FUNCTION.  The strict proposal requires a somewhat greater
conversion effort for user code, but it seems better to make this effort
once than to live forever with runtime coercion of functional arguments
and the resulting complexity.

Members of the Eulisp group have argued strongly for what amounts to the
STRICT-REDEFINITION proposal.  They feel that this would remove one
important difference between their view of Lisp (similar to Scheme in
this instance) and ours.

Moon has argued that the coercing form of the proposal is no more
complex than the strict form; it is all a matter of taste.

Several members of the committee argued in favor of presenting both
proposals to X3J13, since the tradeoff between simplicity and conversion
effort must be discussed by the whole community.

White suggested that if the coercing version of the proposal is
adopted, we might need an APPLICABLE-P predicate that is true of any
object that is legal as a functional argument to APPLY and FUNCALL.
FUNCTIONP will not do this job.

Pitman has argued that items 4 and 5 (either proposal) will break a lot
of code that depends on being able to use lambda expressions and symbols
as function definitions, and that it will be hard to fix such problems.
He may produce a third proposal before the X3J13 meeting that deals with
these problems.  He has suggested that we may wish to settle the type
redefinition issues (points 1 and 2 above) now, while deferring a
decision on the more controversial coercion issues.

Fahlman feels that the issues are now clearly drawn and that we should
go ahead and make a decision on the whole package.

Clinger has suggested that the strict form is preferable because it makes
it possible to reduce the total size of a delivered application program.
Only those Common Lisp functions that are actually called need to be
included, but implicit function coercions tends to create loopholes
through which *every* function might be called.

The cleanup committee believes that the definition of COMPILE needs
clarification, but that it should be done in a separate proposal. The
change to COMPILE in this proposal is the minimum necessary.

Fahlman and Gabriel support FUNCTION-TYPE:STRICT-REDEFINITION.

∂16-Jun-87  1338	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Re: ASSOC-RASSOC-IF-KEY (Version 1)    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Jun 87  13:38:18 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 174496; Tue 16-Jun-87 16:35:22 EDT
Date: Tue, 16 Jun 87 16:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: ASSOC-RASSOC-IF-KEY (Version 1)
To: Masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870615-132344-158@Xerox>
Message-ID: <870616163500.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 15 Jun 87 13:23 PDT
    From: Masinter.pa@Xerox.COM

    I've been unable to find any other implementation (outside of symbolics)
    that has ASSOC-IF-KEY.  I looked at Spice, Xerox and VaxLisp. I'm uneasy
    saying that the others are "split down the middle" if they aren't. 

I think I didn't have access to other lisps in order to try it on the day
I sent that message. If none of the other lisps you know do it, then I'm
happy to say under current practice that only we are known to have implemented
the extension.

    I tried to generate a test case. Can you think of something more
    illuminating than

    (ASSOC-IF #'ZEROP '(("ABC" . 3) ("E"  . 4) ("" . 7)) :KEY #'LENGTH)

      => ("" . 7)

Well, I don't like to think of a non-accessor as the :KEY, though this
is technically fine.  We should probably give some advice about this in
the sample cleanup template; my feeling is that the test case just has
to illustrate the feature, not motivate it. Under this criterion, the
case above is fine.

The problem with a simple test case is that the need for this only comes up
in real program situations where objects with structured parts appear in
alists. In that case, you might have something like:

(DEFSTRUCT FOO X)
(ASSOC-IF #'IDENTITY '((#S(FOO :X NIL) 3 4) (#S(FOO :X T) 7)) :KEY #'FOO-X)

or

(ASSOC-IF #'PROBE-FILE '((#S(FOO :X "FOO.LSP") 3 4) (#S(FOO :X "BAR.LSP") 7))
	  :KEY #'FOO-X)

for that matter. In a real program, the #S(...) forms would presumably not be
constant -- they'd be pushed on by programs calling constructors -- and this
latter example doesn't return a constant value across implementations, but it
hopefully gives you a sense of what you can do. Another case might be:

(DEFVAR *KNOWN-PACKAGES* (MAPCAR #'FIND-PACKAGE '("LISP" "KEYWORD")))

(DEFUN KNOWN-PACKAGE-P (PACKAGE) (MEMBER PACKAGE *KNOWN-PACKAGES*))

(ASSOC-IF #'KNOWN-PACKAGE-P '((FROB . FUNCTION) (IF . SPECIAL-FORM))
	  :KEY #'SYMBOL-PACKAGE)
 => (IF . SPECIAL-FORM)

A situation that seems most familiar to me takes more work to set up:

(DEFUN FULL-DIRECTORY-LIST (WILD-PATHNAME)
  "Returns (wild-path (path1 :WRITE-DATE date1 :AUTHOR author1) ...)."
  (LET* ((PATHS (DIRECTORY WILD-PATHNAME))
         (DATES   (MAPCAR #'FILE-WRITE-DATE PATHS))
	 (AUTHORS (MAPCAR #'FILE-WRITE-DATE PATHS)))
    (CONS FILES
	  (MAPCAR #'(LAMBDA (PATH DATE AUTHOR)
		      (LIST PATH :WRITE-DATE DATE :AUTHOR AUTHOR))
		  PATHS DATES AUTHORS))))

In this case, you could imagine a variety of ASSOC-type operations that you
might want to do on the pathname in the car of each list in the cdr of the
result. In general, it's true that you can always write:

(ASSOC-IF #'(LAMBDA (P) (MEMBER (PATHNAME-TYPE P) '("LSP" "L" "LISP")
			     :TEST #'STRING-EQUAL))
	  (CDR DIRECTORY-LISTING))

but somehow I find it more aesthetic to see:

(ASSOC-IF #'(LAMBDA (TYPE) (MEMBER TYPE '("LSP" "LISP" "L")))
	  (CDR DIRECTORY-LISTING)
	  :KEY #'PATHNAME-TYPE)

so that the key extraction and the predication are separate. This increases
the likelihood that the function in the predicate position will already exist
with some known name. For example, going back to your original example,
there is no function which does (ZEROP (LENGTH x)) but there are functions
ZEROP and LENGTH which work together well in the place where :KEY is provided.

Feel free to extract any part of this message that moves you and add it to
the proposal if you feel it's warranted. Doubtless this text is too long
and rambly to be included as a whole.

∂16-Jun-87  1945	edsel!bhopal!jonl@navajo.stanford.edu 	READ TODAY: Cover letter for mailing to X3J13 
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 16 Jun 87  19:45:14 PDT
Received: by navajo.stanford.edu; Tue, 16 Jun 87 19:42:37 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA10855; Tue, 16 Jun 87 18:34:50 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA01141; Tue, 16 Jun 87 18:37:02 PDT
Date: Tue, 16 Jun 87 18:37:02 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706170137.AA01141@bhopal.edsel.uucp>
To: navajo!Masinter.pa%Xerox.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%sail.stanford.edu@navajo.stanford.edu
In-Reply-To: navajo!Masinter.pa@Xerox.COM's message of 15 Jun 87 14:29 PDT <870615-144409-103@Xerox>
Subject: READ TODAY: Cover letter for mailing to X3J13


I believe that Dick will attend the Monday meeting at Symbolics on Jun 29.
He is out of town now and won't be back til sometile Thursday.

-- JonL --

∂16-Jun-87  2040	FAHLMAN@C.CS.CMU.EDU 	Issue: EVAL-DEFEATS-LINKER  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jun 87  20:40:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 16 Jun 87 23:39:12-EDT
Date: Tue, 16 Jun 1987  23:39 EDT
Message-ID: <FAHLMAN.12311108567.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:   willc%tekchips.tek.com@RELAY.CS.NET
Subject: Issue: EVAL-DEFEATS-LINKER
In-reply-to: Msg of 13 Jun 1987  01:55-EDT from Masinter.pa at Xerox.COM


This proposal seems very odd to me.

It is certainly desirable for a Common Lisp implementation to have some
way to create a core image for application delivery that contains only
as much code as that application needs, and not all the rest of Common
Lisp and the associated development environment.  I have argued that
this approach to application delivery is much better than trying to
create some small delivery-oriented subset of Common Lisp: it is better
to keep those functions that you actually use and jettison the rest than
to try to guess in advance what subset would be appropriate for a whole
class of appliction.

A normal garbage collection will keep alive all of the functions that
are actually needed by a given application program, either directly or
indirectly.  Unfortunately, it will also keep alive every other function
that is globally named by a symbol, even if that symbol is not mentioned
in the application code.  Such functions are still "accessible" if there
is a read/eval present, since the user could ask for them by name, so
the garbage collector is not allowed to eliminate them.

We could get rid of these named functions if, by examining all the
application code, we could prove any of the following:

1. The symbol is not mentioned in the application and there is no way to
smuggle it into the system at runtime via calls to read, intern, etc.

2. The function is not called anywhere, and the symbol, though it may be
present, is not converted into a function anywhere.  Clinger's proposal
is to make this proof easier by eliminating a large class of implict
symbol-to-function conversions.

3. The function, though it may be present, is not called and is nowhere
passed to EVAL, APPLY, or FUNCALL.

That's one approach to eliminating the unneeded parts of Common Lisp.  A
different approach is is to simply ask the user to declare that the
application does not contain a full Common Lisp interpreter, if that is
his intent.  For example, an implementation might provide a facility
called COMPRESS-FOR-DELIVERY that retains a user-specified set of root
functions and everything that they call (transitively), but that flushes
all other functions that are normally found in a Common Lisp.

If such an application happens to have an EVAL lurking within, and if
the the user somehow passes (Y-OR-N-P "Foo") to it, he might find that
Y-OR-N-P is simply undefined.  Sorry, but this is a desk calculator, not
a full Common Lisp interpreter.

It seems to me that the latter approach is by far the more interesting
and useful one.  It also seems to me that this is an environment issue
and not something that this committee needs to worry about.  I see no
significant portability issue here.  In the compressed system, EVAL
doesn't mean quite what it did before, but nobody is claiming that this
desk calculator is a legal common lisp.  Exactly what COMPRESS retains
will depend on the internal details of each implementation, so there is
no point in trying to standardize this.

-- Scott

∂16-Jun-87  2336	Masinter.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE (version 5) 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jun 87  23:36:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JUN 87 15:18:19 PDT
Date: 16 Jun 87 15:17 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE (version 5)
In-reply-to: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>'s message of Tue,
 16 Jun 87 09:07 EDT
To: Fahlman@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870616-151819-260@Xerox>

Thanks, Scott.

Given that some important members of the community don't have regular
mail access, I think it would disenfranchise them to *not* mail this
issue out. I think your rewrite looks very good. Since I'm mailing the
other issues this afternoon, I am going to release your version, intact.
I will precede it with an introduction.


∂17-Jun-87  0844	barmar@AQUINAS.THINK.COM 	Issue: FUNCTION-TYPE (Version 5)  
Received: from [192.5.104.1] by SAIL.STANFORD.EDU with TCP; 17 Jun 87  08:44:15 PDT
Received: from POLYCARP.THINK.COM by AQUINAS.THINK.COM via CHAOS with CHAOS-MAIL id 32813; Wed 17-Jun-87 11:46:53 EDT
Date: Wed, 17 Jun 87 11:40 EDT
From: Barry Margolin <barmar@AQUINAS.THINK.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: CL-Cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: <870616-155121-101@Xerox>
Message-ID: <870617114008.1.BARMAR@POLYCARP.THINK.COM>

I think STRICT-REDEFINITION is reasonable, although I think I would
probably vote for COERCE-REDEFINITION because it has less impact on
existing code.

    The STRICT-REDEFINITION proposal would require some additional changes
    to user code.  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.  One strategy for
    automatic conversion is to replace every call to FUNCALL, APPLY, etc.
    with a call to an equivalent function or macro that tests the functional
    argument at runtime and coerces the argument to a true function if
    necessary.  If implemented carefully, this should not cost significantly
    more than doing a built-in coercion within FUNCALL and APPLY.

There is also a big hole in STRICT-REDEFINITION as currently proposed.
This paragraph suggests that one might coerce a symbol or lambda list to
a function at runtime, but the proposal doesn't mention any new function
that one would call to do this.  There needs to be a MAKE-FUNCTION
function, which takes a symbol or lambda list and returns the
corresponding function.  It probably should have an optional environment
argument, too.  It might be equivalent to

(defun make-function (thing &optional env)
  (eval `(function ,thing) env))

However, it should probably be a primitive so that implimentations can
do it optimally.

						barmar

∂17-Jun-87  1312	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: FUNCTION-TYPE (Version 5) 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 17 Jun 87  13:12:21 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 175697; Wed 17-Jun-87 16:11:37 EDT
Date: Wed, 17 Jun 87 16:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE (Version 5)
To: X3J13@SAIL.STANFORD.EDU
cc: CL-Cleanup@Sail.Stanford.Edu
In-Reply-To: <870616-155121-101@Xerox>
Message-ID: <870617161131.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

Since apparently we're going to discuss this proposal at length on the
X3J13 mailing list, I just wanted to point out one minor hole in it.

    CONVERSION COST:
    One strategy for
    automatic conversion is to replace every call to FUNCALL, APPLY, etc.
    with a call to an equivalent function or macro that tests the functional
    argument at runtime and coerces the argument to a true function if
    necessary.  If implemented carefully, this should not cost significantly
    more than doing a built-in coercion within FUNCALL and APPLY.

There is a large number of functions hiding inside that little "etc."
By my count there are 61 functions in Common Lisp that take :test or :key
arguments.  There are probably a few other functions that call FUNCALL
or APPLY internally.

∂17-Jun-87  1535	DLW@ALDERAAN.SCRC.Symbolics.COM 	Issue: IF-BODY (Version 7) 
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 17 Jun 87  15:35:51 PDT
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 93095; Wed 17-Jun-87 18:15:56 EDT
Date: Wed, 17 Jun 87 18:15 EDT
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue: IF-BODY (Version 7)
To: CL-CLEANUP@Sail.stanford.edu, X3J13@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
In-Reply-To: <870616-170738-108@Xerox>
Message-ID: <870617181519.0.DLW@CHICOPEE.SCRC.Symbolics.COM>
Line-fold: No

    Date: 16 Jun 87 17:07 PDT
    From: Masinter.pa@Xerox.COM

	     If this proposal is not accepted, it should be mandated that
    extensions to IF are explicitly disallowed.  The status quo, where there
    is a tacit acceptance of extensions which are not portable and difficult
    to detect, is unacceptable.

I'd like to state emphatically that I do not agree with this point of
view about extensions.  The original point of Common Lisp was to be a
large common subset, designed to allow portable programs without
stifling extensions and experimentation, and without creating massive
compatibility problems.  (I say "massive" because that's what would
happen if a policy of such explicit disallowal were applied across the
board.)  If this attitude had prevailed at the beginning, there would
have been no Common Lisp.

I take the position that there ought to be tools that specifically help
you make sure that your program can be expected to run portably in other
CL implementations.  The extended IF is not particularly "difficult to
detect" for such a tool; in fact, it's very easy.  Meanwhile, the
extended implementation need not print out any warnings.

Such a portability tool is needed for other reasons: even if a
particular CL implementation doesn't have any "extensions", nevertheless
it necessarily makes choices about things that the CL manual leave up to
the implementation, and a program could be depending on those choices.

∂17-Jun-87  1941	edsel!bhopal!jonl@navajo.stanford.edu 	Issue: EVAL-DEFEATS-LINKER
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 17 Jun 87  19:41:40 PDT
Received: by navajo.stanford.edu; Wed, 17 Jun 87 19:39:01 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA00489; Wed, 17 Jun 87 19:21:41 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA03068; Wed, 17 Jun 87 19:23:56 PDT
Date: Wed, 17 Jun 87 19:23:56 PDT
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8706180223.AA03068@bhopal.edsel.uucp>
To: navajo!Fahlman%C.CS.CMU.EDU@navajo.stanford.edu
Cc: navajo!cl-cleanup%SAIL.STANFORD.EDU@navajo.stanford.edu,
        navajo!willc%tekchips.tek.com%RELAY.CS.NET@navajo.stanford.edu
In-Reply-To: "Scott E. Fahlman"'s message of Tue, 16 Jun 1987  23:39 EDT <FAHLMAN.12311108567.BABYL@C.CS.CMU.EDU>
Subject: Issue: EVAL-DEFEATS-LINKER

I think I'll  have to agree generally with your analysis of this problem.
At Lucid, we have spent a good deal of time working on a tool similar to 
what you called COMPRESS-FOR-DELIVERY, and the results are not uniformly 
heartwarming.  Primarly, the mass of data involved in keeping track of all 
the constraints is a quagmire [that perhaps needs an expert system for 
solution?]; so it is not at all as simple a task as it seems at first.

Re: We could get rid of these named functions if, by examining all the
    application code, we could prove any of the following: ... [and]
    Clinger's proposal is to make this proof easier by eliminating a 
    large class of implict symbol-to-function conversions.

I'm just as skeptical as you are about the usefulness of making a 
controversial change in CL semantics just in order to remove one small 
aspect of the many hurdles in front of the impossible proof.  Many of 
the alleged dangers of the symbol-to-function mapping are in fact 
compile-time "harmless"; e.g. (mapc 'list l1 l2) should cause no one 
any more concern than (mapc #'list l1 l2), so why restrict it?  Also I 
like to write code like
     (dolist (fn '(a b c d e f))	
	;; Install the "boot level" versions of these basic functions
	(setf (symbol-function fn)
	      (symbol-function (append-symbols 'boot- fn))))
Rather than throw out the baby with the bathwater, I'd much rather have a 
declaration that said something like "This instance of symbol-function is 
restricted to the set of symbols {a b c d e f boot-a boot-b ... boot-f}".

Somehow, if the "proof" were ever made to be successful, I fear that the 
resultant language would be so much more like Pascal, and so little like 
the classic Lisps that the AI world grew up on, that X3J13 might just as 
well admit defeat and join the FortranADAPascalCModula crowd.


-- JonL --

∂18-Jun-87  1126	RPG  	FUNCTION-TYPE (Version 5)    
To:   cl-cleanup@SAIL.STANFORD.EDU    

I also believe that we should release this proposal to a larger
community. Scott's rendering of it seems good; his representation of
my position is accurate.

			-rpg-

∂18-Jun-87  1132	RPG  	FUNCTION-TYPE  (Version 5)   
To:   cl-cleanup@SAIL.STANFORD.EDU    

BARMAR's correct, we forgot to include an extension to COERCE on pages
51-52 to coerce symbols and certain lists to functions. I recall 
formulating an intention to mail such a proposal, but it seems I forgot.

			-rpg-

∂19-Jun-87  1429	@RELAY.CS.NET:willc@tekchips.tek.com 	Re: Issue: EVAL-DEFEATS-LINKER  
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 19 Jun 87  14:29:06 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac22243; 19 Jun 87 16:05 EDT
Received: from tektronix.tek.com by RELAY.CS.NET id aq09203; 19 Jun 87 15:56 EDT
Received: by tektronix.TEK.COM (5.51/6.23)
	id AA22564; Fri, 19 Jun 87 12:11:47 PDT
Received: by tekchips.TEK.COM (5.51/6.22)
	id AA01863; Fri, 19 Jun 87 12:14:18 PDT
Message-Id: <8706191914.AA01863@tekchips.TEK.COM>
To: cl-cleanup@SAIL.STANFORD.EDU
Cc: Fahlman@C.CS.CMU.EDU, willc%tekchips.tek.com@RELAY.CS.NET
Subject: Re: Issue: EVAL-DEFEATS-LINKER
In-Reply-To: Your message of Tue, 16 Jun 1987  23:39 EDT.
	     <FAHLMAN.12311108567.BABYL@C.CS.CMU.EDU>
Date: 19 Jun 87 12:14:16 PDT (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET

This is my response to a message from Scott Fahlman.

> This proposal seems very odd to me.

Cultural differences account for this:

    I think ordinary programs (which don't call EVAL or any of its subspecies) 
    should be linked selectively with no special effort.  This is what people
    do every day with other programming languages, including Scheme.  I
    couldn't care less about programs that explicitly call EVAL or its
    subspecies, because Real Programmers don't call EVAL.

    Scott wants programs that call EVAL or its subspecies, which he and
    his culture consider to be normal programs, to be linked selectively.
    This requires the user to name all the functions that might be involved
    in a call to EVAL.  He couldn't care less about programs that don't call
    EVAL or its subspecies, because Real Programmers call EVAL.

> A normal garbage collection will keep alive all of the functions that
> are actually needed by a given application program, either directly or
> indirectly.  Unfortunately, it will also keep alive every other function
> that is globally named by a symbol, even if that symbol is not mentioned
> in the application code.  Such functions are still "accessible" if there
> is a read/eval present, since the user could ask for them by name, so
> the garbage collector is not allowed to eliminate them.

The second sentence is correct only if EVAL or one of its subspecies is called
explicitly, the language is poorly designed, or the implementation is not
structured for selective linking.  I don't think programs that call EVAL
are worth worrying about, and I'm trying to patch the language design so
future implementatations can be designed for selective linking.  Note that
READ without EVAL would cause no problems for selective linking in a well-
designed implementation if it weren't for the language problems I have
identified.

> That's one approach to eliminating the unneeded parts of Common Lisp.  A
> different approach is is to simply ask the user to declare that the
> application does not contain a full Common Lisp interpreter, if that is
> his intent.  For example, an implementation might provide a facility
> called COMPRESS-FOR-DELIVERY that retains a user-specified set of root
> functions and everything that they call (transitively), but that flushes
> all other functions that are normally found in a Common Lisp.
> 
> If such an application happens to have an EVAL lurking within, and if
> the the user somehow passes (Y-OR-N-P "Foo") to it, he might find that
> Y-OR-N-P is simply undefined.  Sorry, but this is a desk calculator, not
> a full Common Lisp interpreter.
> 
> It seems to me that the latter approach is by far the more interesting
> and useful one.  It also seems to me that this is an environment issue
> and not something that this committee needs to worry about.  I see no
> significant portability issue here.  In the compressed system, EVAL
> doesn't mean quite what it did before, but nobody is claiming that this
> desk calculator is a legal common lisp.  Exactly what COMPRESS retains
> will depend on the internal details of each implementation, so there is
> no point in trying to standardize this.
> 
> -- Scott

My summary of this is that Scott is proposing that the semantics of EVAL
be left unspecified, and that it is ok to do this because EVAL is part of
the programming environment, not part of the language.  His proposal
wouldn't work unless we did the same for EVAL's subspecies like
SYMBOL-VALUE and SYMBOL-FUNCTION, so I have to assume he wants their
semantics to be left unspecified as well.

Considered by itself, this change in the status of EVAL and its subspecies
would be catastrophic, because essential functions like FUNCALL and APPLY
are defined in terms of EVAL or its subspecies.  If we change FUNCALL and
APPLY as I propose, and go further to fix everything else that depends on
EVAL and its subspecies, then I would be very sympathetic to the idea of
dropping EVAL, SYMBOL-VALUE, and SYMBOL-FUNCTION and their ilk from the
supported language.  I doubt that Scott really wants to go that far.

================================================================

I am sympathetic to David Moon's suggestion that #. and #, could be
left out of the proposal, since programs that want to be linked
selectively can just define #. and #, to be something innocuous.

-- Will

∂19-Jun-87  1737	FAHLMAN@C.CS.CMU.EDU 	Issue: EVAL-DEFEATS-LINKER  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Jun 87  17:37:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 19 Jun 87 20:36:06-EDT
Date: Fri, 19 Jun 1987  20:36 EDT
Message-ID: <FAHLMAN.12311861665.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: Issue: EVAL-DEFEATS-LINKER


    > This proposal seems very odd to me.

    Cultural differences account for this:

Yeah, I guess so.  I actually don't object to your proposal.  I've got
no objection to your kind of "selective linking with no special effort"
if a system wants to supply it.  I think that a system geared for
application delivery wants to have the kind of user-specified
compression I described in the previous note, but if some compression
can happen automatically, so much the better.  If the price for this is
flushing the coercion in APPLY and FUNCALL, that just gives me another
reason to favor FUNCTION-TYPE:STRICT-REDEFINITION, which I support for
other reasons anyway.  Like Moon, I dislike the change to #. and #, ,
but I guess that's not a big issue here.

    My summary of this is that Scott is proposing that the semantics of EVAL
    be left unspecified, and that it is ok to do this because EVAL is part of
    the programming environment, not part of the language.  His proposal
    wouldn't work unless we did the same for EVAL's subspecies like
    SYMBOL-VALUE and SYMBOL-FUNCTION, so I have to assume he wants their
    semantics to be left unspecified as well.

    Considered by itself, this change in the status of EVAL and its subspecies
    would be catastrophic, because essential functions like FUNCALL and APPLY
    are defined in terms of EVAL or its subspecies.

Well, not really.  It's another matter of culture, I guess, but I think
of this as leaving the semantics of EVAL alone; EVAL still treats a
symbol defined as a function just as before.  What changes is the set of
symbols that happen to have functional definitions at runtime.  Think of
it as coding in a Common Lisp subset, but you don't choose the subset
until the program is done and you examine what functions you actually used.

I suppose that flushing something like ATANH at compression time could
be viewed as changing the semantics of EVAL, and I suppose you could say
that this is disastrous because EVAL is used to define other things, but
I don't really see this as a useful way to look at the world.  If you
take this view, doesn't it also change EVAL (in a disastrous way) when
you define some new function?

-- Scott

∂22-Jun-87  2236	NGALL@G.BBN.COM 	Re: Issue: FUNCTION-TYPE (Version 5)  
Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 22 Jun 87  22:35:54 PDT
Date: 23 Jun 1987 01:34-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Issue: FUNCTION-TYPE (Version 5)
From: NGALL@G.BBN.COM
To: CL-Cleanup@SAIL.STANFORD.EDU
Cc: Masinter.pa@XEROX.COM
Message-ID: <[G.BBN.COM]23-Jun-87 01:34:43.NGALL>
In-Reply-To: <870616-155121-101@Xerox>

	
    Date: 16 Jun 87 15:33 PDT
    From: Masinter.pa@Xerox.COM
    
    
    FUNCTION-TYPE is one of the more difficult issues facing the cleanup
    committee. This is a tough but important issue that involves some
    fundamental trade-offs, so discussion by the whole X3J13 committee is
    called for.
    
My main concern about losing symbols as valid function objects (i.e.,
things that can be given to apply and funcall) is that it will make
the "functional style" of Lisp more difficult to debug.

For example, I use the following reader macro to allow function names
(symbols) to be used as arguments when my code is in the debugging
phase and "true" fucntions to be used when my code is "finished".

(defun |#!-reader| (stream subchar arg)
  (declare (ignore subchar arg))
  (let ((fname (read stream t nil t)))
    (if *debugging-p*
      `',fname
      `#',fname)))

(set-dispatch-macro-character
  #\#
  #\!
  (if *debugging-p* '|#!-reader| #'|#!-reader|))

Then, I can code the following (in most implementations):

(proclaim '(optimze (speed 0) (safety 3)))

(proclaim '(notinline froz))

(eval-when (compile load eval) (defparameter *debugging-p* t))

(defun froz ...)

...(funcall #!froz ...)...

...(mapcar #!froz ...)...

(defparameter *action-seq* `(,#!froz ,#!zorf ,#!(lambda ...) ...))
...
(apply (elt *action-seq* i) ...)

I can at any time trace froz in order to find out what is going on
(besides tracing I may also do some types of profiling). (Cf. trace,
pg 441.)  And what is probably even more important, when my
observation of the behavior of froz leads me to redefine froz, every
piece of code or data-structure that references the function name froz
will correctly get the new definition.

As CLtL is currently vague as to when it is permissable to dereference
a function name to its definition (compile-time, load-time, or
apply-time),  I have to avoid implementations that do not deference at
apply-time.

Under the strict redefinition proposal, I would have to recompile
every data structure that contained #'froz.  In other words, it would
make functional objects impratical to debug.

Under both proposals. function names (i.e., symbols and
lambda-expressions) are (virtually) eliminated as functional objects.
This is great way to "purify" the semantics of the language, but it
puts a big burden on implementors to come up with  development environments
that have the ease of debugging that function names provided.

I think I have probably mixed up a few issues here (it is late for
me), but I wanted to put in my warning that flushing function names
that can be passed around as functions has some major consequences on
Lisp style due to debugging/redefinition issues.


-- Nick

∂23-Jun-87  0809	FAHLMAN@C.CS.CMU.EDU 	Issue: FUNCTION-TYPE (Version 5) 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Jun 87  08:09:41 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 23 Jun 87 10:57:54-EDT
Date: Tue, 23 Jun 1987  10:57 EDT
Message-ID: <FAHLMAN.12312804981.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   NGALL@G.BBN.COM
Cc:   CL-Cleanup@SAIL.STANFORD.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
In-reply-to: Msg of 23 Jun 1987  01:34-EDT from NGALL at G.BBN.COM


There are lots of ways in which an implementation could provide tracing
facilities for anonymous function objects.  For human-interface
purposes, function objects would be identified using some label that is
derived from the original name under which the funciton was defined.
This information could be hidden in some slot of the function object or
(somewhat more portably) associated with it in a hashtable.

I haven't thought this through, but I bet that one could develop a trace
facility like the one you describe, but using anonymous stand-in
functions that print something and then call the original function
(which can be redefined) rather than using a symbol as a wrapper.  This
might even be strictly portable, which your hack is not.

If the same debugging functionality can be achieved in a different way,
I don't see the elimination of one dubious hack as a strong argument for
keeping the status quo.

-- Scott

∂23-Jun-87  0948	edsel!kent-state!eb@navajo.stanford.edu 	Issue: FUNCTION-TYPE (Version 5)  
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 23 Jun 87  09:48:42 PDT
Received: by navajo.stanford.edu; Tue, 23 Jun 87 09:45:40 PDT
Received: from kent-state.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA12003; Tue, 23 Jun 87 09:15:21 PDT
Received: by kent-state.edsel.uucp (3.2/SMI-3.2)
	id AA08001; Tue, 23 Jun 87 09:16:28 PDT
Date: Tue, 23 Jun 87 09:16:28 PDT
From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)
Message-Id: <8706231616.AA08001@kent-state.edsel.uucp>
To: navajo!NGALL%G.BBN.COM@navajo.stanford.edu
Cc: navajo!cl-cleanup%sail@navajo.stanford.edu
In-Reply-To: navajo!NGALL@G.BBN.COM's message of 23 Jun 1987 01:34-EDT <[G.BBN.COM]23-Jun-87 01:34:43.NGALL>
Subject: Issue: FUNCTION-TYPE (Version 5)

   Date: 23 Jun 1987 01:34-EDT
   Sender: navajo!NGALL@G.BBN.COM
   From: navajo!NGALL@G.BBN.COM


   My main concern about losing symbols as valid function objects (i.e.,
   things that can be given to apply and funcall) is that it will make
   the "functional style" of Lisp more difficult to debug.

   For example, I use the following reader macro to allow function names
   (symbols) to be used as arguments when my code is in the debugging
   phase and "true" fucntions to be used when my code is "finished".

   (defun |#!-reader| (stream subchar arg)
     (declare (ignore subchar arg))
     (let ((fname (read stream t nil t)))
       (if *debugging-p*
	 `',fname
	 `#',fname)))

   (set-dispatch-macro-character
     #\#
     #\!
     (if *debugging-p* '|#!-reader| #'|#!-reader|))

Here's a version of your debugging environment that adheres to the
strict definition of functions:

(defun |#!-reader| (stream subchar arg)
  (declare (ignore subchar arg))
  (let ((fname (read stream t nil t)))
    (if (consp fname)
	`#',fname
	(if *debugging-p*
	    `#'(lambda (&rest x) (apply #',fname x))
	    `#',fname))))

(set-dispatch-macro-character
  #\#
  #\!
  (if *debugging-p* 
      #'(lambda (&rest x) (apply #'|#!-reader| x))
      #'|#!-reader|))

∂23-Jun-87  1145	NGALL@G.BBN.COM 	Re: Issue: FUNCTION-TYPE (Version 5)  
Received: from G.BBN.COM by SAIL.STANFORD.EDU with TCP; 23 Jun 87  11:44:55 PDT
Date: 23 Jun 1987 14:43-EDT
Sender: NGALL@G.BBN.COM
Subject: Re: Issue: FUNCTION-TYPE (Version 5)
From: NGALL@G.BBN.COM
To: Fahlman@C.CS.CMU.EDU
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <[G.BBN.COM]23-Jun-87 14:43:05.NGALL>
In-Reply-To: <FAHLMAN.12312804981.BABYL@C.CS.CMU.EDU>

	
    Date: Tue, 23 Jun 1987  10:57 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
    ...
    I haven't thought this through, but I bet that one could develop a trace
    facility like the one you describe, but using anonymous stand-in
    functions that print something and then call the original function
    (which can be redefined) rather than using a symbol as a wrapper.  This
    might even be strictly portable, which your hack is not.

That's the problem.  No implementations (except perhaps Symbolics)
seem to have thought through encapsulation issues (of which tracing is
but one example).  Thus in many implementations, tracing functions
called from compiled code, even with speed 0 and safety 3 and
notinlines, does not work, or only works in some situtations.

    If the same debugging functionality can be achieved in a different way,
    I don't see the elimination of one dubious hack as a strong argument for
    keeping the status quo.

That's a big IF in my opinion, given that most implementations have so
far only provided the crudest of tracing and breaking facilities
(which all depend on apply-time deferencing of function-names).

It is not entirely clear from your response what you consider to be my
dubious hack.  If you mean that depending on implementations to
dereference function-names (i.e., symbols) at apply time (unless
declarations permit otherwise), then I must disagree with you.
Virtually all Lisp interpreters have this behavior, it is the
compilers that cause inconsistent behavior.  And since one of Common
Lisp's major goals is to "impose identical semantics" on compiled and
interpreted code, I claim that my examples were perfectly correct CL
programs and compilers that don't enforce proper dereferencing are
broken.

The ability to apply function names (and have them deferenced as late
as possible) may have gotten into Lisp for
dubious reasons, but it has been a very strong reason why Lisp has
succeeded as a flexible, incremental, and rapid development
environment.  If we remove this feature without alternative mechanisms
ALREADY IN PLACE, we will make Lisp debugging more primitive than
conventional language debugging.

-- Nick

∂23-Jun-87  1538	RAM@C.CS.CMU.EDU 	Issue: FUNCTION-TYPE (Version 5)
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 23 Jun 87  15:38:19 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 23 Jun 87 18:37:27-EDT
Date: Tue, 23 Jun 1987  18:37 EDT
Message-ID: <RAM.12312888633.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   NGALL@G.BBN.COM
Cc:   CL-Cleanup@SAIL.STANFORD.EDU, Fahlman@C.CS.CMU.EDU
Subject: Issue: FUNCTION-TYPE (Version 5)
In-reply-to: Msg of 23 Jun 1987  14:43-EDT from NGALL at G.BBN.COM


Since this message addresses compiler semantics, I thought I'd comment
on it...

    Date: Tuesday, 23 June 1987  14:43-EDT
    From: NGALL at G.BBN.COM
    To:   Fahlman at C.CS.CMU.EDU
    Re:   Issue: FUNCTION-TYPE (Version 5)

    [...]  It is not entirely clear from your response what you
    consider to be my dubious hack.  If you mean that depending on
    implementations to dereference function-names (i.e., symbols) at
    apply time (unless declarations permit otherwise), then I must
    disagree with you.  Virtually all Lisp interpreters have this
    behavior, it is the compilers that cause inconsistent behavior.
    And since one of Common Lisp's major goals is to "impose identical
    semantics" on compiled and interpreted code, I claim that my
    examples were perfectly correct CL programs and compilers that
    don't enforce proper dereferencing are broken.

Perhaps unfortunately, it isn't possible to implement anything that
could reasonably be called a "compiler" so that it has exactly the
same semantics as traditional interpreters.  The entire purpose of a
compiler is to make use of compile-time information in order to
transform the program into a more efficient and more specific program.

In my compiler cleanup proposal, I argue that Common Lisp shouldn't
talk about the semantics of compiled v.s. interpreted code, instead it
should define "evaluation" in a way that is broad enough to encompass
both compiled and interpreted evaluation strategies.  This mostly
amounts to saying "It is an error to write a program that cannot be
compiled.", since there are few things a compiler can do that
interpreters don't.

    The ability to apply function names (and have them deferenced as
    late as possible) may have gotten into Lisp for dubious reasons,
    but it has been a very strong reason why Lisp has succeeded as a
    flexible, incremental, and rapid development environment.

This is a valid point, but it doesn't directly translate into marching
orders for Common Lisp standardization.  We should attempt to design
Common Lisp so that it doesn't preclude useful environment features,
but we are not obligated to provide them directly in the language.

I agree with you that it should be possible to force compilers to do
full function call, but the issues aren't totally clear.  For example,
the functions that are being expanded inline are presumably standard
Common Lisp functions.  It is all very well to say "NOTINLINE inhibits
inline expansion", but this capability is of little use unless you can
redefine standard functions.  [Which was discussed to death on
common-lisp a while back.]

You must always remember that when Common Lisp says that something "is
an error", implementations are not forbidden to assign meaning to that
usage.  If there is a feature that is needed to support an environment
so amazing mind-bogglingly whizzy that you can't live without it, then
everybody will want that kind of environment support, and all
"reasonable" implementations will provide it.  This in itself is not a
particularly strong argument for standardizing the *feature that
supports the environment*.  It is only when we start talking about
portable environment facilities that we become concerned.

The concept of a "reasonable" implementation is also important.
Common Lisp does not reqire implementations to be reasonable; it only
requires that programs meeting the specification run in all
implementations (subject to resource limitations and other ill-defined
vaguenesses.)   It is not a valid argument to say "X must be in Common
Lisp because I refuse to use a system that doesn't support X."  You
must demonstrate that X aids significantly in writing interesting
portable programs, rather than simply allowing you to hack in the
manner to which you have become accustomed.

  Rob

∂25-Jun-87  2333	Moon@STONY-BROOK.SCRC.Symbolics.COM 	FUNCTION-TYPE: not allowing symbols to be used as functions    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 25 Jun 87  23:33:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 182745; Fri 26-Jun-87 01:43:35 EDT
Date: Fri, 26 Jun 87 01:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: FUNCTION-TYPE: not allowing symbols to be used as functions
To: CL-Cleanup@sail.stanford.edu
Message-ID: <870626014327.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

*MACROEXPAND-HOOK* is another one you overlooked.  Its default value
is the symbol FUNCALL, and its value gets funcalled, therefore it
relies on funcalling a symbol and would need to be reworked.

∂26-Jun-87  1104	@MCC.COM,@HAL.CAD.MCC.COM:Loeffler@MCC.COM 	Issue: IF-BODY (Version 7)
Received: from MCC.COM by SAIL.STANFORD.EDU with TCP; 26 Jun 87  11:04:33 PDT
Received: from HAL.CAD.MCC.COM by MCC.COM with TCP; Fri 26 Jun 87 13:02:58-CDT
Date: Fri, 26 Jun 87 13:02 CDT
From: David D. Loeffler <Loeffler@MCC.COM>
Subject: Issue: IF-BODY (Version 7)
To: CL-CLEANUP%Sail.stanford.edu@MCC.COM
cc: Masinter.pa%Xerox.COM@MCC.COM
In-Reply-To: <870616-170738-108@Xerox>
Message-ID: <870626130230.6.LOEFFLER@HAL.CAD.MCC.COM>
Reply-To: Loeffler@MCC.COM
Postal-address: MCC, 3500 West Balcones Center Dr., Austin, TX 78759
Business-phone: (512) 338-3666

If I were to change IF to allow multiple else causes I would like to
change IF to be like Bernie Greenberg's IF in his Multics Emacs
implementation, namely:

(IF test then-clauses :ELSE else-clauses)


This certainly would be incompatible with existing code but would allow
both multiple THEN and ELSE clauses.

  -- David D. Loeffler

∂29-Jun-87  2239	KMP@STONY-BROOK.SCRC.Symbolics.COM 	DEFVAR-DOCUMENTATION (Version 1)  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 29 Jun 87  22:39:09 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 185077; Tue 30-Jun-87 01:27:05 EDT
Date: Tue, 30 Jun 87 01:26 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DEFVAR-DOCUMENTATION (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <870630012646.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        DEFVAR-DOCUMENTATION
References:   DEFVAR, DEFPARAMETER, DEFCONSTANT (pp68-9)
Category:     CLARIFICATION
Edit history: 30-Jun-87, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  CLtL is not explicit about whether the documentation part of
  DEFVAR, DEFPARAMETER, and DEFCONSTANT special forms is evaluated.

Proposal (DEFVAR-DOCUMENTATION:UNEVALUATED):

  Clarify that the documentation part of DEFVAR, DEFPARAMETER, and
  DEFCONSTANT special forms is not evaluated. That is, it must be
  a literal string, not a form which evaluates to a string.

Rationale:

  To ensure portability, implementations must agree on whether or not
  this position is evaluated. Specifying that the position is unevaluated
  is the conservative thing to suggest.

Current Practice:

  Some implementations evaluate this position. Others do not.

Adoption Cost:

  The change is presumably trivial in all implementations.

Benefits:

  Code portability would be improved.

Conversion Cost:

  Code which uses other than a literal string is not portable, so no portable
  programs will be broken. Some non-portable programs which rely on a particular
  vendor's interpretation would have to be rewritten. Automatic tools to detect
  most offending cases could trivially be constructed.

Aesthetics:

  No significant impact.

Discussion:

  Pitman thinks this is a good idea.

∂06-Jul-87  1658	Masinter.pa@Xerox.COM 	AREF-1D (Version 6)   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 6 Jul 87  16:57:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JUL 87 16:45:33 PDT
Date: 6 Jul 87 16:45 PDT
From: Masinter.pa@Xerox.COM
Subject: AREF-1D (Version 6)
To: cl-cleanup@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Message-ID: <870706-164533-1986@Xerox>

This revision clarifies the proposal by giving arguments and some
equivalence relations. I added that row-major-aref was usable with SETF
(which did not appear in the original proposal although it was implied
in one of the examples.)
!
Issue:        AREF-1D
References:   Arrays (pp286-298)
Category:     ENHANCEMENT
Edit history: 22-Apr-87, Version 1 by Pitman
              02-Jun-87, Version 2 by Pitman (ROW-MAJOR-AREF)
              6-Jun-87, Versions 3, 4 by Masinter (editorial)
              11-Jun-87, Version 5, to X3J13 (no changes)
               6-Jul-87, Version 6, by Masinter

Problem Description:

It's hard to write functions like Maclisp's LISTARRAY and FILLARRAY
efficiently in Common Lisp because they take arguments of varying rank.
Currently, you have to make a displaced array to work with temporarily
and then throw away the displaced array when you're done. In many cases,
this is bothersome because there is no a priori reason why they should
have to cons at all.

Proposal (AREF-1D:ROW-MAJOR-AREF):

Introduce a new function ROW-MAJOR-AREF that allows one-dimensional
access to the storage backing up a given array assuming the normal
row-major storage layout.

ROW-MAJOR-AREF is valid for use with SETF.

row-major-aref array index              [Function]

This accesses and returns the element of array specified by index when
the elements of array are considered in row-major order. Array may be an
array of any dimensionality. row-major-aref may be used with setf. For
reference, the following sets of expressions are equivalent:

(row-major-aref array index) ==
    (aref (make-array (array-total-size array)
                      :displaced-to array
                      :element-type (array-element-type array))
          index)

and

(aref array .. subscripts ..) ==
    (row-major-aref array (array-row-major-index array .. subscripts
..))

Rationale:

Common Lisp requires row-major storage layout of arrays and has a number
of operators that allow users to exploit that order. ROW-MAJOR-AREF is a
useful, simple addition.

LISTARRAY and FILLARRAY, for example, could be trivially defined by
loops that had the following form:

    (DOTIMES (I (ARRAY-TOTAL-SIZE ARRAY))
      ... (ROW-MAJOR-AREF ARRAY I) ...)

Currently, the only really efficient way to write this would involve
something like:

    (ECASE (ARRAY-RANK ARRAY1)
      ((0) (SETF (AREF ARRAY1) (AREF ARRAY2)))
      ((1) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
	     (SETF (AREF ARRAY1 I) (AREF ARRAY2 I))))
      ((2) (DOTIMES (I (ARRAY-DIMENSION ARRAY 0))
	     (DOTIMES (I (ARRAY-DIMENSION ARRAY 1))
	       (SETF (AREF ARRAY1 I J) (AREF ARRAY2 I J)))))
      ...some finite number of clauses...)

Current Practice:

Many implementations have this primitive under some other name for use
internally. In Symbolics systems, for example, it is SYS:%1D-AREF.

Adoption Cost:

This change is fairly localized. In implementations that already use
this primitive internally, it's little more than a matter of changing
the name of or otherwise releasing the existing primitive. In some
implementations, it might involve writing a small amount of code or
compiler work to make ROW-MAJOR-AREF work efficiently.

Benefits:

This gives users efficient access to something to which they already
have inefficient access.

Conversion Cost:

This is an upward-compatible change; the name ROW-MAJOR-AREF is unlikely
to be used by any current program.

Aesthetics:

This allows certain programs to be written in a more aesthetic way.

Discussion:

The cleanup committee generally supports this enhancement. Version 2 was
endorsed (assuming change to function name ROW-MAJOR-AREF.)

     ----- End Forwarded Messages -----

∂13-Jul-87  1257	Masinter.pa@Xerox.COM 	Issue: FUNCTION-TYPE  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87  12:54:07 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 12:54:07 PDT
Date: 13 Jul 87 12:53 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870713-125407-2098@Xerox>

We are tasked with producing a new version of FUNCTION-TYPE for
consideration at the next X3J13. The new version should reflect the
discussion held so far. My notes and memory are poor. Does anyone else
have any notes?

My notes include that point 6 (the description of COMPILE) should be
removed from this proposal, that there was some sentiment for
considering a proposal where symbols coerced to their symbol-function
but lists did not, consideration of APPLICABLE-P, a proposal where
FUNCTION and FUNCTIONP stayed the same but there was a new type
PROCEDURE and PROCEDUREP, that we be more consistent about justifying
removing COMPILED-FUNCTION-P (i.e., why bother?), that the proposal
mention selective linking.

Some of the discussion centered around the merits of Dynamic Linking and
the Value of Lisp, the behavior of COERCE and the FUNCTION type. 

∂13-Jul-87  1321	Masinter.pa@Xerox.COM 	Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5) 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87  13:21:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 13:18:40 PDT
Date: 13 Jul 87 13:18 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Message-ID: <870713-131840-2151@Xerox>


This issue passed conditionally. In this version, I  changed  the last
paragraph of the proposal,  and attempted to add a test case. I hope
that I did not spoil the intent. 
!
Issue:          GET-SETF-METHOD-ENVIRONMENT
References:     GET-SETF-METHOD (CLtL p 187)
Category:       Change
Edit History:   Version 1 9-Jan-87, Version 1 by Masinter 
                (no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
                Version 2 29-May-87, extracted again 
                Version 3  5-Jun-87, by Masinter
                Version 4  11-Jun-87, for release
                Version 5  13-Jul-87, by Masinter
                
Problem Description:

If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,

 (defmacro special-incf ... (get-setf-method ...) ...)

then  

 (macrolet ((test (x) `(car ,x)))
         (special-incf (test z)))

would not "see" the test definition.

Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):

Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. NIL can also be passed
explicitly to denote the null lexical environment.

Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.

Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.

Clarify that, within the scope of a MACROLET, FLET and LABELS, global
SETF definitions of the name defined by the MACROLET, FLET or LABELS do
not apply.  A SETF method applies only when the global function binding
of the name is lexically visible.  All of the built in macros of Common
Lisp (SETF, INCF, DECF, POP, ROTATEF, etc.) which modify location
specifications obey this convention.

Test Case:

;;; This macro is like POP 

(defmacro xpop (place &environment env)
  (multiple-value-bind (dummies vals new setter getter)
                       (get-setf-method place env)
     `(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter))
        (prog1 (car ,(car new))
               (setq ,(car new) (cdr ,(car new)))
               ,setter)))))

(defsetf frob (x) (value) 
    `(setf (car ,x) ,value))

;;; The following will modify (cdr z) and not (car z)
(macrolet ((frob (x) `(cdr ,x)))
     (xpop (frob z)))

;;; The following is an error; an error may be signaled at macro
expansion time

(flet ((frob (x) (cdr x))
     (xpop (frob z)))


Rationale:

This was an omission in the original definition of CLtL.

Current Practice:

Many Common Lisp implementations already have this extension, although
some do not. One implementation has extended GET-SETF-METHOD to take an
optional argument which is incompatible with this use.

Adoption Cost:

Some implementations will have to add this feature, although it is not a
major change.

Benefits:

This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.

Conversion Cost:

This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a user's program is
very small.

Aesthetics:

SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct. 

Discussion:

The cleanup committee generally supports this change.

A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common
Lisp Object System) and should be addressed by a future proposal. For a
while, the cleanup committee attempted to deal with these issues
together, but decided to separate them out into their component parts.
This issue is the simplest.

∂13-Jul-87  1344	Masinter.pa@Xerox.COM 	Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5) 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87  13:21:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 13:18:40 PDT
Date: 13 Jul 87 13:18 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU
CC: Masinter.pa@Xerox.COM
Message-ID: <870713-131840-2151@Xerox>


This issue passed conditionally. In this version, I  changed  the last
paragraph of the proposal,  and attempted to add a test case. I hope
that I did not spoil the intent. 
!
Issue:          GET-SETF-METHOD-ENVIRONMENT
References:     GET-SETF-METHOD (CLtL p 187)
Category:       Change
Edit History:   Version 1 9-Jan-87, Version 1 by Masinter 
                (no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
                Version 2 29-May-87, extracted again 
                Version 3  5-Jun-87, by Masinter
                Version 4  11-Jun-87, for release
                Version 5  13-Jul-87, by Masinter
                
Problem Description:

If a macro that performs similar processing to SETF uses
GET-SETF-METHOD, and that macro occurs within a MACROLET, the expansion
will not see the MACROLET definition, e.g.,

 (defmacro special-incf ... (get-setf-method ...) ...)

then  

 (macrolet ((test (x) `(car ,x)))
         (special-incf (test z)))

would not "see" the test definition.

Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):

Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. NIL can also be passed
explicitly to denote the null lexical environment.

Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.

Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.

Clarify that, within the scope of a MACROLET, FLET and LABELS, global
SETF definitions of the name defined by the MACROLET, FLET or LABELS do
not apply.  A SETF method applies only when the global function binding
of the name is lexically visible.  All of the built in macros of Common
Lisp (SETF, INCF, DECF, POP, ROTATEF, etc.) which modify location
specifications obey this convention.

Test Case:

;;; This macro is like POP 

(defmacro xpop (place &environment env)
  (multiple-value-bind (dummies vals new setter getter)
                       (get-setf-method place env)
     `(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter))
        (prog1 (car ,(car new))
               (setq ,(car new) (cdr ,(car new)))
               ,setter)))))

(defsetf frob (x) (value) 
    `(setf (car ,x) ,value))

;;; The following will modify (cdr z) and not (car z)
(macrolet ((frob (x) `(cdr ,x)))
     (xpop (frob z)))

;;; The following is an error; an error may be signaled at macro
expansion time

(flet ((frob (x) (cdr x))
     (xpop (frob z)))


Rationale:

This was an omission in the original definition of CLtL.

Current Practice:

Many Common Lisp implementations already have this extension, although
some do not. One implementation has extended GET-SETF-METHOD to take an
optional argument which is incompatible with this use.

Adoption Cost:

Some implementations will have to add this feature, although it is not a
major change.

Benefits:

This change improves portability and the ability to use MACROLET, FLET
and LABELS in portable code which might also have SETF forms.

Conversion Cost:

This is generally an upward compatible change. In implementations which
did not already take into account the lexical environment for SETF'd
forms might start working differently if the internal implementation of
SETF is changed. The likelihood of this affecting a user's program is
very small.

Aesthetics:

SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more
consistent and correct. 

Discussion:

The cleanup committee generally supports this change.

A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common
Lisp Object System) and should be addressed by a future proposal. For a
while, the cleanup committee attempted to deal with these issues
together, but decided to separate them out into their component parts.
This issue is the simplest.

∂13-Jul-87  1415	Masinter.pa@Xerox.COM 	Status 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87  14:15:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 14:11:08 PDT
Date: 13 Jul 87 14:05 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
cc: Masinter.pa@Xerox.COM
Subject: Status
Message-ID: <870713-141108-2238@Xerox>

This is my status file.

Please reply with individual messages about each issue.  

At the face-to-face meeting before X3J13, we discussed the remaining
issues in Clarifications.txt. I will be sending out separate messages
about each of those under the heading of an issue name I will ascribe,
and will then add those issues to the status file.

 I intend to segment this status file into Active, Passed and Tabled
Indefinitely. (I suppose there might be some argument about dividing
things between Active and Tabled, but I urge you to avoid arguing about
it until there's an issue that I've marked Tabled that you want to
continue to discuss.)

!


Proposal format (Version 11)
 Format for proposals to the cleanup committee.
 Version 11 released 11-Jun-87.
 (Suggestion to add a Related Issues field.)

ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
 (Standardize interaction of adjust-array and displacement)
 Discussion about :displaced-to nil vs. no :displaced-to.
 Masinter to revise, clarify :displaced-to ommitted'
      same as :displaced-to nil.

ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
 (Extend adjust-array so its OK on non-adjustable arrays.)
 Several comments which need reply
 Not ready for release.
 Notes from boston cl-cleanup meeting have *, but
  the mail traffic seems inconclusive.

* AREF-1D (Version 6/6 JUL 87)
 (Add a new function for accessing arrays with row-major-index)
 Version 5 released
 Conditionally passed at X3j13/Jun87 pending new version.
 Version 6 mailed to cl-cleanup.

ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
 (Extend ASSOC-IF, etc.  to allow :KEY)
 Not ready for release.
 Needs revision of current practice, test case, example. (KMP?)
 The summary says Version 2, but I only have version 1 on file.
 Does anyone else have a version 2? Or was this wishful thinking?

COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
 (Does *BREAK-ON-WARNING* affect the compiler?)
 Questions on interaction with condition proposal.
 Is this an environment issue?
 Not released.
 Postponed pending error proposal

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

< DEFVAR-INIT-TIME (Version 2/29-May-87)
 (DEFVAR initializes when evaluated, not later.)
 Version 2 passed X3J13/Jun87.

DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
 (can DO-SYMBOLS see the same symbol twice?)
 Debate: extend so that both options are available?
 Not ready for release.
 Needs more information on implementation and
   performance cost.
 Masinter will rewrite, flush :ALLOWED option,
  rewrite :ADD-KEYWORDS to make default for
  :ALLOW-DUPLICATES as NIL., conversion cost => nil.

EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
 ("selective linking" means GC non-used symbols; 
 proposal to change #., #, and part of FUNCTION-TYPE)
 Not ready for release.
   Was discussion at X3J13 conclusive? 
   Should this issue be abandoned? (cc: clinger, please)

FILE-WRITE-DATE-IF-NOT-EXISTS 
 (What does FILE-WRITE-DATE do if no such file?)
 Defer to condition system?
 In discussion, formal proposal not yet submitted.

< 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 1/10 June 87)
 (Allow another argument to ~D etc to paramerize digits between commas)
 Ready for release.

FORMAT-NEGATIVE-PARAMETERS
 In discussion, formal proposal not yet submitted.
 Notes: is this an editorial policy question rather than
   an individual issue?

< FORMAT-OP-C (Version 5/ 11-Jun-87)
 (What does ~C do?)
 Version 5 passed X3J13/Jun87.

FUNCTION-TYPE (Version 5/ 16-Jun-87)
 (Change definition of FUNCTIONP, function type ...)
 Draft released 16-Jun-87.
 Discussed at X3J13, new proposal due.

GC-MESSAGES (version 1)
 (Control over unsolicited GC messages in typescript)
 merge with other controls for unsolicited messages?
 Not ready for release.
 Pitman volunteered to revise.

* GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
 (Environment argument for GET-SETF-METHOD)
 Version 4 conditionally passed X3J13/Jun87.
 Version 5 mailed 13-Jul-87 13:18:47 

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) 
 Pitman will release as report from cleanup + error committee.
 (Was not released).

< IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
 (Does IMPORT affect home package?)
 Version 5 passed X3J13/Jun87.

* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun 87)
 ( &KEY arguments not in keyword package?)
 Version 6 conditionally passed X3J13/Jun87.
 Examine wording and avoid "keyword argument" phrasing.
  Introduce phrase "a key argument" to denote arguments
  defined with &KEY ??

LOAD-TIME-EVAL (Version 1, 6 Jun 87)
 (New function/macro/special form for evaluation when 
 compiled file is loaded?)
 Not ready for release.
 Deferred to compiler committee?

MACRO-FUNCTION-ENVIRONMENT 
 (Add environment argument to MACRO-FUNCTION?)
 From ENVIRONMENT-ARGUMENTS
 Formal proposal not yet submitted.
 Masinter will extract from environment-arguments

* PATHNAME-STREAM (Version 2)
 (PATHNAME only works on file streams)
 Version 2 conditionally passed X3J13/Jun 87
 Needs revision to clarify "file" = "opened with open"
  (there are some non-file devices which have pathnames) 

PATHNAME-SYMBOL (Version 2)
 (Do symbols automaticly coerce to pathnames?)
 Not ready for release.
 Moon will revise, extend language, clarify
   which functions are affected, etc.

PEEK-CHAR-READ-CHAR-ECHO (Version 1)
 (character interaction with echoing on terminal)
 Not ready for release.
 Pitman will revise & resubmit.

< PRINC-CHARACTER (Version 3)
 (PRINC behavior on character objections)
 Version 3 passed X3J13/Jun87.

PROCLAIM-LEXICAL  (Version 1)
 (add LEXICAL proclaimation, default binding type for
  undeclared free variables)
 Not ready for release.
 Rees & Moon will revise & resubmit. Rees says he won't.
 David?

PROMPT-FOR (Version 1)
 (add new function which prompts)
 Not ready for release.
 Tabled indefinitely.

PUSH-EVALUATION-ORDER
 (What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
 In discussion, formal proposal not yet submitted. 
 Need volunteer to submit.

REQUIRED-KEYWORD-ARGUMENTS
 (Syntax for keyword arguments which must be supplied?)
 In discussion, formal proposal not yet submitted.
 Table indefinitely.

REMF-DESTRUCTION-UNSPECIFIED (Version 1)
 (How does REMF affect its arguments?)
 Not ready for release.
 Pitman will revise & resubmit.

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
 (FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
 In discussion, no clear consensus
 Not ready for release.
 Pitman will revise & resubmit.

SHARPSIGN-BACKSLASH-BITS
 (What does C-META-H-X mean?)
 Not ready for release.
 Forward to Linden for character proposal?

SHARPSIGN-PLUS-MINUS-NUMBER
 (Is #+68000, #-3600 allowed?)
 Not ready for release.
 Pitman will revise & resubmit.

SHARPSIGN-PLUS-MINUS-PACKAGE
 (What package are *features* in?)
 Not ready for release.
 Pitman will revise & resubmit.

SPECIAL-FORM-SHADOW
 (Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
 In discussion, no formal proposal submitted.
 Send to macro committee?

TAILP-NIL
 (Operation of TAILP given NIL)
 Not ready for release.
 Masinter will revise & resubmit.

UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
 (GO out of UNWIND-PROTECT clauses.)
 Not ready for release.
  Gabriel will revise & resubmit.

∂15-Jul-87  1329	Masinter.pa@Xerox.COM 	Issue: Pathname-subdirectory-list    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 15 Jul 87  13:29:01 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 15 JUL 87 13:27:05 PDT
Date: 15 Jul 87 13:24 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: Pathname-subdirectory-list
To: cl-cleanup@sail.stanford.edu
cc: Ghenis.pasa@Xerox.COM
Message-ID: <870715-132705-3165@Xerox>

This arrived in my mailbox before the X3J13 meeting. While I suspect
there may be some alternative proposals, and perhaps some other
important related issues, this seems like a good way to introduce the
topic.

!

ISSUE: (PATHNAME-SUBDIRECTORY-LIST)

REFERENCES: CLtL pages 409 - 418

CATEGORY: ADDITION
  
EDIT HISTORY: Version 1 by Ghenis.pasa@Xerox.com, 06/18/87

PROBLEM DESCRIPTION:

It is impossible to write PORTABLE code that can produce a pathname
based on directory plus SUBDIRECTORY information. If the directory used
is not a root, then the string provided must contain OS-specific
separators. This defeats the purpose of having an abstraction like
pathname. Specifying a subdirectory RELATIVE to the current default is
possible but also inconvenient and non-portable.

This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.


PROPOSAL (PATHNAME-SUBDIRECTORY-LIST:ALLOW): 

Add a :SUBDIRECTORIES field to pathnames, to store a list of strings.

The string form of a pathname can be obtained by using the appropriate
OS-specific separator and end-delimiters.
Require global variables called LISP:*HOST-OS-ALIST* and
LISP:*DEFAULT-OS* to provide the information needed to assemble
namestrings correctly


TEST CASE (desired behavior): 

	>(defparameter LISP:*HOST-OS-ALIST*
		'(("vmsvax" . "vms") ("unixvax" . "unix"))

	>(defparameter LISP:*DEFAULT-OS* "msdos")

	>(defvar vmspath
		(make-pathname :host "vmsvax"
		 			:directory "smith"
		 			:sudirectories '("lisp") 
					:name "test"
		 			:type "lsp"))

	>(defvar localpath 
		(make-pathname :directory "smith" 			
					:sudirectories '("lisp")
 					:name "test"
 					:type "lsp"))

	>(namestring vmspath)
	"{vmsvax}[smith.lisp]test.lsp"

	>(namestring localpath)
	"c:\smith\lisp\test.lsp"


RATIONALE:

Pathnames are an abstraction meant to deal with the common notions in
file systems. Subdirectories exist in most operating systems. Common
Lisp must provide a standard way of dealing with subdirectories for
pathnames to be truly useful.


CURRENT PRACTICE:

CLtL acknowledges this problem and declares it to be a system dependent
issue.


ADOPTION COST:

This should be a simple addition to implement.


BENEFITS: 

Adding a :SUBDIRECTORIES field to pathnames would make the abstraction
completely system-independent. Relative pathnames could be trivially
specified by pathnames lacking a :DIRECTORY field.


CONVERSION COST: This is an upwards-compatible addition.


AESTHETICS:

Adding a :SUBDIRECTORIES field to pathnames would make the abstraction
completely system-independent.

DISCUSSION: >>Additional arguments, discussions, endorsements,
  testimonials, etc. should go here.<<

∂16-Jul-87  1714	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: Pathname-subdirectory-list
Received: from [192.10.41.144] by SAIL.STANFORD.EDU with TCP; 16 Jul 87  17:14:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 194405; Thu 16-Jul-87 20:14:29 EDT
Date: Thu, 16 Jul 87 20:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: Pathname-subdirectory-list
To: Masinter.pa@Xerox.COM, Ghenis.pasa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <870715-132705-3165@Xerox>
Message-ID: <870716201416.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 15 Jul 87 13:24 PDT
    From: Masinter.pa@Xerox.COM

    PROBLEM DESCRIPTION:

    It is impossible to write PORTABLE code that can produce a pathname
    based on directory plus SUBDIRECTORY information. If the directory used
    is not a root, then the string provided must contain OS-specific
    separators. This defeats the purpose of having an abstraction like
    pathname. Specifying a subdirectory RELATIVE to the current default is
    possible but also inconvenient and non-portable.

    This problem is even worse for programs running on machines on a network
    that can retrieve files from multiple hosts, each using a different OS
    and thus a different subdirectory delimiter.

I agree with the problem description.  We've been dealing with heterogeneous
network for quite some time and have run into the same thing.

    PROPOSAL (PATHNAME-SUBDIRECTORY-LIST:ALLOW): 

    Add a :SUBDIRECTORIES field to pathnames, to store a list of strings.

Adding a new field as a way of solving this problem doesn't make sense.
Subdirectories are a structuring of the existing directory field, they are
not a new -independent- aspect of a pathname.

The solution to this problem that Symbolics has used for years works
quite well.  The directory is a structured field whose value is returned
as a list of strings, one string for each subdirectory level.  In
addition to strings, in our system we allow certain keywords in the
list, enumerated below.  Note that this general approach is the solution
suggested by CLtL itself, page 412 about 3/4 of the way down the page;
thus the only reason to change the language would be if we want to force
all implementations to use the same representation of structured
directories, which might be difficult if some implementation uses a
strange file system with a directory feature we haven't thought of.

When constructing a pathname, either a list of strings, or a single
string containing host-dependent delimiters, is accepted.  To retrieve a
string containing host-dependent delimiters, the existing
DIRECTORY-NAMESTRING function is used.

In case those keywords aren't self-evident, here are some examples. 
Vixen is a Unix, presumably everyone is familiar with Unix pathname
syntax.

(make-pathname :host "vixen"
	       :directory '("foo" "bar")) => #P"VIXEN:/foo/bar/"
(make-pathname :host "vixen"
	       :directory '(:relative "bar")) => #P"VIXEN:bar/"
(make-pathname :host "vixen"
	       :directory '(:relative :up "bar")) => #P"VIXEN:../bar/"
(make-pathname :host "vixen"
	       :directory '(:relative :up :up "bar")) => #P"VIXEN:../../bar/"
(make-pathname :host "vixen"
	       :directory '("foo" :wild "bar")) => #P"VIXEN:/foo/*/bar/"

I can't show you :wild-inferiors on Unix, because Unix is too simple
and elegant to have such useful features, so I'll use VMS:

(make-pathname :host "dumbo"
	       :directory '("foo" :wild "bar")) => #P"DUMBO:[foo.*.bar]"
(make-pathname :host "dumbo"
	       :directory '("foo" :wild-inferiors "bar")) => #P"DUMBO:[foo...bar]"

The name of the VMS host is not intended to be particularly pejorative, all of our
Vaxes are named after flying critters.

∂16-Jul-87  1730	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)  
Received: from [192.10.41.144] by SAIL.STANFORD.EDU with TCP; 16 Jul 87  17:27:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 194407; Thu 16-Jul-87 20:19:38 EDT
Date: Thu, 16 Jul 87 20:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GET-SETF-METHOD-ENVIRONMENT (Version 5)
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870713-131840-2151@Xerox>
Message-ID: <870716201931.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 13 Jul 87 13:18 PDT
    From: Masinter.pa@Xerox.COM

    This issue passed conditionally. In this version, I  changed  the last
    paragraph of the proposal,  and attempted to add a test case. I hope
    that I did not spoil the intent. 

The new version looks okay to me.

∂20-Jul-87  2130	edsel!bhopal!jonl@labrea.stanford.edu 	Apropos case sensitive?   
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 20 Jul 87  21:30:44 PDT
Received: by labrea.stanford.edu; Mon, 20 Jul 87 21:26:35 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA05223; Fri, 17 Jul 87 11:45:06 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA00220; Fri, 17 Jul 87 11:49:11 PDT
Date: Fri, 17 Jul 87 11:49:11 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8707171849.AA00220@bhopal.edsel.uucp>
To: labrea!vrotney%venera.isi.edu@labrea.stanford.edu
Cc: labrea!Common-Lisp%sail@labrea.stanford.edu,
        labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: vrotney@venera.isi.edu's message of Tue, 14 Jul 87  19:45:12 PDT <8707150245.AA03095@hpai00>
Subject: Apropos case sensitive?

[Note: LUCIDites are now using another mail gateway: typical address is:
       edsel!jonl@labrea.stanford.edu]

Our reasoning here at Lucid was similar to what you came up with -- namely
that the language of CLtL, p. 443, very strongly implied the same semantics
of macthing as the default for SEARCH, which is an EQL, rather than an
EQUALP, test.  

Many of us also felt the need so strongly for a case-insensitive apropos 
that Lucid Common Lisp actually has two such functions hidden inside it:
    lucid::case-insensitive-apropos
    lucid::case-insensitive-apropos-list
but they will probably be "shaken" out in the delivered 2.1 beta images.  

I feel that this issue should be presented to the "cleanup" sub-committee
of the X3J13 standards committee.  Perhaps SEF can prod Steve Handerson 
into writing up a proposal to them?  Lucid might feel impelled to "expose"
this hidden function if the committe were inclined towards the proposal.

By the way, there are some other issues about apropos that might need 
"cleaning up", some of which were discussed on this list a couple of 
years ago (for "couple" mabye equal to one).  For example, the 
documentation uses the term "available symbols", but in at least one 
instance, it ought to use "accessible symbols", for conformity to 
chapter 11 on packages.  Also, the scope of do-all-symbols has been 
questioned by some; there have been at least two proposals on it:

  (1) to add a new "function" called, say do-most-symbols, that excluded
      certain packages

  (2) to add a global variable (or a special variable) called, say,
      *all-symbols-exclusions* which is a list of packages which the
      several "all-symbols" functions would skip [e.g., do-all-symbols,
      find-all-symbols, apropos, case-insensitive-apropos, etc]


-- JonL --

∂23-Jul-87  1735	Masinter.pa@Xerox.COM 	Issue: LOAD-TIME-EVAL (Version 2)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 87  15:50:20 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUL 87 15:50:14 PDT
Date: 23 Jul 87 15:49 PDT
From: Masinter.pa@Xerox.COM
to: cl-cleanup@Sail.stanford.edu
Subject: Issue: LOAD-TIME-EVAL (Version 2)
Message-ID: <870723-155014-1175@Xerox>

The following from Jim Kempf:

Larry:

	I've modified the proposal for LOAD-TIME-EVAL along the lines
suggested by Dave Moon and am resubmitting it. I'll keep the name of
the proposal at LOAD-TIME-EVAL, although LOAD-TIME-CONSTANT, as suggested
by Dave is probably a more appropriate name. SHARP-COMMA-SPECIAL-FORM
seems pretty much to be out, since the new proposal is for a functional
interface, rather than a special form.

	Note that Dave's proposal will require more extensive modifications
in our system than a macro or special form; however, I believe it is
more elegant, since it avoids introducing a new special form (one of
the original goals of Common Lisp), and therefore more appropriate.

			Jim Kempf	kempf@hplabs.hp.com

!

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.

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

(MAKE-LOAD-TIME-EVAL <quoted form> &ENVIRONMENT env) : function

When processed by the interpreter or when encountered during evaluation
of the COMPILE function, the <quoted form> is evaluated once (and only
once) and the result is returned. When processed during a file
compilation, arrangement is made for the <quoted form> to be
evaluated when the compiled file is loaded, and the result returned.
Note that determining when file compilation is occurring and the details
of arranging for deferral of further processing until compiled
file load time are necessarily implementation dependent.


Test Case: 

(defmacro print-load-date (&environment env)
  `(quote ,(make-load-time-eval '(format T "~A~%" (get-date) env))))

When interpreted or processed during invocation of COMPILE, this
macro expands into code which  prints the return value of the GET-DATE 
function (presumed, for purposes of this example, to be a human 
readable date) to *STANDARD-OUTPUT*. When macroexpanded during a
file compilation, printing is deferred until the compiled file is
loaded.

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


∂23-Jul-87  1735	Masinter.pa@Xerox.COM 	Status, clarification list, members  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 23 Jul 87  15:54:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 JUL 87 15:54:24 PDT
Date: 23 Jul 87 15:54 PDT
From: Masinter.pa@Xerox.COM
Subject: Status, clarification list, members
To: cl-cleanup@Sail.stanford.edu
Message-ID: <870723-155424-1184@Xerox>

First, I want to apologize again for the delay in getting out the list
of clarifications & issues. I feel like it is important to merge in the
discussion with the work Scott Fahlman did in January of this year.  I'm
still working on this list.

I've added Dieter Kolb, Siemens, Germany to the distribution list.
Siemens has a mail connection to Xerox, and Dieter can get arpanet mail
addressed to cl-cleanup, but, due to some technical and administrative
problems,  I will have to forward his mail to the distribution list.

I will be adding another EuLisp committee member to cl-cleanup as well.
Part of our goal is to make sure that the EuLisp community is well
represented in the cleanup process.

∂24-Jul-87  1024	KMP@STONY-BROOK.SCRC.Symbolics.COM 	OPEN-KEYWORDS 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 87  10:24:42 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 198555; Fri 24-Jul-87 13:25:34 EDT
Date: Fri, 24 Jul 87 13:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: OPEN-KEYWORDS
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870724132524.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:		OPEN-KEYWORDS
References:	Pages 420-422
Category:	CHANGE
Edit history:	Revision 1 by Skona Brittain 07/17/87

Problem Description:

  The :if-exists and :if-does-not-exist arguments interact, but keyword
  arguments should generally be orthogonal.

Proposal (OPEN-KEYWORDS:ORTHOGONAL):

  Delete the following phrases from the first 2 paragraphs on page 422:
  ", or if the :if-exists argument is :overwrite or :append" and
  ", and the if-exists argument is anything but :overwrite or :append"

Test Case:

  The following piece of code causes an error to be signaled:
  (open "test" :direction :output :if-exists :overwrite)
  if a file named "test" -doesn't- already exist.
  With the change in this proposal, it wouldn't be an error.

Rationale:

  As is clear from the test case example, a user might want to specify
  that a certain action get taken in the case that a file already
  exists, without affecting what happens in the case that it doesn't
  exist.  There is no good reason for the two cases to affect each
  other.

Current Practice:



Adoption Cost:

  Slight.

Benefits:

  More sensible, easier to understand, more efficient to use and to
  implement.

Conversion Cost:

  Slight, automatable.

Esthetics:

  Keyword arguments are supposed to be orthogonal, thus this deviation
  is unaesthetic.  It being so contrary to intuition makes it particularly
  difficult for new LISP users to grasp.

Discussion:


∂24-Jul-87  1038	KMP@STONY-BROOK.SCRC.Symbolics.COM 	Mail from Skona Brittain
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Jul 87  10:38:35 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 198567; Fri 24-Jul-87 13:39:24 EDT
Date: Fri, 24 Jul 87 13:39 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Mail from Skona Brittain
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870724133919.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

The OPEN-KEYWORDS proposal which I just sent arrived in my hardcopy mailbox
today. I passed it through completely unedited; in fact, I didn't have time
to read it while I was typing. I'll comment later when I've had time.

There was also a cover letter that said:

    ... I still have not been able to do much of anything with my account.
    I tried to send mail but kept getting "no such local user" messages,
    even when just directly responding to a test message from a non-local
    friend. Nor have i received any X3-J13 mail at all yet. So if you want
    to respond to this, I would appreciate your trying my netmail address,
    but if your mail gets returned, please use [P.O. Box 747, Santa Barbara,
    CA 93102; (805) 963-3412].

    Regarding the order of arguments' evaluation, as in the 
    push-evaluation-order proposal, I still believe that this is specified in
    CLtL. I mentioned the reference on page 97 to "the usual left-to-right 
    order in which the various subforms are evaluated" but have since found
    a less oblique one: the entire last half of page 99.

    It is my impression that there needs to be a clarification of the
    effect of *print-level* and *print-length*, so if this impression is
    correct, I will volunteer to write it up. Basically, there seems to be a
    confusion about whether it is the actual components of the object that
    count or what the object looks like when printed in list notation. For
    example, the levels of 'x and (quote x) are considered different (cf
    page 373) but string-char arrays of rank >1 are affected by
    *print-length* even when printed in non-list notation (cf page 369).
    Other cases that are affected by this distinction include
    - a structure with n components has 2n+1 elements in its printed list
    representation
    - nil vs. ()
    - a rank 0 array has a component but prints with no parentheses whereas
    a 0xN array has 2 levels of parens and no components, etc.
    Since I am obviously not as well-qualified as the rest of the
    clean-up committee to judge such issues, and since I don't have access
    to any other preliminary feedback, there does not seem to be much point
    in my proceeding with writing up something like this until further
    notice.
    
    A suggestion for a change that I have is that some of the defstruct
    arguments be strings instead of symbols, but I also don't know if
    there's any point in entertaining it.

    I was under the impression at the meeting Monday that thecleanu-up
    committee was going to suggest setting up several other committees,
    including one on the file systems handling, but when I reminded Larry on
    Wednesday, he said there weren't any that hadn't already been set up, so
    I am unsure of the status of the situation regarding a file
    subcommittee. ...


∂27-Jul-87  1005	KMP@STONY-BROOK.SCRC.Symbolics.COM 	APPEND-DOTTED 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Jul 87  10:05:12 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 199647; Mon 27-Jul-87 13:02:54 EDT
Date: Mon, 27 Jul 87 13:02 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: APPEND-DOTTED
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870727130240.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        APPEND-DOTTED
References:   APPEND (p268)
Category:     CHANGE/CLARIFICATION
Edit history: 27-Jul-87, Version 1 by Pitman
Status:	      For Internal Discussion

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.

Proposal (APPEND-DOTTED:REPLACE):

  Define that the cdr of the last cons in any but the last list given to
  append is discarded (whether NIL or not) when constructing the new 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.

Test Case:

  (APPEND '(A B C . D) '()) => (A B C)		;Proposed

  [Note that (COPY-LIST '(A B C . D)) would still return (A B C . D).]

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

Adoption Cost:

  Technically, the change should be relatively small for those
  implementations which don't already implement it. However:

  If there are any implementations which have microcoded APPEND incompatibly,
  the small change may nevertheless be somewhat painful.

  Some implementations may have optimized their APPEND 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.

Benefits:

  Since non-lists are allowed as a last argument and since APPEND can
  therefore produce dotted lists, some readers may have (incorrectly)
  assumed that APPEND 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.

Conversion Cost:

  This change is "upward compatible".

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:

  KMP supports the proposed extension.

∂27-Jul-87  1754	FAHLMAN@C.CS.CMU.EDU 	APPEND-DOTTED
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 87  17:54:08 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 27 Jul 87 20:54:00-EDT
Date: Mon, 27 Jul 1987  20:53 EDT
Message-ID: <FAHLMAN.12321826393.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: APPEND-DOTTED
In-reply-to: Msg of 27 Jul 1987  13:02-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


This looks good to me.

-- Scott

∂27-Jul-87  1802	FAHLMAN@C.CS.CMU.EDU 	[Fahlman: Iteration standard]    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 27 Jul 87  18:02:42 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 27 Jul 87 21:02:34-EDT
Date: Mon, 27 Jul 1987  21:02 EDT
Message-ID: <FAHLMAN.12321827954.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: [Fahlman: Iteration standard]


This is not really cleanup committee business.  I just thought that it
might be of interest to some of you...

Date: Thursday, 23 July 1987  21:15-EDT
From: Scott E. Fahlman <Fahlman>
To:   loop-groop%clam at SUN.COM
cc:   fahlman
Re:   Iteration standard

OK, apparently this is the proper address for iteration discussions.
Here's what I wanted to say (probably an anticlimax at this point):

In the past, I have always been a vocal opponent of adopting the MIT
LOOP macro, or anything very close to it, as a part of the Common Lisp
standard.  I think that the basic functionality of LOOP is OK, and I've
got no real problem with its lack of a clean unifying abstraction; my
objection was that the cute, non-Lispy, pseudo-English infix/keyword
syntax was confusing and not in keeping with the rest of the language or
the direction in which Lisp should be moving.  My hope was that if we
stalled this decision for a while, someone would come up with something
better and that that "something better" would catch on in some
significant segment of the community.  (This strategy turned out to be a
good one with respect to object-oriented programming and old-style
flavors.)

Well, I've mellowed on this.  Personally, I would still rather see
something like

(loop (for i 0 100 2)
      (while (non-prime-p (foobar i))
      (collect (flowers-in-may))
      (finally (print *famous-last-words*)))

than the non-parenthesized run-on sentence equivalent, but we've been
hung up on this difference of opinion for five years and I'm ready to
throw in the towel.  Nothing else has caught on, and in the meantime
LOOP has consolidated its position and started to spread.  It IS better
than nothing.  The people who use it seem to like it.  When
pretty-printed properly it is readable enough -- I can blur my eyes and
pretend that the missing parens are there.

So, speaking only for myself, I would be willing to accept and even
support LOOP or something very similar as long as (1) it is cleanly
defined and (2) someone provides a portable, efficient public-domain
implementation.  In my view, it's time to settle this and move on.

Of course, I can't speak for the other people who still find LOOP syntax
disgusting.  Maybe some of the others are ready to compromise as well.
I was discussing this with Stan Shebs of Utah -- another former LOOPS
hater, probably because he was a fan of PSL's FOR macro -- and he was
also ready to bow to the inevitable.  Those who favor a more uniform and
principled approach to the whole iteration business -- the fans of LetS,
for example -- may be harder to please.

-- Scott

∂30-Jul-87  1129	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue KEYWORD-ARGUMENT-NAME-PACKAGE   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 30 Jul 87  11:28:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 202848; Thu 30-Jul-87 14:29:55 EDT
Date: Thu, 30 Jul 87 14:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue KEYWORD-ARGUMENT-NAME-PACKAGE
To: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <870713-141108-2238@Xerox>
Message-ID: <870730142947.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 13 Jul 87 14:05 PDT
    From: Masinter.pa@Xerox.COM

    * KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun 87)
     ( &KEY arguments not in keyword package?)
     Version 6 conditionally passed X3J13/Jun87.
     Examine wording and avoid "keyword argument" phrasing.
      Introduce phrase "a key argument" to denote arguments
      defined with &KEY ??

In some CLOS stuff I'm writing today, I'm using the terms "positional
argument" and "named argument".  Positional arguments are received by
required and optional parameters, while named arguments are received
by &key parameters.  &rest parameters can receive either kind of argument.

I don't have time to revise the proposal today, but perhaps I can do
so along these lines later, if people agree that this is a good
terminology.

∂30-Jul-87  1145	FAHLMAN@C.CS.CMU.EDU 	Issue KEYWORD-ARGUMENT-NAME-PACKAGE   
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 30 Jul 87  11:44:56 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 30 Jul 87 14:44:49-EDT
Date: Thu, 30 Jul 1987  14:44 EDT
Message-ID: <FAHLMAN.12322545615.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 KEYWORD-ARGUMENT-NAME-PACKAGE
In-reply-to: Msg of 30 Jul 1987  14:29-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


Seems like a good terminology to me, though you'll have to define your
terms at the start of the proposal so that nobody has to guess exactly
what you mean.

-- Scott

∂30-Jul-87  1717	Masinter.pa@Xerox.COM 	Re: Issue KEYWORD-ARGUMENT-NAME-PACKAGE   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 30 Jul 87  17:16:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 JUL 87 17:16:56 PDT
Date: 30 Jul 87 17:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue KEYWORD-ARGUMENT-NAME-PACKAGE
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Thu, 30 Jul 87 14:29 EDT
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <870730-171656-1501@Xerox>

 

While I think that "positional" and "named" are good ways of talking
about the different kinds of arguments, and that "key arguments" is
awkward, I don't think it is necessary for you to spend your time
rewriting the  proposal KEYWORD-ARGUMENT-NAME-PACKAGE, which doesn't
make any recommendations about terminology in the standard; rather, it
just uses it locally.

I would like to see a set of "terminology" recommendations for the spec
gathered and passed by X3J13; there are a number of other things which
have passed through here that would belong in it. I don't think they fit
into the standard form for language changes (since the considerations
are different, e.g., "current practice" might refer to existing
textbooks and programming language literature).

∂31-Jul-87  1833	edsel!bhopal!jonl@labrea.stanford.edu 	Issue KEYWORD-ARGUMENT-NAME-PACKAGE 
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 31 Jul 87  18:33:28 PDT
Received: by labrea.stanford.edu; Fri, 31 Jul 87 18:22:00 PDT
Received: from bhopal.edsel.uucp by edsel.uucp (3.2/SMI-2.0)
	id AA04329; Fri, 31 Jul 87 18:22:15 PDT
Received: by bhopal.edsel.uucp (3.2/SMI-3.2)
	id AA06397; Fri, 31 Jul 87 18:19:33 PDT
Date: Fri, 31 Jul 87 18:19:33 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8708010119.AA06397@bhopal.edsel.uucp>
To: labrea!cl-cleanup%sail@labrea.stanford.edu
In-Reply-To: David A. Moon's message of Thu, 30 Jul 87 14:29 EDT <870730142947.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue KEYWORD-ARGUMENT-NAME-PACKAGE


I too like this terminology, and think that changing it now is an important
thing to do, despite the five years of "keyword arguments."

By the way, as an English phrase, "&key parameters" leaves me a bit cold.
How about "positional parameters" and "named parameters" , to parallel
"positional arguments" and "named arguments"?

-- JonL --

∂05-Aug-87  1931	Moon@STONY-BROOK.SCRC.Symbolics.COM 	APPEND-DOTTED
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 5 Aug 87  19:30:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 207665; Wed 5-Aug-87 21:35:47 EDT
Date: Wed, 5 Aug 87 21:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: APPEND-DOTTED
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870727130240.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <870805213544.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

I approve.

∂14-Aug-87  1651	unido!ztivax!kolb@seismo.CSS.GOV 	Redefinition of system functions    
Received: from seismo.CSS.GOV by SAIL.STANFORD.EDU with TCP; 14 Aug 87  16:51:10 PDT
Received: from unido.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP 
	id AA13396; Fri, 14 Aug 87 19:51:00 EDT
Received: by unido.uucp with uucp; 
	  Fri, 14 Aug 87 16:01:15 +0100
From: "Dieter Kolb" <unido!ztivax!kolb@seismo.CSS.GOV>
Date: Fri, 14 Aug 87 15:06:16 -0100
Message-Id: <8708141406.AA04604@ztivax.uucp>
Received: by ztivax.uucp; Fri, 14 Aug 87 15:06:16 -0100
To: CL-Cleanup@sail.stanford.edu
Subject: Redefinition of system functions

Problem description:
CLtL allows the redefinition of functions exported from other packages. 
Unexperienced programmers may redefine a system function unintentional 
which may result into an inconsistent state of the system and cause to 
abort.

This happens, for example, if a beginner follows the CL introductory 
book "Essential LISP" by Anderson et.al. page 41 where an exercise asks 
to define a function make-list. After the redefinition of make-list the 
system crashs without returning a message that the function has been 
redefined.

CLtL only says that special forms can not be redefined. But this doesn't 
solve the general problem of redefining system functions.

Solution:
Redefinition of exported functions should stay allowed. However, some 
functions - especially all functions of the package LISP -  should be 
protected from redefinition. In the case a user tries to redefine such a 
function a confirmation should be required.

Protected user functions can be specified in a special list (look-up-
table, value of the variable *protected-functions-from-redefinition*). 
Functions from package LISP are protected per se and have not to be 
added into this list. 
There should be two functions to add and to remove an entry to/from this 
list:
protect-function-from-redefinition name
release-function-for-redefinition name

The only function involved in protecting functions from redefinition 
seems to be defun. Advising (in the sense of Interlisp) protected 
functions, however, should stay allowed. 


Dieter Kolb

∂14-Aug-87  2055	FAHLMAN@C.CS.CMU.EDU 	Redefinition of system functions 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 14 Aug 87  20:54:58 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 14 Aug 87 23:54:46-EDT
Date: Fri, 14 Aug 1987  23:54 EDT
Message-ID: <FAHLMAN.12326577897.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Dieter Kolb <unido!ztivax!kolb@SEISMO.CSS.GOV>
Cc:   CL-Cleanup@SAIL.STANFORD.EDU
Subject: Redefinition of system functions
In-reply-to: Msg of Fri 14 Aug 87 15:06:16 -0100 from Dieter Kolb <unido!ztivax!kolb at seismo.CSS.GOV>


If there are functions whose redefinition would destroy a particular
Lisp system, I wouldn't mind getting a warning and perhaps even a
correctable error from DEFUN if I am about to lose.  The set of
protected functions might include all of the built-in Common Lisp
functions, or it might be a small subset, depending on the details of
the implementation.

There must be a way to turn this protection off, however -- some people
know what they are doing and don't want Lisp to save them.  Advising is
one such case, patching over bugs in the built-in functions is another,
and turning a built-in function into a CLOS generic function so that new
behaviors can be added for new types is yet another (once we decide how
much of this will be allowed).

In any case, I think that such protection probably should be considered
an programming-environment issue that is left up to each implementor.
Is there any real need for a standard solution here?  I suppose we do
need to make clear that randomly modifying the built-in functions is not
something that is allowed in strictly legal Common Lisp programs.

-- Scott

∂24-Aug-87  1138	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: SHADOW-ALREADY-PRESENT (version 1)  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 24 Aug 87  11:38:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 219273; Mon 24-Aug-87 14:33:31 EDT
Date: Mon, 24 Aug 87 14:33 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SHADOW-ALREADY-PRESENT (version 1)
To: Cl-Cleanup@sail.stanford.edu
References: <8708241350.AA23968@ztivax.uucp>, <8708241451.AA28748@HADES.MIT.EDU>
Message-ID: <870824143300.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

Issue:         SHADOW-ALREADY-PRESENT

References:    CLtL p.186

Category:      CLARIFICATION

Edit history:  Moon 24 Aug 87 new issue (version 1)

Problem description:

The description of the SHADOW function can be interpreted as saying that
the function has no effect, if the symbol is already present in the
package.  This happens if the third sentence in the description ("then
nothing is done") is interpreted as applying to the entire description
rather than just to the fourth sentence.

Proposal SHADOW-ALREADY-PRESENT:WORKS:  The SHADOW function always adds
the symbol to the PACKAGE-SHADOWING-SYMBOLS list, even when the symbol is
already present in the package.

Test Case:

(make-package 'test-1)
(intern "TEST" (find-package 'test-1))
(shadow 'test-1::test (find-package 'test-1))
(assert (not (null (member 'test-1::test (package-shadowing-symbols
					   (find-package 'test-1))))))
(make-package 'test-2)
(intern "TEST" (find-package 'test-2))
(use-package 'test-2 (find-package 'test-1))	;should not error

Rationale:

Page 180 describes a name conflict problem that can occur when calling
the function USE-PACKAGE. The name conflict is between a symbol directly
present in the using package and an external symbol of the used package.
This name conflict may be resolved in favor of the symbol directly
present in the using package by making it a shadowing symbol.  For this
to work, SHADOW must add the symbol to the PACKAGE-SHADOWING-SYMBOLS list
even when it is already present in the package.

Current practice:

[I have not confirmed any of these myself except Symbolics --Moon]

Symbolics and Spice Lisp behave as proposed here.  Kyoto Common Lisp
behaves the other way.  Kolb implied, but did not state explicitly,
that Lucid Common Lisp and Xerox Common Lisp behave like KCL.  It seems
likely that we will find several implementations in each camp.

Adoption Cost:  It should be a one-line change in one function.

Cost of non-adoption: Inconsistency among implementations and lack of a
clear way to resolve the name conflict mentioned in Rationale.

Benefits: Consistency.

Conversion Cost: Technically this would be an incompatible change to
implementations that do not already behave as proposed, however it is
difficult to conceive of a user program that would require any
conversion to cope with the change.  Some users might want to remove
kludges that were only necessary to get around the misbehavior of
SHADOW.

Esthetics: The proposal would remove an unnecessary special case,
thus simplifying the language slightly.

Discussion:

The issue was raised by Dieter Kolb on the Common-Lisp mailing list.

It would be useless for SHADOW to fail to put a symbol that is already
present in the package onto the PACKAGE-SHADOWING-SYMBOLS list.  Moon
believes CLtL intended to describe what is being proposed, but
unfortunately used ambiguous language.

∂24-Aug-87  1808	FAHLMAN@C.CS.CMU.EDU 	Issue: SHADOW-ALREADY-PRESENT (version 1)  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 24 Aug 87  18:07:54 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 24 Aug 87 21:08:04-EDT
Date: Mon, 24 Aug 1987  21:08 EDT
Message-ID: <FAHLMAN.12329168991.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: SHADOW-ALREADY-PRESENT (version 1)
In-reply-to: Msg of 24 Aug 1987  14:33-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


I'm in favor of SHADOW-ALREADY-PRESENT:WORKS.
Thanks to Moon for writing this up so quickly.

-- Scott

∂27-Aug-87  1429	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: SHADOW-ALREADY-PRESENT (version 2)  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 27 Aug 87  14:28:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 222476; Thu 27-Aug-87 17:30:06 EDT
Date: Thu, 27 Aug 87 17:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SHADOW-ALREADY-PRESENT (version 2)
To: Cl-Cleanup@sail.stanford.edu
cc: Jon L White <edsel!bhopal!jonl@labrea.stanford.edu>
References: <870824143300.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870827172932.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

Issue:         SHADOW-ALREADY-PRESENT

References:    CLtL p.186

Category:      CLARIFICATION

Edit history:  Moon 24 Aug 87 new issue (version 1)
               Moon 27 Aug 87 incorporate suggestions from JonL (version 2)

Problem description:

The description of the SHADOW function can be interpreted as saying that
the function has no effect, if the symbol is already present in the
package.  This happens if the third sentence in the description ("then
nothing is done") is interpreted as applying to the entire description
rather than just to the fourth sentence.

SHADOW is said to take symbols as arguments, however only the print-name
is meaningful for this operation (that fact is already documented).

Proposal SHADOW-ALREADY-PRESENT:WORKS:

The SHADOW function always adds the symbol to the PACKAGE-SHADOWING-SYMBOLS
list, even when the symbol is already present in the package.  In addition,
the first argument is allowed to be or contain strings as well as symbols.
The specification "the print name of each symbol is extracted" is to be
modified accordingly.

Test Case:

(make-package 'test-1)
(intern "TEST" (find-package 'test-1))
(shadow 'test-1::test (find-package 'test-1))
(assert (not (null (member 'test-1::test (package-shadowing-symbols
                                           (find-package 'test-1))))))
(make-package 'test-2)
(intern "TEST" (find-package 'test-2))
(use-package 'test-2 (find-package 'test-1))    ;should not error

To test the use of strings in place of symbols, change the
third line of the test case to
(shadow "TEST" (find-package 'test-1))
Note the use of capital letters in the string.

Rationale:

Page 180 describes a name conflict problem that can occur when calling
the function USE-PACKAGE. The name conflict is between a symbol directly
present in the using package and an external symbol of the used package.
This name conflict may be resolved in favor of the symbol directly
present in the using package by making it a shadowing symbol.  For this
to work, SHADOW must add the symbol to the PACKAGE-SHADOWING-SYMBOLS list
even when it is already present in the package.

Since only the print name of a symbol argument is meaningful, a string
should also be accepted.  This is particularly useful to avoid problems
when compiling code in one package environment and loading it into a
slightly different package environment, where the symbol that was referred
to at compile time may not be present at load time.  This is particularly
important because the symbol referred to by the print name may be changed
by evaluation of the SHADOW form.  A close reading of CLtL shows that one
can already use (shadow '#:bar) in place of (shadow 'bar), to achieve much
the same effect as (shadow "BAR").  But the user should not have to play
such games, strings should be accepted.

Current practice:

[I have not confirmed any of these myself except Symbolics --Moon]

Symbolics and Spice Lisp add the symbol to the PACKAGE-SHADOWING-SYMBOLS
list, even when the symbol is already present in the package.  Kyoto Common
Lisp, Lucid Common Lisp, and Xerox Common Lisp ignore SHADOW when the
symbol is already present in the package.  It seems likely that we will
find several implementations in each camp.

SHADOW accepts strings in Symbolics Common Lisp.

Adoption Cost:

It should be two one-line changes in one function.

Cost of non-adoption:

Inconsistency among implementations and lack of a clear way to resolve the
name conflict mentioned in Rationale.

Benefits:

Consistency among implementations and fewer mysterious package problems.

Conversion Cost:

Technically this would be an incompatible change to implementations that do
not already behave as proposed, however it is difficult to conceive of a
user program that would require any conversion to cope with the change.
Some users might want to remove kludges that were only necessary to get
around the former misbehavior of SHADOW.

Esthetics:

The proposal would remove an unnecessary special case, thus simplifying the
language slightly.

Discussion:

The issue was raised by Dieter Kolb on the Common-Lisp mailing list.

It would be useless for SHADOW to fail to put a symbol that is already
present in the package onto the PACKAGE-SHADOWING-SYMBOLS list.  Moon
believes CLtL intended to describe what is being proposed, but
unfortunately used ambiguous language.

Epigram:

"Who knows what evil lurks in the hearts of men?"

∂29-Aug-87  1337	Masinter.pa@Xerox.COM 	[Dan Carnese <Carnese@SPAR-20.ARPA>: proposal] 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 29 Aug 87  13:36:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 29 AUG 87 13:36:54 PDT
Date: 29 Aug 87 13:36 PDT
From: Masinter.pa@Xerox.COM
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
To: cl-cleanup@sail.stanford.edu
cc: Carnese@SPAR-20.ARPA
Message-ID: <870829-133654-4656@Xerox>

I've given the name "EXPORT-COORDINATION" to this issue. I think this is
an interesting proposal. Comments? (Before Dan writes up a more formal
proposal?)



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

Return-Path:
<@SPAR-20.ARPA,@KATYDID.SPAR.CAS.SLB.COM:Carnese@SPAR-20.ARPA>
Received: from SPAR-20.ARPA by Xerox.COM ; 25 AUG 87 13:01:17 PDT
Received: from KATYDID.SPAR.CAS.SLB.COM (KATYDID.#Internet) by
SPAR-20.ARPA with TCP; Tue 25 Aug 87 12:59:13-PDT
Date: Tue, 25 Aug 87 12:59 PDT
From: Dan Carnese <Carnese@SPAR-20.ARPA>
Subject: proposal
To: masinter.pa
Message-ID: <870825125906.2.CARNESE@KATYDID.SPAR.CAS.SLB.COM>

Thanks for the information.  I didn't realize that proposals were
required
to be in such a detailed format but of course that makes sense.

I think the problem can be "symbolized" as
multiple-forms-for-exported-defined-symbols.  Its definition could be:

        Exporting a defined symbol currently requires two seperate
forms:
        one to give a value to the symbol and another to cause the
symbol
        to be on a package export list.  These two forms must be kept in
        sync as the program evolves.

The benefit would be:

        Explicit export lists could be eliminated in many cases.

The thrust of the discussion would be:

        This is an extremely straightforward addition, one which could
be
        implemented by macros that would simply expand to an export and
an
        existing definition form.  Only DEFSTRUCT* would involve actual
        programming, to process the additional defstruct and slot
options.

        The proposal does not completely eliminate the need for explicit
        calls to EXPORT for two reasons.   First, it is sometimes useful
to
        export symbols for which no definition forms are applicable,
e.g.,
        to be used as arguments to functions.  Second, explicit exports
of
        defined symbols are still needed in the following case.  Suppose
A
        and B are packages, A defines an external symbol F, and B uses
A.
        Suppose further that F appears in a form being read into package
B,
        and that this form is to be read before the definition of F is
        loaded.  In this case, an explicit export of F must occur, to
avoid
        F being inappropriately interned in B.

Does this sound reasonable?

-- Dan


     ----- End Forwarded Messages -----

∂29-Aug-87  1439	RAM@C.CS.CMU.EDU 	[Dan Carnese <Carnese@SPAR-20.ARPA>: proposal] 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 29 Aug 87  14:39:04 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Sat 29 Aug 87 17:40:55-EDT
Date: Sat, 29 Aug 1987  17:40 EDT
Message-ID: <RAM.12330441992.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   Masinter.pa@XEROX.COM
Cc:   Carnese@SPAR-20.ARPA, cl-cleanup@SAIL.STANFORD.EDU
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
In-reply-to: Msg of 29 Aug 1987  16:36-EDT from Masinter.pa at Xerox.COM


The idea has obvious intuitive appeal, since people tend to think of
exporting definitions rather than names.  Unfortunately, I think that
there is likely to be some messy semantics due to name resolution
happening at read time and the implicit package manipulation happening
later on.  The semantics of package manipulation with respect to
compile-file/load is currently not defined.  [Except perhaps in some
vague language that suggests the semantics of loading the source are
preserved, which is clearly wrong.]  It is certainly naive to suppose
that a macro can expand into arbirary package manipulation code and
"the right thing" will happen.

I think that exporting symbols from the current package happens to be
safe as long as all the code in a file is restricted to one package,
but I certainly don't want to have to figure out which of all possible
kinds of package manipulation will break what possible reasonable
compiler organizations.

You should also be careful that you aren't thinking of this issue in
terms of "top-level defining forms", since I am convinced that the
notion of a "top-level form" is semantically bankrupt.  Although some
forms are most often used at "top-level" (however defined), the
semantics of those forms are a result of its evaluation, and a form can
be evaluated anywhere.  Consider the semantics of:
  (if <whatever>
      (defun-exported foo ...))

Consider the possible range of implementations such as "compilers" and
"interpreters".  Is Foo {always | never | sometimes} exported at 
{read | macroexpand | compile | load | run} time?

I currently favor requiring all package manipulation to be done at the
head of the file.  This has the advantage that it allows compilers and
editors to find all stuff pertinent to read-time semantics without
having to go through the motions of compiling the entire file.

Of course, it would be possible to have an automatic exporting feature
without allowing users to have package-hacking macros.

  Rob

∂02-Sep-87  1926	CARNESE@SPAR-20.ARPA 	Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]   
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 2 Sep 87  19:26:25 PDT
Date: Wed 2 Sep 87 19:25:58-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
To: Ram@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12330441992.BABYL@>
Message-ID: <12331542476.10.CARNESE@SPAR-20.ARPA>

Although not explicitly stated in the message Larry forwarded, the proposal
is for def...* forms that export the defined symbols from their packages.
Of course, your observations are valid about the non-clarity of the value
of *package* and of when a symbol is actually defined.  But they don't seem
directly relevant to this proposal, since they describe problems in the
current language definition.  So long as the export occurs just after the
cell is filled, I don't think we're adding to the existing murkiness.

-------

∂02-Sep-87  1952	FAHLMAN@C.CS.CMU.EDU 	[Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 2 Sep 87  19:52:23 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 2 Sep 87 22:52:27-EDT
Date: Wed, 2 Sep 1987  22:52 EDT
Message-ID: <FAHLMAN.12331547288.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To:   Dan Carnese <CARNESE@SPAR-20.ARPA>
Cc:   cl-cleanup@SAIL.STANFORD.EDU
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
In-reply-to: Msg of 2 Sep 1987  22:25-EDT from Dan Carnese <CARNESE at SPAR-20.ARPA>


I'll stay out of the argument about whether it is a good idea to scatter
the exports (implicit or explicit) all through the file, rather than
requiring all the exports to occur at the start of each file.  This is
tied up with some big questions about the compiler, and it can't really
be settled in isolation.

Just for the record, though, I would strongly oppose any proposal to use
DEF...* for naming the def-exporting forms.  The last thing we need in
this language is to start sticking stars and other meaningless
decorations on the end of symbols whenever we want to say "different in
some way that I know and you'll have to guess".  There's already some of
this kind of thing in the language, held over from other Lisps, but we
shouldn't extend the practice.

-- Scott

∂03-Sep-87  1118	RAM@C.CS.CMU.EDU 	[Dan Carnese <Carnese@SPAR-20.ARPA>: proposal] 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 3 Sep 87  11:17:57 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Thu 3 Sep 87 14:18:04-EDT
Date: Thu, 3 Sep 1987  14:17 EDT
Message-ID: <RAM.12331715786.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   Dan Carnese <CARNESE@SPAR-20.ARPA>
Cc:   cl-cleanup@SAIL.STANFORD.EDU
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
In-reply-to: Msg of 2 Sep 1987  22:25-EDT from Dan Carnese <CARNESE at SPAR-20.ARPA>


Actually, having the defining form export the symbol from its home
package is more problematic than exporting from the current package.
Consider a code fragment like:
    (in-package 'a :use '(lisp b))
    ...
    (defun-exported b::foo ...)
    foo

What package is the following "foo" in?  Obviously the DEFUN-EXPORTED
and the "foo" could be in the same form, so under some circumstances,
that "foo" couldn't possibly refer to B:FOO, yet if the compiler
happened to process the DEFUN-EXPORTED before the "foo" was read, then
it would be B:FOO. 

To say that these things are "just problems in the current language
definition" doesn't avoid the problem.  Adding new langauge features
is language design, and a language designer must consider how each
language feature will affect his ability to properly define the
language.  I am suggesting that this feature would significantly
complicate the language definition for what seems to me to be little
gain.

  Rob

∂04-Sep-87  1030	edsel!bhopal!jonl@labrea.stanford.edu 	[Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
Received: from LABREA.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 4 Sep 87  10:30:27 PDT
Received: by labrea.stanford.edu; Fri, 4 Sep 87 10:11:04 PDT
Received: from bhopal.edsel.com by edsel.uucp (3.2/SMI-2.0)
	id AA22223; Fri, 4 Sep 87 09:08:33 PDT
Received: by bhopal.edsel.com (3.2/SMI-3.2)
	id AA04816; Fri, 4 Sep 87 09:08:14 PDT
Date: Fri, 4 Sep 87 09:08:14 PDT
From: edsel!bhopal!jonl@labrea.stanford.edu (Jon L White)
Message-Id: <8709041608.AA04816@bhopal.edsel.com>
To: labrea!Ram%C.CS.CMU.EDU@labrea.stanford.edu,
        labrea!Fahlman%C.CS.CMU.EDU@labrea.stanford.edu
Cc: labrea!CARNESE%SPAR-20.ARPA@labrea.stanford.edu,
        labrea!cl-cleanup%SAIL@labrea.stanford.edu
In-Reply-To: navajo!Ram@C.CS.CMU.EDU's message of Thu, 3 Sep 1987  14:17 EDT <RAM.12331715786.BABYL@>
Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]

One of the good qualities I liked about Mesa (the Xerox answer to Pascal)
was the way programmers were encouraged to write a "defs" file for every
"module" -- basically, this file declares the exportable items, along with 
their syntax (no code, however), and also mentions the importations (a bit 
like CL's REQUIRE).  I don't know how much of a pain it was for programmers 
to produce correct modules under this regimen, but it sure made it a heck 
of a lot easier to read someone else's code.

I, for one, in my regular work wind up reading a lot of other people's 
code; and most of my code is eventually read by other people.  Hence I
would prefer a direction for Common Lisp which facilitated the ability
to read other people's code, even at the expense of some programming
conveniences.  This means that having all the "7 extrememly randoms"
at the beginning of a file (except for PROVIDE) is a much better
solution than having them sprinkled around random other files in 
random other modules.

-- JonL --

∂04-Sep-87  1047	CARNESE@SPAR-20.ARPA 	Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]   
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 4 Sep 87  10:47:43 PDT
Date: Fri 4 Sep 87 10:15:49-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
To: Ram@C.CS.CMU.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12331715786.BABYL@>
Message-ID: <12331966613.10.CARNESE@SPAR-20.ARPA>


    Return-Path: <RAM@C.CS.CMU.EDU>
    Received: from C.CS.CMU.EDU by SPAR-20.ARPA with TCP; Thu 3 Sep 87 11:18:03-PDT
    Received: ID <RAM@C.CS.CMU.EDU>; Thu 3 Sep 87 14:18:04-EDT
    Date: Thu, 3 Sep 1987  14:17 EDT
    Message-ID: <RAM.12331715786.BABYL@>
    Sender: RAM@λλ
    From: Ram@C.CS.CMU.EDU
    To:   Dan Carnese <CARNESE@SPAR-20.ARPA>
    Cc:   cl-cleanup@SAIL.STANFORD.EDU
    Subject: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
    In-reply-to: Msg of 2 Sep 1987  22:25-EDT from Dan Carnese <CARNESE at SPAR-20.ARPA>


    Actually, having the defining form export the symbol from its home
    package is more problematic than exporting from the current package.
    Consider a code fragment like:
        (in-package 'a :use '(lisp b))
        ...
        (defun-exported b::foo ...)
        foo

    What package is the following "foo" in?  Obviously the DEFUN-EXPORTED
    and the "foo" could be in the same form, so under some circumstances,
    that "foo" couldn't possibly refer to B:FOO, yet if the compiler
    happened to process the DEFUN-EXPORTED before the "foo" was read, then
    it would be B:FOO. 

    To say that these things are "just problems in the current language
    definition" doesn't avoid the problem.  Adding new langauge features
    is language design, and a language designer must consider how each
    language feature will affect his ability to properly define the
    language.  I am suggesting that this feature would significantly
    complicate the language definition for what seems to me to be little
    gain.

      Rob

Sorry, but I'm still not clear on how this extension makes the situation
any more complicated.  What I understand you to be saying is that the
semantics of your example would not be well-defined in the case where these
are not top-level forms.  Of course, you're right.  But since any code
involving the new constructs can be expanded into existing constructs
(e.g., by replacing the defun-exported with a defun followed by an export),
the proposal doesn't introduce any new kinds of problematic situations.
Thus, it is difficult to argue that the language definition would be made
more complicated by having such expansions predefined.

With regard to the naming issue that Scott raised, the use of "-exported"
as a suffix seems quite reasonable.  I'm happy to accede to a change that
increases readability.
-------

∂21-Sep-87  1436	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: SETF-METHOD-FOR-SYMBOLS (version 1) 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Sep 87  14:36:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 238094; Mon 21-Sep-87 17:37:55 EDT
Date: Mon, 21 Sep 87 17:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
To: CL-Cleanup@sail.stanford.edu
Supersedes: <870921172903.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <870921173659.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

Issue:         SETF-METHOD-FOR-SYMBOLS

References:    CLtL pp. 105, 99

Category:      CHANGE

Edit history:  Version 1   Moon 21 Sep 87

Problem description:

The description of SETF in CLtL is inconsistent in that page 99
requires side-effects to be elaborated in left-to-right order,
while page 105 specifies a setf-method for symbols that makes
it impossible to implement this in some cases, such as the test
case given below (provided by Timothy Daly of IBM).

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

Test Case:

Given

 (setq r '(a 1 b 2 c 3))
 (setq s r)
 (setf (getf r 'b) (progn (setq r nil) 6))

what is the value of R and 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).

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 above.  Franz returns something else: r = nil and s = (a 1 b 6 c 3).

Symbolics plans to fix this in the next release.

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:

The opposite of what I just said.

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:

I wish CLtL did a much better job of explaining the philosophy of SETF,
and included some better examples of precisely what is meant by the
"`obvious' semantics" mentioned on page 99.  I will accept some of the
blame for this lack in the documentation. --Moon

∂21-Sep-87  1957	FAHLMAN@C.CS.CMU.EDU 	Issue: SETF-METHOD-FOR-SYMBOLS (version 1) 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Sep 87  19:56:53 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 21 Sep 87 22:57:14-EDT
Date: Mon, 21 Sep 1987  22:57 EDT
Message-ID: <FAHLMAN.12336528894.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: SETF-METHOD-FOR-SYMBOLS (version 1)
In-reply-to: Msg of 21 Sep 1987  17:36-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


I tried Daly's example in Spice Lisp, and it gave what Moon proposes as
the intuitive answer: both R and S end up with (A 1 B 6 C 3).  And in
the same Lisp, (get-setf-method 'foo) returns the values prescribed in
CLtL: nil nil (#:G1) (setq foo #:G1) foo.  So the statement in Moon's
proposal that Daly's example is impossible to implement with with this
set of values is false.  There might be other examples which dictate the
change in get-setf-method that Moon proposes, but this particular
case does not force the issue.

The trick here is that the get-setf-method value-set for Getf sets up
all of the necessary bindings, rather than doing this in the method for
a symbol:

(get-setf-method '(getf a b)) =>

(#:G1 #:G2)
(A B)
(#:G3)
(progn (setq #:G1 (%putf #:G1 #:G2 #:G3))
       (setq A #:G1)
       #:G3)
(getf #:G1 #:G2)

Is there some problem here I don't see?

For what it's worth, I get the following:

(setf (getf (nthcdr 2 r) 'b) (progn (setq r nil) 6))
r = nil, s = (a 1 b 6 c 3)

(setf (nthcdr 2 r) (progn (setq r nil) 6))
r= nil, s = (a 1 . 6)

I think that these values are right, since changing the tail of the old
value of R can't set anything back into R to override the explict SETQ.
Anyone disagree?  Our code gets no failures trying to setq the nthcdr of
nil, or whatever.

Unless I'm missing something, I would say that these examples shoot down
Moon's proposal in its current form.

-- Scott

∂22-Sep-87  0756	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: SETF-METHOD-FOR-SYMBOLS (version 1) 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Sep 87  07:55:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 238559; Tue 22-Sep-87 10:57:35 EDT
Date: Tue, 22 Sep 87 10:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-METHOD-FOR-SYMBOLS (version 1)
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12336528894.BABYL@C.CS.CMU.EDU>
Message-ID: <870922105646.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 21 Sep 1987  22:57 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    I tried Daly's example in Spice Lisp, and it gave what Moon proposes as
    the intuitive answer: both R and S end up with (A 1 B 6 C 3).  And in
    the same Lisp, (get-setf-method 'foo) returns the values prescribed in
    CLtL: nil nil (#:G1) (setq foo #:G1) foo.  So the statement in Moon's
    proposal that Daly's example is impossible to implement with with this
    set of values is false.  There might be other examples which dictate the
    change in get-setf-method that Moon proposes, but this particular
    case does not force the issue.

    The trick here is that the get-setf-method value-set for Getf sets up
    all of the necessary bindings, rather than doing this in the method for
    a symbol:

    (get-setf-method '(getf a b)) =>

    (#:G1 #:G2)
    (A B)
    (#:G3)
    (progn (setq #:G1 (%putf #:G1 #:G2 #:G3))
	   (setq A #:G1)
	   #:G3)
    (getf #:G1 #:G2)

    Is there some problem here I don't see?

Doesn't this only show that getf's setf-method is calling a private
copy of get-setf-method for the first argument, rather than recursively
calling the regular get-setf-method?  If not, how did it know that a
temporary variable needed to be bound to a?  Perhaps it just always
binds a temporary variable to any first argument; but then the difference
between the CLtL setf-method for variables and my proposed new one
is ignored by Spice Lisp in this case.

It's true that I shouldn't have said it was impossible to implement setf
correctly in the face of the setf-method prescribed by CLtL.  I should
have realized that an implementation was free to introduce more
temporary variables than the ones implied by the setf-method.  However,
consider this example, using the setf-method for ldb prescribed by CLtL
page 106:

(setq a 0)
(incf (ldb (byte 2 2) a) (setq a 2))

Does this leave a=8, a=10, or a=2?  I believe 8 is what is intended by
page 99's statement about order of evaluation of subforms.

Note that no arguments about an implementation having its own setf method
for ldb are relevant here.  If users are to be able to write hairy setf
methods in portable code, which I assume is a goal otherwise why did we
document all this stuff, then setf-methods written in the style of the
one CLtL gives for LDB have to work portably and produce equivalent effects
in all implementations.

    For what it's worth, I get the following:

    (setf (getf (nthcdr 2 r) 'b) (progn (setq r nil) 6))
    r = nil, s = (a 1 b 6 c 3)

    (setf (nthcdr 2 r) (progn (setq r nil) 6))
    r= nil, s = (a 1 . 6)

    I think that these values are right, since changing the tail of the old
    value of R can't set anything back into R to override the explict SETQ.

I agree.

    Anyone disagree?  Our code gets no failures trying to setq the nthcdr of
    nil, or whatever.

    Unless I'm missing something, I would say that these examples shoot down
    Moon's proposal in its current form.

Do you still think that after seeing my reaction above?  If so, I think we
need to back off and consider precisely what CLtL p.99 was supposed to be
saying.

∂22-Sep-87  0854	FAHLMAN@C.CS.CMU.EDU 	Issue: SETF-METHOD-FOR-SYMBOLS (version 1) 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 87  08:54:34 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 22 Sep 87 11:54:13-EDT
Date: Tue, 22 Sep 1987  11:54 EDT
Message-ID: <FAHLMAN.12336670332.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: SETF-METHOD-FOR-SYMBOLS (version 1)
In-reply-to: Msg of 22 Sep 1987  10:56-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


Well, here's our setf method for Getf.  It clearly is not using some
private method to get symbols right, but is using the standard setf
method for whatever the first form is.  It seems to me that the way it
is using the store variable from the first subform is fairly
straightforward, and doesn't introduce more temporaries than would be
needed under your scheme, but I could be wrong.

Can you show me the Getf method that would result from your proposed way
of handling the symbol values?  Is it significantly simpler or more
efficient?  When it comes to efficiency, I'd rather have a little extra
variable shuffling in Getf and places like that than in all setf's
involving a symbol destination.

(define-setf-method getf (place prop &optional default &environment env)
  (multiple-value-bind (temps values stores set get)
		       (get-setf-method place env)
    (let ((newval (gensym))
	  (ptemp (gensym))
	  (def-temp (gensym)))
      (values `(,@temps ,(car stores) ,ptemp ,@(if default `(,def-temp)))
	      `(,@values ,get ,prop ,@(if default `(,default)))
	      `(,newval)
	      `(progn (setq ,(car stores)
			    (%primitive putf ,(car stores) ,ptemp ,newval))
		      ,set
		      ,newval)
	      `(getf ,(car stores) ,ptemp ,@(if default `(,def-temp)))))))

-- Scott

∂22-Sep-87  0905	FAHLMAN@C.CS.CMU.EDU 	Issue: SETF-METHOD-FOR-SYMBOLS (version 1) 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 87  09:05:07 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 22 Sep 87 12:05:27-EDT
Date: Tue, 22 Sep 1987  12:05 EDT
Message-ID: <FAHLMAN.12336672387.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: SETF-METHOD-FOR-SYMBOLS (version 1)
In-reply-to: Msg of 22 Sep 1987  10:56-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


Maybe we should fix the manual's definition for setf of ldb rather than
the values returned for symbol?  Or if fixing ldb is really too hairy
under the current setf definition, maybe this shold be the example we
use in the cleanup proposal.

-- Scott

∂22-Sep-87  1253	Masinter.pa@Xerox.COM 	Re: APPEND-DOTTED
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87  12:53:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 12:51:54 PDT
Date: 22 Sep 87 12:51 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: APPEND-DOTTED
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 27 Jul 87 13:02 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <870922-125154-12438@Xerox>

(I'm *finally* back on CL-Cleanup related work; we must hustle to get
stuff out for the meeting. Sorry.)

In current practice, Xerox Common Lisp and Kyoto Common Lisp signal
errors on the proposed test case (both interpreted and compiled.)

There are notes in the ISSUES.TXT file:

Page 268:

The doc for APPEND should be clarified to warn the user that APPEND
can return a non-list, e.g. (append '() t) => t.

Also, the doc for NCONC should be clarified so that NCONC behaves
analogously to APPEND when its last argument is an atom.


Should this be added to this proposal?




∂22-Sep-87  1254	Masinter.pa@Xerox.COM 	[remailed] Re: APPEND-DOTTED    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87  12:53:55 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 12:52:21 PDT
Date: 22 Sep 87 12:52 PDT
From: Masinter.pa@Xerox.COM
Subject: [remailed] Re: APPEND-DOTTED
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Mon, 27 Jul 87 13:02 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
line-fold: no
Message-ID: <870922-125221-12440@Xerox>

(I'm *finally* back on CL-Cleanup related work; we must hustle to get stuff out for the meeting. Sorry.)

In current practice, Xerox Common Lisp and Kyoto Common Lisp signal errors on the proposed test case (both interpreted and compiled.)

There are notes in the ISSUES.TXT file:

Page 268:

The doc for APPEND should be clarified to warn the user that APPEND
can return a non-list, e.g. (append '() t) => t.

Also, the doc for NCONC should be clarified so that NCONC behaves
analogously to APPEND when its last argument is an atom.


Should this be added to this proposal?




∂22-Sep-87  1300	dcm%hpfclp@hplabs.HP.COM 	Re: Issue: SETF-METHOD-FOR-SYMBOLS (version 1)   
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87  13:00:11 PDT
Received: from hpfcdcm.HP.COM by hpfclp.HP.COM; Tue, 22 Sep 87 10:59:27 mdt
Received: from hpfcdcm by hpfcdcm.HP.COM; Tue, 22 Sep 87 10:58:59 mdt
Return-Path: <dcm@hpfcdcm>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: SETF-METHOD-FOR-SYMBOLS (version 1) 
X-Mailer: mh6.5
In-Reply-To: Your message of Mon, 21 Sep 87 17:36:00 -0400.
             <870921173659.3.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Tue, 22 Sep 87 10:58:55 MST
Message-Id: <3760.559328335@hpfcdcm>
From: Dave Matthews   <dcm%hpfclp@hplabs.HP.COM>



HP's Common Lisp produced the desired results, namely r and s having
identical values.  I agree that this change would be beneficial to the
language and should not adversely impact the performance of most
implementations.

1 LISP [USER:] > (setq r '(a 1 b 2 c 3))
(A 1 B 2 C 3)
2 LISP [USER:] > (setq s r)
(A 1 B 2 C 3)
3 LISP [USER:] > (setf (getf r 'b) (progn (setq r nil) 6))
6
4 LISP [USER:] > r
(A 1 B 6 C 3)
5 LISP [USER:] > s
(A 1 B 6 C 3)
6 LISP [USER:] > (eq r s)
T

Dave Matthews

∂22-Sep-87  1303	Masinter.pa@Xerox.COM 	Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87  13:03:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 13:03:35 PDT
Date: 22 Sep 87 13:03 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
In-reply-to: Dan Carnese <CARNESE@SPAR-20.ARPA>'s message of Fri, 4 Sep
 87 10:15:49 PDT
To: CARNESE@SPAR-20.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <870922-130335-12464@Xerox>


I think the discussion on cl-cleanup is inconclusive enough that the
next step on this proposal is to take it to the wider forum of
common-lisp@sail.stanford.edu. I don't think we're going to make a lot
more progress on it here. There are enough reservations about the
soundness of the programming style it encourages that I think it
requires a clearer mandate from the user community to justify a required
language extension.

Larry

∂22-Sep-87  1306	Masinter.pa@Xerox.COM 	Re: Issue: EVAL-DEFEATS-LINKER  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87  13:06:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 13:06:49 PDT
Date: 22 Sep 87 13:06 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: EVAL-DEFEATS-LINKER
In-reply-to: various messages in june
To: cl-cleanup@SAIL.STANFORD.EDU
cc: willc%tekchips.tek.com@RELAY.CS.NET
Message-ID: <870922-130649-12470@Xerox>


I think procedurally the proper mechanism for dealing with this issue is
to split it; since the heart of the matter is covered in FUNCTION-TYPE,
we should pursue FUNCTION-TYPE, and deal with the other parts of the
proposal (remove #. from standard read table, etc.) separately. 

Please cc: willc on messages regarding FUNCTION-TYPE, as he is not a
member of CL-CLEANUP.


∂22-Sep-87  1347	FAHLMAN@C.CS.CMU.EDU 	[remailed] Re: APPEND-DOTTED
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Sep 87  13:47:30 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Tue 22 Sep 87 16:46:39-EDT
Date: Tue, 22 Sep 1987  16:46 EDT
Message-ID: <FAHLMAN.12336723575.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: [remailed] Re: APPEND-DOTTED
In-reply-to: Msg of 22 Sep 1987  15:52-EDT from Masinter.pa at Xerox.COM


Larry,

Welcome back.

Would it be possible to mail out a summary of where all the old issues
stand before we start digging in the issues file for new items.  I still
don't know what, if anything, was settled in Boston, since I wasn't
there and since the minutes have not appeared.

I gather from some message you sent earlier that the issue of strict vs.
maximally compatible FUNCTION-TYPE was not settled, and that in fact
this issue was further obscured by lots of semi-related questions that
people raised?  Were all the other issues disposed of?  Were ANY of the
other issues disposed of?  Just trying to get a clear picture of where
we stand...

-- Scott

∂22-Sep-87  1434	Masinter.pa@Xerox.COM 	Re: Issue: FUNCTION-TYPE   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87  14:34:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 14:20:17 PDT
Date: 22 Sep 87 14:11 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE
To: cl-cleanup@Sail.stanford.edu
cc: willc%tekchips.tek.com@RELAY.CS.NET
Message-ID: <870922-142017-12589@Xerox>


I've thought about FUNCTION-TYPE on and off over the summer, as one of
the more important issues for us to revisit.  I've changed my mind; I am
now in favor of STRICT-REDEFINITION as long as the proposal that
specifies that it "is an error" to give symbols to functions that expect
functions. ) as long as the restriction is "is an error" rather than
"signals an error".

I think that the proposal has technical (linking, analysis) and
aesthetic (cleaner language semantic) advantages, and that backward
compatibility is well-served by noting that many implementations will
continue to support automatic coercion.

I think we owe X3J13 a new draft of the proposal with fewer (rather than
more) alternatives expressed. 

All of the alternatives expressed so far have some flaws. I'm willing to
work on the STRICT-REDEFINITION proposal to correct its problems (e.g.,
deal with *MACROEXPAND-HOOK*, add COERCE to type FUNCTION).

Are there any volunteers to work on any of the other proposals?

∂22-Sep-87  1434	Masinter.pa@Xerox.COM 	Status 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87  14:34:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 14:22:41 PDT
Date: 22 Sep 87 14:21 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Status
to: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: no
Message-ID: <870922-142241-12598@Xerox>

I'm working on my status file to update it. Since Scott asked, I'll send this version now and another version, probably tomorrow. I'm only part-way done -- please don't bother to send correction and review for issues after FUNCTION-TYPE in this list.

To summarize: some issues were "passed" at X3J13. Others were discussed. At a meeting of cl-cleanup prior to X3J13, we went over the issues.txt file and attempted to divvy up some of the files. 

In some cases, I've indicated a question ???? on whether an item is ready to release. I'd like everyone to reply, either with an accept, don't care, or object on each releasable item. 

Annotations:
* ready for release (I think)
< already approved, no more action pending.
{ awaiting action from some other committee
???? A question: if you do not reply to this issue,
     I will take the action indicated.

In particular, if it says "???? Ready for release with endorsement", I propose to edit the last submitted version of the proposal as sent to CL-CLEANUP to include the statement that the cleanup committee endorses the proposal, and send it on to X3J13.


!
* Proposal format (Version 11)
 Format for proposals to the cleanup committee.
 Version 11 released 11-Jun-87.
 (Suggestion to add a Related Issues field; LMM proposes instead
  just to use References field.)
???? Version 12 modified to suggest naming Related Issues in the References field.

ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
 (Standardize interaction of adjust-array and displacement)
 Discussion about :displaced-to nil vs. no :displaced-to.
 Masinter (or other volunteer) to revise, clarify :displaced-to ommitted
      same as :displaced-to nil.
 Not ready for release.

ADJUST-ARRAY-FILL-POINTER-SOURCE (not yet submitted - from ISSUES file)
(p 297) Specify that the fill pointer is ignored for the purposes of deciding whether a given element of a new array resulting from ADJUST-ARRAY
should take its value from the old array contents or from the specified :INITIAL-ELEMENT.

ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
 (Extend adjust-array so its OK on non-adjustable arrays.)
 Several comments which need reply
 Not ready for release.
 Notes from boston cl-cleanup meeting have *, but
  the mail traffic seems inconclusive.

APPEND-DOTTED (version 1/27 Jul 87)
 Sumbitted by KMP.
 Need mod to Current Practice
 Mention (append () t), clarify NCONC?
 Not ready for release.

APPLY-HOOK-SPECIAL-FORMS (not yet submitted/from ISSUES file) 
 (p 322) At end of second paragraph on *APPLYHOOK*,
 clarify that the apply hook function is not used
 when special forms are evaluated.
 Masinter to submit.

* AREF-1D (Version 6/6 JUL 87)
 (Add a new function for accessing arrays with row-major-index)
 Version 5 conditionally passed at X3j13/Jun87 pending new version.
 Version 6 mailed to cl-cleanup 6Jul.
???? Ready for release with endorsement?

ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
 (Extend ASSOC-IF, etc.  to allow :KEY)
 Needs revision of current practice, test case, example.
 (Only Symbolics is known to implement this feature)
 The summary says Version 2, but I only have version 1 on file.
 Does anyone else have a version 2? Or was this wishful thinking?
 Not ready for release

{ COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
 (Does *BREAK-ON-WARNING* affect the compiler?)
 Questions on interaction with condition proposal. 
 Postponed pending error proposal

< COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
 (Compiler warnings are printed on *ERROR-OUTPUT*)
 Version 6 passed X3J13/Jun87.

DEFINITION-FUNCTIONS (not yet submitted)
  (Extensions for documentation-type for delete-definition
  for type FUNCTION, VARIABLE, TYPE. )
   Masinter to submit.

{ 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.
   Await object proposal.

{ 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.
  Await object proposal.

* DEFVAR-DOCUMENTATION (Version 1/30-Jun)
   (Documentation string is not evaluated.)
   Submitted, no replies
???? Ready for release with endorsement?

< DEFVAR-INITIALIZATION (Version 4/Jun-87)
 ((DEFVAR var) doesn't initialize)
 Version 4 passed X3J13/Jun87.

< DEFVAR-INIT-TIME (Version 2/29-May-87)
 (DEFVAR initializes when evaluated, not later.)
 Version 2 passed X3J13/Jun87.

DISASSEMBLE-SIDE-EFFECT (not yet submitted/from ISSUES.TXT)
Clarify that if DISASSEMBLE is given a symbol whose function definition is interpreted, that definition is indeed compiled and then disassembled, but the resulting compiled definition does not replace the interpreted one as the symbol's function definition.
Need volunteer to submit.

DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
 (can DO-SYMBOLS see the same symbol twice?)
 Debate: extend so that both options are available?
 Needs more information on implementation and
   performance cost.
 Masinter will rewrite, flush :ALLOWED option,
  rewrite :ADD-KEYWORDS to make default for
  :ALLOW-DUPLICATES as NIL., conversion cost => nil.
 Not ready for release.

EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
 ("selective linking" means GC non-used symbols; 
 proposal to change #., #, and part of FUNCTION-TYPE)
   Postpone pending FUNCTION-TYPE resolution & 
	handle remainders.

EXPORT-COORDINATION (from Carnese, no formal proposal)
  Coordinate EXPORT and DEFxxx by adding new form.
  Is this a good idea to allow?
  Not yet formally submitted.
???? Drop this issue?

{ FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no fromal 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.

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.

< 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 1/10 June 87)
 (Allow another argument to ~D etc to paramerize digits between commas)
???? Ready for release with endorsement?

FORMAT-NEGATIVE-PARAMETERS (mail 19 May, no formal proposal)
"format parameters are assumed to be non-negative integers except as specifically stated"
Need volunteer to write up.

< FORMAT-OP-C (Version 5/ 11-Jun-87)
 (What does ~C do?)
 Version 5 passed X3J13/Jun87.

FUNCTION-TYPE (Version 5/ 16-Jun-87)
 (Change definition of FUNCTIONP, function type ...)
 Draft released 16-Jun-87.
 Discussed at X3J13, new proposal due.

<<< status and notes after this point are incomplete and possibly inaccurate >>>

FUNCTION-SPECS (mail 17 Jul)

GET-SETF-METHOD-ENVIRONMENT (mail 23-Jul)

GC-MESSAGES (version 1)
 (Control over unsolicited GC messages in typescript)
 merge with other controls for unsolicited messages?
 Not ready for release.
 Pitman volunteered to revise.

* GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
 (Environment argument for GET-SETF-METHOD)
 Version 4 conditionally passed X3J13/Jun87.
 Version 5 mailed 13-Jul-87 13:18:47 

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?
 Mail 6-Jul

IGNORE-ERRORS (Version 4, 29-May-87)
 (Introduce error catcher) 
 Pitman will release as report from cleanup + error committee.
 (Was not released).

< IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
 (Does IMPORT affect home package?)
 Version 5 passed X3J13/Jun87.

* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun 87)
 ( &KEY arguments not in keyword package?)
 Version 6 conditionally passed X3J13/Jun87.
 Examine wording and avoid "keyword argument" phrasing.
  Introduce phrase "a key argument" to denote arguments
  defined with &KEY ??
   Mail 30 Jul

LISP-SYMBOL-REDEFINITION 
  Mail 22 Aug

LOAD-TIME-EVAL (Version 1, 6 Jun 87)
 (New function/macro/special form for evaluation when 
 compiled file is loaded?)
 Not ready for release.
 Deferred to compiler committee?
 Mail 23-Jul

MACRO-FUNCTION-ENVIRONMENT 
 (Add environment argument to MACRO-FUNCTION?)
 From ENVIRONMENT-ARGUMENTS
 Formal proposal not yet submitted.
 Masinter will extract from environment-arguments

OPEN-KEYWORDS (mail 27-JUL)

* PATHNAME-STREAM (Version 2)
 (PATHNAME only works on file streams)
 Version 2 conditionally passed X3J13/Jun 87
 Needs revision to clarify "file" = "opened with open"
  (there are some non-file devices which have pathnames) 
   Mail 11-Jun

PATHNAME-SUBDIRECTORY-LIST (mail 23-Jul)

PATHNAME-SYMBOL (Version 2)
 (Do symbols automaticly coerce to pathnames?)
 Not ready for release.
 Moon will revise, extend language, clarify
   which functions are affected, etc.

PEEK-CHAR-READ-CHAR-ECHO (Version 1)
 (character interaction with echoing on terminal)
 Not ready for release.
 Pitman will revise & resubmit.

< PRINC-CHARACTER (Version 3)
 (PRINC behavior on character objections)
 Version 3 passed X3J13/Jun87.

PROCLAIM-LEXICAL  (Version 1)
 (add LEXICAL proclaimation, default binding type for
  undeclared free variables)
 Not ready for release.
 Rees & Moon will revise & resubmit. Rees says he won't.
 David? Mail 4 Aug.

PROMPT-FOR (Version 1)
 (add new function which prompts)
 Not ready for release.
 Tabled indefinitely.


REQUIRED-KEYWORD-ARGUMENTS
 (Syntax for keyword arguments which must be supplied?)
 In discussion, formal proposal not yet submitted.
 Table indefinitely.

REMF-DESTRUCTION-UNSPECIFIED (Version 1)
 (How does REMF affect its arguments?)
 Not ready for release.
 Pitman will revise & resubmit.

SETF-EVALUATION-ORDER (not yet submitted)
   (Clarify SETF order) (subsume PUSH-EVALUATION-ORDER,
 (What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
 In discussion, formal proposal not yet submitted. 
 Need volunteer to submit. (SETF-VARIABLE? submitted by Moon. Expand?)

SETF-METHOD-FOR-SYMBOLS 

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
 (FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
 In discussion, no clear consensus
 Not ready for release.
 Pitman will revise & resubmit.

SHADOW-ALREADY-PRESENT (???)

SHARPSIGN-BACKSLASH-BITS
 (What does C-META-H-X mean?)
 Not ready for release.
 Forward to Linden for character proposal?

SHARPSIGN-PLUS-MINUS-NUMBER
 (Is #+68000, #-3600 allowed?)
 Not ready for release.
 Pitman will revise & resubmit.

SHARPSIGN-PLUS-MINUS-PACKAGE
 (What package are *features* in?)
 Not ready for release.
 Pitman will revise & resubmit.

SPECIAL-FORM-SHADOW
 (Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
 In discussion, no formal proposal submitted.
 Send to macro committee?

STANDARD-INPUT-INITIAL-BINDING
(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.

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
 (Operation of TAILP given NIL)
 Not ready for release.
 Masinter will revise & resubmit.

UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
 (GO out of UNWIND-PROTECT clauses.)
 Not ready for release.
  Gabriel will revise & resubmit.

∂22-Sep-87  1434	Masinter.pa@Xerox.COM 	Status 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87  14:34:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 14:22:41 PDT
Date: 22 Sep 87 14:21 PDT
From: Masinter.pa@Xerox.COM
To: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Status
to: cl-cleanup@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: no
Message-ID: <870922-142241-12598@Xerox>

I'm working on my status file to update it. Since Scott asked, I'll send this version now and another version, probably tomorrow. I'm only part-way done -- please don't bother to send correction and review for issues after FUNCTION-TYPE in this list.

To summarize: some issues were "passed" at X3J13. Others were discussed. At a meeting of cl-cleanup prior to X3J13, we went over the issues.txt file and attempted to divvy up some of the files. 

In some cases, I've indicated a question ???? on whether an item is ready to release. I'd like everyone to reply, either with an accept, don't care, or object on each releasable item. 

Annotations:
* ready for release (I think)
< already approved, no more action pending.
{ awaiting action from some other committee
???? A question: if you do not reply to this issue,
     I will take the action indicated.

In particular, if it says "???? Ready for release with endorsement", I propose to edit the last submitted version of the proposal as sent to CL-CLEANUP to include the statement that the cleanup committee endorses the proposal, and send it on to X3J13.


!
* Proposal format (Version 11)
 Format for proposals to the cleanup committee.
 Version 11 released 11-Jun-87.
 (Suggestion to add a Related Issues field; LMM proposes instead
  just to use References field.)
???? Version 12 modified to suggest naming Related Issues in the References field.

ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
 (Standardize interaction of adjust-array and displacement)
 Discussion about :displaced-to nil vs. no :displaced-to.
 Masinter (or other volunteer) to revise, clarify :displaced-to ommitted
      same as :displaced-to nil.
 Not ready for release.

ADJUST-ARRAY-FILL-POINTER-SOURCE (not yet submitted - from ISSUES file)
(p 297) Specify that the fill pointer is ignored for the purposes of deciding whether a given element of a new array resulting from ADJUST-ARRAY
should take its value from the old array contents or from the specified :INITIAL-ELEMENT.

ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
 (Extend adjust-array so its OK on non-adjustable arrays.)
 Several comments which need reply
 Not ready for release.
 Notes from boston cl-cleanup meeting have *, but
  the mail traffic seems inconclusive.

APPEND-DOTTED (version 1/27 Jul 87)
 Sumbitted by KMP.
 Need mod to Current Practice
 Mention (append () t), clarify NCONC?
 Not ready for release.

APPLY-HOOK-SPECIAL-FORMS (not yet submitted/from ISSUES file) 
 (p 322) At end of second paragraph on *APPLYHOOK*,
 clarify that the apply hook function is not used
 when special forms are evaluated.
 Masinter to submit.

* AREF-1D (Version 6/6 JUL 87)
 (Add a new function for accessing arrays with row-major-index)
 Version 5 conditionally passed at X3j13/Jun87 pending new version.
 Version 6 mailed to cl-cleanup 6Jul.
???? Ready for release with endorsement?

ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
 (Extend ASSOC-IF, etc.  to allow :KEY)
 Needs revision of current practice, test case, example.
 (Only Symbolics is known to implement this feature)
 The summary says Version 2, but I only have version 1 on file.
 Does anyone else have a version 2? Or was this wishful thinking?
 Not ready for release

{ COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
 (Does *BREAK-ON-WARNING* affect the compiler?)
 Questions on interaction with condition proposal. 
 Postponed pending error proposal

< COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
 (Compiler warnings are printed on *ERROR-OUTPUT*)
 Version 6 passed X3J13/Jun87.

DEFINITION-FUNCTIONS (not yet submitted)
  (Extensions for documentation-type for delete-definition
  for type FUNCTION, VARIABLE, TYPE. )
   Masinter to submit.

{ 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.
   Await object proposal.

{ 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.
  Await object proposal.

* DEFVAR-DOCUMENTATION (Version 1/30-Jun)
   (Documentation string is not evaluated.)
   Submitted, no replies
???? Ready for release with endorsement?

< DEFVAR-INITIALIZATION (Version 4/Jun-87)
 ((DEFVAR var) doesn't initialize)
 Version 4 passed X3J13/Jun87.

< DEFVAR-INIT-TIME (Version 2/29-May-87)
 (DEFVAR initializes when evaluated, not later.)
 Version 2 passed X3J13/Jun87.

DISASSEMBLE-SIDE-EFFECT (not yet submitted/from ISSUES.TXT)
Clarify that if DISASSEMBLE is given a symbol whose function definition is interpreted, that definition is indeed compiled and then disassembled, but the resulting compiled definition does not replace the interpreted one as the symbol's function definition.
Need volunteer to submit.

DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
 (can DO-SYMBOLS see the same symbol twice?)
 Debate: extend so that both options are available?
 Needs more information on implementation and
   performance cost.
 Masinter will rewrite, flush :ALLOWED option,
  rewrite :ADD-KEYWORDS to make default for
  :ALLOW-DUPLICATES as NIL., conversion cost => nil.
 Not ready for release.

EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
 ("selective linking" means GC non-used symbols; 
 proposal to change #., #, and part of FUNCTION-TYPE)
   Postpone pending FUNCTION-TYPE resolution & 
	handle remainders.

EXPORT-COORDINATION (from Carnese, no formal proposal)
  Coordinate EXPORT and DEFxxx by adding new form.
  Is this a good idea to allow?
  Not yet formally submitted.
???? Drop this issue?

{ FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no fromal 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.

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.

< 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 1/10 June 87)
 (Allow another argument to ~D etc to paramerize digits between commas)
???? Ready for release with endorsement?

FORMAT-NEGATIVE-PARAMETERS (mail 19 May, no formal proposal)
"format parameters are assumed to be non-negative integers except as specifically stated"
Need volunteer to write up.

< FORMAT-OP-C (Version 5/ 11-Jun-87)
 (What does ~C do?)
 Version 5 passed X3J13/Jun87.

FUNCTION-TYPE (Version 5/ 16-Jun-87)
 (Change definition of FUNCTIONP, function type ...)
 Draft released 16-Jun-87.
 Discussed at X3J13, new proposal due.

<<< status and notes after this point are incomplete and possibly inaccurate >>>

FUNCTION-SPECS (mail 17 Jul)

GET-SETF-METHOD-ENVIRONMENT (mail 23-Jul)

GC-MESSAGES (version 1)
 (Control over unsolicited GC messages in typescript)
 merge with other controls for unsolicited messages?
 Not ready for release.
 Pitman volunteered to revise.

* GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
 (Environment argument for GET-SETF-METHOD)
 Version 4 conditionally passed X3J13/Jun87.
 Version 5 mailed 13-Jul-87 13:18:47 

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?
 Mail 6-Jul

IGNORE-ERRORS (Version 4, 29-May-87)
 (Introduce error catcher) 
 Pitman will release as report from cleanup + error committee.
 (Was not released).

< IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
 (Does IMPORT affect home package?)
 Version 5 passed X3J13/Jun87.

* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun 87)
 ( &KEY arguments not in keyword package?)
 Version 6 conditionally passed X3J13/Jun87.
 Examine wording and avoid "keyword argument" phrasing.
  Introduce phrase "a key argument" to denote arguments
  defined with &KEY ??
   Mail 30 Jul

LISP-SYMBOL-REDEFINITION 
  Mail 22 Aug

LOAD-TIME-EVAL (Version 1, 6 Jun 87)
 (New function/macro/special form for evaluation when 
 compiled file is loaded?)
 Not ready for release.
 Deferred to compiler committee?
 Mail 23-Jul

MACRO-FUNCTION-ENVIRONMENT 
 (Add environment argument to MACRO-FUNCTION?)
 From ENVIRONMENT-ARGUMENTS
 Formal proposal not yet submitted.
 Masinter will extract from environment-arguments

OPEN-KEYWORDS (mail 27-JUL)

* PATHNAME-STREAM (Version 2)
 (PATHNAME only works on file streams)
 Version 2 conditionally passed X3J13/Jun 87
 Needs revision to clarify "file" = "opened with open"
  (there are some non-file devices which have pathnames) 
   Mail 11-Jun

PATHNAME-SUBDIRECTORY-LIST (mail 23-Jul)

PATHNAME-SYMBOL (Version 2)
 (Do symbols automaticly coerce to pathnames?)
 Not ready for release.
 Moon will revise, extend language, clarify
   which functions are affected, etc.

PEEK-CHAR-READ-CHAR-ECHO (Version 1)
 (character interaction with echoing on terminal)
 Not ready for release.
 Pitman will revise & resubmit.

< PRINC-CHARACTER (Version 3)
 (PRINC behavior on character objections)
 Version 3 passed X3J13/Jun87.

PROCLAIM-LEXICAL  (Version 1)
 (add LEXICAL proclaimation, default binding type for
  undeclared free variables)
 Not ready for release.
 Rees & Moon will revise & resubmit. Rees says he won't.
 David? Mail 4 Aug.

PROMPT-FOR (Version 1)
 (add new function which prompts)
 Not ready for release.
 Tabled indefinitely.


REQUIRED-KEYWORD-ARGUMENTS
 (Syntax for keyword arguments which must be supplied?)
 In discussion, formal proposal not yet submitted.
 Table indefinitely.

REMF-DESTRUCTION-UNSPECIFIED (Version 1)
 (How does REMF affect its arguments?)
 Not ready for release.
 Pitman will revise & resubmit.

SETF-EVALUATION-ORDER (not yet submitted)
   (Clarify SETF order) (subsume PUSH-EVALUATION-ORDER,
 (What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
 In discussion, formal proposal not yet submitted. 
 Need volunteer to submit. (SETF-VARIABLE? submitted by Moon. Expand?)

SETF-METHOD-FOR-SYMBOLS 

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2)
 (FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
 In discussion, no clear consensus
 Not ready for release.
 Pitman will revise & resubmit.

SHADOW-ALREADY-PRESENT (???)

SHARPSIGN-BACKSLASH-BITS
 (What does C-META-H-X mean?)
 Not ready for release.
 Forward to Linden for character proposal?

SHARPSIGN-PLUS-MINUS-NUMBER
 (Is #+68000, #-3600 allowed?)
 Not ready for release.
 Pitman will revise & resubmit.

SHARPSIGN-PLUS-MINUS-PACKAGE
 (What package are *features* in?)
 Not ready for release.
 Pitman will revise & resubmit.

SPECIAL-FORM-SHADOW
 (Is it OK to shadow a special form with FLET, LABELS, MACROLET?)
 In discussion, no formal proposal submitted.
 Send to macro committee?

STANDARD-INPUT-INITIAL-BINDING
(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.

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
 (Operation of TAILP given NIL)
 Not ready for release.
 Masinter will revise & resubmit.

UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
 (GO out of UNWIND-PROTECT clauses.)
 Not ready for release.
  Gabriel will revise & resubmit.

∂22-Sep-87  1513	Masinter.pa@Xerox.COM 	status: remaining ISSUES.TXT file    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Sep 87  15:13:33 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 87 15:13:59 PDT
Date: 22 Sep 87 15:04 PDT
From: Masinter.pa@Xerox.COM
Subject: status: remaining ISSUES.TXT file
To: cl-cleanup@sail.stanford.edu
line-fold: no
Message-ID: <870922-151359-12701@Xerox>

For the record, this is the remainder of the issues file that Scott worked on -- was it 1.5 years ago -- that I don't believe have made it into proposals yet. This is my "working copy":

This file contains a list of issues and proposals for the X3J13 cleanup
committee to consider.  It is broken into several sections, divided by a
line of ='s.

* Editorial changes: items that merely clarify what must currently be
   decyphered out of CLtL; not changes to Common Lisp but to the language
   describing it.

* Simple clarifications: items that are unclear, contradictory, or
  underspecified in CLtL.  In these cases, the proper fix seems obvious.

* Complex clarifications: these may require a bit more discussion.

* Simple changes: proposed small changes that may or may not be
  desirable.

* Complex changes: these are more complex or fundamental changes that
  will probably require extensive discussion.  Some of them require the
  development of a specific proposal.

* Proposed additions: these are additions or compatible extensions that
  may or may not be worth adding to the language.  Some of them require
  the development of specific proposals.  In general, these are less
  urgent than the clarifications and proposed changes.

* Issues to pass along to the compiler committee.

The clarifications on Steele's list of Jan, 1986, are included here
except for those that have been withdrawn or extensively modified by
later discussion.  The initial judgements about which issues are simple
and which are complex were made by Scott Fahlman, who has frequently
been wrong about such things in the past.

This file does not currently reflect proposals made after the August
1986 Lisp conference.  The formal proposals discussed just before the
Lisp conference are included here, more or less as place-holders.  I
have not yet dug through the relevant mail to find all of the options
and amendments that were proposed in the course of discussion.

The plan is to have the "cleanup" subcommittee of X3J13 turn these
issues into a series of proposals that will be sent to the Clisp mailing
list for comment, then to the full X3J13 committee, which will consider
whether to include these changes in the forthcoming Common Lisp
standard.

Editorial changes:

---------------------------------------------------------------------------
(p ???)
Modify the general rule about operating only on active elements of arrays to exclude ADJUST-ARRAY, SETF of AREF, ROW-MAJOR-AREF, and SETF of ROW-MAJOR-AREF.
---------------------------------------------------------------------------
p ???
Modify the description of APROPOS to replace the words ``available in'' to
``accessible in,'' and specify that APROPOS on a given package finds the
same symbols that DO-SYMBOLS would.
---------------------------------------------------------------------------
"Throughout: Adopt the term "special operator" for the symbol that
introduces a special form, leaving "special form" to refer to the whole
form. Note that the name SPECIAL-FORM-P is not quite accurate, since it acts on the symbols that introduce forms rather than the forms themselves."


p 274: Clarify by example that NSUBST-IF-NOT is perhaps non-intuitive:
    (let* ((item-list '(numbers (1.0 2 5/3) symbols (foo bar)))
	   (new (nsubst-if-not '3.1415 #'numberp item-list)))
      (values new item-list))
    => 3.1415
---------------------------------------------------------------------------
Page 113:
Clarify that the bindings created by FLET and LABELS have lexical scope
and indefinite extent.  The functions themselves have indefinite extent.
---------------------------------------------------------------------------
Page 426:
Make explicit that when a compiled file is loaded, symbols naming
lexical variables in the code may or may not be created.  This is left up
to the implementation.

===========================================================================
SIMPLE CLARIFICATIONS:
---------------------------------------------------------------------------
Page 379:

Specify that PEEK-CHAR operations on echo streams should not echo.  The
echo occurs when the character is actually read.  (We may have to add "on
systems which can manage this", since there may be some that cannot.)
---------------------------------------------------------------------------
Page 404:

Specify that the ~< ... ~> directives to FORMAT divide the whitespace
evenly into the gaps between the units of text.  Any remaining quanta of
whitespace are distributed into gaps from left to right, not placed
randomly.
---------------------------------------------------------------------------
Page 140:

Clarify that in an UNWIND-PROTECT, the cleanup forms are executed in the
dynamic environment of the UNWIND-PROTECT itself.
---------------------------------------------------------------------------
Page 51:

Clarify that coerce MAY NOT copy the argument if it is already of the
correct type.  (At present, the manual is inconsistent on whether a copy
is allowed.)
---------------------------------------------------------------------------
Page 426:

Clarify what the :VERBOSE and :PRINT options to LOAD do, or at least what
their intent is.

One proposal, by SEF:

1. Load with no switches should not print anything on standard-output.

2. The :verbose switch is intended to print some per-file information
and an indication when the loading is done, but not something for every
form that is loaded.

3. The :print switch is intended to cause the read/eval/print loop's
output to be printed, or if the file is compiled, something for each
form that is loaded.

4. These are only guidelines covering the intent of how these switches
are to be used.  Implementations are free to indicate this kind of
information in other ways if that makes sense in their environment.

---------------------------------------------------------------------------
Page 67:

Clarify that argument-list init-forms are NOT lexically within the block
established by the Defun of which they are a part.  (Most implementations
have done it this way.)
---------------------------------------------------------------------------
Page 422:

Clarify that WITH-OPEN-FILE returns the value(s) of the last form in the
body.
---------------------------------------------------------------------------
Page 200, 215:

Clarification: Division by 0 should be documented to be an error.  It
doesn't seem to be at present.

[For flonums, maybe allow IEEE-type infinities here.  Wait for error
proposal before discussing whether error must be signalled and how.]
---------------------------------------------------------------------------
Page 50, 307:

Clarification: It is an error to redefine an built-in type via DEFSTRUCT or
DEFTYPE.  [Coordinate with object proposal.]
---------------------------------------------------------------------------
Page 316:

Clarify that if a defstruct specifies a BOA constructor, the default
keyword-style constructor is not also defined.  (OR clarify that it is.)
---------------------------------------------------------------------------
Page 280:

Clarify that the :KEY argument to ASSOC is applied to the car of each list,
not the whole pair.
---------------------------------------------------------------------------
Page 104:

In the description of the second value of a setf method:

    A list of *value forms* (subforms of the given form) to whose values
    the temporary values are to be bound.

preface the parentheical remark with "often" or "usually".  It is not
always true, as in the following example:


    (DEFMACRO ELT-IF (SEQ PRED IND1 IND2)
	`(ELT ,SEQ (IF ,PRED ,IND1 ,IND2)))

The setf method of (ELT2 S P A B) is defined to be the same as that of
(ELT S (IF P A B)).  There is no way to express the setf method of this
form in terms of the values of subforms of (ELT2 S P A B), since A and
B are not always evaluated.  In the implementations I have checked, the
setf method of (ELT2 S P A B) has value forms S and (IF P A B).

The current statement is also harmful if read as a prescription for
DEFINE-SETF-METHOD, since it is then impossible to define SETF methods
for forms that do not always evaluate all of their arguments.
---------------------------------------------------------------------------
Page 130:

Specify that constant forms such as strings may appear at top-level in a
tagbody, but that only symbols and integers are considered to be tags.
It is an error to use anything else as the destination tag for a GO.

Specify that it is an error for the same (EQL) tag to appear more than
once in the body of a TAGBODY.  (However, a TAGBODY may have the same
tag as another TAGBODY in which it nests, in which case the tag in the
outer TAGBODY is shadowed, as already specified.)

===========================================================================
COMPLEX CLARIFICATIONS:
---------------------------------------------------------------------------
Page ???:

It is not specified what happens when the same (EQL) variable appears more
than once in a lambda-list or binding form (LET, LET*, etc.).  This was
discussed at some length in June/July 1986.  Possible options:

1. It is an error.
2. Latest (rightmost) binding governs in all forms.
3. It is an error in parallel-binding forms and lambdas, but rightmost
   governs in serial-binding forms such as LET*.

[Related issue: special dispensation to allow multiple uses of ignored
variables?  Bring back IGNORE as a universally-ignored variable?]
---------------------------------------------------------------------------
Page 68:

(merge with LISP-SYMBOL-REDEFINITION)
Clarify that using DEFCONSTANT to redefine any constant described in the
Common Lisp specification is an error.

Clarify that if the user defines a constant, compiles code that refers
to that constant, and then redefines the constant, then behavior of the
compiled code may be unpredictable.  It is an error to execute such
code.

Clarify that it is not an error to issue a second DEFCONSTANT command
for an existing constant iff the new value is EQL to the old one.
[Needed for reloading compiled code files.]
---------------------------------------------------------------------------
Page 413, 424:

The semantics of TRUENAME and PROBE-FILE on open streams
needs to be clarified.  The requirement that PROBE-FILE never return
NIL on an open file is clearly broken.  Spice Lisp currently
implements TRUENAME and PROBE-FILE in the same way, except that
TRUENAME errors instead of returning NIL.  Someone (Moon, I believe)
suggested that (PROBE-FILE <stream>) was the same as 
(PROBE-FILE (PATHNAME <stream>)), but that (TRUENAME <stream>) was
somehow different.  There also needs to be some discussion of the
meaning of operations on closed streams.  The manual never says which
operations may be done on closed streams, let alone what the
operations do.
---------------------------------------------------------------------------
Page ???:

Define carefully which returned values may be shared structure.  These
must not be destructively modified (or should be copied if you want to
be safe).  Symbol name-strings, rest-arg lists...
---------------------------------------------------------------------------
Page 93:

Clarify that MACROLET shadows any setf function for the associated macro:
  (DEFUN LOSER (X)
    (CAR X)
  (DEFUN SET-LOSER (X Y)
    (SETF (CAR X) Y))
  (DEFSETF LOSER SET-LOSER)
  (DEFUN LOSSAGE (X Y)
    (MACROLET ((LOSER (X)
	         `(SYMBOL-VALUE ,X)))
      (SETF (LOSER X) Y)))
LOSSAGE calls SET, not SET-LOSER.
---------------------------------------------------------------------------
Page 113:

Clarify that FLET shadows DEFMACRO. 
---------------------------------------------------------------------------
Page 321:

Modify EVAL to have an optional environment argument.
[I think this is unwise. -- SEF]
---------------------------------------------------------------------------
Page 440:

Specify explicitly that one may trace macros as well as functions.
[Is this feasible in all implementations? CF CLOS trace proposal]
---------------------------------------------------------------------------
Page 80:

Clarify what EQUAL and EQUALP do on structures.  Proposal: If the
structures are of the same type, both EQUAL and EQUALP do component-wise
comparison.
---------------------------------------------------------------------------
Page 112:

Clarify Compiler-Let or flush it.  [SEF: Flush it.]
---------------------------------------------------------------------------
Page 389:

Need a portable way to print a #\SPACE as " ".  (FORMAT NIL "~C"
#\Space) may or may not do this.  Same with PRINC.  For Standard
characters, it is safe to be more specific about how things are printed.
---------------------------------------------------------------------------
Page 160:

Either specify that IGNOREd arguments do not generate a warning if you
use them after all, or add a new declaration IGNORABLE.

[Stupid issue, discussed to death earlier.]
---------------------------------------------------------------------------
Page 295:

Proposed clarifications regarding fill pointers:
  If no fill pointer is specified to Make-Array, the implementaiton is
    not required to supply a fill-pointer, but may do so.
  If a destructive sequence function such as DELETE is passed an array
    with a fill pointer, it may change the active size of the array by
    manipulating the fill pointer; it is not required that the underlying
    array's ARRAY-DIMENSION be altered.
  If ADJUST-ARRAY is called on a vector with a fill pointer, but is not
    given a :FILL-POINTER argument, the fill-pointer is retained and is
    reset to the new length of the vector.
---------------------------------------------------------------------------
Page 249 and elsewhere:

What is the effect of giving circular lists to MAP, MAPCAR, SOME,
EVERY, etc.?  Specify that it is an error, or require it to work?

[ There's a real split on this issue.  To some people, circular lists
are a clever hack and this obviously should work.  To others, they are
an evil that should not be encouraged.  SEF and GLS have argued in favor
of treating this as an error. ]
---------------------------------------------------------------------------
Page 307:

Does COPY-FOO (where foo is a structure) work on subtypes that include
FOO?  Does COPY-PERSON work on ASTRONAUT?

[Subsumed by object proposal?  Gregor suggests: COPY-xxx as defined by a
defstruct returns a structure of that defstruct's type.  COPY returns a
structure of the same type as its argument.]
---------------------------------------------------------------------------
Page 152:

Clarify (figure out) how MACROLET and *MACROEXPAND-HOOK* interact.
---------------------------------------------------------------------------
Page 447:

Clarify by example what sort of thing goes into
LISP-IMPLEMENTATION-TYPE, etc.
---------------------------------------------------------------------------
Page ???:

Clarify the ways in which an implementation may extend pure Common Lisp:
Extra keywords to specified functions?  To all functions?  Extra return
values?  Functions working on otherwise illegal types?  Require a compiler
mode that catches non-Common stuff?  Should we document certain specific
functions (e.g. COMPILE) as allowing implementation-specific keyword
extensions. (cf IF-BODY discussion)
---------------------------------------------------------------------------
Chapter 23:

Pathnames and the file system interface require much clarification and
probably some changes.  A comprehensive proposal is needed here.
The Symbolics solution might work for us.  If we can't fix this up, we
should consider dumping the whole thing and going with something very
simple and minimal, such as a raw string in system-specific format to
designate a file.
---------------------------------------------------------------------------
Page 145:

Specify that the &REST or &BODY argument to a macro may be the very list
from the macro call, and not a copy, and therefore the user should not
perform destructive operations on it.
---------------------------------------------------------------------------
Page 60:

Decide whether an &rest arg is required to be a freshly-consed list or
whether it may be part of a pre-existing list passed in by APPLY.
---------------------------------------------------------------------------
Page 162:

Decide what the behavior of (THE (VALUES ...) form) should be.  Does it
specify exactly how many values should be returned, or a lower limit, or
what?

One proposal: in (THE (VALUES ...) form), the form may return more
values, but not fewer, than the number of types specified in the (VALUES
...) form, and any extra values are of unrestricted type.
Also specify that (THE type form) where type is not (VALUES ...) is
equivalent to (THE (VALUES type) form).

[Discussed June/July 1986.]

===========================================================================
SIMPLE CHANGES:
---------------------------------------------------------------------------
Page 239:

Change CHAR-EQUAL, CHAR-NOT-EQUAL, CHAR-LESSP, CHAR-GREATERP,
CHAR-NOT-LESSP, and CHAR-NOT-GREATERP to consider two characters to be
different if their bits attributes are different.

[May be subsumed under a wholesale redesign of character objects,
eliminating the BIT and FONT attributes. Character committee??]
---------------------------------------------------------------------------
Page 202:

Define (LCM) to return 1 (the manual is incorrect in claiming that the
result should be infinity).
---------------------------------------------------------------------------
Page 377:

Extend READ-DELIMITED-LIST by adding one more optional argument,
dot-permitted-p, defaulting to nil, that if true allows the delimited list
to contain dot notation, and if false forbids dot notation.
---------------------------------------------------------------------------
Page 323:

Eliminate the ENV argument to APPLYHOOK, which is useless.
---------------------------------------------------------------------------
Page 418:

Flush :DIRECTION :PROBE as an allowable argument to OPEN.
---------------------------------------------------------------------------
Page 171 ff:

All functions that take a package as an argument, except those
named PACKAGE-xxx, will also take a string or symbol and do an implicit
find-package.  This gives users maximum flexibility and minimum confusion.
---------------------------------------------------------------------------
Page 316:

BOA constructors take keywords, with the obvious semantics.
---------------------------------------------------------------------------
Page 251:

(reduce #'+ list-of-objects :KEY #'object-quantity) would apply the
function OBJECT-QUANTITY to each element of the list-of-objects before
reducing it with +.
---------------------------------------------------------------------------
Page 327:

Functions that require a string, pathname, stream, or symbol
should not accept a symbol.  NIL is confusing, and some implementations
use symbols for certain streams.  [Proposal by Moon]
---------------------------------------------------------------------------
Page 305:

Require that structures (created without the :TYPE specifier) are
disjoint from the other built-in types such as vector?  They already
must be distinguishable from plain old vectors.
---------------------------------------------------------------------------
Page ???:

Forbid implementations to produce unsolicited output to
*standard-ouput*.  Output to *error-ouput* is always OK.
---------------------------------------------------------------------------
Page 444:

In the description of Decoded Time format, the Time-zone component is
required to be an integer which is the number of hours west of GMT.
(The latest term is Coordinated Universal Time, or UTC, by the way).
Since time zones are not always an integral number of hours west of GMT,
this should be changed to either (a) a non-complex, non-negative number
which is the number of hours west of GMT, or (b) an integer which is the
number of {minutes, seconds} west of GMT.

===========================================================================
COMPLEX CHANGES:
---------------------------------------------------------------------------
Page 210:

Change the branch cuts of the ATAN function to follow W. Kahan's
recommendations.  (Paul Penfield intends to recommend the same change to
the APL community.)  

[Steele should produce a specific proposal without forwarding pointers.]
---------------------------------------------------------------------------
Page 181:

There must be a package with only the official Common Lisp symbols,
either named LISP or COMMON-LISP.  Work out where
implementation-specific extensions go.  Several proposals exist.
---------------------------------------------------------------------------
Page 80:

EQUAL should descend into arrays, if they are the same type and
dimensionality, comparing leaves by EQL.

[SEF: I was partly to blame for the decision not to do this.  I now
believe that we blew it here, and should consider un-blowing it.  The
change will break some code, but the community might accept it anyway.]
---------------------------------------------------------------------------
Page 26, 42:

Alter the LIST type-specifier to distinguish proper lists from others and
to specify the element-type of the list.
---------------------------------------------------------------------------
Page 93:

Flush MACROLET, thereby doing away with environment arguments and related
confusion.

[This has been proposed N times and rejected each time on the grounds that
MACROLET is not *totally* useless, but I still think that this is the right
thing to do. -- SEF]
---------------------------------------------------------------------------
Page 154:

Eliminate the provision that a macro at the start of a body may expand
into a declaration.

[KMP, who was one of the more vocal proponents of this feature, has
now suggested that we consider flushing it.  It requires some confusing
environment hackery to do this right.]
---------------------------------------------------------------------------
Page 322:

Flush *applyhook* and *evalhook* and related hackery.  Does anyone use
this (correctly) for anything other than implementing steppers?  If not,
it may be preferable to forget about portable stepper hooks and make
stepping an implementaiton-dependent facility like DEBUG.  These hooks
cause an awful lot of confusion and anxiety for users and implementors.
---------------------------------------------------------------------------
Page 153:

Proposed alterations to SPECIAL declaration and possible addition of
UNSPECIAL (see Common Lisp mail around July 1986 including proposal by
Pavel).  One or more coherent proposals have to be constructed for
consideration.
---------------------------------------------------------------------------
Page 58:

Turn the warning that standard macros should not expand into
non-standard special forms into a requirement.  Makes life easier for
code-walkers.

[Can all implemenations live with this?]
---------------------------------------------------------------------------
Page ???:

Three related, controversial proposals on case-sensitivity for symbols. 

1)  Add a switch that would tell read and friends to suppress case
conversion, along with a note indicating that portable code assumes this
switch to be OFF.  

[SEF: This is the proposal dear to the unix people.  I still think that
it is asking for trouble to put this in.  Some code will assume this
switch despite the warning, some won't, and the two kinds of code will
not mix.]

2) Alternatively, think again about making the language case-preserving,
but with INTERN ignoring case completely.  This means that there is *NO*
way to create two symbols, one named "FOO" and the other named "foo",
but now that we have strings this may not be necessary.

[SEF: I now believe that this is what we should have done, but it is
probably too radical a change to consider at this point.]

3) Add a property of read tables which tell whether READ under the read table preserves case.  READ-CHAR is not affected.

[LMM: This is the way Xerox Lisp handles it, and it works very well. It puts case sensitivity where it belongs, as part of the read-table description.]
---------------------------------------------------------------------------
Page 171:

Even if we keep the status quo for symbols, we may want to reconsider
the rules on case-sensitivity for package names.  Need a specific
proposal and analysis of transition strategy.
[LMM: this is unnecessary, I think.]
---------------------------------------------------------------------------
Page 382:

How to communicate the current depth in printing when there are
user-defined print functions?  Guy said that what had in mind was that
the user would bind *print-level* according to the depth arg supplied to
the print function, but there were several problems with this.  Most of
the tasteful solutions involved adding new args to WRITE which indicated
the nature of the recursive use of the printer.  Others objected that
nobody wants to use WRITE directly, so that isn't a real fix.
---------------------------------------------------------------------------
Chapter 13:
[Not in cleanup committee....]
We need a comprehensive proposal for handling extended characters
(16-bit char-code, plus possibly other fields) and strings of extended
characters.  The Japanese are developing a Kanji standard.  Maybe we
can just adopt this; certainly we must coordinate with it.

At the same time, consider whether to retain the char-bit and char-font
fileds in present form.  Since an implementaiton may omit these fields,
this should not break truly portable code.
===========================================================================
PROPOSED ADDITIONS:
---------------------------------------------------------------------------
Page ???

Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects.  Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time. (Discussed by not good results).
---------------------------------------------------------------------------
Page 226:

Add SIGNED-LDB.  Like LDB but sign-extends the extracted byte.
---------------------------------------------------------------------------
Page 283:

Add functions HASH-TABLE-REHASH-SIZE, HASH-TABLE-REHASH-THRESHOLD,
HASH-TABLE-SIZE, and HASH-TABLE-TEST each take a hash table and return
the appropriate current information.

[ Which, if any, are SETF-able?  What does hash-table-test return, the
function object for the test function? ]
---------------------------------------------------------------------------
Page 439:

Add COMPILEDP.  This takes a function and returns non-NIL if it is a
compiled function, and NIL if it is not.  If the function is a symbol
whose compiled-function definition was installed by the COMPILE
function, then the non-NIL value returned is the interpreted definition
that was compiled.
---------------------------------------------------------------------------
Page 439: 

Add UNCOMPILE.  This takes a symbol and restores the previous
interpreted definition of that symbol if that symbol previously had an
interpreted definition and was then given to COMPILE; otherwise no
action is taken.
---------------------------------------------------------------------------
Page 447:

Add USER-NAME.  This returns a string identifying the user of the Common
Lisp system, or NIL if that cannot be determined.
---------------------------------------------------------------------------
Page 327:

Add *DISCARD-OUTPUT-STREAM* (alias, the bit bucket).
[Make this a constant so that it can be optimized?  You should never want
to rebind this to another value.]
---------------------------------------------------------------------------
Page 117:

Add (CASE-WITH-TEST test item ...clauses...).
---------------------------------------------------------------------------
Page 51:

Extension: Let COERCE coerce symbols to strings.  NIL is treated as the
empty sequence, not a symbol.  Also let COERCE turn string-chars into
strings of length 1.
---------------------------------------------------------------------------
Page ???:

Add TRUE and FALSE, functions that take any number of args, ignore them,
and return T and NIL respectively.
Someplace:
---------------------------------------------------------------------------
Page 95, 267:

Add SETF of NTHCDR.
---------------------------------------------------------------------------
Page 158:

Add a TYPE-RESTRICT declaration.  (TYPE-RESTRICT type1 type2), where
type2 is a subtype of type1, says that within the scope of the
declaration if the compiler can prove a value is of type1, it is
allowed to assume that it is of type2.  This gets rid of a lot of
multiple-THE forms when you want maximally tense code.
---------------------------------------------------------------------------
Page 73:

Fill out the set of mumble-P type predicates.  Currently we have some
and not others.
---------------------------------------------------------------------------
Page ???:

We need a set of "undoing" functions, so that interactive errors and
failed experiments can be recovered from without starting over.
See comprehensive proposal by Eric Benson.

[SEF: A generic "undo" facility, like SETF, has been opposed on various
occasions, but is a bad idea because users will expect too much of it,
and complain when it doesn't undo everything.]
[cf DEFINITION-FUNCTIONS, in prep]
---------------------------------------------------------------------------
Page 336:

Add (syntax-type <character>), which returns one of the following:
:illegal, :whitespace, :constituent, :single-escape, :multiple-escape,
:terminating-macro, :non-terminating-macro.

[Make this setf-able?  If so, what do we do about macro characters that
have no definitions?]
---------------------------------------------------------------------------
Page 283:

Add EQUALP hash-tables?  Case-insensitive hash-tables for strings?  Let
the user provide his own test (with associated hashing function)?  [Need
a coherent proposal.]
---------------------------------------------------------------------------
Page ???:

Have a function COPY that can copy any single object.  For a CONS cell
it would copy just that CONS.  Whether (EQ X (COPY X)) for X a character
or number is implementation-dependent.

[Proposal in archives by Morrison, needs some tuning.]
---------------------------------------------------------------------------
Page 171:

We need a way to say "use all the symbols from package FOO except for X,
Y, ..."  Shadowing is no good, since you might want to inherit X from
somewhere else.  Also, do we want a make-package that says ALL symbols
get exported?
---------------------------------------------------------------------------
Page ???:

Fahlman's proposal for &more arguments, similar to &rest but leaves the
arguments on the stack LEXPR-style.  Removes one of the worst inherent
efficiency problems in Common Lisp.
---------------------------------------------------------------------------
Page 438:

Review and develop a general philosophy on the handling of semi-standard
system interface functions such as GC, BYE, ED, SAVE-SYSTEM, etc.  Then
see what we want to add (or remove).
---------------------------------------------------------------------------
Page ???:

Consider FUNCTION-PARAMETERS and related proposals that were discussed
extensively in June/July 1986.
---------------------------------------------------------------------------
Page ???:

Consider PARSE-BODY and extended syntax for &BODY, as discussed in
June/July 1986.

[Note, if we flush MACROLET or eliminate macro-expansion into
declarations, this extension becomes less critical, though it may still
be useful.]
---------------------------------------------------------------------------
Page 154:

Permit declarations before the body of a LABELS, FLET, or MACROLET.

===========================================================================
For the compiler committee:
---------------------------------------------------------------------------
A lot of compiler/eval-when issues need to be settled.  Among the
issues: Define clearly how REQUIRE interacts with the compiler.  Are
DEFSETF-generated available in the compiler environment by default?
---------------------------------------------------------------------------
Package interactions with COMPILE and LOAD need to be worked out better.
Restrict IN-PACKAGE, IMPORT, and firends to the start of files only?
Add a new declarative form to handle this?  Some favor legitimzing -*-
forms, but this is unacceptable to many.
---------------------------------------------------------------------------
Related issue: Add INCLUDE, or some other way to stuff multiple source
files into one binary?  (Package hackery makes this complicated.)
---------------------------------------------------------------------------
Related issue: There should be some discussion of the semantics of
compilation on literal constants (things appearing in quoted structure
in code).  To what degree is sharing and non-sharing preserved?  Many
implementations both introduce and remove sharing.  Probably most don't
dump circular structures.
---------------------------------------------------------------------------
What things can a compiler optimize by inline expansion, tail-recursion
elimination, etc.?  What things must be handled correctly if the user
redefines a built-in function (or specializes it using the object
facility)?

Proto-proposal: All built-in functions may be optimized inline
(and therefore do not respond to later modifcation) unless this is
inhibited with a NOTINLINE declaration.  Maybe create a list of
functions such as PRINT that are not open-coded by default.  Also,
within a DEFUN, a recursive call to the function being defined may be
optimizied into a jump, unless this is inhibited by NOTINLINE.  (Maybe
think up a better term than NOTINLINE.)
---------------------------------------------------------------------------


NEW:

Declare *print-circle* means to print out shared structure too. Alternative: add another variable *print-shared*. Alternative: add another value to *print-circle* (nil :none   t :unspecified :circular :shared).


∂22-Sep-87  1929	CARNESE@SPAR-20.ARPA 	Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]   
Received: from SPAR-20.ARPA by SAIL.STANFORD.EDU with TCP; 22 Sep 87  19:28:59 PDT
Date: Tue 22 Sep 87 19:27:09-PDT
From: Dan Carnese <CARNESE@SPAR-20.ARPA>
Subject: Re: [Dan Carnese <Carnese@SPAR-20.ARPA>: proposal]
To: Masinter.pa@XEROX.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870922-130335-12464@Xerox>
Message-ID: <12336785573.41.CARNESE@SPAR-20.ARPA>

My fault for dropping the ball on this discussion.

The two principal objections that have been made are:
	1) [RAM] Some uses of the proposed construct would not have
well-defined behavior under the current definition of Common Lisp.
	2) [JonL] Readability concerns argue that package structuring
should occur in a standard place.  This might be a special non-code file,
such as Mesa's module definitions, or at the start of each code file.

The response to 1) was:
	3) The new construct simply maps to existing ones.  Thus, if you
can define the correct behavior for existing constructs, the new one will
behave properly as well.

Although not explicitly stated, the response to 3) from Rob seems to be:
	4) Allowing package-related operations to occur anywhere in a file
is itself problematic and perhaps will be removed as part of a solution.
Since the proposed constructs will result in such operations, the constructs
should not be added to the language.

Here's where I pick up the ball again.  Suppose the language is changed so
that package operations are determinable without evaluating forms.  The
obvious ways to do this are compatible with the new construct.
	5a) The langauge could be changed so that a set of special forms
evaluated at read time would perform the package operations.  This might
involve changing existing functions (e.g., in-package and export) to have
read-time semantics, or introducing new functions which have such
semantics.  In either case, the proposed constructs would macro-expand into
a read-time export followed by the standard definition.
	5b) The langauge could be changed to require a standard header
which would not consist of forms to be evaluated, i.e., the file attribute
list approach.  Then the standard behavior for the proposed constructs
while reading a file would be to verify that the symbol being defined has
in fact been exported.  Of course it should also be possible to have the
constructs export the symbol rather than signalling an error, based on the
value of a global variable.

Under either of these approaches, the use of the proposed constructs can
allow the programming environment to help the user in the construction and
maintenance of export lists.  Editor commands such as "create export
declarations from exports of package", "compare export declarations with
current exports for package", and "undefun and unexport symbol" could be
defined.  Their availability would mean that the tedious task of keeping
the export declarations up to date could be largely automated.

The proposals involved objection 2) are similar to those described in 5b),
so the same line of reasoning applies.
-------

∂26-Sep-87  1740	Masinter.pa@Xerox.COM 	reply to yuasa message
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 26 Sep 87  17:40:28 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 26 SEP 87 17:41:03 PDT
Date: 26 Sep 87 17:40 PDT
From: Masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: reply to yuasa message
Message-ID: <870926-174103-17910@Xerox>

Feeling less presumptious than 	usual, I thought it would be
presumptuous of me to send this, which sounds like it speaks for
cl-cleanup, without checking it out with you. Opinions?


Subject: Re: Japanese Activities toward Lisp Standardization
In-reply-to:
yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay:CSNet:Xerox's message of
24 Sep 87 03:55
To: yuasa%kurims.kurims.kyoto-u.junet@utokyo-relay.cs.net

In the United States, the X3J13 committee of ANSI is progressing toward
establishing a standard for Lisp. As with TG/A, X3J13 has agreed that
Common Lisp is a good starting point for technical discussions.  We have
also been discussing various technical deficiencies of Common Lisp and
proposals for their correction.

The Lisp community as a whole can be best served if there are not too
many standards. We would like to invite a member TG/A to participate in
the  discussions of the "cleanup" working group of X3J13, and to bring
forward those technical deficiencies that are of most serious concern to
TG/A. Fortunately, almost all of our work goes on using electronic mail.
We would welcome active participation, argumentation, proposals and
criticisms. 



 

∂26-Sep-87  2000	gls@Think.COM 	reply to yuasa message   
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 26 Sep 87  20:00:14 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Sat, 26 Sep 87 23:00:24 EDT
Received: by kali.think.com; Sat, 26 Sep 87 23:00:41 EDT
Date: Sat, 26 Sep 87 23:00:41 EDT
From: gls@Think.COM
Message-Id: <8709270300.AA02152@kali.think.com>
To: Masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 26 Sep 87 17:40 PDT <870926-174103-17910@Xerox>
Subject: reply to yuasa message

Looks okay to me.
--Guy

∂26-Sep-87  2030	FAHLMAN@C.CS.CMU.EDU 	reply to yuasa message 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 26 Sep 87  20:30:44 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sat 26 Sep 87 23:31:06-EDT
Date: Sat, 26 Sep 1987  23:31 EDT
Message-ID: <FAHLMAN.12337845783.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: reply to yuasa message
In-reply-to: Msg of 26 Sep 1987  20:40-EDT from Masinter.pa at Xerox.COM


Looks OK to me, too.

∂28-Sep-87  0910	Moon@STONY-BROOK.SCRC.Symbolics.COM 	reply to yuasa message 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 28 Sep 87  09:09:54 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 242883; Mon 28-Sep-87 12:10:47 EDT
Date: Mon, 28 Sep 87 12:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: reply to yuasa message
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <870926-174103-17910@Xerox>
Message-ID: <870928121053.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

I have no problems with this.

∂08-Oct-87  1655	Masinter.pa@Xerox.COM 	Issue: PATHNAME-STREAM (Version 4)   
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 8 Oct 87  16:55:44 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 08 OCT 87 16:17:35 PDT
Date: 8 Oct 87 16:17 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-STREAM (Version 4)
TO: CL-Cleanup@sail.stanford.edu
CC: MASINTER.pa@Xerox.COM
Message-ID: <871008-161735-1333@Xerox>

This issue passed conditionally last meeting, pending a change in the
wording to not restrict streams with pathnames to "files", since some
users model a "device" as something that isn't a "file". I rewrote the
description and edited the language of other parts of the proposal.

!
Issue:         PATHNAME-STREAM

References:    PATHNAME (p.413), also the introductory text right above
               it on the same page.
               Derived references: PARSE-NAMESTRING (p.414),
               MERGE-PATHNAMES (p.415), PATHNAME-HOST etc. (p.417),
               OPEN (p.418), WITH-OPEN-FILE (p.422),
               RENAME-FILE (p.423), DELETE-FILE (p.424)

Edit History:  Version 1 by Moon 11-May-87
               Version 2 by Masinter 29-May-87 (minor editing)
               Version 3 by Masinter 11-Jun-87 (minor editing)
               Version 4 by Masinter  8-Oct-87 (rewording)



Category:     	CHANGE/CLARIFICATION

Problem Description:

CLtL says that a stream can be used as an argument and converted to a
pathname, but many sources or sinks of data that streams might be
connected to have no pathnames associated with them; for example,
streams created with make-two-way-stream or open-string-stream. There is
no reasonable way to coerce such a stream to a pathname.

Proposal PATHNAME-STREAM:FILES-ONLY:

Clarify that the use of a stream as an argument that expects a pathname
(as described on p413 of CLtL) only applies to streams that are
originally opened by use of the OPEN, WITH-OPEN-FILE or the like. For
example, it is an error to attempt to obtain a pathname from a
two-way-stream or a string-stream. 

Rationale:

This is probably what the designers of Common Lisp intended. This is the
only thing that can be implemented without large changes to the language
such as extending pathnames to things other than files. 

Current Practice:

Some systems signal an error if a non-file stream is used as a pathname.

Adoption Cost:

Since the proposal says only "is an error" rather than "signals an
error", no implementations need change.

Benefits:

The description of pathname functions will make more sense.

Conversion Cost:  None.  

Aesthetics: Makes language a little cleaner.

Discussion: The cleanup committee supports this clarification.

∂09-Oct-87  0927	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-STREAM (Version 4)    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Oct 87  09:27:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 252443; Fri 9-Oct-87 12:25:07 EDT
Date: Fri, 9 Oct 87 12:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-STREAM (Version 4)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <871008-161735-1333@Xerox>
Message-ID: <871009122453.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

This looks okay to me.  There is one typographical error.  In

  Clarify that the use of a stream as an argument that expects a pathname
  (as described on p413 of CLtL) only applies to streams that are
  originally opened by use of the OPEN, WITH-OPEN-FILE or the like.
                              |
the word "the" should be removed or the phrase should be changed
to "the OPEN function".

∂09-Oct-87  0927	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: PATHNAME-STREAM (Version 4)    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 9 Oct 87  09:27:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 252444; Fri 9-Oct-87 12:25:58 EDT
Date: Fri, 9 Oct 87 12:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-STREAM (Version 4)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <871008-161735-1333@Xerox>
Supersedes: <871009122453.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Forgot about synonym streams.
Message-ID: <871009122541.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

This looks okay to me.  There is one typographical error.  In

  Clarify that the use of a stream as an argument that expects a pathname
  (as described on p413 of CLtL) only applies to streams that are
  originally opened by use of the OPEN, WITH-OPEN-FILE or the like.
                              |
the word "the" should be removed or the phrase should be changed
to "the OPEN function".

Oh, also, a synonym stream whose target is an acceptable stream is
also acceptable, right?

∂09-Oct-87  1408	Masinter.pa@Xerox.COM 	Re: Issue: PATHNAME-STREAM (Version 4)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 87  14:07:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 87 14:07:23 PDT
Date: 9 Oct 87 14:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-STREAM (Version 4)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 9 Oct 87 12:25 EDT
To: CL-Cleanup@sail.stanford.edu
Message-ID: <871009-140723-1578@Xerox>

> Oh, also, a synonym stream whose target is an acceptable stream is
also acceptable, right?

I think not. I think the idea is to push the specification described by
the language on p. 417 ("The pathname argument may be a pathname, a
string or symbol, or a stream that is or was open to a file") back to
cover more generally all of the functions in CL which take pathname
arguments, rather than the weaker specification of p. 413 ("Any argument
called pathname in this manual may actually be a pathname, a string or
symbol, or a stream.")

If you hand a stream to a function that expects a pathname, does it
coerce it to (pathname stream) or to (truename stream)? 

What is the difference between (pathname x) and (parse-namestring x)? 


What are the constraints that (pathname stream) has to follow, e.g., if
you do an open the result, should the stream have the same data?  

The reason why synonym streams are suspect is that I presume that
(pathname stream) should be time invarant, e.g., you should get the same
pathname given the same stream no matter when you execute it. Following
synonym streams would violate that invarant. 


∂09-Oct-87  1419	Masinter.pa@Xerox.COM 	Re: Issue: PATHNAME-STREAM (Version 4)    
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 87  14:07:53 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 87 14:07:23 PDT
Date: 9 Oct 87 14:07 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-STREAM (Version 4)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 9 Oct 87 12:25 EDT
To: CL-Cleanup@sail.stanford.edu
Message-ID: <871009-140723-1578@Xerox>

> Oh, also, a synonym stream whose target is an acceptable stream is
also acceptable, right?

I think not. I think the idea is to push the specification described by
the language on p. 417 ("The pathname argument may be a pathname, a
string or symbol, or a stream that is or was open to a file") back to
cover more generally all of the functions in CL which take pathname
arguments, rather than the weaker specification of p. 413 ("Any argument
called pathname in this manual may actually be a pathname, a string or
symbol, or a stream.")

If you hand a stream to a function that expects a pathname, does it
coerce it to (pathname stream) or to (truename stream)? 

What is the difference between (pathname x) and (parse-namestring x)? 


What are the constraints that (pathname stream) has to follow, e.g., if
you do an open the result, should the stream have the same data?  

The reason why synonym streams are suspect is that I presume that
(pathname stream) should be time invarant, e.g., you should get the same
pathname given the same stream no matter when you execute it. Following
synonym streams would violate that invarant. 


∂09-Oct-87  1457	Masinter.pa@Xerox.COM 	Issue: STREAM-CLASS-ACCESS 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 87  14:56:52 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 87 14:57:30 PDT
Date: 9 Oct 87 14:57 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: STREAM-CLASS-ACCESS
To: cl-cleanup@Sail.stanford.edu
Message-ID: <871009-145730-1702@Xerox>

(This issue was called FOLLOW-SYNONYM-STREAM in the original message by
KMP).

I vaguely remember this being discussed before but cannot find the mail.
I would prefer an extension for accessing the constructed streams that
treated them as if they were constructed by DEFSTRUCT or DEFCLASS, viz:

 As if: (defstruct (synonym-stream (:constructor (make-synonym-stream
(symbol))) symbol)
 => (make-synonym-stream symbol) as in CLtL
       (synonym-stream-p object)
       (synonym-stream-symbol synonym-stream)



As if: (defstruct (broadcast-stream (:constructor (make-broadcast-stream
(&rest streams))) streams)
=> (make-broadcast-stream &rest streams) is in CLtL
       (broadcast-stream-p object)
       (broadcast-stream-streams broadcast-stream)

As if: (defstruct  (two-way-stream (:constructor (make-two-way-stream
(input-stream output-stream))
     => (make-two-way-stream input-stream output-stream) 
          (two-way-stream-p object)
         (two-way-stream-input-stream two-way-stream)
         (two-way-stream-output-stream two-way-stream)

(The reason that I think I remember previous mail is that I remember a
discussion of whether it should be input-stream output-stream or just
input and output to shorten the names two-way-stream-input and
two-way-stream-output.)

(defun follow-synonym-stream (stream)
   (if (synonym-stream-p stream)
    (follow-synonym-stream (symbol-value (synonym-stream-symbol
stream)))
    stream))

∂09-Oct-87  1524	Masinter.pa@Xerox.COM 	Issue: DEFINITION-FUNCTIONS
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 87  15:23:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 87 15:20:50 PDT
Date: 9 Oct 87 15:20 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: DEFINITION-FUNCTIONS
to: cl-cleanup@Sail.stanford.edu
Message-ID: <871009-152050-1749@Xerox>


I promised I would submit a proposal for "named definitions" for making
documentation etc more extensible in Common Lisp.  I don't have a formal
proposal, but I've been sitting on this  very rough draft...  


- - - - 
A "definition type" a symbol, like one of the following
	function (including defun, defmacro, define-modify-macro...)
	setf  
	variable
	type


Definition types are used by several functions, including DOCUMENTATION.

A defining form, such as a form introduced with DEFUN, DEFSTRUCT, or
whatever, is said to give a given definition type to a specific name.
Frequently, a definition name is a symbol, but need not be.

(definition-type form)
     Given a form (such as DEFUN, DEFMACRO and the like) returns the
type of thing defined by it.
      (Can be either a form or else the symbol that introduces such a
form).
     DEFSTRUCT, DEFTYPE => TYPE
     DEFMACRO, DEFUN, DEFINE-MODIFY-MACRO, ... => FUNCTION
     DEFSETF => SETF
     DEFVAR, DEFPARAMETER, DEFCONST => VARIABLE

(definition-name form)
      Given a form (no symbol allowed), returns the name of the thing
defined. Often SECOND, but e.g.
     with DEFSTRUCT might do more processing.


(documentation name definition-type)
	As before, type can be any definition type.

(delete-definition name definition-type)
	delete all effects of name having a definition of type
	(delete-definition name 'function)  replaces (fmakunbound name)

	(delete-definition name 'variable)  replaces (makunbound name)

For adding more:

(def-definition-type type-name description &key undefiner)
	Define type-name as a new kind of definition type.
	Undefiner is a function which will remove a definition


(defdefiner definer-name type &key undefiner name-function)
	says that definer-name defines things of type.
	Undefiner says how to remove 'em
	name-function, defaults to second, says, given an expression
		which starts with definer-name, what the name of the thing is, e.g.,

	(defdefiner defun function :undefiner #'fmakunbound :name-function
#'second)

	(defdefiner defstruct type :undefiner #'si:remove-structure-definition
			:name-function #'(lambda (x) (if (consp (second x)) (car (second x))
(Second x)))))

	Note that when you undefine a name using delete-definition, *all* of
the known undefiners
	(both the general one supplied with def-define-type and the specific
one defined
	for each definer with defdefiner) are applied. The undefiner should not
error
	if there is no definition. 

	function is defined by (DEFINE-MODIFY-MACRO DEFMACRO DEFUN) 
	type is defined by  DEFTYPE DEFSTRUCT
	variable is defined by  DEFCONSTANT DEFPARAMETER DEFVAR
	setf is defined by DEFSETF and DEFINE-SETF-METHOD
	define-type is defined by DEF-DEFINE-TYPE


(ed name &optional type)  
	Optional type allows you to say which definition if there is more than
one.

- - - - - - - - - - -
The following make sense in some environments:


(has-definition-p name definition-type &key)
	True if name has some definition of given type 

(symbol-definition-types name)
	Return list of all types for which name has a definition

- - - - - - - - -

With the error proposal, DEFINE-PROCEED-FUNCTION would define function,
too.
With CLOS, DEFCLASS would define a class.

This is awkwardly said, so I may have to explain it better: definers are
for things that define the *whole thing*, for which other definitions
are mutually exclusive.  Thus, a defmethod doesn't define the generic
function, it only defines a piece of the generic function. So (defmethod
frob ((a widget) ...) ...) can't be a "definer" for the function frob. 

There is some design choice of whether it is a definer for the function
(:method frob widget) (since definition names need not be symbols) or
whether it is the definer for the method (frob widget).  I think this
need not be nailed down by the definition protocol.

I think this is separate from the "function spec" proposal because
"function specs" have to do with identifying pieces of executable code
which might have breakpoints, etc. assigned to them.

∂09-Oct-87  1524	Masinter.pa@Xerox.COM 	Issue Status (reply solicited)  
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 9 Oct 87  15:24:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 09 OCT 87 15:22:42 PDT
Date: 9 Oct 87 15:22 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue Status (reply solicited)
to: CL-CLEANUP@Sail.stanford.edu
cc: Masinter.pa@Xerox.COM
line-fold: 80
Message-ID: <871009-152242-1753@Xerox>

This is a revised version of the status file I sent out 22-Sep-87. I
have now gone through the mail I have on each issue, and attempted to
reflect what I think the current status is. As usual, if you want a copy
of the issue to refresh your memory or your mail archive, let me know.
(Someday I will be able to store these on a directory you have access
to.)

In some cases, I've indicated a question ???? on whether an item is
ready to release. I'd like everyone to reply, either with an accept,
don't care, or object on each releasable item. 


Annotations:
* ready for release (I think)
< already approved, no more action pending.
{ awaiting action from some other committee
???? A question: Please reply.
~ Tabled until resubmitted, i.e., no immediate action proposed.


In particular, if it says "???? Ready for release with endorsement", I
propose to edit the last submitted version of the proposal as sent to
CL-CLEANUP to include the statement that the cleanup committee endorses
the proposal, and send it on to X3J13. A simple one-line "please don't
release yet" reply will suffice. 

!
* Proposal format (Version 12)
 Format for proposals to the cleanup committee.
 Version 11 released 11-Jun-87.
???? Release version 12 with "Related issues" field? 

ADJUST-ARRAY-DISPLACEMENT (Version 3 / 5-jun-87)
 (Standardize interaction of adjust-array and displacement)
 Discussion about :displaced-to nil vs. no :displaced-to.
 Need volunteer to revise, clarify :displaced-to ommitted
      same as :displaced-to nil.
 Not ready for release.

ADJUST-ARRAY-FILL-POINTER-SOURCE (not yet submitted - from ISSUES file)
 (p 297) "Specify that the fill pointer is ignored for the
 purposes of deciding whether a given element of a new array
 resulting from ADJUST-ARRAY should take its value from the
 old array contents or from the specified :INITIAL-ELEMENT."

ADJUST-ARRAY-NOT-ADJUSTABLE (version 1/22-apr-87)
 (Extend adjust-array so its OK on non-adjustable arrays.)
 Several comments which need reply
 Not ready for release.
 Notes from boston cl-cleanup meeting have *, but
  the mail traffic seems inconclusive.

APPEND-DOTTED (version 1/27 Jul 87)
 Sumbitted by KMP.
 Need mod to Current Practice
 Mention (append () t), clarify NCONC?
 Not ready for release.

APPLY-HOOK-SPECIAL-FORMS (not yet submitted/from ISSUES file) 
 (p 322) At end of second paragraph on *APPLYHOOK*,
 clarify that the apply hook function is not used
 when special forms are evaluated.
 Need volunteer[lmm?] to submit.

* AREF-1D (Version 6/6 JUL 87)
 (Add a new function for accessing arrays with row-major-index)
 Version 5 conditionally passed at X3j13/Jun87 pending new version.
 Version 6 mailed to cl-cleanup 6Jul.
???? Ready for release with endorsement?

ASSOC-RASSOC-IF-KEY (Version 2/15-Jun-87)
 (Extend ASSOC-IF, etc.  to allow :KEY)
 Needs revision of current practice, test case, example.
 (Only Symbolics is known to implement this feature)
 The summary says Version 2, but I only have version 1 on file.
 Not ready for release
???? Does anyone else have a version 2? Or was this wishful thinking?

{ COMPILER-WARNING-BREAK (Version 2/7-Apr-87)
 (Does *BREAK-ON-WARNING* affect the compiler?)
 Questions on interaction with condition proposal. 
 Postponed pending error proposal

< COMPILER-WARNING-STREAM (Version 6/ 5-Jun-87)
 (Compiler warnings are printed on *ERROR-OUTPUT*)
 Version 6 passed X3J13/Jun87.

CONSTANT-SIDE-EFFECTS (not yet submitted)
   (it is an error to do destructive operations on constants in code,
   defconstant.)
   Discussed 12/86 - 1/87
   Need volunteer to submit

DECLARATION-SCOPE (not yet submitted)
   (What is the scope of SPECIAL declarations?
   INLINE declarations? where can declarations be placed?)
   Discussed at length, but no formal proposals.

DEFINITION-FUNCTIONS (not yet submitted)
  (Extensions for documentation-type for delete-definition
  for type FUNCTION, VARIABLE, TYPE. )
  Rough draft mailed  9-Oct-87.
  Very preliminary.

{ 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."
   Await object proposal.

{ 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."
  Await object proposal.

* DEFVAR-DOCUMENTATION (Version 1/30-Jun)
   (Documentation string is not evaluated.)
   Submitted, no replies
???? Ready for release with endorsement?

< DEFVAR-INITIALIZATION (Version 4/Jun-87)
 ((DEFVAR var) doesn't initialize)
 Version 4 passed X3J13/Jun87.

< DEFVAR-INIT-TIME (Version 2/29-May-87)
 (DEFVAR initializes when evaluated, not later.)
 Version 2 passed X3J13/Jun87.

DISASSEMBLE-SIDE-EFFECT (not yet submitted/from ISSUES.TXT)
 "Clarify that if DISASSEMBLE is given a symbol whose function
 definition is interpreted, that definition is indeed compiled
 and then disassembled, but the resulting compiled definition
 does not replace the interpreted one as the symbol's function
 definition."
 Need volunteer to submit.

DO-SYMBOLS-DUPLICATES (Version 2/29-May-87)
 (can DO-SYMBOLS see the same symbol twice?)
 Debate: extend so that both options are available?
 Needs more information on implementation and
   performance cost.
 Masinter will rewrite, flush :ALLOWED option,
  rewrite :ADD-KEYWORDS to make default for
  :ALLOW-DUPLICATES as NIL., conversion cost => nil.
 Not ready for release.

EVAL-DEFEATS-LINKER (Version 1/12 Jun-87)
 ("selective linking" means GC non-used symbols; 
 proposal to change #., #, and part of FUNCTION-TYPE)
   Postpone pending FUNCTION-TYPE resolution & 
	handle remainders.

EXPORT-COORDINATION (no formal proposal)
  Coordinate EXPORT and DEFxxx by adding new form.
  Is this a good idea to allow?
  Not yet formally submitted.
  Looking for proposal to make package manipulation lexical.

{ FILE-WRITE-DATE-IF-NOT-EXISTS (from Weinreb, no fromal 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.

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.

< 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 1/10 June 87)
 (Allow another argument to ~D etc to paramerize digits between commas)
???? Ready for release with endorsement?

FORMAT-NEGATIVE-PARAMETERS (mail 19 May, no formal proposal)
  "format parameters are assumed to be non-negative integers except
    as specifically stated"
Need volunteer to write up.

< FORMAT-OP-C (Version 5/ 11-Jun-87)
 (What does ~C do?)
 Version 5 passed X3J13/Jun87.

FUNCTION-TYPE (Version 5/ 16-Jun-87)
 (Change definition of FUNCTIONP, function type ...)
 Draft released 16-Jun-87.
 Discussed at X3J13, new proposal due.


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.
 Need volunteer to submit.

FUNCTION-SPECS (not yet submitted)
   (add "function specs" for defun, trace
  etc) Mail from Moon 16-Jun. 
  cf SETF-FUNCTION-VS-MACRO.

GC-MESSAGES (version 1)
 (Control over unsolicited GC messages in typescript)
 merge with other controls for unsolicited messages?
 Not ready for release.
 Pitman volunteered to revise.

* GET-SETF-METHOD-ENVIRONMENT (Version 5, 13-Jun-87)
 (Environment argument for GET-SETF-METHOD)
 Version 4 conditionally passed X3J13/Jun87.
 Version 5 mailed 13-Jul-87 13:18:47 
???? release with endorsement

{ 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) 
 Pitman will release as report from cleanup + error committee.
 Awaiting error proposal

< IMPORT-SETF-SYMBOL-PACKAGE (Version 5/ 11-Jun-87)
 (Does IMPORT affect home package?)
 Version 5 passed X3J13/Jun87.

* KEYWORD-ARGUMENT-NAME-PACKAGE (Version 6/11 Jun 87)
 ( &KEY arguments not in keyword package?)
 Version 6 conditionally passed X3J13/Jun87.
 Rewrite using CLOS terminology ("named argument")
 instead of  "keyword argument".
 Need volunteer to rewrite

LISP-SYMBOL-REDEFINITION  (no formal proposal yet)
  Is it legal to redefine symbols in the LISP package?
  Mail 14-Aug-87

LOAD-TIME-EVAL (Version 2, 17-JUL-87)
 (New function/macro/special form for evaluation when 
 compiled file is loaded?)
 No discussion after Version 2.
???? ready for release with endorsement ?

MACRO-FUNCTION-ENVIRONMENT 
 (Add environment argument to MACRO-FUNCTION?)
 From ENVIRONMENT-ARGUMENTS
 Formal proposal not yet submitted.
 re-extract from environment-arguments?
???? drop this issue ?

* OPEN-KEYWORDS-EXISTS (Version 1/17-Jul-87)
  No discussion.
???? Ready for release ?

* PATHNAME-STREAM (Version 4)
 (PATHNAME only works on file streams)
 Version 2 conditionally passed X3J13/Jun 87
???? Ready for release ?

PATHNAME-SUBDIRECTORY-LIST (Version 1/18-Jun-87)
  How to deal with subdirectory structures in pathname functions?
  Proposal for :SUBDIRECTORY rejected; make :DIRECTORY a structure?
  Needs revision

PATHNAME-SYMBOL (Version 2)
 (Do symbols automaticly coerce to pathnames?)
 Not ready for release.
 Needs to be revised, extend language, clarify
   which functions are affected, etc.

PATHNAME-UNSPECIFIC-COMPONENT (not yet submitted)
  Mail Aug 87 discussion
  How to deal with logical devices, :unspecific components,
    etc in pathname functions

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."
???? Disposition?

< PRINC-CHARACTER (Version 3)
 (PRINC behavior on character objections)
 Version 3 passed X3J13/Jun87.

PROCLAIM-LEXICAL  (Version 1)
 (add LEXICAL proclaimation, default binding type for
  undeclared free variables)
 Not ready for release.
 This got sidetracked. Lets try to hash this one out.

~ PROMPT-FOR (Version 1)
 (add new function which prompts)
 Tabled until re-submitted.

PUSH-EVALUATION-ORDER (not yet submitted)
 (What order does (PUSH (A) (CAR (B))) evaluate (A) and (B)?)
 Also INCF, PUSHNEW, etc.
 (Mail 20 May 87)
 (cf SETF-METHOD-FOR-SYMBOL).

REMF-DESTRUCTION-UNSPECIFIED (Version 1)
 (How does REMF affect its arguments?)
 Found some discussion dated Feb 87.
???? Pitman will revise & resubmit. ?

SETF-METHOD-FOR-SYMBOL (Version 1, 21-Sep-87)
  In discussion.
  "Maybe we should fix the definition for setf of ldb rather than
  the values returned for symbol?"
  Not ready for release.

SETF-FUNCTION-VS-MACRO (not yet submitted)
  Proposal in circulation on CLOS discussion for allowing
  (DEFUN (SETF FOO) (new-value ... arguments) ...)
  "Fixing our problems with setf"

 
* SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 2, 28-Apr-87)
 (FIND, SUBSTITUTE etc work on multi-dimensional arrays?)
 No discussion since May-87
???? Release GENERALIZE option?

* SHADOW-ALREADY-PRESENT (Version 2, 27 Aug 87)
  Revised according to discussion
???? Ready for release?

{ SHARPSIGN-BACKSLASH-BITS
 (What does C-META-H-X mean?)
 Forwarded to character committee.

~ SHARPSIGN-PLUS-MINUS-NUMBER
 (Is #+68000, #-3600 allowed?)
 Mild disagreement: it is an error?
 Table until resubmitted

SHARPSIGN-PLUS-MINUS-PACKAGE (version 2, 9-Mar-87)
 (What package are *features* in?)
 Mild support for :KEYWORD
???? Report out with only :KEYWORD proposal?

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)

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.

UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT (Version 1)
 (GO out of UNWIND-PROTECT clauses.)
 Not ready for release.
 Gabriel will revise & resubmit?

∂15-Oct-87  1411	@STONY-BROOK.SCRC.Symbolics.COM,@EUPHRATES.SCRC.Symbolics.COM:Moon@STONY-BROOK.SCRC.Symbolics.COM 	SETF-FUNCTION-VS-MACRO (Version 1)  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Oct 87  14:10:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 256462; 15 Oct 87 17:11:02 EDT
Date: Thu, 15 Oct 87 17:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SETF-FUNCTION-VS-MACRO (Version 1)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19871015211100.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

ISSUE:         SETF-FUNCTION-VS-MACRO

REFERENCES:    setf rules for what -place- can be (pp.94-7)
               compile function (p.438)
               defun macro (p.57)
               disassemble function (p.439)
               documentation function (p.440)
               fboundp function (p.90)
               flet special form (p.113)
               fmakunbound function (p.92)
               ftype declaration (p.158)
               function special form (p.87)
               function declaration (p.159)
               inline declaration (p.159)
               notinline declaration (p.159)
               labels special form (p.113)
               symbol-function and setf of symbol-function (p.90)
               trace macro (p.440)
               untrace macro (p.440)

CATEGORY:      ADDITION

EDIT HISTORY:  Version 1, 13-Oct-87 Moon
		   (based on discussion among the CLOS working group)

PROBLEM DESCRIPTION:

The Common Lisp Object System needs a well-defined way to relate the
name and arguments of a setting function to those of a reading function,
because both functions can be generic and can have user-defined methods.
We tried to hide the name and arguments of the setting function with
macrology, but the complexity got out of hand.  It seems better to make
this information explicit; the version of the CLOS specification that
assumes the adoption of proposal SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
is much simpler in the relevant areas.

PROPOSAL (SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS): 

Add to Common Lisp the concept of "setf functions".  Right now, Common
Lisp only has "setf macros", which are defined by define-setf-method and
both forms of defsetf.  Terminology:
  - a "setf macro" is something that produces code (or other
    specifications, as in define-setf-method) which, when evaluated,
    will perform the effect of an invocation of setf.
  - a "setf function" is something that is called to perform
    directly the effect of an invocation of setf.

The form (setf (-name- ...) ...), when -name- is defined as a function
(rather than a macro) and no setf macro has been defined for -name-,
expands into a call to a setf function.  The name of this setf function
is a list (setf -name-), where -name- is a symbol.  The functions,
macros, and special forms defined in CLtL and listed in the References
section above need to be enhanced to accept such lists in addition to
symbols as function names, so that setf functions can be defined and
manipulated.

A setf function receives the new value to be stored as its first
argument.  Thus, #'(setf foo) should have one more required parameter
than #'foo, the first required parameter is the new value to be stored,
and the remaining parameters should be the same as #'foo's parameters.

A setf function must return its first argument, since setf is defined
to return the new value.

A definition of a setf function can be lexically local, like a
definition of a reading function.  The following rules specify the
behavior of SETF; note that these rules are ordered and the first rule
to apply supersedes any later rules.  These rules are a consistent
extension of the current behavior of Common Lisp and the Cleanup
committee's resolution of issue GET-SETF-METHOD-ENVIRONMENT.  Only
rule 4 is new with this proposal.

Rules for the macroexpansion of (setf (foo x) y):

(1) If the function-name foo refers to the global function definition,
rather than a locally defined function or macro, and if there is a
setf macro defined for foo, use the setf macro to compute the expansion.

(2) If the function-name foo is defined as a macro in the current scope,
use macroexpand-1 to expand (foo x) and try again.

(3) If the function-name foo is defined as a special form in the current
scope, signal an error.

(4) Expand into the equivalent of
    (let ((#:temp-1 x)		;force correct order of evaluation
          (#:temp-2 y))
      (funcall #'(setf foo) #:temp-2 #:temp-1))

Note that rule 4 is independent of the scope of the function name
(setf foo).  It does not matter if that scope is different from the
scope of the function name foo.  This allows some nonsensical programs
to be written, but does not seem harmful enough to justify making more
complicated rules to compare the scopes of the two function definitions.

The above rules are actually implemented by GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE, rather than by the SETF macro itself.
Thus GET-SETF-METHOD generates the appropriate five values for a form
that is not a macro-invocation and does not have a defined setf macro.

Normally one does not define both a setf function and a setf macro
for the same reading function.

Normally one defines a local reading function and a local setf function
together in a single FLET or LABELS.

In the absence of any setf macro definition, SETF of a function expands
into a call to the setf function.  This means that the setf function
only needs to be defined at run time, not compile time.

TEST CASE:  (really more examples than test cases)

;If setf of subseq was not already built into Common Lisp,
;it could have been defined like this
(defun (setf subseq) (new-value sequence start &optional end)
  (unless end (setq end (length sequence)))
  (setq end (min end (+ start (length new-value))))
  (do ((i start (1+ i))
       (j 0 (1+ j)))
      ((= i end) new-value)
    (setf (elt sequence i) (elt new-value j))))

;Another example, showing a locally defined setf function
(defun frobulate (mumble)
  (let ((table (mumble-table mumble)))
    (flet ((foo (x)
             (gethash x table))
           ((setf foo) (new x)
             (setf (gethash x table) new)))
      ..
      (foo a)
      ..
      (setf (foo a) b))))

;get-setf-method could implement setf functions by calling
;this function when rules 1-3 do not apply
(defun get-setf-method-for-setf-function (form)
  (let ((new-value (gensym))
	(temp-vars (do ((a (cdr form) (cdr a))
			(v nil (cons (gensym) v)))
		       ((null a) v))))
    (values temp-vars (cdr form) (list new-value)
	    `(funcall #'(setf ,(car form))
		      ,new-value ,@temp-vars)
	    `(,(car form) ,@temp-vars))))

RATIONALE:

By making the names and arguments of setting functions explicit, CLOS is
considerably simplified.  In addition, this can supersede any proposals
to introduce a lexically local form of defsetf; lexically local setf
functions serve the same needs.

Current code that resembles

 (defsetf foo |setf FOO|)
 (defun foo (x) ..)
 (defun |setf FOO| (x new) ..)

or

 (defsetf foo internal-foo-setter)
 (defun foo (x) ..)
 (defun internal-foo-setter (x new) ..)

can be, but is not required to be, replaced with the following code

 (defun foo (x) ..)
 (defun (setf foo) (new x) ..)

An advantage of this is that several disparate styles of using
defsetf can be replaced with a single common style of using
setf functions, making programs more standardized and readable.

CURRENT PRACTICE:

A few Common Lisp implementations already have a similar feature,
in that they have setting functions named (SETF reader).  I don't
know of any implementation that has precisely the proposed feature.

ADOPTION COST:

The main cost is generalization of a few functions to accept lists
beginning with SETF where they now accept only symbols.  Implementations
must add a data structure to store the function definition of a setf
function, however, this can trivially be done with property lists or
generated symbols.

The cost of making the SETF macro expand into a call to a setf function,
when it does not find a setf macro or a regular macro to expand, is
negligible.

This will be an incompatible change for Symbolics, since it already has
setf functions but they do not take the same arguments as proposed here.
However, the change is considered worthwhile.

COST OF NON-ADOPTION:

Non-adoption of this proposal would be a significant roadblock to the
Common Lisp Object System.  Some major rethinking of CLOS would be
required.

BENEFITS:

Allow CLOS to be defined without out-of-hand complexity.

CONVERSION COST:

None, this is an upward-compatible change.

ESTHETICS:

SETF would be more esthetic, but less powerful, if it had only the
proposed setf functions and did not have setf macros.  Such a major
incompatible change is of course out of the question, however by
stressing setf functions rather than setf macros SETF could become
easier to teach.

DISCUSSION:

Note that in Common Lisp, setf macroexpansion is an operation on
function names, not on functions.  It differs from some dialects of
Scheme, such as T, in this respect.  This proposal does not attempt to
change that.

The following related features were considered but are specifically
not being proposed at this time, since they are unnecessary for CLOS
and appear not to improve the simplicity and esthetics of the language:

  Lexically local setf macros, that is, a cross between defsetf and
  macrolet.  This does not appear to be logically necessary.  Do all three
  ways of defining lexically global setf macros need local counterparts?
  
  Should we define the meaning of defmacro or macrolet of (setf foo)?
  This would be a fourth way to define a setf macro.
  
  Should we enhance the definition of global setf macros, for example to
  say that (macro-function '(setf foo)) returns an expander function that
  takes two arguments and returns five values?
  
  Should we introduce a new name for symbol-function, since it accepts
  non-symbols now?


∂15-Oct-87  1725	FAHLMAN@C.CS.CMU.EDU 	SETF-FUNCTION-VS-MACRO (Version 1)    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 87  17:24:59 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 15 Oct 87 20:21:44-EDT
Date: Thu, 15 Oct 1987  20:21 EDT
Message-ID: <FAHLMAN.12342792040.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: SETF-FUNCTION-VS-MACRO (Version 1)
In-reply-to: Msg of 15 Oct 1987  17:11-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


I have no problem with this proposal, except for the notion that the
name of the setf-function associated with FOO should be a list, (SETF
FOO).  This seems like a more radical change than is really necessary to
accomplish the stated purposes.  It is a considerable extension to the
idea of a "function name", at least for standard Common Lisp
implementations that do not implement Lisp machine style function-specs.

Would it not be simpler to introduce a new setf-able access function
GET-SETF-FUNCTION which takes a symbol and returns the associated SETF
function?  Under Moon's proposal a SETF form expands into something like
(funcall #'(setf foo) ...).  This would become (funcall
(get-setf-function foo)...).  I assume that in either case one must use
an explicit funcall and not just drop this "name" into the car-position
of an expression to be evaluated.

The one problem I can see with this alternative proposal is that it
there is no very good way to do something like FLET for the setf
function if there is not a name-like entity that can be bound.  Is that
the reason for introducing this new kind of "name" instead of just
setting up the association with a setf-able function?  Of course, we
could arbitrarily add some tweak to FLET that would locally rebind the
setf-function, but maybe Moon's scheme is more regular after all.

If we do go ahead with Moon's proposal in its current form, it would be
a good idea to address this concern and why something like the
alternative discussed here is not a better choice.

I assume that this would not preclude the addition of something like the
function specs that are present on the Lisp machine?  If we finally
decide that Common Lisp is going to remain a Lisp-2, then we might want
to look at that whole issue again.

-- Scott

∂15-Oct-87  1738	Moon@STONY-BROOK.SCRC.Symbolics.COM 	SETF-FUNCTION-VS-MACRO (Version 1)    
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Oct 87  17:38:43 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 256662; Thu 15-Oct-87 20:39:42 EDT
Date: Thu, 15 Oct 87 20:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SETF-FUNCTION-VS-MACRO (Version 1)
To: Scott E. Fahlman <Fahlman@C.CS.CMU.EDU>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <FAHLMAN.12342792040.BABYL@C.CS.CMU.EDU>
Message-ID: <19871016003933.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 15 Oct 1987  20:21 EDT
    From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>

    I have no problem with this proposal, except for the notion that the
    name of the setf-function associated with FOO should be a list, (SETF
    FOO).

    Would it not be simpler to introduce a new setf-able access function
    GET-SETF-FUNCTION which takes a symbol and returns the associated SETF
    function?  

The CLOS committee tried that for a long time, but it doesn't work.
Fundamentally the problem is that there has to be a name that the user
uses to define the thing and to talk about it.  Trying to hide the name
just means you use a more obscure name, like an alternate syntax for
DEFUN or DEFUN-SETF or something.

    The one problem I can see with this alternative proposal is that it
    there is no very good way to do something like FLET for the setf
    function if there is not a name-like entity that can be bound.  

Precisely.  That's the reason for making the name explicit.

    I assume that this would not preclude the addition of something like the
    function specs that are present on the Lisp machine?

Right.  There could be other function names that are not symbols, however
we don't really need to propose any others for CLOS.

    I assume that in either case one must use
    an explicit funcall and not just drop this "name" into the car-position
    of an expression to be evaluated.

Yes, the extra complexity of allowing something new in the car of a form
didn't seem to be justified.  I guess I should have listed that among the
rejected ideas at the end.

∂15-Oct-87  1746	FAHLMAN@C.CS.CMU.EDU 	SETF-FUNCTION-VS-MACRO (Version 1)    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 15 Oct 87  17:46:11 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 15 Oct 87 20:46:42-EDT
Date: Thu, 15 Oct 1987  20:46 EDT
Message-ID: <FAHLMAN.12342796585.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: SETF-FUNCTION-VS-MACRO (Version 1)
In-reply-to: Msg of 15 Oct 1987  20:39-EDT from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>


OK, Moon's proposal looks to me like the right way to go.  It would be
useful to address the alternative I raised in the proposal and the
arguments against it, just so that N other people won't bring up the
same idea.

-- Scott

∂16-Oct-87  0107	peck@Sun.COM 	Re: Issue: PUSH-EVALUATION-ORDER    
Received: from SUN.COM by SAIL.STANFORD.EDU with TCP; 16 Oct 87  01:07:25 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-3.2)
	id AA01645; Fri, 16 Oct 87 01:02:58 PDT
Received: from denali.sun.com by snail.sun.com (4.0/SMI-3.2)
	id AA21892; Fri, 16 Oct 87 01:06:59 PDT
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
	id AA04926; Fri, 16 Oct 87 01:07:15 PDT
Message-Id: <8710160807.AA04926@denali.sun.com>
To: cl-cleanup@Sail.stanford.edu
Subject: Re: Issue: PUSH-EVALUATION-ORDER 
In-Reply-To: Your message of 09 Oct 87 13:47:00 -0700;
	<871009-134727-1519@Xerox> .
Date: Fri, 16 Oct 87 01:07:11 -0700
From: peck@Sun.COM

Issue: PUSH-EVALUATION-ORDER
References: CLtL pages 99 vs 270
Category: CLARIFICATION
Edit History: Jeff Peck, 15-Oct-1987, (version 1)
Problem Description:
    In the form: (PUSH (ref1) (CAR (ref2)))
It is unclear whether (ref1) should be evaluated before (ref2). 

CLtL, page 99, in a discussion of generalized variable macros, states:
 "Other macros that manipulate generalized variables include ... PUSH 
	...
  Macros that manipulate generalized variables must guarentee the "obvious"
  semantics: subforms of generalized-variable references are evaluated ...
  in exactly the same order as they appear in the *source* program."

[That is, the sub-forms of Place should be evaluated once, left to right.]

  "The expansion of these macros must consist of code that follows these
  rules or has the same effect as such code.  This is accomplished by
  introducing temporary variables bound to the subforms of the reference."
                                               ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

This paragraph and a discussion of SETF on the previous pages may also be
 interpreted as requiring that *all* argument forms of such macros should
 be evaluated once, in source order, left to right.


However, CLtL, page 270 states:
 "The effect of (PUSH Item Place) is roughly equivalent to
    (SETF Place (CONS Item Place))
  except that the latter would evaluate any subforms of Place twice
  while PUSH takes care to evaluate them only once."

   That is, the effect of the form (PUSH Item Place) is to evaluate 
(SETF Place (CONS Item Place)) but with subforms of Place only evaluated once.

    Place and Item appear in different order in the PUSH form and the
indicated equivalent SETF form.  Should the PUSH form have primacy over the
obvious SETF form with respect to the left-to-right evaluation?

  Are all subforms in a macro argument list guarenteed to be evaluated in
order, or only those subforms representing generalized variable references?



Test Case:
    (macroexpand '(push (ref1) (car (ref2))))

    (LET* ((#:G8 (REF2))
	   (#:G7 (CONS (REF1) (CAR #:G8))))
      (EXCL::.INV-CAR #:G8 #:G7)) 
    
	    ---versus---
    
    (LET* ((#:G5 (REF1))
	   (#:G4 (REF2)))
      NIL
      (SYS:RPLACA2 #:G4 (VALUES (CONS #:G5 (CAR #:G4)))))



Proposal: PUSH-EVALUATION-ORDER:REDEFINE-PUSH
    The form of PUSH is (PUSH Place Item).
Rationale:
    PUSH is basically defined in the wrong order with respect to the obvious
implementation.  Other generalized variable access functions are defined
with the Place form preceding the Value form.  Accept for the natural visual
clue that PUSH should attach Item "in front" of Place, it would be more
natural to write (PUSH Place Item) and be parallel to SETF forms.
Discusion:
   Never mind, this would break reams of existing code...


Proposal: PUSH-EVALUATION-ORDER:PLACE-FIRST
    Page 270 should be modified to read:
 "(PUSH Item Place) is equivalent to (SETF Place (CONS Item Place))
  except that the subforms of Place are evaluated only once."
	and
 "(PUSHNEW Item Place :test P) is equivalent to
  (SETF Place (ADJOIN Item Place :test P)) except that the subforms of 
  Place are evaluated only once."

Rationale:
   The wording of CLtL on page 99 does not disallow or contradict this
interpretation.  The wording of page 270 is already very close to this.



Proposal: PUSH-EVALUATION-ORDER:ITEM-FIRST
    Page 270 should be modified to read:
 "(PUSH Item Place) is generally equivalent to (SETF Place (CONS Item Place))
  except that the subforms of Place are evaluated only once, and Item
  is evaluated before Place."
	and
 "(PUSHNEW Item Place :test P) is generally equivalent to
  (SETF Place (ADJOIN Item Place :test P)) except that the subforms of 
  Place are evaluated only once, and Item is evaluated before Place."

    Page 99 should be modified to explain explicitly that *all* argument
forms of *any* macro that ever uses generalized variable references, *must*
evaluate in left to right order as appearing in the source.

    Specifically, the phase "subforms of the reference" which appears
several times should be changed to something like:
 "subforms of the [generalized-variable manipulating macro] arguments".

    Perhaps PUSH should be used as an example instead of the over worked SETF.

Rational:
    This is the unstated intention of the page 97-100 discussion of 
generalized-variable referencing macros, and indeed the intended definition
of "obvious semantics" for all macros.



Current-practice:
    PLACE-FIRST:  Lucid, Franz and Kyoto evaluate Place then Item.
    ITEM-FIRST:   Symbolics evaluates Item then Place.

Adoption Cost:
    Minimal, PUSH could simply be defined by the appropriate macro.

Cost of non-adoption:
    Obvious programs may be non-portable. Although it should be rare that
order of evaluation will effect actual operation.  Occasional programs may
get different results on Symbolics.

Benefits:
    The implementation and semantics of PUSH become obvious to all.
With ITEM-FIRST, it is obvious when macros wrapped around PUSH will
evaluate their arguments in the proper order, no exceptions need to be made.

Esthetics:
    Most folks won't notice.  For true esthetics, see REDEFINE-PUSH.


Discussion:
    David Moon (Symbolics) argues that the unstated intention of page 99
is the definition of the language, while admitting that:
  "The quoted paragraphs could be taken to restrict order of evaluation only
   of the subforms of (CAR (ref2)), not all of the subforms of the PUSH form."

∂16-Oct-87  0936	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Re: Issue: PUSH-EVALUATION-ORDER 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 16 Oct 87  09:35:56 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 257095; Fri 16-Oct-87 12:35:53 EDT
Date: Fri, 16 Oct 87 12:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PUSH-EVALUATION-ORDER 
To: peck@Sun.COM
cc: cl-cleanup@Sail.stanford.edu
In-Reply-To: <8710160807.AA04926@denali.sun.com>
Message-ID: <19871016163545.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 16 Oct 87 01:07:11 -0700
    From: peck@Sun.COM

I favor PUSH-EVALUATION-ORDER:ITEM-FIRST.  I've always believed that
on page 99 of CLtL, "subforms of generalized-variable references" is
a typographical error for "subforms of macros that manipulate generalized
variable references."  I only wish this typo had been caught before
the book was published.   Note the paragraph a little further down the
page "As an example of these semantic rules, in the generalized-variable
reference (setf reference value), the value form must be evaluated after
all the subforms of the reference because the value form appears to the
right of them."  In this single sentence, the term "generalized-variable
reference" is used both to mean a setf-able place and a form that invokes
setf.  Confusing, isn't it?  However, I don't see how this paragraph
can be interpreted any other way than that these rules govern the order
of evaluation of all the subforms of one of these macros, not just the
subforms inside "place".

∂16-Oct-87  1106	sandra%orion@cs.utah.edu 	compile-time effects of top-level forms
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Oct 87  11:06:13 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA25495; Fri, 16 Oct 87 12:06:14 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	id AA12450; Fri, 16 Oct 87 12:05:57 MDT
Date: Fri, 16 Oct 87 12:05:57 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8710161805.AA12450@orion.utah.edu>
Subject: compile-time effects of top-level forms
To: cl-cleanup@sail.stanford.edu

Issue:         COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS

References:    CLtL pages 66-70, 143

Category:      CLARIFICATION

Edit history:  V1, 07 Oct 1987 Sandra Loosemore (sandra@cs.utah.edu)
               V2, 15 Oct 1987 Sandra Loosemore (sandra@cs.utah.edu)

Related issues: none

Problem description:

CLtL currently leaves several issues unresolved regarding the compile-time
handling of top-level forms such as DEFMACRO and DEFVAR.  The purpose of
this proposal is to ensure that all CL implementations support usages
which appear to be standard programming practices.

This proposal addresses only the semantics of top-level defining forms
as it affects compilation of subsequent forms in the same file.  Specifically,
this proposal does *not* attempt to specify:

    (1) Compile-time behavior of defining forms which do not appear at 
        top-level within the file being compiled.

    (2) Inheritance or separation of the compiler environment from the normal,
        interpreter environment; or inheritance of the compiler environment
        across calls to COMPILE-FILE.


Proposal:

Certain defining macros, appearing at top-level within a file being
processed by COMPILE-FILE, normally have compile-time side effects which
affect how subsequent forms in the same file are compiled.  As an example,
DEFVAR should store information that tells the compiler that bindings to
the named variable that appear later in the file should be made special
bindings, rather than the default lexical bindings.

In some implementations, compile-time definitions may be handled
differently than those which would occur if the file was loaded in the
usual way.  It should not be assumed that the compile-time effects of the
defining forms remain in place after compilation is completed.  In
particular, an implementation may or may not make the definitions available
to the interpreter or to further calls to COMPILE-FILE.

The defining forms which have compile-time side effects are as follows:

DEFTYPE:   Type names defined via DEFTYPE must be recognized as valid in
subsequent type declarations.

DEFMACRO, DEFINE-MODIFY-MACRO:  Macro definitions must be stored at compile
time, so that occurences of the macro later on in the file will be expanded
correctly.  The body of the macro (*not* the expansion) must be evaluable
at compile time.

DEFUN:  An implementation may choose to store information about the
function for the purposes of compile-time error-checking (such as checking
the number of arguments on calls).  Portable code should not rely on DEFUN
making the function definition available at compile time.

DEFVAR, DEFPARAMETER:  The compiler must recognize that the variables
named by these forms have been proclaimed special.  The initial value form
must not be evaluated at compile time.

DEFCONSTANT:  An implementation may choose to store information about the
variable for the purposes of compile-time error-checking (such as checking
for rebinding of or assignment to the variable).  An implementation may also
choose to evaluate the inital value form at compile time.

DEFSETF, DEFINE-SETF-METHOD:  SETF methods must be available during the
expansion of calls to SETF later on in the file.  The body of
DEFINE-SETF-METHOD and the complex form of DEFSETF must be evaluable at
compile time.

DEFSTRUCT:  The structure type name must be recognized as a valid type name
in declarations, as for DEFTYPE.  The structure slot accessors must be made
known to SETF.  In addition, further DEFSTRUCT definitions should be able
to :INCLUDE a structure type defined earlier in the file being compiled.
The functions which DEFSTRUCT generates, and the #S reader syntax, may or
may not be available at compile time.


Test Case:

;;; DEFTYPE

(deftype small-int () '(int 0 10))

(let ((x 0))
     (declare (type (small-int x)))
     (format t "Type a number between 0 and 10:")
     (setq x (read))
     (format t "The number is ~s.~%" x))


;;; DEFMACRO

(defmacro silly (x) `(car ,x))

(let ((y  nil))
     (format t "Type a list:")
     (setq y (read))
     (format t "The SILLY macro returned ~s.~%" (silly y)))


;;; DEFVAR and DEFPARAMETER

(defvar *v1* 
    (progn 
	(print "Defvar should print this at load time.")
	'v1-global-value))
(defparameter *v2* 
    (progn
	(print "Defparameter should print this at load time.")
	'v2-global-value))

(defun test-defvar-and-defparameter ()
    (format t "*v1* = ~s~%" *v1*)
    (format t "*v2* = ~s~%" *v2*))

(let ((*v1*  'v1-special-binding-value)
      (*v2*  'v2-special-binding-value))
     (test-defvar-and-defparameter))


;;; DEFCONSTANT

(defconstant *v3*
    (progn
	(print "This may be printed at compile-time as well as load time.")
	'v3-value))


;;; DEFSETF

(defsetf silly set-silly)

(defun set-silly (x value)
    (if (y-or-n-p "Do you want to change the CAR of ~s to ~s?" x value)
	(setf (car x) value))
    value)

(setf (silly (list 'a 'b 'c)) 'j-random-luser)


;;; DEFSTRUCT

(defstruct person name age sex)
(defstruct (astronaut (:include person) (:conc-name astro-))
    helmet-size
    (favorite-beverage 'tang))


Rationale:

The proposal reflects standard programming practices.  The primary purpose
of the proposal is to make an explicit statement that CL supports the
behavior that most programmers expect and many implementations already
provide.

The only reference to compile-time processing of defining forms in CLtL
appears to be in reference to DEFMACRO, on page 143, where it is stated
that macro definitions must be ``seen'' by the compiler before the first
use of the macro.


Current practice:

Many (probably most) Common Lisp implementations, including VaxLisp and
Lucid Lisp, are already largely in conformance.  

Kyoto Common Lisp is a notable offender.  By default, KCL evaluates *all*
top level forms as they are compiled, which is clearly in violation of the
behavior specified on p 69-70 of CLtL.  There is a flag to disable the
compile-time evaluation, but then macros such as DEFMACRO, DEFVAR, etc. do
not make their definitions available at compile-time either.


Adoption Cost:

The expansions of defining macros typically store information on property
lists or in hash tables, where it is later accessed by the compiler.  The
simplest way to achieve the required behavior is to modify the expansions
to wrap an (EVAL-WHEN (EVAL COMPILE LOAD) ...) around the forms which store
this information.


Cost of non-adoption:

The current vagueness in CLtL on compiler semantics can lead to unexpected
portability problems.  At least one person commented on the original
version of the proposal with, in effect, "Doesn't CLtL already *say* that
somewhere?!?"  The problem now is that what many people (even experienced
programmers) think are portable programming practices are actually not.  


Benefits:

Adoption of the proposal will provide more definite guidelines on how to
write programs that will compile correctly under all CL implementations.


Conversion Cost:

Minimal.


Esthetics:

Without a definite statement on the compile-time behavior of top-level
defining forms, programmers need to wrap an explicit EVAL-WHEN around all
such forms to guarantee consistent behavior across implementations.  It
would be cleaner to specify a default behavior that does what people seem
to expect anyway.


Discussion:

Reaction to an earlier version of this proposal on the CL mailing list was
overwhelmingly positive.  The current version incorporates a couple
additional suggestions that were made by others, notably Robert Kerns.

-------

∂16-Oct-87  1107	sandra%orion@cs.utah.edu 	proposal for modifying behavior of REQUIRE  
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 16 Oct 87  11:06:55 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA25574; Fri, 16 Oct 87 12:06:57 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	id AA12462; Fri, 16 Oct 87 12:06:51 MDT
Date: Fri, 16 Oct 87 12:06:51 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8710161806.AA12462@orion.utah.edu>
Subject: proposal for modifying behavior of REQUIRE
To: cl-cleanup@sail.stanford.edu

Issue:         REQUIRE-PATHNAME-DEFAULTS

References:    CLtL p. 188

Category:      CHANGE, ADDITION

Edit history:  V1, 15 Oct 1987  Sandra Loosemore (sandra@cs.utah.edu)

Related issues: none

Problem description:

If an explicit pathname is not given to the function REQUIRE, it decides
what files to load in an implementation-specific manner.  The proposal
specifies a portable mechanism for locating modules intended to augment
current nonportable mechanisms.


Proposal:

*REQUIRE-PATHNAME-LIST* [Variable]

The variable *REQUIRE-PATHNAME-LIST* is a list of pathnames.  This
list is used by the function REQUIRE in determining where to look for
modules an explicit pathnames are not specified.

REQUIRE tests for the following cases:

(1) If the pathname argument is present and non-NIL, it is a single
pathname or a list of pathnames whose files are to be loaded in order, left
to right.

(2) A pathname is constructed from the module name and merged with
successive pathnames from the list *REQUIRE-PATHNAME-LIST*, until
a matching file is found and loaded.

(3) The system will determine, in some system-dependent manner, which files
to load.  This will typically involve some central registry of module names
and the associated file lists.

Users will typically wish to push new pathnames onto the front of 
*REQUIRE-PATHNAME-LIST* to specify alternate locations where modules
may be found.


Test Case:



Rationale:

Because of the wide variation between implementations, leaving it up to
REQUIRE to determine which files to load is very nonportable.  Providing an
explicit pathname is often impractical as well; for example, the same code
may run under two implementations with different operating systems and
different file naming conventions; the modules may reside in different
places on different machines; or it may be desirable to support alternate
versions of some modules (such as a release version and an experimental
version).

This proposal provides a portable way of describing where modules can be
found.  The value of the *REQUIRE-PATHNAME-LIST* can be established in a
startup or initialization file, keeping a system-specific detail separate
from portable code files.  Allowing a search list rather than a single
default pathname gives users extra flexibility to customize the behavior of
REQUIRE.  Moreover, the current default behavior is still supported for
those programs which depend on it.


Current practice:

The idea of using a search list for loadable modules is modeled after the
LoadDirectories* variable used by Portable Standard Lisp.  PCLS, the CL
compatibility package layered on top of PSL, currently uses a variable
SYS:*REQUIRE-PATHNAME-LIST* as described in this proposal.

VaxLisp (under VMS) looks for a module with the specified name first in the
current directory, then in the place specified by the logical name
LISP$MODULES, then in LISP$SYSTEM.

Lucid's documentation does not specify how their implementation of REQUIRE
works.  I was unable to get it to find modules except in
*DEFAULT-PATHNAME-DEFAULTS*.

KCL looks for modules only in *DEFAULT-PATHNAME-DEFAULTS*.


Adoption Cost:

The change is minor and isolated to a single function.  Here is a suggested
implementation of REQUIRE:

(defvar *require-pathname-list* nil
    "Where REQUIRE looks for modules if you don't give an explicit pathname.")

(defun require (module &optional pathname)
    (cond ((member (string module) *modules* :test #'equal))
          ((consp pathname)
	   (dolist (p pathname)
	       (load p)))
	  (pathname
	   (load pathname))
	  ((progn
	       (setq pathname (pathname module))
	       (some
		   #'(lambda (default)
			 (load (merge-pathnames pathname (pathname default))
			       :if-does-not-exist nil))
		   *require-pathname-list*)))
	  ((load pathname :if-does-not-exist nil))
	  (t
	   (cerror "Nothing will be loaded."
	       "Module ~s could not be found."
	       module)))
    module)



Cost of non-adoption:

Using REQUIRE in portable code is difficult.  In KCL and Lucid, I was forced
to redefine REQUIRE in my startup file to get it to look for modules in
places other than *DEFAULT-PATHNAME-DEFAULTS*.


Benefits:

See above, under "Rationale".


Conversion Cost:

None.  The proposal is entirely compatible with the existing definition.


Esthetics:

I'd ordinarily be the last person to propose extensions to Common Lisp, but
having to learn one feature that works under all implementations is better
than having to learn each implementation's own peculiar way of handling the
same situation.


Discussion:

I mentioned the idea of having a variable to specify where REQUIRE looks
for modules in passing on the CL mailing list.  There were 2 positive
responses and no negative ones.  Cutting.pa@xerox.com proposed a search
list rather than a single pathname, which is actually what I had in mind
anyway.

-------

∂18-Oct-87  1959	FAHLMAN@C.CS.CMU.EDU 	Issue: DEFINITION-FUNCTIONS 
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Oct 87  19:59:34 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 18 Oct 87 23:00:05-EDT
Date: Sun, 18 Oct 1987  23:00 EDT
Message-ID: <FAHLMAN.12343607303.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: DEFINITION-FUNCTIONS
In-reply-to: Msg of 9 Oct 1987  18:20-EDT from Masinter.pa at Xerox.COM


    Date: Friday, 9 October 1987  18:20-EDT
    From: Masinter.pa at Xerox.COM
    To:   cl-cleanup at Sail.stanford.edu
    Re:   Issue: DEFINITION-FUNCTIONS

    I promised I would submit a proposal for "named definitions" for making
    documentation etc more extensible in Common Lisp.

Just going over some old mail and found this.  I'd like to see a lot
more motivation for all this machinery.  Does this really solve some
useful problem, or is it extensibility for its own sake?

-- Scott

∂18-Oct-87  2021	FAHLMAN@C.CS.CMU.EDU 	compile-time effects of top-level forms    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 18 Oct 87  20:21:40 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 18 Oct 87 23:22:02-EDT
Date: Sun, 18 Oct 1987  23:21 EDT
Message-ID: <FAHLMAN.12343611292.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: compile-time effects of top-level forms
In-reply-to: Msg of 16 Oct 1987  14:05-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)


I think that these proposals have to be considered by the compiler
committee (which has to be resuscitated somehow).  I think that all of
the compiler issues need to be considered as part of a single coherent
package.

-- Scott

∂19-Oct-87  0731	sandra%orion@cs.utah.edu 	Re: compile-time effects of top-level forms 
Received: from CS.UTAH.EDU by SAIL.STANFORD.EDU with TCP; 19 Oct 87  07:31:10 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA08766; Mon, 19 Oct 87 08:31:14 MDT
Received: by orion.utah.edu (5.54/utah-1.0-slave)
	id AA02958; Mon, 19 Oct 87 08:31:07 MDT
Date: Mon, 19 Oct 87 08:31:07 MDT
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8710191431.AA02958@orion.utah.edu>
Subject: Re: compile-time effects of top-level forms
To: "Scott E. Fahlman" <Fahlman@c.cs.cmu.edu>
Cc: sandra%orion@λcs.utah.eduλ (Sandra J Loosemore),
        cl-cleanup@sail.stanford.edu
In-Reply-To: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>, Sun, 18 Oct 1987  23:21 EDT

I'm afraid that bundling together *all* compiler issues will mean it
will take so long to get agreement that nobody will care any more!  (I
suspect that a lot of us have already reached that stage; I, for one,
certainly have a hard time getting excited about the semantics of
non-top-level DEFMACROs.)  I purposely tried to formulate this proposal
to steer clear of controversial issues and give implementations maximum
freedom.  

What I'm really after is a statement that CL does support -- and will
continue to support -- certain fairly standard programming practices.
To my mind, a partial statement on compiler semantics is better than
none at all.  Since there seems to be such overwhelming agreement with
this proposal (as far as it goes), I don't think it would be
unreasonable to commit to it now, and use it as a starting point for
more sweeping compiler cleanup efforts later (if anybody ever gets
interested).

-Sandra
-------

∂19-Oct-87  0801	FAHLMAN@C.CS.CMU.EDU 	compile-time effects of top-level forms    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Oct 87  08:01:43 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 19 Oct 87 10:51:06-EDT
Date: Mon, 19 Oct 1987  10:50 EDT
Message-ID: <FAHLMAN.12343736727.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: compile-time effects of top-level forms
In-reply-to: Msg of 19 Oct 1987  10:31-EDT from sandra%orion at cs.utah.edu (Sandra J Loosemore)


It is not necessarily true that dealing with the compiler issues as a
group, rather than a few at a time, would slow the process down.  There
was a comprehensive compiler proposal on the table a year ago.  Some
aspects of it were controversial, but it should not have taken more than
a couple of months to hill-climb to some sort of agreement.  The problem
is that the proposal was tabled by the compiler committee chairman,
who apparently thought things were moving too fast.  He has successfully
put an end to that danger.

I suppose it would goad things along a bit if the cleanup committee were
to usurp jurisdiction over a few of these issues and pretend to settle
them, but that really doesn't seem like a good way to get the process
back on track.  Also, the cleanup committee has its own problems when it
comes to getting things done.

-- Scott

∂20-Oct-87  1208	KMP@STONY-BROOK.SCRC.Symbolics.COM 	:1  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Oct 87  12:08:25 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 259304; Tue 20-Oct-87 15:09:25 EDT
Date: Tue, 20 Oct 87 15:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: :1
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <871020150857.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Does anyone have an unambiguous reference to a passage that claims
that the syntax ``:1'' denotes a symbol? In the 3600 implementation,
it's a number and I've heard people claim that this is a bug, but
I just looked and could not find any text which convinced me of this.
If no one can convince me, I'll write up a cleanup item.

∂20-Oct-87  1224	RAM@C.CS.CMU.EDU 	:1
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 20 Oct 87  12:24:38 PDT
Received: ID <RAM@C.CS.CMU.EDU>; Tue 20 Oct 87 15:24:59-EDT
Date: Tue, 20 Oct 1987  15:24 EDT
Message-ID: <RAM.12344048730.BABYL@>
Sender: RAM@λλ
From: Ram@C.CS.CMU.EDU
To:   Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc:   CL-Cleanup@SAIL.STANFORD.EDU
Subject: :1
In-reply-to: Msg of 20 Oct 1987  15:08-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


How about pp339-341: "Any token that is not a potential number and
does not consist entirely of dots will always be taken as a symbol,
now and in the future; programs may rely on this fact."

":1" is not a potential number according to the rules on page 341.

  Rob

∂20-Oct-87  1240	KMP@STONY-BROOK.SCRC.Symbolics.COM 	:1  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Oct 87  12:40:31 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 259340; Tue 20-Oct-87 15:41:25 EDT
Date: Tue, 20 Oct 87 15:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: :1
To: Ram@C.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <RAM.12344048730.BABYL@>
Message-ID: <871020154057.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Yeah, that's the kind of thing I was looking for. Seems
adequately unambiguous to me. Thanks.

Btw, I can't believe we said "and in the future". What a
strange thing to have promised. Not like I'm proposing changing
it or anything, but it's hard enough to legislate the present
without worrying about promises for the future...

∂20-Oct-87  1247	Masinter.pa@Xerox.COM 	Re: :1 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 20 Oct 87  12:47:29 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 20 OCT 87 12:48:11 PDT
Date: 20 Oct 87 12:47 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: :1
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Tue, 20 Oct 87 15:08 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871020-124811-2217@Xerox>

Kent, "In general, the token is interpreted as a number if it satisfies
the syntax for numbers specified in Table 22-2." There is no : anywhere
in table 22-2. I thus don't see how that can possibly be taken as
including :1.


In addition, there is no way to read the description on p 341 to include
any tokens with : as potential numbers.

∂20-Oct-87  1350	gls@Think.COM 	:1   
Received: from THINK.COM by SAIL.STANFORD.EDU with TCP; 20 Oct 87  13:50:36 PDT
Return-Path: <gls@Think.COM>
Received: from kali.think.com by Think.COM; Tue, 20 Oct 87 16:23:58 EDT
Received: by kali.think.com; Tue, 20 Oct 87 16:23:07 EDT
Date: Tue, 20 Oct 87 16:23:07 EDT
From: gls@Think.COM
Message-Id: <8710202023.AA28861@kali.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu, KMP@stony-brook.scrc.symbolics.com
In-Reply-To: Kent M Pitman's message of Tue, 20 Oct 87 15:08 EDT <871020150857.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: :1

   Date: Tue, 20 Oct 87 15:08 EDT
   From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>

   Does anyone have an unambiguous reference to a passage that claims
   that the syntax ``:1'' denotes a symbol? In the 3600 implementation,
   it's a number and I've heard people claim that this is a bug, but
   I just looked and could not find any text which convinced me of this.
   If no one can convince me, I'll write up a cleanup item.


See pages 343-344:

"If there is a single package marker, and it occurs at the beginning of the
token, then the token is interpreted as a keyword, that is, a symbol in the
:keyword package.  The part of the token after the package marker must not
have the syntax of a number."

[Unfortunately this leaves the question of potential numbers vague at best.]

"All other patterns of package markers ... presently do not mean anything
in Common Lisp.... It is therefore an error to use such patterns in a
Common Lisp program.  The valid patterns for tokens may be summarized as
follows:
	nnnnn		...
	xxxxx		...
	:xxxxx		...
	ppppp:xxxxx	...
	ppppp::xxxxx	...
where nnnnn has the syntax of a number, and xxxxx and ppppp do not have the
syntax of a number."

So the token ":1" is an error and may be given any interpretation by
an implementation.

--Guy

∂20-Oct-87  1424	Moon@STONY-BROOK.SCRC.Symbolics.COM 	:1 
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 20 Oct 87  14:24:14 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 259443; Tue 20-Oct-87 17:23:42 EDT
Date: Tue, 20 Oct 87 17:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: :1
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Ram@C.CS.CMU.EDU,
    Masinter.pa@Xerox.COM, gls@Think.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <871020150857.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
             <RAM.12344048730.BABYL@>,
             <871020154057.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
             <871020-124811-2217@Xerox>,
             <8710202023.AA28861@kali.think.com>
Message-ID: <19871020212343.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Tue, 20 Oct 87 15:08 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    Does anyone have an unambiguous reference to a passage that claims
    that the syntax ``:1'' denotes a symbol? In the 3600 implementation,
    it's a number and I've heard people claim that this is a bug, but
    I just looked and could not find any text which convinced me of this.

Those people are wrong, see GLS's response below.

    Date: Tue, 20 Oct 1987  15:24 EDT
    From: Ram@C.CS.CMU.EDU

    How about pp339-341: "Any token that is not a potential number and
    does not consist entirely of dots will always be taken as a symbol,
    now and in the future; programs may rely on this fact."

    ":1" is not a potential number according to the rules on page 341.

":1" is not a single token in Symbolics' implementation.  Table 22-1
says : is a constituent, but that cannot be correct, since it would
forbid the extension to factored package prefixes such as
"foo:(bar baz quux)".  : is really a macro character.  It's hard, for
me anyway, to tell whether this is a simple error in the description
of read syntax in CLtL, or whether it means Symbolics chooses not to
conform to a part of the language we disagree with.  Fortunately it
makes little or no difference to the portability of practical programs.

    Date: Tue, 20 Oct 87 16:23:07 EDT
    From: gls@Think.COM

    So the token ":1" is an error and may be given any interpretation by
    an implementation.

Agreed.  No valid portable program may contain or depend on that syntax,
among numerous others.

∂21-Oct-87  1444	Masinter.pa@Xerox.COM 	Issue: TRACE-FUNCTION-ONLY 
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 21 Oct 87  14:41:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 OCT 87 14:41:29 PDT
Date: 21 Oct 87 14:40 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: TRACE-FUNCTION-ONLY
To: cl-cleanup@Sail.stanford.edu
Message-ID: <871021-144129-3988@Xerox>

I took the liberty of renaming this issue since the "problem" is broader
than CLOS, but this is otherwise as submitted.

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

Return-Path: <kempf%hplabsz@hplabs.HP.COM>
Received: from hplabs.HP.COM ([15.255.16.7]) by Xerox.COM ; 21 OCT 87
10:00:05 PDT
Received: from hplms2 by hplabs.HP.COM with SMTP ; Wed, 21 Oct 87
09:59:19 PDT
Received: from hplabsz.hpl.hp.com by hplms2; Wed, 21 Oct 87 09:58:43 pdt
Return-Path: <kempf@hplabsz>
Received: from hplabsz by hplabsz; Wed, 21 Oct 87 10:58:12 pdt
To: Masinter.pa
Cc: Common-Lisp-Object-System@sail.stanford.edu
Subject: TRACE Proposal
X-Mailer: mh6.5
Date: Wed, 21 Oct 87 09:58:09 PDT
Message-Id: <24566.561833889@hplabsz>
From: kempf%hplabsz@hplabs.HP.COM


Larry:

	Here is a copy of the proposed modifications to TRACE, which
were discussed at the September CLOS committee meeting. I have not
included the TRACE-EXECUTION proposal, since it is a generic function,
similar to PRINT-OBJECT, and its disposition was not clear at the
meeting.

	I hope this gets to you in time for the November meeting. If
not, apologies: OOPSLA and recovery took longer than expected.

		Jim Kempf


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


Issue:         TRACE-CLOS

References:    trace macro pp. 440-441

Category:      MODIFICATION

Edit history:  Version 1, 21-Oct-87 Kempf

Problem description:

With the addition of the Common Lisp Object System, there is no
command language level way to trace individual method execution.
The TRACE macro, as currently specified in Common Lisp, allows
only tracing of globally defined functions through their names.
Since a generic function name may have several executable methods,
users need some way to specify that they would like invocation of
particular
methods to be traced, rather than invocation of the entire generic
function.

In addition, the current specification of TRACE does not allow tracing
of functions associated with SETF "methods", of macro functions, 
nor of lexically defined functions or functions invoked via. their
function definition objects.  While this proposal does not attempt 
to address the latter problems, since identification and/or tracing of
these
is likely to be implementation dependent, it does leave 
open the option for those implementations which can arrange it. Finally,
some implementations of Common Lisp have extended TRACE to take an
option 
which puts the system into a break loop after the trace information has
been
printed. This proposal adds that capability to the standard.

Proposal (TRACE-CLOS::TRACE-FUNCTION-SPECIFICATION)

(Font Note: UPPERCASE indicates bold, _this_ indicates italic)

TRACE _function-spec_ &KEY (:BREAK NIL) _[Macro]_

TRACE

UNTRACE _function-spec_	_[Macro]_

UNTRACE

Invoking TRACE with a function specification causes the function
specified
to be traced. Henceforth, whenever the specified function is invoked,
information about the call, the arguments passed, and the returned
values, if any, will be printed to the stream that is the value of
*TRACE-OUTPUT*. If the keyword argument :BREAK is T, then the BREAK
function will be called after the trace information is printed. 
UNTRACE undoes any tracing. Calling TRACE without any arguments
prints a list of currently traced executable entities, calling
UNTRACE without any arguments causes tracing to be undone for
all currently traced entities.

A _function_spec_ is either a symbol naming a function (i.e. a
symbol whose global function cell is bound to a function definition
object, or to which the application of MACRO-FUNCTION will return
a function definition object) or a list whose first element indicates
what kind of funcallable object is to be traced and whose tail indicates
which particular function should be traced. The complete set of
function specifications will necessarily be implementation dependent;
however,
every implementation is required to support the following:

	_symbol_-Invocations of the function or macrofunction named by
	         _symbol_ via. _symbol_ as a global name are traced.

	(METHOD _generic-function-name-specification_
                _{method-qualifiers}_* 
	        _parameter-specializer-name-list_
        )
	If the method whose parameter specializer list, generic function
	name specification, and method qualifiers are listed is tracable,
	then invocations through the generic function name specification 
	will be traced.

	(SETF _symbol_)-If the SETF function having the name specification
	is tracable, it will be traced (see proposal SETF-CLOS for
	more information on SETF name specifications).

Implementations are encouraged to provide for tracing of as many
funcallable objects as possible.

Rationale:

Adoption of the Common Lisp Object System will require the availability
of debugging information on individual methods. 

Current practice:

Some Common Lisp implementations have extended TRACE syntax to
allow specification of breaks. Currently, the TRACE macro is
specified to take any number of symbols.

Adoption Cost:

The syntax of the TRACE macro will take only one function specification
in order to accomodate the :BREAK key. But, since TRACE tends to
be used interactively at the command langauge level, the impact
on existing code should be slight.

Cost of non-adoption:

Without this, implementation dependent ways of specifying the
:BREAK option would continue to be used. In addition, most
implementors would probably add their own syntax for allowing
programmers to obtain information on individual method invocation.

Benefits:

Allow programmers to obtain information on individual method
invocations.

Conversion Cost:

Minor re-write of the TRACE and UNTRACE macros.



     ----- End Forwarded Messages -----

∂21-Oct-87  1741	FAHLMAN@C.CS.CMU.EDU 	Issue: TRACE-FUNCTION-ONLY  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 21 Oct 87  17:41:01 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Wed 21 Oct 87 20:41:32-EDT
Date: Wed, 21 Oct 1987  20:41 EDT
Message-ID: <FAHLMAN.12344368508.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: TRACE-FUNCTION-ONLY
In-reply-to: Msg of 21 Oct 1987  17:40-EDT from Masinter.pa at Xerox.COM


(Kempf should probably be in on his discussion, but I don't have a
usable return address for him.)

My first reaction to this proposal was that TRACE is part of each
implementation's environment, and that since it does not affect portable
code, it should not be part of the spec.  OK, we put TRACE into the
manual, and this has the benficial effect that in a new implementation
you know that the thing called TRACE is what you want to find out about
when you need this facility.  But we should not try to constrain it any
further.

My second reaction was that I'd really like any implementaiton I use to
support tracing of generic functions, methods, and (if we adopt the
SETF-function proposal) these new function-spec forms.  For that matter,
if we get deeper into the function-spec game, TRACE should follow.  So
maybe putting this requirement into the standard is not so bad after all
-- it's one way of goading companies that might be slow to react
otherwise because their own people aren't deeply into CLOS yet.

So I'd be willing to go along with that part of the proposal.  However,
I think that the :BREAK stuff does not belong here.  If you want to
propose that as a required extension, you should do it in a separate
proposal and try to provide a better justification than "some
implementations do this, so I've randomly tossed it in with the other
stuff".

If you add :BREAK in the way you propose, you are introducing a
gratuitous incompatibility with the syntax in CLtL, since now TRACE only
takes a single symbol or function-spec.  An alternative is the scheme
used in CMU Common Lisp:

(trace [trace-form]*)

where the trace form is either a symbol naming a function or a list
whose car is a function-name symbol and whose CDR contains the options
to be used in tracing that function: :BREAK, :BREAK-AFTER, :WHEREIN,
etc. 

I think that we got this extended syntax from Maclisp and that lots of
other Common Lisp implementations follow it as well.  I would like any
proposal for extensions to TRACE to be compatible with this extended
syntax, which I think is better than requiring a separate call to TRACE
for each named function.  It might be ambiguous to allow arbitrary
function-specs to appear as trace forms -- do you want to trace the SETF
function of some symbol or SETF itself? -- but it would not be a problem
to allow an arbitrary function spec to appear in the car of a
trace-form, with implementation-specific keyword options allowed in the
CDR.

-- Scott

∂21-Oct-87  1752	Moon@STONY-BROOK.SCRC.Symbolics.COM 	Issue: TRACE-FUNCTION-ONLY  
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 21 Oct 87  17:51:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 260521; Wed 21-Oct-87 20:52:29 EDT
Date: Wed, 21 Oct 87 20:41 EDT
From: Fahlman@C.CS.CMU.EDU
Sender: FAHLMAN@C.CS.CMU.EDU
Subject: Issue: TRACE-FUNCTION-ONLY
To: Masinter.pa@XEROX.COM, kempf%hplabsz@hplabs.hp.com
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 21 Oct 87 17:40 EDT from Masinter.pa@Xerox.COM
Message-ID: <19871022005229.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Supersedes: <FAHLMAN.12344368508.BABYL@C.CS.CMU.EDU>
Redirected-Date: Wed, 21 Oct 87 20:52 EDT
Redirected-by: Moon@STONY-BROOK.SCRC.Symbolics.COM

[This message has been redirected:
  kempf%hplabsz@hplabs.hp.com should be a usable address for sending to Jim Kempf from CMU-C.
    kempf%hplabsz@hplabs.hp.com has been added.]


(Kempf should probably be in on his discussion, but I don't have a
usable return address for him.)

My first reaction to this proposal was that TRACE is part of each
implementation's environment, and that since it does not affect portable
code, it should not be part of the spec.  OK, we put TRACE into the
manual, and this has the benficial effect that in a new implementation
you know that the thing called TRACE is what you want to find out about
when you need this facility.  But we should not try to constrain it any
further.

My second reaction was that I'd really like any implementaiton I use to
support tracing of generic functions, methods, and (if we adopt the
SETF-function proposal) these new function-spec forms.  For that matter,
if we get deeper into the function-spec game, TRACE should follow.  So
maybe putting this requirement into the standard is not so bad after all
-- it's one way of goading companies that might be slow to react
otherwise because their own people aren't deeply into CLOS yet.

So I'd be willing to go along with that part of the proposal.  However,
I think that the :BREAK stuff does not belong here.  If you want to
propose that as a required extension, you should do it in a separate
proposal and try to provide a better justification than "some
implementations do this, so I've randomly tossed it in with the other
stuff".

If you add :BREAK in the way you propose, you are introducing a
gratuitous incompatibility with the syntax in CLtL, since now TRACE only
takes a single symbol or function-spec.  An alternative is the scheme
used in CMU Common Lisp:

(trace [trace-form]*)

where the trace form is either a symbol naming a function or a list
whose car is a function-name symbol and whose CDR contains the options
to be used in tracing that function: :BREAK, :BREAK-AFTER, :WHEREIN,
etc. 

I think that we got this extended syntax from Maclisp and that lots of
other Common Lisp implementations follow it as well.  I would like any
proposal for extensions to TRACE to be compatible with this extended
syntax, which I think is better than requiring a separate call to TRACE
for each named function.  It might be ambiguous to allow arbitrary
function-specs to appear as trace forms -- do you want to trace the SETF
function of some symbol or SETF itself? -- but it would not be a problem
to allow an arbitrary function spec to appear in the car of a
trace-form, with implementation-specific keyword options allowed in the
CDR.

-- Scott


∂22-Oct-87  0741	KMP@STONY-BROOK.SCRC.Symbolics.COM 	DECLARE-MACROS (Version 1)   
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Oct 87  07:41:08 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 260815; Thu 22-Oct-87 10:41:49 EDT
Date: Thu, 22 Oct 87 10:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DECLARE-MACROS (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
    Moon@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <871022104113.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        DECLARE-MACROS
References:   Declaration Syntax (p154)
Category:     CHANGE
Edit history: 22-Oct-87, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  It is permissible for a macro call to expand into a declaration and be
  recognized as such. This linguistic feature provides some useful
  flexibility, but has a number of disadvantages:

  * Operations on the executable portion of a body of code inside a 
    binding form (such as inserting an additional form) is a complicated
    operation. This is because one or more trial macro expansions must be
    done in order to pass over any declarations or documentation string
    and find the beginning of the body.

  * In some cases, it may be desirable to ask a question about a 
    particular piece of code without actually modifying the code. Since 
    the presence of *MACROEXPAND-HOOK* in the language means that a call
    to MACROEXPAND can be a destructive operation, some seemingly harmless
    inquiry operations about an expression during program analysis can
    risk destructively modifying the expression.

  * In order to find the end of the declarations, MACROEXPAND must be
    called until a non-macro form is seen or until a macro does not expand
    into a macro. In some interpreters which do macroexpansion on the fly,
    this may cause inefficiency because macro expansion of the first form
    in a body must be done twice. In implementations where this is 
    optimized, the implementor may resent the fact that an optimization is
    needed in the first place.

  * Various code analysis tools have been shown to have been significantly
    slowed down by the need to expand macros in order to determine whether
    a binding is SPECIAL when analyzing a variable binding form. This is
    particularly serious when macro invocations are deeply nested; the
    number of macro expansions can be expontential in the depth of nesting
    unless a macro-expansion caching mechanism is added. For example,
    certain efficiency problems in the Symbolics compiler have been traced
    to this feature.

  * User macros must be very careful about finding declarations in a body
    of code by doing proper macro expansion. Often, however, naive users
    don't realize this and so unknowingly write buggy code. This problem can
    be (and is) defined away as simply a programmer error, but this is a
    place where we could fairly straightforwardly redefine the language to
    better accomodate what has been shown to be a common expectation of the
    naive user.

Proposal (DECLARE-MACROS:FLUSH):

  Make it illegal for a macro call to expand into a DECLARE form and be
  recognized as such.

  It should still be possible for a macro call to expand into a PROCLAIM
  form, however.

Rationale:

  The advantages provided by the ability to have a macro form expand into
  a declaration have been shown in practice to not be worth the price paid
  elsewhere in the language.

Current Practice:

  Most or all implementations support the old behavior even though few
  user programs probably need it.

  Some user macros are careful about finding declarations in a body of code
  by doing proper macro expansion, but some probably cheat and look just
  for explicit uses of DECLARE. The cheat probably works most of the time.

Adoption Cost:

  The nature of this change is such that implementations which did not
  choose to change would simply be supporting an implementation-dependent
  extension (except for some `minor' worry about destructive modification
  due to macro expanding while *MACROEXPAND-HOOK* is set to something
  which implemented displacing macros).

  In any case, there might be several places in which the interpreter,
  compiler, and system macros had knowledge about doing macro expansion
  before declaration processing. The change is not trivial, but most of
  its complexity is likely to be in finding the places which need change
  and not in making the actual change.

Benefits:

  The efficiency of some tools may be improved.

  User macros which must do minor surgery on bodies of code will be
  easier to write.

Conversion Cost:

  Most users probably do not write macros which expand into DECLARE forms
  so most users are probably not affected.

  Users who do exploit this feature probably know that they do. In any
  case, compilers could be made to detect cases where this feature is
  being exploited and warn about it.

  Rewrites must be devised on a case-by-case basis. A common sort of
  rewrite would take the form:

   Old code:  (DEFMACRO SPEEDY () `(DECLARE (SPEED 3) (SAFETY 0)))
   	      (LET (..bindings..) (SPEEDY) ..body..)

   New code:  (DEFMACRO SPEEDY-LET (BVL &BODY FORMS)
		`(LET ,BVL (DECLARE (SPEED 3) (SAFETY 0)) ,@FORMS))
	      (SPEEDY-LET (..bindings..) ..body..)

Aesthetics:

  This change simplifies the semantics of the language slightly and
  probably tends to better support the assumptions of naive programmers
  writing macros.

  In some cases involving complicated extensions to declarations, it
  may be slightly harder to express such extensions in a modular way.
  Experience thus far has shown such cases to be rare, however.

Discussion:

  Symbolics took an in-house poll of people who take advantage of the
  feature and it was generally agreed that in most cases where this
  feature is used at all, that it would be just as easy to work around
  using the sample rewrite techniques cited above.

  Moon `credits' Pitman for (against some opposition) pushing this
  `feature' down everyone's throats in the original CL design process.
  Pitman admits this was an expensive mistake. Moon and Pitman support
  this change as an important simplification to the language.

∂22-Oct-87  1150	Pavel.pa@Xerox.COM 	Re: DECLARE-MACROS (Version 1)
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 22 Oct 87  11:50:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 OCT 87 11:49:41 PDT
Date: Thu, 22 Oct 87 11:49:34 PDT
From: Pavel.pa@Xerox.COM
Subject: Re: DECLARE-MACROS (Version 1)
In-reply-to: <871022104113.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <871022-114941-5200@Xerox>

I support this change.  It was the cause of no small amount of grousing
by other developers of Xerox Common Lisp when they saw the complexities
it entailed in the interpreter, compiler, and macros.  I think the
proposal states the situation correctly: ``This linguistic feature
provides some useful   flexibility, but has a number of disadvantages''.
I think the problems far outweigh the value of the flexibility.

	Pavel

∂22-Oct-87  1224	FAHLMAN@C.CS.CMU.EDU 	DECLARE-MACROS (Version 1)  
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Oct 87  12:24:48 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 22 Oct 87 15:25:13-EDT
Date: Thu, 22 Oct 1987  15:24 EDT
Message-ID: <FAHLMAN.12344573036.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: DECLARE-MACROS (Version 1)
In-reply-to: Msg of 22 Oct 1987  10:41-EDT from Kent M Pitman <KMP at STONY-BROOK.SCRC.Symbolics.COM>


I have suggested on several occasions that we eliminate macro ->
declaration expansion, and I still think that this would be a good idea.
It would have been an even better idea if it had happened earlier, but
my time machine has been confiscated by the reality police, so I can't
do much about that.

I think that there are several bits of hair in the language spec that we
added because of this "feature" and that we could flush if it goes away
-- environment args in various places, etc.  It may be best to let these
things live on, however.

-- Scott

∂22-Oct-87  1259	KMP@STONY-BROOK.SCRC.Symbolics.COM 	COLON-NUMBER (Version 1)
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 22 Oct 87  12:58:54 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 261173; Thu 22-Oct-87 15:59:38 EDT
Date: Thu, 22 Oct 87 15:59 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: COLON-NUMBER (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
References: <871020150857.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
            The message of 20 Oct 87 15:24 EDT from Ram@C.CS.CMU.EDU,
            <8710202023.AA28861@kali.think.com>,
            <871020-124811-2217@Xerox>,
            <19871020212343.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
            <8710221841.AA00236@kali.think.com>
Message-ID: <871022155903.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        COLON-NUMBER
References:   Parsing of Numbers and Symbols (p339-341, 343-344)
Category:     CLARIFICATION
Edit history: 22-Oct-87, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  CLtL is unclear about whether a colon followed by a potential number
  is a potential number. There are passages which seem to address this
  issue unambiguously but fail.

Proposal (COLON-NUMBER:UNDEFINED):

  Clarify that syntax involving a leading colon followed by a potential
  number is not well-defined. That is, use of notation such as :1, :1/2,
  and :2↑3 in a position where an expression appropriate for READ is
  expected is an error.

Rationale:

  This makes the status quo apparent.

Current Practice:

  Some implementations, such as Symbolics Lisp, claim the right to 
  interpret this as an ``is an error'' situation where their
  upward-compatible extension is to parse ``:1'' as the number 1
  (incidentally, but uninterestingly, expressed in the KEYWORD package).

  Other implementations tokenize ``:1'' as a single token, identify it
  as a symbol, and then parse it as :\1 would be parsed.

Adoption Cost:

  None. This clarification forces no implementations to change.

Benefits:

  Programmer expectations that any useful behavior can be portably relied
  upon in this pathological case should be soundly trounced.

Conversion Cost:

  Slight. Some users may have mistakenly believed that this was an aspect
  of the language that was guaranteed and may have written programs that
  exploited that belief. Such incidences are probably very rare, however.
  Also, even in the few cases where such code fortuitously worked,
  implementations are likely to continue to support it so such code will
  probably continue to fortuitously work in many of those rare situations.

Aesthetics:

  Arguably a slight improvement in visual aesthetics. What was already 
  a pretty marginal syntax is discouraged.

Discussion:

  Pitman supports this clarification. He thinks this issue is not a big
  deal, but it does crop up often enough to be a nuisance. It would be
  nice to have everyone acknowledge a unified position, even if that only
  meant agreeing to disagree.

∂22-Oct-87  1303	FAHLMAN@C.CS.CMU.EDU 	COLON-NUMBER (Version 1)    
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 22 Oct 87  13:03:21 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Thu 22 Oct 87 16:03:48-EDT
Date: Thu, 22 Oct 1987  16:03 EDT
Message-ID: <FAHLMAN.12344580093.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CM