perm filename CLCLEA.3[COM,LSP] blob sn#861898 filedate 1988-10-07 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00808 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00115 00002	
C00116 00003	∂19-Jun-88  2245	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE   
C00119 00004	∂20-Jun-88  0729	CL-Cleanup-mailer 	KCL scoping bug?
C00127 00005	∂20-Jun-88  0748	CL-Cleanup-mailer 	Common Lisp Semantics for Function Call  
C00130 00006	∂20-Jun-88  0921	CL-Cleanup-mailer 	Issue: COERCE-FROM-TYPE (Version 1) 
C00137 00007	∂20-Jun-88  1149	CL-Cleanup-mailer 	comments on draft proposals    
C00140 00008	∂20-Jun-88  1311	CL-Cleanup-mailer 	Issue: FUNCTION-COERCE-TIME (Version 1)  
C00152 00009	∂20-Jun-88  1312	CL-Cleanup-mailer 	Issue: ALIST-NIL (Version 1)   
C00159 00010	∂20-Jun-88  1316	CL-Cleanup-mailer 	Issue: TRACE-ERROR (Version 1) 
C00165 00011	∂20-Jun-88  1411	CL-Cleanup-mailer 	Issue: DECODE-UNIVERSAL-DAYLIGHT (Version 1)  
C00171 00012	∂20-Jun-88  1418	CL-Cleanup-mailer 	Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 1)  
C00173 00013	∂20-Jun-88  1546	CL-Cleanup-mailer 	STEP-ENVIRONMENT, version 3    
C00179 00014	∂20-Jun-88  1842	CL-Cleanup-mailer 	Issue: STEP-ENVIRONMENT, version 3  
C00180 00015	∂21-Jun-88  0003	CL-Cleanup-mailer   
C00182 00016	∂21-Jun-88  1739	CL-Cleanup-mailer 	Issue: TRACE-ERROR (Version 1) 
C00185 00017	∂21-Jun-88  1740	CL-Cleanup-mailer 	STEP-ENVIRONMENT, version 3    
C00187 00018	∂22-Jun-88  1004	CL-Cleanup-mailer 	Issue: TRACE-ERROR (Version 1) 
C00193 00019	∂22-Jun-88  1254	CL-Cleanup-mailer 	Issue: STREAM-CLASS-ACCESS (version 1)   
C00196 00020	∂22-Jun-88  1508	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 1) 
C00204 00021	∂22-Jun-88  2258	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COERCE-TIME (Version 1)   
C00206 00022	∂22-Jun-88  2306	CL-Cleanup-mailer 	Re: Issue: ALIST-NIL (Version 1)    
C00208 00023	∂22-Jun-88  2317	CL-Cleanup-mailer 	Re: Issue: TRACE-ERROR (Version 1)  
C00211 00024	∂22-Jun-88  2338	CL-Cleanup-mailer 	Re: Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 1)   
C00213 00025	∂23-Jun-88  0153	CL-Cleanup-mailer 	&key in defstruct :constructor arglists  
C00217 00026	∂23-Jun-88  0725	CL-Cleanup-mailer 	Re: Issue: TRACE-ERROR (Version 1)  
C00225 00027	∂23-Jun-88  0733	CL-Cleanup-mailer 	Re: Issue: ALIST-NIL (Version 1)    
C00230 00028	∂23-Jun-88  0738	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COERCE-TIME (Version 1)   
C00233 00029	∂23-Jun-88  0842	CL-Cleanup-mailer 	Re: Issue: ALIST-NIL (Version 1)    
C00235 00030	∂23-Jun-88  1005	CL-Cleanup-mailer 	Issue: FUNCTION-DEFINITION (Version 1)   
C00248 00031	∂23-Jun-88  1254	CL-Cleanup-mailer 	Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 2)   
C00267 00032	∂23-Jun-88  1412	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 1)  
C00276 00033	∂23-Jun-88  1516	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
C00278 00034	∂24-Jun-88  0912	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
C00280 00035	∂24-Jun-88  1058	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
C00298 00036	∂24-Jun-88  1100	CL-Cleanup-mailer 	Issue: STRUCTURE-INFO (Version 1)   
C00304 00037	∂24-Jun-88  1149	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
C00306 00038	∂24-Jun-88  1209	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
C00309 00039	∂24-Jun-88  1225	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
C00311 00040	∂24-Jun-88  1307	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
C00313 00041	∂24-Jun-88  1552	CL-Cleanup-mailer 	EQUAL 
C00319 00042	∂24-Jun-88  1647	CL-Cleanup-mailer 	EQUAL 
C00323 00043	∂27-Jun-88  0753	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
C00328 00044	∂27-Jun-88  0817	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
C00331 00045	∂27-Jun-88  0834	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
C00335 00046	∂27-Jun-88  1238	CL-Cleanup-mailer 	Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)   
C00343 00047	∂27-Jun-88  1357	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 1)  
C00349 00048	∂28-Jun-88  0919	CL-Cleanup-mailer   
C00352 00049	∂28-Jun-88  0943	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
C00357 00050	∂28-Jun-88  1000	CL-Cleanup-mailer   
C00358 00051	∂28-Jun-88  1041	CL-Cleanup-mailer 	Issue: STANDARD-OUTPUT-INITIAL-BINDING (version 5) 
C00371 00052	∂28-Jun-88  1100	CL-Cleanup-mailer 	Issue:  SYMBOL-MACROLET-UTILITY
C00376 00053	∂28-Jun-88  1137	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 5)  
C00384 00054	∂28-Jun-88  1347	CL-Cleanup-mailer 	Issue: DOTTED-MACRO-FORMS (Version 1)    
C00393 00055	∂28-Jun-88  1353	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-UTILITY (Version 1)    
C00399 00056	∂28-Jun-88  1413	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 1) 
C00402 00057	∂29-Jun-88  0931	CL-Cleanup-mailer   
C00403 00058	∂29-Jun-88  1013	CL-Cleanup-mailer   
C00406 00059	∂29-Jun-88  1054	CL-Cleanup-mailer 	RE: Issue: SYMBOL-MACROLET-UTILITY (Version 1)
C00412 00060	∂29-Jun-88  1114	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)  
C00418 00061	∂29-Jun-88  1116	CL-Cleanup-mailer 	Re: Issue: SYMBOL-MACROLET-UTILITY (Version 1)     
C00421 00062	∂29-Jun-88  1136	CL-Cleanup-mailer 	Re: Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)   
C00425 00063	∂29-Jun-88  1413	CL-Cleanup-mailer 	Re: Issue:  SYMBOL-MACROLET-UTILITY 
C00433 00064	∂29-Jun-88  2336	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
C00435 00065	∂30-Jun-88  0004	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
C00437 00066	∂30-Jun-88  0623	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
C00439 00067	∂30-Jun-88  0735	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
C00448 00068	∂30-Jun-88  0803	CL-Cleanup-mailer 	EQUAL 
C00451 00069	∂30-Jun-88  0809	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
C00456 00070	∂30-Jun-88  0927	CL-Cleanup-mailer 	various DEFSTRUCT issues  
C00465 00071	∂30-Jun-88  1145	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
C00472 00072	∂30-Jun-88  1557	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
C00474 00073	∂30-Jun-88  1557	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
C00476 00074	∂01-Jul-88  0701	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
C00478 00075	∂02-Jul-88  1158	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-CASE (Version 1)    
C00488 00076	∂05-Jul-88  0854	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
C00494 00077	∂05-Jul-88  1156	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
C00508 00078	∂05-Jul-88  1454	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 6)  
C00520 00079	∂05-Jul-88  1455	CL-Cleanup-mailer 	Issue: STREAM-CAPABILITIES (version 1)   
C00533 00080	∂05-Jul-88  1624	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)  
C00535 00081	∂06-Jul-88  0720	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 6)  
C00545 00082	∂06-Jul-88  1836	CL-Cleanup-mailer 	EQUAL-STRUCTURE 
C00547 00083	∂07-Jul-88  0824	CL-Cleanup-mailer 	Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1) 
C00561 00084	∂07-Jul-88  0908	CL-Cleanup-mailer 	RE: Issue: SYMBOL-MACROLET-UTILITY  
C00568 00085	∂07-Jul-88  1136	CL-Cleanup-mailer 	Issue: PATHNAME-CANONICAL-TYPE (Version 1)    
C00577 00086	∂07-Jul-88  1308	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 1)  
C00588 00087	∂07-Jul-88  1312	CL-Cleanup-mailer 	Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)   
C00595 00088	∂08-Jul-88  0310	CL-Cleanup-mailer 	Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)   
C00597 00089	∂08-Jul-88  0541	CL-Cleanup-mailer 	Issue: PATHNAME-CANONICAL-TYPE (Version 1)    
C00601 00090	∂08-Jul-88  0542	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 1)  
C00603 00091	∂08-Jul-88  0545	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
C00607 00092	∂08-Jul-88  0545	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
C00610 00093	∂08-Jul-88  0546	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
C00615 00094	∂08-Jul-88  0546	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
C00619 00095	∂08-Jul-88  0546	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
C00629 00096	∂08-Jul-88  1028	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
C00632 00097	∂08-Jul-88  1420	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 7)  
C00643 00098	∂08-Jul-88  1457	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 7)  
C00646 00099	∂08-Jul-88  1522	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)  
C00658 00100	∂11-Jul-88  0856	CL-Cleanup-mailer 	subtypep vagueness   
C00661 00101	∂11-Jul-88  1023	CL-Cleanup-mailer 	Re: subtypep vagueness    
C00663 00102	∂11-Jul-88  1029	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
C00670 00103	∂11-Jul-88  1034	CL-Cleanup-mailer 	Re: subtypep vagueness    
C00672 00104	∂11-Jul-88  1059	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
C00675 00105	∂11-Jul-88  1313	CL-Cleanup-mailer 	SUBTYPEP-TOO-VAGUE (initial draft)  
C00681 00106	∂11-Jul-88  1418	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
C00686 00107	∂11-Jul-88  1436	CL-Cleanup-mailer 	Re:  issue BOGUS-FIXNUMS (initial draft) 
C00691 00108	∂11-Jul-88  1944	CL-Cleanup-mailer 	SUBTYPEP-TOO-VAGUE (initial draft)  
C00693 00109	∂12-Jul-88  0247	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
C00695 00110	∂12-Jul-88  0926	CL-Cleanup-mailer 	package-clutter:reduce    
C00696 00111	∂12-Jul-88  1152	CL-Cleanup-mailer 	Re: issue BOGUS-FIXNUMS (initial draft)  
C00699 00112	∂12-Jul-88  1253	CL-Cleanup-mailer 	Re: SUBTYPEP-TOO-VAGUE (initial draft)   
C00703 00113	∂12-Jul-88  1302	CL-Cleanup-mailer 	SUBTYPEP-TOO-VAGUE (initial draft)  
C00705 00114	∂12-Jul-88  1305	CL-Cleanup-mailer 	Re: SUBTYPEP-TOO-VAGUE (initial draft)   
C00707 00115	∂12-Jul-88  1544	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
C00709 00116	∂12-Jul-88  1555	CL-Cleanup-mailer 	Re: issue BOGUS-FIXNUMS (initial draft)  
C00712 00117	∂12-Jul-88  1630	CL-Cleanup-mailer 	Re: issue BOGUS-FIXNUMS (initial draft)  
C00714 00118	∂13-Jul-88  0853	CL-Cleanup-mailer 	an alternate BOGUS-FIXNUMS proposal 
C00720 00119	∂13-Jul-88  1221	CL-Cleanup-mailer 	Re:  an alternate BOGUS-FIXNUMS proposal 
C00723 00120	∂13-Jul-88  1445	CL-Cleanup-mailer 	Re:  an alternate BOGUS-FIXNUMS proposal 
C00728 00121	∂13-Jul-88  1543	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
C00731 00122	∂14-Jul-88  1146	CL-Cleanup-mailer 	Re:  an alternate BOGUS-FIXNUMS proposal 
C00736 00123	∂14-Jul-88  1538	CL-Cleanup-mailer 	Re: various DEFSTRUCT issues   
C00738 00124	∂14-Jul-88  2214	CL-Cleanup-mailer 	BOGUS-FIXNUMS, again 
C00745 00125	∂15-Jul-88  0013	CL-Cleanup-mailer 	an alternate BOGUS-FIXNUMS proposal 
C00751 00126	∂15-Jul-88  0110	CL-Cleanup-mailer 	re: issue BOGUS-FIXNUMS   
C00757 00127	∂15-Jul-88  0555	CL-Cleanup-mailer 	Issue: BOGUS-FIXNUMS 
C00764 00128	∂17-Jul-88  0820	CL-Cleanup-mailer 	Re: issue BOGUS-FIXNUMS (initial draft)  
C00773 00129	∂18-Jul-88  0914	CL-Cleanup-mailer 	Re: issue BOGUS-FIXNUMS (initial draft)  
C00781 00130	∂18-Jul-88  1345	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
C00783 00131	∂18-Jul-88  1403	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00788 00132	∂18-Jul-88  1433	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
C00793 00133	∂18-Jul-88  1552	CL-Cleanup-mailer 	Re: issue BOGUS-FIXNUMS (initial draft)  
C00801 00134	∂18-Jul-88  1555	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
C00804 00135	∂18-Jul-88  1556	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
C00806 00136	∂18-Jul-88  1957	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
C00817 00137	∂18-Jul-88  2033	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00819 00138	∂19-Jul-88  0805	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00830 00139	∂19-Jul-88  0823	CL-Cleanup-mailer 	EQUAL, and hash tables, and value/object distinctions   
C00835 00140	∂19-Jul-88  1342	CL-Cleanup-mailer 	SUBTYPEP-TOO-VAGUE, version 2  
C00842 00141	∂19-Jul-88  1350	CL-Cleanup-mailer 	more on BOGUS-FIXNUMS
C00849 00142	∂19-Jul-88  1453	CL-Cleanup-mailer 	more on BOGUS-FIXNUMS
C00851 00143	∂20-Jul-88  1147	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00854 00144	∂20-Jul-88  1217	CL-Cleanup-mailer 	Re:  more on BOGUS-FIXNUMS
C00857 00145	∂20-Jul-88  1535	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00864 00146	∂20-Jul-88  1712	CL-Cleanup-mailer 	re: encourage no side-effect garbage
C00866 00147	∂20-Jul-88  1732	CL-Cleanup-mailer 	proposal: encourage no side-effect garbage    
C00871 00148	∂20-Jul-88  1751	CL-Cleanup-mailer 	proposal: eliminate forced consing  
C00891 00149	∂21-Jul-88  0622	CL-Cleanup-mailer 	Re: proposal: encourage no side-effect garbage     
C00894 00150	∂21-Jul-88  0623	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
C00901 00151	∂21-Jul-88  0643	CL-Cleanup-mailer 	Re: proposal: eliminate forced consing   
C00903 00152	∂21-Jul-88  0803	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
C00906 00153	∂21-Jul-88  0814	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
C00907 00154	∂21-Jul-88  0825	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
C00910 00155	∂21-Jul-88  0833	CL-Cleanup-mailer 	[Masinter.pa: Re: questions]   
C00920 00156	∂21-Jul-88  0936	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
C00924 00157	∂21-Jul-88  1044	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 1)    
C00932 00158	∂21-Jul-88  1205	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
C00935 00159	∂21-Jul-88  1211	CL-Cleanup-mailer 	proposal: eliminate forced consing  
C00937 00160	∂21-Jul-88  1302	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
C00943 00161	∂21-Jul-88  1308	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
C00945 00162	∂21-Jul-88  1351	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
C00946 00163	∂21-Jul-88  1417	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
C00957 00164	∂21-Jul-88  1515	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00963 00165	∂21-Jul-88  1537	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
C00966 00166	∂21-Jul-88  1546	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00973 00167	∂21-Jul-88  1633	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
C00977 00168	∂22-Jul-88  0642	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
C00980 00169	∂22-Jul-88  0649	CL-Cleanup-mailer 	FIXNUM's aren't Bogus!    
C00989 00170	∂22-Jul-88  0928	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
C00992 00171	∂22-Jul-88  0957	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
C00995 00172	∂22-Jul-88  1000	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00999 00173	∂22-Jul-88  1001	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)  
C01001 00174	∂22-Jul-88  1002	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)  
C01005 00175	∂22-Jul-88  1005	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01009 00176	∂22-Jul-88  1006	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (Version 1)
C01011 00177	∂22-Jul-88  1026	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01015 00178	∂22-Jul-88  1133	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
C01018 00179	∂22-Jul-88  1259	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01021 00180	∂22-Jul-88  1335	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01029 00181	∂22-Jul-88  1346	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01031 00182	∂22-Jul-88  1910	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
C01036 00183	∂23-Jul-88  0838	CL-Cleanup-mailer 	Re: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)    
C01038 00184	∂24-Jul-88  2306	CL-Cleanup-mailer 	Re: [Masinter.pa: Re: questions]    
C01041 00185	∂25-Jul-88  0716	CL-Cleanup-mailer 	Re: [Masinter.pa: Re: questions]    
C01043 00186	∂26-Jul-88  1656	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME  
C01050 00187	∂26-Jul-88  1657	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-REDEFINITION  
C01056 00188	∂26-Jul-88  1658	CL-Cleanup-mailer 	ISSUE: VARIABLE-LIST-ASYMMETRY 
C01060 00189	∂26-Jul-88  1659	CL-Cleanup-mailer 	A lambda question    
C01062 00190	∂26-Jul-88  1725	CL-Cleanup-mailer 	Re: A lambda question     
C01064 00191	∂28-Jul-88  1201	CL-Cleanup-mailer 	Issue BOGUS-FIXNUMS (Version 2)
C01074 00192	∂28-Jul-88  1917	CL-Cleanup-mailer 	MULTIPLE-VALUE-SETQ and SYMBOL-MACROLET interaction
C01077 00193	∂28-Jul-88  2109	CL-Cleanup-mailer 	Re: Issue BOGUS-FIXNUMS (Version 2) 
C01079 00194	∂28-Jul-88  2200	CL-Cleanup-mailer 	Re: ISSUE: DEFSTRUCT-REDEFINITION   
C01081 00195	∂29-Jul-88  0803	CL-Cleanup-mailer 	Re: ISSUE: DEFSTRUCT-REDEFINITION   
C01083 00196	∂29-Jul-88  1410	CL-Cleanup-mailer 	SYMBOL-MACROLET-SEMANTICS 
C01096 00197	∂29-Jul-88  2306	CL-Cleanup-mailer 	bignums    
C01100 00198	∂31-Jul-88  1340	CL-Cleanup-mailer 	Issue BOGUS-FIXNUMS (Version 2)
C01108 00199	∂01-Aug-88  0716	CL-Cleanup-mailer 	ISSUE: VARIABLE-LIST-ASYMMETRY (Version 1)    
C01111 00200	∂01-Aug-88  0742	CL-Cleanup-mailer 	A lambda question    
C01117 00201	∂01-Aug-88  1024	CL-Cleanup-mailer 	A lambda question (a.k.a. issue FUNCTION-DEFINITION)    
C01119 00202	∂01-Aug-88  1041	CL-Cleanup-mailer 	Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
C01124 00203	∂01-Aug-88  1058	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-SEMANTICS (Version 1)  
C01131 00204	∂01-Aug-88  1133	CL-Cleanup-mailer 	Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
C01136 00205	∂01-Aug-88  2023	CL-Cleanup-mailer 	ISSUE: VARIABLE-LIST-ASYMMETRY 
C01138 00206	∂02-Aug-88  0717	CL-Cleanup-mailer 	ISSUE: VARIABLE-LIST-ASYMMETRY 
C01143 00207	∂04-Aug-88  1522	CL-Cleanup-mailer 	ISSUE: VARIABLE-LIST-ASYMMETRY 
C01148 00208	∂04-Aug-88  1740	CL-Cleanup-mailer 	A lambda question    
C01150 00209	∂04-Aug-88  2349	CL-Cleanup-mailer 	bignums    
C01155 00210	∂05-Aug-88  1006	CL-Cleanup-mailer 	issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE    
C01160 00211	∂05-Aug-88  1024	CL-Cleanup-mailer 	Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 1) 
C01163 00212	∂16-Aug-88  1541	CL-Cleanup-mailer 	Issue: NTH-VALUE (Version 1)   
C01168 00213	∂16-Aug-88  1627	CL-Cleanup-mailer 	Issue: NTH-VALUE (Version 1)   
C01172 00214	∂16-Aug-88  1641	CL-Cleanup-mailer 	Re: Issue: NTH-VALUE (Version 1)    
C01174 00215	∂18-Aug-88  1114	CL-Cleanup-mailer 	(LET ((var)) ...) and (PROG ((var)) ...) 
C01177 00216	∂18-Aug-88  1406	CL-Cleanup-mailer 	Issue VARIABLE-LIST-ASYMMETRY  
C01179 00217	∂18-Aug-88  1631	CL-Cleanup-mailer 	Issue VARIABLE-LIST-ASYMMETRY  
C01181 00218	∂21-Aug-88  1521	CL-Cleanup-mailer 	new item: RANGE-OF-COUNT-KEYWORD    
C01188 00219	∂22-Aug-88  0841	CL-Cleanup-mailer 	Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
C01201 00220	∂22-Aug-88  0948	CL-Cleanup-mailer 	Re: Issue: RANGE-OF-COUNT-KEYWORD (Version 2) 
C01203 00221	∂22-Aug-88  2241	CL-Cleanup-mailer 	Issue "Eliminate forced consing" re-visited   
C01227 00222	∂23-Aug-88  0740	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
C01233 00223	∂23-Aug-88  0819	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
C01237 00224	∂23-Aug-88  1114	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
C01242 00225	∂23-Aug-88  1158	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
C01249 00226	∂23-Aug-88  1230	CL-Cleanup-mailer 	Issue "Eliminate forced consing" re-visited   
C01252 00227	∂23-Aug-88  1650	CL-Cleanup-mailer 	loop vs. sequence functions    
C01259 00228	∂23-Aug-88  2308	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
C01261 00229	∂23-Aug-88  2317	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
C01263 00230	∂24-Aug-88  0808	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
C01269 00231	∂24-Aug-88  2030	CL-Cleanup-mailer 	required libraries to reduce image size  
C01271 00232	∂24-Aug-88  2107	CL-Cleanup-mailer 	oops, important mis-speak in previous mail, correction included   
C01273 00233	∂24-Aug-88  2111	CL-Cleanup-mailer 	brief summary of issue "Eliminate Forced Consing"  
C01276 00234	∂25-Aug-88  1056	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
C01281 00235	∂25-Aug-88  1721	CL-Cleanup-mailer 	Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
C01283 00236	∂27-Aug-88  1111	CL-Cleanup-mailer 	Issue ELIMINATE FORCED CONSING (Version 2)  [formerly "Eliminate forced consing" re-visited]    
C01293 00237	∂30-Aug-88  1158	CL-Cleanup-mailer 	DISALLOW-CLOSED-STREAM-FUNCTIONS    
C01297 00238	∂30-Aug-88  1201	CL-Cleanup-mailer 	RETURN-VALUES-UNSPECIFIED 
C01301 00239	∂30-Aug-88  1201	CL-Cleanup-mailer 	ARGUMENTS-UNDERSPECIFIED  
C01305 00240	∂31-Aug-88  1513	CL-Cleanup-mailer 	Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
C01315 00241	∂31-Aug-88  1632	CL-Cleanup-mailer 	Issue: PROCLAIM-SCOPE (Version 1)   
C01323 00242	∂31-Aug-88  2112	CL-Cleanup-mailer 	3 new cleanups  
C01325 00243	∂31-Aug-88  2112	CL-Cleanup-mailer 	lambda-cleanup  
C01332 00244	∂31-Aug-88  2112	CL-Cleanup-mailer 	list type cleanup    
C01336 00245	∂31-Aug-88  2113	CL-Cleanup-mailer 	CLOS standard class cleanup    
C01349 00246	∂31-Aug-88  2118	CL-Cleanup-mailer 	Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
C01352 00247	∂01-Sep-88  0847	CL-Cleanup-mailer 	Re: Issue: PROCLAIM-SCOPE (Version 1)    
C01355 00248	∂01-Sep-88  1040	CL-Cleanup-mailer 	Re: CLOS standard class cleanup
C01360 00249	∂01-Sep-88  1105	CL-Cleanup-mailer 	Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
C01363 00250	∂01-Sep-88  1123	CL-Cleanup-mailer 	lambda-cleanup  
C01365 00251	∂01-Sep-88  1210	CL-Cleanup-mailer 	Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
C01367 00252	∂01-Sep-88  1422	CL-Cleanup-mailer 	Re: Issue: PROCLAIM-SCOPE (Version 1)    
C01373 00253	∂01-Sep-88  1437	CL-Cleanup-mailer 	Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1) 
C01377 00254	∂01-Sep-88  2309	CL-Cleanup-mailer 	Issue: PROCLAIM-SCOPE (Version 1)   
C01382 00255	∂02-Sep-88  1357	CL-Cleanup-mailer 	reaching closure on open cleanup items   
C01384 00256	∂02-Sep-88  1636	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (Version 1) formerly    
C01386 00257	∂02-Sep-88  1637	CL-Cleanup-mailer 	Re: RETURN-VALUES-UNSPECIFIED  
C01388 00258	∂02-Sep-88  1844	CL-Cleanup-mailer 	Ooops! Issue: LAMBDA-CAR-OF-FORM    
C01390 00259	∂02-Sep-88  1844	CL-Cleanup-mailer 	Issue: LAMBDA-CAR-OF-FORM (was LAMBDA-IS-OPERATOR) 
C01392 00260	∂02-Sep-88  1845	CL-Cleanup-mailer 	Re: Issue: PROCLAIM-SCOPE (Version 1)    
C01394 00261	∂02-Sep-88  1845	CL-Cleanup-mailer 	Re: required libraries to reduce image size   
C01397 00262	∂02-Sep-88  1845	CL-Cleanup-mailer 	Re: required libraries to reduce image size   
C01400 00263	∂02-Sep-88  1845	CL-Cleanup-mailer 	Re: Issue: PROCLAIM-SCOPE (Version 1)    
C01402 00264	∂04-Sep-88  1447	CL-Cleanup-mailer 	[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>: Issue: ALIST-NIL  
C01409 00265	∂04-Sep-88  1521	CL-Cleanup-mailer 	Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)   
C01414 00266	∂04-Sep-88  1559	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (Version 1)   
C01417 00267	∂04-Sep-88  1617	CL-Cleanup-mailer 	Issue: COERCE (Version 1) vs COERCE-FROM-TYPE 
C01419 00268	∂05-Sep-88  1324	CL-Cleanup-mailer 	Re: Potential issues?
C01423 00269	∂05-Sep-88  1417	CL-Cleanup-mailer 	Potential issues?    
C01429 00270	∂06-Sep-88  1010	CL-Cleanup-mailer 	RETURN-VALUES-UNSPECIFIED 
C01431 00271	∂06-Sep-88  1753	CL-Cleanup-mailer 	Re: RETURN-VALUES-UNSPECIFIED  
C01432 00272	∂07-Sep-88  0001	CL-Cleanup-mailer 	Revised ELIMINATE-CONSING-PROPOSAL, version 3 
C01457 00273	∂07-Sep-88  0219	CL-Cleanup-mailer 	discussion of Moon's comments re: ELIMINATE-FORCED-CONSING   
C01474 00274	∂07-Sep-88  1155	CL-Cleanup-mailer 	ELIMINATE-FORCED-CONSING  
C01479 00275	∂07-Sep-88  1225	CL-Cleanup-mailer 	discussion of Moon's comments re: ELIMINATE-FORCED-CONSING   
C01482 00276	∂07-Sep-88  1226	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS  
C01490 00277	∂07-Sep-88  1423	CL-Cleanup-mailer 	Issue: GET-MACRO-CHARACTER-READTABLE
C01494 00278	∂07-Sep-88  1634	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 1) 
C01506 00279	∂07-Sep-88  1825	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS  
C01508 00280	∂07-Sep-88  1840	CL-Cleanup-mailer 	SYMBOL-MACROFLET
C01512 00281	∂07-Sep-88  1843	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (Version 1)   
C01516 00282	∂07-Sep-88  1853	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 1) 
C01518 00283	∂07-Sep-88  1911	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME  
C01520 00284	∂07-Sep-88  1913	CL-Cleanup-mailer 	[Masinter.pa: Re: questions]   
C01524 00285	∂07-Sep-88  1918	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 1)    
C01526 00286	∂07-Sep-88  1923	CL-Cleanup-mailer 	Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)   
C01529 00287	∂07-Sep-88  1935	CL-Cleanup-mailer 	Issue: PATHNAME-CANONICAL-TYPE (Version 1)    
C01534 00288	∂07-Sep-88  1942	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)  
C01539 00289	∂07-Sep-88  1956	CL-Cleanup-mailer 	Issue: PROCLAIM-SCOPE (Version 1)   
C01541 00290	∂07-Sep-88  2005	CL-Cleanup-mailer 	symbol-macrolet-semantics, symbol-macrolet-utility 
C01545 00291	∂07-Sep-88  2004	Common-Lisp-Object-System-mailer 	symbol-macrolet-semantics, symbol-macrolet-utility 
C01549 00292	∂07-Sep-88  2027	CL-Cleanup-mailer 	SUBTYPEP-TOO-VAGUE, version 2  
C01555 00293	∂07-Sep-88  2241	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS  
C01558 00294	∂08-Sep-88  1143	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 1)    
C01561 00295	∂08-Sep-88  1143	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 1)    
C01564 00296	∂08-Sep-88  1147	CL-Cleanup-mailer 	Issue: PROCLAIM-SCOPE (Version 1)   
C01567 00297	∂08-Sep-88  1254	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 1)    
C01570 00298	∂08-Sep-88  1346	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 1)    
C01572 00299	∂08-Sep-88  1634	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (Version 1)
C01574 00300	∂12-Sep-88  1147	CL-Cleanup-mailer 	Issue: DESCRIBE-INTERACTIVE (Version 1)  
C01580 00301	∂12-Sep-88  1334	CL-Cleanup-mailer 	Issue: IN-PACKAGE-FUNCTIONALITY
C01581 00302	∂12-Sep-88  1337	CL-Cleanup-mailer 	Issue: LAMBDA-FORM   
C01582 00303	∂12-Sep-88  1341	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION    
C01584 00304	∂12-Sep-88  1345	CL-Cleanup-mailer 	Issue: NTH-VALUE
C01586 00305	∂12-Sep-88  1353	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME  
C01587 00306	∂12-Sep-88  1417	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 1)   
C01589 00307	∂12-Sep-88  1418	CL-Cleanup-mailer 	Issue: BOGUS-FIXNUMS 
C01591 00308	∂12-Sep-88  1421	CL-Cleanup-mailer 	Issue: VARIABLE-LIST-ASYMMETRY 
C01592 00309	∂12-Sep-88  1424	CL-Cleanup-mailer 	issue TRUENAME-SYNTAX-ONLY
C01600 00310	∂12-Sep-88  1507	CL-Cleanup-mailer 	Issue: ROOM-DEFAULT-ARGUMENT (Version 1) 
C01605 00311	∂12-Sep-88  1706	CL-Cleanup-mailer 	Issue: ROOM-DEFAULT-ARGUMENT (Version 1) 
C01607 00312	∂12-Sep-88  1709	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 1)   
C01610 00313	∂12-Sep-88  1727	CL-Cleanup-mailer 	Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
C01616 00314	∂12-Sep-88  1747	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
C01621 00315	∂12-Sep-88  1814	CL-Cleanup-mailer 	issue TRUENAME-SYNTAX-ONLY
C01627 00316	∂13-Sep-88  0232	CL-Cleanup-mailer 	Re: COERCE-FROM-TYPE and TYPE-OF    
C01630 00317	∂13-Sep-88  0633	CL-Cleanup-mailer 	Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE   
C01632 00318	∂13-Sep-88  0637	CL-Cleanup-mailer 	Issue: DEFSTRUCT-REDEFINITION  
C01634 00319	∂13-Sep-88  0649	CL-Cleanup-mailer 	Issue PROCLAIM-SCOPE 
C01636 00320	∂13-Sep-88  0703	CL-Cleanup-mailer 	Issue: LIST-TYPE-SPECIFIER
C01638 00321	∂13-Sep-88  0713	CL-Cleanup-mailer 	Issue: RETURN-VALUES-UNSPECIFIED    
C01640 00322	∂13-Sep-88  0714	CL-Cleanup-mailer 	Issue: ARGUMENTS-UNDERSPECIFIED
C01641 00323	∂13-Sep-88  0708	Common-Lisp-Object-System-mailer 	RE: Issue: SYMBOL-MACROLET-DECLARE (version 1)
C01644 00324	∂13-Sep-88  0725	CL-Cleanup-mailer 	Re: COERCE-FROM-TYPE and TYPE-OF    
C01647 00325	∂13-Sep-88  0825	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
C01656 00326	∂13-Sep-88  0916	CL-Cleanup-mailer 	Re: issue TRUENAME-SYNTAX-ONLY 
C01664 00327	∂13-Sep-88  0935	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 1)   
C01668 00328	∂13-Sep-88  1109	CL-Cleanup-mailer 	SYMBOL-MACROFLET
C01673 00329	∂13-Sep-88  1131	CL-Cleanup-mailer 	SYMBOL-MACROFLET
C01675 00330	∂13-Sep-88  1145	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
C01679 00331	∂13-Sep-88  1212	CL-Cleanup-mailer 	SYMBOL-MACROFLET
C01682 00332	∂13-Sep-88  1213	CL-Cleanup-mailer 	Exponent sign printing with ~E 
C01688 00333	∂13-Sep-88  1214	CL-Cleanup-mailer 	SYMBOL-MACROFLET
C01692 00334	∂13-Sep-88  1216	CL-Cleanup-mailer 	SYMBOL-MACROFLET
C01696 00335	∂13-Sep-88  1232	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 1)
C01700 00336	∂13-Sep-88  1234	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (version 1) 
C01703 00337	∂13-Sep-88  1238	CL-Cleanup-mailer 	Issue: TAILP-NIL (version 1)   
C01706 00338	∂13-Sep-88  1240	CL-Cleanup-mailer 	SYMBOL-MACROFLET
C01711 00339	∂13-Sep-88  1459	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)  
C01717 00340	∂13-Sep-88  1502	CL-Cleanup-mailer 	Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)   
C01720 00341	∂13-Sep-88  1542	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 2)   
C01728 00342	∂13-Sep-88  1550	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)  
C01732 00343	∂13-Sep-88  1604	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (version 1) 
C01736 00344	∂13-Sep-88  1612	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 1)
C01738 00345	∂13-Sep-88  2331	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)  
C01742 00346	∂14-Sep-88  0007	CL-Cleanup-mailer 	Re: Exponent sign printing with ~E  
C01744 00347	∂14-Sep-88  0123	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)   
C01746 00348	∂14-Sep-88  0244	CL-Cleanup-mailer 	Re: Issue: DECODE-UNIVERSAL-DAYLIGHT (Version 1)   
C01749 00349	∂14-Sep-88  0635	CL-Cleanup-mailer 	RE: Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)    
C01751 00350	∂14-Sep-88  0651	CL-Cleanup-mailer 	RE: Issue: TAILP-NIL (Version 2)    
C01753 00351	∂14-Sep-88  0721	CL-Cleanup-mailer 	RE: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)   
C01755 00352	∂14-Sep-88  0730	CL-Cleanup-mailer 	Issue: STREAM-CAPABILITIES
C01757 00353	∂14-Sep-88  0748	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER    
C01759 00354	∂14-Sep-88  0804	CL-Cleanup-mailer 	Issue: ALIST-NIL
C01761 00355	∂14-Sep-88  0924	CL-Cleanup-mailer 	Issue: ALIST-NIL
C01764 00356	∂14-Sep-88  0934	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER    
C01768 00357	∂14-Sep-88  0934	CL-Cleanup-mailer 	RE: Issue: ALIST-NIL 
C01770 00358	∂14-Sep-88  0944	CL-Cleanup-mailer 	Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)    
C01778 00359	∂14-Sep-88  1010	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER    
C01781 00360	∂14-Sep-88  1020	CL-Cleanup-mailer 	RE: Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
C01783 00361	∂14-Sep-88  1031	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)   
C01785 00362	∂14-Sep-88  1130	CL-Cleanup-mailer 	Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)    
C01787 00363	∂14-Sep-88  1226	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (version 2)   
C01789 00364	∂14-Sep-88  1233	CL-Cleanup-mailer 	Re: issue TRUENAME-SYNTAX-ONLY 
C01801 00365	∂14-Sep-88  1321	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 1)
C01803 00366	∂14-Sep-88  1322	CL-Cleanup-mailer 	not about Issue: HASH-TABLE-ACCESS (version 1)
C01806 00367	∂14-Sep-88  1322	CL-Cleanup-mailer 	Re: issue TRUENAME-SYNTAX-ONLY 
C01818 00368	∂14-Sep-88  1329	CL-Cleanup-mailer 	Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
C01825 00369	∂14-Sep-88  1458	CL-Cleanup-mailer 	Re: issue TRUENAME-SYNTAX-ONLY 
C01830 00370	∂14-Sep-88  2011	CL-Cleanup-mailer 	Re: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)    
C01839 00371	∂14-Sep-88  2207	CL-Cleanup-mailer 	Re: Issue: DEFSTRUCT-REDEFINITION   
C01842 00372	∂14-Sep-88  2207	CL-Cleanup-mailer 	Re: Issue: DOTTED-MACRO-FORMS (Version 1)
C01844 00373	∂14-Sep-88  2207	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 1)   
C01846 00374	∂14-Sep-88  2207	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 2)
C01851 00375	∂14-Sep-88  2213	CL-Cleanup-mailer 	ELIMINATE-FORCED-CONSING  
C01854 00376	∂14-Sep-88  2222	CL-Cleanup-mailer 	re: encourage no side-effect garbage
C01856 00377	∂14-Sep-88  2331	CL-Cleanup-mailer 	ELIMINATE-FORCED-CONSING  
C01859 00378	∂15-Sep-88  0018	CL-Cleanup-mailer 	Re: Issue: EXIT-EXTENT (Version 1)  
C01861 00379	∂15-Sep-88  0018	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 2)   
C01863 00380	∂15-Sep-88  0053	CL-Cleanup-mailer 	Committee meeting    
C01865 00381	∂15-Sep-88  0117	CL-Cleanup-mailer 	Re: Issue FIXNUM-NONPORTABLE (Version 1) 
C01872 00382	∂15-Sep-88  1029	CL-Cleanup-mailer 	Re: Issue: EXIT-EXTENT (Version 1)  
C01874 00383	∂15-Sep-88  1029	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 2)
C01876 00384	∂15-Sep-88  1250	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2) 
C01879 00385	∂15-Sep-88  1344	CL-Cleanup-mailer 	Re: Virginia and Hawaii X3J13 meetings   
C01881 00386	∂15-Sep-88  1351	CL-Cleanup-mailer 	Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE, version 2   
C01887 00387	∂15-Sep-88  1633	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)   
C01891 00388	∂15-Sep-88  1852	CL-Cleanup-mailer 	Issue: FUNCTION-DEFINITION (Version 1)   
C01905 00389	∂16-Sep-88  0005	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-ACCESS (version 1) 
C01908 00390	∂16-Sep-88  0145	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1) 
C01911 00391	∂16-Sep-88  0156	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-PACKAGE-GENERATORS 
C01913 00392	∂16-Sep-88  0202	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 1)
C01915 00393	∂16-Sep-88  0241	CL-Cleanup-mailer 	Re: Issue: LAMBDA-FORM (Version 1)  
C01917 00394	∂16-Sep-88  0755	CL-Cleanup-mailer 	Re: Issue: LAMBDA-FORM (Version 2)  
C01925 00395	∂16-Sep-88  0837	CL-Cleanup-mailer 	Issue: FUNCTION-COERCE-TIME (Version 2)  
C01939 00396	∂16-Sep-88  1603	CL-Cleanup-mailer 	Re: Issue: LAMBDA-FORM (Version 2)  
C01943 00397	∂16-Sep-88  1629	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2) 
C01945 00398	∂16-Sep-88  1752	CL-Cleanup-mailer 	Re: Issue: LAMBDA-FORM (Version 2)  
C01947 00399	∂16-Sep-88  1752	CL-Cleanup-mailer 	Re: Issue: PACKAGE-CLUTTER
C01950 00400	∂16-Sep-88  2307	CL-Cleanup-mailer 	Re: Issue: PACKAGE-CLUTTER     
C01953 00401	∂17-Sep-88  0907	CL-Cleanup-mailer 	Re: Issue: LAMBDA-FORM (Version 2)  
C01956 00402	∂17-Sep-88  1320	CL-Cleanup-mailer 	Re: Issue: PACKAGE-CLUTTER     
C01959 00403	∂17-Sep-88  1414	CL-Cleanup-mailer 	Re: Issue: PACKAGE-CLUTTER     
C01963 00404	∂17-Sep-88  1504	CL-Cleanup-mailer 	LISP-SYMBOL-REDEFINITION  
C01971 00405	∂17-Sep-88  1514	CL-Cleanup-mailer 	Re: list type cleanup
C01975 00406	∂17-Sep-88  1517	CL-Cleanup-mailer 	[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>: Issue:  
C02004 00407	∂17-Sep-88  1519	CL-Cleanup-mailer 	Issue: LIST-TYPE-SPECIFIER (Version 1)   
C02008 00408	∂17-Sep-88  1620	CL-Cleanup-mailer 	Re: Issue: PACKAGE-CLUTTER     
C02013 00409	∂17-Sep-88  1622	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 5)   
C02015 00410	∂17-Sep-88  1648	CL-Cleanup-mailer 	Issue: LIST-TYPE-SPECIFIER (Version 1)   
C02018 00411	∂18-Sep-88  1217	CL-Cleanup-mailer 	Re: Issue: LIST-TYPE-SPECIFIER (Version 1)    
C02021 00412	∂18-Sep-88  1218	CL-Cleanup-mailer 	LISP-SYMBOL-REDEFINITION  
C02024 00413	∂18-Sep-88  1234	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (version 1) 
C02026 00414	∂18-Sep-88  1241	CL-Cleanup-mailer 	Re: Issue FIXNUM-NONPORTABLE (Version 1) 
C02028 00415	∂18-Sep-88  1250	CL-Cleanup-mailer 	Re: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)    
C02030 00416	∂18-Sep-88  1253	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 2)   
C02032 00417	∂18-Sep-88  1323	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 1)
C02036 00418	∂18-Sep-88  1343	CL-Cleanup-mailer 	LISP-SYMBOL-REDEFINITION  
C02039 00419	∂18-Sep-88  1432	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-PACKAGE-GENERATORS 
C02042 00420	∂18-Sep-88  1632	CL-Cleanup-mailer 	Re: Issue: LOAD-TIME-EVAL (Version 5)    
C02045 00421	∂18-Sep-88  2235	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 1)
C02047 00422	∂19-Sep-88  0853	CL-Cleanup-mailer 	Re: Issue: LOAD-TIME-EVAL (Version 5)    
C02050 00423	∂19-Sep-88  0933	CL-Compiler-mailer 	Issue: LOAD-TIME-EVAL    
C02054 00424	∂19-Sep-88  1224	CL-Cleanup-mailer 	Issue: RANGE-OF-COUNT-KEYWORD  
C02056 00425	∂19-Sep-88  1236	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 1)   
C02058 00426	∂19-Sep-88  1259	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE    
C02060 00427	∂19-Sep-88  1308	CL-Compiler-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM  
C02072 00428	∂19-Sep-88  1429	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)   
C02075 00429	∂19-Sep-88  1431	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (version 2)  
C02084 00430	∂19-Sep-88  1438	CL-Cleanup-mailer 	Re: CL-CLEANUP committee mtg's 
C02086 00431	∂19-Sep-88  1439	CL-Editorial-mailer 	Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)   
C02095 00432	∂19-Sep-88  1505	CL-Cleanup-mailer 	Re: Issue: NTH-VALUE 
C02097 00433	∂19-Sep-88  1505	CL-Cleanup-mailer 	Issue writeups  
C02100 00434	∂19-Sep-88  1505	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1) 
C02102 00435	∂19-Sep-88  1512	CL-Cleanup-mailer 	Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)   
C02105 00436	∂19-Sep-88  1542	CL-Cleanup-mailer 	Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
C02116 00437	∂19-Sep-88  1618	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
C02119 00438	∂19-Sep-88  1636	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST, PATHNAME-COMPONENT-CASE,  
C02122 00439	∂19-Sep-88  1658	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST, PATHNAME-COMPONENT-CASE,  
C02126 00440	∂19-Sep-88  1715	CL-Cleanup-mailer 	Re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 2)    
C02129 00441	∂19-Sep-88  1752	CL-Cleanup-mailer 	Re: Issue: PACKAGE-CLUTTER     
C02131 00442	∂19-Sep-88  1808	CL-Cleanup-mailer 	ARGUMENTS-UNDERSPECIFIED  
C02138 00443	∂19-Sep-88  1810	CL-Cleanup-mailer 	RETURN-VALUES-UNSPECIFIED 
C02143 00444	∂19-Sep-88  2014	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 1)
C02147 00445	∂19-Sep-88  2036	CL-Cleanup-mailer 	Issue: TAILP-NIL (version 1)   
C02149 00446	∂19-Sep-88  2222	CL-Cleanup-mailer 	Re: Issue: PACKAGE-CLUTTER     
C02151 00447	∂19-Sep-88  2342	CL-Cleanup-mailer 	Re: Issue: ROOM-DEFAULT-ARGUMENT (Version 1)  
C02154 00448	∂20-Sep-88  0022	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER    
C02162 00449	∂20-Sep-88  0028	CL-Cleanup-mailer 	Re: Issue: SETF-FUNCTION-VS-MACRO (version 3) 
C02166 00450	∂20-Sep-88  0039	CL-Cleanup-mailer 	Re: Issue: PACKAGE-CLUTTER
C02168 00451	∂20-Sep-88  0040	CL-Cleanup-mailer 	Re: Issue: SETF-FUNCTION-VS-MACRO (version 3) 
C02170 00452	∂20-Sep-88  0127	CL-Cleanup-mailer 	Re: Issue: STACK-LET (Version 1)    
C02172 00453	∂20-Sep-88  0129	CL-Cleanup-mailer 	Issue: STANDARD-CLASS-OVERHEAD 
C02174 00454	∂20-Sep-88  0218	CL-Cleanup-mailer 	Re: Issue: STREAM-CAPABILITIES 
C02178 00455	∂20-Sep-88  0927	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C02184 00456	∂20-Sep-88  1005	CL-Cleanup-mailer 	Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)    
C02186 00457	∂20-Sep-88  1019	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)  
C02195 00458	∂20-Sep-88  1024	CL-Cleanup-mailer 	Re: Issue: STREAM-CAPABILITIES 
C02199 00459	∂20-Sep-88  1038	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)  
C02202 00460	∂20-Sep-88  1044	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C02206 00461	∂20-Sep-88  1047	CL-Cleanup-mailer 	Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
C02209 00462	∂20-Sep-88  1151	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
C02211 00463	∂20-Sep-88  1201	CL-Cleanup-mailer 	(only slightly about) Issue: CONTAGION-ON-NUMERICAL-COMPARISONS   
C02216 00464	∂20-Sep-88  1210	CL-Cleanup-mailer 	message references   
C02220 00465	∂20-Sep-88  1258	CL-Cleanup-mailer 	clcleanup mail archives   
C02222 00466	∂20-Sep-88  1649	CL-Compiler-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM  
C02228 00467	∂20-Sep-88  1715	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C02230 00468	∂20-Sep-88  1721	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 1) 
C02236 00469	∂20-Sep-88  1746	CL-Compiler-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM  
C02239 00470	∂20-Sep-88  1800	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 1) 
C02247 00471	∂20-Sep-88  1817	CL-Cleanup-mailer 	Re: Issue: SYMBOL-MACROLET-SEMANTICS (Version 1)   
C02249 00472	∂20-Sep-88  1817	CL-Cleanup-mailer 	Re: Issue: TAGBODY-CONTENTS (version 1)  
C02251 00473	∂20-Sep-88  1817	Common-Lisp-Object-System-mailer 	Re: Issue: SYMBOL-MACROLET-DECLARE (version 1)
C02253 00474	∂20-Sep-88  1836	CL-Cleanup-mailer 	Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1) 
C02256 00475	∂20-Sep-88  1836	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C02260 00476	∂20-Sep-88  1909	CL-Cleanup-mailer 	Issue: ARGUMENTS-UNDERSPECIFIED (Version 3)   
C02262 00477	∂20-Sep-88  1920	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 1) 
C02265 00478	∂20-Sep-88  1921	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C02269 00479	∂20-Sep-88  1944	CL-Compiler-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM  
C02275 00480	∂20-Sep-88  1959	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C02277 00481	∂20-Sep-88  2001	CL-Cleanup-mailer 	Re: Issue: DOTTED-MACRO-FORMS (Version 1)
C02280 00482	∂20-Sep-88  2004	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C02284 00483	∂20-Sep-88  2008	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
C02287 00484	∂20-Sep-88  2029	CL-Cleanup-mailer 	Issue: ROOM-DEFAULT-ARGUMENT (Version 1) 
C02291 00485	∂20-Sep-88  2044	CL-Cleanup-mailer 	message references   
C02295 00486	∂20-Sep-88  2126	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C02299 00487	∂20-Sep-88  2131	CL-Cleanup-mailer 	Re: message references    
C02300 00488	∂20-Sep-88  2132	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C02303 00489	∂20-Sep-88  2326	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C02305 00490	∂21-Sep-88  0035	CL-Cleanup-mailer 	ELIMINATE-FORCED-CONSING  
C02307 00491	∂21-Sep-88  0052	CL-Cleanup-mailer 	Re: Issue: DOTTED-MACRO-FORMS (Version 1)
C02309 00492	∂21-Sep-88  0111	CL-Cleanup-mailer 	Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE  
C02315 00493	∂21-Sep-88  0135	CL-Cleanup-mailer 	Issue: ALIST-NIL  (Version 3)  
C02322 00494	∂21-Sep-88  0148	CL-Cleanup-mailer 	Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)   
C02327 00495	∂21-Sep-88  0240	CL-Cleanup-mailer 	Re: Issue: CLOSED-STREAM-OPERATIONS (Version 1)    
C02329 00496	∂21-Sep-88  0249	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED
C02332 00497	∂21-Sep-88  0306	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE (Version 1)
C02334 00498	∂21-Sep-88  0319	CL-Cleanup-mailer 	Re: Issue: CONTAGION-ON-NUMERICAL-COMPARISONS 
C02336 00499	∂21-Sep-88  0845	CL-Cleanup-mailer 	Re: Issue: TAGBODY-CONTENTS (version 1)  
C02338 00500	∂21-Sep-88  0906	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 1) 
C02342 00501	∂21-Sep-88  0923	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 1) 
C02346 00502	∂21-Sep-88  0950	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C02351 00503	∂21-Sep-88  1006	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 1) 
C02354 00504	∂21-Sep-88  1036	CL-Cleanup-mailer 	Issue: FUNCTION-DECLARATION (version 1)  
C02359 00505	∂21-Sep-88  1050	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C02366 00506	∂21-Sep-88  1059	CL-Cleanup-mailer 	SYMBOL-MACROLET-SEMANTICS (Version 2)    
C02376 00507	∂21-Sep-88  1126	CL-Cleanup-mailer 	message references   
C02379 00508	∂21-Sep-88  1126	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C02384 00509	∂21-Sep-88  1126	CL-Compiler-mailer 	Issue: COMPILE-FILE-ENVIRONMENT (Version 1)  
C02393 00510	∂21-Sep-88  1138	CL-Cleanup-mailer 	Re: message references    
C02395 00511	∂21-Sep-88  1153	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 6)   
C02404 00512	∂21-Sep-88  1300	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 6)   
C02407 00513	∂21-Sep-88  1302	CL-Cleanup-mailer 	SYMBOL-MACROLET-SEMANTICS (Version 2)    
C02409 00514	∂21-Sep-88  1321	CL-Compiler-mailer 	Issue: LOAD-TIME-EVAL (Version 6)  
C02413 00515	∂21-Sep-88  1329	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 6)   
C02417 00516	∂21-Sep-88  1340	CL-Compiler-mailer 	Issue: LOAD-TIME-EVAL (Version 6)  
C02419 00517	∂21-Sep-88  1403	CL-Cleanup-mailer 	Issue: PRINT-PRETTY-HOOK (version 1)
C02425 00518	∂21-Sep-88  1408	CL-Compiler-mailer 	Re: Issue: LOAD-TIME-EVAL (Version 6)   
C02430 00519	∂21-Sep-88  1436	CL-Cleanup-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM    
C02434 00520	∂21-Sep-88  1525	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C02440 00521	∂21-Sep-88  1718	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)  
C02449 00522	∂21-Sep-88  2329	CL-Cleanup-mailer 	Re: Issue: PRINT-PRETTY-HOOK (version 1) 
C02451 00523	∂22-Sep-88  0728	CL-Cleanup-mailer 	Re: Issue: PRINT-PRETTY-HOOK (version 1) 
C02453 00524	∂22-Sep-88  0741	CL-Cleanup-mailer 	Re: Issue: PRINT-PRETTY-HOOK (version 1) 
C02458 00525	∂22-Sep-88  0814	CL-Cleanup-mailer 	Re: Issue: PRINT-PRETTY-HOOK (version 1) 
C02460 00526	∂22-Sep-88  0852	CL-Cleanup-mailer 	Re: Issue: FUNCTION-DECLARATION (version 1)   
C02464 00527	∂22-Sep-88  0932	CL-Cleanup-mailer 	Re: Issue: PRINT-PRETTY-HOOK (version 1) 
C02468 00528	∂22-Sep-88  0932	CL-Cleanup-mailer 	Re: Issue: PRINT-PRETTY-HOOK (version 1) 
C02471 00529	∂22-Sep-88  0941	CL-Cleanup-mailer 	Issue: LOAD-TIME-EVAL (Version 6)   
C02475 00530	∂22-Sep-88  0946	CL-Compiler-mailer 	Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C02478 00531	∂22-Sep-88  1007	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 2)
C02483 00532	∂22-Sep-88  1015	CL-Cleanup-mailer 	SYMBOL-MACROLET-SEMANTICS (Version 2)    
C02486 00533	∂22-Sep-88  1041	CL-Cleanup-mailer 	Issue SYMBOL-MACROLET-SEMANTICS, Version 3    
C02496 00534	∂22-Sep-88  1047	CL-Cleanup-mailer 	Issue SYMBOL-MACROLET-SEMANTICS, Version 4    
C02505 00535	∂22-Sep-88  1413	CL-Cleanup-mailer 	CLOS in the standard 
C02509 00536	∂22-Sep-88  1722	CL-Cleanup-mailer 	LISP-SYMBOL-REDEFINITION  
C02512 00537	∂22-Sep-88  1727	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (version 1) 
C02514 00538	∂22-Sep-88  1923	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 1)
C02522 00539	∂22-Sep-88  2211	CL-Cleanup-mailer 	Re: Issue: DECLARE-FUNCTION-AMBIGUITY (version 1)  
C02525 00540	∂22-Sep-88  2230	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 3)
C02532 00541	∂22-Sep-88  2249	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 3)
C02534 00542	∂22-Sep-88  2253	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 3) 
C02535 00543	∂23-Sep-88  0017	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 3)
C02540 00544	∂23-Sep-88  0021	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER    
C02545 00545	∂23-Sep-88  0125	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 2)  
C02560 00546	∂23-Sep-88  0125	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (split from PACKAGE-CLUTTER) 
C02563 00547	∂23-Sep-88  0134	CL-Cleanup-mailer 	Issue: DESCRIBE-INTERACTIVE (Version 2)  
C02569 00548	∂23-Sep-88  0242	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 3)  
C02575 00549	∂23-Sep-88  0243	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE (Version 2)     
C02583 00550	∂23-Sep-88  0709	CL-Cleanup-mailer 	Re: Issue: PACKAGE-CLUTTER (Version 2)   
C02588 00551	∂23-Sep-88  0847	CL-Cleanup-mailer 	Issue: PRINT-PRETTY-HOOK (version 1)     
C02590 00552	∂23-Sep-88  0901	CL-Compiler-mailer 	Re: Issue: COMPILE-FILE-ENVIRONMENT (Version 1)   
C02593 00553	∂23-Sep-88  0913	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
C02619 00554	∂23-Sep-88  1353	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
C02621 00555	∂23-Sep-88  1434	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (version 1) 
C02623 00556	∂23-Sep-88  1447	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 1)
C02626 00557	∂23-Sep-88  1539	CL-Cleanup-mailer 	away....   
C02628 00558	∂23-Sep-88  1705	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)  
C02636 00559	∂23-Sep-88  1946	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
C02638 00560	∂24-Sep-88  1634	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 7) 
C02653 00561	∂24-Sep-88  1635	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 1)
C02657 00562	∂24-Sep-88  1732	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 1)
C02659 00563	∂26-Sep-88  1206	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 7) 
C02662 00564	∂26-Sep-88  1246	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 7) 
C02667 00565	∂26-Sep-88  1412	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 7) 
C02669 00566	∂26-Sep-88  1436	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 7) 
C02673 00567	∂26-Sep-88  1455	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 7) 
C02678 00568	∂26-Sep-88  1523	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 7) 
C02681 00569	∂26-Sep-88  1719	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (split from PACKAGE-CLUTTER) 
C02687 00570	∂26-Sep-88  1724	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 2)  
C02689 00571	∂26-Sep-88  1739	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 3)  
C02692 00572	∂26-Sep-88  1756	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 2)  
C02695 00573	∂26-Sep-88  1934	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 1)
C02697 00574	∂26-Sep-88  2043	CL-Cleanup-mailer 	Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)   
C02699 00575	∂26-Sep-88  2103	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 2)  
C02702 00576	∂26-Sep-88  2106	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)  
C02704 00577	∂26-Sep-88  2139	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 5) 
C02706 00578	∂26-Sep-88  2154	CL-Cleanup-mailer 	proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM   
C02716 00579	∂26-Sep-88  2302	CL-Cleanup-mailer 	Issue HASH-TABLE-TESTS    
C02724 00580	∂27-Sep-88  0504	CL-Cleanup-mailer 	Moon@stony-brook.scrc.symbolics.com 
C02726 00581	∂27-Sep-88  0728	CL-Cleanup-mailer 	Re: Moon@stony-brook.scrc.symbolics.com  
C02728 00582	∂27-Sep-88  0927	CL-Cleanup-mailer 	Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)   
C02732 00583	∂27-Sep-88  0936	CL-Cleanup-mailer 	Issue HASH-TABLE-TESTS (Version 1)  
C02734 00584	∂27-Sep-88  1006	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 2)  
C02737 00585	∂27-Sep-88  1039	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 7) 
C02740 00586	∂27-Sep-88  1055	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 7) 
C02745 00587	∂27-Sep-88  1724	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 4)
C02756 00588	∂27-Sep-88  1928	CL-Cleanup-mailer 	Re: Issue: PACKAGE-CLUTTER (Version 2)   
C02759 00589	∂27-Sep-88  2256	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 3)  
C02778 00590	∂27-Sep-88  2318	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (?) 
C02782 00591	∂27-Sep-88  2359	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 7) 
C02786 00592	∂28-Sep-88  0852	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 7) 
C02791 00593	∂28-Sep-88  0908	CL-Cleanup-mailer 	Re: Issue: PROCLAIM-LEXICAL (Version 7)  
C02797 00594	∂28-Sep-88  0914	CL-Cleanup-mailer 	Re: Issue: PACKAGE-CLUTTER (Version 2)   
C02801 00595	∂28-Sep-88  0914	CL-Cleanup-mailer 	Re: Issue: PROCLAIM-LEXICAL (Version 7)  
C02807 00596	∂28-Sep-88  0956	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (?) 
C02812 00597	∂28-Sep-88  1049	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (version 3)   
C02816 00598	∂28-Sep-88  1102	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED
C02819 00599	∂28-Sep-88  1156	CL-Cleanup-mailer 	Re: Issue: PACKAGE-CLUTTER (Version 2)   
C02822 00600	∂28-Sep-88  1307	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 2)  
C02824 00601	∂28-Sep-88  1311	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 2)  
C02827 00602	∂28-Sep-88  1322	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 3)  
C02832 00603	∂28-Sep-88  1355	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 3)  
C02836 00604	∂28-Sep-88  1453	CL-Cleanup-mailer 	Issues: IN-PACKAGE-FUNCTIONALITY and DEFPACKAGE    
C02839 00605	∂28-Sep-88  1500	CL-Cleanup-mailer 	back....   
C02840 00606	∂28-Sep-88  1503	CL-Cleanup-mailer 	Issues: IN-PACKAGE-FUNCTIONALITY and DEFPACKAGE    
C02843 00607	∂28-Sep-88  1519	CL-Cleanup-mailer 	Re: Issues: IN-PACKAGE-FUNCTIONALITY and DEFPACKAGE
C02845 00608	∂28-Sep-88  1614	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 7) 
C02850 00609	∂28-Sep-88  1619	CL-Cleanup-mailer 	Re: Issue: DOTTED-MACRO-FORMS (Version 1)
C02860 00610	∂28-Sep-88  1645	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 2)  
C02864 00611	∂28-Sep-88  1656	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (version 3)   
C02867 00612	∂28-Sep-88  1752	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (version 2)   
C02872 00613	∂28-Sep-88  1755	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 2)  
C02875 00614	∂28-Sep-88  1846	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 3)  
C02879 00615	∂28-Sep-88  1939	CL-Cleanup-mailer 	on Splitting and Merging issues
C02881 00616	∂29-Sep-88  0705	CL-Cleanup-mailer 	Issue: DECLARE-FUNCTION-AMBIGUITY (formerly FUNCTION-DECLARATION) 
C02888 00617	∂29-Sep-88  0727	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (version 3)   
C02890 00618	∂29-Sep-88  1632	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)  
C02895 00619	∂29-Sep-88  1733	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 2)  
C02897 00620	∂30-Sep-88  1020	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (version 3)   
C02901 00621	∂30-Sep-88  1419	CL-Cleanup-mailer 	Issue: KILL-PACKAGE (Version 1)
C02912 00622	∂30-Sep-88  1550	CL-Cleanup-mailer 	Issue: SYMBOL-MACROFLET (Version 1) 
C02921 00623	∂30-Sep-88  1554	CL-Cleanup-mailer 	Re: Issue: KILL-PACKAGE (Version 1) 
C02923 00624	∂30-Sep-88  1753	CL-Cleanup-mailer 	Issue: SYMBOL-MACROFLET (Version 1) 
C02925 00625	∂30-Sep-88  1804	CL-Cleanup-mailer 	Issue: DECLARE-FUNCTION-AMBIGUITY (version 3) 
C02932 00626	∂30-Sep-88  2135	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 5)
C02941 00627	∂30-Sep-88  2213	CL-Cleanup-mailer 	Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)  
C02947 00628	∂01-Oct-88  0156	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 4)  
C02962 00629	∂01-Oct-88  1338	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 5)
C02967 00630	∂01-Oct-88  1357	CL-Cleanup-mailer 	Issue: KILL-PACKAGE (Version 2)
C02980 00631	∂01-Oct-88  1521	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 4)  
C02986 00632	∂01-Oct-88  1548	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 4)  
C02990 00633	∂01-Oct-88  1608	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 2) 
C03003 00634	∂01-Oct-88  1612	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 4)   
C03005 00635	∂01-Oct-88  1619	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 4)   
C03007 00636	∂01-Oct-88  1640	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 5)  
C03016 00637	∂01-Oct-88  1709	CL-Cleanup-mailer 	Issue: ALIST-NIL  (Version 3)  
C03025 00638	∂01-Oct-88  1748	CL-Cleanup-mailer 	Issue: NTH-VALUE (Version 2)   
C03031 00639	∂01-Oct-88  1749	CL-Cleanup-mailer 	Issue: KILL-PACKAGE (Version 1)
C03035 00640	∂01-Oct-88  1809	CL-Cleanup-mailer 	Issue: KILL-PACKAGE (Version 1)
C03040 00641	∂01-Oct-88  2055	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 4)  
C03043 00642	∂01-Oct-88  2104	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 5)
C03046 00643	∂01-Oct-88  2130	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 4)  
C03049 00644	∂02-Oct-88  0844	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 4)   
C03052 00645	∂02-Oct-88  1135	CL-Cleanup-mailer 	New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
C03072 00646	∂02-Oct-88  1159	CL-Compiler-mailer 	Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)    
C03080 00647	∂02-Oct-88  1223	CL-Compiler-mailer 	Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)    
C03082 00648	∂02-Oct-88  1257	CL-Compiler-mailer 	New Issue: SYNTACTIC-ENVIRONMENT-ACCESS 
C03089 00649	∂02-Oct-88  1308	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 4)   
C03092 00650	∂02-Oct-88  1311	CL-Cleanup-mailer 	Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
C03098 00651	∂02-Oct-88  1333	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (version 5)   
C03108 00652	∂02-Oct-88  1346	CL-Compiler-mailer 	Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)    
C03110 00653	∂02-Oct-88  1401	CL-Cleanup-mailer 	Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
C03113 00654	∂02-Oct-88  1426	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COERCE-TIME (Version 2)   
C03115 00655	∂02-Oct-88  1434	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
C03117 00656	∂02-Oct-88  1446	CL-Cleanup-mailer 	Re: Issue: FUNCTION-DEFINITION (Version 1)    
C03120 00657	∂02-Oct-88  1509	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (Version 2) 
C03127 00658	∂02-Oct-88  1608	CL-Cleanup-mailer 	Re: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2) 
C03129 00659	∂02-Oct-88  1617	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4) 
C03139 00660	∂02-Oct-88  1620	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 3) 
C03148 00661	∂02-Oct-88  1836	CL-Cleanup-mailer 	Issue: TEST-NOT-IF-NOT (Version 1)  
C03156 00662	∂02-Oct-88  1847	CL-Cleanup-mailer 	Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
C03168 00663	∂03-Oct-88  0727	CL-Cleanup-mailer 	Re: Issue: TEST-NOT-IF-NOT (Version 1)   
C03170 00664	∂03-Oct-88  0958	CL-Cleanup-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS   
C03175 00665	∂03-Oct-88  1013	CL-Cleanup-mailer 	Re: Issue: TEST-NOT-IF-NOT (Version 1)   
C03178 00666	∂03-Oct-88  1014	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
C03180 00667	∂03-Oct-88  1025	CL-Cleanup-mailer 	Re: Issue: FORMAT-PRETTY-PRINT (version 5)    
C03184 00668	∂03-Oct-88  1035	CL-Cleanup-mailer 	Re: Issue: PRINT-PRETTY-HOOK (version 1) 
C03189 00669	∂03-Oct-88  1038	CL-Cleanup-mailer 	Re: Issue: PRINT-PRETTY-HOOK (version 1) 
C03192 00670	∂03-Oct-88  1309	CL-Cleanup-mailer 	Deprication, cleanup goals, performance  
C03196 00671	∂03-Oct-88  1323	CL-Cleanup-mailer 	Deprecation, cleanup goals, performance  
C03199 00672	∂03-Oct-88  1538	CL-Cleanup-mailer 	Re: Issue: NTH-VALUE (Version 2)    
C03202 00673	∂03-Oct-88  1539	CL-Cleanup-mailer 	Re: Issue: KILL-PACKAGE (Version 2) 
C03204 00674	∂03-Oct-88  1720	CL-Cleanup-mailer 	Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2) 
C03209 00675	∂03-Oct-88  1854	CL-Cleanup-mailer 	Re: Issue: PRINT-PRETTY-HOOK (version 1) 
C03212 00676	∂03-Oct-88  1932	CL-Cleanup-mailer 	Issue: TEST-NOT-IF-NOT (Version 1)  
C03215 00677	∂03-Oct-88  1954	CL-Compiler-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
C03222 00678	∂03-Oct-88  1959	CL-Compiler-mailer 	New Issue: SYNTACTIC-ENVIRONMENT-ACCESS 
C03224 00679	∂03-Oct-88  2042	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 4)  
C03227 00680	∂03-Oct-88  2049	CL-Cleanup-mailer 	Issue: DECLARE-FUNCTION-AMBIGUITY (version 3) 
C03230 00681	∂03-Oct-88  2102	CL-Cleanup-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS   
C03236 00682	∂04-Oct-88  0911	CL-Cleanup-mailer 	Re: Issue: PRINT-PRETTY-HOOK (version 1) 
C03240 00683	∂04-Oct-88  1223	CL-Cleanup-mailer 	Issue: EXPT-RATIO (Version 1)  
C03246 00684	∂04-Oct-88  1303	CL-Cleanup-mailer 	Issue: EXPT-RATIO (Version 1)  
C03248 00685	∂04-Oct-88  1410	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (Version 2) 
C03250 00686	∂04-Oct-88  1419	CL-Cleanup-mailer 	Issue: KILL-PACKAGE (Version 2)
C03252 00687	∂04-Oct-88  1420	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (Version 3) 
C03258 00688	∂04-Oct-88  1431	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 2)  
C03261 00689	∂04-Oct-88  1434	CL-Cleanup-mailer 	Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
C03265 00690	∂04-Oct-88  1508	CL-Cleanup-mailer 	Issue: KILL-PACKAGE (Version 3)
C03279 00691	∂04-Oct-88  1548	CL-Cleanup-mailer 	Re: Issue: TAGBODY-CONTENTS (Version 3)  
C03282 00692	∂04-Oct-88  1557	CL-Cleanup-mailer 	Re: Issue: TAGBODY-CONTENTS (Version 3)  
C03286 00693	∂05-Oct-88  0059	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)    
C03304 00694	∂05-Oct-88  0110	CL-Cleanup-mailer 	Re: Issue: LIST-TYPE-SPECIFIER (Version 1)    
C03307 00695	∂05-Oct-88  0739	CL-Cleanup-mailer 	Issue: TEST-NOT-IF-NOT (Version 1)  
C03309 00696	∂05-Oct-88  1102	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 2)  
C03320 00697	∂05-Oct-88  1105	CL-Cleanup-mailer 	Issue: TEST-NOT-IF-NOT (Version 2)  
C03329 00698	∂05-Oct-88  1121	CL-Cleanup-mailer 	Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2) 
C03336 00699	∂05-Oct-88  1145	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)    
C03338 00700	∂05-Oct-88  1151	CL-Cleanup-mailer 	Re: Issue: TAGBODY-CONTENTS (Version 3)  
C03340 00701	∂05-Oct-88  1203	CL-Cleanup-mailer 	Re: Issue: TAGBODY-CONTENTS (Version 3)  
C03343 00702	∂05-Oct-88  1207	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 2)   
C03345 00703	∂05-Oct-88  1221	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)    
C03349 00704	∂05-Oct-88  1342	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 2)  
C03352 00705	∂05-Oct-88  1353	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 2)   
C03355 00706	∂05-Oct-88  1416	CL-Cleanup-mailer 	Issue: NTH-VALUE (Version 3)   
C03361 00707	∂05-Oct-88  1417	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
C03363 00708	∂05-Oct-88  1417	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 3)  
C03377 00709	∂05-Oct-88  1510	CL-Cleanup-mailer 	Re: Potential Clean-Up Issues  
C03386 00710	∂05-Oct-88  1511	CL-Cleanup-mailer 	Issue: TEST-NOT-IF-NOT (Version 1)  
C03388 00711	∂05-Oct-88  1543	CL-Cleanup-mailer 	Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
C03392 00712	∂05-Oct-88  1551	CL-Cleanup-mailer 	Re: Issue: PACKAGE-CLUTTER (Version 3)   
C03394 00713	∂05-Oct-88  1558	CL-Cleanup-mailer 	New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
C03398 00714	∂05-Oct-88  1612	CL-Cleanup-mailer 	Issue: EXPT-RATIO (Version 1)  
C03400 00715	∂05-Oct-88  1725	CL-Cleanup-mailer 	Issue: KILL-PACKAGE (Version 3)
C03407 00716	∂05-Oct-88  1934	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
C03412 00717	∂05-Oct-88  2032	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (Version 4) 
C03420 00718	∂05-Oct-88  2044	CL-Cleanup-mailer 	Re: Issue: TAGBODY-CONTENTS (Version 4)  
C03422 00719	∂05-Oct-88  2049	CL-Cleanup-mailer 	Re: Issue: TAGBODY-CONTENTS (Version 4)  
C03425 00720	∂05-Oct-88  2050	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03436 00721	∂05-Oct-88  2154	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03442 00722	∂05-Oct-88  2312	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
C03445 00723	∂05-Oct-88  2330	CL-Cleanup-mailer 	Issue: FORMAT-PRETTY-PRINT (version 5)   
C03449 00724	∂06-Oct-88  0019	CL-Cleanup-mailer 	Issue: LIST-TYPE-SPECIFIER (Version 1)   
C03453 00725	∂06-Oct-88  0114	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 4)  
C03458 00726	∂06-Oct-88  0125	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)    
C03464 00727	∂06-Oct-88  0132	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 3)  
C03468 00728	∂06-Oct-88  0207	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 8) 
C03490 00729	∂06-Oct-88  0827	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
C03492 00730	∂06-Oct-88  1019	CL-Cleanup-mailer 	several hundred ugly things    
C03495 00731	∂06-Oct-88  1034	Common-Lisp-Object-System-mailer 	Re: Issue: EVAL-OTHER (Version 2)   
C03502 00732	∂06-Oct-88  1213	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
C03504 00733	∂06-Oct-88  1237	CL-Cleanup-mailer 	Issue: TEST-NOT-IF-NOT (Version 1)  
C03506 00734	∂06-Oct-88  1258	CL-Cleanup-mailer 	Re: Issue: PRINT-PRETTY-HOOK (version 1) 
C03510 00735	∂06-Oct-88  1302	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (Version 4) 
C03512 00736	∂06-Oct-88  1315	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)    
C03515 00737	∂06-Oct-88  1343	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
C03519 00738	∂06-Oct-88  1350	CL-Cleanup-mailer 	Issue: RETURN-VALUES-UNSPECIFIED (Version 3)  
C03523 00739	∂06-Oct-88  1530	CL-Cleanup-mailer 	Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)    
C03533 00740	∂06-Oct-88  1532	CL-Cleanup-mailer 	Issue:	SETF-SUB-METHODS (Version 5) 
C03561 00741	∂06-Oct-88  1620	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 5) 
C03565 00742	∂06-Oct-88  1623	CL-Cleanup-mailer 	Re: Issue: STRUCTURE-INFO (Version 1)    
C03568 00743	∂06-Oct-88  1642	CL-Cleanup-mailer 	SUBTYPEP-TOO-VAGUE, version 3  
C03575 00744	∂06-Oct-88  1649	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 5)  
C03577 00745	∂06-Oct-88  1755	CL-Cleanup-mailer 	Re: several hundred ugly things     
C03584 00746	∂06-Oct-88  1851	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 2)    
C03592 00747	∂06-Oct-88  1852	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 2)    
C03601 00748	∂06-Oct-88  1909	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 2)    
C03604 00749	∂06-Oct-88  1958	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 2)    
C03608 00750	∂06-Oct-88  1958	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 6)    
C03630 00751	∂06-Oct-88  2002	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03632 00752	∂06-Oct-88  2057	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 5)
C03634 00753	∂06-Oct-88  2115	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 5)  
C03650 00754	∂06-Oct-88  2118	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 4)  
C03652 00755	∂06-Oct-88  2124	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03655 00756	∂06-Oct-88  2220	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)   
C03664 00757	∂07-Oct-88  0017	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)   
C03678 00758	∂07-Oct-88  0650	CL-Cleanup-mailer 	Re: Issue: PRINT-CIRCLE-STRUCTURE (Version 1) 
C03681 00759	∂07-Oct-88  0743	CL-Cleanup-mailer 	Issue FIXNUM-NON-PORTABLE (Version 3)    
C03683 00760	∂07-Oct-88  0836	CL-Cleanup-mailer 	Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2) 
C03688 00761	∂07-Oct-88  0848	CL-Cleanup-mailer 	Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2) 
C03691 00762	∂07-Oct-88  1020	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)   
C03694 00763	∂07-Oct-88  1102	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)   
C03700 00764	∂07-Oct-88  1106	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 2)    
C03702 00765	∂07-Oct-88  1115	CL-Cleanup-mailer 	SUBTYPEP-TOO-VAGUE, version 3  
C03705 00766	∂07-Oct-88  1144	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 3) 
C03720 00767	∂07-Oct-88  1212	CL-Cleanup-mailer 	several hundred ugly things    
C03723 00768	∂07-Oct-88  1222	CL-Cleanup-mailer 	Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2) 
C03726 00769	∂07-Oct-88  1222	CL-Compiler-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
C03732 00770	∂07-Oct-88  1305	CL-Cleanup-mailer 	PRINT-CIRCLE-STRUCTURE    
C03740 00771	∂07-Oct-88  1418	CL-Cleanup-mailer 	Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES  
C03747 00772	∂07-Oct-88  1501	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 1)     
C03759 00773	∂07-Oct-88  1528	CL-Cleanup-mailer 	Issue: DEFPACKAGE (version 5)  
C03761 00774	∂07-Oct-88  1556	CL-Cleanup-mailer 	Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES  
C03765 00775	∂07-Oct-88  1608	CL-Cleanup-mailer 	Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES   
C03768 00776	∂07-Oct-88  1616	CL-Cleanup-mailer 	Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES   
C03774 00777	∂07-Oct-88  1640	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)   
C03781 00778	∂07-Oct-88  1643	CL-Cleanup-mailer 	Re: Issue: LIST-TYPE-SPECIFIER (Version 1)    
C03783 00779	∂07-Oct-88  1643	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (Version 2)   
C03792 00780	∂07-Oct-88  1702	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 4) 
C03806 00781	∂07-Oct-88  1732	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-STRUCTURE (Version 1)     
C03809 00782	∂07-Oct-88  1738	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 4) 
C03813 00783	∂07-Oct-88  1743	CL-Cleanup-mailer 	Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
C03818 00784	∂07-Oct-88  1746	CL-Cleanup-mailer 	Issue: SYMBOL-MACROFLET (Version 1) 
C03820 00785	∂07-Oct-88  1752	CL-Cleanup-mailer 	Issue SYMBOL-MACROLET-SEMANTICS, Version 4    
C03822 00786	∂07-Oct-88  1757	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)   
C03825 00787	∂07-Oct-88  1802	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 6)    
C03827 00788	∂07-Oct-88  1805	CL-Cleanup-mailer 	New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
C03863 00789	∂07-Oct-88  1812	CL-Cleanup-mailer 	Issue:	SETF-SUB-METHODS (Version 5) 
C03868 00790	∂07-Oct-88  2013	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03870 00791	∂07-Oct-88  2018	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-STRUCTURE (version 1.1)   
C03872 00792	∂07-Oct-88  2019	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)   
C03877 00793	∂07-Oct-88  2019	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03881 00794	∂07-Oct-88  2028	CL-Cleanup-mailer 	Re: several hundred ugly things     
C03884 00795	∂07-Oct-88  2041	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 4) 
C03887 00796	∂07-Oct-88  2018	CL-Cleanup-mailer 	New Issue: SYNTACTIC-ENVIRONMENT-ACCESS  
C03892 00797	∂07-Oct-88  2019	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (Version 2)   
C03894 00798	∂07-Oct-88  2041	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03897 00799	∂07-Oct-88  2041	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)    
C03902 00800	∂07-Oct-88  2128	CL-Cleanup-mailer 	Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)   
C03919 00801	∂07-Oct-88  2149	CL-Cleanup-mailer 	Re: Issue: LIST-TYPE-SPECIFIER (Version 1)    
C03921 00802	∂07-Oct-88  2150	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (Version 3)   
C03930 00803	∂07-Oct-88  2150	CL-Cleanup-mailer 	Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS   
C03932 00804	∂07-Oct-88  2150	CL-Cleanup-mailer 	Re: Issue: SETF-SUB-METHODS (Version 5)  
C03934 00805	∂07-Oct-88  2150	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 4)  
C03950 00806	∂07-Oct-88  2304	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 5)  
C03952 00807	∂07-Oct-88  2343	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 7)    
C03975 00808	∂07-Oct-88  2351	CL-Cleanup-mailer 	Issue Status (finally!!)  
C03994 ENDMK
C⊗;
∂19-Jun-88  2245	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Jun 88  22:45:51 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 19 JUN 88 22:44:31 PDT
Date: 19 Jun 88 22:44 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: COERCE-INCOMPLETE
In-reply-to: Masayuki Ida <ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET>'s
 message of Mon, 13 Jun 88 11:07:16 JST
To: ida%aoyama.cc.aoyama.junet%UTOKYO-RELAY.CSNet@relay.cs.net
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880619-224431-6041@Xerox>

A brief summary of our discussion of the issue COERCE-INCOMPLETE:

We think that COERCE is incomplete in some ways. However, we are not all happy
with the ways that you propose. 

Making COERCE symmetric would probably be a bad idea, e.g., that it can coerce
from INTEGER to FLOAT and not from FLOAT to INTEGER is on purpose. 

We think COERCE from integer to character is odd and non-portable and think it
perhaps should be removed from the standard.

COERCE from character to STRING is a good idea. 

We are now puzzled by the inconsistency of (COERCE x 'STRING) vs (STRING x) and
want to reduce it.

We would like (COERCE x 'PATHNAME) to work like (PATHNAME x). 

The reason that (COERCE symbol 'STRING) is difficult is that (COERCE 'NIL
'STRING) as a symbol could return "NIL", but (COERCE '() 'STRING) as the empty
list could return "". 

FUNCTION-TYPE has extended COERCE to work for 'FUNCTION.

∂20-Jun-88  0729	CL-Cleanup-mailer 	KCL scoping bug?
Received: from CLI.COM by SAIL.Stanford.EDU with TCP; 20 Jun 88  07:27:35 PDT
Received: by CLI.COM (4.0/1); Mon, 20 Jun 88 09:22:45 CDT
Date: Mon, 20 Jun 88 09:22:45 CDT
From: Robert S. Boyer <boyer@CLI.COM>
Message-Id: <8806201422.AA07863@CLI.COM>
To: cl-cleanup@sail.stanford.edu
Cc: yuasa%tutics.tut.junet%utokyo-relay.csnet@RELAY.CS.NET,
        Masinter.pa@Xerox.COM
Subject: KCL scoping bug?

Larry,

Here is all the correspondence on that particular issue from the kcl
mailing list.

From: vax135!melmac!ilan@ucbvax.Berkeley.EDU
Date: Tue, 3 May 88 10:25:26 edt
To: ilan@ucbvax.Berkeley.EDU, vax135!froggy.ics.utexas.edu!boyer
Subject: KCL scoping bug?

Hi,

I'm not sure how to post stuff to the KCL board at the moment, so I'm
sending this to you.  If you deem it worthwhile please post it
to the KCL mailing-list.

The following produces a scoping error in the interpreter (June 3, 87) -
the compiler handles the code correctly. (The example is lifted 
directly from CLtL p. 155).


---------

>
(setq x 'x-dyn z 'z-dyn)Z-DYN

>
(load "nonsense.l")Loading nonsense.l
Finished loading nonsense.l
T

>
#'foo
(LAMBDA-BLOCK FOO (&REST ARGS) (PRINT ARGS) (LIST ARGS))

>#'nonsense
(LAMBDA-BLOCK NONSENSE (K X Z)
  (FOO Z X)
  (LET ((J (FOO K X)) (X (* K K)))
    (DECLARE (INLINE FOO) (SPECIAL X Z))
    (FOO X J Z)))

>(nonsense 1 2 3)
(3 2)
(1 2)			;;; <---- SHOULD BE (1 X-DYN)
(1 ((1 2)) Z-DYN)	;;; <---- SHOULD BE (1 ((1 X-DYN)) Z-DYN)
((1 ((1 2)) Z-DYN))	;;; <---- SHOULD BE ((1 ((1 X-DYN)) Z-DYN))

>(compile 'nonsense)End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
NONSENSE

>
(nonsense 1 2 3)
(3 2)
(1 X-DYN)
(1 ((1 X-DYN)) Z-DYN)
((1 ((1 X-DYN)) Z-DYN))

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


--Ilan Caron ..!ucbvax!vax135!lcuxlj!ilan

From: vax135!melmac!ilan@ucbvax.Berkeley.EDU
Date: Tue, 24 May 88 13:41:32 edt
Message-Id: <8805241741.AA29869@vax135.UUCP>
To: ilan@ucbvax.Berkeley.EDU, vax135!cli.com!kcl
Subject: KCL scoping bug?


A couple of weeks ago I posted what seemed to be a KCL interpreter
scoping bug using the example from CLtL p. 155.

Having seen no response to what seems to be a potential source
of major confusion, I'm reposting the bug - this time on a simpler
piece of code.  The interpreter doesn't make a special reference
for Y in spite of the special declaration.

Please note that the bug only manifests itself when interpreted, the
compiler handles the situation correctly.


------------------
KCL (June 3, 1987)
------------------

Starts dribbling to x (1988/5/25, 2:29:20).
NIL

> #'foo
(LAMBDA-BLOCK FOO (X Y Z)
  (LET ((X Y) (Y Z)) (DECLARE (SPECIAL Y Z)) (LIST X Y Z)))

>(setq x 'dyn-x y 'dyn-y z 'dyn-z)
DYN-Z

>(foo 'lex-x 'lex-y 'lex-z)
(LEX-Y DYN-Z DYN-Z)			;;; <---- should be (DYN-Y ...)

> (compile 'foo)
; (DEFUN FOO ...) is being compiled.
;; Warning: The variable X is not used.
;; Warning: The variable Y is not used.
;; Warning: The variable Z is not used.
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
FOO

>(foo 'lex-x 'lex-y 'lex-z)
(DYN-Y DYN-Z DYN-Z)			;;; <---- this is correct

>

---------
--ilan caron

Date: Thu, 26 May 88 10:10:26 jst
From: Taiichi Yuasa <yuasa%tutics.tut.junet@relay.cs.net>
To: kcl@cli.com
Subject: Re: KCL scoping bug?


Here's the story.
I noticed long time ago that there's an inconsistency as you
posted.  However, at that time I did not know which interpretation
is correct.  So, I decided to leave the inconsistency until
someone (x3j13, perhaps) clarifies which is correct.  I still do not
know which is correct.  It's easy to solve the inconsistency.
Is there any general consensus on this matter?
If most people agree that the compiler is correct and the interpreter
is wrong, I'm happy to fix the bug immediately.

-- Taiichi



Received: by CLI.COM (4.0/1); Tue, 31 May 88 12:41:47 CDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
	id AA01603; Tue, 31 May 88 09:18:42 PDT
From: vax135!melmac!ilan@ucbvax.Berkeley.EDU
Date: Tue, 31 May 88 12:13:03 edt
Message-Id: <8805311613.AA03145@vax135.UUCP>
To: vax135!cli.com!kcl
Subject: Re:  KCL scoping bug?


The example and explanation on p. 155 CLtL makes it pretty
clear that the compiler is correct, (i.e. that the special
declaration also applies to references within the initforms
of a LET) - in particular, The Book says: "The reference
to X in the second call to FOO is also a special reference".

------------------------------------------------------------
For those interested, the relevant nonsensical code is:

  (defun nonsense (k x z)
    (foo z x)
    (let
     (
      (j (foo k x))	;;; <--- the problematic reference to X
      (x (* k k))
      )
     (declare (inline foo) (special x z))
     (foo x j z)
     )
    )

--ilan caron

∂20-Jun-88  0748	CL-Cleanup-mailer 	Common Lisp Semantics for Function Call  
Received: from CLI.COM by SAIL.Stanford.EDU with TCP; 20 Jun 88  07:48:10 PDT
Received: by CLI.COM (4.0/1); Mon, 20 Jun 88 09:43:23 CDT
Date: Mon, 20 Jun 88 09:43:23 CDT
From: Robert S. Boyer <boyer@CLI.COM>
Message-Id: <8806201443.AA08049@CLI.COM>
To: cl-cleanup@sail.stanford.edu
Cc: yuasa%tutics.tut.junet%utokyo-relay.csnet@RELAY.CS.NET,
        Masinter.pa@Xerox.COM, wfs@CLI.COM
Subject: Common Lisp Semantics for Function Call

In the case of an ordinary function call, does Common Lisp specify
whether the symbol-function is grabbed before or after the args are
evaluated?  Symbolics and KCL do it "before" when interpreting and
"after" when running compiled code.  This question was previously
reported to the Common Lisp mailing list, by Bill Schelter around
December 87 I think, but I saw no response.

It seems to me that the natural solution is to go "before".  This

  (a) provides an extension of the left-to-right-order of evaluation 
      that is part of Common Lisp (even if it is not in the manual), and
  (b) is consistent with the idea that you need, when interpreting,
      to look at the definition of the car of the form to decide
      whether it is a macro or not.

Below is an illustration of the problem of "before" vs. "after",
in KCL.


>(defun foo ()
   (setf (symbol-function 'bar) #'(lambda (x) (print 'old)))
   (bar (setf (symbol-function 'bar) #'(lambda (x) (print 'new)))))
FOO

>(foo)

OLD
OLD

>(foo)

OLD
OLD

>(foo)

OLD
OLD

>(compile 'foo)
FOO

>(foo)

NEW
NEW

>(foo)

NEW
NEW

>(foo)

NEW
NEW

;  It is, of course, unnecessary to observe that such coding is
;  inelegant, even repulsive.

∂20-Jun-88  0921	CL-Cleanup-mailer 	Issue: COERCE-FROM-TYPE (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Jun 88  09:21:27 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 421917; Mon 20-Jun-88 12:20:05 EDT
Date: Mon, 20 Jun 88 12:19 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COERCE-FROM-TYPE (Version 1) 
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880620121941.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:          COERCE-FROM-TYPE
References:     COERCE (p51)
Related-Issues: COERCE-INCOMPLETE
Category:       ADDITION
Edit history:   20-Jun-88, Version 1 by Pitman
Status:	        For Internal Discussion

Problem Description:

  COERCE is difficult to extend because ambiguities arise about the
  source type of the coercion.

  For example, should (COERCE NIL 'STRING) return "" or "NIL".
  The choice would be arbitrary unless you knew whether NIL was being
  viewed as an empty list or a symbol.

  Similarly, (COERCE (CHAR-CODE #\A) 'STRING) might return the same
  as (FORMAT NIL "~D" (CHAR-CODE #\A)) -- "65" in most ASCII-based
  implementations -- or it might return "A", depending on whether the
  result of char-code was viewed as a number or more specifically as
  a character code.

Proposal (COERCE-FROM-TYPE:NEW-ARGUMENT):

  Add an extra optional argument to COERCE which specifies the type
  from which the coercion is to be done. The new syntax would be:

   COERCE object to &optional (from (TYPE-OF object))

  Constrain that FROM must be such that (TYPEP OBJECT FROM) is true.

Rationale:

  This leaves room for a subsequent proposal to extend COERCE in
  interesting ways. For example, extensions such as the following
  might be considered:

   (COERCE NIL 'STRING 'LIST)   => ""
   (COERCE NIL 'STRING 'SYMBOL) => "NIL"

  A new type CHAR-CODE might even be introduced as
   (DEFTYPE CHAR-CODE () `(INTEGER 0 (,CHAR-BITS-LIMIT)))
  so that COERCE could handle cases like:

   (EQUAL (COERCE (CHAR-CODE #\A) 'STRING 'NUMBER)
	  (FORMAT NIL "~D" (CHAR-CODE #\A))) => T
   (COERCE (CHAR-CODE #\A) 'STRING 'CHAR-CODE) => "A"

  Such specific proposals are deliberately not part of this proposal
  in order to separate the general purpose mechanism from the more
  specific details.

Current Practice:

  Probably no one implements the proposed behavior at this time.

Cost to Implementors:

  The more optimization a compiler does (or might do) of COERCE, the more
  work might be necessary. In general, however, the changes would probably
  not involve a major amount of work.

Cost to Users:

  This change is upward compatible.

Cost of Non-Adoption:

  Various proposals to extend COERCE would probably not pass because
  not everyone can agree on how to view the type of the first argument
  when more than one type is possible.

Benefits:

  More (if not all) kinds of coercions in the language would be able
  to go through COERCE. Documentation and ease of use would be simplified.

Aesthetics:

  A part of the language which is currently in somewhat of a disarray
  would become more organized, making it simpler to explain and easier
  to learn.

Discussion:

  Pitman wrote and supports COERCE-FROM-TYPE:NEW-ARGUMENT.

  Pitman is also studying similar generalizations of EQUAL and COPY that
  might address the numerous problems with those operators.

  The main obstacle to extending COERCE in the past has been that when an
  object could be viewed as more than one type, confusion might result if
  people did not agree on the view in use. Since if this proposal passed
  there is a way to specify the view type of the object going in, it might
  then be worth considering whether COERCE should be made generic and
  whether a standard protocol for extending it could be defined.

∂20-Jun-88  1149	CL-Cleanup-mailer 	comments on draft proposals    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Jun 88  11:49:49 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA21981; Mon, 20 Jun 88 12:48:31 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8806201848.AA21981@cs.utah.edu>
Date: Mon, 20 Jun 88 12:48:30 MDT
Subject: comments on draft proposals
To: cl-cleanup@sail.stanford.edu

EQUAL-STRUCTURE:  My favorite alternative is CHANGE-EQUALP.  I have found
the current definition of EQUALP to be pretty useless.  I actually think
that the most useful behavior would be to have EQUAL descend only list
structures and compare everything else with EQL, and have EQUALP descend
arrays and structures as well as lists while making it consider characters
of different case and numbers of different types distinct.

DEFPACKAGE:  I like this proposal.  About the only thing I would change
would be making the options that only use the names of the symbols
(everything but :IMPORT and :SHADOWING-IMPORT) take strings as well.
I would also like to see some clarification of the order in which things
happen:  do the clauses get processed in the order they appear, or in
"Put In Seven Extremely Random User Interface commands" order, or in
some other order?  The compiler cleanup group would be willing to put
forward a proposal to remove the magic status of the N random package
forms, but I think the DEFPACKAGE proposal can stand on its own.

DECLARATION-SCOPE:  Seems OK to me.  It is at least more understandable
than the current language in CLtL.

-Sandra
-------

∂20-Jun-88  1311	CL-Cleanup-mailer 	Issue: FUNCTION-COERCE-TIME (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Jun 88  13:11:35 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 422133; Mon 20-Jun-88 16:10:25 EDT
Date: Mon, 20 Jun 88 16:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COERCE-TIME (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880620160959.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        FUNCTION-COERCE-TIME
References:   SET-MACRO-CHARACTER (p362),
	      SET-DISPATCH-MACRO-CHARACTER (p364),
	      MAP (p249), MAPL (p129), ...
	      Functions using :TEST, :KEY, etc. (REDUCE, MEMBER, DELETE, ...)
	      Functions using a positional predicate (SORT, DELETE-IF, ...)
Category:     CLARIFICATION
Edit history: 20-Jun-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  Many functions which accept arguments which are to be treated functionally
  but which are not of type FUNCTION. This functionality can be very useful,
  but the time at which the coercion is accomplished must be made clear.

Proposal (FUNCTION-COERCE-TIME:LAZY):

  Specify that when a non-function (eg, a symbol) is used in place of a
  function as an argument to operators which take functional arguments,
  the coercion of that non-function to a function is delayed as long as
  possible. That is, it is as if the result of calling
   #'(LAMBDA (NON-FUNCTION)
       #'(LAMBDA (&REST ARGUMENTS)
	   (APPLY NON-FUNCTION ARGUMENTS)))
  on the non-functional argument were passed instead.

  Rationale:
  
    One of the main reasons that it may be useful to pass a non-function
    instead of a function is to accomplish indirection which allows later
    redefinitions to take proper effect. Early binding would tend to
    thwart the usefulness of such indirection and force people into
    notationally more clumsy devices.

Proposal (FUNCTION-COERCE-TIME:AMBITIOUS):

  Specify that when a non-function (eg, a symbol) is used in place of a
  function as an argument to operators which take functional arguments,
  the coercion of that non-function to a function is done immediately.

  Rationale:

    This is easier to implement since the coercion is done up front and
    no further worry about uncoerced functions is needed internally.

    Also, inlining of mapped functions (without using temporary storage
    to hold a cached value of the function being mapped) can be done
    without needing to know whether the function being inlined will
    affect the place which holds the functional argument being passed.

Proposal (FUNCTION-COERCE-TIME:HYBRID):

  Specify that when a non-function (eg, a symbol) is used in place of a
  function as an argument to operators which take functional arguments,
  the coercion of that non-function to a function must be done immediately
  if the functional argument is to be used only internally to the function
  (eg, SORT or MAPCAR) but is delayed as long as possible otherwise. (eg,
  SET-MACRO-CHARACTER). That is, it is as if the result of calling
   #'(LAMBDA (NON-FUNCTION)
       #'(LAMBDA (&REST ARGUMENTS)
	   (APPLY NON-FUNCTION ARGUMENTS)))
  on the non-functional argument were passed instead.

  Rationale:

    Debugging is enhanced for operations such as SET-MACRO-CHARACTER
    without needlessly hampering useful optimizations to things like
    SORT or MAPCAR, which very rarely require this facility.

Test Cases:

  (DEFVAR *SOME-FUNCTIONS*
	  (LIST #'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 1)
		#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 2)
	        #'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 3)
	        #'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 4)))

  ; Control situation A
  (PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
	 (LIST (MAPCAR #'(LAMBDA (&REST X) (APPLY #'FOO X))
		       *SOME-FUNCTIONS*)
	       (FOO T)))
  => ((1 1 2 3) 4)

  ; Control situation B
  (LET ((FOO (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))))
    (LIST (MAPCAR FOO
		  *SOME-FUNCTIONS*)
		  (FOO T)))
  => ((1 1 1 1) 4)

  ; Interesting Situation 1
  (PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
	 (LIST (MAPCAR #'FOO
		       *SOME-FUNCTIONS*)
	       (FOO T)))
  =>    ((1 1 2 3) 4)				;Lazy-1
     or ((1 1 1 1) 4)				;Ambitious-1


  ; Interesting Situation 2
  (PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
	 (LIST (MAPCAR 'FOO
		       *SOME-FUNCTIONS*)
	       (FOO T)))
  =>    ((1 1 2 3) 4)				;Lazy-2
     or ((1 1 1 1) 4)				;Ambitious-2

  (DEFUN SHARP-DOLLAR (STREAM CHAR N)
    (DECLARE (IGNORE CHAR))
    (EXPT (READ STREAM) (OR N 1)))

  (SET-DISPATCH-MACRO-CHARACTER #\# #\$ 'SHARP-DOLLAR)

  (VALUES (READ-FROM-STRING "(#$3 #4$3)"))
  => (3 81)

  (DEFUN SHARP-DOLLAR (STREAM CHAR N)
    (DECLARE (IGNORE CHAR))
    (+ (READ STREAM) (* (OR N 0) 0.01))) 

  (VALUES (READ-FROM-STRING "(#$3 #4$3)"))
  => (3.0 3.04)					;Lazy-3
     (3 81)					;Ambitious-3

  Proposal LAZY      requires LAZY-1,      LAZY-2,      LAZY-3.
  Proposal AMBITIOUS requires AMBITIOUS-1, AMBITIOUS-2, AMBITIOUS-3.
  Proposal HYBRID    requires AMBITIOUS-1, AMBITIOUS-2, LAZY-3.

Current Practice:

  Implementations are permitted to differ in when they do the coercion since
  the coercion time is not clearly spelled out.

  (In the test case, LAZY-1 can occur only if MAPCAR is inlined, and then
  only if the original value of the function definition is not cached.)

  [Some info below is based on empirical testing -- I didn't look at the
   source or try to see how speed/safety affect things. -kmp]

  Symbolics Genera implements AMBITIOUS-1 interpreted and LAZY-1 compiled.
  Symbolics Cloe (a compiled-only lisp) implements LAZY-1 both `interpreted'
   and compiled.

  Both Symbolics Genera and Symbolics Cloe implement LAZY-2.

  Symbolics Genera implements LAZY-3.
  Symbolics Cloe implements AMBITIOUS-3.

Cost to Implementors:

  [Costs may vary widely depending on current practice.
   I'll leave this one open for now pending feedback from others. -kmp]

Cost to Users:

  This change is upward compatible.

Cost of Non-Adoption:

  A very important aspect of the language would be left unspecified.
  Portability would suffer.

Benefits:

  HYBRID has the benefit of making things like readmacros easier to debug.

  LAZY offers the additional benefit of being able to repair certain
  functional arguments to SORT or MAPCAR (eg, as a symbol) in the debugger,
  and then to proceed the error (in implementations offering that restart
  option) in a way that makes the ongoing call to SORT or MAPCAR notice
  the repairwork right away.

Aesthetics:

  Since this is a visible aspect of the language, anything which clarified
  the behavior that a programmer might expect would seem to improve the
  aesthetics somewhat.

Discussion:

  This issue was raised by Nick Gall and written up by Pitman.
  Pitman supports FUNCTION-COERCE-TIME:HYBRID.

∂20-Jun-88  1312	CL-Cleanup-mailer 	Issue: ALIST-NIL (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Jun 88  13:12:48 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 422136; 20 Jun 88 16:11:32 EDT
Date: Mon, 20 Jun 88 16:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ALIST-NIL (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880620161106.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Character-Type-Mappings: (1 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI")
Fonts: CPTFONT, CPTFONTI

Issue:        ALIST-NIL
References:   Definition of "a-list" (p279), ASSOC (p280)
Category:     CHANGE
Edit history: 20-Jun-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  NIL is permitted to be an element of an a-list but nothing useful
  can be done with such an element.

Proposal (ε1issue-nameε0:ε1proposal-nameε0):

  Change the definition of an a-list to require all elements to be
  real conses. Uses of ASSOC with non-standard a-list would be an error.

Test Case:

  (ASSOC 'X '(NIL (X . 3)))
  is currently defined to return (X . 3).
  Under this proposal, this would be an error.

Rationale:

  No motivation in CLtL is given for NIL being allowed in an a-list.

  The description of a-lists seem needlessly complicated by this feature.

  FIND (with a :KEY of #'CAR) and ASSOC (with no key) are almost identical
  except for their treatment of this issue. If no one makes significant
  use of the feature, it would be better to be able to simplify the
  relationship between these functions.

Current Practice:

  All valid implementations allow NIL.

Cost to Implementors:

  Since the proposal is to make this an "is an error" situation, no
  implementation would be forced to change.

Cost to Users:

  There are two basic ways in which the author is able to guess this
  feature might be used:

  #1: A user might want a leading NIL on an a-list so that if the list
  were empty, there'd still be a tail to which cells could be attached
  in the future. That is,
   (DEFVAR *MY-ALIST* (CONS NIL '()))
  so that 
   ...(NCONC *MY-ALIST* (LIST new-cell))...
  would always be possible as a side-effect and
   ...(ASSOC element *MY-ALIST*)...
  would always be possible for lookup. It might be argued that this is more
  clearly written:
   (DEFVAR *MY-TABLE* (CONS NIL '()))
   (DEFUN ADD-ENTRY (ENTRY TABLE) (NCONC TABLE (LIST ENTRY)))
   (DEFMACRO MY-TABLE-CONTENTS (X) `(CDR ,X))
   ...(ADD-ENTRY new-cell *MY-TABLE*)...
   ...(ASSOC element (MY-TABLE-CONTENTS *MY-TABLE*))...

  #2: A user might want to splice out an element from an a-list, preserving
  the place that the element occupied in the list. In the very rare cases
  where this was necessary, one could rewrite:
   (DEFUN VOID-FIRST-ENTRY (ALIST) (SETF (CAR ALIST) NIL))
  as:
   (DEFUN VOID-FIRST-ENTRY (ALIST)
     (LET ((ENTRY (CONS NIL NIL)))
       (SETF (CAR ENTRY) ENTRY) ;Something unique
       (SETF (CAR ALIST) ENTRY)))

Cost of Non-Adoption:

  There only consequence of non-adoption is the burden of carrying around
  the additional complexity in each implementation, in the documentation,
  and in teaching. The cost of this burden is likely to be a subjective
  matter.

Benefits:

  Simplified documentation.

Aesthetics:

  This change would simplify the language.

Discussion:

  Pitman submitted this proposal after looking at the write-up of
  a-lists in the new standard. The description seems needlessly
  cluttered by this unmotivated and he felt that either a motivation
  for this feature should be cited and defended or the feature should
  go away. The degree to which he believes in this feature will be
  determined by any claims made by others in ensuing discussion.

  Some people might consider this change gratuitous.

∂20-Jun-88  1316	CL-Cleanup-mailer 	Issue: TRACE-ERROR (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Jun 88  13:16:01 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 422142; Mon 20-Jun-88 16:14:36 EDT
Date: Mon, 20 Jun 88 16:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TRACE-ERROR (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880620161405.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        TRACE-ERROR
References:   TRACE (p440), UNTRACE (p440)
Category:     CHANGE
Edit history: 20-Jun-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  TRACE does not signal an error when given invalid options in
  some implementations. For example, more than one implementation
  might an extended syntax such as:
   (TRACE (FOO {key value}*))
  but they might still vary as to what options they provided.
  In some such implementations, GET might be used to detect the 
  options the implementation is interested in, rather than iterating
  down the list trying to determine which options really apply.
  As such, if
   (TRACE (FOO :WHEREIN BAR))
  is done by someone used to an implementation that allowed a :WHEREIN
  keyword, an implementation might simply ignore the :WHEREIN keyword.
  It may not be until a computation is well underway that the ignored
  (possibly mis-named or mis-spelled) keyword is detected. Backing up
  to retry the trace once the problem is detected may be expensive and
  frustrating.

Proposal (TRACE-ERROR:REQUIRE-SIGNAL):

  Permit the use of non-standard syntax, but require that TRACE and UNTRACE
  do careful syntax checking and signal an error if any unknown options
  or syntax are used.

Test Case:

  (TRACE (FOO :WHEREIN BAR))
  might mean any of a variety of things, but would not be permitted to just
  trace FOO and silently ignore the :WHEREIN option as if it had not been
  specified.

Rationale:

  TRACE is an environmental interface which varies greatly between
  implementations. Implementors moving frequently between implementations
  can get confused about which implementation they are dealing with and
  make mistakes that were trivially avoidable by simple error checking at
  the proper time.

  Some errors of this kind are not eliminated by this proposal. For example,
  two implementations may use the same syntax and/or option in different ways.
  However, in many cases where implementations offer extensions, the namings
  are not done in a vacuum and they frequently try to agree on naming -- so
  this problem is more rare than random chance might suggest. In any case,
  this proposal clearly reduces risk of error even if it does not eliminate it.

Current Practice:

  Implementations are currently permitted to ignore spurious TRACE
  options/syntax because of TRACE's weak contract, and many do.

Cost to Implementors:

  Trivial error checking would have to be added to TRACE and UNTRACE.

Cost to Users:

  This change is upward compatible.

Cost of Non-Adoption:

  Some interactive problems would continue to be likely to occur periodically.

Benefits:

  A possible source of interactive debugging error is removed.

Aesthetics:

  Users will feel a little safer.

Discussion:

  Pitman wrote and supports TRACE-ERROR:REQUIRE-SIGNAL.

  This issue came up while debugging Macsyma on a system which quietly 
  ignored what Pitman felt were TRACE options that should either be used
  or complained about.

∂20-Jun-88  1411	CL-Cleanup-mailer 	Issue: DECODE-UNIVERSAL-DAYLIGHT (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Jun 88  14:11:26 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 422182; Mon 20-Jun-88 17:10:16 EDT
Date: Mon, 20 Jun 88 17:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECODE-UNIVERSAL-DAYLIGHT (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880620170950.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        DECODE-UNIVERSAL-TIME-DAYLIGHT
References:   DECODE-UNIVERSAL-TIME (p445)
Category:     CLARIFICATION
Edit history: 20-Jun-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  The description of DECODE-UNIVERSAL-TIME does not say what happens with
  TIME-ZONE. Since the description of ENCODE-UNIVERSAL-TIME mentions that
  its behavior differs depending on whether a time zone is explicitly passed,
  some implementors may have assumed that DECODE-UNIVERSAL-TIME should do
  likewise.

  Even if all implementations did the same thing, it should still be clarified
  whether an implementation were permitted to return dsp=NIL tz=n rather than
  dsp=T tz=n+1 for time zones in which daylight savings time was believed to
  be (or known to be) in effect. Currently, you cannot tell whether "NIL" for
  daylight-savings-time-p means "daylight savings time is in effect" or
  just "daylight savings time is not known to not be in effect".

  These tools appear to be more portable than they are.

Proposal (DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE):

  Specify that, like ENCODE-UNIVERSAL-TIME, DECODE-UNIVERSAL-TIME ignores
  daylight savings information if a timezone is explicitly specified.

  Rationale:

    This makes things consistent with ENCODE-UNIVERSAL-TIME.

Proposal (DECODE-UNIVERSAL-TIME-DAYLIGHT:UNLIKE-ENCODE):

  Specify that, unlike ENCODE-UNIVERSAL-TIME, DECODE-UNIVERSAL-TIME treats
  daylight savings information the same regardless of whether a time zone
  argument is explicitly or not.

  Rationale:

    Although inconsistent with ENCODE-UNIVERSAL-TIME, this seems
    to be what was intended.

    [Maybe someone can suggest a better motivation? -kmp]

Test Case:

  ;; ### Kludge: This test case relies on time zone not changing in real
  ;; ###   time, in blatant defiance of warning in note at bottom
  ;; ###   of p445.
  (LET* ((HERE (NTH 8 (MULTIPLE-VALUE-LIST (GET-DECODED-TIME)))) ;Time zone
	 (RECENTLY (GET-UNIVERSAL-TIME))
	 (A (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY))))
	 (B (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY HERE)))))
    (LIST A B (EQUAL A B)))

Current Practice:

  Symbolics Genera and Symbolics Cloe return ((T 5) (NIL 5) NIL) in EDT.

Cost to Implementors:

  The cost of changing this should be trivial.

Cost to Users:

  This feature is already not well-defined since no portable program can rely
  on the current behavior, so the cost is effectively zero.

Cost of Non-Adoption:

  The time primitives are considerably less useful if this point is not
  clearly spelled out.

Benefits:

  The cost of non-adoption would be avoided.

Aesthetics:

  Anything that improves the intelligibility of language primitives improves
  language aesthetics.

Discussion:

  Pitman wrote this proposal after running into this problem while trying
  to port Macsyma between different Common Lisp implementations. He doesn't
  have a strong preference on which proposal should be adopted, but thinks
  this issue should be nailed down.

∂20-Jun-88  1418	CL-Cleanup-mailer 	Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Jun 88  14:18:37 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 422192; Mon 20-Jun-88 17:17:22 EDT
Date: Mon, 20 Jun 88 17:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
References: <880620170950.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <880620171657.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

That last subject line should have been DECODE-UNIVERSAL-TIME-DAYLIGHT
to match what's in the proposal. Sorry.

∂20-Jun-88  1546	CL-Cleanup-mailer 	STEP-ENVIRONMENT, version 3    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Jun 88  15:46:13 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA29826; Mon, 20 Jun 88 16:44:53 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8806202244.AA29826@cs.utah.edu>
Date: Mon, 20 Jun 88 16:44:51 MDT
Subject: STEP-ENVIRONMENT, version 3
To: cl-cleanup@sail.stanford.edu


As promised, here is a revised version of the STEP-ENVIRONMENT proposal.
I have removed the part of the proposal that would make STEP a special
form instead of a macro.

-Sandra



Issue:         STEP-ENVIRONMENT
 
References:    STEP (CLtL p.441)
               TIME (CLtL p.441)
 
Category:      CLARIFICATION/CHANGE
 
Edit history:  Version 1, 12-Mar-88, Moon
               Version 2, 10-Jun-88, Masinter (add discussion)
	       Version 3, 20-Jun-88, Loosemore (not a special form)

 
Problem description:
 
CLtL does not specify in what lexical environment the form given to STEP
is evaluated.  Some people think it's supposed to be evaluated in the
null environment, others think it is supposed to be evaluated in the
current environment, the one in which the STEP form was evaluated.
 
The same considerations apply to TIME.
 
 
Proposal (STEP-ENVIRONMENT:CURRENT):
 
1. Clarify that STEP and TIME evaluate the form in the current environment.

2. Clarify that calls to both STEP and TIME may be compiled, but that
in the case of STEP, it is acceptable for an implementation to
interactively step through only those parts of the evaluation that are
interpreted. 

 
Test Cases/Examples:
 
;Assuming X is not a special variable
(setq x 1)
(let ((x 2))
  (step (print x)))
 
This should print and return 2, not 1, when interpreted.
 
Rationale:
 
1. It is more useful for the lexical environment to pass transparently
through STEP and TIME than to reset to the null environment.

2. Although STEP is primarily a debugging tool, there is no reason to
prevent it from being compiled correctly.

 
Current practice:

Vax Lisp behaves as proposed.  Symbolics Common Lisp treats STEP as a special
form and does not allow it to be compiled. 

Cost to Implementors:
 
Minimal.

Cost to Users:
 
None.

Cost of non-adoption:
 
These debugging tools will continue to have vague specifications.
 
Benefits:
 
Slightly more preicse specification of Common Lisp.
 
Esthetics:
 
Slightly improved.
 
Discussion:
 
There was some discussion of separating this out into two separate
proposals, but it didn't seem useful.
 
Eric Benson contributed the definition of TIME in Lucid Common Lisp:
 
(defmacro time (form)
  `(time-internal #'(lambda () ,form)))
 
 
The function TIME-INTERNAL looks something like:
 
(defun time-internal (thunk)
  (let ((before-time (get-time-state)))
    (unwind-protect
        (funcall thunk)
      (print-time-information before-time (get-time-state)))))
 
The definition of STEP is similar.  This is just to show that it is
easy to get the right lexical environment even though TIME and STEP
are macros.

VaxLisp expands STEP into something like:

(defmacro step (form)
    `(let ((*eval-hook* #'step-command-loop))
        ,form))
 

-------

∂20-Jun-88  1842	CL-Cleanup-mailer 	Issue: STEP-ENVIRONMENT, version 3  
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 20 Jun 88  18:42:35 PDT
Date: 20 Jun 88 21:20:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: Issue: STEP-ENVIRONMENT, version 3
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen   
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

This looks pretty good--we really want to minimize the number of special
forms if at all possible.

			---Walter
------

∂21-Jun-88  0003	CL-Cleanup-mailer   
Received: from research.att.com (ATT.ARPA) by SAIL.Stanford.EDU with TCP; 21 Jun 88  00:03:28 PDT
From: frodo@research.att.com
Date: Tue, 21 Jun 88 03:00:14 EDT
To: cl-cleanup@sail.stanford.edu

I have received your message of Mon Jun 20 04:00:28 1988 correctly.
This message is being sent by my automatic mail answering program.
(Really, no sh....)

I'm sailing to Cape Cod on board Nimble.
I will return Friday June 24, 1988.

If you are sending me mail because you need help with a system related
problem and are you are in need of help immediately, perhaps you should
contact someone else.

Ted J. Kowalski

(If you send me another message, this message will not be repeated)

∂21-Jun-88  1739	CL-Cleanup-mailer 	Issue: TRACE-ERROR (Version 1) 
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Jun 88  17:39:38 PDT
Received: by labrea.stanford.edu; Tue, 21 Jun 88 17:39:43 PDT
Received: from blacksox.lucid.com by edsel id AA21953g; Tue, 21 Jun 88 14:13:19 PDT
Received: by blacksox id AA00406g; Tue, 21 Jun 88 14:12:17 pdt
Date: Tue, 21 Jun 88 14:12:17 pdt
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8806212112.AA00406@blacksox.lucid.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Mon, 20 Jun 88 16:14 EDT <880620161405.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: TRACE-ERROR (Version 1)

It seems to me that this is beyond the scope of the cleanup committee
or even the standardization effort.  What you are describing is a bug
in a particular implementation of TRACE.  It is a bug because it
reduces the usability of TRACE, not because that version of TRACE does
not conform to some present or future Common Lisp standard.  Send a
bug report to your Lisp supplier.

P.S. As it happens, I think that supplier is Lucid!  I believe that
our TRACE implementation accepts the :WHEREIN keyword but does not
implement its functionality.  As it turns out, I think we can now
implement :WHEREIN easily, but everyone forgot about it!  Send in a
bug report and it will go on the queue of things to do.  (I could
submit a bug report myself, but customers get higher priority.)

∂21-Jun-88  1740	CL-Cleanup-mailer 	STEP-ENVIRONMENT, version 3    
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Jun 88  17:40:22 PDT
Received: by labrea.stanford.edu; Tue, 21 Jun 88 17:40:26 PDT
Received: from blacksox.lucid.com by edsel id AA21993g; Tue, 21 Jun 88 14:17:18 PDT
Received: by blacksox id AA00409g; Tue, 21 Jun 88 14:16:19 pdt
Date: Tue, 21 Jun 88 14:16:19 pdt
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8806212116.AA00409@blacksox.lucid.com>
To: sandra@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 20 Jun 88 16:44:51 MDT <8806202244.AA29826@cs.utah.edu>
Subject: STEP-ENVIRONMENT, version 3

Add to Current Practice: Lucid Common Lisp behaves as proposed.

∂22-Jun-88  1004	CL-Cleanup-mailer 	Issue: TRACE-ERROR (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Jun 88  10:04:05 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423231; Wed 22-Jun-88 13:03:12 EDT
Date: Wed, 22 Jun 88 13:02 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TRACE-ERROR (Version 1)
To: edsel!eb@labrea.stanford.edu
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8806212112.AA00406@blacksox.lucid.com>
Message-ID: <880622130258.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Tue, 21 Jun 88 14:12:17 pdt
    From: Eric Benson <edsel!eb@labrea.stanford.edu>

    It seems to me that this is beyond the scope of the cleanup committee
    or even the standardization effort.  What you are describing is a bug
    in a particular implementation of TRACE.

Not necessarily if the documentation doesn't say it's a bug. Some vendors
prefer not to change anything that the standard doesn't require them to change.
Also, the time between releases may be very long. And, as far as I can see,
there's no good reason I should ever find myself inconvenienced by this problem.

    It is a bug because it reduces the usability of TRACE, 

Few vendors use this criterion in general for determining what's a bug
and what's not.

    not because that version of TRACE does not conform to some present or
    future Common Lisp standard. 

Certainly not if we don't agree to discuss it in this forum, but that's
a bit self-defeatist.

    Send a bug report to your Lisp supplier.

But it's not guaranteed to help since I have no leverage.
I (wearing my third-party application developer hat) can afford to
discriminate against a CL because it doesn't do floating point or bignums
right, or because it doesn't implement lexical closures, but if it reaches
and interesting target market and it doesn't do TRACE right, I'm probably
going to be stuck using it. Some vendors want to implement just the bare
minimum and appeal to the full force of the "is an error" rule wherever
possible. I think that where reasonable we should raise the least common
denominator, and I think a reasonable place to start is in places that
users (eg, me, in this case) report that there's been a problem.

In this particular case, any reasonable vendor is probably going to give
in to my demands, but this bug is an easy mistake to make and there's no
reason not to put the feature I'm asking for in the standard if only to
remind all vendors to get the feature into release 1 of their product.

    P.S. As it happens, I think that supplier is Lucid! ...

I'm pretty sure it was not.

    I believe that our TRACE implementation accepts the :WHEREIN keyword
    but does not implement its functionality.

[Actually, I just pulled :WHEREIN out of a hat. I don't remember the real
keyword, but I know I never use :WHEREIN. Maybe it was :BREAK...] Anyway,
I'm inclined to believe this would be acceptable as long as TRACE does
typeout saying that it was not using the keyword. Anything that tells the
user what's going on.

∂22-Jun-88  1254	CL-Cleanup-mailer 	Issue: STREAM-CLASS-ACCESS (version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Jun 88  12:54:25 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423341; Wed 22-Jun-88 15:54:01 EDT
Date: Wed, 22 Jun 88 15:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-CLASS-ACCESS (version 1)
To: vanroggen%aitg.decnet@Hudson.DEC.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 17 Jun 88 20:34 EDT from "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Message-ID: <880622155347.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I have this issue filed as STREAM-CLASS-ACCESS. You called it just
STREAM-ACCESS. It would be nice if we could stick to just one name so
that I and others who try to keep this stuff usefully archived don't get
the archive split uselessly into two pieces.

The editorial committee should see to it that it's clear that these
types have to do with `structure' rather than `intent' of the resulting
streams. For example, if you broadcast to two string streams, you have a
stream of type BROADCAST-STREAM, not (necessarily) a string of type
STRING-STREAM, etc.

In any case, the write-up looks generally quite good as it stands and
the proposal has my support.

∂22-Jun-88  1508	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Jun 88  15:08:15 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423409; Wed 22-Jun-88 18:08:02 EDT
Date: Wed, 22 Jun 88 18:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-FORM (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880622180746.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        LAMBDA-FORM
References:   LAMBDA (p59)
Category:     ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  In Scheme, one writes not #'(LAMBDA ...) but just (LAMBDA ...).

  Many Common Lisp programmers have asked for this feature.
  It can be written by the user, but since it's a commonly asked
  for feature, it would make sense for it to be in the standard.

  Also, even though the definition is trivial,

    (DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))

  it is difficult to offer this as an extension because then "portable
  code" tries to define it, it will get a redefinition warning because
  it will be clobbering the system's predefined definition.
  [An implementation could shadow LAMBDA, but that, too, has associated
  problems.]

Proposal (LAMBDA-FORM:NEW-MACRO):

  Add a LAMBDA macro, which has equivalent effect to:

    (DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))

  Rationale:

   This is an upward-compatible extension which ``codifies current
   practice'' in that it makes a commonly defined macro available
   as a standard part of the language.

Proposal (LAMBDA-FORM:NEW-SPECIAL-FORM): 

  Add a new special form LAMBDA, which has equivalent effect to:

    (DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))

  except that the macro expansion might not be available in all
  implementations.

  Rationale:

   This is a slightly incompatible extension which ``codifies current
   practice'' in that it makes a commonly defined feature available
   as a standard part of the language. The idea of making it a special
   form would be that some people would prefer to treat (LAMBDA ...)
   as more primitive than #'(LAMBDA ...).

Test Case:

  #1: (DEFUN ADDER (N) (LAMBDA (X) (+ X N)))
      (FUNCALL (ADDER 5) 3) => 8
  
  #2: (MAPCAR (LAMBDA (X) (+ X 3)) '(1 2 3)) => (4 5 6)

  #3: (MACROEXPAND '(LAMBDA (X) (+ X Y)))
      ; The following result is required under NEW-MACRO
      ;  and is possible under NEW-SPECIAL-FORM
      => (FUNCTION (LAMBDA (X) (+ X Y)))
      ; The following result is prohibited under NEW-MACRO
      ;  and is permitted but not required under NEW-SPECIAL-FORM.
      => (LAMBDA (X) (+ X Y))

Current Practice:

  Symbolics Genera implements NEW-MACRO.

  Symbolics Cloe does not offer a LAMBDA macro because users who defined
  their own in portable code complained that they were getting redefinition
  warnings that CLtL had led them to believe shouldn't happen. (Actually,
  CLtL technically does allow it, but arguably only by technicality.)

Cost to Implementors:

  NEW-MACRO is trivial to add.

  NEW-SPECIAL form might require more work in some implementations, but
   probably not a lot more.

Cost to Users:

  None. This change is basically upward compatible.

Cost of Non-Adoption:

  There are no really major consequences of non-adoption.

Benefits:

  Improved aesthetics.

  It's been suggested that some people write '(LAMBDA ...) rather than
  #'(LAMBDA ...) because it's less ugly, and then run into confusion
  later. If they could just write (LAMBDA ...), some that use overly
  superficial reasons for the choice of one notation over another might
  accidentally select the primitive they should probably really be using.

Aesthetics:

  Some people believe strongly that (LAMBDA ...) looks a lot better
  than #'(LAMBDA ...). Certainly it takes up fewer characters, and
  (LAMBDA ...) is a notable offender in code needing to be split onto
  multiple lines, so every little bit helps.

Discussion:

  Numerous people have suggested this from time to time in the past,
  but it's often been amidst a bunch of other more controversial issues.
  Pitman wrote up this proposal and supports LAMBDA-FORM:NEW-MACRO.

∂22-Jun-88  2258	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COERCE-TIME (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Jun 88  22:58:22 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 88 22:58:11 PDT
Date: 22 Jun 88 22:46 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-COERCE-TIME (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Mon, 20 Jun 88 16:09 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880622-225811-3055@Xerox>

This is the right idea, but "at late as possible" is probably too vague to
satisfy folks.

I think the idea is that supplying x as a functional argument to  remove-if,
mapc, etc.  should work identically to supplying #'(lambda (&rest arguments)
(apply (if (functionp x) x (symbol-function x)) arguments))


∂22-Jun-88  2306	CL-Cleanup-mailer 	Re: Issue: ALIST-NIL (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Jun 88  23:06:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 88 23:06:16 PDT
Date: 22 Jun 88 22:56 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ALIST-NIL (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Mon, 20 Jun 88 16:11 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880622-230616-3064@Xerox>

of all of the odd little confusing corners of CL, this seems like one of the
least important to clean up.  I would imagine the intent was more along the
lines of your #2; and that putting NIL there seems simpler than putting some
otherwise useless CONS. Besides, putting the NIL there also makes it clear where
the "dummy" entries are, allowing for a quick (remove nil alist).


So, I'm agin it.

∂22-Jun-88  2317	CL-Cleanup-mailer 	Re: Issue: TRACE-ERROR (Version 1)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Jun 88  23:17:32 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 88 23:16:36 PDT
Date: 22 Jun 88 23:06 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TRACE-ERROR (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Mon, 20 Jun 88 16:14 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880622-231636-3071@Xerox>

I would like to separate out, if possible, the requirement for conformance --
what it is you have to have to say that you have ANSI Common Lisp -- and the
strong recommendations the standard might make for having an acceptable
environment. This issue is in many ways like IF-BODY; it attempts to put some
constraints on things that implementations do that aren't part of the standard
anyway.

I don't know for sure that there is precedent, but I vaguely remember some
similar wording in other standards documents. I'd like to see the only
"standard" for ED, TRACE, BREAK and the other "environment" features be that
they exist in the Lisp package and that the implementations document what they
do; secondly, we can strongly *recommend* (maybe in the notes) that TRACE do
error checking and that DRIBBLE change the current *terminal-io* rather than
work with an embedded top-level loop.

We certainly gutted DRIBBLE, I don't know why we should turn around and tighten
up TRACE.

∂22-Jun-88  2338	CL-Cleanup-mailer 	Re: Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Jun 88  23:38:39 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 88 23:35:08 PDT
Date: 22 Jun 88 23:24 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Mon, 20 Jun 88 17:16 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880622-233508-3081@Xerox>

I think it takes more deduction than most of our readers are willing to expend
to figure out how to interpret various return values for your test case.


∂23-Jun-88  0153	CL-Cleanup-mailer 	&key in defstruct :constructor arglists  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 23 Jun 88  01:45:32 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
	id AA02079; Thu, 23 Jun 88 01:44:08 PDT
Received: from denali.sun.com by snail.sun.com (4.0/SMI-3.2)
	id AA29442; Wed, 22 Jun 88 17:27:29 PDT
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
	id AA26402; Wed, 22 Jun 88 17:34:18 PDT
Message-Id: <8806230034.AA26402@denali.sun.com>
To: cl-cleanup@sail.stanford.edu
Cc: cl-cleanup-request@sail.stanford.edu
Cc: peck@Sun.COM
Subject: &key in defstruct :constructor arglists
Date: Wed, 22 Jun 88 17:34:16 -0700
From: peck@Sun.COM

Is there a really good reason why the arglists for :constructor functions
may *not* include a mix of keyword and non-keyword specifiers??
 CLtL, page 316:
    "In addition, the keywords &optional, &rest, and &aux are recognised
     in the argument list. They work in the way you might expect ..."

I would like to do this:
(defstruct (foo (:constructor create-foo (a &optional b (c 'sea)
					    &key (d 2)
					    &aux e (f 'eff))))
  (a 1) (b 2) (c 3) (d 4) (e 5) (f 6))


But CLtL encourages me do something ugly like this:
(defstruct (foo (:constructor create-foo% (a b c d &aux e (f 'eff))))
  (a 1) (b 2) (c 3) (d 4) (e 5) (f 6))

(defun create-foo (a &optional b (c 'sea) &key (d 2))
  (create-foo% a b c d))

Even so, the handling of foo-b is incorrect if create-foo is called with
only 1 argument.  Must a user hand code all the supplied-p forms to do this?
  CLtL: "The actions taken in the B and E cases were carefully chosen to
         allow the user to specify all possible behaviors."
The intent is clearly to make this *easier* for programmers...

Is the code to handle &key really any different than for &optional?

  Biggest impact i can see here is that we might lose the cuteness of
strictly "By Order of Arguments" --> "BOA-constructor".



PS to: cl-cleanup-request@sail.stanford.edu
  please add me to this list: peck@sun.com

∂23-Jun-88  0725	CL-Cleanup-mailer 	Re: Issue: TRACE-ERROR (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jun 88  07:25:18 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423614; Thu 23-Jun-88 10:24:49 EDT
Date: Thu, 23 Jun 88 10:24 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TRACE-ERROR (Version 1)
To: masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880622-231636-3071@Xerox>
Message-ID: <880623102431.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 22 Jun 88 23:06 PDT
    From: masinter.pa@Xerox.COM

    I would like to separate out, if possible, the requirement for
    conformance -- what it is you have to have to say that you have
    ANSI Common Lisp -- and the strong recommendations the standard
    might make for having an acceptable environment.

I'm completely baffled by why anyone thinks this has anything whatsoever
to do with conformance. Conformance has to do with adherence to what is
written. I'm suggesting we write something different. Whether people
conform or not will be judged against what we write and is, indeed,
something beyond our jurisdiction.

    This issue is in many ways like IF-BODY; it attempts to put some
    constraints on things that implementations do that aren't part of
    the standard anyway.

There are things that are intended to be left open and things that
are not. We have to separate them out. I am asserting that the right
to ignore a user's TRACE specification without a hint that that's what
you're doing is something we don't want to leave open, even if we leave
open what kinds of TRACE extensions we allow. This is no different than
allowing people to extend COERCE or OPEN or SUBTYPEP, but requiring
specifying that COERCE must signal an error if it can't do the coercion
or that OPEN must still return a stream even if the keywords are 
non-standard or how TYPEP passes back information about the fact that 
it couldn't do its job correctly.

    I don't know for sure that there is precedent, but I vaguely
    remember some similar wording in other standards documents. I'd like
    to see the only "standard" for ED, TRACE, BREAK and the other
    "environment" features be that they exist in the Lisp package and
    that the implementations document what they do; 

I'd be almost ammenable to this except that I'd want to specify that if
they do nothing they must either return some CL-specified value or
else do typeout informing the user that they did nothing.

For example, on the 3600, ED communicates with and/or spins off a new
process which will run the editor. It therefore returns before it has
`done anything'. On the 3600, you have a bar at the bottom of the screen
that tells you that the machine is still busy, so this isn't too baffling.
If I were on a machine that did not have a status line at the bottom of
the screen and called ED only to see it return, I might not know if it
was still doing something in background and might not know how to decide
when to stop waiting.

    secondly, we can strongly *recommend* (maybe in the notes) that TRACE do
    error checking

This would be ok, but since no one has advanced a reason why TRACE should
not always do error checking, this is pretty wimpy.

    and that DRIBBLE change the current *terminal-io* rather than
    work with an embedded top-level loop.

People have advanced valid reasons for this not to happen. It's interesting
that you pick these examples because you seem to intend me to be able to
send a bug report to an implementation which doesn't follow the recommendation
saying "gosh, i wish it did" and yet I hope you're not trying to incite
Lispm users to riot by inserting a recommendation about DRIBBLE which is
non-binding but which has been shown not to be generally agreed upon by the
technical community.

I personally think there is no place for notes in the standard. There
bindingness on conformity (or lack thereof) is just too confusing.

    We certainly gutted DRIBBLE, I don't know why we should turn around and tighten
    up TRACE.

Not so. We didn't gut DRIBBLE, we acknowledged the status quo (a status quo
which was supported by the existing vague wording). Making any change would
have forced some implementation to make an incompatible change. On the other
hand, the proposed change to TRACE is not interestingly incompatible. The two
issues are not at all in the same class as I see it.

∂23-Jun-88  0733	CL-Cleanup-mailer 	Re: Issue: ALIST-NIL (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jun 88  07:33:47 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423620; Thu 23-Jun-88 10:33:19 EDT
Date: Thu, 23 Jun 88 10:33 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: ALIST-NIL (Version 1)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880622-230616-3064@Xerox>
Message-ID: <880623103303.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 22 Jun 88 22:56 PDT
    From: masinter.pa@Xerox.COM

    of all of the odd little confusing corners of CL, this seems like one of the
    least important to clean up. 

i don't know what your criterion for importance is. there was a lot of mail
a while back that exposed widespread confusion about whether even arbitrary
symbols could occur in an alist. this was traced to confusion over the need
to mention atoms in one paragraph forced by the mention elsewhere of nil as
a possible alist element.

i continue to believe that the proper metric of importance is the set of things
which people think important enough to bother mentioning. even if there seem
to be a thousand things of similar kind in the language, the fact that the
complainants do not mention the other 999 is an appropriate way of rank ordering
the one against the other 999.

in this case, confusion over what can go in alists was already on my list of
problems from macsyma days. it came up again on the common-lisp mailing list.
and it came up again when i was looking at the standard this time around.
i consider this reason enough for the issue to go to committee vote unless
someone can advance a sound technical argument as to why nils should be allowed.

    I would imagine the intent was more along the lines of your #2; and that
    putting NIL there seems simpler than putting some otherwise useless CONS.

on the other hand, i have never seen this done in practice so it may have been
useless optimization.

    Besides, putting the NIL there also makes it clear where
    the "dummy" entries are, allowing for a quick (remove nil alist).

well, if your only purpose was to do a remove later, you could often just
put :DELETED there and be sure to clean up the alist when you were done,
or else just do the real splicing as you went.

    So, I'm agin it.

i'll add your no vote on the next revision.

∂23-Jun-88  0738	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COERCE-TIME (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jun 88  07:38:32 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423624; Thu 23-Jun-88 10:37:51 EDT
Date: Thu, 23 Jun 88 10:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-COERCE-TIME (Version 1)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880622-225811-3055@Xerox>
Message-ID: <880623103735.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 22 Jun 88 22:46 PDT
    From: masinter.pa@Xerox.COM

    This is the right idea, but "at late as possible" is probably too vague to
    satisfy folks.

Sigh. You're probably right.

    I think the idea is that supplying x as a functional argument to  remove-if,
    mapc, etc.  should work identically to supplying #'(lambda (&rest arguments)
    (apply (if (functionp x) x (symbol-function x)) arguments))

Since I plan to submit a cleanup item to re-allow LAMBDA expressions as coerceable
to functions, i would appreciate it if we could avoid any wording that got us
caught up in irrelevant presuppositions about what was a function or what wasn't.
For example,
 #'(lambda (&rest arguments) (apply (coerce x 'function) arguments))
would both make your local intent clearer and make this proposal more modular.

I'll take care of ammending it in a few days after I make sure there are no other
comments.

∂23-Jun-88  0842	CL-Cleanup-mailer 	Re: Issue: ALIST-NIL (Version 1)    
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 23 Jun 88  08:42:46 PDT
Date: 23 Jun 88 11:26:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: Re: Issue: ALIST-NIL (Version 1)
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen   
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

You didn't mention that the [R]ASSOC[-IF[-NOT]] functions might be
faster if they didn't have to check for NIL.

In general, I'm in favor of this, but I'm somewhat concerned about
compatibility.  However, I think "Cost to User #1" isn't really much
of an argument.  #2 is an issue, though, and your suggestion isn't
good enough a work-around, since it might change the behavior for the
xxx-IF and xxx-IF-NOT functions, depending on the predicate used.

			---Walter
------

∂23-Jun-88  1005	CL-Cleanup-mailer 	Issue: FUNCTION-DEFINITION (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jun 88  10:05:16 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423715; Thu 23-Jun-88 13:05:03 EDT
Date: Thu, 23 Jun 88 13:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-DEFINITION (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880623130442.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        FUNCTION-DEFINITION
References:   none
Category:     ADDITION
Edit history: 23-Jun-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  There are portable ways to turn symbols and lists into functions,
  but there are no portable ways to get back the original symbols and
  lists given the functions.

Proposal (FUNCTION-DEFINITION:OPTIONAL):

  Introduce a new function called FUNCTION-DEFINITION which took as
  its argument a function and returned three values:
   #1: its ``definition'' as a symbol or list, or NIL if the
       information was no longer available.
   #2: NIL if the definition was enclosed in the null lexical
       environment and something non-NIL if the definition was (or
       might have been) enclosed in some non-null lexical environment.
       [It is always safe for an implementation to return T for this
       value.]
   #3: the `name' of this function. the name is intended for debugging
       only and may be any lisp object -- not necessarily one that would
       be valid for use as a name in DEFUN or FUNCTION, for example.
       By convention, NIL is used to mean that the function had no name.
  Implementations would be free to not record this information, or to provide
  primitives for flushing some or all of the information at any time.

  Examples:
  
    The following examples illustrate some possible return values, but
    are not not intended to be exhaustive:
  
    #1:    (FUNCTION-DEFINITION #'(LAMBDA (X) X))
	or (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
	might return NIL, NIL, NIL
		  or (LAMBDA (X) X), T, NIL
		  or (LAMBDA (X) X), NIL, NIL
  
    #2: (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
	might return NIL, NIL, NIL
		  or (LAMBDA (X) NIL), T, NIL
	   but -not- (LAMBDA (X) X), NIL, NIL
  
    #3: (DEFUN FOO (X) X)
	(SETF (SYMBOL-FUNCTION #'BAR) #'FOO)
	(DEFUN FOO (Y) Y)
	(FUNCTION-DEFINITION #'BAR)
	might return NIL, NIL, NIL
		  or (LAMBDA (X) X), T, NIL
		  or (LAMBDA (X) X), T, FOO
  
    #4: (DEFUN FOO ()
	  (FLET ((BAR (X) X))
	    #'BAR))
	(FUNCTION-DEFINITION (FOO))
	might return NIL, NIL, NIL
		  or (LAMBDA (X) X), T, NIL
		  or (LAMBDA (X) X), T, (:INTERNAL FOO 0 BAR)
		  or (LAMBDA (X) X), T, "BAR in FOO"
  
  Rationale:
  
    This functionality would be useful to the pretty printer, debugger,
    inspector, and other tools.
  
  Cost to Implementors:
  
    Because NIL can be returned as a first value, the amount of work forced
    by this proposal is trivial. The following implementation is technically
    legitimate, although many implementations would want to provide something
    more useful:
  
     (DEFUN FUNCTION-DEFINITION (FUNCTION)
       (CHECK-TYPE FUNCTION FUNCTION)
       (VALUES NIL NIL NIL))

Proposal (FUNCTION-DEFINITION:REQUIRED):

  Introduce a new function called FUNCTION-DEFINITION which took as
  its argument a function and returned three values:
   #1: its ``definition'' as a symbol or list, or NIL if the
       information was no longer available.
   #2: NIL if the definition was enclosed in the null lexical
       environment and something non-NIL if the definition was (or
       might have been) enclosed in some non-null lexical environment.
       [It is always safe for an implementation to return T for this
       value.]
   #3: the `name' of this function. the name is intended for debugging
       only and may be any lisp object -- not necessarily one that would
       be valid for use as a name in DEFUN or FUNCTION, for example.
       By convention, NIL is used to mean that the function had no name.
  Implementations would be free to not record this information in file
  compilations. In-core calls to EVAL and COMPILE would be required to
  retain the information, however.

  Examples:
  
    The following examples illustrate some possible return values, but
    are not not intended to be exhaustive:
  
    #1:    (FUNCTION-DEFINITION #'(LAMBDA (X) X))
	or (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
	might return NIL, NIL, NIL
		  or (LAMBDA (X) X), T, NIL
		  or (LAMBDA (X) X), NIL, NIL
	in compiled code.
  
           (FUNCTION-DEFINITION (EVAL '(LAMBDA (X) X)))
	would not be permitted to return NIL, NIL, NIL since the compilation
	occurred in the same environment.

    #2: (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
	might return NIL, NIL, NIL
		  or (LAMBDA (X) NIL), T, NIL
	   but -not- (LAMBDA (X) X), NIL, NIL
        in compiled code.
  
	(FUNCTION-DEFINITION (FUNCALL (EVAL '(LAMBDA () #'(LAMBDA (X) X)))))
	would not be permitted to return NIL, NIL, NIL since the compilation
	occurred in the same environment.

    #3: (DEFUN FOO (X) X)
	(SETF (SYMBOL-FUNCTION #'BAR) #'FOO)
	(DEFUN FOO (Y) Y)
	(FUNCTION-DEFINITION #'BAR)
	might return NIL, NIL, NIL
		  or (LAMBDA (X) X), T, NIL
		  or (LAMBDA (X) X), T, FOO
        in compiled code.
  
	If the DEFUN had been done interactively, the call to
	FUNCTION-DEFINITION would not be permitted to return NIL, NIL, NIL
	since the compilation occurred in the same environment.

    #4: (DEFUN FOO ()
	  (FLET ((BAR (X) X))
	    #'BAR))
	(FUNCTION-DEFINITION (FOO))
	might return NIL, NIL, NIL
		  or (LAMBDA (X) X), T, NIL
		  or (LAMBDA (X) X), T, (:INTERNAL FOO 0 BAR)
		  or (LAMBDA (X) X), T, "BAR in FOO"
        in compiled code.
  
	If the DEFUN had been done interactively, the call to
	FUNCTION-DEFINITION would not be permitted to return NIL, NIL, NIL
	since the compilation occurred in the same environment.
  
  Rationale:
  
    This functionality would be useful to the pretty printer, debugger,
    inspector, and other tools.
  
    Additionally, this would be useful to programs which need to pass
    around both a function and a representation of a function because a
    single object could be passed which was efficient to call without 
    compromising the ability to reliably retrieve its representation.

  Cost to Implementors:
  
    Because NIL can be returned as a first value, the amount of work forced
    by this proposal is small, but not trivial. A simple implementation
    might allocate a slot in each function that could hold the definition,
    or might allocate a hash table to hold the information.

Current Practice:

  Many implementations record this information, but not all that do
  publish an interface to extracting the information.

  The language T has this operation and calls it DISCLOSE. It is the
  conceptual inverse of the ENCLOSE which occurs in some Scheme dialects,
  and is implemented as what CLOS would call a "generic function".

Cost to Users:

  None. The change is upward compatible.

Cost of Non-Adoption:

  Certain kinds of portable debugging tools would be harder to write.

Benefits:

  The cost of non-adoption would be avoided.

Aesthetics:

  The phrase ``program is data; data is program'' comes up a lot in discussions
  about Lisp. This makes the case for ``program is data'' more interesting.

Discussion:

  Pitman would prefer FUNCTION-DEFINITION:REQUIRED if people would agree to it
  because it is considerably more useful in practice, but would like to see at
  least FUNCTION-DEFINITION:OPTIONAL.

∂23-Jun-88  1254	CL-Cleanup-mailer 	Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 2)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jun 88  12:54:15 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423827; Thu 23-Jun-88 15:54:01 EDT
Date: Thu, 23 Jun 88 15:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880623155341.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Ok, I've revived this proposal per discussion in committee with
corrections to just treat echo streams (as created by MAKE-ECHO-STREAM)
and not get caught up in the problems of terminal interaction.

Please read carefully. A lot of little things changed in the process
and I don't guarantee this is error-free.

Naturally, if we could agree to just go forward with one of the two
proposals, the thing would be textually a bit simpler...

-----
Issue:        PEEK-CHAR-READ-CHAR-ECHO
References:   READ-CHAR (p379), UNREAD-CHAR (p379), PEEK-CHAR (p379),
	      MAKE-ECHO-STREAM (p330), Streams (p327-328),
	      READ-PRESERVING-WHITESPACE (p376), 
	      READ-DELIMITED-LIST (p377)
Category:     CLARIFICATION/CHANGE
Edit history: 06-Mar-88, Version 1 by Pitman,
	      23-Jun-88, Version 2 by Pitman (remove interactive stuff)
Status:	      For Internal Discussion
	      
Problem Description:

  The interaction between PEEK-CHAR, READ-CHAR and streams made by
  MAKE-ECHO-STREAM is not made adequately clear about how many times
  a particular character may be echoed and at what time such echo
  is permissible.

  For example, given:
   (WITH-INPUT-FROM-STRING (STRING-STREAM "A")
     (LET ((*STANDARD-INPUT* (MAKE-ECHO-STREAM STRING-STREAM
					       *STANDARD-OUTPUT*)))
       (LET ((CHAR NIL))
	 (PEEK-CHAR)             (PRIN1 '---)
	 (PEEK-CHAR)             (PRIN1 '---)
	 (SETQ CHAR (READ-CHAR)) (PRIN1 '---)
	 (UNREAD-CHAR CHAR)      (PRIN1 '---)
	 (READ-CHAR))))
  what is seen on the terminal? There are at least these possibilities:

  [1] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. The first time
      a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not echo,
      re-fetching the char by READ-CHAR doesn't echo.
      A------------

  [2] Characters are echoed whenever seen by PEEK-CHAR or READ-CHAR.
      Characters are not unechoed by UNREAD-CHAR.
      A---A---A---A---

  [3] Characters are not echoed by PEEK-CHAR but are echoed by READ-CHAR.
      No `unecho' action is done by UNREAD-CHAR.
      ------A------A

  [4] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echos
      but UNREAD-CHAR does not `unecho'.
      A---A---A------A

  [5] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echos
      but UNREAD-CHAR unechos (a magic Erase character must be 
      presupposed for display terminals, a file stream that can randomly
      access during output and/or back up must be presupposed for files,
      paper terminals just lose):
      A<Erase>---A<Erase>---A---<Erase>---A

  [6] PEEK-CHAR is implemented by peeking and does not echo. The first
      time a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not
      echo, re-fetching the char by READ-CHAR doesn't echo:
      ------A------

  This list is not believed to be exhaustive. It is only to illustrate
  of the variety of possible ways in which the current specification can 
  be implemented without technically being in conflict with the written 
  word of CLtL. Obviously not all of these interpretations are considered 
  useful by all people, but usefulness has not been determined to be 
  criterial in satisfying the specification.

  The description of streams (p327-328) is also [probably deliberately]
  fuzzy on this issue as it relates to operating systems on which echoing 
  is done by the operating system. That is, some systems are line-at-a-time
  and all READ-CHAR and PEEK-CHAR operations happen after issues of echo
  have long since been resolved by a system call that reads and echos input 
  a line at a time. Other systems are character-at-a-time and these issues 
  hit home in a different way. It will probably be necessary to continue
  leaving things slightly unspecified in order to accomodate the native 
  style of the variety of operating systems now trying to support Common 
  Lisp, but we should be more up front about the game we are playing. (For
  example, code which must port between character-at-a-time and 
  line-at-a-time systems must be more careful about whether it does 
  newline-preceded or newline-terminated output than many CL programmers 
  might realize given the current wording.) Additionally, though, we should
  be on the lookout for less ambitious goals involving only partial
  compatibility to improve the situation wherever we can find a way to.

  Abstract functions READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST
  are implicitly affected by any decisions made on this issue since their
  descriptions involve the use of UNREAD-CHAR and PEEK-CHAR, respectively.

Proposal (PEEK-CHAR-READ-CHAR-ECHO:READ-CHAR):

  Ammend the description of READ-CHAR to say that when the stream is
  an echo stream (a stream created by MAKE-ECHO-STREAM), the character
  will be echoed on the stream at the time this operation is performed.

  Ammend the description of UNREAD-CHAR to say that when the stream
  is an echo stream (a stream created by MAKE-ECHO-STREAM), no attempt
  will be made to undo any echoing of the character which might already
  have been done on the stream.

  Ammend the description of PEEK-CHAR to say that when the stream is
  an echo stream (a stream created by MAKE-ECHO-STREAM), characters
  which are only peeked at are not echoed. Note however that in the
  case that the PEEK-TYPE argument is not NIL, the characters which
  are passed by PEEK-CHAR are treated as if by READ-CHAR, and so are
  echoed.

  Ammend the description of abstract input functions 
  READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST to acknowledge
  that they are implicitly affected by these new echoing rules of 
  READ-CHAR, UNREAD-CHAR, and PEEK-CHAR.

  Note: This is consistent with behavior [3] in the problem description.

  Clarify that the echo behavior of interactive streams such as
  *TERMINAL-IO* continues to be implementation dependent.

  Rationale:

    This is in use in a number of systems and few problems have been
    reported. However, the reason there are so few reports may be that
    few people use echo streams or that people who care about echo
    behavior just avoid UNREAD-CHAR as too unpredictable (perhaps using
    more reliable implementation-dependent primitives).
  
Proposal (PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR):

  Ammend the description of READ-CHAR to say that when the stream is
  an echo stream (a stream created by MAKE-ECHO-STREAM), the character
  will be echoed on the stream the first time those characters are seen.
  (Characters which are not echoed by READ-CHAR are those which were
  put there by UNREAD-CHAR and hence are assumed to have been echoed
  already by a previous call to READ-CHAR.)

  Ammend the description of UNREAD-CHAR to say that when the stream
  is an echo stream (a stream created by MAKE-ECHO-STREAM), no attempt
  will be made to undo any echoing of the character which might already
  have been done on the stream. However, characters placed on the
  stream by UNREAD-CHAR will be marked in such as way as to inhibit
  later re-echo by READ-CHAR.

  Ammend the description of PEEK-CHAR to say that when the stream is
  an echo stream (a stream created by MAKE-ECHO-STREAM), characters
  which are only peeked at are not echoed. Note however that in the
  case that the PEEK-TYPE argument is not NIL, the characters which
  are passed by PEEK-CHAR are treated as if by READ-CHAR, and so are
  echoed unless they have been marked otherwise by READ-CHAR.

  Ammend the description of abstract input functions 
  READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST to acknowledge
  that they are implicitly affected by these new echoing rules of 
  READ-CHAR, UNREAD-CHAR, and PEEK-CHAR.

  Note: This is consistent with behavior [6] in the problem description.

  Clarify that the echo behavior of interactive streams such as
  *TERMINAL-IO* continues to be implementation dependent.

  Rationale:

    Although this is not known to be in use in any particular system,
    nothing prevents its use. It proposes a more rational interpretation
    of the echoing behavior of UNREAD-CHAR which might make it possible
    for programmers concerned about echo behavior not to have to shy
    away from UNREAD-CHAR. (It would probably also improve the behavior
    of READ-PRESERVING-WHITESPACE with regard to echoing, since its
    description mentions using UNREAD-CHAR.)

Rationale:

  Correct echoing behavior is important to programs which do batch
  processing, parsing, etc. Allowing multiple or premature echoing
  is clearly unsatisfactory.

  Either of these proposals is an improvement over existing practice.

Current Practice:

  A wide variety of behaviors are in use.

Cost to Implementors:

  The code to implement the proposed change itself is probably fairly
  localized.

  In some operating systems, there may be echoing constraints which
  I am overlooking. Depending on what those are, I may be 
  over-trivializing the difficulty of adopting these for some
  implementations. I invite informed commentary on this issue.

  In some cases, there may be second order effects in the system 
  itself which would also require a somewhat less predictable amount 
  of work to fix. In most cases, my hope is that the work would be 
  slight only because I assume that anyone who was going to rely on 
  a particular echo behavior for anything major would have realized 
  that CLtL wasn't guaranteeing this point and would have sent mail
  complaining about this problem a lot sooner. Since no one has made 
  much noise about this, my hope is that it hasn't affected too many 
  people yet.

Cost to Users:

  Any change is effectively upward compatible since the previous
  behavior is so ill-specified.

  Most users probably naively expect (perhaps even without realizing
  it explicitly) that echoing will take care of itself. That is, they
  probably expect that echoing will occur at the time of the
  READ-CHAR and probably do not give a lot of thought to the effect
  of PEEK-CHAR. As such, FIRST-READ-CHAR probably best supports most 
  of their naive intuitions.

Cost of Non-Adoption:

  The streams returned by MAKE-ECHO-STREAM would continue to be
  significantly hard to use portably.

Benefits:

  A number of applications involving of parsers, batch script
  interpreters, and such would be possible to implement
  straightforwardly and portably.

Aesthetics:

  [Thoughts anyone? -kmp]

Discussion:

  Pitman supports PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR because
  he feels it is more practically coherent. However, he says he has
  only mental exercises and no actual personal experience upon which
  to base that belief.

  Version 1 of this proposal treated interactive streams on par
  with echo streams, but while people agreed that this issue is
  a severe portability problem, some considered that the treatment
  of interactive streams got involved in operating system issues
  that were beyond the scope of the standard, so that part of the
  text was removed.
 

∂23-Jun-88  1412	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jun 88  14:12:08 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423898; Thu 23-Jun-88 17:11:49 EDT
Date: Thu, 23 Jun 88 17:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COMPOSITION (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880623171122.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        FUNCTION-COMPOSITION
References:   None
Category:     ADDITION
Edit history: 21-Jun-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  A number of useful functions on functions are conspicuously
  absent from Common Lisp's basic set. Among them are functions
  which return constant T, constant NIL, and functions which
  combine functions in common, interesting ways.

Proposal (FUNCTION-COMPOSITION:NEW-FUNCTIONS):

  Add the following functions:

   COMPOSE &REST functions				[Function]

    Returns a function whose value is the same as the composition
    of the given functions. eg, (FUNCALL (COMPOSE #'F #'G #'H) A B C)
    is the same as (F (G (H A B C))). Also, for example, #'CAADR may
    be described as (COMPOSE #'CAR #'CAR #'CDR).

   CONJOIN &REST functions				[Function]

    Returns a function whose value is the same as the AND of the
    given functions applied to the same arguments.

   DISJOIN &REST functions				[Function]

    Returns a function whose value is the same as the OR of the
    given functions applied to the same arguments.

   COMPLEMENT function					[Function]

    Returns a function whose value is the same as the OR of the
    given functions applied to the same arguments.

   ALWAYS value						[Function]

    Returns a function whose value is always VALUE.

Examples:

  (MAPCAR #'(LAMBDA (X) (DECLARE (IGNORE X)) T) '(3 A 4.3))
  ==
  (MAPCAR (ALWAYS T) '(3 A 4.3))
  => (T T T)

  (MAPCAR #'(LAMBDA (X) (AND (NUMBERP X) (ZEROP X))) '(3 A 0.0))
  ==
  (MAPCAR (CONJOIN #'NUMBERP #'ZEROP) '(3 A 0.0))
  => (NIL NIL T)

  (FIND-IF #'(LAMBDA (X) (AND (INTEGERP X) (SYMBOLP X))) '(3.0 A 4))
  ==
  (FIND-IF (DISJOIN #'INTEGERP #'SYMBOLP) '(3.0 A 4))
  => A

  (FUNCALL #'(LAMBDA (&REST X) (REVERSE (APPLY #'LIST* X))) 3 4 5 '(6 7))
  ==
  (FUNCALL (COMPOSE #'REVERSE #'LIST*) 3 4 5 '(6 7))
  => (7 6 5 4 3)

  (FIND-IF-NOT #'ZEROP '(0 0 3))
  ==
  (FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
  => 3

Rationale:

  This can contribute to syntactic conciseness, and may sometimes
  even make things easier for a compiler to recognize and compile
  efficiently.

  In principle, a proposal to flush the :TEST-NOT keywords and the
  -IF-NOT functions could even be entertained if the COMPLEMENT
  function were added.

Current Practice:

  No Common Lisp implementations provide these primitives, but they do
  exist in the T language.

Cost to Implementors:

  A straightforward implementation is simple to cook up. The definitions
  given here would suffice. Typically some additional work might be
  desirable to make these open code in interesting ways.

  (DEFUN COMPOSE (&REST FUNCTIONS)
    (COND ((NOT FUNCTIONS)
	   (ERROR "COMPOSE requires at least one function."))
	  ((NOT (REST FUNCTIONS))
	   (FIRST FUNCTIONS))
	  (T
	   (LET ((REVERSED-FUNCTIONS (REVERSE FUNCTIONS)))
	     (LET ((LAST-FUNCTION   (FIRST REVERSED-FUNCTIONS))
	           (OTHER-FUNCTIONS (REST  REVERSED-FUNCTIONS)))
               #'(LAMBDA (&REST ARGUMENTS)
                   (DO ((O OTHER-FUNCTIONS (CDR O))
			(VAL (APPLY LAST-FUNCTION ARGUMENTS)
			     (FUNCALL (CAR O) VAL)))
		       ((NULL O) VAL))))))))

  (DEFUN CONJOIN (&REST FUNCTIONS)
    #'(LAMBDA (&REST ARGUMENTS)
        (DO ((F FUNCTIONS (CDR F))
	     (VAL T (AND VAL (APPLY (CAR F) ARGUMENTS))))
	    ((OR (NULL VAL) (NULL F)) VAL))))

  (DEFUN DISJOIN (&REST FUNCTIONS)
    #'(LAMBDA (&REST ARGUMENTS)
        (DO ((F FUNCTIONS (CDR F))
	     (VAL NIL (OR VAL (APPLY (CAR F) ARGUMENTS))))
	    ((OR VAL (NULL F)) VAL))))

  (DEFUN COMPLEMENT (FUNCTION)
    #'(LAMBDA (&REST ARGUMENTS)
        (NOT (APPLY FUNCTION ARGUMENTS))))

  (DEFUN ALWAYS (VALUE)
    #'(LAMBDA (&REST ARGUMENTS) 
        (DECLARE (IGNORE ARGUMENTS))
        VALUE))

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  (COMPLEMENT BENEFITS)

Benefits:

  Some code would be more clear. 
  Some compilers might be able to produce better code.

  Takes a step toward being able to flush the -IF-NOT functions
  and the :TEST-NOT keywords, both of which are high on the list
  of what people are referring to when they say Common Lisp is
  bloated by too much garbage.

Aesthetics:

  In situations where these could be used straightforwardly, the
  alternatives are far less perspicuous.

Discussion:

  Pitman supports the inclusion of these primitives.

∂23-Jun-88  1516	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 23 Jun 88  15:16:52 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 23 Jun 88 18:16:42 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1) 
In-reply-to: Your message of Thu, 23 Jun 88 17:11:00 -0400.
             <880623171122.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> 
Date: Thu, 23 Jun 88 18:16:22 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


Presumably the following is a typo, and you intend this to a function that
calls the given function and then negates its argument.  Or something like
that.

---------------------------------------------------------------------------
   COMPLEMENT function					[Function]

    Returns a function whose value is the same as the OR of the
    given functions applied to the same arguments.
---------------------------------------------------------------------------

This all seems a bit gratuitous to me, but if the rest of you think it
would promote better programming style, I won't argue.

-- Scott

∂24-Jun-88  0912	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Jun 88  09:12:06 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 424181; Fri 24-Jun-88 12:11:52 EDT
Date: Fri, 24 Jun 88 12:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1) 
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 23 Jun 88 18:16 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU
Message-ID: <880624121129.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Thu, 23 Jun 88 18:16:22 EDT
    From: Scott.Fahlman@B.GP.CS.CMU.EDU

    Presumably the following is a typo ...

Yup.

    ... This all seems a bit gratuitous to me, but if the rest of you
    think it would promote better programming style, I won't argue.

Well, I'm not passionate about this issue, but times have changed a lot
since the last time this issue came up. Functional programming styles
are much more respectable to talk about now. I just wanted to give people
a chance to react to them anew.

∂24-Jun-88  1058	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Jun 88  10:58:26 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 424262; Fri 24-Jun-88 13:58:12 EDT
Date: Fri, 24 Jun 88 13:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: DICK@WHEATIES.AI.MIT.EDU
Message-ID: <880624135739.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Don't panic -- Versions 1-3 were circulated between Dick Waters and myself
and did not reach this list. This is the first version CL-Cleanup should
have seen.

Also, please be sure to cc Dick@WHEATIES.AI.MIT.EDU in any correspondence
on this issue since he's not on CL-Cleanup.
 -kmp

----------
Issue:        STREAM-INFO
References:   FORMAT ~T (pp398-9) and ~<...~> (pp404-6), PPRINT (p383)
Category:     ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman (2d model)
	      23-Jun-88, Version 2 by Waters (1d model, modified 2d model)
	      24-Jun-88, Version 3 by Pitman (minor reformatting)
	      24-Jun-88, Version 4 by Pitman (remove 2d model for submission)
Status:	      For Internal Discussion

Problem Description:

  Currently, there is no portable way to inquire about the line width
  of an output stream, the current character position on a line
  or the amount of space that the display of a string will take up.
  This makes it essentially impossible to write a portable
  implementation of a pretty printer.

Proposal (STREAM-INFO: ONE-DIMENSIONAL-FUNCTIONS):

  Introduce four new functions:

   OUTPUT-WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*)       [Function]

    Returns the maximum line width that can be printed on the
    OUTPUT-STREAM without causing truncation or wraparound.  The
    result is returned as a non-negative integer, or NIL if the stream
    has no meaningful width (or the width cannot be computed).  The
    unit of width is arbitrary, however, given a particular output
    stream, the unit must have some fixed value.

   OUTPUT-POSITION &optional (OUTPUT-STREAM *STANDARD-OUTPUT*)    [Function]

    Returns the current horizontal position of the cursor on the given
    OUTPUT-STREAM as a non-negative integer, or NIL if it cannot be
    computed.  (The position is the position of the distance of the
    left edge of the cursor from the left margin.  I.e., 0 means
    cursor is at the left end of a line.)  The units are arbitrary,
    but for a given stream, they must be the same as the units used by
    OUTPUT-WIDTH.

   STRING-WIDTH STRING &optional (OUTPUT-STREAM *STANDARD-OUTPUT*)
		       &key (START 0) (END NIL) 		  [Function]

    The START and END parameters delimit a substring of string in the
    usual manner.  STRING-WIDTH returns the change in output position
    that would occur if STRING were written to OUTPUT-STREAM using
    (WRITE-STRING STRING OUTPUT-STREAM :start START :end END) given
    the current state of OUTPUT-STREAM or NIL if the change cannot be
    computed.  The returned value is an integer.  The units are
    arbitrary, but for a given stream, they must be the same as the
    units used by OUTPUT-WIDTH.  STRING-WIDTH satisfies the following
    constraint.

    (LET* ((STREAM ...)
           (STRING ...)
           (CURRENT-X (OUTPUT-POSITION STREAM)))
      (= (STRING-WIDTH STRING STREAM)
         (- (PROGN (WRITE-STRING STRING STREAM) 
                   (OUTPUT-POSITION STREAM))
            CURRENT-X)))

    STRING-WIDTH does not return any indication of the vertical
    distance required when printing string.  Merely the difference in
    horizontal position before and after printing.  This difference
    may be negative (e.g., if STRING contains backspace or newline
    characters.)  It is possible that the width of a string will
    depend on the horizontal position where output begins (e.g., if
    the string contains tab characters.)  If this is the case, the
    width returned assumes that the output occurs starting at the
    current horizontal position in the stream.  Similarly, the width
    of string may depend on other aspects of the state of
    OUTPUT-STREAM (e.g., the font being used).  In all respects the
    width is computed based on the current state of the stream.
    STRING-WIDTH never causes any change in the state of OUTPUT-STREAM.

   OUTPUT-SPACE WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [function]

    This function causes blank space to be inserted in OUTPUT-STREAM
    so that the output position is increased by WIDTH.  WIDTH is an
    integer.  The units are arbitrary, but for a given stream, they
    must be the same as the units used by OUTPUT-WIDTH.  A negative
    WIDTH parameter indicates backspacing.  The unit of WIDTH should
    be chosen so that it is possible to move the output position left
    and right by a single unit.  OUTPUT-SPACE satisfies the following
    constraint.

    (LET* ((STREAM ...)
           (N ...))
      (= (+ (OUTPUT-POSITION STREAM) N)
         (PROGN (OUTPUT-SPACE N STREAM)
                (OUTPUT-POSITION STREAM))))

    OUTPUT-SPACE returns T if the spacing operation has been achieved
    and NIL otherwise (e.g., if the requested spacing would move off
    of the end of the line or if the the operation cannot be supported
    for the given stream.)

   A key motivation behind the functions above is dealing with
   output streams that support variable length fonts.  The unit of
   width is allowed to vary from stream to stream in order to allow
   for differences between output devices.  The only thing that
   matters is that the four functions above operate on the same units
   when given the same stream.

   If an output stream only supports a single fixed width font, the
   logical choice of width unit is the length of a single character.
   In this situation (and ignoring characters such as tab, newline,
   and other control characters that do not have an output width of
   one) the functions above have the following simple meanings.
   OUTPUT-WIDTH returns the maximum number of characters which can be
   printed on a single line.  OUTPUT-POSITION returns the number of
   characters which have already been printed on the current line.
   STRING-LENGTH returns the number of characters in the string.
   OUTPUT-SPACE prints the specified number of space, or backspace,
   characters.

   Another key feature of the functions above is that they are all
   permitted to return NIL without performing any action.  This is to
   allow for the fact that the required operations might not be
   supported for every kind of stream.  However, it is hoped that the
   functions would in fact be supported for most kinds of streams.

Test Case:

  Suppose that S is an output stream that supports a single fixed
  width font which can display 72 characters on a line and that the
  associated width unit is the width of one character.  Evaluating the
  following will produce the results shown.

  (output-width S) => 72
  (terpri S)
  (output-position S) => 0
  (string-width "testing: " S) => 9
  (write-string "testing: " S)
  (output-position S) => 9
  (write-string "foo" S)
  (terpri S)
  (output-space 9 S) => T
  (write-string "bar" S)

  The output produced is
testing: foo
	 bar

Rationale:

  Pretty printing requires the function OUTPUT-WIDTH in order to know
  how wide the output it produces can be.  Pretty printing requires
  OUTPUT-POSITION in order to determine where on the line output is
  when pretty printing starts.  Pretty printing requires STRING-WIDTH
  in order to determine how much space things will take in the output.
  (If a variable width font is being used, this cannot be determined
  without a detailed knowledge of the font being used.)  Pretty
  printing requires OUTPUT-SPACE in order to get proper indentations.
  (If a variable width font is being used, indentations may be
  required that cannot be obtained by outputting spaces.)

Current Practice:

  Essentially every implementation of Common Lisp must support the
  functionality above internally in order to support PPRINT and the
  FORMAT directives ~T and ~<...~>.  However, there is no documented
  interface to this functionality in CLTL.  As a result, while some
  implementations of Common Lisp make this functionality available to
  users, some do not.  Further, the implementations that do provide
  this functionality do so in a variety of incompatible ways.

Cost to Implementors:

  This proposal is written in such a way as to allow implementations which
  do not have the ability to compute difficult values to just return NIL.
  Very little work is forced. The idea is to offer implementors a common way
  to provide this useful information to portable programs where possible.  

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  Complex output programs such as pretty printers cannot be written portably.

Benefits:

  A wide range of programs can gain better control of the format of output.

Aesthetics:

  No significant aesthetic impact other than a slight increase in the
  number of functions defined.

Discussion:

  Dick Waters submitted a request for changes along the line of the
  horizontal aspects of these functions in a letter to X3J13 dated
  June 14, 1988.  Pitman and Waters wrote up the request formally.

  STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS is the minimum which is
  required in order to support pretty printing into a stream which
  displays output using a variable width font.

  We drafted an alternate proposal, STREAM-INFO:TWO-DIMENSIONAL-FUNCTIONS,
  which goes significantly beyond what is needed merely for pretty printing
  and provides primitives OUTPUT-DIMENSIONS, OUTPUT-POSITION,
  STRING-DIMENSIONS, and OUTPUT-SPACE but it is not included here.
  A key point of contention which would be likely to swamp the 2d proposal
  is the age old question of how to handle the issue of vertical distance
  (where is the origin, which way do you count, ...). If anyone would
  prefer to see larger problem 2d proposal, it could be circulated, but at
  the last minute Pitman got worried that even the 1d version was going to
  be controversial enough and decided to keep things focused on that.

  For his own needs, Waters is strongly interested in having either
  ONE-DIMENSIONAL-FUNCTIONS or TWO-DIMENSIONAL-FUNCTIONS proposal accepted,
  but does not care which. Pitman concurs.

  One variation of the 1d proposal might be useful to consider:
   STRING-WIDTH could return two additional values: the number of newlines
    that WRITE-STRING of the string would execute and the maximum X position
    encountered (which might differ from the first value if the number of
    newlines was non-zero).
  This feature wasn't necessary for Waters' minimalist proposal, but Pitman
  would be willing to write it in here if people thought it would be useful
  enough for other purposes.

∂24-Jun-88  1100	CL-Cleanup-mailer 	Issue: STRUCTURE-INFO (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Jun 88  11:00:21 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 424268; Fri 24-Jun-88 14:00:04 EDT
Date: Fri, 24 Jun 88 13:59 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STRUCTURE-INFO (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: DICK@WHEATIES.AI.MIT.EDU
Message-ID: <880624135946.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Please be sure to cc Dick@WHEATIES.AI.MIT.EDU in any correspondence
on this issue since he's not on CL-Cleanup.
 -kmp

----------
Issue:        STRUCTURE-INFO
References:   Structures (pp305-320)
Category:     ADDITION
Edit history: 24-Jun-88, Version 1 by Pitman and Waters
Status:	      For Internal Discussion

Problem Description:

  There is no portable way to determine whether something is a structure
  and no portable way to ask abstractly what the contents of a structure
  are without understanding that particular structure.

Proposal (STRUCTURE-INFO:NEW-FUNCTIONS):

  Introduce these new functions:

   STRUCTUREP thing					[Function]

    Predicate returns true if the given object is represented as
    a structure (without the use of DEFSTRUCT's :TYPE option).
    Otherwise, returns false.

   STRUCTURE-CONTENTS structure 			[Function]

    Returns an alist of field names (as keywords) and field values showing
    the contents of the STRUCTURE. The STRUCTURE may be any object
    for which STRUCTUREP returns true.

Test Case:

  (DEFSTRUCT (FRED (:TYPE VECTOR)) (A 1) (B 2) (C 3))
  (SETQ FRED (MAKE-FRED))
  (STRUCTUREP FRED) => NIL
  (VECTORP FRED) => T
  (STRUCTURE-CONTENTS FRED) is undefined

  (DEFSTRUCT WILMA (A 1) (B 2) (C 3))
  (SETQ WILMA (MAKE-WILMA))
  (STRUCTUREP WILMA) => T
  (STRUCTURE-CONTENTS WILMA) => ((:A . 1) (:B . 2) (:C . 3))

Rationale:

  STRUCTUREP is important for implementing a portable pretty printer in
  a number of ways.  STRUCTURE-CONTENTS is less important, but is necessary
  if a portable pretty printer is to print structures in #S notation.

Current Practice:

  Some implementations, such as Symbolics Genera, provide
   (TYPEP x 'STRUCTURE).
  Most implementations do not go so far as to provide STRUCTUREP, however.

  Probably no implementations offer STRUCTURE-CONTENTS in any exported form.

Cost to Implementors:

  Since the standard printer must access this same information when 
  printing structures, it must be very trivial to provide this functionality.

Cost to Users:

  None. This is an upward compatible change.

Cost of Non-Adoption:

  Portable pretty printers would not be able to pretty-print structure
  objects in #S notation.

Benefits:

  In addition to pretty printers, this might be of some use to programmers
  customizing the generic function DESCRIBE, or to people writing
  DESCRIBE-like facilities.

Aesthetics:

  No major aesthetic impact.

Discussion:

  Dick Waters submitted a request for changes of this kind in a letter to
  X3J13 dated June 14, 1988. Pitman wrote up the request formally.

  If the CLOS meta-object protocol becomes a standard part of CL, this
  facility would not be necessary.  However, if that protocol is in any way
  optional, it would be useful to have this interface since it can be
  implemented using considerably less powerful primitives than that
  protocol offers.

∂24-Jun-88  1149	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 Jun 88  11:49:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUN 88 11:42:59 PDT
Date: 23 Jun 88 00:53 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: STREAM-INFO (Version 4)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Fri, 24 Jun 88 13:57 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, DICK@WHEATIES.AI.MIT.EDU
Message-ID: <880624-114259-5815@Xerox>

"Returns the current horizontal position of the cursor..."

The word "cursor" is unfortunately overused and not defined here or elsewhere in
CLtL. 
What is 
	(with-output-to-string (x ) (princ "a test") (output-position x))?

Is it implementation dependent?

What is (output-position *terminal-io*)? What is the relation between
(output-position (make-broadcast-stream a b)) and (output-position a) and
(output-position b)?


I'm sure I can think of more questions given time...


∂24-Jun-88  1209	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Jun 88  12:09:13 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 424326; 24 Jun 88 15:08:21 EDT
Date: Fri, 24 Jun 88 15:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: STREAM-INFO (Version 4)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, Dick@WHEATIES.AI.MIT.EDU
In-Reply-To: <880624-114259-5815@Xerox>
Message-ID: <880624150813.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

We'll see if we can add enough description of a cursor to make
the proposal more clear.

It's good to have the hard issues listed out, and they should probably be
in the discussion section, but since you're permitted to return NIL on any
case you think is too hard, I hope the proposal doesn't get stalled on that.

The important point here is that many implementations -do- have a theory
of where the cursor is in some or all of those situations, and if the
implementation has a theory, Dick just wants to be able to access that info.
The idea isn't to make more work for implementors -- only to make a common
interface to this facility where it does exist. As it is, you have to
use a lot of #+ and #- stuff to deal with this -- and every time a new
implementation comes along, it has to decide which existing implementation
to use as a pattern or whether to make up its own protocol.

∂24-Jun-88  1225	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 Jun 88  12:25:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUN 88 12:18:12 PDT
Date: 24 Jun 88 12:17 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: STREAM-INFO (Version 4)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Fri, 24 Jun 88 15:08 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU,
 Dick@WHEATIES.AI.MIT.EDU
Message-ID: <880624-121812-5897@Xerox>

While relying on implementation-specific heuristics for implementation-specific
streams seems right to me, it seems less clear for streams that are created
using otherwise portable mechanisms. For example, we could define that for
string streams created , the line width is the value of *string-stream-width*
(and encapsulated in the stream), where NIL means infinite,  and that the unit
of width is 1 and that every character takes exactly 1 character, that
two-way-streams and echo-streams inherit the position and width of their output
streams, that broadcast streams inherit from their first component. 

∂24-Jun-88  1307	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 Jun 88  13:07:45 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUN 88 12:56:50 PDT
Date: 24 Jun 88 12:56 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1) 
In-reply-to: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Thu, 23 Jun 88 18:16:22
 EDT
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880624-125650-6005@Xerox>

I think this stuff might be useful, but it falls into the category of a package
of useful things that we should distribute. Compare the situation  with LOOP,
where the proliferation of incompatible LOOP macros is a serious problem. Is
there a problem with proliferation of versions of these?




∂24-Jun-88  1552	CL-Cleanup-mailer 	EQUAL 
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 24 Jun 88  15:52:33 PDT
Received: by labrea.stanford.edu; Fri, 24 Jun 88 15:52:27 PDT
Received: from bhopal.lucid.com by edsel id AA07541g; Fri, 24 Jun 88 14:38:25 PDT
Received: by bhopal id AA16670g; Fri, 24 Jun 88 14:38:05 PDT
Date: Fri, 24 Jun 88 14:38:05 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806242138.AA16670@bhopal.lucid.com>
To: RWK@ai.ai.mit.edu
Cc: edsel!jlm@labrea.stanford.edu, common-lisp@sail.stanford.edu,
        cl-cleanup@sail.stanford.edu
In-Reply-To: "Robert W. Kerns"'s message of Mon, 13 Jun 88 02:05:15 EDT <396357.880613.RWK@AI.AI.MIT.EDU>
Subject: EQUAL

[apologies for so late a reply -- have been out of town for over a week]

Jim's point about the historical reference of EQUAL seemed to me to be that
it was made to work for the datatypes that were "in common use" in the Lisps
of that day, namely the datatypes necessary for writing programs in the 
Lisp language.  Hence, conses, symbols, numbers, maybe strings, and not 
much else.

However, I certainly wouldn't expect anything productive to come from a 
discussion on how to determine whether two programs/functions  *really*  
are "equal"!   Possibly you took MacDonald's argument to an extreme that 
he didn't originally intend?

What would be the objections to extending EQUAL to accommodate the serious 
modern datatypes of Common Lisp? in particular:

   (1) Do component-wise EQUAL comparisons on arrays [this implies "descent"
       for pointer arrays].  Unlike with EQUALP, the arrays must be of the 
       same type, but the presence of fill-pointers,  array-element-type
       "upgrading", adjustability, and displacement may require some 
       refinements of this clause.

   (2) Descend defstructs, except possibly for "system" defstructs that
       are built-in by the implementation [i.e., an implementation can
       use defstruct to implement a STREAM, but impose a "private"
       definition of EQUAL for streams; probably same for all types 
       discussed in the cleanup issue TYPE-HIERARCHY-UNDERSPECIFIED].  
       Possibly extend defstruct to admit an option :equal, similar to 
       the :copier option, but this isn't a critical requirement now.

   (3) Require that EQUAL be a "generic" function, so that CLOS methods
       can be written for it; likely, the "default" method for non-built-in
       classes would be some sort of error, meaning that mindless descent
       isn't a good default.  By analogy with defstructs, you can compare
       two defstuct-instances of the same type with the :equal functions,
       and you could only compare two clos instances for which there is an 
       appropriate EQUAL method supplied.


This definition would imply that hashtables of :type EQUAL will operate in
the manner expected by so many users of Common Lisp.  Somehow, people have
been lured into thinking that this is already the current practice; but of 
course something much more limiting is the current state.


Finally, I might point out that recent discussions about EQUALP seem to 
have overlooked it's variations on numerical equality and array-type
indifference.  Extending EQUAL to descend structures is *not* the same 
as retracting EQUALP to be case-sensitive.


-- JonL --

∂24-Jun-88  1647	CL-Cleanup-mailer 	EQUAL 
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 24 Jun 88  16:47:42 PDT
Received: by labrea.stanford.edu; Fri, 24 Jun 88 16:47:38 PDT
Received: from bhopal.lucid.com by edsel id AA08086g; Fri, 24 Jun 88 16:40:19 PDT
Received: by bhopal id AA18154g; Fri, 24 Jun 88 16:39:58 PDT
Date: Fri, 24 Jun 88 16:39:58 PDT
From: Jim McDonald <edsel!jlm@labrea.stanford.edu>
Message-Id: <8806242339.AA18154@bhopal.lucid.com>
To: edsel!jonl@labrea.stanford.edu
Cc: common-lisp@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Fri, 24 Jun 88 14:38:13 EST <8806242138.AA16670@bhopal.lucid.com>
Subject: EQUAL

My concern about having EQUAL descend structures and arrays is that
they are much more likely than lists to be circular.

Typically, a list is created after its elements, whereas a structure
or array is created before its elements.  (*Typically*, not always!)

As a rule of thumb, I'd bet that less than .0001% of all lists are
circular, and that less than 1% of all arrays are circular, but only
that less than 30% of all structures are circular.  

I think there is a tendancy to include fields like CHILDREN and
PARENTS, or PREVIOUS and NEXT, etc. in structures, which are thus
almost guaranteed to be circular.  In fact, when I'm creating circular
data I tend to think first of using structures, because I am then less
likely to get screwed by EQUAL, etc.

I don't have time now to think through the algorithmic details, but
maybe DEFSTRUCT could let you specify that specific slots are
"back-pointers".  Then EQUAL could record them when descending and
perform a more sophisticated comparison than it would for all other
pointers.   Thus you would only pay at runtime for the specific
complications you did introduce, not those you might have.  Making
backpointers explicit might help human readability as well.

[As something of an aside, I think you should also be able to specify
 *print-level* and *print-length* for specific structure fields, to
 avoid losing on some fields when trying to see others.]

  jlm

∂27-Jun-88  0753	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jun 88  07:53:34 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 425042; Mon 27-Jun-88 10:48:33 EDT
Date: Mon, 27 Jun 88 10:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: STREAM-INFO (Version 4)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, Dick@WHEATIES.AI.MIT.EDU
In-Reply-To: <880624-121812-5897@Xerox>
Message-ID: <880627104822.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 24 Jun 88 12:17 PDT
    From: Masinter.pa@Xerox.COM

    While relying on implementation-specific heuristics for implementation-specific
    streams seems right to me, it seems less clear for streams that are created
    using otherwise portable mechanisms. For example, we could define that for
    string streams created , the line width is the value of *string-stream-width*
    (and encapsulated in the stream), where NIL means infinite,  and that the unit
    of width is 1 and that every character takes exactly 1 character, 

This might be useful. It should be clear that you mean string streams created
by a CL primitive and not arbitrary string streams, though, since implementations
might have other theories on other streams. Also, actually, I think it should
somehow be streams of STRING-CHAR only, since arbitrary chars may have fonting
information and it may in some cases be clear to an implementor that this portable
model is not appropriate. I'd hate to tie an implementor's hands....

    that two-way-streams and echo-streams inherit the position and width of their
    output streams,

Ok since they have a unique output stream (no ambiguity).

    that broadcast streams inherit from their first component.

Perhaps, but this I'm less sure of and might be inclined to leave as
undefined.  It might, for example, make more sense for an implementation
to use the MIN of the width of the streams. Also, it might make sense
for an implementation to canonicalize the units so if stream1 were fixed
width (char=1) and stream2 were pixel-based, the merged stream might
report in pixels so even if it used stream1's information, it might not
-look- like stream1's information, so it might be misleading to say it
was.

I'm ammenable to a rewrite of this proposal per these suggestions if you
wanted to do that (and if no one else had a dissenting opinion). The
original intent (and the reason I didn't mail out the 2d proposal) was
to keep things simple. I don't want to add any hair that will make it
harder for this to pass x3j13, but things that seem reasonable to
everyone are ok by me...

∂27-Jun-88  0817	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
Received: from rice-chex.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jun 88  08:17:22 PDT
Received: by rice-chex.ai.mit.edu; Mon, 27 Jun 88 11:19:15 EDT
Date: Mon, 27 Jun 88 11:19:15 EDT
From: dick@wheaties.ai.mit.edu (Richard C. Waters)
Message-Id: <8806271519.AA01551@rice-chex.ai.mit.edu>
To: Masinter.pa@xerox.com
Cc: CL-Cleanup@sail.stanford.edu, KMP@stony-brook.scrc.symbolics.com
In-Reply-To: Masinter.pa@xerox.com's message of 24 Jun 88 12:17 PDT <880624-121812-5897@Xerox>
Subject: Issue: STREAM-INFO (Version 4)


    While relying on implementation-specific heuristics for
    implementation-specific streams seems right to me, it seems less clear
    for streams that are created using otherwise portable mechanisms. 
This is a good point.  However, I agree with KMP that we do not want to load
this proposal up with a lot of baggage.
								      
    For example, we could define that for string streams created, the line
    width is the value of *string-stream-width* (and encapsulated in the
    stream), where NIL means infinite, and that the unit of width is 1 and
    that every character takes exactly 1 character,
Here, it seems to me that that logical width of a string stream is
infinity.  I would not add any extra hair.  It is the user who
presumably has some theory about how wide the stream should be.  Any
reasonable pretty printer or the like will have a way for the user to
override the inherent width of a stream.

    that two-way-streams and echo-streams inherit the position and
    width of their output streams,
This sounds good to me.

    that broadcast streams inherit from their first component.
I agree with KMP's comments on this.  Things do not seem all that simple.

			Dick

∂27-Jun-88  0834	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
Received: from rice-chex.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jun 88  08:33:51 PDT
Received: by rice-chex.ai.mit.edu; Mon, 27 Jun 88 11:35:44 EDT
Date: Mon, 27 Jun 88 11:35:44 EDT
From: dick@wheaties.ai.mit.edu (Richard C. Waters)
Message-Id: <8806271535.AA01655@rice-chex.ai.mit.edu>
To: Masinter.pa@xerox.com
Cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 23 Jun 88 00:53 PDT <880624-114259-5815@Xerox>
Subject: Issue: STREAM-INFO (Version 4)

  
    "Returns the current horizontal position of the cursor..."

    The word "cursor" is unfortunately overused and not defined here or
    elsewhere in CLtL.

Cursor is indeed a vague word.  Perhaps we could just say THAT
"OUTPUT-POSITION returns the total net width of all of the
characters written to the stream since that last <newline> character
(or since the creation of the stream if no <newlines> have ever been
written).


    What is (with-output-to-string (x) (princ "a test") (output-position x))?
    Is it implementation dependent?

There is really a key point here.  Yes it is implementation dependent.
In particular, the values returned cannot be used for anything but
comparing with each other.  For example, if the output-width is not
nil, then the value of output-position can be compared with it to
determine how close you are to the end of the line (in percent, but
not by any absolute measure.)  [With a string-stream the logical
output-width is assumedly nil.]

Another use of output-position is that no matter what number
output-position returns, sending a <newline> to the stream and then
calling output-space with the same number will get you back to the
same horizontal place.

The proposal is carefully crafted to give you these two capabilities
while adding as few other constraints as possible.

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

NOTE, a broadcast stream must keep track of the relationships between
the units of width used by the actual target streams so that
output-space requests can be translated correctly when they are
broadcast to all of the actual targets.  

				Dick

∂27-Jun-88  1238	CL-Cleanup-mailer 	Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jun 88  12:38:20 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 425383; Mon 27-Jun-88 15:38:00 EDT
Date: Mon, 27 Jun 88 15:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880627153746.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        PATHNAME-TYPE-UNSPECIFIC
References:   Pathnames (pp410-413)
Category:     CHANGE
Edit history: 27-Jun-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  CLtL (p412) specifies that the type is ``always a string, NIL,
  or :WILD.'' This description is too restrictive to be practical.

  In file systems which have no first-class notion of a name/type
  distinction, it is possible to make files named "foo." and "foo"
  which are distinct. One of these (usually the former) can get a
  type of "" but it is not clear how to represent the other. If
  NIL is used, merging primitives cannot detect that the field is
  filled and should not be merged against.

Proposal (PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN):

  Permit :UNSPECIFIC as a value of the type field of a pathname for
  operating systems in which it makes sense.

  When a pathname is converted to a namestring, NIL and :UNSPECIFIC
  both cause the component not to appear in the string.

  When merging, however, a NIL value for a component will be replaced
  with the default for that component, while :UNSPECIFIC will be left
  alone.

Test Case:

  For file systems where :UNSPECIFIC makes sense...

  (PATHNAME-TYPE (MAKE-PATHNAME :TYPE :UNSPECIFIC)) => :UNSPECIFIC

  (PATHNAME-TYPE (MERGE-PATHNAMES (MAKE-PATHNAME :TYPE :UNSPECIFIC)
				  (MAKE-PATHNAME :TYPE "FOO")))

Rationale:

  This is, by necessity, current practice in some implementations
  already.

Current Practice:

  Symbolics Genera uses a file type of :UNSPECIFIC on Unix and
  ITS file systems, for example.

Cost to Implementors:

  None. No change to any implementation is forced.

  Some implementations which use a non-standard token other than :UNSPECIFIC
  to implement this functionality might want to switch to use :UNSPECIFIC so
  that portable programs could expect it.

Cost to Users:

  Some programs which manipulate pathnames should be updated to expect
  :UNSPECIFIC in the type fields in some situations.

  Any program which doesn't already expect :UNSPECIFIC is already not really
  portable, however, given that some implementations have been forced to
  go beyond the standard in order to represent all possible pathnames.

Cost of Non-Adoption:

  Some implementations would be unable to both represent all possible pathnames
  in a rational way and at the same time to conform to the standard.

Benefits:

  Some programs involving pathnames would be more portable.

Aesthetics:

  Sweeping a hairy situation under the rug doesn't make it go away.
  This change makes things appear less simple, but since in reality
  they were less simple, it is effectively a simplification of the
  correspondence between the CL model and reality.

Discussion:

  Pitman supports PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.

  This feature existed in the Colander draft edition of CLtL, but was
  removed for the Laser edition. The following text is excerpted from
  the Colander edition, p259:

   ``??? Query: Is :unspecific really needed over and above nil?

   ``A component of a pathname can also be the keyword
     :UNSPECIFIC. This means that the component has been explicitly
     determined not to be there, as opposed to be missing. One way
     this can occur is with generic pathnames, which refer not to
     a file but to a whole family of files. The version, and usually
     the type, of a generic pathname are :unspecific. Another way
     :unspecific is used to represent components that are not simply
     supported by a file system. When a pathname is converted to a
     namestring, nil and :unspecific both cause the component not to
     appear in the string. When merging, however, a nil value for
     a component will be replaced with the default for that
     component, while :unspecific will be left alone.''

∂27-Jun-88  1357	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 1)  
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 27 Jun 88  13:57:07 PDT
Received: by labrea.stanford.edu; Mon, 27 Jun 88 13:57:02 PDT
Received: from bhopal.lucid.com by edsel id AA00331g; Mon, 27 Jun 88 12:29:22 PDT
Received: by bhopal id AA00551g; Mon, 27 Jun 88 12:29:15 PDT
Date: Mon, 27 Jun 88 12:29:15 PDT
From: Jim McDonald <edsel!jlm@labrea.stanford.edu>
Message-Id: <8806271929.AA00551@bhopal.lucid.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Thu, 23 Jun 88 17:11 EDT <880623171122.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COMPOSITION (Version 1)

The following is a sketch of some other possibly useful operators.
Maybe some kind soul out there will adopt them and make a real
proposal to add them. 

Note that the notions of permutation-vector are actually just a
first stab--one might really want some lambda-list -> lambda-list
operator that understands &optional, &key, &rest, etc.  It might
also be useful to have an operator that permitted deletion or
repetition of arguments.  

I think the caveat about redefinition of the given function should
be added to the existing proposal and apply to all the composition 
functions. 

   COMMUTE function                                    [Function]

    Returns a function whose value is the same as that of the
    given function applied to the same arguments with the first
    two interchanged.

   PERMUTE function argument-permutation
           &optional value-permutation                 [Function]

    Returns a function whose values are a permutation of the
    values which would be returned by an application of the given
    function to a permutation of its arguments.

    If argument-permutation is NIL, the effect is as if all 
    arguments were passed to the given function without being
    permuted.  If it is non-NIL, it must be a sequence of integers
    containing a permutation of an initial subset of the natural 
    numbers, and the effect is as if each argument, at position i,
    is first moved to position (elt argument-permutation i) before
    the given function is called.  

    If values-permutation is NIL, the effect is as if values were
    returned from the given function without being permuted.  If 
    it is non-NIL, it must be a sequence containing a permutation
    of an initial subset of the natural numbers, and the effect is
    as if each value, at position j, is first moved to position 
    (elt value-permutation j) before the result function returns. 

    Note that in practice such argument and value movement could
    be implicit in the behavior of the result function, and the
    given function might never be called.  Hence subsequent 
    redefinitions of the given function may have unpredictable 
    effects on the behavior of the result function.

Examples:

   (FUNCALL #'(LAMBDA (X Y) (CONS Y X)) 1 2)
   ==
   (FUNCALL (COMMUTE #'CONS) 1 2) 
   =>
   (2 . 1)


   (FUNCALL #'(LAMBDA (A B C D E F) (LIST C B A F E D)) 11 22 33 44 55 66)
   ==
   (FUNCALL (PERMUTE #'LIST #(2 1 0 5 4 3)) 10 11 12 13 14 15 16)
   =>
   '(12 11 10 16 15 14)


   (FUNCALL #'(LAMBDA (I J)
                (MULTIPLE-VALUE-BIND (Q R) 
                    (TRUNCATE I J)
                  (VALUES R Q)))
            10 3)
   ==
   (FUNCALL (PERMUTE #'TRUNCATE nil '(1 0)) 10 3)
   =>
   1
   3


∂28-Jun-88  0919	CL-Cleanup-mailer   
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 28 Jun 88  09:19:22 PDT
Date: 28 Jun 88 12:04:00 EDT
From: "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
Reply-To: "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>

I dislike the names OUTPUT-WIDTH and OUTPUT-POSITION for several reasons:

(1) It's ambiguous--the "position" could be for the whole stream output
so far instead of just the current line.
(2) VAX LISP already has exactly the functionality of OUTPUT-POSITION but
with the name LINE-POSITION.  VAX LISP also has a function called
RIGHT-MARGIN, which might be the same as OUTPUT-WIDTH, but I'm not sure.

Is the intent of OUTPUT-WIDTH to provide an indication to the pretty
printer of how far it knows it can print towards the side?  Is it meant
to be an absolute limit, in that printing beyond that point is undefined?
What should the OUTPUT-WIDTH of string streams be?  In VAX LISP, the
RIGHT-MARGIN of string streams is 80, but we allow users to override how
far the printer goes before inserting newlines.

A lesser name complaint is OUTPUT-SPACE might be better named WRITE-SPACE
to match the other WRITE-xxx functions.

			---Walter
------

∂28-Jun-88  0943	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Jun 88  09:43:29 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 425840; Tue 28-Jun-88 12:39:35 EDT
Date: Tue, 28 Jun 88 12:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 4)
To: vanroggen%bach.decnet@hudson.dec.com
cc: cl-cleanup@sail.stanford.edu, Dick@WHEATIES.AI.MIT.EDU
In-Reply-To: The message of 28 Jun 88 12:04 EDT from "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>
Message-ID: <880628123845.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

[Added Dick@WHEATIES.AI.MIT.EDU -- He's not on CL-Cleanup. Please
 remember to CC him explicitly. -kmp]

    Date: 28 Jun 88 12:04:00 EDT
    From: "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>

    I dislike the names OUTPUT-WIDTH and OUTPUT-POSITION for several reasons:

    (1) It's ambiguous--the "position" could be for the whole stream output
    so far instead of just the current line.
    (2) VAX LISP already has exactly the functionality of OUTPUT-POSITION but
    with the name LINE-POSITION.

LINE-POSITION is ok by me.

    VAX LISP also has a function called RIGHT-MARGIN, which might be the same
    as OUTPUT-WIDTH, but I'm not sure.

I tried not to call it anything with the word "right" in it for the sake of
anyone who might get ambitious and want to do a Hebrew implementation that
went right to left. The text descriptions probably mention left/right all
over the place, but I felt that was less critical and easier to work around
than having the language primitives themselves be biased.

LINE-WIDTH would be consistent and ok with me, though.

    Is the intent of OUTPUT-WIDTH to provide an indication to the pretty
    printer of how far it knows it can print towards the side?  Is it meant
    to be an absolute limit, in that printing beyond that point is undefined?

The point beyond which things get ugly or wrap or truncated or whatever.
Undefined, I guess.

    What should the OUTPUT-WIDTH of string streams be?

Someone proposed NIL, which seemed right to me.

    In VAX LISP, the RIGHT-MARGIN of string streams is 80, but we allow
    users to override how far the printer goes before inserting newlines.

It's so easy to do (OR (OUTPUT-WIDTH ...) 80) that I think it's a bad idea
to return a number if you don't mean it. If you do, it's hard to tell the
difference between an intentional and an accidental number. In the worst case,
there should be a DEFAULT argument, which defaults but can be overridden.
I doubt we'd all be able to agree on a number to which it should default,
though, so its value probably couldn't be relied upon portably.

    A lesser name complaint is OUTPUT-SPACE might be better named WRITE-SPACE
    to match the other WRITE-xxx functions.
			    ---Walter
    ------

WRITE-SPACE sounds ok to me.

∂28-Jun-88  1000	CL-Cleanup-mailer   
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 28 Jun 88  10:00:33 PDT
Date: 28 Jun 88 12:47:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

Could you specify the "technicality" referred to in the CURRENT PRACTICE
section (or leave out the argument)?

Either proposal is acceptable to me.

			---Walter
------

∂28-Jun-88  1041	CL-Cleanup-mailer 	Issue: STANDARD-OUTPUT-INITIAL-BINDING (version 5) 
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 28 Jun 88  10:41:05 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA01118; Tue, 28 Jun 88 13:38:40 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA08214; Tue, 28 Jun 88 13:42:36 EDT
Message-Id: <8806281742.AA08214@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: STANDARD-OUTPUT-INITIAL-BINDING (version 5)
Date: Tue, 28 Jun 88 13:42:30 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

Issue:         STANDARD-INPUT-INITIAL-BINDING
References:    Standard streams (pp. 327-329)
Category:      CHANGE
Edit history:  Version 1 by Pierson and Haflich 1/19/87
    	       Version 2 by Pierson 2/29/88
	       Version 3 by Pierson 5/23/88, per comments by Moon
               Version 4 by Pierson 5/26/88, clean up
    	       Version 5 by Pierson 6/28/88, simple design per Masinter
Status:        For Internal Discussion

Problem description:

CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*.  This requirement
hampers the integration of Common Lisp with many existing and
potential operating environments.

For example, a Unix implementation is currently unable to legally
support Unix standard error output even though Common Lisp defines
*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
to the same stream as *STANDARD-OUTPUT*.  A workstation environnment
which provides stream access to windows as an extension is currently
forbidden to make trace output appear in a separate window by default
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.

Proposal (STANDARD-INPUT-INITIAL-BINDING:CONTRACTS-AND-FUNCTIONS):

A Common Lisp implementation is required to provide the following
initial streams.  Each initial stream has a specific purpose as defined
in CLtL.

    *TERMINAL-IO*
    	Is always bound to a writable two-way stream.  It is legal for
	input from *TERMINAL-IO* to always return EOF.

    *STANDARD-INPUT*
    *STANDARD-OUTPUT*
    *ERROR-OUTPUT*
    *TRACE-OUTPUT*
    *QUERY-IO*
    *DEBUG-IO*
    	The initial bindings of these streams are undefined except
	that none of these streams may be synonym-streams for another
	one of these streams.  Any or all of these streams may be
	synonym streams for *TERMINAL-IO*.  Any or all of these
	streams may be synonyms for the same implementation-sepcific
	stream. 

Add the following inquiry functions to Common Lisp:

    STREAM-SAME-DESTINATION-P stream1 stream2	    	    [Function]

      Returns T if the Lisp can prove that the two streams send their
      output to the same "destination".  For example, this function
      would return true for two streams that output to Unix files iff
      the streams resulted either in output to the same file
      descriptor or in output to two different file descriptors for
      the same inode.

    STREAM-SAME-SOURCE-P stream1 stream2    	    	    [Function]

      Returns T if the Lisp can prove that the two streams receive
      their input from the same "source", where same source mans that
      input on one stream will change what the other stream would next
      read.  For example, this function would return true for two
      streams that read from Unix files iff the streams resulted in
      input from the same file descriptor but not if the streams
      resulted in in input from two different file descriptors for the
      same inode because then reading one stream would not change what
      the other stream saw.

    STREAM-INTERACTIVE-P stream	    	    	    	    [Function]

      Returns T if the Lisp can prove that the stream is interactive,
      where interactive means that the stream is a two way stream
      connected in such a way that output can result in a change in
      succeeding input.

Test Cases/Examples:

(PROGN
   (PRINT "Output" *STANDARD-OUTPUT*)
   (PRINT "Error" *STANDARD-ERROR*))

In current Common Lisp will write:
------
Output
Error
------

With proposal *might* write:
------
Output
------
and "Error" appears somewhere else.

(LET* ((IN1 (OPEN "foo" :DIRECTION :INPUT))
       (IN2 (OPEN "foo" :DIRECTION :INPUT))
       (OUT1 (OPEN "foo" :DIRECTION :OUTPUT))
       (OUT2 (OPEN "foo" :DIRECTION :OUTPUT))
       (STREAM1 (MAKE-TWO-WAY-STREAM IN1 OUT1))
       (STREAM2 (MAKE-TWO-WAY-STREAM IN2 OUT2)))
  (LIST (STREAM-SAME-DESTINATION-P STREAM1 OUT1)
        (STREAM-SAME-DESTINATION-P STREAM1 STREAM2)
	(STREAM-SAME-SOURCE-P STREAM1 IN1)
	(STREAM-SAME-SOURCE-P STREAM1 STREAM2)
	(STREAM-INTERACTIVE-P STREAM1)
	(STREAM-INTERACTIVE-P *TERMINAL-IO*)))

==> (T T T NIL NIL ?) ; *TERMINAL-IO* might or might not be interactive

Rationale:

This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output.  The inquiry functions answer questions that portable Lisp
programs can't answer on their own because the information is
frequently only maintained at an operating system level.

Current practice:

Lucid binds *TERMINAL-IO* to a special internal stream type.  Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output.  KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output.

Cost to Implementors:

All implementations will have to change to some degree but the changes
will probably be simple and localized.  All known implementations
already support the underlying streams required to implement this
proposal.  The new inquiry functions will require some work to write
correctly for each environment.

Cost to Users:

User code which depends on the strict binding hierarchy in CLtL may
have to change.  

Cost of non-Adoption:

It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.

Benefits:

Implementations will be more able to match their IO behavior to their
environment and their user's expectations.  Portable programs will
have more tools for reasoning about stream relationships.

Aesthetics:

Improved because this area becomes better defined.

Discussion:

Pitman was concerned that the initial version of this proposal didn't
provide a guaranteed way to get back the initial streams after
rebinding, e.g. *standard-io*.  The second version of this proposal
offered a solution to that problem which was generally considered too
complex.  This problem should now be solved.

Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
*DEBUG-IO*) should fail to work in a non-interactive environment where
nothing like a terminal exists.

Masinter notes that:
    ``In many multi-processing multi-window environments,
      the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
      differs for each process.''  

Masinter doesn't believe that STREAM-SAME-SOURCE-P is needed; Pierson
disagrees.

The definition of STREAM-INTERACTIVE-P is intentionally vague because
it is not reasonable for the Lisp to try and distinguish between, say,
a terminal connection to a human and a pseudo terminal connection to
another program.

Pierson supports STANDARD-OUTPUT-INITIAL-BINDING:CONTRACTS-AND-FUNCTIONS.

∂28-Jun-88  1100	CL-Cleanup-mailer 	Issue:  SYMBOL-MACROLET-UTILITY
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 28 Jun 88  10:58:14 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA10391; Tue, 28 Jun 88 10:58:00 PDT
Date: Tue, 28 Jun 88 10:58:00 PDT
Message-Id: <8806281758.AA10391@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: cl-cleanup@sail.stanford.edu
Subject: Issue:  SYMBOL-MACROLET-UTILITY

Status:		DRAFT
Issue:		SYMBOL-MACROLET-UTILITY
References:	X3J13 document 88-002R, Chapter 2, pp. 2-81f., 2-88f., 2-92f.
Category:	DELETION
Edit history:	21-Jun-88, Version 1 by Piazza

Problem Description:

    Anything expressible with SYMBOL-MACROLET could also be written with
    regular MACROLET, except that the macro symbol could not stand alone as an
    expression; it would have to be enclosed in parentheses.  The cost
    associated with implementing and maintaining the SYMBOL-MACROLET feature
    exceeds this incremental utility.

Proposal (SYMBOL-MACROLET:FLUSH):

    Remove SYMBOL-MACROLET (and WITH-ACCESSORS and WITH-SLOTS) from 88-002R.

Rationale:

    Flushing SYMBOL-MACROLET eliminates the cost of implementing and
    maintaining this feature, while MACROLET still provides most of
    SYMBOL-MACROLET's expressive power.

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

Current Practice:

    Portable Common Loops provides a code-walking implementation of
    SYMBOL-MACROLET as specified in 88-002R.

Cost to Implementors:

    Presumably few implementors have implemented SYMBOL-MACROLET, excepting
    the implementation provided by PCL.  If it is flushed from the language,
    no one will incur any implementation cost.

Cost to Users:

    Users will lose the expressive ability provided by SYMBOL-MACROLET,
    WITH-ACCESSORS, and WITH-SLOTS, and will have to make do with MACROLET.

Cost of Non-Adoption:

    Implementors must implement significant new functionality, adding to
    system size and language complexity.  (A separate proposal,
    SYMBOL-MACROLET-SEMANTICS, addresses problems with the currently
    specified semantics of SYMBOL-MACROLET.)

Benefits:

    SYMBOL-MACROLET:FLUSH reduces the implementation and maintenance costs for
    a Common Lisp implementation.  It also simplifies the language by
    eliminating the concept of a "symbol macro."

Aesthetics:

    There seem to be mixed feelings as to the desirability of SYMBOL-MACROLET
    as a construct in the language.  Some feel it hairs up the language while
    offering only trivial benefit beyond what is already provided through
    normal macros.  Others herald it as a important new language feature.

Discussion:

    As it was adopted by X3J13 as part of CLOS, there has been no formal
    discussion on the pros and cons SYMBOL-MACROLET on its own.

∂28-Jun-88  1137	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 5)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Jun 88  11:37:00 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 425928; Tue 28-Jun-88 14:34:26 EDT
Date: Tue, 28 Jun 88 14:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 5)
To: pierson%mist@MULTIMAX.ARPA
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8806281742.AA08214@mist.UUCP>
Message-ID: <880628143405.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

[Lest anyone become confused with all these issue names being so similar,
I note that the issue name is STANDARD-INPUT-INITIAL-BINDING as in the
body of your message, not STANDARD-OUTPUT-INITIAL-BINDING as in
your subject line.]

The proposal's wording is somewhat too vague for my taste. For example,
it first says htat the streams are as per CLtL and then it lists a bunch
of streams with commentary after some and not others. Does it mean to say
they are as per CLtL except as indicated? When indicated, does the info
augment or replace what is in CLtL?

There is no such thing as "returning EOF". I think you want to say that
*TERMINAL-IO* can be an empty stream. In the case that it is indeed empty,
it must behave like any other empty file (e.g., signalling an error when
the ERROR-P argument to the read function used is not NIL). I'm not sure
why the issue of an empty *TERMINAL-IO* input stream is addressed, but the
issue of a bit-sink output stream (output being discarded) is not addressed.
Is there a natural asymmetry that I'm not seeing?

The wording "The initial bindings of these streams are undefined" also
doesn't suffice. Streams don't have bindings, variables have bindings.
We must say that the stream variables are bound and that the initial
values of these stream variables are streams. It is the kind of stream
which they are which we can leave unspecified.

In the phrase "the same implemntation-specific stream", "same" has no
antecedent. I think you mean to be drawing some correspondence between
Lisp's *ERROR-OUTPUT* and some Unix/Vax/...-specific error output stream,
but you haven't said that clearly.

It is critical that it say somewhere that *TERMINAL-IO* may not initially
be a synonym stream to *STANDARD-OUTPUT*, *STANDARD-INPUT*. (Don't say that
it may not be a synonym stream at all; it's ok for it to be a synonym to
some internal stream, for example, it's just not ok for it to be a synonym
to one of the other stream variables.)

In place of STREAM-SAME-DESTINATION-P and STREAM-SAME-SOURCE-P, I happen to
prefer the following:

 STREAM-SOURCE-ID-LIST stream				[Function]
 STREAM-DESTINATION-ID-LIST stream			[Function]

 Returns a list of tokens which identify the source or destination of the
 stream at the current time. The tokens may be any lisp objects
 distinguishable using EQL. The only valid operation on the list of tokens
 are non-desctructive set operations.

 A synonym stream always returns the same id list as the stream to which
 it is indirected.

 An encapsulated stream (such as an echo stream or a broadcast stream)
 always returns at least the union of the tokens which would be returned
 by each of the encapsulated streams.

Your STREAM-SAME-DESTINATION-P and STREAM-SAME-SOURCE-P would be possible
to write using set intersection operators, but it would be possible to
detect some other useful relationships as well.

STREAM-INTERACTIVE-P is definitely a good idea, though I would have called
it INTERACTIVE-STREAM-P for symmetry with INPUT-STREAM-P.

You've got a reference to *STANDARD-ERROR* in there where I think you
want *ERROR-OUTPUT*.

Under "cost to implementors", why do you say all implementations will have
to change? Additions are not traditionally counted as changes. Separate
things out so you don't scare people reading casually. The basic structure
of the streams is not changed by this proposal. The restrictions on what
those streams can be is in fact weakened so that if anything, some 
non-conforming implementations might become conforming. Make this two
paragraphs, I think, separating the issue of the stream hierarchy from the
issue of the new streams.

[In fact, I would very much prefer to see this go as two separate
proposals since they're really separable issues. That way, if we get
bogged down in the set of functions operating on streams and that takes
longer to get voted in (or never gets voted in), we'll still have the
important changes to the stream bindings taken care of -- I don't expect
that issue to be nearly so controversial now that this proposal is simplified
as you have it here.]

I'll reserve specific statements of approval until I see a redraft or
replies to these comments. I think it's getting better, though.

∂28-Jun-88  1347	CL-Cleanup-mailer 	Issue: DOTTED-MACRO-FORMS (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Jun 88  13:47:49 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 426049; Tue 28-Jun-88 16:47:36 EDT
Date: Tue, 28 Jun 88 16:47 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DOTTED-MACRO-FORMS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: goldman@VAXA.ISI.EDU
References: The message of 14 Jun 88 17:32 EDT from goldman@VAXA.ISI.EDU
Message-ID: <880628164723.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        DOTTED-MACRO-FORMS
References:   forms (p54), lists and dotted lists (pp26-27),
	      DEFMACRO (p145), destructuring macro arguments (p146)
Category:     CLARIFICATION
Edit history: 28-Jun-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  CLtL is not explicit about whether macro forms may be dotted lists.

  p54 says that only certain forms are "meaningful": self-evaluating
   forms, symbols, and "lists".

  pp26-27 defines "list" and "dotted list". It goes on to say
   ``Throughout this manual, unless otherwise specified, it is an
   error to pass a dotted list to a function that is specified
   to require a list as an argument.''

  p146 states that in DEFMACRO destructuring, ``the argument
   form that would match the parameter is treated as a
   (possibly dotted) list, to be used as an argument forms list
   for satisfying the parameters in the embedded lambda list.''
   It goes on to say that ". var" is treated like "&rest var"
   at any level of the defmacro lambda-list.

Test Case:

  #1: (DEFMACRO MACW (&WHOLE W &REST R) `(- ,(CDR W)))
      (MACW . 1) => ??

  #2: (DEFMACRO MACR (&REST R) `(- ,R))
      (MACR . 1) => ??

  #3: (DEFMACRO MACX (&WHOLE W) `(- ,(CDR W)))
      (MACX . 1)

Current Practice:

  A. Some implementations bind W to (MACW . 1) in #1 and #3
   		      and bind R to 1 in #1 and #2.

  B. Some implementations bind W to (MACW . 1) in #3
		      and signal a syntax error in #1 and #2.

  C. Some implementations signal a syntax error in #1, #2, and #3.
     Symbolics Genera is such an implementation.

Proposal (DOTTED-MACRO-FORMS:EXPLICITLY-VAGUE):

  Clarify that it is an error for a macro form to be a dotted list.

  Rationale:
  
    Makes current practice explicit.
  
    Dotted lists are a possible symptom of program syntax error.
    Allowing implementations to check for this error may catch enough
    errors to justify the loss of program flexibility.

  Test Case:

    (MACW . 1) would be an error under this proposal.
    (MACR . 1) would be an error under this proposal.

  Cost to Implementors:
  
    None. This is merely a clarification of existing practice.
  
  Cost to Users:
  
    None. Users already can't rely on this behavior since it varies
    widely between implementations already.
  
Proposal (DOTTED-MACRO-FORMS:ALLOW):

  Clarify that if &REST occurs in a DEFMACRO lambda-list, it is permitted
  to match an atom or dotted list.

  Rationale:
  
    This is more flexible, and there is no efficiency or compatibility
    argument for not allowing it.
  
  Test Case:

    (MACW . 1) would reliably return -1 under this proposal.
    (MACR . 1) would reliably return -1 under this proposal.

  Cost to Implementors:
  
    Generally trivial. In most cases, some error checking might have to
    be removed or the algorithm used by the destructuring bind primitives
    might have to be modified slightly.
  
  Cost to Users:
  
    None. Users already can't rely on this behavior since it varies
    widely between implementations already.
  
Cost of Non-Adoption:

  Some users would continue to incorrectly believe the behavior
  was well-defined, and portability problems would result.

Benefits:

  People would know what to expect.

Aesthetics:

  Some people believe that dotted forms are ugly. Disallowing dotted forms
  would make them happier.

  Some people believe that there's no reason to unnecessarily restrict
  &WHOLE and/or &REST since there is no computational overhead and since
  the interpretation, if there is one at all, is pretty well agreed upon.

  Most importantly, however, we should be clear about what we intend or allow.
  If this is well-defined, we should say how.
  If this is not well-defined, we should say so.

Discussion:

  Goldman@VAXA.ISI.EDU raised this issue on Common-Lisp.
  Pitman converted Goldman's mail to this formal proposal, but some
  parts had to change in the process because of some apparent confusion
  in the original message about the number of arguments permitted when
  an &WHOLE variable is the only variable in a lambda list. Pitman
  believes you must write (&WHOLE W &REST IGNORE) in the case where
  Goldman as using just (&WHOLE W).

  Goldman's message seemed to suggest we adopt something similar to
  DOTTED-MACRO-FORMS:ALLOW.

  Pitman supports DOTTED-MACRO-FORMS:EXPLICITLY-VAGUE.

∂28-Jun-88  1353	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-UTILITY (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Jun 88  13:53:52 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 426053; Tue 28-Jun-88 16:53:18 EDT
Date: Tue, 28 Jun 88 16:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYMBOL-MACROLET-UTILITY (Version 1)
To: piazza%lisp.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8806281758.AA10391@decwrl.dec.com>
Message-ID: <880628165306.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

You called the proposal SYMBOL-MACROLET:FLUSH rather than
SYMBOL-MACROLET-UTILITY:FLUSH.

I personally oppose this proposal, but I of course have no opposition to
it's being presented to X3J13 for a vote.

This is a very complex issue, and I don't think it does it justice
to have such a terse presentation. I think both the specific reasons
why people dislike it (I believe there to be interesting semantic 
arguments which go beyond a desire for a minimalist language)
and the specific reasons why people think it's an important new language
feature need to be brought out.

Issues I'd like to see added at appropriate points (perhaps in the
discussion):

 * Current Practice

   Symbolics Cloe has both a code-walking version of a SYMBOL-MACROLET
   macro and compiler support for a SYMBOL-MACROLET special form.

 * Abstraction / Expressive Power

   Symbolics Cloe originally started with the macro version of
   SYMBOL-MACROLET, but found that the problem is that a code-walking
   SYMBOL-MACROLET destroys important abstraction information (like the
   fact that a particular TAGBODY/GO/BLOCK/RETURN configuration can be
   viewed as a PROG/PROG*/DO/DO*/...). There's no loss of computational
   power by doing the expansion, but there is a loss of perspicuity and
   it is not always easy for a compiler to put that information back in.

 * ONCE-ONLY

   If I recall correctly, some people have a worry about the relationship
   between SYMBOL-MACROLET and ONCE-ONLY (an interesting macro which
   occurs in several implementations). I haven't thought hard about this
   issue, but maybe someone who has can comment on it.

   Note that if users write their own code-walking SYMBOL-MACROLET, the
   wrong interaction may happen with a ONCE-ONLY primitive and there's
   no obvious way to work around the problem.

 * Need by users

   I've wanted this feature on a number of occassions to help me implement
   embedded languages. I bet others have, too. I think that wants to at 
   least get mentioned somewhere. When arbitrary users come up with the
   need for this facility, it is unreasonable (both in terms of code
   duplication and in terms of programmer expertise) to suppose that they
   can or should just go out and write a code-walker. Having written one
   myself, I must say I think that getting it right for even one 
   implementation is very hard and making it really portable is almost a
   pipe dream.

I think there other issues lurking here as well, but these should do as
starters to help flesh out this proposal.

∂28-Jun-88  1413	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Jun 88  14:13:36 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 426076; Tue 28-Jun-88 17:11:54 EDT
Date: Tue, 28 Jun 88 17:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-FORM (Version 1)
To: vanroggen%aitg.decnet@Hudson.DEC.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 28 Jun 88 12:47 EDT from "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Message-ID: <880628171141.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 28 Jun 88 12:47:00 EDT
    From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

    Could you specify the "technicality" referred to in the CURRENT PRACTICE
    section (or leave out the argument)?
    ...

CLtL specifies that "all" of the functions, macros, variables, etc. it
describes must be in the LISP package, but it doesn't say "all and
only". There's technically nothing keeping any implementation from
defining any of the variables as a function or macro, or any of the
functions as a variable.  Indeed, it doesn't say that other things can't
occur in the package besides those things described.

On my list of things to submit is a cleanup item clarifying this point.
I'll expand it in the next draft if it seems possible to do so concisely,
or perhaps move the remark to the discussion.

I just wanted to indicate somewhere that implementations like Symbolics
Genera which offer a LAMBDA macro are technically in conformance with
CLtL. I could do that in the discussion section, for example.

∂29-Jun-88  0931	CL-Cleanup-mailer   
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 29 Jun 88  09:31:52 PDT
Date: 29 Jun 88 12:27:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

Although VAX LISP happens to conform to DOTTED-MACRO-FORMS:ALLOW, I
think making dotted macro forms be an error is the right thing to do.
It's best to avoid blurring the data/code distinction too much, particularly
for people who are new to Lisp.

			---Walter
------

∂29-Jun-88  1013	CL-Cleanup-mailer   
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 29 Jun 88  10:13:03 PDT
Date: 29 Jun 88 13:04:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

What's the name of this issue?  STANDARD-OUTPUT-xxx or STANDARD-INPUT-xxx?

The problem description and proposal sound pretty good, except that I
don't understand the reason for the restriction that the predefined
streams other than *TERMINAL-IO* can't be synonym streams for each other.
Is it really necessary to disallow some implementation initially binding
*ERROR-OUTPUT* to a synonym stream for *DEBUG-IO*, for example?

I don't see the need for adding three more predicates.  Where is the
justification?  Most of the other sections of the proposal adequately
justify the need for loosening the initial binding requirements for
predefined streams, but not for the additional predicates.

Furthermore the descriptions of those predicates seem controversial.
What is STREAM-INTERACTIVE-P really trying to establish?  It seems
unlikely that output to a stream satisfying the predicate will really
change the following input--there aren't any such streams in Common
Lisp now, are there?  Or is it really trying to ask if there's someone
out there (human or not) that will provide (synchronously?) some input
after there's been some output?  Or is something like TWO-WAY-STREAM-P
sufficient?  Does this imply *TERMINAL-IO* must be a TWO-WAY-STREAM?
Or is it just asking if it's bidirectional?

I assume the use of *STANDARD-ERROR* is a typo in the Test Case.

			---Walter
------

∂29-Jun-88  1054	CL-Cleanup-mailer 	RE: Issue: SYMBOL-MACROLET-UTILITY (Version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 29 Jun 88  10:54:30 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA11621; Wed, 29 Jun 88 10:54:12 PDT
Date: Wed, 29 Jun 88 10:54:12 PDT
Message-Id: <8806291754.AA11621@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: DECWRL::KMP@stony-brook.scrc.symbolics.com
Subject: RE: Issue: SYMBOL-MACROLET-UTILITY (Version 1)


> You called the proposal SYMBOL-MACROLET:FLUSH rather than
> SYMBOL-MACROLET-UTILITY:FLUSH.

Oops.

 
>    Symbolics Cloe has both a code-walking version of a SYMBOL-MACROLET
>    macro and compiler support for a SYMBOL-MACROLET special form.

I'll add this to current practice.
 
>  * Abstraction / Expressive Power
>  
>    Symbolics Cloe originally started with the macro version of
>    SYMBOL-MACROLET, but found that the problem is that a code-walking
>    SYMBOL-MACROLET destroys important abstraction information (like the
>    fact that a particular TAGBODY/GO/BLOCK/RETURN configuration can be
>    viewed as a PROG/PROG*/DO/DO*/...). There's no loss of computational
>    power by doing the expansion, but there is a loss of perspicuity and
>    it is not always easy for a compiler to put that information back in.

This seems to have to do with whether SYMBOL-MACROLET should be a macro or a
special form.  I've written (but not yet distributed) a separate issue for
this, but I'd like to first see debate on the keep/flush question.  Note that,
as voted, CLOS specifies SYMBOL-MACROLET to be a macro, which implies code
walking.
 
>  * ONCE-ONLY
>  
>    If I recall correctly, some people have a worry about the relationship
>    between SYMBOL-MACROLET and ONCE-ONLY (an interesting macro which
>    occurs in several implementations). I haven't thought hard about this
>    issue, but maybe someone who has can comment on it.
>  
>    Note that if users write their own code-walking SYMBOL-MACROLET, the
>    wrong interaction may happen with a ONCE-ONLY primitive and there's
>    no obvious way to work around the problem.

Again, this is a code-walking-vs.-special-form issue.  I agree that, if
admitted to the language, SYMBOL-MACROLET should be a special form, not a
macro.  However, I also believe that that's a different question.
 
>  * Need by users
>
>    I've wanted this feature on a number of occassions to help me implement
>    embedded languages. I bet others have, too. I think that wants to at 
>    least get mentioned somewhere. When arbitrary users come up with the
>    need for this facility, it is unreasonable (both in terms of code
>    duplication and in terms of programmer expertise) to suppose that they
>    can or should just go out and write a code-walker. Having written one
>    myself, I must say I think that getting it right for even one 
>    implementation is very hard and making it really portable is almost a
>    pipe dream.
 
I'll include a mention about "embedded languages."  Of course, embedded
languages are not Common Lisp.  If one favors SYMBOL-MACROLET because it
supports embedded languages, then one "should" also favor souping up
readmacros to make READ a fully-general parser, for how else can we support
an embedded language like FORTRAN?

/JEP

∂29-Jun-88  1114	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Jun 88  11:14:15 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 426591; Wed 29-Jun-88 14:12:03 EDT
Date: Wed, 29 Jun 88 14:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)
To: vanroggen%aitg.decnet@hudson.dec.com
cc: cl-cleanup@sail.stanford.edu, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: The message of 29 Jun 88 13:04 EDT from "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Message-ID: <880629141141.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 29 Jun 88 13:04:00 EDT
    From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>

    ... I don't understand the reason for the restriction that the predefined
    streams other than *TERMINAL-IO* can't be synonym streams for each other.
    Is it really necessary to disallow some implementation initially binding
    *ERROR-OUTPUT* to a synonym stream for *DEBUG-IO*, for example?

I believe it is. People write programs that do things like:

 (LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
   ...)

but if *DEBUG-IO* is a synonym stream for a two-way stream which is made
up of synonym streams to *STANDARD-INPUT* and *STANDARD-OUTPUT*, then you
get a circular stream and massive lossage results.

Once the STREAM-CLASS-ACCESS issue goes through and it is possible to detect
a synonym stream, it will finally be possible to at least write cautious
code, but I would hate to think that every time I bound one of these streams
to another, that I must first check to make sure that a synonym circularity
is not being introduced.

As I recall, the current wording neither precludes synonym streams to two-way
streams which are synonym streams nor does it preclude later bindings of these
streams in ways that might introduce circularities, so I agree that the intent
of that text might want to be clarified.

Fyi, I've been screwed rather badly by doing the following seemingly harmless
thing:

 (LET ((*STANDARD-INPUT*  *TERMINAL-IO*)
       (*STANDARD-OUTPUT* *TERMINAL-IO*))
   ...)

on some implementations only to find out that *TERMINAL-IO* was implemented
as a two-way stream to synonym streams to *STANDARD-INPUT* and 
*STANDARD-OUTPUT*. The fireworks that result can be quite messy...

    I don't see the need for adding three more predicates...

Heh,heh. This is why I suggested this should be two proposals, Dan.

    Furthermore the descriptions of those predicates seem controversial.
    What is STREAM-INTERACTIVE-P really trying to establish?  ...

These are good points that I think should get nailed down. Among other things
to add to the list of things interactiveness might want to include are:
 * Should I prompt for input?
 * Is input editing (ie, rubout handling) something that should
   be dealt with?
 * Should I expect that READ-CHAR might hang waiting for input
   (vs returning an eof if no chars are available).

∂29-Jun-88  1116	CL-Cleanup-mailer 	Re: Issue: SYMBOL-MACROLET-UTILITY (Version 1)     
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 29 Jun 88  11:16:27 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA12398; Wed, 29 Jun 88 14:14:06 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA11107; Wed, 29 Jun 88 14:18:05 EDT
Message-Id: <8806291818.AA11107@mist.UUCP>
To: "piazza%lisp.DEC@decwrl.dec.com"@multimax (Jeffrey Piazza)
Cc: cl-cleanup%sail.stanford.edu@Multimax
Subject: Re: Issue: SYMBOL-MACROLET-UTILITY (Version 1) 
In-Reply-To: Your message of Wed, 29 Jun 88 10:54:12 -0700.
             <8806291754.AA11621@decwrl.dec.com> 
Date: Wed, 29 Jun 88 14:17:58 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    I'll include a mention about "embedded languages."  Of course, embedded
    languages are not Common Lisp.  If one favors SYMBOL-MACROLET because it
    supports embedded languages, then one "should" also favor souping up
    readmacros to make READ a fully-general parser, for how else can we support
    an embedded language like FORTRAN?

Embedding languages in Lisp is old and valuable tradition.  Therefore
it is reasonable to support a Lisp feature on the grounds that it
makes it easier to use Lisp in one of its traditional areas of
strength.

I would expect to support a language like FORTRAN or C by using READ
as a lexer and writing a separate parser.  For example, a Lisp version
of yacc *may* be appearing as free software soon (not from me).  I
assume that Kent was refering to custom embedded languages more on the
level of CLISP.

∂29-Jun-88  1136	CL-Cleanup-mailer 	Re: Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)   
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 29 Jun 88  11:35:43 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA12718; Wed, 29 Jun 88 14:33:28 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA11220; Wed, 29 Jun 88 14:37:26 EDT
Message-Id: <8806291837.AA11220@mist.UUCP>
To: Kent M Pitman <KMP%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5) 
In-Reply-To: Your message of Wed, 29 Jun 88 14:11:00 -0400.
             <880629141141.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> 
Date: Wed, 29 Jun 88 14:37:21 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    As I recall, the current wording neither precludes synonym streams
    to two-way streams which are synonym streams nor does it preclude
    later bindings of these streams in ways that might introduce
    circularities, so I agree that the intent of that text might want
    to be clarified.
    
I'll try to clean this up.  The intent is that the streams in question
can all be synonyms for the same internal stream, but not for each
other, two-way-streams for each other, etc.

        I don't see the need for adding three more predicates...
    
    Heh,heh. This is why I suggested this should be two proposals, Dan.
    
I thought this might happen, but decided to wait and see.  The next
version will have two proposals if that's what people want.  If anyone
strongly opposes two proposals, speak now or...

        Furthermore the descriptions of those predicates seem controversial.
        What is STREAM-INTERACTIVE-P really trying to establish?  ...
    
    These are good points that I think should get nailed down. Among
    other things to add to the list of things interactiveness might
    want to include are:
     * Should I prompt for input?
     * Is input editing (ie, rubout handling) something that should
       be dealt with?
     * Should I expect that READ-CHAR might hang waiting for input
       (vs returning an eof if no chars are available).
    
Good questions.  I'll really rework this one.  I thinks that
STREAM-INTERACTIVE-P is the shakiest of the new predicates just
because it's the hardest to nail down.

∂29-Jun-88  1413	CL-Cleanup-mailer 	Re: Issue:  SYMBOL-MACROLET-UTILITY 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Jun 88  14:13:11 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 29 JUN 88 13:46:28 PDT
Date: Wed, 29 Jun 88 13:44 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue:  SYMBOL-MACROLET-UTILITY
To: Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>
cc: cl-cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-2.text.newest
In-Reply-To: <8806281758.AA10391@decwrl.dec.com>
Message-ID: <19880629204455.4.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no


    Date: Tue, 28 Jun 88 10:58:00 PDT
    From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)

    Status:		DRAFT
    Issue:		SYMBOL-MACROLET-UTILITY
    References:	X3J13 document 88-002R, Chapter 2, pp. 2-81f., 2-88f., 2-92f.
    Category:	DELETION
    Edit history:	21-Jun-88, Version 1 by Piazza

    Problem Description:

	Anything expressible with SYMBOL-MACROLET could also be written with
	regular MACROLET, except that the macro symbol could not stand alone as an
	expression; it would have to be enclosed in parentheses.  The cost
	associated with implementing and maintaining the SYMBOL-MACROLET feature
	exceeds this incremental utility.

This isn't a problem description, it is a statement of opinion.  A
problem description would say something like:

  The symbol-macrolet utitily introduced with CLOS has some semantic
  problems.  <discussion of these problems here>.  These problems may
  cause problems with some existing code <extension of previous
  discussion here>.

    Proposal (SYMBOL-MACROLET:FLUSH):

	Remove SYMBOL-MACROLET (and WITH-ACCESSORS and WITH-SLOTS) from 88-002R.

    Rationale:

	Flushing SYMBOL-MACROLET eliminates the cost of implementing and
	maintaining this feature, while MACROLET still provides most of
	SYMBOL-MACROLET's expressive power.

The explanation of the hack of using the symbol as what looks like a
no arguments function should be presented here.  There needs to be a
discussion of the fact that this would work much better in a Lisp-1
than a Lisp-2.

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

    Current Practice:

	Portable Common Loops provides a code-walking implementation of
	SYMBOL-MACROLET as specified in 88-002R.

    Cost to Implementors:

	Presumably few implementors have implemented SYMBOL-MACROLET, excepting
	the implementation provided by PCL.  If it is flushed from the language,
	no one will incur any implementation cost.

    Cost to Users:

	Users will lose the expressive ability provided by SYMBOL-MACROLET,
	WITH-ACCESSORS, and WITH-SLOTS, and will have to make do with
        MACROLET.

Another cost is that they won't be able to overload names to mean both
a real function and one of these hack macros.  For example:

(defclass foo () (car cdr))

(defun describe-foo (foo)
  (macrolet ((car () (slot-value foo 'car))
	     (cdr () (slot-value foo 'cdr)))
    ...
    Can't use normal car and cdr in here
    ...))

Of course this is something that Scheme programmers are used to dealing
with.  But Common Lisp programmers are not.  The potential for this
seriously aggravating the existing problem with macro expansions
capturing the wrong lexical context is huge.

    Cost of Non-Adoption:

	Implementors must implement significant new functionality, adding to
	system size and language complexity.  (A separate proposal,
	SYMBOL-MACROLET-SEMANTICS, addresses problems with the currently
	specified semantics of SYMBOL-MACROLET.)

I am not sure I buy this.  For one, there is already an implementation
of it in PCL.  For another, any exiting compiler must already have the
right stuff in it to do this.  

If you insist on doing an entirely custom CLOS, the work required to do
this part of it is very small compared to the work required to do the
rest of it.

    Benefits:

	SYMBOL-MACROLET:FLUSH reduces the implementation and maintenance costs for
	a Common Lisp implementation.  It also simplifies the language by
	eliminating the concept of a "symbol macro."

    Aesthetics:

	There seem to be mixed feelings as to the desirability of SYMBOL-MACROLET
	as a construct in the language.  Some feel it hairs up the language while
	offering only trivial benefit beyond what is already provided through
	normal macros.  Others herald it as a important new language feature.

    Discussion:

	As it was adopted by X3J13 as part of CLOS, there has been no formal
	discussion on the pros and cons SYMBOL-MACROLET on its own.

That discussion should appear in this part of the proposal.
-------

∂29-Jun-88  2336	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Jun 88  23:36:41 PDT
Received: from Burger.ms by ArpaGateway.ms ; 29 JUN 88 23:33:15 PDT
From: masinter.pa@Xerox.COM
Date: 29 Jun 88 23:32:43 PDT
Subject: Re: Issue: STREAM-INFO (Version 4)
In-reply-to: KMP@STONY-BROOK.SCRC.Symbolics.COM's message of Mon, 27 Jun 88
 10:48 EDT, <880627104822.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.pa@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU,
 Dick@WHEATIES.AI.MIT.EDU
Message-ID: <880629-233315-4002@Xerox>

How 'bout just making it explicit that this things are intentionally left
undefined, with some of the reasons you gave?

I'm a little leary of adding a function where the requirements on the output
values are not spelled out. Is the width of "froboznick" guaranteed to be the
sum of the widths of "frob" and "oznick"? Greater than the width of "frob"? Of
"foo"? What about kerning?

If we can't guarantee anything about these functions, can programmers really
write portable programs? Or would a hack with #+ and #- be more honest?

∂30-Jun-88  0004	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Jun 88  00:04:41 PDT
Received: from Burger.ms by ArpaGateway.ms ; 29 JUN 88 23:56:06 PDT
From: masinter.pa@Xerox.COM
Date: 29 Jun 88 23:55:32 PDT
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)
In-reply-to: edsel!jlm@labrea.stanford.edu's message of Mon, 27 Jun 88 12:29:15
 PDT, <8806271929.AA00551@bhopal.lucid.com>
To: Jim McDonald <edsel!jlm@labrea.stanford.edu>
cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
Message-ID: <880629-235606-4020@Xerox>

I'd rather see a portable implementation circulated, frankly.

Why should these be in the standard?

∂30-Jun-88  0623	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 30 Jun 88  06:23:38 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA18500; Thu, 30 Jun 88 06:23:24 PDT
Date: Thu, 30 Jun 88 06:23:24 PDT
Message-Id: <8806301323.AA18500@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)


  From: masinter.pa@Xerox.COM
  Date: 29 Jun 88 23:55:32 PDT

  I'd rather see a portable implementation circulated, frankly.
  
  Why should these be in the standard?

To allow and encourage compiler optimizations that would otherwise
be difficult to do.

			---Walter

∂30-Jun-88  0735	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Jun 88  07:35:14 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 427060; Thu 30-Jun-88 10:34:33 EDT
Date: Thu, 30 Jun 88 10:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: STREAM-INFO (Version 4)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU,
    Dick@WHEATIES.AI.MIT.EDU
In-Reply-To: <880629-233315-4002@Xerox>
Message-ID: <880630103421.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: 29 Jun 88 23:32:43 PDT
    From: masinter.pa@Xerox.COM

    How 'bout just making it explicit that this things are intentionally left
    undefined, with some of the reasons you gave?

    I'm a little leary of adding a function where the requirements on the output
    values are not spelled out. Is the width of "froboznick" guaranteed to be the
    sum of the widths of "frob" and "oznick"? Greater than the width of "frob"? Of
    "foo"? What about kerning?

Dick spelled out the requirement. He doesn't need an algebra on these values.
The only need he has, and it's quite legitimate, is to ask "If I were to output
this, where would I end up." If there's something that will, in the same units,
tell him where the margin is, he can at least know if he's passing an interesting
boundary.

Kerning is not really relevant. Either the implementation looks at kerning when
deciding if a line is too long or it doesn't. The thing which returns the margin
position and the thing which returns the string width can easily conspire to do
the right thing without prejudice to whether kerning is involved.

Dick could have just as well asked for a primitive that would have said
(OUTPUT-FITS-P string stream) and returns T or NIL saying whether the string will
fit on the stream without running into the margin, but that would have been so
limited to his application that it would have served no useful extension purposes
in implementations that did want to extend it.

    If we can't guarantee anything about these functions, can programmers really
    write portable programs? Or would a hack with #+ and #- be more honest?

The issue is not honesty. The issue is one of codifying existing
practice. Dick Waters has done a lot of really interesting work on
pretty printers over the years. That work has been of tremendous benefit
to the Lisp community.  In Maclisp, he could essentially tell where the
end of the line was. We took away that capability in Common Lisp.  In
Common Lisp, you can't even clear the screen. I personally think that
was ridulous, and I'm surprised that the user community put up with it.
But the world was more complicated with fancy displays and fancy fonts
and all, and people were tolerant for a while.

But we've had our time to play and it's really time we came up with
something useful so people can get on with their work if at all
possible.  The set of primitives proposed is a subset of what is in use
on a major Lisp workstation and it has been demonstrated to be useful.
If it has problems to do with kerning (things have to be rounded off),
output will look no stupider than it will look if we don't allow people
to have pretty printed output at all. More likely, it will work just
fine because most applications are very fault tolerant -- in the worst
case, you might get some line wraparound and yucky looking typeout. But
you'll get line wraparound a LOT more in portable programs if you offer
people no way at all to detect the edge of the line.  We should just warn
people that the process is heuristic and people who are building weapons
systems or real time medical systems can avoid using it.

Common Lisp is not an exercise in doing everything right the first time.
It is an exercise in trying to satisfy the commercial needs of a lot of
Lisp users for the next few years. My condition system has its problems,
too, but the important point in both cases is that it is an improvement
over what is there if you don't have it. Sometimes when you don't fully
understand an issue, you just have to go with your best guess and be
prepared to have problems result.  As embarrassing as it is to have your
mistakes noticed later, it's sometimes better than not taking any action
at all.  And after using for a few years, you'll have a user community
who can make informed decisions about whether they like what they got
and what they want next.  If you don't offer them anything at all, then
in five more years you'll have no one who's any more informed on the
issues than you have now and you'll end up having to make the same
arbitrary decision as you're making now.

Also, this problem is not like characters or pathnames where we are
forcing a representation. If necessary, a particular vendor with special
needs can have these primitives can work completely independently of how
the rest of system represents width, position, etc.  on the screen -- or
it can just return NIL all over the place saying it's not willing to
play the game.

∂30-Jun-88  0803	CL-Cleanup-mailer 	EQUAL 
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 30 Jun 88  08:03:23 PDT
Received: by labrea.stanford.edu; Thu, 30 Jun 88 08:03:22 PDT
Received: from bhopal.lucid.com by edsel id AA14691g; Wed, 29 Jun 88 18:44:42 PDT
Received: by bhopal id AA15550g; Wed, 29 Jun 88 18:50:58 PDT
Date: Wed, 29 Jun 88 18:50:58 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806300150.AA15550@bhopal.lucid.com>
To: edsel!jlm@labrea.stanford.edu
Cc: common-lisp@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Jim McDonald's message of Fri, 24 Jun 88 16:40:01 EST <8806242339.AA18154@bhopal.lucid.com>
Subject: EQUAL


    Date: Fri, 24 Jun 88 16:40:01 EST
    From: Jim McDonald <jlm>

    My concern about having EQUAL descend structures and arrays is that
    they are much more likely than lists to be circular.
    ...
    As a rule of thumb, I'd bet that less than .0001% of all lists are
    circular, and that less than 1% of all arrays are circular, but only
    that less than 30% of all structures are circular.  

Probabilities can be very misleading here -- for any given application,
the probability is typically either 0 or 1.  And even for those cases
that do utilize circular stucture (I'm including lists here), the 
relevance to the EQUAL question is entirely moot if they are never
given as arguments to EQUAL.  One would surely suspect that to be the
case for the many programs that deal in circular lists!


-- JonL  --

∂30-Jun-88  0809	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Jun 88  08:09:10 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 427086; Thu 30-Jun-88 11:08:20 EDT
Date: Thu, 30 Jun 88 11:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)
To: Masinter.PA@Xerox.COM, vanroggen%aitg.DEC@decwrl.dec.com,
    piazza%lisp.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8806301323.AA18500@decwrl.dec.com>,
             The message of 29 Jun 88 23:55 PDT from masinter.pa@Xerox.COM,
             <8806291754.AA11621@decwrl.dec.com>
Message-ID: <880630110812.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

    Date: Thu, 30 Jun 88 06:23:24 PDT
    From: vanroggen%aitg.DEC@decwrl.dec.com

      From: masinter.pa@Xerox.COM
      Date: 29 Jun 88 23:55:32 PDT

      I'd rather see a portable implementation circulated, frankly.
  
      Why should these be in the standard?

    To allow and encourage compiler optimizations that would otherwise
    be difficult to do.

Right. These are easy to write correctly in a portable way, but the
portable way is not nearly as efficient as what coudl be non-portably
provided... And I doubt anyone would spend any effort to optimize them
if they weren't part of the core language.

But as alluded to in the proposal, this would also get us a foothold
from which to be able to suggest flushing the -IF-NOT functions and
:TEST-NOT keywords. Those functions provide not only clutter in the
form of size, but it's a pain to try to coherently explain
 - the default value of the :TEST and :TEST-NOT parameters, which
   cannot be independent
 - the effect of providing both the :TEST and :TEST-NOT
I'll be submitting a proposal to make that cleanup, and that proposal
might fly on its own, but it would go better (I think) if it had support
from a reasonably concise alternative mechanism (particularly COMPLEMENT).

Also, I bet the reason there are not :TEST-AND and :TEST-OR arguments 
is not that ANDing and ORing predicates is less useful than NOTing them,
but rather that NOT takes one argument and the rest take more and no one
wanted to worry about :TEST-AND '(FOO BAR) or :TEST-AND (LIST #'FOO #'BAR)
which would have had to cons a needless list. This proposal provides a
way to specify things so that no consing is necessary in many cases
-- :TEST (CONJOIN #'FOO #'BAR) -- Stack consing might occur, or inlining
might completely unroll the need for a list at all...

Aside to Jeffrey, I like COMMUTE as an addition to the set of things I
had listed, by the way, but I didn't really like PERMUTE as described.
It is a nice idea conceptually but the fact that its permuation argument
is evaluated means that it can be opaque to such optimization when the
argument is not constant, and the result may be suprisingly less
efficient than the programmer may expect in those cases.

∂30-Jun-88  0927	CL-Cleanup-mailer 	various DEFSTRUCT issues  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 30 Jun 88  09:26:34 PDT
Return-Path: <barmar@Think.COM>
Received: from brigit.think.com by Think.COM; Thu, 30 Jun 88 12:24:23 EDT
Received: from OCCAM.THINK.COM by brigit.think.com; Thu, 30 Jun 88 00:12:59 EDT
Date: Thu, 30 Jun 88 00:10 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: various DEFSTRUCT issues
To: cl-cleanup@sail.stanford.edu
Message-Id: <19880630041044.9.BARMAR@OCCAM.THINK.COM>

At the X3J13 meeting there was an issue about DEFSTRUCT and duplicated
slot names.  This has caused me to think a bit about some other related
problems with DEFSTRUCT.  I haven't really given a whole lot of thought
to these, but I wanted to get them out to some other people before I
forgot.

Issue 1: Slots with STRING-EQUAL names

This is the one that I briefly mentioned at the meeting.  Consider the
following:

(in-package 'foo)
(defstruct struct
  slot1
  bar:slot1)

The problem with this is that the package of the slot name is generally
not used by DEFSTRUCT.  The constructor takes keyword arguments, so it
would be ambiguous which slot is being initialized by (make-struct
:slot1 <val>).  And accessor functions are interned in the package that
is current when the DEFSTRUCT is being expanded, so it would try to
define FOO::STRUCT-SLOT1 as an accessor for both slots.

In the case of a single structure definition, like above, it would
probably be OK to specify that string-equal slot names are not
permitted.  However, they are more likely to occur when :INCLUDEing a
structure in a different package:

(in-package 'foo)
(defstruct foo-struct
  slot1)

and in a different file:

(in-package 'bar)
(defstruct (bar-struct (:include foo:foo-struct))
  slot1)

In this case you don't have a problem with the accessors, because they
are FOO::FOO-STRUCT-SLOT1 and BAR::BAR-STRUCT-SLOT1.  However, you still
have a problem with MAKE-BAR-STRUCT, because of the keyword argument.

I think the solution to this is to make use of the extension to keyword
argument syntax that was done for CLOS.  The keyword arguments to
structure constructors would be the actual name of the argument.
However, for back compatibility, we can also specify that :keywords are
also accepted (but we should deprecate this use).  However, it is an error
to use the :keyword version if the structure contains two string-equal
slot names.

Additionally, the specification of the default printed representation of
structures must be tightened, as it currently allows the slot names to
be printed in any package.  They should be printed with their correct
package prefixes.

Existing practice: Sun Common Lisp 2.0.3 (Lucid, I believe) detects
attempts to define structures with string-equal slots at defstruct
expansion time, whether the conflicting slot comes from inheritance or
not.  Symbolics Common Lisp in Genera 7.2 and Kyoto Common Lisp June 3,
1987 don't notice the conflict.  In SCL, (make-bar-struct :slot1 <val>)
creates a structure in which both slots contain <val>); in KCL, the
FOO::SLOT1 slot contains VAL, while the BAR::SLOT1 slot contains NIL.
Regarding printed reps, Symbolics currently prints all the slot names as
:keywords; KCL simply PRIN1's the slot name symbols, so it corresponds
to my proposal; Sun CL uses no package prefixes at all.

Issue 2: Redefining structures

CLOS specifies in greate detail what happens when classes are redefined.
What happens when structures are redefined?  Does CLtL discuss this
anywhere?  Assuming existing practice is what I think it is, we should
probably specify that it is an error to use a structure accessor or
copier on a structure that was created prior to the redefinition; this
may imply that it is an error to try to print such a structure, as the
print function might use an accessor.

But what about redefining :INCLUDEd structures?  What does this do:

(defstruct foo
  a b)

(defstruct (bar (:include foo))
  c)

(defstruct foo
  b a d)

How does this redefinition of FOO affect the BAR structure?  In the very
least, I think my above statement should be taken to imply that any BARs
created before FOO is redefined are no longer accessible using the FOO-
accessors.  But what about new structures created by MAKE-BAR after the
redefinition?  In all three implementations I tried, the redefinition
had absolutely no effect on MAKE-BAR, nor on the printing of BAR
structures.  The only anomoly is that (foo-b (make-bar :a 1 :b 2)) now
returns 1; all three apparently implement structures internally as
vectors, and accessors are simply AREFs.  One could imagine, however, an
implementation that used property lists or alists internally, so that
FOO-B would continue to return the B slot of BAR structures.

So, we could say that after redefining a structure, it is an error to
use any of its accessors on structures that :INCLUDE that structure but
which have not been reevaluated/recompiled.  (Actually, that wording is
pretty attrocious.)  And after the :INCLUDEing structure is redefined,
the :INCLUDEe's accessors may only be used on new instances.

                                                barmar

∂30-Jun-88  1145	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
Received: from rice-chex.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Jun 88  11:45:12 PDT
Received: by rice-chex.ai.mit.edu; Thu, 30 Jun 88 14:47:06 EDT
Date: Thu, 30 Jun 88 14:47:06 EDT
From: dick@wheaties.ai.mit.edu (Richard C. Waters)
Message-Id: <8806301847.AA07038@rice-chex.ai.mit.edu>
To: masinter.pa@xerox.com
In-Reply-To: masinter.pa@xerox.com's message of 29 Jun 88 23:32:43 PDT <880629-233315-4002@Xerox>
Subject: Issue: STREAM-INFO (Version 4)
Cc: dick@wheaties.ai.mit.edu, CL-Cleanup@sail.stanford.edu


  How 'bout just making it explicit that these things are intentionally left
  undefined, with some of the reasons you gave?

  I'm a little leary of adding a function where the requirements on
  the output values are not spelled out. Is the width of "froboznick"
  guaranteed to be the sum of the widths of "frob" and "oznick"?
  Greater than the width of "frob"? Of "foo"? What about kerning?

I think that there are some very specific things that we can say.  The
key thing is that we have to make it clear exactly what is being
specified.  In particular, the actual numerical values are
implementation specific and do not matter much.  However, there are
several key RELATIVE properties which are the whole point.

In the following, suppose that N is a positive integer, X and Y are
strings, and S is a stream that fully supports all four functions
OUTPUT-WIDTH, OUTPUT-POSITION, STRING-WIDTH, OUTPUT-SPACE; i.e., NIL is
never returned when any of these functions is called on S.

First, there are three minimal properties of OUTPUT-POSITION.

(1) (NOT (MINUSP (OUTPUT-POSITION S)))

(2) (ZEROP (OUTPUT-POSITION (PROGN (TERPRI S) S)))

(3) If something is at an output position of N on one line, and
something else is at an output position of N on another line, and
assuming that wraparound truncation etc. have not occured on either
line (see (5) below), then the two things are lined up vertically one
under the other.

Second, there are two properties that define
STRING-WIDTH and OUTPUT-SPACE in terms of OUTPUT-POSITION.

(3) (= (+ (OUTPUT-POSITION S) (STRING-WIDTH X S))
       (OUTPUT-POSITION (PROGN (WRITE-STRING X S) S)))

(4) (= (+ (OUTPUT-POSITION S) N)
       (OUTPUT-POSITION (PROGN (OUTPUT-SPACE N S) S)))
and OUTPUT-SPACE has no effect on S other than introducing blank space
that changes the output position.

For the following properties it must be assumed that X and Y consist
solely of standard characters as defined on CLTL pp20-21 and that X
and Y do not contain any #\newline characters.

The following property defines the meaning of OUTPUT-WIDTH.

(5) Assuming that one has just done (TERPRI S),
If (< (STRING-WIDTH X S) (OUTPUT-WIDTH S))
then (WRITE-STRING X S) is guaranteed to output the string on one line
without any truncation or wraparound.
  [If the condition above is not satisfied, then the exact result of
the output is not specified.  However, It is assumed that each
implementation will do something reasonable, e.g., use wraparound.  It
might also be the case that the output width was pessimistic and that
the string might fit on the end of the line.  The point of
OUTPUT-WIDTH is that it returns a guaranteed safe width.]

  This property must hold no matter what characters are in X as long
as none of these characters cause a reduction in output position.
I.e., it is alright for X to contain tabs and many other weird
characters, but the property may be violated if X contains newlines or
backspaces.

(6) (= (STRING-WIDTH (CONCATENATE 'STRING X Y) S)
       (+ (STRING-WIDTH X S) (STRING-WIDTH Y S)))

  This property is violated for many kinds of nonstandard characters,
notably tabs and newlines.  It could also fail if the strings had
ligatures or font change characters or other wierd things.

Nevertheless, this property is very useful.  The efficiency of my
pretty printer is significantly improved by assuming that this
property holds.

			Dick Waters

PS  I agree with KMPs basic comment that although this is indeed a
fuzzy area, it is better to get information which may in many
situations only be approximate than not to be able to get any
information at all.

∂30-Jun-88  1557	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 4)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Jun 88  15:57:46 PDT
Received: from Burger.ms by ArpaGateway.ms ; 30 JUN 88 15:57:23 PDT
From: masinter.pa@Xerox.COM
Date: 30 Jun 88 15:56:48 PDT
Subject: Re: Issue: STREAM-INFO (Version 4)
In-reply-to: KMP@STONY-BROOK.SCRC.Symbolics.COM's message of Thu, 30 Jun 88
 10:34 EDT, <880630103421.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU,
 Dick@WHEATIES.AI.MIT.EDU
Message-ID: <880630-155723-5604@Xerox>

I guess I wasn't clear. I understand your point, and see that it is probably not
a good idea to be more explicit about what the functions you propose should do.
However, I think the proposal needs to be really explicit that there are no such
contracts, lest users mistakenly assume there are.

∂30-Jun-88  1557	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COMPOSITION (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Jun 88  15:57:41 PDT
Received: from Burger.ms by ArpaGateway.ms ; 30 JUN 88 15:51:33 PDT
From: masinter.pa@Xerox.COM
Date: 30 Jun 88 15:48:42 PDT
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)
In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Thu, 30 Jun 88
 06:23:24 PDT, <8806301323.AA18500@decwrl.dec.com>
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880630-155133-5578@Xerox>

Perhaps you could indicate the kinds of compiler optimizations that might be
useful? Would people use these functions if the compiler didn't optimize them?
Souldn'sShouldn't the mythical compiler be able to do as well given
INLINE-proclaimed portable definitions?

∂01-Jul-88  0701	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Jul 88  07:01:11 PDT
Return-Path: <gls@Think.COM>
Received: from brigit.think.com by Think.COM; Fri, 1 Jul 88 10:00:24 EDT
Received: by brigit.think.com; Fri, 1 Jul 88 09:59:34 EDT
Date: Fri, 1 Jul 88 09:59:34 EDT
From: gls@Think.COM
Message-Id: <8807011359.AA10552@brigit.think.com>
To: dick@wheaties.ai.mit.edu
Cc: masinter.pa@xerox.com, dick@wheaties.ai.mit.edu,
        CL-Cleanup@sail.stanford.edu
In-Reply-To: Richard C. Waters's message of Thu, 30 Jun 88 14:47:06 EDT <8806301847.AA07038@rice-chex.ai.mit.edu>
Subject: Issue: STREAM-INFO (Version 4)

Dick,
  Does your pretty printer depend crucially on the equality in
properties (3) and (6), or can they be relaxed to inequalities

   (3) (<= (+ (OUTPUT-POSITION S) (STRING-WIDTH X S))
	   (OUTPUT-POSITION (PROGN (WRITE-STRING X S) S)))

   (6) (<= (STRING-WIDTH (CONCATENATE 'STRING X Y) S)
	   (+ (STRING-WIDTH X S) (STRING-WIDTH Y S)))

?

--Guy

∂02-Jul-88  1158	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-CASE (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jul 88  11:58:08 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 428071; Fri 1-Jul-88 19:57:18 EDT
Date: Fri, 1 Jul 88 19:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-CASE (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880701195711.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        PATHNAME-COMPONENT-CASE
References:   Pathnames (pp410-413),
	      MAKE-PATHNAME (p416),
	      PATHNAME-HOST (p417),
	      PATHNAME-DEVICE (p417),
	      PATHNAME-DIRECTORY (p417),
	      PATHNAME-NAME (p417),
	      PATHNAME-TYPE (p417)
Category:     CHANGE
Edit history: 1-Jul-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  Issues of case in pathnames are a major source of problems.

  In some file systems, the canonical case is lowercase, in some
  uppercase, in some mixed.

  In some file systems, case matters, in others it does not.

  (NAMESTRING (MAKE-PATHNAME :NAME "FOO" :TYPE "LISP"))
  will produce an `ugly' file name like "FOO.LISP" in many (but not all)
  Common Lisp implementations talking to Unix, for example.

  (NAMESTRING (MAKE-PATHNAME :NAME "foo" :TYPE "lisp"))
  might produce an `ugly' file name like "↑Vf↑Vo↑Vo.↑Vl↑Vi↑Vs↑Vp"
  in a Common Lisp implementation talking to a Tops-20.

  Problems like this make it difficult to use MAKE-PATHNAME for much of
  anything without corrective (non-portable) code.

  Other problems occur in merging because doing
   (NAMESTRING (MERGE-PATHNAMES (MAKE-PATHNAME :HOST "MY-TOPS-20" :NAME "FOO")
	                        (PARSE-NAMESTRING "MY-UNIX:x.lisp")))
  should probably return "MY-TOPS-20:FOO.LISP" but in fact might return
  "MY-TOPS-20:FOO.↑Vl↑Vi↑Vs↑Vp" in some implementations.

  Problems like this make it difficult to use any merging primitives for
  much of anything without corrective (non-portable code).

Proposal (PATHNAME-COMPONENT-CASE:CANONICALIZE):

  Designate a treatment for case in pathname components which is
  distinct from the treatment of case in the namestrings. The treatment
  should be invariant across operating systems.

  If a string given to MAKE-PATHNAME, or returned by any of the
  PATHNAME-xxx accessor operations, is all uppercase, it is said to
  designate a name in the system's "canonical case".

  If a string given to MAKE-PATHNAME, or returned by any of the
  PATHNAME-xxx accessor operations, is all lowercase, it is said to
  designate a name in the system's "anticanonical case".

  If a string given to MAKE-PATHNAME, or returned by any of the
  PATHNAME-xxx accessor operations, is mixed case, it is said
  designate a name in exactly the indicated case.

  Functions such as PARSE-NAMESTRING and NAMESTRING which convert
  from or to native host syntax will perform any necessary conversions
  from internal syntax.

  Note: In fact, this proposal does not require an implementation to
  change its internal representation. It only requires the CL-defined
  accessors to behave as if the internal representation had been changed.
  Whether the actual internal representation is changed is still up to an
  implementation. A consequence of this is that if pathnames print 
  in a way that shows the components individually (such as #S), they
  are not constrained to print the components in any particular case;
  they are constrained only to have definite syntax conventions and to
  be able to invert those conventions at the appropriate time. Any change
  to the way pathnames print is beyond the scope of this proposal.

Test Case:

  (PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp"))    => "FOO"
  (PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"

Rationale:

  This does not solve the whole pathname problem, but it does improve
  the situation for a clearly defined set of very common problems.

Current Practice:

  Symbolics Genera implements this behavior.

Cost to Implementors:

  While this proposal is compatible with CLtL, it may not be compatible with
  the implementations of CLtL which some implementations have chosen.

  It is possible to isolate the forced changes to the referenced functions
  (MAKE-PATHNAME and the PATHNAME-xxx accessors). Existing functions can be
  renamed, and new functions with the same name can be introduced which simply
  encapsulate case conversion. No further change is forced.

  It may, however, be desirable for an implementation to make a more complete
  overhaul of their representation. In implementations where the implementors
  feel a need to do this, the amount of work may be considerably greater.

Cost to Users:

  Technically, this change is upward compatible.

  In fact, since the existing CLtL spec is so poor, nearly everyone relies
  heavily on implementation-specific behavior since there is little other
  choice. As such, any change is almost certain to break lots of programs,
  in usually superficial but nevertheless important ways. However, if we
  really make the pathname facility more portable, the user community may be
  willing to bear the consequences of these changes.

Cost of Non-Adoption:

  We would be contributing to the perpetuation of the existing fiasco of a
  pathname system.

Benefits:

  The major costs of non-adoption would be avoided.

Aesthetics:

  More code is required, but the code supports a simpler user model.
  Anything that simplifies the user model of pathnames is going to be an
  improvement.

Discussion:

  Pitman suports PATHNAME-COMPONENT-CASE:CANONICALIZE.

∂05-Jul-88  0854	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 4) 
Received: from rice-chex.ai.mit.edu ([128.52.38.46]) by SAIL.Stanford.EDU with TCP; 5 Jul 88  08:54:07 PDT
Received: by rice-chex.ai.mit.edu; Tue, 5 Jul 88 11:55:44 EDT
Date: Tue, 5 Jul 88 11:55:44 EDT
From: dick@wheaties.ai.mit.edu (Richard C. Waters)
Message-Id: <8807051555.AA03348@rice-chex.ai.mit.edu>
To: gls@think.com
Cc: masinter.pa@xerox.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: gls@think.com's message of Fri, 1 Jul 88 09:59:34 EDT <8807011359.AA10552@brigit.think.com>
Subject: Issue: STREAM-INFO (Version 4)



      Does your pretty printer depend crucially on the equality in
    properties (3) and (6), or can they be relaxed to inequalities

       (3) (<= (+ (OUTPUT-POSITION S) (STRING-WIDTH X S))
	       (OUTPUT-POSITION (PROGN (WRITE-STRING X S) S)))

Several points here;  First, the pretty printer does crucially depend
on the fact that if there is any significant inequality, then it must go
the other way.  I.e.

 (=> (+ (OUTPUT-POSITION S) (STRING-WIDTH X S))
     (OUTPUT-POSITION (PROGN (WRITE-STRING X S) S)))

The pretty printer has to be able to make a guaranteed pesimistic
prediction of what the output position will be without actually
printing anything.  If the inequality went the way you suggest, I
could not be sure that printing the string would not go off of the end
of a line.
  Second, having it be an equality is not TOTALLY crucial, but without
it, I would have to query the stream for the resulting output position
every time I sent a string to it.  With the equality, the stream
almost never has to be queried---A significant saving in time.
  Third, it is true however, that it is not going to make any
difference to the pretty printer if the equality is off slightly.  The
most aesthetic way for an implementation to deal with this case is to
make the horizontal unit returned by the functions course rather than fine.
  Fourth, if there is a fear that the property above would make it too
hard to implement STRING-WIDTH, then one might only require that the
property hold if the string contains standard characters, and allow
implementations to vary as to how close they come to the ideal in
general.  (Note that with this weak a restriction, and assuming a
fixed width font, the function STRING-WIDTH could be implemented
merely as LENGTH.  This is the way the pretty printer works now, and
it doesn't seem to be causing any problems.)
  Fifth, the bottom line here is that pretty printing will work better
or worse based on how accurately STRING-WIDTH is implemented.
However, there is nothing for the pretty printer to do, but simply
assume that the information is accurate.

       (6) (<= (STRING-WIDTH (CONCATENATE 'STRING X Y) S)
	       (+ (STRING-WIDTH X S) (STRING-WIDTH Y S)))

Here, the comments are much the same.
  First, this time the inequality as stated is in the proper direction.
  Second, having the inequality is not totally crucial, but it
significantly reduces the number of times OUTPUT-POSITION and/or
STRING-LENGTH have to be called.
  Third, it is not going to make any difference to the pretty printer
if the equality is off slightly.
  Fourth, note that the equality is only required when the string
contains standard characters.  If a fixed width font is in use, this
is consistent with implementing STRING-WIDTH as length.

I strongly suggest supporting both of the above as eqaulities at least
for standard characters.  Since in the fixed width font case this is
trivial to do, I see no argument against it.

			Dick

∂05-Jul-88  1156	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Jul 88  11:56:38 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 428605; Tue 5-Jul-88 14:56:20 EDT
Date: Tue, 5 Jul 88 14:56 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: pierson%mist@MULTIMAX.ARPA, KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <880705145610.9.KMP@PEWEE.SCRC.Symbolics.COM>

Dan -- I know you were gonna do something on this. I wasn't sure what
your timeframe was. It's very important to us right now, though, so in
an effort to get something on the table, I wrote the following. I hope
this doesn't step on your toes, but rather makes your job a bit easier.
-kmp

-----
Issue:          PATHNAME-SUBDIRECTORY-LIST
References:     Pathnames (pp410-413), MAKE-PATHNAME (p416),
		PATHNAME-DIRECTORY (p417)
Category:       CHANGE
Edit history:   18-Jun-87, Version 1 by Ghenis.pasa@Xerox.COM
	        05-Jul-88, Version 2 by Pitman (major revision)
Status:	        For Internal Discussion
Related-Issues: PATHNAME-COMPONENT-CASE

Problem Description:

  It is impossible to write portable code that can produce a pathname
  in a subdirectory of a hierarchical file system. This defeats much of
  the purpose of having an abstraction like pathname.

  According to CLtL, only a string is a portable filler of the directory
  slot, but in order to denote a subdirectory, the use of separators (such
  as dots, slashes, or backslashes) would be necessary. The very fact that
  such syntax varies from host to host means that although the
  representation might be "portable", the code using that representation 
  is not 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.

  Related problems:

  - In some implementations "FOO.BAR" might denote the "BAR" subdirectory
    of "FOO" while in other implementations because "." is not the
    separator. To be safe, portable programs must avoid all potential
    separators.

  - Even in implementations where "." is the separator, "FOO.BAR" may be
    recognized by some to mean the "BAR" subdirectory of "FOO" and by others
    to mean `a seven letter directory with "." being a superquoted part of
    its name'.

  - In fact, CLtL does not even say for toplevel directories whether the
    directory delimiters are a part. eg, is "foo" or "/foo" the directory
    filler for a unix pathname "/foo/bar.lisp". Similarly, is "[FOO]" or
    "FOO" the directory filler for a VMS pathname "[FOO]ME.LSP"?

Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)

  Allow a list to be a filler of a pathname. The car of the list may be either
  of the symbols :ABSOLUTE or :RELATIVE.

  If the car of the list is :RELATIVE, the rest of the list is the
  implementation-dependent result of PARSE-NAMESTRING for file systems which
  have relative pathnames. Unless some other proposal is submitted to clarify
  the behavior of relative pathnames in merging, etc. that behavior is left
  undefined.

  If the car of the list is :ABSOLUTE, the rest of the list is a list of 
  strings each naming a single level of directory structure. The strings
  should contain only the directory names themselves -- no separator
  characters.

  The spec (:ABSOLUTE) represents the root directory.

  Clarify that if a string is used as a filler of a directory field in a
  pathname, it should be the unadorned name of a toplevel directory.
  Specifying a string, str, is equivalent to specifying the list
  (:ABSOLUTE str).

  In place of a string, at any point in the list, the symbol :WILD or 
  :WILD-INFERIORS may occur. These symbols may not be meaningful for all
  operating systems, but may be useful on those operating systems which 
  do provide such mechanisms. They denote a full wildcard match of one
  or several directory levels, respectively.

Test Case:

  (PATHNAME-DIRECTORY (PARSE-NAMESTRING "[FOO.BAR]BAZ.LSP")) ;on VMS
  => (:ABSOLUTE "FOO" "BAR")

  (PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/baz.lisp")) ;on Unix
  => (:ABSOLUTE "foo" "bar")
  or (:ABSOLUTE "FOO" "BAR") ;if PATHNAME-COMPONENT-CASE:CANONICALIZE passes

  (PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>**>bar>baz.lisp")) ;on LispM
  => (:ABSOLUTE "FOO" :WILD-INFERIORS "BAR")

  (PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
  => (:ABSOLUTE "FOO" :WILD "BAR")

Rationale:

  This would allow programs to usefully deal with hierarchical file systems,
  which are by far the most common file system type.

Current Practice:

  Symbolics Genera implements something very similar to this. [The main
  difference is that in Genera, there is no :ABSOLUTE keyword at the head
  of the list. This has been shown to cause some problems in dealing with
  root directories. Genera represents the root directory by a keyword
  symbol (rather than a list) because the list representation was not
  adequately general.]

Cost to Implementors:

  In principle, nothing about the implementation needs to change except
  the treatment of the directory field by MAKE-PATHNAME and
  PATHNAME-DIRECTORY. The internal representation can otherwise be left
  as-is if necessary.

  For implementations that choose to rationalize this representation
  throughout their internals and any other implementation-specific
  accessors, the cost will be necessarily higher.

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  Serious portability problems would continue to occur. Programmers would be
  driven to the use of implementation-specific facilities because the need
  for this is frequently impossible to ignore.

Benefits:

  The serious costs of non-adoption would be avoided.

Aesthetics:

  This representation of hierarchical pathnames is easy to use and quite
  general. Users will probably see this as an improvement in the aesthetics.

Discussion:

  This issue was raised a while back but no one was fond of the particular
  proposal that was submitted. This is an attempt to revive the issue.

  The original proposal, to add a :SUBDIRECTORIES field to a pathname, was
  discarded because it imposed an unnatural distinction between a toplevel
  directory and its subdirectories. Pitman's guess is the the idea was to
  try to make it a compatible change, but since most programmers will 
  probably want to change from implementation-specific primitives to portable
  ones anyway, that's probably not such a big deal. Also, there might have
  been some programs which thought the change was compatible and ended up
  ignoring important information (the :SUBDIRECTORIES field). Pitman thought
  it would be better if people just accepted the cost of an incompatible
  change in order to get something really pretty as a result.

  This issue used to address the issue of relative pathnames (pathnames
  relative to some default which is separately maintained). Pitman removed
  this issue for now in order to simplify things. He feels the issue should
  be resubmitted under separate cover so that it can be discussed separately.

  Variations on this proposal, one or more of which could be factored in if
  there were sufficient interest are:
   - Flushing the idea of strings as fillers for this field require
     implementations to always use a list.
   - Relaxing the representation to allow the keyword :ABSOLUTE to
     be optional in most cases (but required to represent the root).
   - Never using :ABSOLUTE, but requiring that to represent the root
     directory, you must use the symbol :ROOT as the filler for the
     directory slot.
   - Specifying that the representation is either a list of strings
     or a list whose car is a keyword such as :RELATIVE or :ROOT.
   - Specifying that any implementation-specific contents must be a
     list which begins with a keyword other than ones defined by these
     proposals. eg, (:OTHER implementation-specific-stuff).

∂05-Jul-88  1454	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 6)  
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 5 Jul 88  14:54:00 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA00116; Tue, 5 Jul 88 17:51:23 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA19983; Tue, 5 Jul 88 17:55:34 EDT
Message-Id: <8807052155.AA19983@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 6)
Date: Tue, 05 Jul 88 17:55:32 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

Issue:         STANDARD-INPUT-INITIAL-BINDING
References:    Standard streams (pp. 327-329)
Category:      CHANGE
Edit history:  Version 1 by Pierson and Haflich 1/19/87
    	       Version 2 by Pierson 2/29/88
	       Version 3 by Pierson 5/23/88, per comments by Moon
               Version 4 by Pierson 5/26/88, clean up
    	       Version 5 by Pierson 6/28/88, simple design per Masinter
    	       Version 6 by Pierson 7/ 5/88, clean up and split issue
Status:        For Internal Discussion

The new inquiry functions have been split off into a new issue:
STREAM-CAPABILITIES.  The proposal name has been changed back to
DEFINED-CONTRACTS to reflect this.

Problem description:

CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*.  This requirement
hampers the integration of Common Lisp with many existing and
potential operating environments.

For example, a Unix implementation is currently unable to legally
support Unix standard error output even though Common Lisp defines
*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
to the same stream as *STANDARD-OUTPUT*.  A workstation environnment
which provides stream access to windows as an extension is currently
forbidden to make trace output appear in a separate window by default
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.

Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):

A Common Lisp implementation is required to provide the following
initial streams.  Each initial stream has a specific purpose as
defined in CLtL.  This proposal redefines the initial bindings of
the streams and leaves the rest of the CLtL description unchanged.

    *TERMINAL-IO*
    	Is always bound to a writable two-way stream that is not a
	synonym for any of the the other streams mentioned in this
	proposal.  It is legal for input from *TERMINAL-IO* be a
	permanently empty stream because there may be no convenient
	place to read input from (it is also legal for output to
	*TERMINAL-IO* to go to a bit-sink; there is no portable way
	for a program to detect this case).

    *STANDARD-INPUT*
    *STANDARD-OUTPUT*
    *ERROR-OUTPUT*
    *TRACE-OUTPUT*
    *QUERY-IO*
    *DEBUG-IO*
    	The initial bindings of these variables are undefined except
	that:
	    1. They are all initially bound to streams.
	    2. The streams must support input and/or output as
	       indicated by the variable name.
	    3. None of the streams may be synonym-streams for another
	       one of the streams, whether directly or by indirection
	       via some composite stream type such as a two-way
	       stream.
	    4. Any or all of these streams may be synonym streams for
	       *TERMINAL-IO*.
	    5. Any or all of these streams may be synonyms for the a
	       common implementation dependent stream.  For example,
	       in an interactive Common Lisp invocation running on a
	       character terminal, all of the streams mentioned here
	       might be synonym streams (or two-way streams to synonym
	       streams) to a pair of hidden terminal input/output
	       streams maintained by the implementation.

	The intent of the above rules is to ensure that it is always
	safe to bind any of the above variables to another of the
	above variables without unduly restricting implementation
	flexibility.


Test Cases/Examples:

(PROGN
   (PRINT "Output" *STANDARD-OUTPUT*)
   (PRINT "Error" *ERROR-OUTPUT*))

In current Common Lisp will write:
    ------
    Output
    Error
    ------

With proposal *might* write:
    ------
    Output
    ------
    and "Error" appears somewhere else.


(LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
  ...)

In current Common Lisp: 
    Might cause a circular stream reference because *DEBUG-IO* was
    bound to a two-way stream made up of synonym streams to
    *STANDARD-INPUT* and *STANDARD-OUTPUT*.

With this proposal:
    Would be guaranteed not to cause a circular stream reference.


(LET ((*STANDARD-INPUT*  *TERMINAL-IO*)
      (*STANDARD-OUTPUT* *TERMINAL-IO*))
  ...)

In current Common Lisp: 
    Might cause a circular stream reference because *TERMINAL-IO* was
    bound to a two-way stream made up of synonym streams to
    *STANDARD-INPUT* and *STANDARD-OUTPUT*.

With this proposal:
    Would be guaranteed not to cause a circular stream reference.


Rationale:

This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output.

Current practice:

Lucid binds *TERMINAL-IO* to a special internal stream type.  Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output.  KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output.

Cost to Implementors:

All implementations will have to change to some degree but the changes
will probably be simple and localized.  All known implementations
already support the underlying streams required to implement this
proposal.

Cost to Users:

User code which depends on the strict binding hierarchy in CLtL may
have to change.  

Cost of non-Adoption:

It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.

Benefits:

Implementations will be more able to match their IO behavior to their
environment and their user's expectations.

Aesthetics:

Improved because this area becomes better defined.

Discussion:

Pitman was concerned that the initial version of this proposal didn't
provide a guaranteed way to get back the initial streams after
rebinding, e.g. *standard-io*.  The second version of this proposal
offered a solution to that problem which was generally considered too
complex.  This problem should now be solved.

Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
*DEBUG-IO*) should fail to work in a non-interactive environment where
nothing like a terminal exists.

Masinter notes that:
    ``In many multi-processing multi-window environments,
      the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
      differs for each process.''  

Pitman suggests that this issue be renamed to remove "STANDARD-INPUT"
from the name.  Pierson hasn't done this for fear of further confusing
people's archives.

Pierson supports STANDARD-OUTPUT-INITIAL-BINDING:DEFINED-CONTRACTS.

∂05-Jul-88  1455	CL-Cleanup-mailer 	Issue: STREAM-CAPABILITIES (version 1)   
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 5 Jul 88  14:54:49 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA00214; Tue, 5 Jul 88 17:52:23 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA19990; Tue, 5 Jul 88 17:56:33 EDT
Message-Id: <8807052156.AA19990@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: STREAM-CAPABILITIES (version 1)
Date: Tue, 05 Jul 88 17:56:31 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

Issue:         STREAM-CAPABILITIES
References:    Standard streams (pp. 327-329)
Category:      ADDITION
Edit history:  Version 1 by Pierson 7/ 5 88, add redesign per Pitman
Status:        For Internal Discussion

Two versions, one from Masinter and one from Pitman.

Problem description:

Portable programs cannot currently determine certain useful
relationships among streams because the required information is
operating-system dependent and unavailable at a portable Common Lisp
level. 

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

Proposal (STREAM-CAPABILITIES:NEW-PREDICATES):

Add the following inquiry functions to Common Lisp:

    STREAM-SAME-DESTINATION-P stream1 stream2	    	    [Function]

      Returns T if the Lisp can prove that the two streams send their
      output to the same "destination".  For example, this function
      would return true for two streams that output to Unix files iff
      the streams resulted either in output to the same file
      descriptor or in output to two different file descriptors for
      the same inode.

    STREAM-SAME-SOURCE-P stream1 stream2    	    	    [Function]

      Returns T if the Lisp can prove that the two streams receive
      their input from the same "source", where same source mans that
      input on one stream will change what the other stream would next
      read.  For example, this function would return true for two
      streams that read from Unix files iff the streams resulted in
      input from the same file descriptor but not if the streams
      resulted in in input from two different file descriptors for the
      same inode because then reading one stream would not change what
      the other stream saw.

    INTERACTIVE-STREAM-P stream	    	    	    	    [Function]

      Returns T if the Lisp believes that the stream is interactive.
      Some of the things that define a stream as interactive include:
         1. The stream is connected to a person, program, or device
	    such that the program can prompt for information and
	    expect to receive different input depending on the prompt.
	 2. The program should prompt for input and support "normal
	    input editing".
	 3. READ-CHAR might hang waiting for input instead of
	    immediately returning EOF.
      The answer returned by this function may be incorrect; it will
      most likely be based on whether or not the stream is connected
      to whatever the underlying operating system considers a
      "terminal device".

Test Cases/Examples:

(LET* ((IN1 (OPEN "foo" :DIRECTION :INPUT))
       (IN2 (OPEN "foo" :DIRECTION :INPUT))
       (OUT1 (OPEN "foo" :DIRECTION :OUTPUT))
       (OUT2 (OPEN "foo" :DIRECTION :OUTPUT))
       (STREAM1 (MAKE-TWO-WAY-STREAM IN1 OUT1))
       (STREAM2 (MAKE-TWO-WAY-STREAM IN2 OUT2)))
  (LIST (STREAM-SAME-DESTINATION-P STREAM1 OUT1)
        (STREAM-SAME-DESTINATION-P STREAM1 STREAM2)
	(STREAM-SAME-SOURCE-P STREAM1 IN1)
	(STREAM-SAME-SOURCE-P STREAM1 STREAM2)
	(STREAM-INTERACTIVE-P STREAM1)
	(STREAM-INTERACTIVE-P *TERMINAL-IO*)))

==> (T T T NIL NIL ?) ; *TERMINAL-IO* might or might not be interactive

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

Proposal (STREAM-CAPABILITIES:LIST-FUNCTIONS)

Add the following inquiry functions to Common Lisp:

    STREAM-SOURCE-ID-LIST stream                            [Function]
    STREAM-DESTINATION-ID-LIST stream                       [Function]

      Returns a list of tokens which identify the source or the
      destination of the stream at the current time.  The tokens may
      be any Lisp objects distinguishable using EQL.  The only valid
      operations on the list of tokens are non-destructive set
      operations.

      A synonym stream always returns the same id list as the stream
      to which it is indirected.

      An encapsulated stream (such as an echo stream or a broadcast
      stream) always returns at least the union of the tokens which
      would be returned by each of the encapsulated streams.

    INTERACTIVE-STREAM-P stream	    	    	    	    [Function]

      Returns T if the Lisp believes that the stream is interactive.
      Some of the things that define a stream as interactive include:
         1. The stream is connected to a person, program, or device
	    such that the program can prompt for information and
	    expect to receive different input depending on the prompt.
	 2. The program should prompt for input and support "normal
	    input editing".
	 3. READ-CHAR might hang waiting for input instead of
	    immediately returning EOF.
      The answer returned by this function may be incorrect; it will
      most likely be based on whether or not the stream is connected
      to whatever the underlying operating system considers a
      "terminal device".

Test Cases/Examples:

(LET* ((IN1 (OPEN "foo" :DIRECTION :INPUT))
       (IN2 (OPEN "foo" :DIRECTION :INPUT))
       (OUT1 (OPEN "foo" :DIRECTION :OUTPUT))
       (OUT2 (OPEN "foo" :DIRECTION :OUTPUT))
       (STREAM1 (MAKE-TWO-WAY-STREAM IN1 OUT1))
       (STREAM2 (MAKE-TWO-WAY-STREAM IN2 OUT2)))
  (LIST (INTERSECTION (STREAM-DESTINATION-ID-LIST STREAM1)
                      (STREAM-DESTINATION-ID-LIST OUT1))
        (INTERSECTION (STREAM-DESTINATION-ID-LIST STREAM1)
	              (STREAM-DESTINATION-ID-LIST STREAM2))
	(INTERSECTION (STREAM-SOURCE-ID-LIST STREAM1)
	              (STREAM-SOURCE-ID-LIST IN1))
	(INTERSECTION (STREAM-SOURCE-ID-LIST STREAM1)
	              (STREAM-SOURCE-ID-LIST STREAM2))
	(INTERACTIVE-STREAM-P STREAM1)
	(INTERACTIVE-STREAM-P *TERMINAL-IO*)))

==> (T T T NIL NIL ?) ; *TERMINAL-IO* might or might not be interactive

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

Rationale:

These inquiry functions answer questions that portable Lisp programs
can't answer on their own because the information is frequently only
maintained at an operating system level.

Current practice:

No implementations currently provide this functionality.

Cost to Implementors:

Implementations will have to support these new functions.  Correct
support will require some thought for each operating system supported.

Cost to Users:

None, this is an upward-compatible extension.

Cost of non-Adoption:

Portable programs will have trouble matching their user interface to
different target environments.

Benefits:

Implementations will be more able to match their IO behavior to their
environment and their user's expectations.  Portable programs will
have more tools for reasoning about stream relationships.

Aesthetics:

Improved because this area becomes better defined.

Discussion:

Masinter doesn't believe that STREAM-SAME-SOURCE-P (or, presumably,
STREAM-SOURCE-ID-LIST) is needed; Pierson disagrees.

INTERACTIVE-STREAM-P is problematical, the information would be useful
to some programs, but it's not clear how many implementations can
return a useful answer.

Pierson supports STREAM-CAPABILITIES:NEW-PREDICATES because he is
concerned that it may be hard for implementations to provide the list
functions efficiently because the natural token type for multiple,
disjoint types of streams may be integers.  The implementation would
have to coerce these integers in to some other type of token that
would be guaranteed unique across all possible stream types.

∂05-Jul-88  1624	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)  
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 5 Jul 88  16:24:38 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA00752; Tue, 5 Jul 88 19:22:10 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA20327; Tue, 5 Jul 88 19:26:23 EDT
Message-Id: <8807052326.AA20327@mist.UUCP>
To: Kent M Pitman <KMP%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
In-Reply-To: Your message of Tue, 05 Jul 88 14:56:00 -0400.
             <880705145610.9.KMP@PEWEE.SCRC.Symbolics.COM> 
Date: Tue, 05 Jul 88 19:26:21 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

Actually, I was waiting for Chris Perdue who said in Boston that he
had a draft in review.  Thanks for giving us all a kick.

                                            dan

∂06-Jul-88  0720	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 6)  
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 6 Jul 88  07:20:19 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA01125; Wed, 6 Jul 88 10:17:35 EDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 429040; Wed 6-Jul-88 10:19:18 EDT
Date: Wed, 6 Jul 88 10:19 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 6)
To: pierson%mist@MULTIMAX.ARPA
Cc: cl-cleanup%sail.stanford.edu@MULTIMAX.ARPA
In-Reply-To: <8807052155.AA19983@mist.UUCP>
Message-Id: <880706101913.3.KMP@PEWEE.SCRC.Symbolics.COM>

    Date: Tue, 05 Jul 88 17:55:32 EDT
    From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    Issue:         STANDARD-INPUT-INITIAL-BINDING
    ...
    Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):
    ...
	*DEBUG-IO*
	    The initial bindings of these variables are undefined except
	    that:
		1. They are all initially bound to streams.
		2. The streams must support input and/or output as
		   indicated by the variable name.
		3. None of the streams may be synonym-streams for another
		   one of the streams, whether directly or by indirection
		   via some composite stream type such as a two-way
		   stream.

I would say something more like:

 "None of the standard streams (including *TERMINAL-IO*) may be directed
  by synonym stream to another of these stream variables (except *TERMINAL-IO*),
  whether directly or by indirection via some composite stream such as a
  two-way stream with one of the arms being a synonym stream."

The reason being that you need to restrict *TERMINAL-IO*, and also that
you don't want to restrict people pointing at the contents of one of
these variables, you just don't want them actually being synonyms for the
variable itself.

		4. Any or all of these streams may be synonym streams for
		   *TERMINAL-IO*.
		5. Any or all of these streams may be synonyms for the a

I believe the "the" here is spurious.

		   common implementation dependent stream.  For example,
    ...
    Test Cases/Examples:
    ...
    (LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
      ...)

    In current Common Lisp: 
	Might cause a circular stream reference because *DEBUG-IO* was

I'd say "if" not "because" here.

	bound to a two-way stream made up of synonym streams to
	*STANDARD-INPUT* and *STANDARD-OUTPUT*.

Maybe also note that this could happen only if *DEBUG-IO* was not its original
setting, since the original setting of *DEBUG-IO* is currently a synonym stream
to *TERMINAL-IO*. So the example is in some sense more complicated than you
show. Maybe you could just change the example to be something that shows the
behavior. Eg,

 (DEFUN FOO () 
   (LET ((*DEBUG-IO* (MAKE-TWO-WAY-STREAM (MAKE-SYNONYM-STREAM '*STANDARD-INPUT*)
					  (MAKE-SYNONYM-STREAM '*STANDARD-OUTPUT*))))
     (BAR)))

 (DEFUN BAR ()
   (LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
     (PRINT 'FOO)))

    With this proposal:
	Would be guaranteed not to cause a circular stream reference.

    (LET ((*STANDARD-INPUT*  *TERMINAL-IO*)
	  (*STANDARD-OUTPUT* *TERMINAL-IO*))
      ...)

Well, not guaranteed not to cause a circular reference. Rather, users would be
warned that the code that led to a circular reference was an error.

    In current Common Lisp: 
	Might cause a circular stream reference because *TERMINAL-IO* was
	bound to a two-way stream made up of synonym streams to
	*STANDARD-INPUT* and *STANDARD-OUTPUT*.

    With this proposal:
	Would be guaranteed not to cause a circular stream reference.

Right. Maybe mention that this could conceivably happen in the initial
configuration of some implementations.

    ...
    Current practice:

    Lucid binds *TERMINAL-IO* to a special internal stream type.  Franz
    binds *TERMINAL-IO* to a special internal stream type for terminal
    streams which reads from Unix standard input and writes to Unix
    standard output.  KCL binds *TERMINAL-IO* to a standard two-way-stream
    with input from Unix standard input and output to Unix standard
    output.

Symbolics Genera binds *TERMINAL-IO* as appropriate for each process,
usually to a `window' for interactive applications or to a stream which
will conjure an interaction window on demand for background tasks.

    ...
    Discussion:

    Pitman was concerned that the initial version of this proposal didn't
    provide a guaranteed way to get back the initial streams after
    rebinding, e.g. *standard-io*.  The second version of this proposal
    offered a solution to that problem which was generally considered too
    complex.  This problem should now be solved.

I'm not sure that this continues to be relevant enough to take up space
in the proposal. People can read the old proposal versions if they care.

    Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
    *DEBUG-IO*) should fail to work in a non-interactive environment where
    nothing like a terminal exists.

It might be well to plainly identify that this issue is not really
addressed by the above proposal.

    Masinter notes that:
	``In many multi-processing multi-window environments,
	  the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
	  differs for each process.''  

    Pitman suggests that this issue be renamed to remove "STANDARD-INPUT"
    from the name.  Pierson hasn't done this for fear of further confusing
    people's archives.
    ...

This doesn't need to be here either. If no one cares, I'll live with the
funny name. Brevity is most important, I think.

∂06-Jul-88  1836	CL-Cleanup-mailer 	EQUAL-STRUCTURE 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jul 88  18:36:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JUL 88 18:36:11 PDT
Date: 6 Jul 88 18:35 PDT
From: Masinter.pa@Xerox.COM
Subject: EQUAL-STRUCTURE
to: cl-cleanup@sail.stanford.edu
Message-ID: <880706-183611-1212@Xerox>

After all the debate, I'm convinced that the worst thing that we can do is to
change it without fixing it, and that it is unfixable. I think taking it out is
too radical, and so we should just clarify that it doesn't descend into any
structure that CLtL doesn't mention that it explicitly descends into.

∂07-Jul-88  0824	CL-Cleanup-mailer 	Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Jul 88  08:24:47 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 429853; Thu 7-Jul-88 11:24:18 EDT
Date: Thu, 7 Jul 88 11:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880707112359.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        PATHNAME-SYNTAX-ERROR-TIME
References:   File System Interface (pp409-427)
Category:     CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  There exist conceivable pathnames for which there is no valid mapping in a
  particular implementation. CLtL is not clear about the time at which this
  error might be detected.

  For example, on file systems which constrain pathname-types to be three
  letters or fewer, the type "LISP" is not valid. The question arises: when
  is this error detected?

  In some implementations, the error might be detected while forming the
  pathname. That is, (MAKE-PATHNAME :TYPE "LISP") signals an error.

  In some implementations, the error might be detected while forming the
  namestring. That is, (MAKE-PATHNAME :TYPE "LISP") succeeds, but
  (NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) signals an error.

  In some implementations, validity checking might be done only by the host
  operating system, so Lisp does not detect the error unless the operating
  system complains. For example, (MAKE-PATHNAME :TYPE "LISP") succeeds,
  and even (NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) constructs a plausible
  looking pathname, but (OPEN (NAMESTRING (MAKE-PATHNAME :TYPE "LISP"))) fails.

  In some implementations, Lisp might make `friendly' corrections to the
  pathname in order to form a namestring. For example,
  (MAKE-PATHNAME :TYPE "LISP") might succeed, but 
  (NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) might produce a namestring with
  an extension such as ".LIS" or ".LSP".

  Similar issues might come up in file systems which don't allow wildcard
  pathnames. Is :WILD allowed in a name or type slot and then disallowed
  upon coercion to a pathname, or is :WILD complained about "up front"?

  This phenomenon is a barrier to portability because if a program is
  debugged in an implementation that does, for example, NAMESTRING-time
  error checking, the programmer may be lulled into an expectation that
  it is acceptable to construct and manipulate invalid pathnames as long
  as the problem is caught before an attempt to call NAMESTRING is
  attempted. On the other hand, another programmer may debug his code in
  a Lisp which does early error checking of syntax and may assume that 
  he is home free if the pathname gets constructed correctly.

Proposal (PATHNAME-SYNTAX-ERROR-TIME:PATHNAME-CREATION):

  Clarify that operations such as MAKE-PATHNAME and MERGE-PATHNMES which
  construct new pathnames do plausibility checking of their arguments
  and signal an error rather than construct a pathname for which NAMESTRING
  would not produce a valid pathname.

  Rationale:

    This would identify clearly to the programmer where he should expect an
    error to be signalled for a pathname.

    This would mean that fully constructed pathnames could reliably
    be converted to namestrings.

  Cost to Implementors:
  
    Some implementors, especially those which rely on the operating system
    to be the sole authority on pathname syntax, might have to introduce
    some new syntax-checking facilities.

    Implementations where this error checking is done later would have to be
    changed both to do it earlier, and to not make the unwarranted assumption
    that pathnames with no valid namestring representation are constructable.

  Cost to Users:

    The ability to represent non-viable pathnames for the purpose of merging
    would be lost. This feature was not portably available, but was available
    in some operating systems.

    Some code which expected an error, but expected it at a different time
    would have to be changed.

Proposal (PATHNAME-SYNTAX-ERROR-TIME:NAMESTRING-COERCION):

  Clarify that it was valid to create a pathname which could not be
  converted to a namestring. Require NAMESTRING (and related functions,
  such as ENOUGH-NAMESTRING or any internal functions that might be used
  in place of NAMESTRING by functions like OPEN and PROBE-FILE) to signal
  an error for pathnames which do not represent valid filenames in the
  designated file system.

  Rationale:

    This would identify clearly to the programmer where he should expect an
    error to be signalled for a pathname.

    This would allow the construction of pathnames for the sole purpose of
    merging without causing what might seem to some as gratuitous errors.

  Cost to Implementors:
  
    Implementors who rely on the operating system to be the sole authority
    on pathname syntax, might have to introduce some new syntax-checking
    facilities.

    Implementations where this error checking is done earlier would have to
    be changed both to do it later, and to not make the unwarranted
    assumption that any pathname has a valid namestring representation.

  Cost to Users:

    Early error checking of faulty pathnames would be lost.

    Some code which expected an error, but expected it at a different time
    would have to be changed.

  Benefits:
  
    Macsyma, for example, has encountered a need for "hostless" pathnames
    (in merging). The concept makes no sense if every pathname must have
    a namestring, because a pathname with no host cannot have a namestring.
    However, if it's NAMESTRING's responsibility to signal an error, then
    hostless pathnames are still useful for merging. Consider:
	(MERGE-PATHNAMES (MAKE-PATHNAME :NAME "FRED") MARY)
    This will override both the NAME and the HOST field of MARY because you
    must currently have a host in every pathname. But if MAKE-PATHNAME did
    not force the host, or if one could explicitly say :HOST NIL, then
    such pathnames would be considerably more useful for merging.

Proposal (PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE):

  Clarify that we were unable to reach agreement on this issue and that
  the time at which this error detection occurs is not well-specified.

  Advise the editorial group to warn users clearly about this known source
  of program portability problems.

  Rationale:

    This implements the status quo.

  Cost to Implementors:
  
    None.

  Cost to Users:

    No existing code must be modified, but there is an ongoing cost
    associated with providing error checking at multiple points in a
    program because implementations disagree as to where an error
    might be signalled. In some cases, the effects of having to handle
    this in multiple places may cause unpleasant modularity violations.

Test Case:

  See problem description.

Current Practice:

  Symbolics Genera signals an error at pathname construction time if a
  pathname will be invalid. Once a pathname is successfully constructed,
  it can generally be assumed that NAMESTRING will always succeed.

Aesthetics:

  Making this more well-defined would cause a definite aesthetic
  improvement to some programs.

Discussion:

  Pitman prefers PATHNAME-SYNTAX-ERROR-TIME:NAMESTRING-COERCION but
  believes that anything is an improvement over ...:EXPLICITLY-VAGUE.

  CL pathname functions were not adequate for use in Macsyma because
  they did not adequately represent to-be-merged-only pathnames (a
  feature used very extensively in Macsyma), because errors could be
  signalled at radically different times. To get around this, Pitman
  had to create a data structure in Macsyma called an MPATHNAME which
  was only trivially different than a PATHNAME but which made it
  possible to deal portably with this issue of when errors occurred
  and what kinds of errors occured. Unfortunately, since none of the
  CL functions worked on MPATHNAMEs, a whole series of functions,
  also only trivially different, had to be created: MAKE-MPATHNAME,
  MNAMESTRING, MERGE-MPATHNAMES, MPATHNAME-NAME, MPATHNAME-TYPE, 
  MOPEN, WITH-MOPEN-FILE, etc.

∂07-Jul-88  0908	CL-Cleanup-mailer 	RE: Issue: SYMBOL-MACROLET-UTILITY  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 7 Jul 88  09:08:04 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
	id AA02117; Thu, 7 Jul 88 09:07:29 PDT
Date: Thu, 7 Jul 88 09:07:29 PDT
Message-Id: <8807071607.AA02117@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: Gregor.pa@xerox.com
Subject: RE: Issue: SYMBOL-MACROLET-UTILITY


> This isn't a problem description, it is a statement of opinion.  A
> problem description would say something like:
> 
>   The symbol-macrolet utitily introduced with CLOS has some semantic
>   problems.  <discussion of these problems here>.  These problems may
>   cause problems with some existing code <extension of previous
>   discussion here>.


I'm not completely happy with the problem description as it stands, either.  I
see the issue as essentially a choice between (a) fixing the semantics of
SYMBOL-MACROLET to match the semantics of MACROLET, or (b) doing without
SYMBOL-MACROLET.  I had thought I could separate these into two issues
(namely, keep-vs.-flush first, and fix the semantics only if flush fails), but
now I think I should combine them into one issue after all.  This will be
forthcoming.
 
>    Cost to Users:
> 
>	Users will lose the expressive ability provided by SYMBOL-MACROLET,
>	WITH-ACCESSORS, and WITH-SLOTS, and will have to make do with
>        MACROLET.
> 
>Another cost is that they won't be able to overload names to mean both
>a real function and one of these hack macros.  For example:
> 
>(defclass foo () (car cdr))
> 
>(defun describe-foo (foo)
>  (macrolet ((car () (slot-value foo 'car))
>	     (cdr () (slot-value foo 'cdr)))
>    ...
>    Can't use normal car and cdr in here
>    ...))
> 
>Of course this is something that Scheme programmers are used to dealing
>with.  But Common Lisp programmers are not.  The potential for this
>seriously aggravating the existing problem with macro expansions
>capturing the wrong lexical context is huge.

The namespace argument is a valid one; I'll put that in "Cost to Users".  This
is honestly the first pro-SYMBOL-MACROLET argument I've heard that has more
substance than "But it'd be neat to have SYMBOL-MACROLET."

Characterizing the namespace collision problem as "huge," based on the example
you give, assumes that (a) people have some proclivity toward using names that
conflict with function names like "car" and "cdr", (b) they'd use the same
name for both the macro and the slot (cf. defstruct and the :conc-name prefix
mechanism), and (c) someone writing

		(macrolet ((car () ...)) ...)

wouldn't see the name collision.  I might believe the first assumption
(especially for names like "list"), I'm more dubious of the second, and I
really have a hard time swallowing the third assumption.  Even in a Lisp-2,
programmers are used to avoiding name conflicts.

I tend to believe that changing WITH-SLOTS and WITH-ACCESSORS could eliminate
CLOS' need for SYMBOL-MACROLET altogether, if they just generated MACROLET
macros with prefixes.

 
>     Cost of Non-Adoption:
>  
> 	Implementors must implement significant new functionality, adding to
> 	system size and language complexity.  (A separate proposal,
> 	SYMBOL-MACROLET-SEMANTICS, addresses problems with the currently
> 	specified semantics of SYMBOL-MACROLET.)
>  
> I am not sure I buy this.  For one, there is already an implementation
> of it in PCL.  For another, any exiting compiler must already have the
> right stuff in it to do this.  
> 
> If you insist on doing an entirely custom CLOS, the work required to do
> this part of it is very small compared to the work required to do the
> rest of it.
 
I guess I was getting ahead of myself here.  I'd been taking it as an almost
foregone conclusion that, if SYMBOL-MACROLET is kept in the language, it would
be promoted to a special form, in which case the PCL implementation doesn't
really help anybody.  Another reason to combine this with the
fix-the-semantics issue.

/JEP

∂07-Jul-88  1136	CL-Cleanup-mailer 	Issue: PATHNAME-CANONICAL-TYPE (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Jul 88  11:36:33 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 429994; Thu 7-Jul-88 14:36:18 EDT
Date: Thu, 7 Jul 88 14:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880707143558.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:          PATHNAME-CANONICAL-TYPE
References:     MAKE-PATHNAME (p416)
Category:       ADDITION
Edit history:   07-Jul-88, Version 1 by Pitman
Status:	        For Internal Discussion
Related-Issues: PATHNAME-COMPONENT-CASE

Problem Description:

  The pathame-type of ``Lisp'' and ``Compiled Lisp'' files vary widely from
  implementation to implementation.

  "LSP" is common on Vax VMS. "lisp" is generally used for the Symbolics
  file system. "l" and "lisp" are common on Unix. Some Lisp implementations
  use customized extensions such as "cl" or even "jcl" (eg, for "Joe's CL").

  It would be useful to probe the existence of either a source or a binary
  file, but that cannot currently be done portably. Furthermore, it would be
  useful to create certain standard kinds of files in a system-independent
  fashion.

  A common desire, for example, is to do
    (DEFUN FILE-NEEDS-TO-BE-COMPILED (FILE)
      (LET ((SOURCE (PROBE-FILE
		      (MERGE-PATHNAMES FILE (MAKE-PATHNAME :TYPE ???))))
	    (BINARY (PROBE-FILE
		      (MERGE-PATHNAMES FILE (MAKE-PATHNAME :TYPE ???)))))
        ... (FILE-WRITE-DATE SOURCE) ... (FILE-WRITE-DATE BINARY) ...))
  The problem is that there's nothing portable to put in the ??? positions.

  Indeed, depending on the host (ie, file system) of the pathname, the
  type might need to differ even in the same Lisp implementation. For example,
  Symbolics Genera stores its source files in names like "foo.l" on Unix,
  "FOO.LSP" on VMS, etc.

Proposal (PATHNAME-CANONICAL-TYPE:NEW-CONCEPT):

  In addition to the normal strings and keywords currently allowed as fillers
  of the TYPE field of a pathname, allow other keywords which designate
  ``canonical types''. 

  A canonical type is translated to a real type by MAKE-PATHNAME so that the
  (PATHNAME-TYPE (MAKE-PATHNAME :TYPE canonical-type)) is a string.

  Introduce a new function PATHNAME-CANONICAL-TYPE which returns the canonical
  type of an argument pathname, or the type if there is no canonical type.
  For example,
    (PATHNAME-CANONICAL-TYPE (MAKE-PATHNAME :TYPE :LISP)) => :LISP
  [This information may be explicitly represented as an additional slot, or
  computed on demand using a lookup table, as the implementor prefers.]

  Define the following standard types:
	:LISP		``Lisp'' (source) file
	:BIN		``Compiled Lisp'' (object) file
  Permit implementations to extend the set of canonical type names.

Test Case:

  (PATHNAME-TYPE (MAKE-PATHNAME :TYPE :LISP))
   => "LSP" 	    ;Typically, on VMS
   => "l" or "lisp" ;Typically, on Unix
   => "L" or "LISP" ;Typically, on Unix 
		    ; (assuming PATHNAME-COMPONENT-CASE:CANONICALIZE adopted)
   ..etc.

  (PATHNAME-TYPE (MAKE-PATHNAME :TYPE :BIN))
   => "FAS" 	    ;eg, VAXLISP
   => "BIN"	    ;eg, Symbolics file system
   ...etc.

  (PATHNAME-CANONICAL-TYPE (MAKE-PATHNAME :TYPE :LISP)) => :LISP

  (PATHNAME-CANONICAL-TYPE (MAKE-PATHNAME :TYPE "LSP"))
   => :LISP	    ;eg, VAXLISP
   => "LSP"	    ;eg, Unix

Rationale:

  This is a useful subset of the functionality already available in
  at least one implementation.

Current Practice:

  Symbolics Genera implements this proposal.

Cost to Implementors:

  The cost of implementing these proposed features is very slightly.

  MAKE-PATHNAME would have to change to coerce its :TYPE argument in implementations
  where it does not do so already. PATHNAME-CANONICAL-TYPE can be implemented as a
  fairly straightforward lookup.

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  It would continue to be hard to portably name files when their types
  differed from file system to file system.

Benefits:

  The cost of non-adoption would be avoided.

Aesthetics:

  Some programs would be able to abstract away from the particulars of the host
  file system entirely. Some people believe this would be a definite improvement
  in aesthetics.

Discussion:

  Note that different Lisp implementations which share the same file system,
  need not and perhaps should not agree on the same type string for the
  canonical type :BIN. That is, if I store source files on VAX VMS and compile
  them both for use under Symbolics Genera and VAXLISP, then it is both
  appropriate and useful that VAXLISP :BIN files be named "something.FAS"
  and Genera :BIN files be named "something.BIN" since then they wouldn't
  clobber each other.

  Pitman supports PATHNAME-CANONICAL-TYPE:NEW-CONCEPT.

∂07-Jul-88  1308	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Jul 88  13:08:04 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430072; Thu 7-Jul-88 16:07:49 EDT
Date: Thu, 7 Jul 88 16:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880707160733.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:        PACKAGE-CLUTTER
References:   LISP package (p181)
Category:     CHANGE/CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  CLtL specifies that

   ``The package named LISP contains the primitives of
     the Common Lisp system. Its external symbols include
     all of the user-visible functions and global variables
     that are present in the Common Lisp system, such as
     CAR, CDR, *PACKAGE*, etc. Almost all other packages will
     want to use LISP so that these symbosl will be accessible
     without qualification.''

  It specifies "all" but not "all and only".

  Some implementations place their extensions in the Lisp package.
  Nothing in CLtL prohibits this, but it leads to problems in general.
  For example:

  - A user defining a function by a name not mentioned in CLtL may be
    surprised to clobber a system function in some implementations

  - In one particular implementation, the variable HELP was a system
    constant, so that ((LAMBDA (HELP) ...HELP...) "Press ? for help.")
    signalled a correctable error (asking what variable to bind
    instead of HELP :-).

Proposal (PACKAGE-CLUTTER:REDUCE):

  Specify that the LISP package must contain not only all the symbols
  mentioned as part of the LISP package in standard, but only those symbols.

  Specify that symbols in the LISP package may not have definitions other
  than those specified.

Examples:

  #1: The symbol HELP may not be on the LISP package because it is not
      mentioned in CLtL.

  #2: The symbol VARIABLE is specified to be on the LISP package (because
      it is a valid second argument to the DOCUMENTATION function). Since
      it is not defined as a variable, type, or function, however, it may
      not be bound, defined as a type, or defined as a function, macro or
      special form.

Rationale:

  If extra symbols are permitted in the LISP package, users may be surprised
  by relationships between the LISP package and other packages which they
  did not expect, or may be surprised by functionality that they did not
  expect. The degenerate case is:

   (DEFCONSTANT LISP:A 'YOU-LOSE)
   (DEFCONSTANT LISP:B 'YOU-LOSE)
   (DEFCONSTANT LISP:C 'YOU-LOSE)   
   ...
   (DEFCONSTANT LISP:AA 'YOU-LOSE)
   (DEFCONSTANT LISP:AB 'YOU-LOSE)
   (DEFCONSTANT LISP:AB 'YOU-LOSE)
   ...etc.

  Given such an implementation, even things like (LAMBDA (X) X) are not
  valid because they attempt to bind "system constants". It is necessary
  that the programmer be able to know for sure that an arbitrary name is
  "free for use" and best way to conveniently assure this is to require
  that the LISP package be unadulterated.

  As for the additional definitions, there are situations where additional
  definitions would cause a problem. For example, if a symbol on the Lisp
  package were declared as a special variable even though that value was
  not mentioned in the standard, that variable would behave incorrectly when
  used as a lexical variable. Similarly, if a symbol in the lisp package
  were defined as an implementation-dependent special form, problems might
  result if a user redefined or even bound (as by FLET or MACROLET) that
  name.

  The LISP package is the foothold from which portable programs establish
  their desired environment. Careful control is desirable to make sure
  everyone is starting off on the right foot.

Current Practice:

  Some implementations have been known to add additional symbols (usually
  functional and/or variable extensions) to the LISP package.

  Symbolics Genera currently has exactly the set of symbols on it which is
  prescribed by CLtL. A few symbols, such as EVALHOOK, ROOM, and APPLYHOOK
  are spuriously defined as special variables. The symbol LAMBDA is defined
  as a macro. There may be a few other exceptions like this.

Cost to Implementors:

  The actual cost of moving the symbols out of the LISP package in cases
  where they are not already gone is quite small. However, if any
  implementation really has to do this, it may have a number of suppositions
  about what is in what package, and the changes could potentially be extensive.

Cost to Users:

  This change is upward compatible with any portable program, but users
  of a particular implementation's extensions may be forced to find their
  functions in a different package, so there may be a measurable practical
  cost.

  In many cases where an extension symbol FOO is simply expected to have
  been directly available (due to :USE "LISP"), it will work to just just
  do (IMPORT 'new-home-package-for-foo:FOO) where the user's package is
  declared.

  In many cases where an extension symbol FOO is used by explicit package
  prefix, such as LISP:FOO, it should be easy to search for `LISP:FOO' or
  even `LISP:' to find the cases.

Cost of Non-Adoption:

  The potential for the LISP package to be adulterated and for supposedly
  portable programs to have difficulty getting a foothold in some
  implementations will be `noticeably non-zero'.

Benefits:

  Portability of some programs will be enhanced.

Aesthetics:

  This change probably supports the naive expectation of most programmers
  writing portable code.

Discussion:

  This issue came up a while back on Common-Lisp list. It got bogged down in
  discussions of what the USER package and other system-specific packages might
  contain. This proposal avoids the sticky issue of whether the USER package may
  contain symbols other than those specified in the standard. The smart programmer
  of portable code will never rely on the contents of the USER package anyway.

  Pitman supports PACKAGE-CLUTTER:REDUCE.

∂07-Jul-88  1312	CL-Cleanup-mailer 	Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Jul 88  13:12:42 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430076; Thu 7-Jul-88 16:12:27 EDT
Date: Thu, 7 Jul 88 16:12 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880707161211.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Issue:          IN-PACKAGE-FUNCTIONALITY
References:     IN-PACKAGE (p183)
Category:       CHANGE
Edit history:   07-Jul-88, Version 1 by Pitman
Related-Issues: DEFPACKAGE
Status:	        For Internal Discussion

Problem Description:

  There are two typical uses for IN-PACKAGE -- to define/create a package
  and to select a package. The fact that these two purposes have been
  given to the same function has led to reduced error checking.

Proposal (IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY):

  Eliminate the ability of IN-PACKAGE to create a package on demand.
  Require IN-PACKAGE to signal an error if the package does not exist.

  Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
  are no longer needed.

  Clarify that DEFPACKAGE is the preferred way to declare a package,
  and MAKE-PACKAGE is the preferred way to construct a package at runtime.

  Eliminate the compile-time processing requirement for all package-related
  functions except IN-PACKAGE and DEFPACKAGE.

Test Case:

  #1: (IN-PACKAGE 'NO-SUCH-PACKAGE) 		;signals an error

  #2: (DEFPACKAGE FOO ...options...)		;defines/creates a package
      (IN-PACKAGE 'FOO)				;selects an existing package

Rationale:

  This would greatly improve error checking and modularity, with only minimal
  loss of functionality. Any call to IN-PACKAGE which really needed to
  demand-create a package could be rewritten as a DEFPACKAGE followed by an
  IN-PACKAGE.

Current Practice:

  Probably no one implements this behavior since it's in direct
  contradiction of both the definitions and numerous examples in CLtL.

Cost to Implementors:

  This change would be straightforward to implement.
  The cost may not be trivial in all cases, but should not be very large.

Cost to Users:

  In most cases, minor syntactic changes to some files would be necessary.

  In many cases, no changes would be necessary since files may already be
  doing IN-PACKAGE in situations where the author is hoping he's made sure
  the real package declaration is already loaded.

Cost of Non-Adoption:

  Reduced error checking.

  Less modular code.

Benefits:

  Errors due to demand-creation of a package by IN-PACKAGE without appropriate
  uses of the :USE or :NICKNAMES or without appropriate calls to EXPORT, etc.
  afterward would be easier to detect.

  Modular package declarations would be encouraged.

Aesthetics:

  The fact that IN-PACKAGE is currently ambiguous about intent (whether the
  package should exist already or not) is clearly not aesthetic. This change
  would be an aesthetic improvement.

Discussion:

  Pitman supports IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY.

  As written, this proposal is necessarily contingent on DEFPACKAGE:ADDITION.
  Note, however, that the attempt by this proposal to reduce the set
  of arguments allowed to IN-PACKAGE is not inconsistent with the attempt by 
  DEFPACKAGE:ADDITION to increase the set of arguments. That proposal,
  which is a compatible addition, presupposes that IN-PACKAGE is still
  usable both for selection and creation, so it correctly attempts to
  generalize the arguments it requires. This proposal, which is an
  incompatible change, uses DEFPACKAGE as a foothold to change the model
  of how IN-PACKAGE is used -- only once that new model is in place does
  it make sense to consider eliminating arguments to IN-PACKAGE.

∂08-Jul-88  0310	CL-Cleanup-mailer 	Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)   
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 8 Jul 88  03:09:57 PDT
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa04525; 8 Jul 88 10:07 BST
Received: from xenakis by mordell.maths.bath.AC.UK id aa24723;
          8 Jul 88 10:26 BST
To: KMP@scrc-stony-brook.arpa
CC: CL-Cleanup@sail.stanford.edu
In-reply-to: Kent M Pitman's message of Thu, 7 Jul 88 16:12 EDT <880707161211.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
Date: Fri, 8 Jul 88 10:26:07 BST
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK

I support strongly the IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY proposal.
I have been confused by the dual use of IN-PACKAGE which is not
helpful.
==John

∂08-Jul-88  0541	CL-Cleanup-mailer 	Issue: PATHNAME-CANONICAL-TYPE (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88  05:41:28 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430361; Fri 8-Jul-88 08:41:10 EDT
Return-path: <spt!gz@EDDIE.MIT.EDU>
Received: from EDDIE.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430318; 8 Jul 88 03:37:40 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA17975@EDDIE.MIT.EDU>; Fri, 8 Jul 88 03:37:19 EDT
Received: by spt.entity.com (smail2.5); 8 Jul 88 02:56:28 EDT (Fri)
Date: 8 Jul 88 02:56:28 EDT (Fri)
From: gz@spt.entity.com (Gail Zacharias)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <880707143558.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Message-Id: <8807080256.AA14902@spt.entity.com>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 8 Jul 88 08:41 EDT
Resent-Message-ID: <880708084100.2.KMP@PEWEE.SCRC.Symbolics.COM>

In many environments where lisps operate, "binary" refers to something other
than compiled lisp files (e.g., the executable files of the host system).
Therefore I think the use of :BIN for compiled lisp code is a bad choice, as
it precludes the use of :BIN for implementation-dependent local extensions
where :BIN might be the most natural name (I can imagine some such
implementations ending up with both :BIN and :BINARY, and you have to remember
which is which).  I would prefer :COMPILED-LISP.  Of course implementations
would be free to accept :BIN as a synonym for :COMPILED-LISP (especially in
the cases where compiled lisp files ARE in fact the executable files of the
host system :-).

If you'd prefer something terse, I'd suggest :COMPILED or :LOAD.

∂08-Jul-88  0542	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88  05:42:08 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430362; 8 Jul 88 08:41:44 EDT
Return-path: <spt!gz@EDDIE.MIT.EDU>
Received: from EDDIE.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430319; 8 Jul 88 03:38:09 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA17985@EDDIE.MIT.EDU>; Fri, 8 Jul 88 03:37:44 EDT
Received: by spt.entity.com (smail2.5); 8 Jul 88 03:02:56 EDT (Fri)
Date: 8 Jul 88 03:02:56 EDT (Fri)
From: gz@spt.entity.com (Gail Zacharias)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <880707160733.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 1)
Message-Id: <8807080302.AA14914@spt.entity.com>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 8 Jul 88 08:41 EDT
Resent-Message-ID: <880708084135.3.KMP@PEWEE.SCRC.Symbolics.COM>

How about the use of LISP package symbols for property names?

∂08-Jul-88  0545	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88  05:45:30 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430369; Fri 8-Jul-88 08:45:15 EDT
Return-path: <spt!gz@EDDIE.MIT.EDU>
Received: from EDDIE.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430096; 7 Jul 88 16:36:50 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA05217@EDDIE.MIT.EDU>; Thu, 7 Jul 88 16:36:37 EDT
Received: by spt.entity.com (smail2.5); 7 Jul 88 16:09:32 EDT (Thu)
Date: 7 Jul 88 16:09:32 EDT (Thu)
From: gz@spt.entity.com (Gail Zacharias)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <880705145610.9.KMP@PEWEE.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Message-Id: <8807071609.AA13398@spt.entity.com>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: <880708084513.4.KMP@PEWEE.SCRC.Symbolics.COM>

   Date: Tue, 5 Jul 88 14:56 EDT
   From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

     (PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
     => (:ABSOLUTE "FOO" :WILD "BAR")

I think this is pointless.  Why should there be special syntax for "*" but
not for "x*z"?  It only gives you the ability to detect a small subset of
possible wildcard specs, and it only gives you the ability to construct
a small subset of wildcard specs (and there's nothing equivalent for even
this small subset within file names or types or devices).  It's a hack, which
might get in the way of a more general solution.  Why not just leave everything
as strings for now, and leave other data types for any possible less ad hoc
approaches to the wildcard issues.

∂08-Jul-88  0545	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88  05:45:41 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430370; Fri 8-Jul-88 08:45:25 EDT
Return-path: <spt!gz@EDDIE.MIT.EDU>
Received: from EDDIE.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430095; 7 Jul 88 16:36:39 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA05212@EDDIE.MIT.EDU>; Thu, 7 Jul 88 16:36:27 EDT
Received: by spt.entity.com (smail2.5); 7 Jul 88 16:27:55 EDT (Thu)
Date: 7 Jul 88 16:27:55 EDT (Thu)
From: gz@spt.entity.com (Gail Zacharias)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <880705145610.9.KMP@PEWEE.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Message-Id: <8807071627.AA13436@spt.entity.com>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: <880708084529.5.KMP@PEWEE.SCRC.Symbolics.COM>

The Macintosh has syntax for moving up the directory structure.  This is
similar to Unix's "../", although unlike Unix where there's an explicit ".."
pseudo-component, on the Macintosh it's just syntax.  In any case, I'd like to
see your proposal extended to allow representing upward motion.  Otherwise it
needs to be made clear that counting the number of elements in the
subdirectory list doesn't necessarily say anything about the nesting level of
the directory (it's neither a lower nor an upper bound).

∂08-Jul-88  0546	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88  05:45:58 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430372; Fri 8-Jul-88 08:45:43 EDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430112; Thu 7-Jul-88 16:49:55 EDT
Date: Thu, 7 Jul 88 16:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: gz@spt.entity.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8807071609.AA13398@spt.entity.com>
Message-ID: <880707164958.0.KMP@PEWEE.SCRC.Symbolics.COM>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: <880708084547.7.KMP@PEWEE.SCRC.Symbolics.COM>

    Date: 7 Jul 88 16:09:32 EDT (Thu)
    From: gz@spt.entity.com (Gail Zacharias)

       Date: Tue, 5 Jul 88 14:56 EDT
       From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

	 (PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
	 => (:ABSOLUTE "FOO" :WILD "BAR")

    I think this is pointless.  Why should there be special syntax for "*" but
    not for "x*z"?  It only gives you the ability to detect a small subset of
    possible wildcard specs, and it only gives you the ability to construct
    a small subset of wildcard specs (and there's nothing equivalent for even
    this small subset within file names or types or devices).  It's a hack, which
    might get in the way of a more general solution.  Why not just leave everything
    as strings for now, and leave other data types for any possible less ad hoc
    approaches to the wildcard issues.

I'm not sure of this myself, but I've not studied the issue well enough.
Anyway, it is already institutionalized in that CL already permits :WILD
as a filler of a directory slot even though there might be internal star
matches.

I think the main intent is to allow a person to write a portable call
like (DIRECTORY (MAKE-PATHNAME :NAME "FOO" :TYPE :WILD :VERSION :WILD))
without worrying that "*" might not be the wildcard char in all systems.

It just occurred to me that you are (and I was) supposing that "*" is
what :WILD translates to, but in fact it might not be. I guess I think
it's defensible (albeit less elegant) to support this particular special
case because it does have broader application in portable programs.

Btw, even systems which support embedded "*" disagree as to its
treatment. In some (eg, ITS) the * matches exactly one char, while in
others (eg, Unix or Lispm), it matches any number of chars.
Interestingly, ITS agrees however that when "*" stands alone that it
matches a variable number of chars...

∂08-Jul-88  0546	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88  05:45:56 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430371; Fri 8-Jul-88 08:45:35 EDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430107; Thu 7-Jul-88 16:43:50 EDT
Date: Thu, 7 Jul 88 16:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: gz@spt.entity.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8807071627.AA13436@spt.entity.com>
Message-ID: <880707164340.9.KMP@PEWEE.SCRC.Symbolics.COM>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: <880708084539.6.KMP@PEWEE.SCRC.Symbolics.COM>

    Date: 7 Jul 88 16:27:55 EDT (Thu)
    From: gz@spt.entity.com (Gail Zacharias)

    The Macintosh has syntax for moving up the directory structure.  This is
    similar to Unix's "../", although unlike Unix where there's an explicit ".."
    pseudo-component, on the Macintosh it's just syntax.  In any case, I'd like to
    see your proposal extended to allow representing upward motion.  Otherwise it
    needs to be made clear that counting the number of elements in the
    subdirectory list doesn't necessarily say anything about the nesting level of
    the directory (it's neither a lower nor an upper bound).

If (CAR (PATHNAME-DIRECTORY ...)) yields (:ABSOLUTE . something), then 
if (NOT (MEMBER :WILD-INFERIORS something)) then (LENGTH something) is
the absolute nesting level. If (MEMBER :WILD-INFERIORS something), then
I think (- (LENGTH something) (COUNT :WILD-INFERIORS something)) is a
lower bound on the nesting level.

The idea would be for all such funny syntaxes to be relegated to :RELATIVE.
The lispm represents relative pathnames like lispm's "<<foo>bar.lisp"
as (MAKE-PATHNAME :DIRECTORY (:RELATIVE :UP :UP "FOO") :NAME "BAR" :TYPE "LISP").
I'll have to study how it does merging before sending out a proposal, but
do you see any obvious problems with this notation?

∂08-Jul-88  0546	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88  05:46:11 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430373; Fri 8-Jul-88 08:45:51 EDT
Return-path: <spt!gz@EDDIE.MIT.EDU>
Received: from EDDIE.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430344; 8 Jul 88 06:13:33 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA20751@EDDIE.MIT.EDU>; Fri, 8 Jul 88 06:13:15 EDT
Received: by spt.entity.com (smail2.5); 8 Jul 88 05:55:05 EDT (Fri)
Date: 8 Jul 88 05:55:05 EDT (Fri)
From: gz@spt.entity.com (Gail Zacharias)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
In-Reply-To: <880707164958.0.KMP@PEWEE.SCRC.Symbolics.COM>,
	     <880707164340.9.KMP@PEWEE.SCRC.Symbolics.COM>
Message-Id: <8807080555.AA15328@spt.entity.com>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: <880708084555.8.KMP@PEWEE.SCRC.Symbolics.COM>

   Date: Thu, 7 Jul 88 16:49 EDT
   From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
   Anyway, it is already institutionalized in that CL already permits :WILD
   as a filler of a directory slot even though there might be internal star
   matches.

Oops, you're right, I forgot all about this.  "Never mind".

   Date: Thu, 7 Jul 88 16:43 EDT
   From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
   If (CAR (PATHNAME-DIRECTORY ...)) yields (:ABSOLUTE . something), then 
   if (NOT (MEMBER :WILD-INFERIORS something)) then (LENGTH something) is
   the absolute nesting level.

I don't think (member :wild-inferiors ...) is sufficient.  What about
implementations that allow more than one way to specify multi-level inferiors
(e.g. something along the lines of "x**y").  Such implementations can pick one
pattern to be represented by :WILD-INFERIORS, but they can't replace *every*
multi-level pattern with :WILD-INFERIORS without losing information.  So
there's no implementation-independent way of getting an upper bound (or more
generally of knowing for certain whether a given component is wild or not).

It might be better for the subdirectory list to be just a list of <whatever>'s,
and provide predicates for testing components for wildness and/or
multi-levelness.  (:WILD and :WILD-INFERIORS could still be required to be
recognized on input).  I think :UP might just be a keyword, since I can't
imagine there being more than one way of moving up.  But maybe this should
be a predicate as well just in case.
Another possibility might be for a component to be either a string
or a list (string . properties), where properties would be things like
:WILD, :RESTRICTED-WILD, :MULTI-LEVEL, :UP.  A plain string means it's
a simple (non-wild) component.

                             If (MEMBER :WILD-INFERIORS something), then
   I think (- (LENGTH something) (COUNT :WILD-INFERIORS something)) is a
   lower bound on the nesting level.
   The idea would be for all such funny syntaxes to be relegated to :RELATIVE.

I think then that you're overloading :ABSOLUTE to mean both rooted and
canonicalized.  A unix name like "/foo/bar/../baz/" is fully rooted even
though it contains some relative motion within it.  It's functionally (in the
file system) fully equivalent to "/foo/baz/", but it might not be equivalent
programmatically (i.e. it might intentionally appear in the middle of some
pathname-manipulating algorithm).  Just on general principle, if a user says
"/foo/bar/../baz/", I would not feel comfortable with the loss of information
inherent in *automatically* reducing that to "/foo/baz/" at the pathname
level.  I think of this as a TRUENAME-level action.

In fact, a TRUENAME-like function, say STANDARDIZE-PATHNAME, which didn't
actually require the file (or the directory) to exist, but just did as much
canonicalization as possible, might solve some of these problems.  We (Coral)
have an internal function like that, it expands lisp-defined logical names and
removes syntactically redundant subdirectory motion (as well as any unnecessary
quoting).  It's useful.  Handling subdirectory structures is much simpler if
you can get the system to standardize them for you first.

One more observation, about the :ABSOLUTE/:RELATIVE distinction.  The Macintosh
has a hierarchical file system, and relative pathnames, but it doesn't have a
root directory.  Pathnames are rooted at the device, sort of like twenex
(except twenex doesn't really deal with relative pathnames.  Maybe VMS is a
better analogy).  Anyhow what this means is that being absolute or relative is
not a property of the directory alone, it's a property of the device/directory
pair.  This isn't really a big deal, as I'm sure we can come up with some set
of conventions, but it does seem like it would introduce unnecessary conceptual
hair for our non-jet-setting users (i.e. Mac folks who don't really know from
other file systems).  I think I would prefer the following option from your
discussion section, as being less intrusive for hierarchical file systems
without a root directory:
   - Never using :ABSOLUTE, but requiring that to represent the root
     directory, you must use the symbol :ROOT as the filler for the
     directory slot.
I interpret this to mean that on unix, "foo/bar/" would be ("foo" "bar")
while "/foo/bar/" would be (:ROOT "foo" "bar").  With that interpretation,
I would also:
 . state that this is the convention for output from pathname accessors, and
   that using it on input to constructors may be non-portable (it would
   signal an error in file systems without a root directory)
 . state that the presence of :ROOT (probably?) means the pathname is absolute,
   but the converse is not necessarily true (in particular it's false in file
   systems without a root directory).
 . add a predicate which takes a pathname and tells you if the pathname
   as a whole is absolute (i.e. independent of any "current directory").

∂08-Jul-88  1028	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Jul 88  10:28:30 PDT
Received: by labrea.stanford.edu; Fri, 8 Jul 88 10:28:04 PDT
Received: from bhopal.lucid.com by edsel id AA06008g; Fri, 8 Jul 88 10:21:41 PDT
Received: by bhopal id AA15658g; Fri, 8 Jul 88 10:21:40 PDT
Date: Fri, 8 Jul 88 10:21:40 PDT
From: Jim McDonald <edsel!jlm@labrea.stanford.edu>
Message-Id: <8807081721.AA15658@bhopal.lucid.com>
To: gz@spt.entity.com
Cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: Gail Zacharias's message of 8 Jul 88 05:55:05 EDT (Fri) <8807080555.AA15328@spt.entity.com>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)


>                         I think :UP might just be a keyword, since I can't
>  imagine there being more than one way of moving up.  

Assume you are using some version of un*x, and that /foo/b1/b2 is a
symbolic link to directory /foo/a1/a2/a3.  

Then using csh, after cd /foo/b1/b2/.., pwd will show /foo/a1/a2,
 but using bsh, after cd /foo/b1/b2/.., pwd will show /foo/b1.

I.e., if you are trying to emulate the behavior of csh, you must wait
until the truename is resolved before knowing where :UP will lead you.

In Lucid Common Lisp for the Sun-3, I get the following behavior,
assuming /u/jlm/b1/b2 is a symbolic link to ../a1/a2/a3, and all the
relevant directories actually exist:

> (cd "/u/jlm/")
#P"/u/jlm/"
> (setq aa (pathname "b1/b2/.."))
#P"b1/b2/.."
> (cd aa)
#P"/u/jlm/a1/a2/"
> 

The moral is that (not (eq :UP :UNDO)).

  jlm

∂08-Jul-88  1420	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 7)  
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 8 Jul 88  14:16:21 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA00143; Fri, 8 Jul 88 17:13:45 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA24313; Fri, 8 Jul 88 16:58:13 EDT
Message-Id: <8807082058.AA24313@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 7)
Date: Fri, 08 Jul 88 16:58:07 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

Issue:         STANDARD-INPUT-INITIAL-BINDING
References:    Standard streams (pp. 327-329)
Category:      CHANGE
Edit history:  Version 1 by Pierson and Haflich 1/19/87
    	       Version 2 by Pierson 2/29/88
	       Version 3 by Pierson 5/23/88, per comments by Moon
               Version 4 by Pierson 5/26/88, clean up
    	       Version 5 by Pierson 6/28/88, simple design per Masinter
    	       Version 6 by Pierson 7/ 5/88, clean up and split issue
	       Version 7 by Pierson 7/ 8/88, clean up per Pitman
Status:        For Internal Discussion

Problem description:

CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*.  This requirement
hampers the integration of Common Lisp with many existing and
potential operating environments.

For example, a Unix implementation is currently unable to legally
support Unix standard error output even though Common Lisp defines
*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
to the same stream as *STANDARD-OUTPUT*.  A workstation environnment
which provides stream access to windows as an extension is currently
forbidden to make trace output appear in a separate window by default
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.

Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):

A Common Lisp implementation is required to provide the following
initial streams.  Each initial stream has a specific purpose as
defined in CLtL.  This proposal redefines the initial bindings of
the streams and leaves the rest of the CLtL description unchanged.

    *TERMINAL-IO*
    *STANDARD-INPUT*
    *STANDARD-OUTPUT*
    *ERROR-OUTPUT*
    *TRACE-OUTPUT*
    *QUERY-IO*
    *DEBUG-IO*

    	The initial bindings of these variables are undefined except
	that:
	    1. They are all initially bound to open streams.
	    2. The streams must support input and/or output as
	       indicated by the variable name.
    	    3. None of the standard streams (including *TERMINAL-IO*)
	       may be directed by synonym streams to another of these
	       stream variables (except *TERMINAL-IO*), whether
	       directly or by indirection via some composite stream
	       such as a two way stream with one of the arms being a
	       synonym stream.
	    4. Any or all of these streams may be synonyms for the a
	       common implementation dependent stream.  For example,
	       in an interactive Common Lisp invocation running on a
	       character terminal, all of the streams mentioned here
	       might be synonym streams (or two-way streams to synonym
	       streams) to a pair of hidden terminal input/output
	       streams maintained by the implementation.

	The intent of the above rules is to ensure that it is always
	safe to bind any of the above variables to another of the
	above variables without unduly restricting implementation
	flexibility.


Test Cases/Examples:

(PROGN
   (PRINT "Output" *STANDARD-OUTPUT*)
   (PRINT "Error" *ERROR-OUTPUT*))

In current Common Lisp will write:
    ------
    Output
    Error
    ------

With proposal *might* write:
    ------
    Output
    ------
    and "Error" appears somewhere else.


(LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
  ...)

In current Common Lisp: 
    Might cause a circular stream reference if *DEBUG-IO* was
    bound to a two-way stream made up of synonym streams to
    *STANDARD-INPUT* and *STANDARD-OUTPUT*.

With this proposal:
    Would be guaranteed not to cause a circular stream reference.


(LET ((*STANDARD-INPUT*  *TERMINAL-IO*)
      (*STANDARD-OUTPUT* *TERMINAL-IO*))
  ...)

In current Common Lisp: 
    Might cause a circular stream reference because *TERMINAL-IO* was
    bound to a two-way stream made up of synonym streams to
    *STANDARD-INPUT* and *STANDARD-OUTPUT*.

With this proposal:
    Would be guaranteed not to cause a circular stream reference.


Rationale:

This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output.

Current practice:

Lucid binds *TERMINAL-IO* to a special internal stream type.  Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output.  KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output.  Symbolics Genera binds *TERMINAL-IO* as appropriate for each
process, usually to a window for interactive applications or to a
stream which will conjure an interaction window on demand for
background tasks.

Cost to Implementors:

All implementations will have to change to some degree but the changes
will probably be simple and localized.  All known implementations
already support the underlying streams required to implement this
proposal.

Cost to Users:

User code which depends on the strict binding hierarchy in CLtL may
have to change.  

Cost of non-Adoption:

It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.

Benefits:

Implementations will be more able to match their IO behavior to their
environment and their user's expectations.

Aesthetics:

Improved because this area becomes better defined.

Discussion:

Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
*DEBUG-IO*) should fail to work in a non-interactive environment where
nothing like a terminal exists.  This proposal fails to address this.

Masinter notes that:
    ``In many multi-processing multi-window environments,
      the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
      differs for each process.''  

Pierson supports STANDARD-OUTPUT-INITIAL-BINDING:DEFINED-CONTRACTS.

∂08-Jul-88  1457	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 7)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88  14:57:10 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430755; Fri 8-Jul-88 17:56:11 EDT
Date: Fri, 8 Jul 88 17:56 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 7)
To: pierson%mist@MULTIMAX.ARPA
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8807082058.AA24313@mist.UUCP>
Message-ID: <880708175600.2.KMP@PEWEE.SCRC.Symbolics.COM>

Minor residual nit picking...

 * In the Proposal section, numbered item 4, end of line 1, the
   typo "the a" still appears.

 * In the second example, you are guaranteed that this works only
   if you haven't changed the value of *DEBUG-IO*. Note that, unlike
   the third example which uses the variable *TERMINAL-IO* which
   users are forbidden to change, *DEBUG-IO* has no such restriction.
   Since your proposal says clearly that these are constraints only
   on the initial values, the claim on the second example is a bit
   strong. [I would be ammenable to expanding the proposal to say that 
   it `is an error' (ie, has undefined effects) if you do any later
   bindings or assignments which invalidates one of the assertions you
   have listed.

In spite of the above, it's ok to go ahead and start listing me as a
supporter of this proposal.

∂08-Jul-88  1522	CL-Cleanup-mailer 	Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)  
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 8 Jul 88  15:22:13 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA00490; Fri, 8 Jul 88 18:19:43 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA24471; Fri, 8 Jul 88 18:23:54 EDT
Message-Id: <8807082223.AA24471@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
Date: Fri, 08 Jul 88 18:23:52 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

I've finally changed the status to "Ready for Release?".  Does anyone
disagree? 

Issue:         STANDARD-INPUT-INITIAL-BINDING
References:    Standard streams (pp. 327-329)
Category:      CHANGE
Edit history:  Version 1 by Pierson and Haflich 1/19/87
    	       Version 2 by Pierson 2/29/88
	       Version 3 by Pierson 5/23/88, per comments by Moon
               Version 4 by Pierson 5/26/88, clean up
    	       Version 5 by Pierson 6/28/88, simple design per Masinter
    	       Version 6 by Pierson 7/ 5/88, clean up and split issue
	       Version 7 by Pierson 7/ 8/88, clean up per Pitman
	       Version 8 by Pierson 7/ 8/88, yet more clean up
Status:        Ready for Release?

Problem description:

CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*.  This requirement
hampers the integration of Common Lisp with many existing and
potential operating environments.

For example, a Unix implementation is currently unable to legally
support Unix standard error output even though Common Lisp defines
*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
to the same stream as *STANDARD-OUTPUT*.  A workstation environnment
which provides stream access to windows as an extension is currently
forbidden to make trace output appear in a separate window by default
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.

Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):

A Common Lisp implementation is required to provide the following
initial streams.  Each initial stream has a specific purpose as
defined in CLtL.  This proposal redefines the initial bindings of
the streams and leaves the rest of the CLtL description unchanged.

    *TERMINAL-IO*
    *STANDARD-INPUT*
    *STANDARD-OUTPUT*
    *ERROR-OUTPUT*
    *TRACE-OUTPUT*
    *QUERY-IO*
    *DEBUG-IO*

    	The initial bindings of these variables are undefined except
	that:
	    1. They are all initially bound to open streams.
	    2. The streams must support input and/or output as
	       indicated by the variable name.
    	    3. None of the standard streams (including *TERMINAL-IO*)
	       may be directed by synonym streams to another of these
	       stream variables (except *TERMINAL-IO*), whether
	       directly or by indirection via some composite stream
	       such as a two way stream with one of the arms being a
	       synonym stream.
	    4. Any or all of these streams may be synonyms for the
	       common implementation dependent stream.  For example,
	       in an interactive Common Lisp invocation running on a
	       character terminal, all of the streams mentioned here
	       might be synonym streams (or two-way streams to synonym
	       streams) to a pair of hidden terminal input/output
	       streams maintained by the implementation.

	The intent of the above rules is to ensure that it is always
	safe to bind any of the above variables to another of the
	above variables without unduly restricting implementation
	flexibility.


Test Cases/Examples:

(PROGN
   (PRINT "Output" *STANDARD-OUTPUT*)
   (PRINT "Error" *ERROR-OUTPUT*))

In current Common Lisp will write:
    ------
    Output
    Error
    ------

With proposal *might* write:
    ------
    Output
    ------
    and "Error" appears somewhere else.


(LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
  ...)

In current Common Lisp: 
    Might cause a circular stream reference if *DEBUG-IO* was
    bound to a two-way stream made up of synonym streams to
    *STANDARD-INPUT* and *STANDARD-OUTPUT*.

With this proposal:
    Would be guaranteed not to cause a circular stream reference
    unless the initial value of *DEBUG-IO* had been changed to a value
    that did not conform the restrictions in this proposal.  While no
    Common Lisp implementation should do this, a user program might.


(LET ((*STANDARD-INPUT*  *TERMINAL-IO*)
      (*STANDARD-OUTPUT* *TERMINAL-IO*))
  ...)

In current Common Lisp: 
    Might cause a circular stream reference because *TERMINAL-IO* was
    bound to a two-way stream made up of synonym streams to
    *STANDARD-INPUT* and *STANDARD-OUTPUT*.

With this proposal:
    Would be guaranteed not to cause a circular stream reference.


Rationale:

This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output.

Current practice:

Lucid binds *TERMINAL-IO* to a special internal stream type.  Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output.  KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output.  Symbolics Genera binds *TERMINAL-IO* as appropriate for each
process, usually to a window for interactive applications or to a
stream which will conjure an interaction window on demand for
background tasks.

Cost to Implementors:

All implementations will have to change to some degree but the changes
will probably be simple and localized.  All known implementations
already support the underlying streams required to implement this
proposal.

Cost to Users:

User code which depends on the strict binding hierarchy in CLtL may
have to change.  

Cost of non-Adoption:

It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.

Benefits:

Implementations will be more able to match their IO behavior to their
environment and their user's expectations.

Aesthetics:

Improved because this area becomes better defined.

Discussion:

Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
*DEBUG-IO*) should fail to work in a non-interactive environment where
nothing like a terminal exists.  This proposal fails to address this.

Masinter notes that:
    ``In many multi-processing multi-window environments,
      the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
      differs for each process.''  

Pierson and Pitman support STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS.

∂11-Jul-88  0856	CL-Cleanup-mailer 	subtypep vagueness   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Jul 88  08:56:39 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA06413; Mon, 11 Jul 88 09:56:13 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA22689; Mon, 11 Jul 88 09:55:58 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807111555.AA22689@cdr.utah.edu>
Date: Mon, 11 Jul 88 09:55:52 MDT
Subject: subtypep vagueness
To: cl-cleanup@sail.stanford.edu

While trying to build CLX under (the original) HPCL, I've run into a problem
with the rather vague specification of when SUBTYPEP is allowed to say that
it can't determine the relationship between the two types.  The particular
problem I've run into is:

    (subtypep '(simple-array (unsigned-byte 8) (*)) 'sequence) => T T

    (deftype foo () '(simple-array (unsigned-byte 8) (*)))
    (subtypep 'foo 'sequence) => NIL NIL

Although this behavior is certainly inconvenient, my reading of CLtL
indicates that it's legitimate, since there's no statement of exactly
what cases SUBTYPEP is allowed to give up on.  However, this makes
SUBTYPEP pretty hard to use in a portable way.  Is there any interest
in putting together a proposal that sets out a minimum set of cases
that SUBTYPEP must be able to resolve?

-Sandra
-------

∂11-Jul-88  1023	CL-Cleanup-mailer 	Re: subtypep vagueness    
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 11 Jul 88  10:23:34 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA05135; Mon, 11 Jul 88 13:19:51 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA00352; Mon, 11 Jul 88 13:23:24 EDT
Message-Id: <8807111723.AA00352@mist.UUCP>
To: sandra%cdr%cs.utah.edu@multimax (Sandra J Loosemore)
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: subtypep vagueness 
In-Reply-To: Your message of Mon, 11 Jul 88 09:55:52 -0600.
             <8807111555.AA22689@cdr.utah.edu> 
Date: Mon, 11 Jul 88 13:23:20 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

I would certainly like to see such a proposal.

∂11-Jul-88  1029	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Jul 88  10:29:05 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA09454; Mon, 11 Jul 88 11:28:48 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA22729; Mon, 11 Jul 88 11:28:44 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807111728.AA22729@cdr.utah.edu>
Date: Mon, 11 Jul 88 11:28:42 MDT
Subject: issue BOGUS-FIXNUMS (initial draft)
To: cl-cleanup@sail.stanford.edu


Issue:		BOGUS-FIXNUMS
References:	CLtL p. 14, 34, 43, 231
Category:	CHANGE
Edit History:   Version 1, 11 Jul 1988 (Sandra Loosemore)


Problem Description: 

Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums.  While in many
implementations these correspond to different internal
representations, some implementations may support only a single
representation for all integers.  In such a case, arbitrarily
designating some subrange of integers as "fixnums" becomes an
artificial contrivance which is more likely to confuse users than to
ensure portability of code.


Proposal: BOGUS-FIXNUMS:ELIMINATE-DISTINCTION

(1) Remove all references to the partitioning of the type INTEGER into
FIXNUM and BIGNUM.  Remove FIXNUM and BIGNUM from the table of standard
type specifier symbols on page 43 of CLtL.

(2) Remove the constants MOST-POSITIVE-FIXNUM and MOST-NEGATIVE-FIXNUM
from the language.  

(3) Introduce a new constant, MAX-INTEGER-LENGTH.  This is the maximum
number of bits appearing in any integer; therefore, it is an upper
bound on the INTEGER-LENGTH function.  The value can be NIL if there
are no limits short of memory availability.


Rationale:

Since CLtL does not guarantee anything about the range of fixnums
(saying only that they will *typically* be between -2**n and 2**n - 1,
for n not less than 15), any user program that uses FIXNUM or BIGNUM
declarations is already nonportable.  Using these type specifiers for
discrimination is also of questionable utility in portable code.  In
removing these type specifiers from the language standard, this proposal has
no effect on portability.


Current Practice:

KCL has only a single representation for integers, as do a number of
Common Lisp subsets (including XLisp and A-Lisp).  Some Lisps have
more than two representations for integers; PSL, for example, has
three different representations, similar to Lisp 1.6.  Franz Lisp and
Interlisp also have three different integer representations.

Implementations do not necessarily limit bignum size only by the amount of
"available memory" (which is a rather vague concept anyway).  For example,
many implementations restrict the length of the bignum to be representable
in a fixed-length field.


Cost to implementors:

Slight.  Implementations that support different representations for fixnums
and bignums can continue to do so and provide the type specifiers as a
compatible extension.


Cost to users:

Slight, at least in portable code.  If implementors continue to
support the FIXNUM and BIGNUM type specifiers, existing (nonportable)
user code that relies on them would continue to work in those
implementations.  It's possible that some portable user programs
actually use the value of MOST-POSITIVE-FIXNUM or MOST-NEGATIVE-FIXNUM
(for example, to scale fixed-point values to fit in a fixnum).


Benefits:

Removing the distinction between fixnums and bignums simplifies the
language.  It reduces ambiguity in the case where there are more than
two integer representations. 

Introducing a new constant to describe the maximum size of integers makes
it possible to describe an implementation's exact limitations on the range
of integers it supports.  This constant would also be useful for the
description of subset implementations.


Discussion:

Addition of the MAX-INTEGER-LENGTH constant was suggested by Stan Shebs,
who supports this proposal.-------

∂11-Jul-88  1034	CL-Cleanup-mailer 	Re: subtypep vagueness    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jul 88  10:34:23 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 JUL 88 10:28:01 PDT
Date: 11 Jul 88 10:27 PDT
From: masinter.pa@Xerox.COM
Subject: Re: subtypep vagueness
In-reply-to: sandra%cdr@cs.utah.edu (Sandra J Loosemore)'s message of Mon, 11
 Jul 88 09:55:52 MDT
To: sandra%cdr@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880711-102801-6870@Xerox>

please -- why don't you make a stab at it? Start with the cases that HPCL didn't
do that you found inconvenient for portable code.


∂11-Jul-88  1059	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2) 
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Jul 88  10:59:32 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA00797@EDDIE.MIT.EDU>; Mon, 11 Jul 88 13:57:24 EDT
Received: by spt.entity.com (smail2.5); 11 Jul 88 10:37:26 EDT (Mon)
To: edsel!jlm@labrea.stanford.edu
Cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: Jim McDonald's message of Fri, 8 Jul 88 10:21:40 PDT <8807081721.AA15658@bhopal.lucid.com>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Message-Id: <8807111037.AA02007@spt.entity.com>
Date: 11 Jul 88 10:37:26 EDT (Mon)
From: gz@spt.entity.com (Gail Zacharias)

   Date: Fri, 8 Jul 88 10:21:40 PDT
   From: Jim McDonald <edsel!jlm@labrea.stanford.edu>
   >                         I think :UP might just be a keyword, since I can't
   >  imagine there being more than one way of moving up.  
   ...
   Then using csh, after cd /foo/b1/b2/.., pwd will show /foo/a1/a2,
    but using bsh, after cd /foo/b1/b2/.., pwd will show /foo/b1.

Right you are.  Of course Unix doesn't have any syntax which would allow the
pathname itself to specify which variant it wants, but some other system
might.  So this does show that it would be unwise to assume that every
implementation would be able to represent all upward motion in pathnames with
a single token such as :UP.

∂11-Jul-88  1313	CL-Cleanup-mailer 	SUBTYPEP-TOO-VAGUE (initial draft)  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Jul 88  13:13:08 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA14917; Mon, 11 Jul 88 14:12:52 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA22808; Mon, 11 Jul 88 14:12:48 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807112012.AA22808@cdr.utah.edu>
Date: Mon, 11 Jul 88 14:12:47 MDT
Subject: SUBTYPEP-TOO-VAGUE (initial draft)
To: cl-cleanup@sail.stanford.edu

Issue:		SUBTYPEP-TOO-VAGUE
References:	CLtL p. 72-73
Category:	CLARIFICATION
Edit History:   Version 1, 11 Jul 1988 (Sandra Loosemore)


Problem Description:

The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined.  In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier). 

Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship.  This makes it difficult to depend on
subtype relationships in portable code.


Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY

(1) Clarify that SUBTYPEP is allowed to return a second value of NIL
only when either of the type specifiers involves the SATISFIES, NOT,
AND, OR, the list form of FUNCTION, or VALUES type specifiers.

(2) If a type specifier defined with DEFTYPE is passed to SUBTYPEP,
SUBTYPEP must treat it in the same way as if its expansion were passed
instead.

(3) Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation.  For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).


Rationale:

It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
AND, OR, and NOT are messy to deal with. (MEMBER falls into the same
section but is easy to do).  I don't know how one would compare
FUNCTION or VALUES type specifiers; some rules could be established to
clarify how to compare them but I don't think it would would be
particularly useful to do so. 


Current Practice:

The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE.  Most other implementations
appear to be substantially in conformance with the proposal.


Cost to implementors:

Some implementations will have to rewrite and/or extend parts of SUBTYPEP.


Cost to users:

None.


Benefits:

An area of confusion in the language is cleared up.  Usages of SUBTYPEP
will be more portable.


Discussion:

Item (3) appeared to be the consensus from a discussion on the
common-lisp mailing list some time ago.

A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE.  For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE.  Should this proposal be
extended to deal with these issues, or is another proposal in order?

Do the rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail, or are they obvious?
-------

∂11-Jul-88  1418	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jul 88  14:18:00 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 431776; Mon 11-Jul-88 17:16:39 EDT
Date: Mon, 11 Jul 88 17:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue BOGUS-FIXNUMS (initial draft)
To: sandra%cdr@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8807111728.AA22729@cdr.utah.edu>
Message-ID: <880711171627.4.KMP@PEWEE.SCRC.Symbolics.COM>

This proposal might go over better if we replaced the feature with
another, more portable, feature addressing a similar need. eg,

 FIXNUM could be left undefined as proposed, and then implementations
 could support it as a non-portable extension

but also

 SMALL-INTEGER could be defined as some range of integers which we
 think most implementations can support efficiently (but with the
 understanding that the important thing is to support it correctly
 rather than efficiently). For example, maybe SMALL-INTEGER could
 be defined as (INTEGER -2↑30 (2↑30)). [The specific bounds is open
 to discussion, of course, I'm just proposing ``something like this''.]

 As a corollary, MOST-POSITIVE-EFFICIENTLY-REPRESENTABLE-INTEGER, etc
 might hold an integer (or NIL, if the concept made no sense for some
 reason in a particular implementation -- eg, all numbers were bignums)
 with no necessary relation to the type SMALL-INTEGER. Maybe it could
 just be MOST-POSITIVE-EFFICIENT-INTEGER.

That way, people could declare known-to-be-small integers without
being concerned that some pathological implementation would screw them
by having an ultra-tiny range.

Note also that there'd be a slight two's-complement bias there, but the
alternative seems to be to offer nothing, and I'm not sure that that's
better.

Does anyone think this is worth trying to incorporate with this proposal
to make it more palatable to those who are worried that striking FIXNUM
will lose them functionality. (I don't dispute Sandra's claim that almost
no one knows how to use FIXNUM portably. There are a few, but only very
few, portable uses, and I think not enough to worry about. I'm just
concerned that people use FIXNUM because it's all we offer and that 
perhaps what that really means is not that we should give up on the
feature, but rather that there's such severe need for it that we should
come up with something better.)

∂11-Jul-88  1436	CL-Cleanup-mailer 	Re:  issue BOGUS-FIXNUMS (initial draft) 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 11 Jul 88  14:36:20 PDT
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa06788; 11 Jul 88 22:07 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Mon, 11 Jul 88 21:32:31 bst
Message-Id: <5509.8807112032@aiva.ed.ac.uk>
To: cl-cleanup@sail.stanford.edu, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re:  issue BOGUS-FIXNUMS (initial draft)

> Date: Mon, 11 Jul 88 11:28:42 MDT
> From: sandra <(Sandra J Loosemore)sandra%cdr@edu.utah.cs>

Do I understand this?  You are proposing to eliminate fixnums from
the language?

I would certainly oppose such a change.  Even though fixnums may
differ from implementation to implementation, I want a standard
way to use them when they exist rather than allow implementations
to diverge (so that some call them fixnums, others something else,
and so on).

> Rationale:
> Since CLtL does not guarantee anything about the range of fixnums
> (saying only that they will *typically* be between -2**n and 2**n - 1,
> for n not less than 15), any user program that uses FIXNUM or BIGNUM
> declarations is already nonportable.

This depends on what you count as portable.  There may be no gain
in efficiency, but the program will still work if care is taken
to check the range and in many cases even if not.  Moreover, I
can know that this kind of thing is called "fixnum" and not
something else.

> Current Practice:
> KCL has only a single representation for integers,

It has two -- or three: see Franz below.

> Franz Lisp [has] three different integer representations.

You might say Franz has three, but small fixnums have the same format
as larger ones; the difference is that they live in a known part of
memory and new ones are never allocated.  If you count this as three,
KCL also has three.

> Cost to users:
> Slight, at least in portable code.  If implementors continue to
> support the FIXNUM and BIGNUM type specifiers, existing (nonportable)
> user code that relies on them would continue to work in those
> implementations.

I think it is a mistake to think that "nonportable" code does not count.
It is useful to have a standard way to do something even if it does not
work everywhere, and the optimizations for fixnums are important enough
that most implementations provide some.

I do not accept the argument that it doesn't matter because everyone who
provides fixnums can still provide them.  If they're not in the standard,
users cannot in fact rely on them being provided in a standard way.
Indeed, if we decide to allow only standard symbols in the LISP package,
users would have to type LUCID:FIXNUM, EXCL:FIXNUM, etc. rather than just
FIXNUM as they can now.

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton

∂11-Jul-88  1944	CL-Cleanup-mailer 	SUBTYPEP-TOO-VAGUE (initial draft)  
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Jul 88  19:44:08 PDT
Received: by labrea.stanford.edu; Mon, 11 Jul 88 19:43:23 PDT
Received: from blacksox.lucid.com by edsel id AA19205g; Mon, 11 Jul 88 17:31:13 PDT
Received: by blacksox id AA00951g; Mon, 11 Jul 88 17:27:00 pdt
Date: Mon, 11 Jul 88 17:27:00 pdt
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8807120027.AA00951@blacksox.lucid.com>
To: sandra@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 11 Jul 88 14:12:47 MDT <8807112012.AA22808@cdr.utah.edu>
Subject: SUBTYPEP-TOO-VAGUE (initial draft)

AND, OR and NOT are only messy to deal with if any of the type
specifiers involved use SATISFIES.  Otherwise they are well defined.
I think you should remove AND, OR and NOT from the "exceptions list."

∂12-Jul-88  0247	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 12 Jul 88  02:46:39 PDT
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa03327; 12 Jul 88 10:12 BST
Received: from xenakis by mordell.maths.bath.AC.UK id aa04851;
          12 Jul 88 10:33 BST
To: sandra <@cs.utah.edu:sandra@cdr>
CC: cl-cleanup@sail.stanford.edu
In-reply-to: sandra (Sandra J Loosemore)'s message of Mon, 11 Jul 88 11:28:42 MDT <8807111728.AA22729@cdr.utah.edu>
Subject: issue BOGUS-FIXNUMS (initial draft)
Date: Tue, 12 Jul 88 10:33:24 BST
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK

This looks like a giant step backwards.  Some of us are interested in
writing efficient code.  Even if some machines only have one
representation I find it hard to believe that there are not a subset
which are more efficient.  Are you seriously suggesting that LISP
should counternance numbers not being arbitary precision?

Anyway KCL has fixnum, bignum and short fixnum.

==John

∂12-Jul-88  0926	CL-Cleanup-mailer 	package-clutter:reduce    
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 12 Jul 88  09:26:29 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
	id AA25515; Tue, 12 Jul 88 09:24:27 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb (5.51/1.36)
	id AA02189; Mon, 11 Jul 88 13:03:49 PDT
Date: Mon, 11 Jul 88 13:03:49 PDT
Message-Id: <8807112003.AA02189@trwrb>
To: cl-cleanup@sail.stanford.edu
Subject: package-clutter:reduce

I support this proposal.

∂12-Jul-88  1152	CL-Cleanup-mailer 	Re: issue BOGUS-FIXNUMS (initial draft)  
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 12 Jul 88  11:52:42 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 12 Jul 88 14:51:44 EDT
To: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
cc: sandra <@cs.utah.edu:sandra@cdr>, cl-cleanup@sail.stanford.edu
Subject: Re: issue BOGUS-FIXNUMS (initial draft) 
In-reply-to: Your message of Tue, 12 Jul 88 10:33:24 -0000.
Date: Tue, 12 Jul 88 14:49:53 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU


Striking the FIXNUM type specifier doesn't mean fixnums cease to exist: it
just means this implementation detail is somewhat better hidden.  There
would be nothing to prevent an application that currently uses FIXNUM from
doing:
    (deftype fixnum () '(signed-byte 16))

Or whatever property the program was assuming that FIXNUM had.

Any compiler that can't recognize this deftype as a subtype of its internal
fixnum type (if it in fact is) is broken (not to say that there aren't lots
of broken compilers).


But I think that the issue isn't quite as clear-cut as the anti-fixnums are
making it.  In many implementations, a fixnum type constraint results in a
>10x performance improvement.  People tuning programs for these
implementations cannot ignore this reality, and need some kind of handle on
a "good" integer subrange.

Even if the FIXNUM type specified were flushed, the constants delimiting
the implementation fixnum range should remain.  Of course, with these
constants, once can always:

    (deftype fixnum () `(integer ,most-negative-fixnum ,most-positive-fixnum))

And of course, people will do this.  And their programs will still run
fast, and will still run with no problem on the vast majority of
implementations with a reasonable fixnum size.
 
  Rob

∂12-Jul-88  1253	CL-Cleanup-mailer 	Re: SUBTYPEP-TOO-VAGUE (initial draft)   
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 12 Jul 88  12:52:01 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 12 Jul 88 15:50:38 EDT
To: Eric Benson <edsel!eb@labrea.stanford.edu>
cc: sandra@cs.utah.edu, cl-cleanup@sail.stanford.edu
Subject: Re: SUBTYPEP-TOO-VAGUE (initial draft) 
In-reply-to: Your message of Mon, 11 Jul 88 17:27:00 -0700.
             <8807120027.AA00951@blacksox.lucid.com> 
Date: Tue, 12 Jul 88 15:50:23 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU


    From: Eric Benson <edsel!eb@labrea.stanford.edu>
    Message-Id: <8807120027.AA00951@blacksox.lucid.com>
    To: sandra@cs.utah.edu
    Subject: SUBTYPEP-TOO-VAGUE (initial draft)
    
    AND, OR and NOT are only messy to deal with if any of the type
    specifiers involved use SATISFIES.  Otherwise they are well defined.
    I think you should remove AND, OR and NOT from the "exceptions list."
    
I would change that to say that AND OR and NOT are only *impossible* when
they involve uses of SATISFIES.  They are plenty messy otherwise.  In a
compiler I am working on, I have 1500 lines of hairy and reasonably dense
code for a SUBTYPEP that only partially understands OR and AND, and doesn't
handle NOT at all.  I strongly recommend that SUBTYPEP not be made too firm
until a public domain SUBTYPEP that implements the proposal is available.

How about:
    (subtypep 'integer
	      '(or (rational * (6)) (member 6) (integer 7 *)))

It is fairly easy to see that this is true, but not so easy to see how to
to write a program to solve the general problem.  It might even be a Hard
Problem, given that we have the capability to describe infinite sets.


Even Sandra's proposal may be more hairy than it is worth forcing on the
Common Lisp community.  The MEMBER specifier can also be pretty perverse,
for example: 
    (subtypep '(integer 3 11) '(member 3 4 9 5 6 10 7 11 8 17 15)) => T, T

Any how many SUBTYPEPs correctly recognize that float types are finite?
    (subtypep `(short-float 0s0 (,(* short-float-epsilon 4)))
	      `(member 0s0
		       ,(* short-float-epsilon 1)
		       ,(* short-float-epsilon 2)
		       ,(* short-float-epsilon 3))) => T, T

  Rob

∂12-Jul-88  1302	CL-Cleanup-mailer 	SUBTYPEP-TOO-VAGUE (initial draft)  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 12 Jul 88  13:02:03 PDT
Return-Path: <gls@Think.COM>
Received: from brigit.think.com by Think.COM; Tue, 12 Jul 88 15:04:50 EDT
Received: by brigit.think.com; Tue, 12 Jul 88 15:59:28 EDT
Date: Tue, 12 Jul 88 15:59:28 EDT
From: gls@Think.COM
Message-Id: <8807121959.AA13736@brigit.think.com>
To: Rob.MacLachlan@wb1.cs.cmu.edu
Cc: edsel!eb@labrea.stanford.edu, sandra@cs.utah.edu,
        cl-cleanup@sail.stanford.edu
In-Reply-To: Rob.MacLachlan@wb1.cs.cmu.edu's message of Tue, 12 Jul 88 15:50:23 EDT <8807121858.AA09947@Think.COM>
Subject: SUBTYPEP-TOO-VAGUE (initial draft) 

   Date: Tue, 12 Jul 88 15:50:23 EDT
   From: Rob.MacLachlan@wb1.cs.cmu.edu
   ...
   Any how many SUBTYPEPs correctly recognize that float types are finite?
       (subtypep `(short-float 0s0 (,(* short-float-epsilon 4)))
		 `(member 0s0
			  ,(* short-float-epsilon 1)
			  ,(* short-float-epsilon 2)
			  ,(* short-float-epsilon 3))) => T, T

I see your point, but SHORT-FLOAT-EPSILON is not the right quantity here.
--Guy

∂12-Jul-88  1305	CL-Cleanup-mailer 	Re: SUBTYPEP-TOO-VAGUE (initial draft)   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Jul 88  13:05:21 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA17539; Tue, 12 Jul 88 14:04:35 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA23562; Tue, 12 Jul 88 14:04:33 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807122004.AA23562@cdr.utah.edu>
Date: Tue, 12 Jul 88 14:04:32 MDT
Subject: Re: SUBTYPEP-TOO-VAGUE (initial draft) 
To: Rob.MacLachlan@wb1.cs.cmu.edu
Cc: Eric Benson <edsel!eb@labrea.stanford.edu>, sandra@cs.utah.edu,
        cl-cleanup@sail.stanford.edu
In-Reply-To: Rob.MacLachlan@WB1.CS.CMU.EDU, Tue, 12 Jul 88 15:50:23 EDT

Hmmm, I think you've convinced me to add MEMBER to the list of messy
cases after all....

-Sandra
-------

∂12-Jul-88  1544	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Jul 88  15:44:43 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA07536@EDDIE.MIT.EDU>; Tue, 12 Jul 88 18:43:48 EDT
Received: by spt.entity.com (smail2.5); 12 Jul 88 18:01:06 EDT (Tue)
To: sandra%cdr@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8807111728.AA22729@cdr.utah.edu>
Subject: issue BOGUS-FIXNUMS (initial draft) 
Message-Id: <8807121801.AA06063@spt.entity.com>
Date: 12 Jul 88 18:01:06 EDT (Tue)
From: gz@spt.entity.com (Gail Zacharias)

It is not uncommon for a program to find itself with an object which is known
to be either a small integer or, say, a string or a list.  In such cases
(typep x 'fixnum) is likely to more efficient than either (typep x 'integer)
or (typep x '(integer 0 1000)), and it's an optimization that a compiler can't
do for you.

∂12-Jul-88  1555	CL-Cleanup-mailer 	Re: issue BOGUS-FIXNUMS (initial draft)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jul 88  15:55:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUL 88 15:28:16 PDT
Date: 12 Jul 88 15:28 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: issue BOGUS-FIXNUMS (initial draft)
In-reply-to: sandra%cdr@cs.utah.edu (Sandra J Loosemore)'s message of Mon, 11
 Jul 88 11:28:42 MDT
To: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880712-152816-1764@Xerox>

I can't see getting entirely rid of FIXNUMs and adding something else just
because FIXNUMs aren't really portable. I think it might be more reasonable to
be more explicit about how unportable FIXNUMs are. 

Certainly implementations that have only one representation can arbitrarily
deftype FIXNUM to be SIGNED-BYTE 32 and leave it at that. 

To put it in terms of the proposal: I don't think that the problem statement as
written establishes that there is a significant problem with the language; there
may be a problem with CLtL and with CL programming texts and lots of the CL code
running around, but I think it is OK for the language to have some portable way
of talking about the "most efficient number range". All computers that I know
about have word sizes. 

I certainly would like to discourage programmers from using FIXNUM for
discrimination when they really don't mean it, and from using FIXNUM
declarations when they really mean a given number range, but I don't think
taking FIXNUM out of the language is the proper way to do it. 

I don't see how MAX-INTEGER-LENGTH has anything to do with the problem as
stated. I think it is a separate proposal, if you want to allow for limits on
bignum size.




∂12-Jul-88  1630	CL-Cleanup-mailer 	Re: issue BOGUS-FIXNUMS (initial draft)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jul 88  16:29:54 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 12 JUL 88 16:01:35 PDT
Date: 12 Jul 88 16:00 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: issue BOGUS-FIXNUMS (initial draft) 
In-reply-to: gz@spt.entity.com (Gail Zacharias)'s message of 12 Jul 88 18:01:06
 EDT (Tue)
To: gz@spt.entity.com (Gail Zacharias)
cc: sandra%cdr@cs.utah.edu, cl-cleanup@sail.stanford.edu
Message-ID: <880712-160135-1829@Xerox>

Sigh, that's just the kind of code that is very non-portable and that I'd like
to discourage programmers from writing. I've tried to import stuff from a CL
that had 31 bit FIXNUMs into a system that had 17-bit FIXNUMs and, out of sheer
laziness, they said FIXNUM when they really meant (signed-byte 24).

∂13-Jul-88  0853	CL-Cleanup-mailer 	an alternate BOGUS-FIXNUMS proposal 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Jul 88  08:53:30 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA12244; Wed, 13 Jul 88 09:53:13 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA24171; Wed, 13 Jul 88 09:52:32 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807131552.AA24171@cdr.utah.edu>
Date: Wed, 13 Jul 88 09:52:31 MDT
Subject: an alternate BOGUS-FIXNUMS proposal
To: cl-cleanup@sail.stanford.edu, gz@spt.entity.com (Gail Zacharias)
In-Reply-To: gz@spt.entity.com (Gail Zacharias), 12 Jul 88 18:30:10 EDT (Tue)

Gail Zacharias has suggested an alternate proposal on this issue.  The
relevant parts are:

> Proposal:	BOGUS-FIXNUMS:SET-MINIMUM
> 
> (1) Require that (SIGNED-BYTE 15) must be a subtype of FIXNUM.
> 
> (2) Specify that MOST-POSITIVE-FIXNUM and/or MOST-NEGATIVE-FIXNUM may be
> NIL to indicate no limit aside from any placed on the size of integers.
> That is, the FIXNUM type is equivalent to
>    `(INTEGER ,(OR MOST-NEGATIVE-FIXNUM '*) ,(OR MOST-POSITIVE-FIXNUM '*))
>
> Implementations which do not have fixnums (or do not wish to advertise them
> as such) should make the FIXNUM type be the same as INTEGER and set the
> MOST-POSITIVE/NEGATIVE-FIXNUM constants to NIL.
> 
> Implementations which have fixnums of less than 15 bits would become
> implementations without fixnums.  They would have to make FIXNUM be the
> same as INTEGER and pick a different name for their small integers.
> The efficient integers of such implementations cannot be taken advantage of
> by portable programs by means of FIXNUM declarations.


I suppose a proposal along these lines would be a better than the
status quo.  However, I do see some problems:

- It does not address the issue of what happens to the BIGNUM type
  specifier.  If it remains in the language, are BIGNUM and FIXNUM still
  required to be disjoint?  If an implementation has only a single
  representation for integers and FIXNUM == INTEGER, would the set of
  BIGNUMs be empty?  Or would it be similar to how the different types
  of floats are handled if an implementation does not support all 4
  distinct representations?

- Programmers would still be able to put FIXNUM declarations in their
  code, but under this proposal FIXNUMs would not necessarily guarantee
  the most efficient representation (which appears to be the main reason
  why people are so anxious to preserve the FIXNUM type in the first
  place).

- Forcing users to DEFTYPE their own integer subrange types instead
  would encourage better use of data abstraction.  I've noticed that 
  Lisp programs are typically much sloppier about this than programs
  written in strongly typed languages such as C or Pascal. 

Also, note that if users specify a smaller subrange of integers than
the nominal FIXNUM size in their declarations, it may be possible to
get even more improvements in performance.  For example, a Lisp
implementation on a M68000 typically sizes fixnums to fit in a 32-bit
longword, but if enough type information is available to deduce that
the integers will fit in 16 bits (including perhaps 2 or 3 low tag
bits), it would be possible to use the significantly faster word-sized
arithmetic operations instead of longword operations.

-Sandra
-------

∂13-Jul-88  1221	CL-Cleanup-mailer 	Re:  an alternate BOGUS-FIXNUMS proposal 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 13 Jul 88  12:19:23 PDT
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa07416; 13 Jul 88 19:54 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Wed, 13 Jul 88 20:16:02 bst
Message-Id: <847.8807131916@aiva.ed.ac.uk>
To: gz%spt.entity.com@NSS.Cs.Ucl.AC.UK, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re:  an alternate BOGUS-FIXNUMS proposal
Cc: cl-cleanup@sail.stanford.edu

Date: Wed, 13 Jul 88 09:52:31 MDT
From: sandra <(Sandra J Loosemore)sandra%cdr@edu.utah.cs>

> Gail Zacharias has suggested an alternate proposal on this issue.

> I suppose a proposal along these lines would be a better than the
> status quo.  However, I do see some problems:

I don't mind proposals that make fixnums more portable.  Do you still
think they should be eliminated instead?  Perhaps we should look at
what languages like C say about "short", "int", and "long".  (Very
little is promised, as I recall.)

> - Forcing users to DEFTYPE their own integer subrange types instead
>   would encourage better use of data abstraction.  I've noticed that 
>   Lisp programs are typically much sloppier about this than programs
>   written in strongly typed languages such as C or Pascal.

Well, I for one do not want to figure out exactly what range I need in
every case.  And in some cases I may not know an exact range.  What I
want is more or less soemthing that says "give me an int (as in C,
say), not a BIGNUM".

I'm not sure just what aspects of C and Pascal programs you have in
mind.  There are certainly many programs that use "int" or "long", and
those are analogous to FIXNUM, not to explicit ranges of integers or
numbers of bits.

-- Jeff

∂13-Jul-88  1445	CL-Cleanup-mailer 	Re:  an alternate BOGUS-FIXNUMS proposal 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Jul 88  14:45:08 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA23663; Wed, 13 Jul 88 15:42:56 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA24370; Wed, 13 Jul 88 15:42:54 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807132142.AA24370@cdr.utah.edu>
Date: Wed, 13 Jul 88 15:42:51 MDT
Subject: Re:  an alternate BOGUS-FIXNUMS proposal
To: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@nss.cs.ucl.ac.uk>
Cc: gz%spt.entity.com@nss.cs.ucl.ac.uk, sandra <sandra%cdr@cs.utah.edu>,
        cl-cleanup@sail.stanford.edu
In-Reply-To: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Wed, 13 Jul 88 20:16:02 bst

> From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> Date: Wed, 13 Jul 88 20:16:02 bst
> 
> Perhaps we should look at
> what languages like C say about "short", "int", and "long".  (Very
> little is promised, as I recall.)
> 
> I'm not sure just what aspects of C and Pascal programs you have in
> mind.  There are certainly many programs that use "int" or "long", and
> those are analogous to FIXNUM, not to explicit ranges of integers or
> numbers of bits.

Yes, people do declare things as "int" in C code without giving a
great deal of thought to how big an "int" really is.  But in my mind,
not being guaranteed anything about integer sizes in C (and not being
able to define subrange types as you can in Pascal) is a misfeature.
I don't think its presence in C is a valid justification for including
it in Lisp.

An example of a portable C program that I'm familiar with is the MG
text editor.  It runs on 8 or 9 different configurations (3 of which I
have personally hacked on), including some machines where ints are 16
bits and longs 32, some where both ints and longs are both 32 bits,
and I believe one where ints are 32 and longs are 64.  We define
things like the integer type to use for indexing into a region (that
you really want to be 32 bits, but that might be either int or long)
with #typedef's in a system-specific include file.  Likewise the size
of integer that represents a keystroke (12 bits) might need to be
defined as either a short or int.  We've found that portability
problems are almost invariably due to code that violates the data
abstraction by doing things like declaring a variable that is used to
index into a region as "int" instead of "RSIZE", or assuming that int
and long are the same size. 

-Sandra
-------

∂13-Jul-88  1543	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Jul 88  15:43:37 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA04393@EDDIE.MIT.EDU>; Wed, 13 Jul 88 18:41:56 EDT
Received: by spt.entity.com (smail2.5); 13 Jul 88 18:22:03 EDT (Wed)
To: Masinter.pa@Xerox.COM
Cc: sandra%cdr@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 12 Jul 88 16:00 PDT <880712-160135-1829@Xerox>
Subject: issue BOGUS-FIXNUMS (initial draft) 
Message-Id: <8807131822.AA09967@spt.entity.com>
Date: 13 Jul 88 18:22:03 EDT (Wed)
From: gz@spt.entity.com (Gail Zacharias)

   Date: 12 Jul 88 16:00 PDT
   From: Masinter.pa@Xerox.COM

   Sigh, that's just the kind of code that is very non-portable and that I'd
   like to discourage programmers from writing. I've tried to import stuff
   from a CL that had 31 bit FIXNUMs into a system that had 17-bit FIXNUMs
   and, out of sheer laziness, they said FIXNUM when they really meant
   (signed-byte 24).

It's only non-portable if used on values which are not guaranteed to to be
within the FIXNUM range.  If FIXNUMs were guaranteed to be at least
(signed-byte 24), it would be a perfectly valid program.  Since they're not,
you just had the misfortune of working with buggy code.  Buggy code can be
written using all sorts of otherwise-useful CL constructs.

The problem is of course that currently nothing is guaranteed to be in the
fixnum range, so even programs that use FIXNUM for numbers between -1 and
1 are nominally buggy.  I think the solution is to guarantee some reasonable
range and be done with it.

∂14-Jul-88  1146	CL-Cleanup-mailer 	Re:  an alternate BOGUS-FIXNUMS proposal 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 14 Jul 88  11:42:40 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa06067; 14 Jul 88 19:12 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Thu, 14 Jul 88 19:36:00 BST
Message-Id: <13739.8807141836@subnode.aiai.ed.ac.uk>
To: sandra <@cs.utah.edu:sandra@cdr>
Subject: Re:  an alternate BOGUS-FIXNUMS proposal
Cc: cl-cleanup@sail.stanford.edu

Sandra:
   Forcing users to DEFTYPE their own integer subrange types instead
   would encourage better use of data abstraction.  I've noticed that
   Lisp programs are typically much sloppier about this than programs
   written in strongly typed languages such as C or Pascal.

Me: There are certainly many programs that use "int" or "long", and
   those are analogous to FIXNUM, not to explicit ranges of integers
   or numbers of bits.

Sandra:
   Yes, people do declare things as "int" in C code without giving a
   great deal of thought to how big an "int" really is.  But in my mind,
   not being guaranteed anything about integer sizes in C (and not being
   able to define subrange types as you can in Pascal) is a misfeature.
   I don't think its presence in C is a valid justification for including
   it in Lisp.  [Followed by example of program that avoids using int or
   long directly by using system-specific typedefs.]

My point was that C (and Pascal) programs do use "int", and that this is
analogous to FIXNUM.  While some C programs take more care (if they are
concerned about portability to a wide range of machines), so do some Lisp
programs.  I do not agree that C programs typically show more care than
Lisp programs about this particular issue (though they must, of course, be
more careful about types in general): a great many C programs simply use
"int" or "long".  Nor it is the case that C and Pascal *force* users to
define their own integer subrange types.  And, well, all this is not to
show that "int" in C justifies FIXNUM in Lisp but only that your argument
in favor of "forcing users", etc. does not have the support from C and
Pascal that you suggest.

One the contrary, C and Pascal show that "int" is useful and that forcing
users to define subranges is not necessary.  This point is valid, because
is shows that such ill-defined types are nonetheless useful.  Perhaps it
would not be enough to justify adding FIXNUM to Lisp, but since you are
suggesting a change to CL, the burden of proof is on you to show that
FIXNUM should be removed and that its utility is outweighed by other
factors.

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton

∂14-Jul-88  1538	CL-Cleanup-mailer 	Re: various DEFSTRUCT issues   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jul 88  15:38:10 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 JUL 88 15:21:51 PDT
Date: 14 Jul 88 15:22 PDT
From: masinter.pa@Xerox.COM
Subject: Re: various DEFSTRUCT issues
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Thu, 30 Jun 88 00:10
 EDT
To: Barry Margolin <barmar@Think.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880714-152151-6402@Xerox>

My belief is that we should say that it is an error to have two slots with
string-equal slot names, and that it is an error to redefine a structure, in
that slot-accessors for structures are presumed to be declared "inline". If
users want more flexibility than that, they should use defclass.

Given that we have defclass and CLOS, I'm leaning toward allowing maximal
performance hacking by implementations using vanilla DEFSTRUCT. So requiring
implementations to allow things they don't currently allow (even though some
implementations might allow them) seems like it is going in the wrong direction.


∂14-Jul-88  2214	CL-Cleanup-mailer 	BOGUS-FIXNUMS, again 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Jul 88  22:14:39 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA06686; Thu, 14 Jul 88 23:14:13 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA25613; Thu, 14 Jul 88 23:14:09 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807150514.AA25613@cdr.utah.edu>
Date: Thu, 14 Jul 88 23:14:07 MDT
Subject: BOGUS-FIXNUMS, again
To: cl-cleanup@sail.stanford.edu

Since it appears that nobody besides me (and Stan) likes my previous
proposal on this issue and that I'll have to come up with something
less radical that is more acceptable to the rest of the committee, I
thought it would be useful to enumerate some of the possibilities.  I
realize there are still two other issues which would still have to be
addressed when turning any of these into a real proposal, namely
whether to retain MOST-BLETCHEROUS-FIXNUM :-), and whether the BIGNUM
type specifier should remain and whether it must still be a non-empty
set which is disjoint from FIXNUM. 

#0 (what CLtL says):
    - there is no particular type specifier defined for "small integers".
    - the FIXNUM type specifier is defined but nothing is said about its
      range.
    - FIXNUMs are required to have a more efficient representation than
      non-FIXNUMs.

#1 (my original proposal):
    - there is no particular type specifier defined for "small integers".
    - the FIXNUM type specifier goes away.
    - user-defined integer subrange types use the most efficient 
      representation possible in a given implementation.

#2 (Gail Zacharias's counter-proposal):
    - there is no particular type specifier defined for "small integers".
    - the FIXNUM type specifier is defined to be a superset of
      (SIGNED-BYTE n), for some value of "n" which has yet to be
      decided but that we all agree upon.
    - FIXNUMs are not required to coincide with or be a subset of the
      set of integers which are represented most efficiently.

#3 (change CLtL's "typically" to a firm requirement):
    - there is no particular type specifier defined for "small integers".
    - FIXNUMs must be a supertype of (SIGNED-BYTE n).
    - FIXNUMs are defined to be the set of integers which are represented
      most efficiently.

#4 (dumb, but here for completeness):
    - there is no particular type specifier defined for "small integers".
    - the FIXNUM type specifier is defined to be equivalent to
      (SIGNED-BYTE n).
    - FIXNUMs are required to be a subset of the integers which are
      represented most efficiently.

#5: (Kent Pitman's suggestion):
    - a new SMALL-INTEGER type specifier is introduced which is equivalent
      to (SIGNED-BYTE n).
    - the FIXNUM type specifier goes away.
    - nothing is guaranteed about the efficiency of representation of
      SMALL-INTEGERs.

#6 (similar to #3):
    - a new SMALL-INTEGER type specifier is introduced which is equivalent
      to (SIGNED-BYTE n).
    - the set of FIXNUMs is required to be a superset of SMALL-INTEGERs.
    - FIXNUMs are defined as the set of integers with the most efficient
      representation.  (This implies that SMALL-INTEGERS are also
      guaranteed to be efficient.)

#7 (a cross between #0 and #5):
    - a new SMALL-INTEGER type specifier is introduced which is equivalent
      to (SIGNED-BYTE n).
    - the FIXNUM type specifier remains but the range of FIXNUMs is left
      undefined, as is the relationship between FIXNUM and SMALL-INTEGER.
    - FIXNUMs are defined as the set of integers with the most efficient
      representation.  Nothing is guaranteed about the efficiency of 
      SMALL-INTEGERs.

Comments, anyone?  

-Sandra
-------

∂15-Jul-88  0013	CL-Cleanup-mailer 	an alternate BOGUS-FIXNUMS proposal 
Received: from rutgers.edu ([128.6.21.9]) by SAIL.Stanford.EDU with TCP; 15 Jul 88  00:13:30 PDT
Received: by rutgers.edu (5.59/1.15) with UUCP 
	id AA08860; Fri, 15 Jul 88 01:42:49 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA01559@EDDIE.MIT.EDU>; Wed, 13 Jul 88 23:06:58 EDT
Received: by spt.entity.com (smail2.5); 13 Jul 88 20:29:39 EDT (Wed)
To: sandra%cdr@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Wed, 13 Jul 88 09:52:31 MDT <8807131552.AA24171@cdr.utah.edu>
Subject: an alternate BOGUS-FIXNUMS proposal
Message-Id: <8807132029.AA10252@spt.entity.com>
Date: 13 Jul 88 20:29:39 EDT (Wed)
From: gz@spt.entity.com (Gail Zacharias)

   From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
   Date: Wed, 13 Jul 88 09:52:31 MDT

   - It does not address the issue of what happens to the BIGNUM type
     specifier.

I wouldn't be adverse to removing BIGNUM as a type specifier altogether.

   - Programmers would still be able to put FIXNUM declarations in their
     code, but under this proposal FIXNUMs would not necessarily guarantee
     the most efficient representation (which appears to be the main reason
     why people are so anxious to preserve the FIXNUM type in the first
     place).

It would guarantee an efficient representation in all cases where it can be
reasonably expected to do so.  That is, in all implementations which have a
sufficiently large range of efficient integers.

   Also, note that if users specify a smaller subrange of integers than
   the nominal FIXNUM size in their declarations, it may be possible to
   get even more improvements in performance.

That's right.  Users can always take the extra time and effort needed to do a
more detailed range analysis in especially critical sections of code.

Use of FIXNUM's is not always prompted by programmers' laziness in analyzing
their code.  The problem is that in those implementations which do support
fixnums, the efficiency difference between fixnums and bignums is usually
fairly large.  It's large enough that users are willing to structure their
code to take note of it.  Different algorithms (e.g. different space/speed
tradeoffs) might be appropriate for fixnums and bignums.  In Macsyma, there
are a number of instances where an argument is checked for being a fixnum,
and different code is used if it is (actually it's often the same code,
but full of fixnum declarations for all the intermediate results).  This
is not something that can be done with range declarations.  The following piece
of code is also from Macsyma:
   (DO ((I 0 (1+ I))
        (P MOST-POSITIVE-FIXNUM (NEWPRIME P)))
    ((= I 20.)))
This makes a table of the 20 largest primes which fit in a fixnum.  The table
is used to good effect by various algorithms within Macsyma.  Do you really
wish to disallow these kinds of optimizations?

Common Lisp goes to some trouble to provide for the needs of people writing
serious numerical floating point code.  I think recognizing the (possibility
of the) FIXNUM/BIGNUM distinction is the minimum that can be done for people
writing serious numerical integer code.  There may be a problem with the more
"casual" use of FIXNUM declarations for loop counters and such, but I don't
think that the way to address that problem is to pretend the distinction
doesn't exist.

∂15-Jul-88  0110	CL-Cleanup-mailer 	re: issue BOGUS-FIXNUMS   
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88  01:10:48 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
	id AA02152; Fri, 15 Jul 88 01:08:33 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb (5.51/1.36)
	id AA07355; Thu, 14 Jul 88 12:51:45 PDT
Date: Thu, 14 Jul 88 12:51:45 PDT
Message-Id: <8807141951.AA07355@trwrb>
To: cl-cleanup@sail.stanford.edu
Subject: re: issue BOGUS-FIXNUMS

I believe it is imperative for Common Lisp to support a portable means
of declaring the range of integers to be handled ina particular operation
is within that range efficiently supported by the underlying hardware
architecture.  This is what I mean when I say (declare (fixnum x)) in a
program.  I understand that this limits the portability or usefulness of
my program after porting.  But I believe this limitation is more funda-
mentally imposed by the underlying hardware architecture than by my
fixnum declaration -- the performance of operations involving "fixnums"
is critical to many programs.

When a Common Lisp provides only one integer representation, that may
limit the portability of my program, depending on the representation.
I may need large range; I may need the fastest possible integer operations
restricted to the range efficiently supported.  A representation that
limits range to a fixed range is a bogus bignum implementation, in my book.
A representation that does not take advantage of fast integer arithmetic
performance for a restricted range of integers has a bogus fixnum implementa-
tion, similarly.  That is assuming, of course, that there is only that one
representation.

When a Common Lisp provides more than two representations, it is also
limiting portability in some way.  Let's say there are three representations.
Let's further say that one corresponds to the accepted definition of fixnum
and another to the accepted definition of bignum.  Then use of the third
will likely limit portability, if my declarations are intended to be for
sake of efficiency.  Use of (declare ((integer n0 n1) x)), could, of
course, be useful and portable given three representations.  But they
would not be used for the same purpose as a fixnum or bignum declaration.

I guess my point is that the portability of my program is something I
determine based on the power of the hardware architecture and the quality
of the Lisp implementation.  Given that the architecture is powerful
enough (has a wide enough word size, for example), I can port to it.
But my fixnum declarations are for performance.  If it were not important
for that declaration to be made for efficiency, I likely wouldn't make it
at all.  This may reflect a difference in philosophy between those who
declare everything for sake of program clarity or readability and me, I
suspect.  Those who make declarations for other-than-performance likely find
my fixnum declarations utterly detestable.  I'm not arguing one philosphy
versus the other; I assuming a sizeable set of programmers who use declara-
tions similarly to how I use them.  Taking away the fixnum/bignum distinction
takes away a valuable and well-used tool.

--Joe

∂15-Jul-88  0555	CL-Cleanup-mailer 	Issue: BOGUS-FIXNUMS 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Jul 88  05:55:11 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 433676; Fri 15-Jul-88 08:54:52 EDT
Date: Fri, 15 Jul 88 08:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: BOGUS-FIXNUMS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880715085441.8.KMP@PEWEE.SCRC.Symbolics.COM>

Perhaps the real cause of trouble here is that we have only one type, FIXNUM,
for two purposes -- (a) `machine precision' of either non-portable or 
hyper-optimized programs like Macsyma (b) `small integers' desiring 
efficiency.

The reason I suggested SMALL-INTEGER is that I think that's what some people
really want to say. I'm much less strong on elminating FIXNUM than I am on
providing a useful alternative. As it is now, if you want efficient code but
also want it to be portable, you have nothing to say beyond a cumbersome
signed-byte or bounded integer range. Just as we provide the `common' 
sequence operations because it saves everyone from writing them over and
over, so too we should provide the common declarations to save everyone from
writing them.

I think what Sandra is saying is not argued. FIXNUM declarations are very
seldom portable. Even in Macsyma, the alternate fixnum declared code might
sometimes be gone into on the basis of inputs being fixnums, sometimes not
worrying as carefully as it might about whether intermediate values or
outputs will all be fixnums. And every now and then you might lose unless
you've done some careful checking. GZ, JDalton, etc. are saying they're
willing to do such checking sometimes.

The problem is that naive users will see FIXNUM and mentally relate it to
small integers when it's really quite different. Surely, I can imagine such
a user saying, there is at least the concept of a small integer. Since 
there's only one type even remotely like that, it must be it. In fact, that
would be a wrong assumption. My reading of CLtL says the fixnum subrange
need not even include zero. It might be (INTEGER 5 25), for example. There
might, therefore, be integers smaller than FIXNUMs. We might want to just
plain fix that. It might also include no numbers (though that leaves an
implementation in a quandry about what to put in MOST-POSITIVE-FIXNUM, etc.)
I think some CDC CL had this problem. As best I remember from a manual I saw
a couple years ago, they had set the MOST-xxx vars to NIL because they had
the same representation for all numbers and had chosen them to either all
be fixnums or all be bignums, I don't recall. All of this is bound to confuse
a novice who may just be seeking a simple, efficient type declaration.

My revised view is that we leave FIXNUM and its associated vars be, and
add SMALL-INTEGER. We should choose the range of SMALL-INTEGER such that,
then clearly document that, SMALL-INTEGER is a portable concept which
might lead to inefficiency in an occasional implementation, but in most
implementations it will be suitably fast. We should document that FIXNUM
is intended to denote an implementation-specific type which is not
portable, but which is useful in certain applications, like Macsyma, which
have need to take the fullest advantage of whatever machine they're on, even
at the price of dealing more carefully with portability issues.
I think the availability of a pre-defined and usefully sized type such as
SMALL-INTEGER will make this explanation of FIXNUM much more palatable.

I would remove the type BIGNUM. I think everyone expects it to mean
(AND INTEGER (NOT FIXNUM)) anyway. I bet any implementation where it doesn't
mean this violates user expectations. Given that, one could just DEFTYPE
it for compatibility if it was really used heavily in some particular case.

∂17-Jul-88  0820	CL-Cleanup-mailer 	Re: issue BOGUS-FIXNUMS (initial draft)  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Jul 88  08:20:24 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA03839; Sun, 17 Jul 88 09:19:07 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA23357; Tue, 12 Jul 88 09:08:27 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807121508.AA23357@cdr.utah.edu>
Date: Tue, 12 Jul 88 09:08:25 MDT
Subject: Re: issue BOGUS-FIXNUMS (initial draft)
To: cl-cleanup@sail.stanford.edu
Cc: KMP@stony-brook.scrc.symbolics.com,
        jeff%aiva.edinburgh.ac.uk@nss.cs.ucl.ac.uk,
        jpff%maths.bath.ac.uk@nss.cs.ucl.ac.uk
In-Reply-To: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK, Tue, 12 Jul 88 10:33:24 BST

Well, I thought this issue would generate some flamage....  But before this
gets any farther, let me make one thing clear:  This proposal *is* *not*
(read my lips!  IS NOT!) an attempt to do away with either efficient "fixnum"
arithmetic or arbitrary precision arithmetic!  It is merely an attempt to
get rid of some unfortunate and nonportable terminology from the language
standard.


> Date: Mon, 11 Jul 88 17:16 EDT
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> 
> This proposal might go over better if we replaced the feature with
> another, more portable, feature addressing a similar need. eg,
> 
>  SMALL-INTEGER could be defined as some range of integers which we
>  think most implementations can support efficiently (but with the
>  understanding that the important thing is to support it correctly
>  rather than efficiently). For example, maybe SMALL-INTEGER could
>  be defined as (INTEGER -2↑30 (2↑30)). [The specific bounds is open
>  to discussion, of course, I'm just proposing ``something like this''.]

Users can already define such a type (or types) on their own.  This technique
is used quite extensively in CLX, where there are about a dozen types
defined like:

    (deftype int8 () '(signed-byte 8))
    (deftype card16 () '(unsigned-byte 16))
    (deftype array-index () `(integer 0 ,array-dimension-limit))

Unlike "fixnum", these type specifiers have uniform semantics across all
implementations.  One would hope that in those implementations where they
are subtypes of "fixnum", the compiler would be smart enough to recognize
them as such.

(As an aside, there is a precedent for doing this in other languages
as well.  Many Pascal compilers, for example, only have one size of
integer that is allocated if you just say "integer".  But, if you
define a subrange type like 0..255 instead, they'll only allocate an
8-bit byte for it.)


> From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> Date: Mon, 11 Jul 88 21:32:31 bst
> 
> Even though fixnums may
> differ from implementation to implementation, I want a standard
> way to use them when they exist rather than allow implementations
> to diverge (so that some call them fixnums, others something else,
> and so on).

Having a standard name is of little use unless it is tied to some
standard semantics.  The problem is that there is no guarantee what
you get when you say "fixnum".  There is currently no absolute
prohibition against defining the range of fixnums to be something like
100,000 to 100,010.  If you want "small integer", then by all means
define your own small integer type using DEFTYPE.  That way you're
guaranteed to have it mean exactly the same thing in all
implementations. 

> I do not accept the argument that it doesn't matter because everyone who
> provides fixnums can still provide them.  If they're not in the standard,
> users cannot in fact rely on them being provided in a standard way.
> Indeed, if we decide to allow only standard symbols in the LISP package,
> users would have to type LUCID:FIXNUM, EXCL:FIXNUM, etc. rather than just
> FIXNUM as they can now.

Why not just import the appropriate symbol into the package you're using
once, and be done with it?


> Date: Tue, 12 Jul 88 10:33:24 BST
> From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
> 
> This looks like a giant step backwards.  Some of us are interested in
> writing efficient code.  Even if some machines only have one
> representation I find it hard to believe that there are not a subset
> which are more efficient.  Are you seriously suggesting that LISP
> should counternance numbers not being arbitary precision?

Once again, I AM NOT PROPOSING TO GET RID OF ARBITRARY PRECISION
ARITHMETIC.  If your implementation supports a range of small integers
that are more efficient than larger integers, there is already a portable
way to declare them as such.  

To draw an analogy, small bignums are likely to be considerably faster and
more efficient than large bignums.  Should we assign a special name to
bignums with less than N "bigits" simply because they're faster than bignums
that are larger than that?  How useful would having such a special name be
when both N and the size of the "bigit" vary from implementation to
implementation? 

> Anyway KCL has fixnum, bignum and short fixnum.

It appears I was misinformed on this point -- I was under the impression
that KCL boxed all integers and simply preallocated a range of small
integers.

-Sandra
-------

∂18-Jul-88  0914	CL-Cleanup-mailer 	Re: issue BOGUS-FIXNUMS (initial draft)  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 18 Jul 88  09:09:22 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa04367; 18 Jul 88 16:31 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Mon, 18 Jul 88 16:52:03 BST
Message-Id: <2479.8807181552@subnode.aiai.ed.ac.uk>
To: cl-cleanup@sail.stanford.edu, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: issue BOGUS-FIXNUMS (initial draft)
Cc: jpff <@NSS.Cs.Ucl.AC.UK:jpff@maths.bath.ac.uk>

> Date: Tue, 12 Jul 88 09:08:25 MDT
> From: sandra <(Sandra J Loosemore)sandra%cdr@edu.utah.cs>

What I want to establish is: [1] Fixnums are about as useful as, say,
int or long in C (or if not can be made so rather than be eliminated),
In KCL, fixnums can actually be compiled as ints.  [2] It's nice to have
a standard name for efficient integers, and a standard name has to be in
the standard.  [3] Explicit subranges are not necessarily efficient and
are often less convenient to use.

Moreover, GZ has provided some examples from Macsyma that show that
fixnums can be used with a considerable degree of portability even as
now defined.

In short, the argument for eliminating fixnums seems to be based on an
overemphasis on one aspect of portability rather than a consideration
of what programmers actually do and want.

> > From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> > Date: Mon, 11 Jul 88 21:32:31 bst
> > 
> > Even though fixnums may differ from implementation to
> > implementation, I want a standard way to use them when they exist
> > rather than allow implementations to diverge (so that some call
> > them fixnums, others something else, and so on).
> 
> Having a standard name is of little use unless it is tied to some
> standard semantics.  The problem is that there is no guarantee what
> you get when you say "fixnum".  There is currently no absolute
> prohibition against defining the range of fixnums to be something
> like 100,000 to 100,010.

Well, then perhaps int and long in C are of "little use".  They are
not guaranteed to be the same size everywhere.

Note too that your argument is for reforming fixnums, not for
eliminating them, and I am not arguing against reform.

> If you want "small integer", then by all means define your own small
> integer type using DEFTYPE.  That way you're guaranteed to have it
> mean exactly the same thing in all implementations. 

You may want it to mean "exactly the same thing" (meaning exactly the
same size); that is not what I am asking for.  

Besides I don't want a small integer, I want an efficient one.  A
subrange is not guaranteed to be efficient, and so does not replace
FIXNUM.

> > I do not accept the argument that it doesn't matter because everyone who
> > provides fixnums can still provide them.  If they're not in the standard,
> > users cannot in fact rely on them being provided in a standard way.

Note that your response about packages below does not answer this.

> > Indeed, if we decide to allow only standard symbols in the LISP package,
> > users would have to type LUCID:FIXNUM, EXCL:FIXNUM, etc. rather than just
> > FIXNUM as they can now.

> Why not just import the appropriate symbol into the package you're using
> once, and be done with it?

This is still not providing fixnums in a standard way.  I still have
to add some conditional code for each implementation.

> > Date: Tue, 12 Jul 88 10:33:24 BST
> > From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK

> If your implementation supports a range of small integers
> that are more efficient than larger integers, there is already a portable
> way to declare them as such.  

The range gets ported, but the efficiency may not.  Fixnums work
adequately over a wide range of implementations without requiring
implementation-specific customization of my types.  I am even willing to
have some programs not work in implementations that have a sufficiently
losing notion of fixnums, just as I am willing to do this in other
langauges.

> To draw an analogy, small bignums are likely to be considerably faster and
> more efficient than large bignums.  Should we assign a special name to
> bignums with less than N "bigits" simply because they're faster than bignums
> that are larger than that?

That we do not want a name for every class of more efficient number
does not show we do not want a name for any such class.

Moreover, compilers can (or at least do) get more in the way of
optimization from fixnums than they would from "small bignums".

> It appears I was misinformed on this point -- I was under the impression
> that KCL boxed all integers and simply preallocated a range of small
> integers.

It does "box" all integers (though fixnum declarations may avoid this in
compiled code).  But the representation of fixnums is simpler than
that for bignums.  It is very much like Franz in this respect.

-- Jeff

∂18-Jul-88  1345	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 18 Jul 88  13:44:55 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 18 Jul 88 16:42:31 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1) 
In-reply-to: Your message of Fri, 01 Jul 88 19:57:00 -0400.
             <880701195711.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM> 
Date: Mon, 18 Jul 88 16:42:01 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


This proposal to use case to control the canonicalization of case in
pathname components looks to me like it would cause confusion and paralysis
of truly awesome propotions.  For that reason, I am strongly opposed to
this proposal in its current form.

If we need a way to canonicalize the case of various pathname fields, maybe
we should have a CANONICALIZE-CASE function that takes a string and a
file-system type and does the proper case-conversion.

-- Scott

∂18-Jul-88  1403	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Jul 88  14:03:19 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 434787; Mon 18-Jul-88 17:02:47 EDT
Date: Mon, 18 Jul 88 17:02 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880718170217.3.KMP@PEWEE.SCRC.Symbolics.COM>

Can you elaborate on the kind of ``confusion and paralysis of truly
awsome proportions'' you expect?

Can you also give a couple examples of what you consider portable
uses of the current paradigm which do not involve the use of READ-LINE
in order to obtain a namestring in the first place?

My point is that if every portable use of MAKE-PATHNAME must look like
 (MAKE-PATHNAME :DIRECTORY (MAPCAR #'CANONICALIZE-CASE '("JOE" "TOOLS"))
		:NAME (CANONICALIZE-CASE "FOO" *LOCAL-FS*)
	        :TYPE (CANONICIALIZE-CASE "LISP" *LOCAL-FS*))
then what's the point?

I think the examples I put forth were simple and compelling and I would
like to see some equally compelling -- but most importantly, concrete --
arguments of how such lossage is likely to occur. The only cases I can
imagine causing problems are cases where people insist on programming in
new-CL without reading the documentation. I don't mind designing languages
to take into account naive users (normal, thinking people who have
read the documentation) but I do mind designing languages to take into
account ignorant users (people who believe their own personal prejudices
and intuitions should take precedence over a carefully reasoned and
thoroughly documented theory).

Do you have a technical objection to the proposal on the table? The pathname
system from which I took the idea for this proposal is one of very few I
know of which has tried this approach and demonstrated it to be workable in
the face of numerous operating systems. Frankly, the only comments I've ever
heard numerous users of the Symbolics pathname system were ones of astonishment
at how well that aspect of the lisp machine pathname system works. So it
seems to me that the facts are in direct opposition to your ``doom and gloom''
prediction. Do you contest this claim or practical experience to the contrary
which you would like to share?

Does anyone else have any opinion on this issue? I think the experience both
of users who have tried to port programs between radically different file
systems, and of implementors who support simultaneous interfaces to multiple,
very different file systems would be of interest. I think this is a
tremendously important issue and deserves considerable thought.

∂18-Jul-88  1433	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Jul 88  14:33:27 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 434816; Mon 18-Jul-88 17:32:09 EDT
Date: Mon, 18 Jul 88 17:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue BOGUS-FIXNUMS (initial draft)
To: sandra%cdr@cs.utah.edu
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880718173159.5.KMP@PEWEE.SCRC.Symbolics.COM>

The problem I have with being told I should DEFTYPE my own SMALL-INTEGER is the
following:

I believe that one of Lisp's greatest strengths (which is one of the things setting
it apart from Pascal, for example) is not just that it has the potential for
representing and defining things, but that it is gutsy enough to actually predefine
a set of things which people are likely to find useful.

Most languages can, for example, represent their own programs. eg, you could create
a PL/I program which constructed representations of other PL/I programs. The
important thing about Lisp is not that it can represent itself, but that there
is a common agreement about -how- to do such representation, so that non-cooperating
parties can agree.

I think this is at the heart of why jpff and jeff don't want to get rid of fixnum.
I'm happy with that.

It's just a pain for programmers to have to write the DEFTYPE. DEFTYPE is hard to
understand for a naive user. Using it involves at least a strong understanding of
the type system, a thorough enough knowledge of CL to know that DEFTYPE exists at
all, and a knowledge of how to use cons/list/backquote well enough to construct
a new specifier. On the other hand, if some arbitrary type were predefined, then
many people who understood only numerical programming could just go ahead and use
it. It might not serve all their needs, but it would get them started. And it would
get them used to the idea of a restricted range. Once you know the range is
-2↑16 to 2↑16 or whatever, it's easier to know to ask how to declare a different
range than it is to know to ask how to restrict the range if all you know is that
there is an unrestricted range initially.

Further, if we can agree on any range which makes us generally happy for a number
of small programs, then even if it's not -guaranteed- that it will be efficient,
then it will be -likely- that it will be efficient if only because people tend
to optimize things that have names much more than they optimized things you have
to compose, on the assumption that it's easier for users to trip over named things
and so such optmizations will have higher visibility.

So I think that saying that I should define my own type SMALL-INTEGER doesn't
satsify my need and I stand by my suggestions of my previous message.

∂18-Jul-88  1552	CL-Cleanup-mailer 	Re: issue BOGUS-FIXNUMS (initial draft)  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 18 Jul 88  15:49:52 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa04367; 18 Jul 88 16:31 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Mon, 18 Jul 88 16:52:03 BST
Message-Id: <2479.8807181552@subnode.aiai.ed.ac.uk>
To: cl-cleanup@sail.stanford.edu, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: issue BOGUS-FIXNUMS (initial draft)
Cc: jpff <@NSS.Cs.Ucl.AC.UK:jpff@maths.bath.ac.uk>

> Date: Tue, 12 Jul 88 09:08:25 MDT
> From: sandra <(Sandra J Loosemore)sandra%cdr@edu.utah.cs>

What I want to establish is: [1] Fixnums are about as useful as, say,
int or long in C (or if not can be made so rather than be eliminated),
In KCL, fixnums can actually be compiled as ints.  [2] It's nice to have
a standard name for efficient integers, and a standard name has to be in
the standard.  [3] Explicit subranges are not necessarily efficient and
are often less convenient to use.

Moreover, GZ has provided some examples from Macsyma that show that
fixnums can be used with a considerable degree of portability even as
now defined.

In short, the argument for eliminating fixnums seems to be based on an
overemphasis on one aspect of portability rather than a consideration
of what programmers actually do and want.

> > From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> > Date: Mon, 11 Jul 88 21:32:31 bst
> > 
> > Even though fixnums may differ from implementation to
> > implementation, I want a standard way to use them when they exist
> > rather than allow implementations to diverge (so that some call
> > them fixnums, others something else, and so on).
> 
> Having a standard name is of little use unless it is tied to some
> standard semantics.  The problem is that there is no guarantee what
> you get when you say "fixnum".  There is currently no absolute
> prohibition against defining the range of fixnums to be something
> like 100,000 to 100,010.

Well, then perhaps int and long in C are of "little use".  They are
not guaranteed to be the same size everywhere.

Note too that your argument is for reforming fixnums, not for
eliminating them, and I am not arguing against reform.

> If you want "small integer", then by all means define your own small
> integer type using DEFTYPE.  That way you're guaranteed to have it
> mean exactly the same thing in all implementations. 

You may want it to mean "exactly the same thing" (meaning exactly the
same size); that is not what I am asking for.  

Besides I don't want a small integer, I want an efficient one.  A
subrange is not guaranteed to be efficient, and so does not replace
FIXNUM.

> > I do not accept the argument that it doesn't matter because everyone who
> > provides fixnums can still provide them.  If they're not in the standard,
> > users cannot in fact rely on them being provided in a standard way.

Note that your response about packages below does not answer this.

> > Indeed, if we decide to allow only standard symbols in the LISP package,
> > users would have to type LUCID:FIXNUM, EXCL:FIXNUM, etc. rather than just
> > FIXNUM as they can now.

> Why not just import the appropriate symbol into the package you're using
> once, and be done with it?

This is still not providing fixnums in a standard way.  I still have
to add some conditional code for each implementation.

> > Date: Tue, 12 Jul 88 10:33:24 BST
> > From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK

> If your implementation supports a range of small integers
> that are more efficient than larger integers, there is already a portable
> way to declare them as such.  

The range gets ported, but the efficiency may not.  Fixnums work
adequately over a wide range of implementations without requiring
implementation-specific customization of my types.  I am even willing to
have some programs not work in implementations that have a sufficiently
losing notion of fixnums, just as I am willing to do this in other
langauges.

> To draw an analogy, small bignums are likely to be considerably faster and
> more efficient than large bignums.  Should we assign a special name to
> bignums with less than N "bigits" simply because they're faster than bignums
> that are larger than that?

That we do not want a name for every class of more efficient number
does not show we do not want a name for any such class.

Moreover, compilers can (or at least do) get more in the way of
optimization from fixnums than they would from "small bignums".

> It appears I was misinformed on this point -- I was under the impression
> that KCL boxed all integers and simply preallocated a range of small
> integers.

It does "box" all integers (though fixnum declarations may avoid this in
compiled code).  But the representation of fixnums is simpler than
that for bignums.  It is very much like Franz in this respect.

-- Jeff

∂18-Jul-88  1555	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 18 Jul 88  15:54:37 PDT
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa06386; 18 Jul 88 21:20 BST
Received: from xenakis by mordell.maths.bath.AC.UK id aa27619;
          18 Jul 88 21:45 BST
To: sandra <@cs.utah.edu:sandra@cdr>
CC: cl-cleanup@sail.stanford.edu, KMP@scrc-stony-brook.arpa, 
    jeff <@NSS.Cs.Ucl.AC.UK:jeff@aiva.edinburgh.ac.uk>, 
    jpff <@NSS.Cs.Ucl.AC.UK:jpff@maths.bath.ac.uk>
In-reply-to: sandra (Sandra J Loosemore)'s message of Tue, 12 Jul 88 09:08:25 MDT <8807121508.AA23357@cdr.utah.edu>
Subject: issue BOGUS-FIXNUMS (initial draft)
Date: Mon, 18 Jul 88 21:44:49 BST
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK

>>To draw an analogy, small bignums are likely to be considerably faster and
>>more efficient than large bignums.  Should we assign a special name to
>>bignums with less than N "bigits" simply because they're faster than bignums
>>that are larger than that?  How useful would having such a special name be
>>when both N and the size of the "bigit" vary from implementation to
>>implementation? 

But the factors are much much bigger.  I still am not conmvinced by
your arguments for getting rid of FIXNUMS.  Maybe they should be
better defined, but I cannot see a portable way of getting the effect
I get in FORTRAN, C, etc etc

==John

∂18-Jul-88  1556	CL-Cleanup-mailer 	issue BOGUS-FIXNUMS (initial draft) 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 18 Jul 88  15:56:28 PDT
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa07064; 18 Jul 88 23:11 BST
Received: from xenakis by mordell.maths.bath.AC.UK id aa28020;
          18 Jul 88 23:36 BST
To: KMP@scrc-stony-brook.arpa
CC: sandra <@cs.utah.edu:sandra@cdr>, CL-Cleanup@sail.stanford.edu
In-reply-to: Kent M Pitman's message of Mon, 18 Jul 88 17:31 EDT <880718173159.5.KMP@PEWEE.SCRC.Symbolics.COM>
Subject: issue BOGUS-FIXNUMS (initial draft)
Date: Mon, 18 Jul 88 23:36:04 BST
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK

>>   The problem I have with being told I should DEFTYPE my own SMALL-INTEGER is the
>>   following:

That is well put; I think that is what I was trying to say.  Thank
you.
==John

∂18-Jul-88  1957	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 18 Jul 88  19:57:11 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 18 Jul 88 22:56:05 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1) 
In-reply-to: Your message of Mon, 18 Jul 88 17:02:00 -0400.
             <880718170217.3.KMP@PEWEE.SCRC.Symbolics.COM> 
Date: Mon, 18 Jul 88 22:55:49 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


    Can you elaborate on the kind of ``confusion and paralysis of truly
    awsome proportions'' you expect?
    
Sure.  I expect to see several hundred spurious bug reports of the form "I
told Lisp to replace the extension of this file with `foo' and for some
unknown reason it insisted on producing `filename.FOO'.  That's the form
the spurious report would take for people on lower-case systems like Unix
-- others would have a slightly different problem.

I agree that it would be nice if everyone read the manual, but if a feature
of the language is sufficiently non-intuitive, people are going to be
burned even if there's a warning in red letters -- they'll just refuse to
believe that the language designers could have been so perverse.  Suppose
we decided that it would be useful to represent positive integers as "-n"
and negative integers as "+n".  Do you think that documenting this decision
would turn it into good language design?  I think not, but you are
proposing to tell Unix-based users, and lots of others, that for them "FOO"
means you want lower case in the filename and "foo" means you want upper
case.

As you point out, this would an effectively incompatible change in a part
of the language that is used moderately heavily, though usually for rather
simple tasks.  A lot of users regard most of the pathname stuff as bizarre
nonsense that they really don't want to understand, but they have learned
to do a few simple things (e.g. moving files between directories and
changing file extensions) by rote.  Only a few sophisticated users are
concerned with writing code that works across many systems with radically
different file-naming conventions.  If we can give these sophisticated
users a better way in which to do their job, fine, but I don't think we
should accomplish this by screwing the people who have existing code that
solves their little file problems within, say, an all-Unix environment and
who never plan to export their code to Tenex.  (I hope you aren't going to
reply that such people deserve to be screwed, since they should not be
writing nasty non-portable code.)

    Can you also give a couple examples of what you consider portable
    uses of the current paradigm which do not involve the use of READ-LINE
    in order to obtain a namestring in the first place?
    
No.  I think that the existing pathname stuff is pretty much a dead loss
for this purpose due to the problem you describe and several others.  If it
were up to me, we'd toss this pathname mess out and start over, but it's
too late for that.  If we can patch over the worst of these problems, fine,
that's useful.  I'm not arguing with your goals.  I just don't think we
have to do this in a way that breaks existing code and that will stand
forever as a textbook example of counter-intuitive language design.

Aside from my distaste for a system in which "foo" means "FOO" and
vice-versa, I do have one technical objection to your proposal: unless I've
missed something, there's no way to specify that you want some string to be
used verbatim, regardless of the target system, unless that string happens
to be of mixed case.  I guess in unix the "canonical" case is lower, but
sometimes you want to specify a file whose name is something like
"foo.BAR".  So if we overload the field-value strings to signal
case-canonicalization, we need some way to quote these strings and say
"this is really what I want, so leave it alone".

Would it suffice to add a :CANONICALIZE-CASE keyword to MAKE-PATHNAME for
those few users who really are trying to write code that will run on all
known systems?  That would be an upward compatible change.  If we need
field-by-field control of case-canonicalization, I think that the
CANONICALIZE-CASE function I proposed earlier does the job quite well, even
if it is a bit verbose.  I'd rather have a form that states that this
canonicalization is going on than to surprise naive users by doing it when
they are not expecting it.  Alternatively we could try to work out the
syntax for a new function or macro, MAKE-PORTABLE-PATHNAME, that
accompanies each field specifier with a flag of some sort indicating how
the case is to be treated.

    The pathname
    system from which I took the idea for this proposal is one of very few I
    know of which has tried this approach and demonstrated it to be workable in
    the face of numerous operating systems. Frankly, the only comments I've ever
    heard numerous users of the Symbolics pathname system were ones of astonishment
    at how well that aspect of the lisp machine pathname system works. So it
    seems to me that the facts are in direct opposition to your ``doom and gloom''
    prediction. Do you contest this claim or practical experience to the contrary
    which you would like to share?
    
No, I'm just flaming, based on instrospection and my rough model of how
naive users are likely to think; I haven't run any experiments.  If you
tell me that Symbolics already uses the system that you propose and that
the users are unanimous in their praise of it, I guess I'll have to accept
that, surprising as it may be.  I know that I personally would find it
confusing to write "foo" when I mean "FOO" and vice versa, but then I've
always been kind of slow at catching onto these advanced programming
concepts.  Maybe I'm the only one with this hangup, or maybe I'm typical
and the Symbolics user community has learned not to complain about things
that seem overly complex and counter-intuitive.

Some other views would be useful at this point.  If the rest of you think
that KMP's proposed change is the most intutive way to handle this case
problem, I'll shut up -- I no longer have formal voting rights in any case.

-- Scott

∂18-Jul-88  2033	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Jul 88  20:33:18 PDT
Received: from Burger.ms by ArpaGateway.ms ; 18 JUL 88 20:31:59 PDT
From: masinter.pa@Xerox.COM
Date: 18 Jul 88 20:31:02 PDT
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
In-reply-to: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Mon, 18 Jul 88 22:55:49
 EDT
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
 CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880718-203159-4394@Xerox>

My general goal is to try to standardize current practice, and reduce needless
divergence. As far as I can tell, there are lots of both case sensitive and case
insensitive file systems around. We might be lucky if we can 

a) standardize how pathnames work when talking to various kinds of operating
systems (e.g., all Unix Common Lisps should use file names the same way) and

b) give users some guidelines on how to write portable code given that there are
inevitable differences.

Certainly a proposal that mandates an "unnatural" interface between Lisp and the
host operating system will be rejected by the operating system vendors.

∂19-Jul-88  0805	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Jul 88  08:05:43 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 435112; Tue 19-Jul-88 11:04:36 EDT
Date: Tue, 19 Jul 88 11:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
To: masinter.pa@Xerox.COM, Scott.Fahlman@B.GP.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880718-203159-4394@Xerox>,
             The message of 18 Jul 88 22:55 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU
Message-ID: <880719110427.6.KMP@PEWEE.SCRC.Symbolics.COM>

    Date: 18 Jul 88 20:31:02 PDT
    From: masinter.pa@Xerox.COM

    My general goal is to try to standardize current practice, and reduce needless
    divergence. As far as I can tell, there are lots of both case sensitive and case
    insensitive file systems around. We might be lucky if we can 

    a) standardize how pathnames work when talking to various kinds of operating
    systems (e.g., all Unix Common Lisps should use file names the same way) and

    b) give users some guidelines on how to write portable code given that there are
    inevitable differences.

Speaking now with my user's hat on, I must say that I think this is a
complete whimp-out.

The plain fact is that programmers need MUCH more than a&b, and we are capable
of providing it. Current practice is that there are at least some implementations
which deal exceedingly well with a lot of kinds of operating systems in the
same environment. If we cannot select and standardize on one of those models, it
seems clear to me that the reasons are political and not technical.

    Certainly a proposal that mandates an "unnatural" interface between Lisp and the
    host operating system will be rejected by the operating system vendors.

I can't tell if this remark about unnaturalness alludes to my proposal,
but I'll assume it does and reply on that premise...

I don't intend to propose an "unnatural" interface between Lisp and the
host operating system. In fact, I don't see the functions I'm proposing changing
as part of the interface between Lisp and the operating system. I see them as
an interface to an abstract operating system.

The purpose of the pathname system seems to me to have been to abstract away
from operating systems a bit and provide a portable file system model which
was device independent.

For example, we typically parse out `type' information where there
really is none on Unix. That idea is in some sense unnatural to Unix, but it
is not unnatural to the idea of a file system, and CL programmers thought it
would be useful. So we created a model and users seem happy with it because
it provides them something of value.

Issues of case are completely non-trivial to writers of portable code. The
proposed solution does not intend to slight any host operating system. The
idea is to say that there is a partition in the file system interface:

A pathname is an abstract representation of a filename. It contains
information in its slots which ties it to a particular host file system,
but it is designed in such a way that it can be manipulated with minimum
regard for the particular characteristics of the host operating system. 
The MAKE-PATHNAME operation creates pathnames.
    
PATHNAME-HOST, PATHNAME-DEVICE, etc. access the abstract representation.

A namestring is a concrete representation of a filename. Since
namestrings are not portable, a namestring is rarely part of a program
and is more commonly the result of user typein or of an operation such
as NAMESTRING which coerces a pathname to its native string
representation.

An Idea

In some ways this smells of the FIXNUM issue. Perhaps the problem is
partly just that you have interesting functionality that you don't want
to lose and I can talk you into just `saying what you mean.' Currently
there are two arguably desirable pieces of functionality, and only one
name. Maybe if there were two names, we could make one name refer to what
Scott wants and one name refer to what I want.

In Genera, you can do (SEND pathname :RAW-NAME), etc. to see the
host-specific values, but hardly anyone ever does this in any code I've
ever seen. I would be willing to extend the proposal in any of the
following ways if it would make it more palatable to anyone:

 (a) Add functions PATHNAME-RAW-DEVICE, PATHNAME-RAW-DIRECTORY, 
     PATHNAME-RAW-NAME, PATHNAME-RAW-TYPE, PATHNAME-RAW-VERSION.
     [We could use "NATIVE" instead of "RAW" if people found that more
      appealing. It is longer, though.]

 (b) Add an optional NATIVE-P argument which controlled case translation
     and such in the PATHNAME-xxx accessors. For the sake of portability,
     I would definitely want this argument to default to NIL (meaning that
     the default was to return a canonicalized value, but that it could
     be overridden to inhibit this behavior by people that wanted it).

There are also a couple of interesting variants of (a) which we could
even play with:

 (a1) Make functions FILENAME-HOST, FILENAME-DEVICE, etc. which were like
     PATHNAME-HOST, etc. except:
	- They would accept any argument that was coerceable to a
	  pathname.
	- They would return the argument in native form.
     eg, (FILENAME-NAME "/foo/bar.lisp") => "bar" on Unix

 (a2) Extend the set of functions like FILE-NAMESTRING to include
      NAME-NAMESTRING, TYPE-NAMESTRING, and VERSION-NAMESTRING so that
      it would be more easily possible to pick apart namestrings.

These latter two, especially a1, have the version of making the -raw-
things feel perhaps less like second-class citizens. [Personally, I don't
really care if they are second-class citizens because in my view they
really are. CL is supposed to be a portable language, and I'm content to
provide non-portable features only to the extent that it doesn't get in
the way of providing portable ones. In this case, the names PATHNAME-NAME,
etc. have a right (I feel) to the portable semantics. As long as we don't
muck with that, I'm content to provide whatever else is necessary to
make others happy.]

Aside to Fahlman: I don't think voting rights have much to do with
anything in this forum, so I wouldn't worry about that. I'm happy to
hear your opinion when you're willing (as you were) to elaborate on
your fears enough that we can have a technical discussion.

∂19-Jul-88  0823	CL-Cleanup-mailer 	EQUAL, and hash tables, and value/object distinctions   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Jul 88  08:23:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 435123; Tue 19-Jul-88 11:23:14 EDT
Date: Tue, 19 Jul 88 11:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: EQUAL, and hash tables, and value/object distinctions
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: Greenwald@STONY-BROOK.SCRC.Symbolics.COM, jrose@sun.com, goldman@vaxa.isi.edu,
    common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8807190705.AA05728@bhopal.lucid.com>
Message-ID: <19880719152249.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
bcc: CL-Cleanup@SAIL.STANFORD.EDU

    Date: Tue, 19 Jul 88 00:05:31 PDT
    From: Jon L White <edsel!jonl@labrea.stanford.edu>
    ....numerical equality and inequalities are not
    information losing, and should in fact be transitive relations.  About 
    one year ago, I pointed out this difficulty to Guy Steele with some well-
    chosen examples; and he was quite shocked -- indeed it was his intention 
    that "=" be a true equivalence predicate.

I agree that = should be transitive even when floating-point numbers are
involved.  I.e. (= (/ 10.0 single-float-epsilon)
                   (1+ (floor (/ 10.0 single-float-epsilon))))
should be NIL, since 
                (= (/ 10.0 single-float-epsilon)
                   (floor (/ 10.0 single-float-epsilon)))
is certainly T and
                (= (floor (/ 10.0 single-float-epsilon))
                   (1+ (floor (/ 10.0 single-float-epsilon))))
is certainly NIL.  To understand this example better, it helps
to realize that (= (/ 10.0 single-float-epsilon)
                   (+ (/ 10.0 single-float-epsilon) 1.0))
is true in all implementations.

Since CLtL p.194 expressly forbids this, requiring the first form above
to return T, shouldn't somebody submit an X3J13 Cleanup subcommittee
proposal before it's too late?

    Lucid's 3.0 release performs "appropriate contagion" in the case of
    numerical comparisons, in order to preserve transitivity.

I'm a little surprised that Lucid would change their implementation
incompatibly with both CLtL and previous Lucid implementations without
first getting some concensus that the current definition of Common Lisp
is wrong and in fact will change.  I know Symbolics specifically decided
not to "fix this bug" unilaterally when we noticed it some time ago,
considering that compatibility was more important.  Chacun a son gout.

∂19-Jul-88  1342	CL-Cleanup-mailer 	SUBTYPEP-TOO-VAGUE, version 2  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Jul 88  13:42:20 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA27114; Tue, 19 Jul 88 14:41:47 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA00292; Tue, 19 Jul 88 14:41:39 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807192041.AA00292@cdr.utah.edu>
Date: Tue, 19 Jul 88 14:41:32 MDT
Subject: SUBTYPEP-TOO-VAGUE, version 2
To: cl-cleanup@sail.stanford.edu

Here is a revised version of SUBTYPEP-TOO-VAGUE.  I changed the status
of the MEMBER type specifier and added a requirement that EQUAL type
specifiers be recognized as equivalent.


Issue:		SUBTYPEP-TOO-VAGUE
References:	CLtL p. 72-73
Category:	CLARIFICATION
Edit History:   Version 1, 11 Jul 1988 (Sandra Loosemore)
                Version 2, 19 Jul 1988 (Sandra Loosemore)


Problem Description:

The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined.  In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier). 

Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship.  This makes it difficult to depend on
subtype relationships in portable code.


Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY

(1) Clarify that SUBTYPEP is allowed to return a second value of NIL
only when either of the type specifiers involves the SATISFIES, MEMBER,
NOT, AND, OR, the list form of FUNCTION, or VALUES type specifiers.

(2) If a type specifier defined with DEFTYPE is passed to SUBTYPEP,
SUBTYPEP must treat it in the same way as if its expansion were passed
instead.

(3) SUBTYPEP must always return values T T in the case where the two
type specifiers (or their expansions) are EQUAL.

(4) Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation.  For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).


Rationale:

It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
MEMBER, AND, OR, and NOT are messy to deal with.  I don't know how one
would compare FUNCTION or VALUES type specifiers; some rules could be
established to clarify how to compare them but I don't think it would
would be particularly useful to do so. 


Current Practice:

The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE and does not recognize
EQUAL type specifiers as being equivalent.  Most other implementations
appear to be substantially in conformance with the proposal.


Cost to implementors:

Some implementations will have to rewrite and/or extend parts of SUBTYPEP.


Cost to users:

None.


Benefits:

An area of confusion in the language is cleared up.  Usages of SUBTYPEP
will be more portable.


Discussion:

Item (4) appeared to be the consensus from a discussion on the
common-lisp mailing list some time ago.

A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE.  For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE.  Should this proposal be
extended to deal with these issues, or is another proposal in order?

Do the rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail, or are they obvious?
-------

∂19-Jul-88  1350	CL-Cleanup-mailer 	more on BOGUS-FIXNUMS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Jul 88  13:49:52 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA27381; Tue, 19 Jul 88 14:49:30 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA00305; Tue, 19 Jul 88 14:49:26 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807192049.AA00305@cdr.utah.edu>
Date: Tue, 19 Jul 88 14:49:19 MDT
Subject: more on BOGUS-FIXNUMS
To: cl-cleanup@sail.stanford.edu

Apologies if this is a repeat -- I sent this message out a few days
ago but it seems to have dropped into the bit bucket.  I'm willing to
write up a new proposal on this issue, but I'm not sure what direction
the committee wants it to go in.

----

Since it appears that nobody besides me (and Stan) likes my previous
proposal on this issue and that I'll have to come up with something
less radical that is more acceptable to the rest of the committee, I
thought it would be useful to enumerate some of the possibilities.  I
realize there are still two other issues which would still have to be
addressed when turning any of these into a real proposal, namely
whether to retain MOST-BLETCHEROUS-FIXNUM :-), and whether the BIGNUM
type specifier should remain and whether it must still be a non-empty
set which is disjoint from FIXNUM. 

#0 (what CLtL says):
    - there is no particular type specifier defined for "small integers".
    - the FIXNUM type specifier is defined but nothing is said about its
      range.
    - FIXNUMs are required to have a more efficient representation than
      non-FIXNUMs.

#1 (my original proposal):
    - there is no particular type specifier defined for "small integers".
    - the FIXNUM type specifier goes away.
    - user-defined integer subrange types use the most efficient 
      representation possible in a given implementation.

#2 (Gail Zacharias's counter-proposal):
    - there is no particular type specifier defined for "small integers".
    - the FIXNUM type specifier is defined to be a superset of
      (SIGNED-BYTE n), for some value of "n" which has yet to be
      decided but that we all agree upon.
    - FIXNUMs are not required to coincide with or be a subset of the
      set of integers which are represented most efficiently.

#3 (change CLtL's "typically" to a firm requirement):
    - there is no particular type specifier defined for "small integers".
    - FIXNUMs must be a supertype of (SIGNED-BYTE n).
    - FIXNUMs are defined to be the set of integers which are represented
      most efficiently.

#4 (dumb, but here for completeness):
    - there is no particular type specifier defined for "small integers".
    - the FIXNUM type specifier is defined to be equivalent to
      (SIGNED-BYTE n).
    - FIXNUMs are required to be a subset of the integers which are
      represented most efficiently.

#5: (Kent Pitman's suggestion):
    - a new SMALL-INTEGER type specifier is introduced which is equivalent
      to (SIGNED-BYTE n).
    - the FIXNUM type specifier goes away.
    - nothing is guaranteed about the efficiency of representation of
      SMALL-INTEGERs.

#6 (similar to #3):
    - a new SMALL-INTEGER type specifier is introduced which is equivalent
      to (SIGNED-BYTE n).
    - the set of FIXNUMs is required to be a superset of SMALL-INTEGERs.
    - FIXNUMs are defined as the set of integers with the most efficient
      representation.  (This implies that SMALL-INTEGERS are also
      guaranteed to be efficient.)

#7 (a cross between #0 and #5):
    - a new SMALL-INTEGER type specifier is introduced which is equivalent
      to (SIGNED-BYTE n).
    - the FIXNUM type specifier remains but the range of FIXNUMs is left
      undefined, as is the relationship between FIXNUM and SMALL-INTEGER.
    - FIXNUMs are defined as the set of integers with the most efficient
      representation.  Nothing is guaranteed about the efficiency of 
      SMALL-INTEGERs.

Comments, anyone?  

-Sandra
-------

∂19-Jul-88  1453	CL-Cleanup-mailer 	more on BOGUS-FIXNUMS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Jul 88  14:53:08 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 435456; Tue 19-Jul-88 17:52:04 EDT
Date: Tue, 19 Jul 88 17:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: more on BOGUS-FIXNUMS
To: sandra%cdr@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8807192049.AA00305@cdr.utah.edu>
Message-ID: <880719175155.9.KMP@PEWEE.SCRC.Symbolics.COM>

I'd like to see a full blown proposal based around #7.

∂20-Jul-88  1147	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Jul 88  11:44:38 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa06730; 20 Jul 88 19:18 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Wed, 20 Jul 88 19:13:13 BST
Message-Id: <8514.8807201813@subnode.aiai.ed.ac.uk>
To: KMP@scrc-stony-brook.arpa, Scott.Fahlman@b.gp.cs.cmu.edu, 
    masinter.pa@xerox.com
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Cc: CL-Cleanup@sail.stanford.edu

> Date: Tue, 19 Jul 88 11:04 EDT
> From: Kent M Pitman <KMP@arpa.scrc-stony-brook>

> A namestring is a concrete representation of a filename. Since
> namestrings are not portable, a namestring is rarely part of a program
> and is more commonly the result of user typein or of an operation such
> as NAMESTRING which coerces a pathname to its native string
> representation.

I guess I don't understand this point, because I don't see that pathnames
are all that portable.  Aren't the files usually in a different place on
different machines, and so musn't the pathname be different for different
machines?  A pathname might work if I'm creating a file and am willing to
have it go to some default place (the current directory, say), but
otherwise I may have to know there's a place called "/tmp" or something
of that sort.

Moreover, it turns out that many programs do contain namestrings.  The
defsys in PCL is one example.  They are immediately converted to pathnames,
but nonetheless start out as namestrings.

-- Jeff

∂20-Jul-88  1217	CL-Cleanup-mailer 	Re:  more on BOGUS-FIXNUMS
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Jul 88  12:17:00 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa06991; 20 Jul 88 20:01 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Wed, 20 Jul 88 19:55:54 BST
Message-Id: <8564.8807201855@subnode.aiai.ed.ac.uk>
To: KMP@scrc-stony-brook.arpa, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re:  more on BOGUS-FIXNUMS
Cc: cl-cleanup@sail.stanford.edu

> Date: Tue, 19 Jul 88 17:51 EDT
> From: Kent M Pitman <KMP@arpa.scrc-stony-brook>

> I'd like to see a full blown proposal based around #7.

It might be interesting to see one, but #7 has small-integers, which have
at least a certain size but may be inefficient, and fixnums, which are
efficient (if anything is) but may have (or not have) any size.  I am not
sure why anyone would want to use these small integers rather than specify
exactly what range/size they want.  Are we supposed to imagine they might
very well be efficient just as fixnums might very well be a reasonable
size?  The only definite advantage to small integers is that they're
portable, but they're portable in a sense I'm not sure anyone cares about.
A definite disadvantage, however, is to create confusion between fixnums
and small integers, and also confusion between these small integers and
what some Lisps have called small integers, namely the ones represented
"directly by pointers".

∂20-Jul-88  1535	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Jul 88  15:35:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 436177; Wed 20-Jul-88 18:33:07 EDT
Date: Wed, 20 Jul 88 18:32 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
    masinter.pa@Xerox.COM, Scott.Fahlman@B.GP.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8514.8807201813@subnode.aiai.ed.ac.uk>,
             <880719110427.6.KMP@PEWEE.SCRC.Symbolics.COM>,
             <880718-203159-4394@Xerox>,
             The message of 18 Jul 88 22:55 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU,
             <880718170217.3.KMP@PEWEE.SCRC.Symbolics.COM>,
             The message of 18 Jul 88 16:42 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU,
             <880701195711.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880720223239.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

I support the proposal (PATHNAME-COMPONENT-CASE:CANONICALIZE).  I think
current practice in the Symbolics Genera system (and I believe in the TI
Explorer system as well) has shown that this approach is very viable for
dealing portably with a wide range of file systems.  The choice of upper
rather than lower case as the canonical case is of course arbitrary; a
justification of upper case is for consistency with Common Lisp symbols.
I agree with Kent that if this situation is not straightened out, pathnames
are not very useful for portable programs, and that straightening out the
situation will be a big help in that respect.

I would also support a variant of this proposal that augmented the
portable pathname constructor and accessors with a native constructor
and accessors, either with different names or as additional arguments to
the same-named functions.  I assume Kent left the native constructor and
accessors out of his original proposal because he wanted to keep it lean
and omit unnecessary complications.  However, if Scott feels they should
be included, I'm happy to let them be included.  I agree with Kent that
in practice the portable operations are used much more commonly than the
native operations.  I believe this is because programs that work in
terms of native pathnames typically use namestrings and do not access
pathname components at all.

    Date: Wed, 20 Jul 88 19:13:13 BST
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
    
    I guess I don't understand this point, because I don't see that pathnames
    are all that portable.  Aren't the files usually in a different place on
    different machines....

I have to comment on this, because it's a common misconception.
Actually there are two points that have to be made.  First, we are not
talking about making pathnames portable, we are talking about making
pathname-manipulating programs portable.  That's a big difference!  The
point is to provide portable ways to perform the operations whose
details vary across file systems.  In fact that is the -only- point of
pathnames; if we didn't want to do that, we would just use strings and
manipulate them with string operations.  The pathname abstraction was
introduced solely to make pathname-manipulating programs portable.

The second comment is that it is in fact both possible and useful to make
pathnames themselves portable.  That would be the subject of a separate
proposal.  Again, this has been current practice in both Symbolics and TI
systems since before Common Lisp even existed, and works quite well.  The
interested reader can consult the documentation of "logical pathnames"
for either of those systems.  Basically the idea is to have an imaginary
file system that behaves in the same way everywhere, and that puts files
in the same place everywhere.  Then at each location one defines a set of
translations that implement the imaginary file system by mapping it into
a real file system.  Any namestring embedded in a program ought to be
a logical namestring if one expects that program to be at all portable.

∂20-Jul-88  1712	CL-Cleanup-mailer 	re: encourage no side-effect garbage
Received: from ucbvax.berkeley.edu by SAIL.Stanford.EDU with TCP; 20 Jul 88  17:11:58 PDT
Received: by ucbvax.berkeley.edu (5.59/1.28)
	id AA01259; Wed, 20 Jul 88 17:09:09 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
	id AA17562; Wed, 20 Jul 88 15:48:35 PDT
Date: Wed, 20 Jul 88 15:48:35 PDT
Message-Id: <8807202248.AA17562@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: re: encourage no side-effect garbage

My last comment in my proposal should be amended to say that what I
find distasteful is storage allocated in executing a Common Lisp
function that not returned to me as part of the return value AND
becomes garbage immediately upon return of the function.  Obviously
Lisp maintains internal state that includes allocated storage not
available to the user; this is not the object of my "distaste".

∂20-Jul-88  1732	CL-Cleanup-mailer 	proposal: encourage no side-effect garbage    
Received: from ucbvax.berkeley.edu by SAIL.Stanford.EDU with TCP; 20 Jul 88  17:32:42 PDT
Received: by ucbvax.berkeley.edu (5.59/1.28)
	id AA09177; Wed, 20 Jul 88 15:30:24 PDT
From: trwrb!smpvax1!jrg@ucbvax.berkeley.edu
Received: by trwrb.TRW.COM (5.51/1.36)
	id AA15969; Wed, 20 Jul 88 15:00:40 PDT
Date: Wed, 20 Jul 88 15:00:40 PDT
Message-Id: <8807202200.AA15969@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: proposal: encourage no side-effect garbage

Issue:         ENCOURAGE NO SIDE-EFFECT GARBAGE

References:    CLtL

Category:      ADDITION

Edit history:  Version 1, 20-Jul-88, Ginder

Problem description:

Many Common Lisp implementation create garbage as a side effect of
executing standard Common Lisp functions.  Under some circumstances,
this renders an Common Lisp "primitive" provided according to CLtL
unusable by applications under serious performance requirements or
virtual or physical memory space limitations.

Proposal:

Strongly encourage (not require) Common Lisp implementations to manage
internally-allocated storage in a manner so as not to generate garbage.
Explicitly point out that the quality of a Common Lisp implementation is
directly related to how well it solves this problem.

Rationale:

Some Common Lisp programmers need to write programs that react in
real-time to monitor physical processes or react to crisis situations.
It is imperative that some programs not be interrupted by a GC nor grow
so large by deferring GC that performance degrades.  It should be
possible to write programs with static memory requirements in Common
Lisp.

Current practice:

Programmers replace Common Lisp functions with private versions that
do not create garbage as necessary.

Cost to Users:

No cost, this is upward compatible.  (Users may get to throw away some
code, though!)

Cost of non-adoption:

Those programmers needing to avoid garbage creation can't or must
re-write parts of Common Lisp.

Benefits:

Unnecessary GC's will be avoided.  Common Lisp programs will work in a
more predictable manner.  Side-effect generation of garbage by an
implementation will become a more visible criterion for judging the
quality of an implementation.

Esthetics:

Neutral to vastly improved, depending on your orientation.  It is
extremely distasteful to me for a Common Lisp function to allocate more
storage than it returns to me as a value.



--Joe Ginder, Inference

∂20-Jul-88  1751	CL-Cleanup-mailer 	proposal: eliminate forced consing  
Received: from ucbvax.berkeley.edu by SAIL.Stanford.EDU with TCP; 20 Jul 88  17:51:41 PDT
Received: by ucbvax.berkeley.edu (5.59/1.28)
	id AA09616; Wed, 20 Jul 88 15:56:24 PDT
From: trwrb!smpvax1!jrg@ucbvax.berkeley.edu
Received: by trwrb.TRW.COM (5.51/1.36)
	id AA15976; Wed, 20 Jul 88 15:00:44 PDT
Date: Wed, 20 Jul 88 15:00:44 PDT
Message-Id: <8807202200.AA15976@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: proposal: eliminate forced consing

Issue:         ELIMINATE FORCED CONSING

References:    CLtL section 14.1,3,5; 15.2,5; 17.4; 18.3; 21.2

Category:      ADDITION

Edit history:  Version 1, 20-Jul-88, Ginder

Problem description:

The sequence functions included in CLtL encourage a programming style
that causes excessive storage allocation compared to libraries of
routines with similar functionality in other languages, notably C.
The only options available to the Common Lisp programmer who uses
these functions are to generate a newly-allocated sequence or to
destructively modify the argument sequence(s) given the function.

Proposal:

Add a :TARGET keyword argument to those sequence functions where such an
argument is useful, as specified below, which allows passing a target
argument sequence into which the result of the sequence computation is
to be placed.  The sequence function returns the target sequence
modified as specified below:

	(1) The target sequence must accomodate elements of the type(s)
	in the source sequence.  Thus it would be an error to give a
	target string argument if the source sequence had elements that
	were not of type STRING-CHAR.

	(2a) A non-list target sequence should have an allocated length
	long enough to accomodate the normal result of the sequence
	function.  It is permissable for the target sequence to have a
	fill pointer; in this case, the fill pointer is set to point
	immediately after the last element filled in by the sequence
	computation.  If the target sequence is longer than necessary,
	the unneeded trailing elements are unchanged.

	(2b) A list target sequence argument is extended with new conses
	to be as long as necessary to accomodate the resulting sequence,
	if not enough conses are supplied and the :TARGET-FROM-END keyword
	is nil.  The tail of the target list sequence not used to
	accomodate the sequence computation is returned as a second
	value by the sequence function, but remains linked as the tail
	of the target sequence.  [It might be desirable to return a
	third value, the last cons of the part of the list used for
	the result sequence, permitting the programmer to null-terminate
	that part of the target sequence, breaking the link with the
	unused tail, if appropriate.]

	(3) A :TARGET-FROM-END keyword is supported.  If non-nil, the
	target sequence is filled with new elements starting at the
	end of the target seqeunce, effectively reversing the order of
	elements of the resulting sequence in the target.  In this case,
	an error is signalled if the target sequence is not long enough
	for the result.  If the target sequence is longer than necessary,
	leading elements are unchanged.

	(4) :TARGET-START and :TARGET-END keywords are supported.
	TARGET-START and TARGET-END determine where in the target
	sequence the result of the sequence computation is placed.
	An error is signalled if the sub-length of the target
	sequence specified by these arguments is not long enough to
	accomodate the resulting sequence computation.  If a longer
	than necessary sub-length is specified, then the elements in
	the unneeded part of the specified sub-length are unchanged.

Affected sequence functions:
	subseq, copy-seq, reverse, remove, remove-if, remove-if-not,
	remove-duplicates, substitute, substitute-if, substitute-if-not,
	merge

Affected list functions:
	copy-list, butlast

	copy-alist, copy-tree, adjoin, union, intersection, set-difference,
	set-exclusive-or
 	  [no TARGET-START/END or TARGET-FROM-END, just destructive
	   use of the :TARGET conses]

Affected string functions:
	string-trim, string-left-trim, string-right-trim, string-upcase,
	string-downcase, string-capitalize 

Examples:

(copy-seq '(1 2 3) :target '(a b c d e f g))
	=> (1 2 3 d e f g)

(copy-seq '(1 2 3) :target '(a b c d e f g) :target-from-end t :end 5)
	=> (a b 3 2 1 f g)

(remove 'a '(b b a b b a b b a b b) :count 1 :target '(3))
	=> (b b b b a b b a b b)   ; EQ to :TARGET arg, CDR is new conses.

;;; Note, the :TARGET arg has a fill pointer.
(substitute #\a #\b "This is a string with 2 a's"
	    :target "0123456789012345678901234567890123456")
	=> "This is b string with 2 b's"

In a related addition, provide extended versions of concatenate, append,
revappend, and make-string-output-stream as follows:

	concatenate-into target &rest sequences
	  Like CONCATENATE, but the result type is determined to be
	  the type of TARGET.  The result is TARGET containing as many
	  of the elements of SEQUENCES as can be accomodated by the
	  allocated length of TARGET.  TARGET's fill pointer, if
	  present is set according to how many elements of TARGET ar
	  filled by this operation.

	concatenate-into-subseq target start end &rest sequences
	  Like concatenate-into, but copied from SEQUENCES into	the
	  sub-sequence of TARGET specified by START and END.

	append-into target &rest lists
	  Like APPEND, but the copied list arguments are copied into
	  conses taken from TARGET.  The last list in LISTS
	  is not copied, as in APPEND, rather, the last cons used
	  from TARGET is given the last list in LISTS as its cdr.
	  The result is EQ to TARGET (unless a single list is appended),
	  but contains only those conses needed to hold the appended
	  lists' elements.  The tail of unused conses from TARGET is
	  returned as a second value; new conses are allocated if
	  TARGET supplies an insufficient number of conses.

	revappend-into target x y
	  Like REVAPPEND, but the new conses are taken from TARGET.
	  The result is EQ to TARGET, but contains only those conses
	  needed to hold X's elements.  The tail of unused conses
	  from TARGET is returned as a second value; new conses are
	  allocated if TARGET supplies an insufficient number of conses.

	make-string-output-stream &optional string
	  Like the current MAKE-STRING-OUTPUT-STREAM, except if STRING
	  is provided, make the string-stream write to it rather than
	  a newly-allocated string.  An error is signalled if the output
	  overflows the supplied string.

A related optimization that compilers should be encouraged to support
is to recognize:

   (concatenate 'string (subseq ...) (subseq ...) (subseq ...) ...)

as being optimizable so as to avoid the allocation of storage for
intermediate SUBSEQ results.  This is a very common programming idiom
that can, of course, be expressed using the proposed extensions to avoid
intermediate consing.  However, the extensions do not provide as concise
and readable a mechanism for re-espressing this idiom as may others.
Other extensions might be considered to address this:

	(1) Provide a CONCATENATE function that takes a &rest
	argument of sequence/start/end triples.

	(2) Provide a special form like:
	       (designate-subseq sequence start end)
	that didn't actually allocate anything but provided an imple-
	mentation-specific "handle" on the subsequence for use
	in such expressions as the CONCATENATE expression above.
	(They'd print as the subseq, and setf's of their elements
	would destructively modify the original sequence.)	

However, there is no precedent in CLtL for (1).  And (2) seems like a
complex, sweeping change (for implementors) of limited benefit somewhat
in conflict (though more general than) displaced arrays.  So I don't
want to propose either.

Rationale:

It is sometimes better to use a more complex programming construct for
sake of efficiency than to use a less complex, more expensive one.
Excessive storage allocation is one of Lisp's most widely publicized and
least understood faults.

Current practice:

Similar functionality is provided for bit-vectors, as specified in CLtL
17.4.  A related capability is provided in the destructive versions of
some of the functions extended above.

When functionality similar to this is required, users must "roll their
own".  My experience in several commercial Lisp applications is that
avoiding storage allocation by using programming techniques such as this
may be critical to the success of a project.  The current sequence,
list, and string functions encourage an "expensive", albeit easier to
use, programming style that invites the creation of programs whose
performance suffers greatly in comparison to a program written to solve
the same problem written in C.

Cost to Implementors:

The cost of implementation of these extra sequence function arguments is
significant, but would not be burdensome compared to the utility
provided.  (In my humble opinion, of course.)

Cost to Users:

No cost, this is upward compatible.

Cost of non-adoption:

I submit that the cost of NOT implementing this sort of functionality is
that Common Lisp deserves the reputation it is rapidly gaining of being
very expensive to use, not in programmer productivity, but in the
resources required by the resulting programs.  While it is certainly
easier to write programs that always allocate new storage for results,
it is very expensive compared to what average programmers write in other
languages.  Sometimes the correct trade-off is to invest the extra
programming effort in development of a product in exchange for the
lowered resource requirements in the delivered system.  This is
particularly true when the deployed Lisp application may have thousands
of instances.  It may well be worth several extra man-years of effort to
use facilities such as those mentioned above rather than pay the
increased cost of deployment thousands of times!  (These costs are in
the form of more expensive hardware for deployment.  This might be due
to higher memory requirements or larger disk space requirements to
support a large virtual memory image.) If Common Lisp does not provide
this capability; programmers under serious performance constraints will
choose a different tool.

Benefits:

Those programmers choosing to invest the extra effort needed to
correctly use such facilities can do so with less overhead than
previously required, and will see performance improvement.  Programmers
learning Common Lisp will be challenged to understand the difference
between allocating new storage and re-using old storage as they
understand why these arguments are supported.  This is one of the chief
problems that most programmers encounter as they write Lisp programs.
I've encountered MANY occurances of this problem in helping people who
are trying to write Lisp programs as part of a real-world application
that is intended to be delivered on hardware for which someone must pay
real $$.  The problem encountered is that the program is too slow, or
requires hardware too expensive for practical deployment.  The most
common result is that the programmer gives up, proclaiming that Lisp is
too slow or too resource intensive, and rewrites his program in C.
Although these enhancements alone are not sufficient to solve the cited
problem, something along these lines is necessary as part of a more
complete solution that might include better training of Lisp
programmers, stack consing, and ephemeral GC.  The real benefit of
adopting this extension to sequence functions and similar extensions is
an increased chance of survival for Lisp as a viable tool for creating
deliverable applications.

Esthetics:

This proposal is likely to cause flames from the "functional
programming" camp (unless they've all left for Scheme).  It is
consistent (syntactically) with the existing keyword arguments to
sequence functions.  It adds to the plethora of keyword arguments already
present for many of these functions.

Discussion:

I'd likely tolerate any sort of statements in the new CL manual warning
naive users of the dangers of this programming style.  I agree that it
can be mis-used; but sometimes the benefit is worth the risk.  I simply
want Common Lisp to provide the choice.

Would adoption of these arguments eliminate the need for parallel
destructive versions for some of the affected functions?  (E.g., does
REMOVE with a :TARGET argument eliminate the need for DELETE.)

--Joe Ginder, Inference

∂21-Jul-88  0622	CL-Cleanup-mailer 	Re: proposal: encourage no side-effect garbage     
Received: from SEF1.SLISP.CS.CMU.EDU ([128.2.218.13]) by SAIL.Stanford.EDU with TCP; 21 Jul 88  06:22:28 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 20 Jul 88 22:59:15 EDT
To: trwrb!smpvax1!jrg@ucbvax.berkeley.edu
cc: cl-cleanup@sail.stanford.edu
Subject: Re: proposal: encourage no side-effect garbage 
In-reply-to: Your message of Wed, 20 Jul 88 15:00:40 -0700.
             <8807202200.AA15969@trwrb.TRW.COM> 
Date: Wed, 20 Jul 88 22:58:48 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


I share Joe Ginder's view that we ought to encourage Common Lisp
implementors not to cons promiscuously, but I don't think that such
non-binding encouragements belong in the standard, and I don't think we
ought to make cons-avoidance a requirement.  Users, and particularly large
vendors like Inference, should consider consing behavior as an important
criterion in choosing a Lisp, and should let vendors know that this is
at least as important to them as shaving a few microseconds off TAK.

If the standard is going to contain such encouragements, we should also
encourage implementors to be fast, stick to the standard, produce excellent
documentation, and fix bugs within ten days...

-- Scott

∂21-Jul-88  0623	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
Received: from SEF1.SLISP.CS.CMU.EDU ([128.2.218.13]) by SAIL.Stanford.EDU with TCP; 21 Jul 88  06:23:28 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 21 Jul 88 01:06:51 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1) 
In-reply-to: Your message of Wed, 20 Jul 88 18:32:00 -0400.
             <19880720223239.0.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Thu, 21 Jul 88 01:06:44 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


Dave,

I think that the problem here is that we see rather different classes of
programs and programmers.  At Symbolics and some of the big toolkit
vendors, most of the code that is written has to be portable to all known
file systems.  You people big, nasty portability problems to solve and you
want better tools for this.  If that means that lots of existing code has
to be broken and extremely counter-intuitive conventions have to be
adopted, well, that's a small price to pay.  And to you it seems obvious
that the case-hacking versions of of the pathname functions should get the
good names, since any code that is not portable to every known file system
is "second-class", to use KMP's label.

I see a different environment.  When I'm writing application code for my
own use, or for that of my colleagues at CMU, I want that code to be
portable across several different Common Lisp systems, but all of the file
systems around here are unix-like in their treatment of case.  In the
unlikely event that anyone wants to port this code to a TOPS-20 system,
they'll have to spend ten minutes fixing up a few pathname fields; I'm not
going to worry about that right now.  I'm not opposed to making things
portable across very different file systems, but I put a lower value on
this than the people who do it for a living.  I don't want to achieve this
goal in a way that breaks a lot of existing code and that uses syntactic
conventions that are going to confuse Lispers for generations to come.  I'm
not alone -- lots of people are working in environments where all the file
systems are similar in their treatment of case.

OK, let's accept that we need to solve this portable-case problem and see
if there is some less obnoxious way to do it.  Some ideas:

1. Nobody has responded to my suggestion that we add a :CANONICAL-CASE
keyword to MAKE-PATHNAME, which defaults to NIL.  If non-nil, this says
that all the field-name string are to be converted to canonical case.  If
we do it this way, we break no existing code.  New users and those writing
non-portable code would leave this off, and their field-name strings would
not change case in mysterious ways.  This would eliminate most of the
potential confusion I described in my previous note.

2. Same suggestion, but a non-nil :CANONICAL-CASE argument says to process
the fields the way KMP proposes: canonicalize, anti-canonicalize, or keep
the string as-is, depending on its case.  This gives us more flexibility
that option 1, though it is more complicated.  Again, this breaks no
existing code, and mysterious case-conversions don't happen until you ask
for them; at that point, you'd better have read the manual.  I suppose that
the accessor functions for pathname fields also need a keyword or optional
arg saying to do the hairy case conversions.

3. Make two sets of functions, one set handling the field names verbatim
and the other doing Symbolics-style case conversion.  But leave the good
names (the current ones) with the current non-converting definitions.
Again, we break no existing code and naive users are less likely to land in
the deep guano.  Sophisticated users writing ultra-portable code might have
to type a little more, but not a lot more, and such people are probably
clever enough to use word-abbrev mode.

I could live pretty happily with any of these three solutions; I'm still
pretty unhappy with the original proposal, despite the claim that Symbolics
and maybe TI users have learned to live with this system.  Have you
actually polled the people who get bug reports and who teach Lisp to your
new users to see if this convention is causing confusion?

-- Scott

∂21-Jul-88  0643	CL-Cleanup-mailer 	Re: proposal: eliminate forced consing   
Received: from SEF1.SLISP.CS.CMU.EDU ([128.2.218.13]) by SAIL.Stanford.EDU with TCP; 21 Jul 88  06:43:27 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 20 Jul 88 23:12:33 EDT
To: trwrb!smpvax1!jrg@ucbvax.berkeley.edu
cc: cl-cleanup@sail.stanford.edu
Subject: Re: proposal: eliminate forced consing 
In-reply-to: Your message of Wed, 20 Jul 88 15:00:44 -0700.
             <8807202200.AA15976@trwrb.TRW.COM> 
Date: Wed, 20 Jul 88 23:12:29 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


I wonder if anyone would use this TARGET stuff once we have a good
iteration facility built into the language.  I suspect that the existing
sequence functions will end up being used only in very straightforward
cases.

-- Scott

∂21-Jul-88  0803	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jul 88  08:03:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 88 07:59:17 PDT
Date: 21 Jul 88 07:59 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: more on BOGUS-FIXNUMS
In-reply-to: sandra%cdr@cs.utah.edu (Sandra J Loosemore)'s message of Tue, 19
 Jul 88 14:49:19 MDT
To: sandra%cdr@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880721-075917-3637@Xerox>

I think the SIGNED-INTEGER stuff is a little like PROCEDURE; there seems to be
some sentiment for just patching what we have rather than introducing new names,
especially where they are close.

I like #3; there's some precedent for turning a ClTl's "typically" to a firm
requirement where it encourages portability and there doesn't seem to be any
reason to avoid it. We must be specific about the "n". I'd propose "14", i.e.,
FIXNUMs must be a supertype of (SIGNED-BYTE 14). That's small enough not to give
even today's micros heartburn, and large enough to avoid having people squawk
too much.  It is consistent with current practice, and removes some of the
potential portability requirements. 

While we're at it, let's make FIXNUM a built-in class for CLOS? If its useful
for discrimination, and implementations have 'em, then why not be able to CLOS
them too?

If you want to get rid of something, get rid of BIGNUM. It doesn't fit into the
class hierarchy as nicely, you don't want to use it for class discrimination
(since it is (AND INTEGER (NOT FIXNUM)) and might really represent several
implementation types.)

∂21-Jul-88  0814	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jul 88  08:14:11 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 88 08:09:56 PDT
Date: 21 Jul 88 08:09 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1) 
In-reply-to: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Thu, 21 Jul 88 01:06:44
 EDT
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880721-080956-3657@Xerox>

I'd go for your #1 or #2.

∂21-Jul-88  0825	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Jul 88  08:25:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 436512; 21 Jul 88 11:23:58 EDT
Date: Thu, 21 Jul 88 11:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1) 
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 21 Jul 88 01:06 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU
Message-ID: <19880721152341.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 21 Jul 88 01:06:44 EDT
    From: Scott.Fahlman@B.GP.CS.CMU.EDU
    ....If we do it this way, we break no existing code....

You mean we break none of -your- existing code.  The only way to break no
existing code is to retain the unsatisfactory status quo.  Since CLtL is
not specific here, different implementations have resolved the ambiguity
in different ways, and if they are to be made all to work the same way,
some existing code will have to change.

If the above has an obnoxious tone, it's not intentional.  I simply mean
to point out that what you said is not accurate.

∂21-Jul-88  0833	CL-Cleanup-mailer 	[Masinter.pa: Re: questions]   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jul 88  08:33:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 88 08:20:56 PDT
Date: 21 Jul 88 08:20 PDT
From: Masinter.pa@Xerox.COM
Subject: [Masinter.pa: Re: questions]
To: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <880721-082056-3692@Xerox>

I should have cc'd this group on these, I think.


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

Date: 21 Jul 88 07:48 PDT
From: Masinter.pa
Subject: Re: questions
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 19 Jul 88 13:55
To: chapman%aitg.DEC@decwrl.dec.com


    Are the return values for close, in-package, inspect,
    provde, and require specified?


My guess is that close returns the stream, in-package returns the new pacakge,
inspect returns the item inspected (or a new item if your inspector allows
that), and provide and require return no values. Lets bundle them together until
someone asks to separate them.

    Is there a list of allowed query functions against a closed file?

Not that I know of. You mean a stream that is  the result of OPEN (since we've
established that where CLtL says file it might be OK to talk to Unix's /dev/null
but not a make-two-way-stream thing). You might want to make a best guess and
circulate them. 

    On page 354, "When the @xlisp printer types out the name of a
    special character, it uses the same table as the @f[#\] reader;
    therefore any character name you see typed out is acceptable as
    input (in that implementation).  Standard names are always
    preferred over non-standard names for printing."
    I'd like to change the last sentence to read "... are required
    over non-...".  Do you see a problem with that?


Well, I thought preferred was put there for a reason, and I can imagine
situations where a short-name might be preferred (the case I have in mind is
NewLine. If you're running on a system that talks both to cr and lf based file
systems, you might want to emphasize #\cr #\lf vs #\newline.) 

    On page 160,
    "@f[(ignore @i[var1] @i[var2] ... @i[varn])] affects only variable
    bindings and specifies that the bindings of the specified
    variables are never used.  It is desirable for a compiler to issue
    warning if a variable so declared is ever referred to or is also
    declared special, or if a variable is lexical, never referred to,
    and not declared to be ignored."
    Where is "issue a warning" defined? Should it be defined by the standard?


The compiler committee, bless their collective hearts, are supposed to help with
this issue. What the charter of the compiler is, what warnings it can and cannot
issue, is not specified well enough, which is why this is fuzzy. I'd suggest
editorially that you move this to a section on Compiler Operations (with a
forward reference to it) to give them something to focus on; what is and isn't
allowable behavior for a compiler should be separated from the semantics of the
language, however. 

One possibility is to establish another kind of error situation, a "warnable
condition", that is, something that is legal within the formal semantics of the
language but that a user might expect a compiler to warn about, including misuse
of ignore, a call to 
(+ 3 T) or some such. But I'm reaching.

    On page 24,
    "Symbols have a component called the @i[property list], or @i[plist].
    By convention this is always a list whose even-numbered
    components (calling the first component zero) are symbols,
    here functioning as property names, and whose odd-numbered components
    are associated property values.  Functions are provided for manipulating
    this property list; in effect, these allow a symbol to be treated as an
    extensible record structure."
    Can I change the "by convention" to say "it is required" or something like
    that?


Well, one of the cleanup proposals was discarded because (someone) asserted that
CLtL required property lists had to have an even number of components. I'm less
sure about GETF, which doesn't operate on symbol property lists. 

    On page 67,
    "Other implementation-dependent bookkeeping actions may be taken as well
    by @f[defun]."
    Can I leave this out?

I think so.

    Where a result is not specified to be a copy,
    does that mean it can or can't be, or that it's not allowed? 


I think it means that it can or can't be. That's been the interpretation for
lots of things, that it was deliberately left unspecified.

    The following have underspecified arguments:
	logbitp
	make-dispatch-macro-character
	make-hash-table
	make-sequence 
	make-string 
	nthcdr 
	parse-integer 
    Should I choose the "obvious" specification for the arguments or
    generate clean-up proposals for each one?


I think you should (a) choose the obvious specification, and (b) circulate a
single omnibus document saying that these are the editorial choices you've made,
anyone who wants to hear about the issues on any of them, we'll write it up in
full "cleanup" form. I don't want to bog down the process with stuff that isn't
controversial, however.

    When it is stated that a function supplied to another function
    (e.g. merge) "should not have any side effects", does that mean 
    "it is an error for the function to have side effects", or does it
    mean that if the function has side effects, the result will be
    implementation-dependent?


I'm a little fuzzy on the distinction between "it is an error" and "if you do
it, the results are implementation-dependent". 

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

∂21-Jul-88  0936	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Jul 88  09:36:18 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA24684; Thu, 21 Jul 88 10:35:57 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA01506; Thu, 21 Jul 88 10:35:53 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807211635.AA01506@cdr.utah.edu>
Date: Thu, 21 Jul 88 10:35:52 MDT
Subject: Re: more on BOGUS-FIXNUMS
To: Masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM, 21 Jul 88 07:59 PDT

> Date: 21 Jul 88 07:59 PDT
> From: Masinter.pa@Xerox.COM
> 
> I like #3; there's some precedent for turning a ClTl's "typically" to
> a firm requirement where it encourages portability and there doesn't
> seem to be any reason to avoid it. We must be specific about the "n".
> I'd propose "14", i.e., FIXNUMs must be a supertype of (SIGNED-BYTE
> 14). That's small enough not to give even today's micros heartburn,
> and large enough to avoid having people squawk too much.  It is
> consistent with current practice, and removes some of the potential
> portability requirements.

This is also my favorite alternative (next to removing FIXNUMs 
entirely, that is).

Actually, I don't think we have to worry particularly about supporting
micros.  According to Stan, it appears that the Lisp with the smallest
fixnum range is actually Franz Lisp, which uses a separate spaces
implementation with fixnums in the range [-1024, 1023].  Here are some
fixnum sizes for Lisp implementations that run on micros or otherwise
claim to be "small":

    Cambridge Lisp	24 bits
    PC Scheme		15 bits
    XLisp		C "long" (boxed, no bignums)
    VT-Lisp		no integers, all numbers are Pascal "real"s
    A-Lisp		30 bits  (immediate, no bignums)

Stan says Gold Hill would not disclose information about their
implementation.  It looks like all of other Lisp implementations he
was able to gather information on which claim to be Common Lisps (or
even subsets of Common Lisp) have fixnums at least 24 bits long.
Therefore, unless somebody comes up with a counterexample, I think we
could safely retain the N=16 from CLtL.


-Sandra
-------

∂21-Jul-88  1044	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Jul 88  10:44:00 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 436601; Thu 21-Jul-88 13:43:43 EDT
Date: Thu, 21 Jul 88 13:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880721134308.5.KMP@PEWEE.SCRC.Symbolics.COM>

Issue:        PATHNAME-WILD
References:   Pathnames (pp410-413)
Category:     ADDITION
Edit history: 21-Jul-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  Some file systems provide more complex conventions for wildcards than
  simple component-wise wildcards. For example,

  "F*O" might mean:
    - a normal three character name
    - a three-character name, with the middle char wild
    - at least a two-character name, with the middle 0 or more chars wild
    - a wild match spanning multiple directories

  ">foo>*>bar" might imply:
    - the middle directory is named "*"
    - the middle directory is :WILD
    - there may be zero or more :WILD middle directories
    - the middle directory name matches any one-letter name

  ">foo>**>bar" might mean
    - the middle directory is named "**"
    - the middle directory is :WILD
    - there may be zero or more :WILD middle directories
    - the middle directory name matches any two-letter name

  The CL pathname model does not provide a way to represent such wildcards,
  which means, for example, that (MAKE-PATHNAME :NAME "F*O") cannot be
  recognized by portable code as containing a wildcard.

  CL code needs to at least be able to detect and possibly to manipulate
  such wildcard pathnames.

Proposal (PATHNAME-WILD:NEW-FUNCTION):

  Introduce the following function:

   WILD-PATHNAME-P pathname &optional field-key			[Function]
 
   Tests a pathname for the presence of wildcard components.
   If the first argument is not a pathname an error is signalled.
 
   If no field-key is provided, or the field-key is NIL, this function
   returns true if the argument pathname has any wildcard components.
   Otherwise, it returns false.
 
   If a non-null field-key is provided, it must be one of :HOST, :DEVICE,
   :DIRECTORY, :NAME, :TYPE, or :VERSION. In this case, it returns true
   if the argument pathname is wild in the indicated component. Otherwise,
   it returns false.

Test Case:

  #1: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD)) => T

  #2: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :NAME) => T

  #3: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :TYPE) => NIL

  #4: (WILD-PATHNAME-P (PATHNAME "S:>foo>**>")) => T   ;Lispm

  #4: (WILD-PATHNAME-P (PATHNAME :NAME "F*O")) => T ;Most places

Rationale:

  If the programmer can at least detect wild pathnames reliably,
  he can know to do something useful (give up, merge out the bothersome
  components, call DIRECTORY for a list of matching pathnames, etc.)

Current Practice:

  Presumably no implemenation supports the proposal exactly as stated.

  Symbolics Genera provides the ability to do
    (SEND pathname :WILD-P)
  which returns a value such as NIL, :NAME, :TYPE, etc. In the case
  that more than one field is wild, however, some information is lost.

Cost to Implementors:

  Many implementations probably have a substrate which is capable of this
  or something similar already. In such cases, it's a relatively small
  matter to add the proposed interface.

  Even in cases where an implementation doesn't have ready code, it's clearly
  better for the implementor to write that code once and for all than to ask
  each user of wildcarded code to write it (often more heuristically).

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  Wild pathnames would continue to be mistaken for ordinary pathnames in
  situations which CL pathnames cannot represent.

Benefits:

  Portable user interfaces that prompt users for pathnames could more
  reliably detect wildcard pathnames and more easily guard against
  embarrassing behavior in such situations.

Aesthetics:

  This change would make some portable code less kludgey.

Discussion:

  Pitman supports PATHNAME-WILD:NEW-FUNCTION.

  If someone wanted to argue that this function should accept strings and such,
  coercing its argument to a pathname, I wouldn't object too strenuously. That
  would entail adding an optional host argument, though.

∂21-Jul-88  1205	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 21 Jul 88  12:04:07 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa06633; 21 Jul 88 19:56 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Thu, 21 Jul 88 19:52:13 BST
Message-Id: <10668.8807211852@subnode.aiai.ed.ac.uk>
To: Masinter.pa@xerox.com, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: more on BOGUS-FIXNUMS
Cc: cl-cleanup@sail.stanford.edu

> Date: 21 Jul 88 07:59 PDT
> From: Masinter.pa@com.xerox

> I like #3; there's some precedent for turning a ClTl's "typically" to
> a firm requirement where it encourages portability and there doesn't
> seem to be any reason to avoid it. We must be specific about the "n".
> I'd propose "14", i.e., FIXNUMs must be a supertype of (SIGNED-BYTE
> 14).

It may seem perverse to say so, but I'm not sure this would be an
improvement, for it would provide an implementation with 14-bit
fixnums with what they might regard as sufficient defense: they
strictly conform to the standard.  I have similar fears about the 1024
minimum for array-dimension-limit and array-total-size limit.  I don't
usually make sure my CL programs will run in a system where arrays
can't have more than 1024 elements, and if I did want to be sure I'd
look at the actual limit, not 1024.  But I'd probably complain if the
limit really were so low, and it somehow seems easier to say an
implementation's low limit is pretty rediculous when it isn't
explicitly sanctioned by the standard.  Perhaps if the minimums
were a little bigger...

Anyway, I favor a consistent policy on limits of this sort.  If we
have them for arrays, we can (should?) have them for fixnums.

∂21-Jul-88  1211	CL-Cleanup-mailer 	proposal: eliminate forced consing  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Jul 88  12:11:27 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 436665; Thu 21-Jul-88 15:07:09 EDT
Date: Thu, 21 Jul 88 15:06 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: proposal: eliminate forced consing
To: trwrb!smpvax1!jrg@ucbvax.berkeley.edu
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8807202200.AA15976@trwrb.TRW.COM>
Message-ID: <880721150632.7.KMP@PEWEE.SCRC.Symbolics.COM>

Or we might just use the type argument and the new CLOS type EQL:

 (LET ((X (MAKE-STRING 3 :INITIAL-ELEMENT #\a)))
   (EQ (MAP `(EQL ,X) #'CHAR-UPCASE X) X))

:-)

[I have not yet formulated a serious opinion on this issue.]

∂21-Jul-88  1302	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 21 Jul 88  13:01:43 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 21 Jul 88 16:00:21 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1) 
In-reply-to: Your message of Thu, 21 Jul 88 11:23:00 -0400.
             <19880721152341.2.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Thu, 21 Jul 88 16:00:02 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU

    
        Date: Thu, 21 Jul 88 01:06:44 EDT
        From: Scott.Fahlman@B.GP.CS.CMU.EDU
        ....If we do it this way, we break no existing code....
    
    You mean we break none of -your- existing code.  The only way to break no
    existing code is to retain the unsatisfactory status quo.  Since CLtL is
    not specific here, different implementations have resolved the ambiguity
    in different ways, and if they are to be made all to work the same way,
    some existing code will have to change.
    
Well, what I really meant was that we break no existing Common Lisp code,
where by "Common Lisp" code I mean code written according to any reasonably
straightforward interpretation of what is in the manual.  It hadn't
occurred to me that you folks at Symbolics consider the system describeed
by KMP to be in compliance with CLtL and not an extension -- a worthwhile
extension and perhaps even a necessary extension, given the problems you
want to solve.  KMP did label his proposal a "change" rather than a
"clarification", though I see that he claims in the discussion section that
it is technically in compliance with CLtL.  I have some doubts about
that claim, but let's not argue about that.

So, as you say, some of us are going to have to fix some existing code if
we try to standardize this situation.  If we have a way -- either a switch
or a separate set of functions -- to select either canonicalizing or
verbatim interpretations, whoever has to change his code can do so with a
simple editor macro.

So the only thing we're really fighting about is who gets the good function
names or the default version of switchable functions.  I still think that
the princple of least astonishment suggests that these field names ought to
be used verbatim unless the user specifically asks for canonicalization of
case.  We can make it easy to ask for the canonicalizing behavior (my
proposal 2 does that), but it shouldn't be the default.

One other suggestion: Whether we go with KMP's proposal or something like
my proposal 2, I think that we should use all-lower-case to indicate
canonical case, and all-upper to indicate anti-canonical case.  As someone
pointed out in an earlier message, this choice is arbitrary.  Other things
being equal, we may as well go with the arbitrary choice Symbolics made,
but other things are not equal.  Unix, the herpes of operating systems, is
still spreading and is going to be the file system most Lisps have to deal
with for at least the next 5 years, and probably 10.  Tops-20 is almost
dead, and I don't know of any other default-upper-case file systems that
are on the rise, at least in the communities to whom Lisp is important.  So
let's make the choice that minimizes the number of people who have to type
things in a case that is the opposite from what they want.  Of course, this
choice breaks some existing code, but we've already agreed that that is
necessary.

-- Scott

∂21-Jul-88  1308	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jul 88  13:07:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 88 12:55:03 PDT
Date: 21 Jul 88 12:56 PDT
From: masinter.pa@Xerox.COM
Subject: Re: more on BOGUS-FIXNUMS
In-reply-to: sandra%cdr@cs.utah.edu (Sandra J Loosemore)'s message of Thu, 21
 Jul 88 10:35:52 MDT
To: sandra%cdr@cs.utah.edu
cc: Masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <880721-125503-4335@Xerox>

Xerox Common Lisp has 17-bit fixnums. LISP:MOST-POSITIVE-FIXNUM = 65535,
LISP:MOST-NEGATIVE-FIXNUM = -65536.




∂21-Jul-88  1351	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 21 Jul 88  13:51:20 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 21 Jul 88 16:50:13 EDT
To: Masinter.pa@Xerox.COM
cc: sandra%cdr@cs.utah.edu, cl-cleanup@sail.stanford.edu
Subject: Re: more on BOGUS-FIXNUMS 
In-reply-to: Your message of 21 Jul 88 07:59:00 -0700.
             <880721-075917-3637@Xerox> 
Date: Thu, 21 Jul 88 16:49:53 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


I agree with Larry and GZ on this.

-- Scott

∂21-Jul-88  1417	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Jul 88  14:17:45 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 436759; Thu 21-Jul-88 17:16:58 EDT
Date: Thu, 21 Jul 88 17:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1) 
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 21 Jul 88 16:00 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU
Message-ID: <880721171622.0.KMP@PEWEE.SCRC.Symbolics.COM>

    Date: Thu, 21 Jul 88 16:00:02 EDT
    From: Scott.Fahlman@B.GP.CS.CMU.EDU

    ... I still think that the principle of least astonishment suggests
    that these field names ought to be used verbatim unless the user
    specifically asks for canonicalization of case.  We can make it easy
    to ask for the canonicalizing behavior (my proposal 2 does that), but
    it shouldn't be the default.

There's another theory that says that if he's going to be astonished,
let it happen early. The stated purpose of CL is to provide for the
development of portable programs. If you do a non-portable thing that
kinda feels right and implementations are encouraged to accept it without
warning and you have to know to say something magic to get something
portable, then you don't have a portable language and you don't encourage
portable programs.

Consider that we could have had a :PORTABLE keyword argument on all 
functions. Any time you wanted to opt for portable behavior, you could
ask for it. Then everyone could write

 (DEFUN FOO (X Y Z)
   (* (+ X Y :PORTABLE T) Z :PORTABLE T))

and when people didn't ask for portability, they wouldn't have to put up
with it. You'd get a lot jazzier functionality out of things, and people
would stop complaining about implementations that provided `gratuitous
extra functionality' because that would be the encouraged thing. For example,

 (DEFUN FOO (X Y Z)
   (* (+ X Y) Z))

-- without the :PORTABLE T arguments -- could be a lot faster because then
you could always use native arithmetic. Don't think there aren't CL
implementations which do almost just this (eg, they don't implement fixnums).

Plenty of people find it unintuitive that in present-day CL
 (* (THE FIXNUM X) (THE FIXNUM Y))
doesn't use a fixnum-multiply instruction (because you didn't type
declare the return value) but we just went and defined it in a way that we
knew it was important for it to work, even if it didn't come up too often.
Sorry about those short-sighted who get confused but having the language be
well-defined in a portable way is just more important. Some people are mad,
too, because they think they know the processor type they're on and know
what to expect from the fixnum-multiply instruction, but we've already made
the decision that supporting that activity just wasn't CL's priority.

We invented CL just -exactly- to get away from nonsense where an
implementor's interpretations were preferred over the needs of a community.
The default just has to be the thing which promotes portable applications.
If it's not, you can't test programs in one environment and have any
hope that it will therefore run in another.

It's true that in general there is no reference implementation of CL,
nor is one possible, and running your program in one implementation 
cannot be a guarantee that it will run in another, but that's nothing to
cheer about. That's just a sad thing we should be trying to minimize
rather than institutionalize.

And you just never know when your company or university might fold,
you might get tired of what you're doing and decide to move, or your
company might find itself on different hardware/os/file-system than
it ever thought possible ... and you might be happy you were made to
design in a feature that you never originally thought had a personal
meaning to you. [Certainly this happened to me when I moved from 
ITS/Tops-20 file servers at MIT to Lispm/VMS/Unix ones at Symbolics.]

    ... Whether we go with KMP's proposal or something like my proposal 2,
    I think that we should use all-lower-case to indicate canonical case,
    and all-upper to indicate anti-canonical case. ...

There are already several places where this arbitrary decision has been
made in Lisp. The decision has been made consistently, and I think that's
useful. I would hate to go against the grain:

 * Uppercase is the canonical case for non-backslashed symbols seen by
   the reader. eg, (symbol-name 'xyz) => "XYZ". (p168, p367, ...)
 
 * Uppercase is the canonical case for dispatch readmacros. eg, the chars
   received as arguments by # readmacro functions will have been upcased.
   The "a" in #a will be seen by the function supporting #a as #\A, not
   #\a. eg, see SET-DISPATCH-MACRO-CHARACTER (p364).
 
 * Uppercase is the default case for the Lisp printer. The default value 
   of *PRINT-CASE* is :UPCASE (p372).

You may be surprised to learn that I almost exclusively use file systems
where lowercase or mixed case is culturally preferred. My intent here is
not to force people to use uppercase filenames, or to assert that using
uppercase as a canonical internal case is no problem when I have no
experience with it. I use it daily and can't recall any problem with using
uppercase because
 - the only situations where it comes up is when I'm dealing with things
   I conceptualize as abstract primitives. I write (load "s:>kmp>foo.lisp")
   or (load (make-pathname :name "FOO" :type :lisp)), depending on what is 
   appropriate for the application.
 - it really does feel consisent with the canonical case for other things
   elsewhere in the language.

You can make whatever arguments you want about the prevalence of Unix, but
I don't think our language design has any business catering to a particular
style. The argument we make for the choice of canonical case should be
defensible in the abstract.

To me, the really compelling argument in this regard is the following:

 * Uppercase is the canonical case for spoken language.

   this is not a syntactically well-formed english sentence.
   THIS IS A SYNTACTICALLY WELL-FORMED ENGLISH SENTENCE.

Compatible with Unix or not, this is at least a position which can be defended
in the abstract.

∂21-Jul-88  1515	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 21 Jul 88  15:13:06 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa07572; 21 Jul 88 23:05 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Thu, 21 Jul 88 23:01:09 BST
Message-Id: <11002.8807212201@subnode.aiai.ed.ac.uk>
To: KMP@scrc-stony-brook.arpa, Moon@scrc-stony-brook.arpa, 
    Scott.Fahlman@b.gp.cs.cmu.edu, masinter.pa@xerox.com
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Cc: CL-Cleanup@sail.stanford.edu

Scott's porposals (1 and 2) for a :canonical-case keyword seem worth
considering, but whether 1 or 2 is better is less clear.  I'm still
not sure what anti-canonical accomplishes.  On a system that accpts
only one case, it can do nothing; on a system that accepts any case,
why change case at all?  Why not use whatever the user provides?  Some
case will be more common, but if we're trying to ignore the details of
the FS do we care?  OK, anti-canonical matters so I can still get that
case if I want it, and pathnames need to be able to represent such
namestrings.  2 then?

I do think this goes back to a question of exactly what portibility
gain is involved.  I can see that the Symbolics system does a number
of useful things, but I'm not sure how much each individual thing
does in isolation.

Moreover, pathnames are not useless without this change.  They are a
more sturctured representation than namestrings, and save one from
parsing.  Code that does not aspire to complete portability might
nonetheless use them.  There may also be code that wants to be
portable to different Unix systems, say, where the case problem will
not arise, or between different common lisps that parse namestrings
differently or single lisps that refuse to parse them "correctly"
(Unix names like ".lisprc", say, want to be merge-pathname'd as names
not types.)

> Date: Wed, 20 Jul 88 18:32 EDT
> From: "David A. Moon" <Moon@arpa.scrc-stony-brook>

> The second comment is that it is in fact both possible and useful to
> make pathnames themselves portable.  That would be the subject of a
> separate proposal.  Again, this has been current practice in both
> Symbolics and TI systems since before Common Lisp even existed, and
> works quite well.  The interested reader can consult the documentation
> of "logical pathnames" for either of those systems.

Done.

> Basically the idea is to have an imaginary file system that behaves in
> the same way everywhere, and that puts files in the same place
> everywhere.  Then at each location one defines a set of translations

Isn't this independent of pathnames per se?  (I.e., couldn't it be
done just by having a convention for namestrings?)

And I still have difficulty imagining interesting things portable
programs can do without such a convention (apart from the things
pathnames already provide, such as parsing).  Or, perhaps I should say
I have difficulty imagining interesting things made possible by the
canonical case proposal.  I can easily see the virtues of canonical
types.  But the gain from having the case made magically right seems
small.

-- Jeff

∂21-Jul-88  1537	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 21 Jul 88  15:37:00 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA00913; Thu, 21 Jul 88 18:35:01 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA03624; Thu, 21 Jul 88 18:38:31 EDT
Message-Id: <8807212238.AA03624@mist.UUCP>
To: Kent M Pitman <KMP%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: CL-Cleanup%SAIL.STANFORD.EDU@multimax
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1) 
In-Reply-To: Your message of Thu, 21 Jul 88 17:16:00 -0400.
             <880721171622.0.KMP@PEWEE.SCRC.Symbolics.COM> 
Date: Thu, 21 Jul 88 18:38:24 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    Date: Thu, 21 Jul 88 17:16 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
    
        ... Whether we go with KMP's proposal or something like my proposal 2,
        I think that we should use all-lower-case to indicate canonical case,
        and all-upper to indicate anti-canonical case. ...
    
    There are already several places where this arbitrary decision has been
    made in Lisp. The decision has been made consistently, and I think that's
    useful. I would hate to go against the grain:
    
I hate to agree with Kent here because I really prefer lower case for
everything possible, but he's right.  The decision to make uppercase
the default in Common Lisp was probably a mistake, but it's a mistake
we're stuck with.  Inconsistency is worse.

∂21-Jul-88  1546	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Jul 88  15:46:02 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 436854; Thu 21-Jul-88 18:43:52 EDT
Date: Thu, 21 Jul 88 18:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
    Moon@STONY-BROOK.SCRC.Symbolics.COM, Scott.Fahlman@b.gp.cs.cmu.edu,
    masinter.pa@xerox.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: <11002.8807212201@subnode.aiai.ed.ac.uk>
Message-ID: <880721184315.3.KMP@PEWEE.SCRC.Symbolics.COM>

    Date: Thu, 21 Jul 88 23:01:09 BST
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

    ... And I still have difficulty imagining interesting things portable
    programs can do without such a convention (apart from the things
    pathnames already provide, such as parsing).  Or, perhaps I should say
    I have difficulty imagining interesting things made possible by the
    canonical case proposal.  I can easily see the virtues of canonical
    types.  But the gain from having the case made magically right seems
    small. ...

I'd wager that there is a sizable number of TOPS-20 users out there who
don't know that the TOPS-20 file system admits lowercase names. The only
trouble is that to refer to such a filename in any of the normal TOPS-20
programs, you have to quote every character with Control-V.

Sure, you can say that (MAKE-PATHNAME :TYPE "foo" :VERSION "lisp") should
just create a file called "foo.lisp" on Unix and "foo.lisp" on TOPS-20 and
that should be fine for "portable" programs, but it's not because you have
to tell Emacs
 c-X c-F c-V f c-V o c-V o . c-V l c-V i c-V s c-V p
every time you want to edit the file. This is very unnatural even for people
who know it's what must be done. But for people who don't know it must be
done, they just wonder why "foo.lisp" shows up in their directory listing
but doesn't appear to be something they can edit or delete from outside of
Lisp!

The value you get from having canonical case is that files get created in
a natural way on any operating system.

It also turns out that this just makes file merging a lot simpler.
Consider an operation I do a lot on a day-to-day basis, which takes
advantage of the canonical type and canonical case issues:

 Command: Copy File (from) MYUNIX:/foo/bar/zap.l (to) MY20:
 Copying MYUNIX:/foo/bar/zap.l to MY20:<FOO.BAR>ZAP.LSP.0

rather than:

 Copying MYUNIX:/foo/bar/zap.l to MY20:<FOO.BAR>↑Vz↑Va↑Vp.↑Vl.0

which we might have if neither of these proposals passed.

Sure, you can say that the Copy File command could go to massively more
work using system-dependent knowledge to do all the case foolery to get
machine-to-machine copying correct, but the fact of the matter is that
if all this stuff were defined correctly, you could write COPY-FILE in
nearly portable code (I say nearly only because I'm glossing byte-size
issues, an orthogonal problem):

 (WITH-OPEN-FILE (FROM-STREAM FROM :DIRECTION :INPUT)
   (WITH-OPEN-FILE (TO-STREAM (MERGE-PATHNAMES TO FROM)
			      :DIRECTION :OUTPUT)
     (STREAM-COPY-UNTIL-EOF FROM-STREAM TO-STREAM)))

and everything else takes care of itself. You could also argue that the
hair belongs in MERGE-PATHNAMES but why make work for yourself? There
only needs to be hair at all if you can't get agreement on some trivial
issues, such as those on the floor. If we can just agree on these
details, then no programs will need to have any hair -- things will
just work out.

∂21-Jul-88  1633	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 21 Jul 88  16:31:46 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 21 Jul 88 18:08:44 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1) 
In-reply-to: Your message of Thu, 21 Jul 88 17:16:00 -0400.
             <880721171622.0.KMP@PEWEE.SCRC.Symbolics.COM> 
Date: Thu, 21 Jul 88 18:08:29 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


Let me see if I understand the philosophy underlying your argument.  It
seems to go as follows:

1. There are certain complex and difficult things that a Common Lisp
programmer must do in order to be sure that his code will be absolutely
portable across all known file systems, living and dead.

2. Some people believe that they don't care about that kind of portability.
If given a choice they will not worry about these painful and complex
things.

3. *WE* know that this attitude is short-sighted, so we should try to
remove the temptation to cut corners.  In this case, the best way to do
that is to make sure EVERYONE has to deal with these portability issues all
the time, whether they want to or not.

4.  In the end, they'll thank us for saving them from their baser
instincts.

-- or, more briefly --

Nobody ever expects the Spanish Inquisition!!!

Well, I've said my piece, and will abide by the decision of the committee.
If you and Moon can persuade some of the non-Symbolics people on the
committee that the good names should go to the portable case-bashing
versions, I'll disagree, but I can live with it.

-- Scott

P. S.  I don't agree with your "really compelling argument" about natural
language.  I don't think that an all-upcase sentence is any more
syntactically correct than an all-lower-case one.  But that's not
important, since your arguments about upper-case being the default
elsehwere in the language is a pretty good one.

∂22-Jul-88  0642	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)     
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 22 Jul 88  06:42:03 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 22 Jul 88 09:40:55 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1) 
In-reply-to: Your message of Thu, 21 Jul 88 17:16:00 -0400.
             <880721171622.0.KMP@PEWEE.SCRC.Symbolics.COM> 
Date: Fri, 22 Jul 88 09:40:41 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


After sleeping on it, I've decided that my arguments against your "Spanish
Inquisition" philosophy, forcing users to do everything in a portable way
aaginst their will, were silly.  As you say, Common Lisp does indeed make
people go the long way round in dozens of places in the language, all for
their own good and for greater portability.

The only difference here is that the need for porting code to file
systems of different case comes up much less often than other kinds of
porting issues, and many of us may never be faced with this; if we are,
it's easy to find and fix the problems.  And I still think it's a confusing
choice to use the case of a field to signal how you want the case to be
altered, though perhaps not fatally confusing.  I retain a mild preference
for giving the default names to the verbatim versions, but can live with
either choice.

-- Scott

∂22-Jul-88  0649	CL-Cleanup-mailer 	FIXNUM's aren't Bogus!    
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88  06:49:16 PDT
Received: by labrea.stanford.edu; Fri, 22 Jul 88 06:47:52 PDT
Received: from bhopal.lucid.com by edsel id AA07179g; Fri, 22 Jul 88 06:39:24 PDT
Received: by bhopal id AA04492g; Fri, 22 Jul 88 06:40:17 PDT
Date: Fri, 22 Jul 88 06:40:17 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8807221340.AA04492@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk, sandra%cdr@cs.utah.edu,
        cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 21 Jul 88 12:56 PDT <880721-125503-4335@Xerox>
Subject: FIXNUM's aren't Bogus!

re: Xerox Common Lisp has 17-bit fixnums. LISP:MOST-POSITIVE-FIXNUM = 65535,
    LISP:MOST-NEGATIVE-FIXNUM = -65536.

This choice is quite arbitrary.  FIXNUM is not constrained to mean
"immediate" data type (indeed it was NOT an immediate in PDP10 MacLisp), 
and Xerox Lisp's FIXP could just have well been included in its FIXNUM
type; that would have yielded a range of 32 bits rather than 17.  At one 
time, at least some implementations of Interlisp-D had microcode to cover 
the case of FIXP's; so it was a relatively efficient type.

MacLisp may be considered to be the father of the modern FIXNUM -- it 
originated the trick of reserving a couple pages of write-protected memory 
filled in with a dense neighborhood of integers centered around 0; thus 
"consing" a small fixnum didn't require new storage allocations.  The 
critical meaning for FIXNUM's, however, is not merely that they be "small",
nor that basic operations on them not consume storage, but that they be 
operable in a few, fixed number of steps.  In fact, in compiled code, the 
basic operations (on fixnums) were always one PDP10 instruction [including 
the four rationals, shifting, and even HAULONG, the predecessor of CL's 
INTEGER-LENGTH.  Love that JFFO!]  A *uniform* representation for fixnums 
was the critical factor in compiling these operations into one machine 
instruction.

The opposite of FIXNUM is thus a datum that falls into the asymptotic 
algorithms of "bignums", whose operational timing is proportional to the 
length of the numbers involved. 

I propose this meaning for FIXNUM: that the basic integer operations
use algorithms that are not proportional to the size of the data;  it 
should be just about as fast to add numbers in the middle of the fixnum 
range as it is to add, say, 10 and 11.

I would _prefer_ that the range of positive FIXNUM's be at least as large 
ARRAY-TOTAL-SIZE-LIMIT, so that one can be assured that any legitimate 
array index is a FIXNUM.  However, I'll admit that this is of more
concern to an implementation on "stock" hardware with "general purpose"
indexing registers.


Regarding the portability issues raised by differing FIXNUM ranges --
I agree with all of Jeff Dalton's comments.  Championing portability
here is making a mountain of a molehill.


-- JonL --


P.S.  A candidate for early fixnums might also be Interlisp-10's assymetric 
     representation, wherein very small integers were "immediate" and 
     medium-sized integers fit into one word (maybe Lisp1.5 had a similar 
     scheme too?).  Although operating on such a representation did not 
     require use of an "asymptotic" algorithm, it did require so much more 
     time than the PDP10 MacLisp scheme that they were not considered 
     particularly "efficient" by the relevant community of users.  In fact,
     just decoding the representation cost a subroutine call.  [Who among 
     us remembers (JSP T, NUMVAL)?] 

P.P.S.  The more common technique now for representing fixnums is to
     notice that on byte-addressed machines (like VAX, MC68000 series,
     INTEL 80386, most Risc-type machines, etc.) the low-order two bits 
     or more of an address are redundant (cons cells requiring at least 4
     and probably 8 bytes of memory).  So the low-order two or three bits 
     can be used arbitrarily as datatype tag information, and a prudent 
     choice of the tag code leads to a very efficient FIXNUM implementation.
     Let fixnums have all "low-order" bits zero; thus data in a format like:
                          sxxx...xx0...0
     (where "s" is a sign bit and the "x"'s are arbitrary bits) will still
     be in that format after a machine "longword" addition or subtraction;
     and multiplication and division require at most a pre- or post- shift
     by a couple bits to retain that format.  Hence basic fixnum operations
     can still be done in about one machine instruction. [I credit Stallman 
     with first noticing the immense utility of this fact, back in 1978 
     when we were brainstorming the design of VAX/NIL].  Despite the vast 
     difference in implementational "tricks", PDP10 MacLisp and VAX/NIL
     share what I condsider to be the fundamental feature: low, constant-
     time value for basic operations costs.

    

∂22-Jul-88  0928	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 22 Jul 88  09:24:11 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa05507; 22 Jul 88 17:08 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Fri, 22 Jul 88 17:04:31 BST
Message-Id: <23641.8807221604@aiai.ed.ac.uk>
To: Masinter.pa@xerox.com, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: more on BOGUS-FIXNUMS
Cc: cl-cleanup@sail.stanford.edu

> Date: Thu, 21 Jul 88 10:35:52 MDT
> From: sandra <(Sandra J Loosemore)sandra%cdr@edu.utah.cs>
> Subject: Re: more on BOGUS-FIXNUMS

> Actually, I don't think we have to worry particularly about supporting
> micros.  According to Stan, it appears that the Lisp with the smallest
> fixnum range is actually Franz Lisp, which uses a separate spaces
> implementation with fixnums in the range [-1024, 1023].

That is not correct.  Fixnums in Franz are 32 bits, or at least they
are on VAX or 68k.  Look at any Franz manual or write some Franz code
that declares fixnums or uses fixed-type arithmetic if you want to
check this.

The [-1024, 1023] is for *small fixnums*.  They are just like normal
fixnums but preallocated.  The "separate space" notion is sometimes
used to check whether an integer is in the range of preallocated ones,
but Franz in general uses bibop (the high order bits of the address
are an index into a type table).

BTW, as I have mentioned before, Franz and KCL are vary similar in
this respect.

-- Jeff

∂22-Jul-88  0957	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88  09:57:07 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA26690; Fri, 22 Jul 88 10:56:43 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA02382; Fri, 22 Jul 88 10:56:41 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807221656.AA02382@cdr.utah.edu>
Date: Fri, 22 Jul 88 10:56:40 MDT
Subject: Re: more on BOGUS-FIXNUMS
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Fri, 22 Jul 88 17:04:31 BST

I think this is probably just a misunderstanding of terminology --
what Stan Shebs described to me as being "fixnums" are clearly not the
same beasties that you call "fixnums".  

I could play devil's advocate here and point out that the confusion
over terminology tends to support my argument for getting rid of the
name "fixnum" from the language entirely; when an implementation has
several different classes of numbers, which one(s) do you call
"fixnum"?  In PSL and its derivatives, for example, the class of
numbers which are called "inums" (represented as immediate data) are
more "fixnum"ish than the class of numbers called "fixnums"!

-Sandra
-------

∂22-Jul-88  1000	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88  10:00:32 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA26819; Fri, 22 Jul 88 11:00:09 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA02396; Fri, 22 Jul 88 11:00:07 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807221700.AA02396@cdr.utah.edu>
Date: Fri, 22 Jul 88 11:00:03 MDT
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 1 Jul 88 19:57 EDT

I don't like this proposal at all and agree with Fahlman that it
should definitely not be the default behavior.  I also believe that
there are also so many other issues unresolved with MAKE-PATHNAME that
make it practically impossible to use portably, that trying to deal with
case is rather pointless.  These other issues include:

    - how long the strings for each of the components can be
    - what characters are valid in each component string
    - whether punctuation (such as the square brackets around the
      directory specifications for VMS, or the dot before the file type)
      must/can be included in the component string
    - whether the implementation/operating system even supports the
      concept for a particular component (e.g., devices on Unix,
      directories on CTSS)

These issues are handled differently even among different Lisps
running under the same operating system.  As a result, I have avoided
using MAKE-PATHNAME like the plague.  Instead, I use MERGE-PATHNAME to
fiddle with pathname objects created by passing namestrings to
PATHNAME.  If I must hard-wire namestrings into my code, it is with
the understanding that they are specific to a particular operating
system.  I assume that PATHNAME does any canonicalization of case
appropriate for that Lisp implementation and operating system.  This
approach has been working quite well for me and I would be content
to leave things as they are, perhaps adding only stronger wording in
the standard about how nonportable MAKE-PATHNAME is.  Or, perhaps
MAKE-PATHNAME should be removed from the language entirely.

-Sandra
-------

∂22-Jul-88  1001	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88  10:01:27 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA26844; Fri, 22 Jul 88 11:00:59 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA02402; Fri, 22 Jul 88 11:00:56 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807221700.AA02402@cdr.utah.edu>
Date: Fri, 22 Jul 88 11:00:55 MDT
Subject: Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 5 Jul 88 14:56 EDT

I've never had any need for this functionality and am not convinced it
is really that important.  However, I don't have any strenuous
objections to the content of the proposal.

-Sandra
-------

∂22-Jul-88  1002	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88  10:02:36 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA26901; Fri, 22 Jul 88 11:02:14 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA02408; Fri, 22 Jul 88 11:02:09 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807221702.AA02408@cdr.utah.edu>
Date: Fri, 22 Jul 88 11:02:08 MDT
Subject: Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 7 Jul 88 11:23 EDT

Of the options presented for this issue, I prefer
PATHNAME-SYNTAX-ERROR-TIME:PATHNAME-CREATION.  The NAMESTRING-COERCION
option seems like it is really the wrong time, and I would rather not
leave it EXPLICITLY-VAGUE.

However, I would really like to see something completely different --
namely adding a keyword argument to TRUENAME to allow it to be used
for explicit syntax checking of filenames without signalling an error
if the file doesn't exist.  Functions such as OPEN and the ones in
sections 23.3, 23.4, and 23.5 that actually pass pathnames to the host
file system would be required to (implictly or explicitly) perform the
same checking. 

This would also solve a problem I brought up some time ago, that I was
having with Lucid Lisp under VMS.  I had defined a logical name like
LISP$LIBRARY that expanded into something that included a directory
specifier in its expansion, like disk$login:[loosemore.lisp.library].
However, I was getting things like

    (namestring (merge-pathnames 
                    (pathname "[loosemore]foo.bar")
	            (pathname "lisp$library:")))

=>  "lisp$library:[loosemore]foo.bar"

which the file system naturally barfed on when I tried to open the
file.  The problem was that Lucid's PATHNAME function was treating the
logical name like a device specification instead of expanding it.
TRUENAME would have expanded the logical name for me, but since
LISP$LIBRARY was not a complete pathname for an existing file, it
would also have signalled an error.

-Sandra
-------

∂22-Jul-88  1005	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88  10:05:11 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA26996; Fri, 22 Jul 88 11:04:49 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA02415; Fri, 22 Jul 88 11:04:47 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807221704.AA02415@cdr.utah.edu>
Date: Fri, 22 Jul 88 11:04:45 MDT
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 7 Jul 88 14:35 EDT

The problem this tries to address hasn't been a big one for me, but I don't
see any harm in adopting this proposal.

Under the "Current Practice" section, you might add that programmers
who need to do this kind of thing now typically make a constant or
global variable that is initialized to hold the right file type for
whatever implementation is being used.  In fact, here is what I've
been using (which I believe was stolen from somebody else):

(defvar *binary-file-type*
    #+Symbolics                         (make-pathname :type "bin")
    #+(and dec common vax (not ultrix)) (make-pathname :type "FAS")
    #+(and dec common vax ultrix)       (make-pathname :type "fas")
    #+pcls                              (make-pathname :type "b")
    #+KCL                               (make-pathname :type "o")
    #+Xerox                             (make-pathname :type "dfasl")
    #+(and Lucid MC68000)               (make-pathname :type "lbin")
    #+(and Lucid VAX VMS)               (make-pathname :type "vbin")
    #+excl                              (make-pathname :type "fasl")
    #+system::cmu                       (make-pathname :type "sfasl")
    #+PRIME                             (make-pathname :type "pbin")
    #+HP                                (make-pathname :type "b")
    #+TI                                (make-pathname :type "xfasl")
    "The default file type for compiled files.")

-Sandra
-------

∂22-Jul-88  1006	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88  10:06:06 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA27004; Fri, 22 Jul 88 11:05:45 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA02421; Fri, 22 Jul 88 11:05:40 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807221705.AA02421@cdr.utah.edu>
Date: Fri, 22 Jul 88 11:05:38 MDT
Subject: Re: Issue: PATHNAME-WILD (Version 1)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 21 Jul 88 13:43 EDT

I've never had any need for this functionality and am not convinced it
is really that important.  However, I don't have any strenuous
objections to the content of the proposal.

-Sandra
-------

∂22-Jul-88  1026	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Jul 88  10:26:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 437286; Fri 22-Jul-88 13:25:37 EDT
Date: Fri, 22 Jul 88 13:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: Sandra J Loosemore <sandra%cdr@cs.utah.edu>
cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8807221704.AA02415@cdr.utah.edu>
Message-ID: <19880722172514.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 22 Jul 88 11:04:45 MDT
    From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)

    Under the "Current Practice" section, you might add that programmers
    who need to do this kind of thing now typically make a constant or
    global variable that is initialized to hold the right file type for
    whatever implementation is being used.  In fact, here is what I've
    been using (which I believe was stolen from somebody else)....

Looks like a good argument for standardization, since I think some
of these are wrong, and it would probably take half a week to test
them all.

    (defvar *binary-file-type*
	#+Symbolics                         (make-pathname :type "bin")
	#+(and dec common vax (not ultrix)) (make-pathname :type "FAS")
	#+(and dec common vax ultrix)       (make-pathname :type "fas")
	#+pcls                              (make-pathname :type "b")
	#+KCL                               (make-pathname :type "o")
	#+Xerox                             (make-pathname :type "dfasl")
	#+(and Lucid MC68000)               (make-pathname :type "lbin")
	#+(and Lucid VAX VMS)               (make-pathname :type "vbin")
	#+excl                              (make-pathname :type "fasl")
	#+system::cmu                       (make-pathname :type "sfasl")
	#+PRIME                             (make-pathname :type "pbin")
	#+HP                                (make-pathname :type "b")
	#+TI                                (make-pathname :type "xfasl")
	"The default file type for compiled files.")

∂22-Jul-88  1133	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 22 Jul 88  11:31:03 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa05507; 22 Jul 88 17:08 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Fri, 22 Jul 88 17:04:31 BST
Message-Id: <23641.8807221604@aiai.ed.ac.uk>
To: Masinter.pa@xerox.com, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: more on BOGUS-FIXNUMS
Cc: cl-cleanup@sail.stanford.edu

> Date: Thu, 21 Jul 88 10:35:52 MDT
> From: sandra <(Sandra J Loosemore)sandra%cdr@edu.utah.cs>
> Subject: Re: more on BOGUS-FIXNUMS

> Actually, I don't think we have to worry particularly about supporting
> micros.  According to Stan, it appears that the Lisp with the smallest
> fixnum range is actually Franz Lisp, which uses a separate spaces
> implementation with fixnums in the range [-1024, 1023].

That is not correct.  Fixnums in Franz are 32 bits, or at least they
are on VAX or 68k.  Look at any Franz manual or write some Franz code
that declares fixnums or uses fixed-type arithmetic if you want to
check this.

The [-1024, 1023] is for *small fixnums*.  They are just like normal
fixnums but preallocated.  The "separate space" notion is sometimes
used to check whether an integer is in the range of preallocated ones,
but Franz in general uses bibop (the high order bits of the address
are an index into a type table).

BTW, as I have mentioned before, Franz and KCL are vary similar in
this respect.

-- Jeff

∂22-Jul-88  1259	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 22 Jul 88  12:59:28 PDT
Received: from PEWEE.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 271610; Fri 22-Jul-88 15:30:22 EDT
Date: Fri, 22 Jul 88 15:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: sandra%cdr@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: <8807221704.AA02415@cdr.utah.edu>
Message-ID: <880722153006.9.KMP@PEWEE.SCRC.Symbolics.COM>

    Date: Fri, 22 Jul 88 13:25 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
	Date: Fri, 22 Jul 88 11:04:45 MDT
	From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
    
	Under the "Current Practice" section, you might add ...
    
	(defvar *binary-file-type* ...)
    
Good point. You're not the only one.

    Looks like a good argument for standardization, since I think some
    of these are wrong, and it would probably take half a week to test
    them all.

Just to clarify, I think Moon meant (he can correct me if I'm wrong)
that this is an argument for canonical types, not an argument for
a *binary-file-type* variable, since the same implementation may have
to talk to multiple file systems, and since different extensions may
be used in different file systems, and hence a single extension may
not be appropriate for every file system.

∂22-Jul-88  1335	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Jul 88  13:34:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 437473; Fri 22-Jul-88 16:33:48 EDT
Date: Fri, 22 Jul 88 16:33 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: sandra%cdr@cs.utah.edu, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880722153006.9.KMP@PEWEE.SCRC.Symbolics.COM>
Message-ID: <19880722203320.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 22 Jul 88 15:30 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Fri, 22 Jul 88 13:25 EDT
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
	    Date: Fri, 22 Jul 88 11:04:45 MDT
	    From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
    
	    Under the "Current Practice" section, you might add ...
    
	    (defvar *binary-file-type* ...)
    
    Good point. You're not the only one.

	Looks like a good argument for standardization, since I think some
	of these are wrong, and it would probably take half a week to test
	them all.

    Just to clarify, I think Moon meant (he can correct me if I'm wrong)
    that this is an argument for canonical types, not an argument for
    a *binary-file-type* variable, since the same implementation may have
    to talk to multiple file systems, and since different extensions may
    be used in different file systems, and hence a single extension may
    not be appropriate for every file system.

Well, what I meant was that some of the file types in Sandra's list are
(I suspect) not the ones that the compiler in those systems actually uses.
I wasn't thinking deeper than that.

Now, getting into details beyond what I meant, there is an argument for
canonical types because a single implementation may use multiple file
systems with different file types, and hence no single string per
implementation can work.  True.  That's the issue within a single
implementation.  There is also the multiple implementation issue: can
all implementations agree on a single canonical type that is used as the
output of the compiler, or should there be a standardized variable whose
value is that canonical type?  One might think that everyone could agree
on a single canonical type for compiler output, but in fact not all
Symbolics implementations use the same canonical type, so even within a
single vendor there is disagreement.  One might think this is stupid,
but in fact Symbolics has multiple types of bin files, all(?; more than
one anyway) of which are understood by some implementations, so it's
unclear how to squeeze that into a single universal canonical type.

I suppose the people who aren't used to thinking about multiple file
systems at the same time are thoroughly confused at this point.  Let me
recap:

In increasing order of abstraction:

KMP's pathname component case proposal abstracts the notion of "this
alphabetic case is the standard one, and this other case is the unusual
one".  Abstracting this instead of just using strings verbatim is useful
because file systems disagree on which case is standard (Symbolics and
Unix use lower case; all major computer vendors (IBM, DEC, CDC, etc.)
use upper case.  [If anyone responds with an argument about who is major
and who is minor, I will jump up and down and scream.  That's not the
point.]).

Canonical types abstract the notion of "such and such pathname-type
field means such and such semantic content in the file".  Abstracting this
instead of just using strings is useful because we might be dealing
with multiple file systems, each of which already has its own convention
for what the string should be.

*binary-file-type* (si:*default-binary-file-type* in Genera) abstracts
the notion of "this canonical type is the one the compiler outputs."
Abstracting this instead of just picking a standard name for this
canonical type is useful because there might be several different semantic
file types that could potentially be the output of the compiler.

Whether anyone cares about these abstractions depends, obviously, on
whether the programs they write deal with these concepts and need to
be portable across file systems and/or across implementations.

∂22-Jul-88  1346	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88  13:46:33 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA03399; Fri, 22 Jul 88 14:45:33 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA02616; Fri, 22 Jul 88 14:45:26 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807222045.AA02616@cdr.utah.edu>
Date: Fri, 22 Jul 88 14:45:25 MDT
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>, sandra%cdr@cs.utah.edu,
        cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 22 Jul 88 16:33 EDT

Sigh, I didn't mean to start a controversy on this.  I just wanted to
point out that people have been able to find other solutions to the
problem this proposal is supposed to address, although the alternatives
are somewhat messier.

-Sandra
-------

∂22-Jul-88  1910	CL-Cleanup-mailer 	Re: more on BOGUS-FIXNUMS 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 22 Jul 88  19:08:37 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa06384; 22 Jul 88 19:23 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Fri, 22 Jul 88 19:19:28 BST
Message-Id: <23965.8807221819@aiai.ed.ac.uk>
To: jeff <@NSS.Cs.Ucl.AC.UK:jeff@aiai.edinburgh.ac.uk>, 
    sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: more on BOGUS-FIXNUMS
Cc: cl-cleanup@sail.stanford.edu

> From: sandra <(Sandra J Loosemore)sandra%cdr@edu.utah.cs>
> Date: Fri, 22 Jul 88 10:56:40 MDT

> I think this is probably just a misunderstanding of terminology --
> what Stan Shebs described to me as being "fixnums" are clearly not the
> same beasties that you call "fixnums".  

Yes, but the advantage of my position is that the beasties I call
"fixnums" are the same beasties Franz, MacLisp, and most CL's call
"fixnums".  (So there.)

> I could play devil's advocate here and point out that the confusion
> over terminology tends to support my argument for getting rid of the
> name "fixnum" from the language entirely;

No, it supports clarification of the terminology, not its elimination.

> when an implementation has several different classes of numbers,
> which one(s) do you call "fixnum"?

The ones that are like "ints" (or maybe "longs"): that is, the ones
that are like machine integers (modulo type tags).  Of course, we
already know an implementation might pick a losing implementation of
fixnums, but there are lots of ways a CL can lose and still be CL.

> In PSL and its derivatives, for example, the class of
> numbers which are called "inums" (represented as immediate data) are
> more "fixnum"ish than the class of numbers called "fixnums"!

Actually (looking at PSL documentation), I suppose either could be
called fixnums if PSL were a Common Lisp; but PSL's "fixnums" are
closer to what I mean by "fixnums", espectially where inums are 19 bit
and fixnums are 36 (DEC-20).

What I want from fixnums is that proper declarations will get me
compiled code not much less efficient than for other languages on
the same machine, and using numbers with similar range.  (I'm willing
to allow type information and for fixnums to be immediate.)

Perhaps we should add somethng to CL for integers are are represented
immediately.  In some implementations, this would be the same set as
fixnums, but would not have to be.

BTW, my "real" address is below.

Cheers,
Jeff

Jeff Dalton,                      JANET: J.Dalton@uk.ac.ed             
AI Applications Institute,        ARPA:  J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University.             UUCP:  ...!ukc!ed.ac.uk!J.Dalton

∂23-Jul-88  0838	CL-Cleanup-mailer 	Re: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Jul 88  08:38:37 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA22032; Sat, 23 Jul 88 09:38:12 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA02390; Fri, 22 Jul 88 10:58:36 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807221658.AA02390@cdr.utah.edu>
Date: Fri, 22 Jul 88 10:58:35 MDT
Subject: Re: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 27 Jun 88 15:37 EDT

This seems like a good idea to me.  We here at Utah ran into the same
problem with our implementation of pathnames for Unix PCLS.

-Sandra
-------

∂24-Jul-88  2306	CL-Cleanup-mailer 	Re: [Masinter.pa: Re: questions]    
Received: from hub (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 24 Jul 88  23:06:41 PDT
Received: from csilvax by hub.ucsb.edu (5.59) id AA25226; Sun, 24 Jul 88 10:03:24 PDT
Received: from  by csilvax.ucsb.CSNET (5.51) id AA16752; Sun, 24 Jul 88 09:57:24 PDT
Date: Sun, 24 Jul 88 09:57:24 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Sun, 24 Jul 88 09:57:24 PDT
To: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Re: [Masinter.pa: Re: questions]
Cc: chapman@hudson.dec.com

This is a response to the first part of the first of Kathy's questions:

My impression is that the return value of close is at most nil, rather than 
the stream.  Actually I've assumed that it returns no values, since none were 
mentioned and none were that useful.  

This impression seems to be shared by at least some other authors.  I've 
checked a few implementations (KCL retuns t) and several textbooks (most don't 
mention it, apparently deliberately, but Wilensky says he's assuming it returns 
nil and Brooks' example indicates that no value is returned).

On the other hand, perhaps the lack of a return value in CLtL is just a printing
error.  (After all, I didn't assume that make-array returns no values!).  Is it
perhaps the case that all of the built-in functions have at least 1 return 
value?

Skona

∂25-Jul-88  0716	CL-Cleanup-mailer 	Re: [Masinter.pa: Re: questions]    
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 25 Jul 88  07:16:46 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 25 Jul 88 10:14:44 EDT
To: Skona Brittain <skona%csilvax@hub.ucsb.edu>
cc: CL-CLEANUP@SAIL.STANFORD.EDU, chapman@hudson.dec.com
Subject: Re: [Masinter.pa: Re: questions] 
In-reply-to: Your message of Sun, 24 Jul 88 09:57:24 -0700.
Date: Mon, 25 Jul 88 10:14:23 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


I think that our working assumption has always been that, if no return
value is mentioned, NIL is returned as a single value unless there's
something obvious that has to come back as in MAKE-ARRAY.  Returning no
values is more expensive than returning NIL and discarding it in many
implementations, since the single-return case usually is special-cased for
maximum speed.

-- Scott

∂26-Jul-88  1656	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME  
Received: from hub (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 26 Jul 88  16:56:39 PDT
Received: from csilvax.ucsb.edu by hub (5.59) id AA08760; Tue, 26 Jul 88 16:56:26 PDT
Received: from  by csilvax.ucsb.CSNET (5.51) id AA00842; Tue, 26 Jul 88 16:50:21 PDT
Date: Tue, 26 Jul 88 16:50:21 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Tue, 26 Jul 88 16:50:21 PDT
To: cl-cleanup@SAIL.Stanford.edu
Subject: ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Cc: SKONA@csilvax.ucsb

Issue:          DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References:     CLtL p.308 & 86-003 p.4
Category:       CLARIFICATION
Edit history:   Revision 1 by Skona Brittain 05/13/88
                Revision 2 by Skona Brittain 07/26/88 (incorp.June discussion)


Problem Description:

The case of two slots of a structure having string-equal names, which
is obviously fraught with ambiguity, is not discussed in CLtL.


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

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


Test Cases:

(I)                        (III)
(defstruct struc           (defstruct struc1 
   slot                       slot)
   slot)                   (defstruct (struc2 (:include struc1)) 
                              slot)

(II)                       (IV)
(in-package 'foo)          (in-package 'foo)
(defstruct struct          (defstruct foo-struct
  slot1                      slot1)
  bar:slot1)               (in-package 'bar)
                           (defstruct (bar-struct (:include foo:foo-struct))
                             slot1)


Rationale:

Since it would be difficult to prescribe (or even imagine) reasonable 
behavior for this situation, it should be considered an error.  


Current Practice:

Sun Common Lisp 2.0.3 detects attempts to define structures with string-equal 
slots at defstruct expansion time, even if the conflicting slot comes from 
inheritance.

Symbolics Common Lisp in Genera 7.2 and Kyoto Common Lisp June 3, 1987 
don't notice the conflict and different kinds of haphazard behavior ensue.
At least in KCL, the details differ between the various test cases above.


Cost to Implementors:

None.


Cost to Users:

None.


Cost of Non-Adoption:

Possible confusion.


Benefits:

Clarity.


Aethetics:

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


Discussion: 

Kent thinks this proposal should be strengthened, either by specifying
a particular odd behavior to ensue or, preferably, by requiring the error 
to be signaled (or perhaps even signalled). 

Skona thinks that is too strong.  This error is on par with many others 
in CL that need not be signaled (such as defining a function with 
string-equal argument names).  The cost of the checking does not seem worth it.

Barry suggests that we facilitate including a structure defined in 
a different package without worrying about string-equal names 
by allowing non-keyword symbols to be used as slot name "keywords" 
(i.e. as keyword arguments to the constructor/accessor functions)
as in the extension to keyword argument syntax that was done for CLOS.  
(If this proposal is thusly modified, we should also add a requirement
to the default printed representation of structures that the slot names 
get printed with their package prefixes.  Maybe something should be said
anyway to standardize whether the slot names or the associated keyword
symbols are printed.)

Larry thinks that that alternative is going in the wrong direction: rather 
than enhance defstructure, we should let it do the simple stuff efficiently 
and have CLOS provide the extra power & flexibility when necessary.





∂26-Jul-88  1657	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-REDEFINITION  
Received: from hub (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 26 Jul 88  16:57:42 PDT
Received: from csilvax.ucsb.edu by hub (5.59) id AA08778; Tue, 26 Jul 88 16:57:41 PDT
Received: from  by csilvax.ucsb.CSNET (5.51) id AA00851; Tue, 26 Jul 88 16:51:37 PDT
Date: Tue, 26 Jul 88 16:51:37 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Tue, 26 Jul 88 16:51:37 PDT
To: cl-cleanup@SAIL.Stanford.edu
Subject: ISSUE: DEFSTRUCT-REDEFINITION
Cc: SKONA@csilvax.ucsb

Issue:          DEFSTRUCT-REDEFINITION
References:     
Category:       CLARIFICATION
Edit history:   Revision 1 by Skona Brittain 07/26/88


Problem Description:

The case of a structure type being redefined is not discussed in CLtL.


Proposal (DEFSTRUCT-REDEFINITION:ERROR-ITSELF):

It is an error to redefine a structure.

Proposal (DEFSTRUCT-REDEFINITION:ERROR-IFF-OLD-USE):

Redefining a structure is ok but it is an error to access, in any way,
an instance of the structure that was created prior to the redefinition.
This applies to instances of other structures that :INCLUDEd the 
redefined structure. 
It is also an error to use any of the redefined structures accessors
on any instances of a structure that :INCLUDEd the previous definition.


Test Cases:

(I)
(defstruct struc1
   slot1 slot2)
(setq s (make-struc1 :slot1 1 :slot2 2))
(defstruct struc1  ; this is an error according to ERROR-BY-ITSELF
   slot2 slot1)    ;          but not according to ERROR-IFF-USE
(struc1-slot1 s)   ; this is an error according to ERROR-IFF-USE

(II)
(defstruct struc1
   slot1 slot2)
(defstruct (struc2 (:include struc1))
  slot 3)
(defstruct struc1
  slot2 slot1)
(setq s (make-struc2 :slot1 1 :slot2 2))
(struc1-slot1 s)   ; this is an error according to ERROR-IFF-USE


Rationale:

The issue of redefinition should be addressed since there are always 
consequences that affect use of the structures: at the very least, 
the constructor function gets overwritten when a structure is redefined.

ERROR-BY-ITSELF is simpler, but ERROR-IFF-USED is more amenable to use.


Current Practice:

None of KCL, Lucid, & Symbolics detect a redefinition, but all of them
return 2 as the value of the last forms in each of the above test case sets.


Cost to Implementors:

ERROR-ITSELF:  none if not signaled. extremely slight if signaled.

ERROR-IFF-OLD-USE:  none if not signaled. much more if signaled.


Cost to Users:

ERROR-ITSELF:  It can be quite inconvenient to be prevented from "correcting"
a structure definition, which would presumably happen if the error were 
signaled.

ERROR-IFF-OLD-USE:  None.


Cost of Non-Adoption:

Confusion.


Benefits:

Clarity.


Aethetics:

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


Discussion: 

Larry supports ERROR-BY-ITSELF, "in that slot-accessors for structures are 
presumed to be declared "inline".  If users want more flexibility than that, 
they should use defclass."

Various inbetween proposals are possible, such as only incompatible 
redefinitions cause errors, but they're too hard to define.

My feeling is that it's a cop-out to just say it's an error to redefine
a structure but then never signal the error - users will still be confused
by the differing seemingly erratic behavior and code. 




∂26-Jul-88  1658	CL-Cleanup-mailer 	ISSUE: VARIABLE-LIST-ASYMMETRY 
Received: from hub (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 26 Jul 88  16:58:36 PDT
Received: from csilvax.ucsb.edu by hub (5.59) id AA08804; Tue, 26 Jul 88 16:58:34 PDT
Received: from  by csilvax.ucsb.CSNET (5.51) id AA00859; Tue, 26 Jul 88 16:52:33 PDT
Date: Tue, 26 Jul 88 16:52:33 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Tue, 26 Jul 88 16:52:33 PDT
To: cl-cleanup@SAIL.Stanford.edu
Subject: ISSUE: VARIABLE-LIST-ASYMMETRY
Cc: skona@csilvax.ucsb

Issue:          VARIABLE-LIST-ASYMMETRY
References:     CLtL pgs. 110, 122, 131
Category:       CHANGE
Edit history:   Revision 1 by Skona Brittain 07/26/88


Problem Description:

The symtax of items in the variable-list for various control structues
(do, let, prog and their duals) varies.  This variation seems unnecessary.

The allowed variations are indicated in the following chart:

do & do*:             (var)    (var init)    (var init step)
prog & prog*:   var   (var)    (var init)       n.a.
let & let*:     var            (var val)        n.a.

Note that just plain    var    is prohibited in do forms
and that the case of   (var)   is prohibited in let forms.


Proposal (VARIABLE-LIST-ASYMMETRY:SYMMETRIZE):

Change the variable-list in the syntax descriptions as follows:
do & do*:   ( { var | (var [init [step]] ) }* )
let & let*: ( { var | (var [value]       ) }* )


Test Cases:

(let (a (b) (c 3)) ... )  would be valid.

(do* (a (b) (c 3)) ... )  would be valid.


Rationale:

The assymetry is unnecessary and impedes learning of CL.


Current Practice:

KCL allows  (var)   in let 
but not      var    in do.


Cost to Implementors:

Very slight.


Cost to Users:

None.


Cost of Non-Adoption:

The variation in syntax makes them harder to learn.


Benefits:

Ease of learning.


Aesthetics:

Symmetry is more aesthetic than assymetry, at least to some of us.


Discussion: 





∂26-Jul-88  1659	CL-Cleanup-mailer 	A lambda question    
Received: from hub (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 26 Jul 88  16:59:17 PDT
Received: from csilvax.ucsb.edu by hub (5.59) id AA08824; Tue, 26 Jul 88 16:59:21 PDT
Received: from  by csilvax.ucsb.CSNET (5.51) id AA00866; Tue, 26 Jul 88 16:53:21 PDT
Date: Tue, 26 Jul 88 16:53:21 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Tue, 26 Jul 88 16:53:21 PDT
To: cl-cleanup@SAIL.Stanford.edu
Subject: A lambda question
Cc: skona@csilvax.ucsb


Now that we've supposedly finished with function-type,
is anybody working on a proposal to introduce a func-
tion that would retrieve the lambda-expression defini-
tion from a user-defined function object?

If not, does anybody want such a proposal?  I recall 
someone (Barry or Richard I think) mentioning it in 
Boston but I don't remember what the reaction was or 
if there even was any.

If there were to be such a function, what would be a 
good name for it?

Skona

∂26-Jul-88  1725	CL-Cleanup-mailer 	Re: A lambda question     
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 26 Jul 88  17:25:40 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 26 Jul 88 20:22:05 EDT
To: Skona Brittain <skona%csilvax@hub.ucsb.edu>
cc: cl-cleanup@SAIL.Stanford.edu, skona@csilvax.ucsb
Subject: Re: A lambda question 
In-reply-to: Your message of Tue, 26 Jul 88 16:53:21 -0700.
Date: Tue, 26 Jul 88 20:20:57 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


    If there were to be such a function, what would be a 
    good name for it?
    
How about EXTRACT-LAMBDA-EXPRESSION ?  I assume that the proposal will
allow this function to return NIL if the original lambda expression has
been compiled or optimized to the point where it can no longer be
retrieved?  I wouldn't want to require memory-tight implementations to keep
around the original form in all cases.

-- Scott

∂28-Jul-88  1201	CL-Cleanup-mailer 	Issue BOGUS-FIXNUMS (Version 2)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Jul 88  12:01:26 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA06896; Thu, 28 Jul 88 13:00:51 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
	id AA05586; Thu, 28 Jul 88 13:00:48 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807281900.AA05586@cdr.utah.edu>
Date: Thu, 28 Jul 88 13:00:46 MDT
Subject: Issue BOGUS-FIXNUMS (Version 2)
To: cl-cleanup@sail.stanford.edu

Issue:		BOGUS-FIXNUMS
References:	CLtL p. 14, 34, 43, 231
Category:	CHANGE, CLARIFICATION
Edit History:   Version 1, 11 Jul 1988, Sandra Loosemore
                Version 2, 27 Jul 1988, Sandra Loosemore (change direction)

Problem Description: 

Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation.  However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."

There are few uses of the fixnum type that are portable, given the
current definition.  In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".

Furthermore, it is conceivable that an implementation could support
only a single internal representation for integers, and some
implementations do support more than two representations with varying
ranges and degrees of "efficiency".  In such a case, arbitrarily
partitioning integers into "fixnums" and "bignums" becomes an
artificial contrivance which is more likely to confuse users than to
ensure portability of code.


Proposal: BOGUS-FIXNUMS:TIGHTEN-DEFINITION

(1) Change the wording at the top of page 14 of CLtL:

  In most Common Lisp implementations, there is a range of integers that
  are represented or operated on more efficiently than others; each such
  integer is called a FIXNUM.  Common Lisp is designed to hide this
  distinction as much as possible; the distinction between fixnums and
  non-fixnums is visible to the user in only a few places where the
  efficiency of representation or operation is important.  Exactly which
  integers are fixnums is implementation-dependent.  However, it is
  required that (SIGNED-BYTE 16) be a subtype of FIXNUM in every
  implementation of Common Lisp.  If an implementation does not provide
  a distinguished representation for small integers in this range, then
  the types INTEGER and FIXNUM are considered equivalent in that
  implementation.  See MOST-POSITIVE-FIXNUM and MOST-NEGATIVE-FIXNUM.

(2) Change the wording at the top of page 34 of CLtL to indicate that
FIXNUM is a subtype of INTEGER (removing the reference to BIGNUM).

(3) Remove BIGNUM from the table of standard type specifier symbols on
page 43 of CLtL.

(4) State that the constants MOST-POSITIVE-FIXNUM and
MOST-NEGATIVE-FIXNUM are allowed to have a value of NIL to indicate
that the implementation does not have a particular FIXNUM
representation distinct from other integers. 

(5) Introduce a new constant, MAX-INTEGER-LENGTH.  This is the maximum
number of bits appearing in any integer; therefore, it is an upper
bound on the INTEGER-LENGTH function.  The value can be NIL if there
are no limits short of memory availability.


Rationale:

Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable, and allows programmers to use the
FIXNUM type specifier in a way similar to how the "int" type is used
in C. 


Current Practice:

Xerox Common Lisp has 17-bit fixnums.  I know of no other Lisp which
claims to be an implementation or subset of Common Lisp that has
fixnums less than 24 bits long.

Several existing Lisps have more than two representations for
integers, including Lisp 1.6 and Portable Standard Lisp.  The only
Lisps that exist now that have a single integer representation appear
to be subsets that do not support infinite-precision arithmetic (for
example, XLisp and A-Lisp).

A number of implementations place constraints on the size of integers
apart from memory availability.  For example, the maximum number of
bits may be constrained to fit in a fixed-length field. 


Cost to implementors:

Slight.  All implementations I know of already define FIXNUMs to be at
least 16 bits and would only have to remove the BIGNUM type specifier
(or document it as an extension to the language) to be in compliance
with the proposal.


Cost to users:

Slight.  The removal of the BIGNUM type specifier will affect user code
but it appears to be little-used.  Code which assumes that the values of
the constants MOST-POSITIVE-FIXNUM and MOST-NEGATIVE-FIXNUM are fixnums
would have to be changed to allow for the fact that they might be NIL.


Benefits:

The FIXNUM type specifier would have a portable interpretation.

Introducing a new constant to describe the maximum size of integers makes
it possible to describe an implementation's exact limitations on the range
of integers it supports.  This constant would also be useful for the
description of subset implementations.


Discussion:

An earlier proposal on this issue to remove the FIXNUM type specifier
entirely was almost universally hated.

Masinter and Fahlman expressed agreement with the general direction of
the current proposal.  Pitman would like to see the range of FIXNUMs
remain undefined and a SMALL-INTEGER type with a fixed range (but no
promises about efficiency) introduced.  JonL would like to see a
guarantee that the value of the constant ARRAY-TOTAL-SIZE-LIMIT be a
fixnum (for efficient array addressing on stock hardware). 

Dalton suggests that the FIXNUM type should be made analagous to the
"int" type in C.  While the original K&R definition of C didn't
guarantee anything about integer sizes, the ANSI C standard requires
ints to be at least 16 bits long.

Addition of the MAX-INTEGER-LENGTH constant was suggested by Stan Shebs.
-------

∂28-Jul-88  1917	CL-Cleanup-mailer 	MULTIPLE-VALUE-SETQ and SYMBOL-MACROLET interaction
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 28 Jul 88  19:17:42 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 28 Jul 88 22:16:20 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 28 Jul 88 22:13:59 EDT
Date: Thu, 28 Jul 88 22:15 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: MULTIPLE-VALUE-SETQ and SYMBOL-MACROLET interaction
To: cl-cleanup@sail.stanford.edu
Message-Id: <19880729021542.8.BARMAR@OCCAM.THINK.COM>

In CLOS, the way to access slots as if they were lexical variables is to
use WITH-SLOTS, which uses SYMBOL-MACROLET to macroexpand occurrences of
the slot names into (SLOT-VALUE <object> '<name>) forms.  It also
converts any SETQ special forms into SETF forms.

But what about MULTIPLE-VALUE-SETQ?  If SETQ is allowed to assign slot
variables then so should MULTIPLE-VALUE-SETQ.  At first I thought this
would require a MULTIPLE-VALUE-SETF, and perhaps that is the right way
to go anyway.  However, it could also be done by expanding the
requirement on SYMBOL-MACROLET: it could transform

(multiple-value-setq (<slot> ...) ...)

into

(progn (multiple-value-setq (#:GENSYM ...) ...)
       (setf (slot-value <object> '<slot>) #:GENSYM))

This works properly in Symbolics Flavors because

(multiple-value-setq (var1 var2) <form>)

macroexpands into

(multiple-value-call #'(lambda (#:g1 #:g2) (setq var1 #:g1 var2 #:g2)) <form>)

which reduces it to a solved problem.  Perhaps the CLOS committee was
assuming that MULTIPLE-VALUE-SETQ includes SETQ's in its expansion, but
this is not actually specified by CLtL.

                                                barmar

∂28-Jul-88  2109	CL-Cleanup-mailer 	Re: Issue BOGUS-FIXNUMS (Version 2) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Jul 88  21:09:35 PDT
Received: from Burger.ms by ArpaGateway.ms ; 28 JUL 88 21:08:41 PDT
From: masinter.pa@Xerox.COM
Date: 28 Jul 88 21:07:35 PDT
Subject: Re: Issue BOGUS-FIXNUMS (Version 2)
In-reply-to: sandra%cdr@cs.utah.edu's message of Thu, 28 Jul 88 13:00:46 MDT,
 <8807281900.AA05586@cdr.utah.edu>
To: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880728-210841-4619@Xerox>

I'm sorry I didn't do this sooner, but I think the issue name should be
FIXNUM-NONPORTABLE instead of BOGUS-FIXNUMS. It is less emotionally loaded, and
follows the convention that issue names start with terms that can be found in
CLtI (Common Lisp the Index.) I'm not sure if "Bogus" is there, but I doubt that
the index entry would lead you to FIXNUMs if it were.

∂28-Jul-88  2200	CL-Cleanup-mailer 	Re: ISSUE: DEFSTRUCT-REDEFINITION   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Jul 88  22:00:31 PDT
Received: from Burger.ms by ArpaGateway.ms ; 28 JUL 88 21:59:13 PDT
From: masinter.pa@Xerox.COM
Date: 28 Jul 88 21:58:08 PDT
Subject: Re: ISSUE: DEFSTRUCT-REDEFINITION
In-reply-to: skona%csilvax@hub.ucsb.edu's message of Tue, 26 Jul 88 16:51:37 PDT
To: Skona Brittain <skona%csilvax@hub.ucsb.edu>
cc: cl-cleanup@SAIL.Stanford.edu
Message-ID: <880728-215913-4668@Xerox>

Portable programs should not dynamically redefine structures.

Programming environments are allowed, encouraged, etc. to allow such
redefinition, perhaps with warning messages. It is beyond the scope of the
language standard to define those interactions, except to note that they are not
portable. 
I don't think it is a cop-out. I certainly don't want an error to be signalled.
I'm lacking a good terminology for describing the "is an error" situation that I
think this should be.

∂29-Jul-88  0803	CL-Cleanup-mailer 	Re: ISSUE: DEFSTRUCT-REDEFINITION   
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 29 Jul 88  08:03:23 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA21344; Fri, 29 Jul 88 11:01:14 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA05303; Fri, 29 Jul 88 11:05:02 EDT
Message-Id: <8807291505.AA05303@mist.UUCP>
To: masinter.pa%Xerox.COM@multimax
Cc: cl-cleanup%SAIL.Stanford.edu@multimax
Subject: Re: ISSUE: DEFSTRUCT-REDEFINITION 
In-Reply-To: Your message of 28 Jul 88 21:58:08 -0700.
Date: Fri, 29 Jul 88 11:04:58 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    Programming environments are allowed, encouraged, etc. to allow such
    redefinition, perhaps with warning messages. It is beyond the scope of
    the language standard to define those interactions, except to note
    that they are not portable.  I don't think it is a cop-out. I
    certainly don't want an error to be signalled.  I'm lacking a good
    terminology for describing the "is an error" situation that I think
    this should be.
    
Why not "is non-portable"?

∂29-Jul-88  1410	CL-Cleanup-mailer 	SYMBOL-MACROLET-SEMANTICS 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 29 Jul 88  14:10:34 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA03546; Fri, 29 Jul 88 14:09:49 PDT
Date: Fri, 29 Jul 88 14:09:49 PDT
Message-Id: <8807292109.AA03546@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: cl-cleanup@sail.stanford.edu
Subject: SYMBOL-MACROLET-SEMANTICS

Status:		For Internal Discussion
Issue:		SYMBOL-MACROLET-SEMANTICS
References:	X3J13 document 88-002R, Chapter 2, pp. 2-81f.
Category:	CHANGE
Edit history:	29-July-88, Version 1 by Piazza

Problem Description:

    The SYMBOL-MACROLET construct introduced with CLOS in X3J13 document
    88-002R, because it is specified as a macro, cannot make use of the
    &environment argument mechanism to communicate with complex macros
    appearing within its body.  As a consequence, the behavior of
    SYMBOL-MACROLET, when used in conjunction with side-effects and complex
    macros, is inconsistent with that of MACROLET, and confusing to users.

Test Case:

    (let ((a (make-array 5))
          (i 0))
      (macrolet ((place () `(aref a (incf i))))
        (push x (place)))
      i)		==> 1

    (let ((a (make-array 5))
          (i 0))
      (symbol-macrolet ((place  (aref a (incf i))))
        (push x place))
      i)		==> 2


Proposal (SYMBOL-MACROLET-SEMANTICS:FLUSH):

    Remove SYMBOL-MACROLET from 88-002R.  Remove WITH-ACCESSORS and
    WITH-SLOTS, or modify them to use ordinary macros.

Rationale:

    For most uses of SYMBOL-MACROLET, ordinary MACROLET can provide equivalent
    expressive/abstraction power.  E.g.,

	(symbol-macrolet ((slot1 (slot-value foo 'slot1)))
          (incf slot1))

    becomes

	(macrolet ((slot1 () (slot-value foo 'slot1)))
	  (incf (slot1)))

Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):

    Change the definition of SYMBOL-MACROLET to specify that it is a special
    form, which affects the evaluation environment for symbols.  Enhance
    MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
    Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
    even symbol subforms.  Specify that the expansion of a symbol macro IS
    subject to further macro expansion, and that ``recursive'' symbol macros
    are an error.  Specify that it is an error to try to SETQ a symbol macro.

Rationale:

    The current specification of SYMBOL-MACROLET as a macro leads to
    undesirable results if forms which produce side-effects are part of the
    expansion of a symbol macro.  

    This potential for interaction between macros is exactly why &environment
    arguments were originally added to macros.  Changing SYMBOL-MACROLET to be
    a special form, which communicates through the &environment arguments to
    macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
    (among others) to work with SYMBOL-MACROLET in the same way they work with
    MACROLET.

    This change cannot (reasonably) support the currently specified semantics
    that the expansion text is "outside" the scope of the symbol macro.  For
    indeed, when the symbol macro is expanded, (a copy of) the expansion is
    then within the scope of the SYMBOL-MACROLET, and should then be subject
    to further scrutiny.  The issue of "infinite expansion" of symbol macros is
    no more dangerous than that of normal macros.

    Finally, the rule that SETQ of a symbol macro must be treated as a SETF of
    the expansion seems to be a kludge which was introduced only to support a
    code-walking version of SYMBOL-MACROLET.  If SYMBOL-MACROLET were changed
    to be a special form, this rule would no longer be needed, and should be
    eliminated in order to make the distinction between symbol macros and
    variables cleaner.

Current Practice:

    Portable Common Loops provides a code-walking implementation of
    SYMBOL-MACROLET as specified in 88-002R.  Symbolics Cloe has both a
    code-walking version of a SYMBOL-MACROLET macro and compiler support for
    a SYMBOL-MACROLET special form.

Cost to Implementors:

    If SYMBOL-MACROLET is removed from the language, no one will bear any cost
    of implementation.

    If it is modified to be a special form, compilers and interpreters will
    have to change, as well as MACROEXPAND, MACROEXPAND-1, and SETF (at
    least).

Cost to Users:

    If SYMBOL-MACROLET is converted to a special form, code-walking programs
    will have to be modified to handle SYMBOL-MACROLET correctly.  Those same
    programs would have to be modified to handle the other special forms
    specified in CLOS, anyway.

    If SYMBOL-MACROLET is removed from the language, users will have to make
    do with MACROLET.  Users will be unable to overload names which already
    have definitions as functions.  E.g.,

	(defclass foo () (car cdr))

	(defun describe-foo (foo)
	  (macrolet ((car () (slot-value foo 'car))
		     (cdr () (slot-value foo 'cdr)))
	    ...
	    Can't use normal car and cdr in here
	    ...))

Cost of Non-Adoption:

    SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
    it interacts with complex macros and forms which produce side-effects.

    Implementations which support ONCE-ONLY will break.  For that matter, any
    mechanism which examines code and assumes that "variables" have no side
    effects will break.

Benefits:

    SYMBOL-MACROLET-SEMANTICS:FLUSH reduces the implementation and maintenance
    costs for a Common Lisp implementation.  It also simplifies the language
    by eliminating the concept of a "symbol macro."

    SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
    surrounding interaction of macros (like SETF) and side effects, and makes
    SYMBOL-MACROLET consistent with MACROLET.

Aesthetics:

    There seem to be mixed feelings as to the desirability of SYMBOL-MACROLET
    as a construct in the language.  Some feel it hairs up the language while
    offering only trivial benefit beyond what is already provided through
    normal macros.  Others herald it as a important new language feature.

    If symbol macros are retained but SYMBOL-MACROLET made to be a special
    form, aesthetics are improved by making symbol macros consistent with
    normal macros.

Discussion:

    As it was adopted by X3J13 as part of CLOS, there has been no formal
    discussion on the pros and cons of SYMBOL-MACROLET on its own.

    In favor of SYMBOL-MACROLET are the following arguments:

    * It allows access to a different namespace for defining macros.  That is,
    it allows macros to be defined in the namespace previously used only by
    variables.  This can avoid name conflicts in certain situations.

    * Certain "embedded languages" may be more easily implemented if
    SYMBOL-MACROLET is available.

    Arguments against SYMBOL-MACROLET include:

    * It makes variable references opaque.  That is, a symbol appearing as a
    form is no longer necessarily a variable.  Programs become correspondingly
    more difficult to read and understand.

    * There are other solutions to the problems of name collisions which
    don't add this complexity to the language.  Specifying prefixes for
    WITH-SLOTS and WITH-ACCESSORS in the manner of DEFSTRUCT, for example,
    would eliminate accidental name conflicts in practice.

    * Symbol macros cannot accept arguments, and therefore cannot be used to
    solve the name conflict problems in situations where macro arguments are
    required.

∂29-Jul-88  2306	CL-Cleanup-mailer 	bignums    
Received: from ucbvax.berkeley.edu by SAIL.Stanford.EDU with TCP; 29 Jul 88  23:06:49 PDT
Received: by ucbvax.berkeley.edu (5.59/1.28)
	id AA15744; Fri, 29 Jul 88 23:03:47 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
	id AA26084; Fri, 29 Jul 88 19:07:48 PDT
Date: Fri, 29 Jul 88 19:07:48 PDT
Message-Id: <8807300207.AA26084@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: bignums

I'm disappointed if implementations without bignums are considered to be in
compliance with the specification of Common Lisp.  The term "bignum" really
does have a meaning: integers whose range is limited only by available memory
and that lie outside of the fixnum range.  If implementations have "bignums"
that are limited to a bit field length, then they don't really have bignums.
The term "bignum" typically implies other pieces of info about the integers
that it labels: bignums cons and arithmetic on them is not as efficient as
that performed on fixnums.

While I applaud the effort to provide truely portable type specifiers, I do
not agree with the sentiment for removing from Common Lisp type specifications
that are not portably defined in so far as the range of values contained in
the type varies from implementation to implementation.  The type of programming
that you do when you use "fixnums" is very different from what you do using
a specific integer range.  Retaining the term "bignum" to denote that type of
integers that I described above, even as varying from implementation to
implementation seems useful to me.  Sometimes, you want to program in a
mostly portable way that takes into account the underlying system for sake
of efficiency.  I see no reason why the type specifiers "fixnum" and even
"bignum" are not useful identifiers for often-used concepts in this sort of
programming.  So, I advocate leaving "fixnum" and "bignum" as type identifiers
in Common Lisp.  I'd also advocate further specifying that "bignums" really
should have range limited only my memory space and that using a fixed bit-field
size is NOT an appropriate implementation of "bignums".

--Joe Ginder

∂31-Jul-88  1340	CL-Cleanup-mailer 	Issue BOGUS-FIXNUMS (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 Jul 88  13:40:37 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 440629; Sun 31-Jul-88 16:39:34 EDT
Date: Sun, 31 Jul 88 16:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue BOGUS-FIXNUMS (Version 2)
To: Sandra J Loosemore <sandra%cdr@cs.utah.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8807281900.AA05586@cdr.utah.edu>
Message-ID: <19880731203905.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

I approve of BOGUS-FIXNUMS:TIGHTEN-DEFINITION for the most part, but
I have a few comments and doubts to offer.

    (3) Remove BIGNUM from the table of standard type specifier symbols on
    page 43 of CLtL.

I don't approve or disapprove of this part; I'm of two minds about it.  It
may be an unnecessary incompatible change.  If anyone opposes it, I will
go along with them.

    (4) State that the constants MOST-POSITIVE-FIXNUM and
    MOST-NEGATIVE-FIXNUM are allowed to have a value of NIL to indicate
    that the implementation does not have a particular FIXNUM
    representation distinct from other integers. 

I don't think that allowing these constants to be NIL enhances portability.
That means a lot of "gratuitous" checking for NIL would be required.  I
think a better idea is to require that these constants always have integer
values, and that if an implementation really cannot identify any efficient
range of integers, it should set these constants to arbitrary values
consistent with the requirement that (SIGNED-BYTE 16) is a subtype of
FIXNUM.  Think about a program that would use these constants to
parameterize an algorithm, as in the example taken from Macsyma that does
modular arithmetic using the largest prime modulus that fits in a FIXNUM.
What does such a program gain by allowing NIL here?

In fact I would think that an implementation with only one representation
for integers could define integers represented in a single bignum-digit to
be its fixnums; those are more efficient than larger integers, just not by
as large a factor as in some other implementations.

    (5) Introduce a new constant, MAX-INTEGER-LENGTH.  This is the maximum
    number of bits appearing in any integer; therefore, it is an upper
    bound on the INTEGER-LENGTH function.  The value can be NIL if there
    are no limits short of memory availability.

Again I don't think allowing this constant to be NIL makes sense.  You
surely aren't saying that if this constant is non-NIL, the implementation
guarantees that there is enough memory to create at least one integer of
the specified length, let alone as many integers of that length as the
program might need.  Thus memory availability is always a limitation, and
implementations that truly have no representation limit on the number of
bits in an integer should set this constant to a value that is guaranteed
to be higher than the memory limit.

Possibly what I just said is an argument that this constant should not exist,
because there is no correct way to use it.  It tells a portable program
nothing about what it can or cannot do.

Or possibly it's an argument that under your definition, any implementation
with a non-NIL MAX-INTEGER-LENGTH would be in violation of the bottom of
CLtL page 13, which says there is no limit on the magnitude of an integer
other than storage.  By that reasoning the Symbolics 3600 would be in
violation, since its address space exceeds its bignum representation limit.
However, the bignum representation limit is large enough that numbers of
that size become impracticably slow [see, memory isn't the limit either,
the real limit can be asymptotic speed of arithmetic algorithms] and I
doubt that Symbolics would care to change their bignum representation
to allow larger bignums which no one could actually use.

    Introducing a new constant to describe the maximum size of integers makes
    it possible to describe an implementation's exact limitations on the range
    of integers it supports.  This constant would also be useful for the
    description of subset implementations.

It's true that it's useful to describe these aspects of an implementation.
I'm not sure that that justifies putting the description into the Common
Lisp language, rather than English.  On the whole, I weakly oppose part 5.

    Rationale:

    Many programmers already use FIXNUM to mean "small integer"; this
    proposal makes this usage portable, and allows programmers to use the
    FIXNUM type specifier in a way similar to how the "int" type is used
    in C. 

I.e. as an unending source of bugs and portability problems.  :-(
Maybe I'm just down on C today.

∂01-Aug-88  0716	CL-Cleanup-mailer 	ISSUE: VARIABLE-LIST-ASYMMETRY (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Aug 88  07:16:35 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 440735; Mon 1-Aug-88 10:16:17 EDT
Date: Mon, 1 Aug 88 10:15 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ISSUE: VARIABLE-LIST-ASYMMETRY (Version 1)
To: skona%csilvax@hub.ucsb.edu
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 26 Jul 88 19:52 EDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Message-ID: <880801101542.3.KMP@PEWEE.SCRC.Symbolics.COM>

I'm happy to see this issue raised. This stupid little inconsistency
has been irritating me and others for a while now.

However, I recommend re-casting the proposal to permit all three forms.
The rationale for that is:

 - Most implementations provide all three versions since Maclisp
   did. In cases where there is a pre-CL tradition, that's usually
   the winner.

 - Regularization is nice, but some may find it gratuitous. To 
   minimize code breakage, the right thing is to only add cases,
   not remove any, if that is feasible. In this case, it is 
   trivially possible. Simply add ``(VAR)'' for DO and DO*
   and ``VAR'' for LET/LET*.

Btw, in Current Practice, Symbolics Genera permits all three forms.

∂01-Aug-88  0742	CL-Cleanup-mailer 	A lambda question    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Aug 88  07:42:41 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 440759; Mon 1-Aug-88 10:41:05 EDT
Date: Mon, 1 Aug 88 10:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: A lambda question 
To: Scott.Fahlman@B.GP.CS.CMU.EDU, skona%csilvax@hub.ucsb.edu
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 26 Jul 88 20:20 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU,
             The message of 26 Jul 88 16:53 PDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Message-ID: <880801104035.4.KMP@PEWEE.SCRC.Symbolics.COM>

    Date: Tue, 26 Jul 88 20:20:57 EDT
    From: Scott.Fahlman@B.GP.CS.CMU.EDU

	If there were to be such a function, what would be a 
	good name for it?
    
    How about EXTRACT-LAMBDA-EXPRESSION ?

The T language provides such a primitive. It is called DISCLOSE
(named for symmetry with the ENCLOSE primitive which occurs in some
Scheme dialects and coerces a lambda expression into a procedure).
DISCLOSE may be overly generic-sounding for CL use, but I recommend
DISCLOSE-DEFINITION.

    I assume that the proposal will allow this function to return NIL if
    the original lambda expression has been compiled or optimized to the
    point where it can no longer be retrieved?  I wouldn't want to require
    memory-tight implementations to keep around the original form in all
    cases.

Since some applications for DISCLOSE have semantic impact, I don't agree
that it should be possible for an implementation to simply throw away
the information. I believe that we should spell out particular cases
in which it is or is not permissible. My personal preferences follow:

 - No compiler should be required to retain the source code
   when using the file compiler. That is, using COMPILE-FILE
   does not make the definition available in the environment into
   which the definitions are subsequently LOADed.

 - I am agnostic about interactive DEFUN, etc. I am content to see
   this information retained only at the discretion of the 
   interpreter.

 - I would prefer that arguments to COMPILE be retained, and possibly
   defuns done by explicit EVAL as well. The reason for this is that
   programs like Macsyma which have need of this function do not just
   go around peeking into arbitrary functions (in my experience). They
   usually want to peek into functions that they themselves instantiated.
   So primitives that allow explicit runtime instantiation of functions
   on a case-by-case basis should be reliably invertible (in my opinion).

Notes:

 - I would be ammenable to permitting this function to be SETF-able,
   so that people could ``NIL out'' definitions they didn't want to
   retain.

 - I would also be ammenable to having a special argument to COMPILE
   saying that the information must be retained. I don't care what
   the default value was.

 - If there is not any reliable situation in which a definition will
   have this information retained, then all the uses I have ever had
   for this except for pretty printing are nullified. Perhaps the
   pretty printing argument is reason enough to have it, though.

 - There is some question about whether in the case of named objects,
   (DEFUN FOO (X) X)
   (DISCLOSE-DEFINITION #'FOO) => (LAMBDA (X) X) or (DEFUN FOO (X) X)?
   I think the latter.
   Does whether FOO is still fdefined matter? I think not.

∂01-Aug-88  1024	CL-Cleanup-mailer 	A lambda question (a.k.a. issue FUNCTION-DEFINITION)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Aug 88  10:24:22 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 440856; Mon 1-Aug-88 13:23:04 EDT
Date: Mon, 1 Aug 88 13:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: A lambda question (a.k.a. issue FUNCTION-DEFINITION)
To: Scott.Fahlman@B.GP.CS.CMU.EDU, skona%csilvax@hub.ucsb.edu
cc: CL-Cleanup@SAIL.Stanford.EDU
References: <880801104035.4.KMP@PEWEE.SCRC.Symbolics.COM>,
            The message of 26 Jul 88 20:20 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU,
            The message of 26 Jul 88 16:53 PDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Message-ID: <880801132228.0.KMP@PEWEE.SCRC.Symbolics.COM>

Actually, you faked me into thinking this wasn't written up.
In fact, I submitted a proposal on this a while back:
  FUNCTION-DEFINITION, Version 1, Pitman, 23-Jun-88
Much of my previous message was a re-hash of what had gone into
that proposal. If you don't have a copy and need one, send me
mail privately and I'll re-transmit it to you.

∂01-Aug-88  1041	CL-Cleanup-mailer 	Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Aug 88  10:41:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 AUG 88 10:26:21 PDT
Date: 1 Aug 88 10:26 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: cutting.pa@Xerox.COM
Message-ID: <880801-102621-1527@Xerox>


Issue:         UNREAD-CHAR-AFTER-PEEK-CHAR

References:    pp 379, 380 of CLtL

Category:      CLARIFICATION

Edit history:  Version 1 by Doug Cutting <Cutting.PA@Xerox.COM> on July 29, 1988

Problem description:

PEEK-CHAR and UNREAD-CHAR are very similar mechanisms.  The description of
PEEK-CHAR in CLtL even states that "it is as if one had called READ-CHAR and
then UNREAD-CHAR in succession."  But while CLtL prohibits calling UNREAD-CHAR
twice in succession it does not prohibit calling UNREAD-CHAR after PEEK-CHAR.
The obvious implementation of PEEK-CHAR and UNREAD-CHAR (a one-character buffer)
will not work unless this prohibition is present.

Proposal (UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW): UNREAD-CHAR may not be called
after PEEK-CHAR without an intervening call to READ-CHAR.

Test Cases/Examples:

;;; Following is an example of code which should not be valid CL.
(defun test (stream)
 (let ((char (read-char stream)))
  (peek-char nil stream)
  (unread-char char stream)
  (assert (eql char (read-char stream)))))

Rationale:

PEEK-CHAR and UNREAD-CHAR provide equivalent functionality and it is thus
reasonable for an implementation to implement them in terms of the same
mechanism.

Current practice:

In Xerox Common Lisp, different (non-random-access) stream types behave
differently. One, (TCP/FTP) handled this correctly, while another (keyboard with
line-buffering turned off) did not.

Cost to Implementors:

Zero.  Implementations which allow this are still correct.

Cost to Users:

Small.  I suspect there is very little code which depends upon this working
correctly, as most code uses either PEEK-CHAR or UNREAD-CHAR, but not both.

Cost of non-adoption:

Implementations of sequential streams are forced to be unnecessarily complex in
order to be correct.

Benefits:

Allows simple yet adequately powerful implementation of sequential streams.

Esthetics:

Requires that users have shared, one-char buffer model of how UNREAD-CHAR and
PEEK-CHAR work, rather than two separate one-char buffers.

Discussion:

∂01-Aug-88  1058	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-SEMANTICS (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Aug 88  10:58:48 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 440873; Mon 1-Aug-88 13:57:53 EDT
Date: Mon, 1 Aug 88 13:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYMBOL-MACROLET-SEMANTICS (Version 1)
To: piazza%lisp.DEC@decwrl.dec.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8807292109.AA03546@decwrl.dec.com>
Message-ID: <880801135717.1.KMP@PEWEE.SCRC.Symbolics.COM>

I assume this is the SYMBOL-MACROLET-UTILITY issue in another guise,
though the edit history does not reflect that. Can we please just pick a
topic name and stick to it? I file these by topic and this kind of
mid-topic name shift (especially without clearly identifying the intent)
leaves me with two files, each containing half of the relevant mail.

Some comments on the writeup itself:

 - I find the tone of the writeup to use a kind of bias that made it
   hard to read. I'd be happier if the tone were more objective.

 - Proposals should not talk about changing existing documents. 88-002R
   is written, fixed, and basically cannot change. What you want to change
   is the part of CL which was changed by its adoption. The convention in
   cleanup proposals is to refer abstractly to changing the language, so
   your proposal doesn't become obsolete as the names of reference documents
   change.

 - The problem description does not adequately describe the problem.
   I suspect this is related to the tone problem, which feels like it's
   emerging out of the heat of a debate to be read by someone involved
   in that debate rather than that it's something intended to be read
   cold by the X3J13 members not following this discussion. The latter
   should be the target audience. It should be possible to read the problem
   description out of context and know something interesting about CL, and
   I don't think you can do that with this writeup.

   We have generally used the Test Case section to describe the
   proposal, not the problem, so the problem description should at
   least explicitly allude to the test case as being critical to the
   problem description. In fact, though, I think you need more expository
   text to make it really obvious what the issue was. The first three times
   I read the problem description, I thought you were just griping about
   the absence of &ENVIRONMENT information going into SYMBOL-MACROLET.

 - I think the stated issue is really orthogonal to the proposed solutions.

   For example, flushing the feature because it has a problem is the trivial
   solution to almost any problem, so it doesn't really show whether your
   solution is going anywhere.
 
   The Special Form solution -- even though I like the idea of it being a
   special form -- is not a solution to the stated problem. It makes this be
   a non-issue for system-supplied things that can inspect the environment
   information, but you don't provide access to that information for user
   programs.

   In my mind, part of the solution must involve the introduction of a
   SYMBOL-MACRO-FUNCTION function, which is like MACRO-FUNCTION but tells
   you if something is a symbol macro. This might be implementable portably,
   though it would certainly be easier if it were a special form.

 - I observe that the change to MACROEXPAND and MACROEXPAND-1 is probably
   desirable, but that this isn't the only way to do it. For example, you
   could have a separate function for expanding symbol-macros, or you could
   funcall SYMBOL-MACRO-FUNCTION of the symbol. Probably changing MACROEXPAND
   will be the most natural way to deal with it, but I wanted to note this
   flexibility for the record.

 - I'm personally happy to see the FLUSH option removed and have this proposal
   elaborated around the special form solution since I don't think it's going
   to fly and I don't personally want to waste time on it. I guess if everyone
   doesn't agree on that, though, it's gotta be retained for now, though.

∂01-Aug-88  1133	CL-Cleanup-mailer 	Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Aug 88  11:33:32 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 440902; Mon 1-Aug-88 14:33:05 EDT
Date: Mon, 1 Aug 88 14:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, Cutting.PA@Xerox.COM
In-Reply-To: <880801-102621-1527@Xerox>
Message-ID: <880801143232.2.KMP@PEWEE.SCRC.Symbolics.COM>

This is a reasonable issue. I think I'll eventually buy into it, but let
me suggest some changes I'd like to see before I do.

 - The proposal part is confusingly worded.

   The wording says that in a stream "abc", if I READ-CHAR to get the #\a
   into variable CH1 and then I PEEK-CHAR to see the "b", then I must call
   READ-CHAR before I can (UNREAD-CHAR CH1). But if I take that literally,
   I'll do (SETQ CH2 (READ-CHAR S)) (UNREAD-CHAR CH1 S) and that's not what
   I want. Having done the READ-CHAR, I can only UNREAD-CHAR the char I just
   did READ-CHAR to get. In effect, I can never UNREAD-CHAR CH1 once I've
   peeked at or read the next char. Some streams will let me back up at this
   point, but only those which would have let me back up before doing the
   READ-CHAR in the first place.

   It would be clearer for the proposal to just say that doing either a
   PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
   on any character preceding that which is seen by the PEEK-CHAR (including
   those passed over by PEEK-CHAR when `seeking' with a non-NIL first
   argument) is not portable.

 - A misreading of the proposal might lead one to believe that one could
   do (SETQ CH1 (READ-CHAR STREAM))
      (SETQ CH2 (PEEK-CHAR NIL STREAM))
      (SETQ CH3 (READ-CHAR STREAM))
      (UNREAD-CHAR CH1 STREAM)
   since the unread-char is correctly separated from the PEEK-CHAR by an
   intervening READ-CHAR. The problem is that the wrong char is being
   unread. Some implementations support this, but it's definitely not
   condoned by the description of UNREAD-CHAR on p379.

 - I found the following test case to be more insightful:

   (defun test (&optional (stream *standard-input*))
     (let* ((char1a (read-char stream))
	    (char2a (peek-char nil stream))
	    (char1b (progn (unread-char char1a stream)
			   (read-char stream)))
	    (char2b (read-char stream)))
       (list char1a char2a char1b char2b)))

  - Current practice (for my test case above) in Symbolics Genera:

     (test)ab
     => (#\a #\b #\a #\b)

     (with-input-from-string (s "abc") (test s))
     => (#\a #\b #\a #\b)

     (progn (with-open-file (s "foo.output" :direction :output)
	      (write-string "abc" s))
            (with-open-file (s "foo.output" :direction :input) 
	      (test s)))
     Signals an error about unreading #\a when #\b was already unread.

∂01-Aug-88  2023	CL-Cleanup-mailer 	ISSUE: VARIABLE-LIST-ASYMMETRY 
Received: from hub (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 1 Aug 88  20:22:54 PDT
Received: from csilvax.ucsb.edu by hub (5.59) id AA14148; Mon, 1 Aug 88 20:22:23 PDT
Received: from  by csilvax.ucsb.CSNET (5.51) id AA14310; Mon, 1 Aug 88 20:15:41 PDT
Date: Mon, 1 Aug 88 20:15:41 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Mon, 1 Aug 88 20:15:41 PDT
To: kmp@stony-brook.scrc.symbolics.com
Subject: ISSUE: VARIABLE-LIST-ASYMMETRY
Cc: cl-cleanup@sail.stanford.edu



I don't see any difference between my proposal and 
the modification to it that you are recommending.

∂02-Aug-88  0717	CL-Cleanup-mailer 	ISSUE: VARIABLE-LIST-ASYMMETRY 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Aug 88  07:17:22 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 441230; Tue 2-Aug-88 10:16:16 EDT
Date: Tue, 2 Aug 88 10:15 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ISSUE: VARIABLE-LIST-ASYMMETRY
To: skona%csilvax@Hub.UCSB.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 1 Aug 88 23:15 EDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Message-ID: <880802101539.3.KMP@PEWEE.SCRC.Symbolics.COM>

    Date: Mon, 1 Aug 88 20:15:41 PDT
    From: Skona Brittain <skona%csilvax@hub.ucsb.edu>

    I don't see any difference between my proposal and the
    modification to it that you are recommending.

I'm not surprised. They're the same. :-}
Sorry. I guess I didn't read carefully enough.

But I'm pretty sure I knew what threw me off, and it might be worth
correcting the style. In the problem description, you enumerate the
cases without the use of [...]. Then later you introduce the brackets,
so I was looking for

  var | (var) | (var val)

when you'd written

 var | (var [val])

etc. You might want to consider one of the following syntactic tricks
to help keep others from falling into the same trap:

 * Use notation such as the following in the problem description:
    do   & do*:            (var [init [step]])
    prog & prog*:    var | (var [init])
    let  & let*:     var | (var val)
   so that it matches the proposal.

 * Use notation such as the following in the proposal:
    do   & do*:      var | (var) | (var init) | (var init step)
    prog & prog*:    var | (var) | (var init)
    let  & let*:     var | (var) | (var init)
   in the proposal so it matches the problem description.
  
 * Say something in the running text of the proposal to make it clear
   what's going on to people like me who don't read carefully enough.
   eg,
       ``Extend the language to permit all of the following syntaxes:''

Also, the category for this change is wrong. It should be listed as an ADDITION,
not a CHANGE since it is not incompatible.

And while you're in there, I'd extend the rationale section to add the
comments I made in my last message. There are, after all, other ways you
could have gone with this proposal (such as the way I thought you were
proposing).  When the rationale section can put concern about such
alternatives to rest, I think it should.

You can add my support of the proposal to the discussion section.

∂04-Aug-88  1522	CL-Cleanup-mailer 	ISSUE: VARIABLE-LIST-ASYMMETRY 
Received: from hub (HUB.UCSB.EDU) by SAIL.Stanford.EDU with TCP; 4 Aug 88  15:22:38 PDT
Received: from csilvax.ucsb.edu by hub (5.59) id AA02242; Thu, 4 Aug 88 15:22:22 PDT
Received: from  by csilvax.ucsb.CSNET (5.51) id AA24449; Thu, 4 Aug 88 15:15:33 PDT
Date: Thu, 4 Aug 88 15:15:33 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Thu, 4 Aug 88 15:15:33 PDT
To: cl-cleanup@sail.stanford.edu
Subject: ISSUE: VARIABLE-LIST-ASYMMETRY

Issue:          VARIABLE-LIST-ASYMMETRY
References:     CLtL pgs. 110, 122, 131
Category:       ADDITION
Edit history:   Revision 1 by Skona Brittain 07/26/88
                Revision 2 by Skona Brittain 08/04/88 (change of category,
                                                       spelling & verbosity)

Problem Description:

The syntax of items in the variable-list for various control structues
(do, let, prog and their duals) varies.  This variation seems unnecessary.

The allowed variations are indicated in the following chart:

do & do*:             (var)    (var init)    (var init step)
prog & prog*:   var   (var)    (var init)       n.a.
let & let*:     var            (var val)        n.a.

Note that just plain `` var '' is prohibited in do forms
and that the case of ``(var)'' is prohibited in let forms.


Proposal (VARIABLE-LIST-ASYMMETRY:SYMMETRIZE):

Allow all the variations in all of the forms;
i.e. add the prohibited cases mentioned above.

I.e. change the variable-list in the syntax descriptions as follows:
do & do*:   ( { var | (var [init [step]] ) }* )
let & let*: ( { var | (var [value]       ) }* )


Test Cases:

(let (a (b) (c 3)) ... )  would be valid.

(do* (a (b) (c 3)) ... )  would be valid.


Rationale:

The asymmetry is unnecessary and impedes learning of CL.

Any other way to make these cases consistent, such as either
omitting just ``var'' from do & do* and prog & prog*, or
omitting ``(var)'' from let & let* and prog & prog*, 
would be an incompatible change to the language.  
This way just adds the flexibility found in some of the forms to all of them.


Current Practice:

KCL allows ``(var)'' in let & let* but not ``var'' in do & do*.

Symbolics Genera allows all three cases in all the forms; i.e. it conforms
to this proposal.


Cost to Implementors:

Extremely slight. (May involve subtracting code rather than adding it).


Cost to Users:

None.


Cost of Non-Adoption:

The variation in syntax makes them harder to learn.


Benefits:

Ease of learning.


Aesthetics:

Symmetry is more aesthetic than asymmetry, at least to some of us.


Discussion: 

Kent supports this proposal.

The issue about whether the atomic ``var'' should be allowed at all in the 
variable lists for let & let* is a separate issue.  (So is whether
it should mean that the var is initially bound to nil.)  Since it is allowed, 
this proposal merely says that the alternative syntax of an atom within a 
list with no initial value, ``(var)'', should also be allowed.

∂04-Aug-88  1740	CL-Cleanup-mailer 	A lambda question    
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 4 Aug 88  17:39:48 PDT
Received: by labrea.stanford.edu; Thu, 4 Aug 88 17:38:30 PDT
Received: from bhopal.lucid.com by edsel id AA08863g; Thu, 4 Aug 88 17:35:17 PDT
Received: by bhopal id AA14409g; Thu, 4 Aug 88 17:37:05 PDT
Date: Thu, 4 Aug 88 17:37:05 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8808050037.AA14409@bhopal.lucid.com>
To: skona%csilvax@hub.ucsb.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Skona Brittain's message of Tue, 26 Jul 88 16:53:21 PDT <8807270025.AA26144@edsel.lucid.com>
Subject: A lambda question

re: Now that we've supposedly finished with function-type,
    is anybody working on a proposal to introduce a func-
    tion that would retrieve the lambda-expression defini-
    tion from a user-defined function object?

Lucid Common Lisp has such a function, called SOURCE-CODE.  It retrieves 
the lambda expression used in an interpretive definition, even after sub-
sequent compilation of the function; but it does not attempt to maintain 
an "out-of-core" database like the emacs TAGS facility.


-- JonL --

∂04-Aug-88  2349	CL-Cleanup-mailer 	bignums    
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 4 Aug 88  23:49:47 PDT
Received: by labrea.stanford.edu; Thu, 4 Aug 88 23:48:34 PDT
Received: from bhopal.lucid.com by edsel id AA10028g; Thu, 4 Aug 88 22:30:50 PDT
Received: by bhopal id AA15094g; Thu, 4 Aug 88 22:32:30 PDT
Date: Thu, 4 Aug 88 22:32:30 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8808050532.AA15094@bhopal.lucid.com>
To: trwrb!smpvax1!jrg@ucbvax.berkeley.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU's message of Fri, 29 Jul 88 19:07:48 PDT <8807300207.AA26084@trwrb.TRW.COM>
Subject: bignums

re:  I'd also advocate further specifying that "bignums" really
    should have range limited only my memory space and that using a fixed 
    bit-field size is NOT an appropriate implementation of "bignums".

Have you considered the possibility that for even moderately small 
"fixed bit-field" sizes, the range of bignums specified is larger 
than any reasonable amount of virtual memory that your operating 
system will allow you to have (and garbage collect)?

Seriously, I have advocated a minimum size for most-positive-fixnum as
about 2↑24-1, which I think is defensible in terms of hardware to do
"efficient" arithmetic.  Do you feel like proposing (and defending) a 
minimum size for most-positive-bignum?

Two interesing stories (really true!):

 (1) During the days that Bill Gosper was computing larger and larger 
     decimal expansions of pi, he happened upon a huge bignum on the 3600 
     that caused it to "die of constipation".  It seems that sufficient
     space had been allocated for it, but at the time of a GC flip, there
     wasn't sufficient space to copy it.  [This was about 1984 I think.]

 (2) A similar thing actually happened to me later, on a 3600.  Suspecting
     that I knew about a "bit-field size", I was intending to compute 
     log2(most-positive-bignum); but unfortunately a typo put in some extra
     shifting steps, so that I actually computed something close to 
     most-positive-bignum.  As in RWG's case, I finally got caught by the 
     GC-flip, and fell into some sort of debugger loop.  I intercepted it 
     a couple days later in a state of catatonia -- apparently it was trying
     to print out the arguments in the frame that had caused the death, and 
     printing most-positive-bignum in base 10 appeared to be taking some time
     . . . 


-- JonL --

∂05-Aug-88  1006	CL-Cleanup-mailer 	issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Aug 88  10:06:35 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA21471; Fri, 5 Aug 88 11:05:48 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA00261; Fri, 5 Aug 88 11:05:43 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8808051705.AA00261@defun.utah.edu>
Date: Fri, 5 Aug 88 11:05:42 MDT
Subject: issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
To: cl-cleanup@sail.stanford.edu

I hope this issue is minor enough to be noncontroversial.

-Sandra


Issue:		DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
References:	CLtL p. 312-314
Category:	CLARIFICATION
Edit History:   V1, 5 Aug 1988, Sandra Loosemore


Problem Description:

CLtL doesn't make clear whether defstructs that :INCLUDE another
structure type and do not specify a :PRINT-FUNCTION inherit the
:PRINT-FUNCTION of the parent structure type.  While it is stated on
page 314 that #S syntax is used if a :PRINT-FUNCTION is not specified,
the language on page 313 indicates that all operations on the parent
type will also work on objects of the child type.  Because of the
ambiguity, existing implementations have gone both ways, and users
cannot depend on either #S syntax or the parent type's :PRINT-FUNCTION
being used.


Proposal: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES

Clarify that defstruct types which :INCLUDE another type but do not
specify an explicit :PRINT-FUNCTION inherit the structure print
function from the :INCLUDE'd type.


Rationale:

Users typically specify a print function for a structure type because
its slots will contain circular objects or large internal data
structures which are confusing when printed.  Any structure type that
:INCLUDEs this type will also contain the same slots; it seems more
reasonable to inherit the parent's print function than to use the
default #S syntax.


Current Practice:

Lucid Common Lisp implements the proposal.  VaxLisp uses #S syntax
unless an explicit :PRINT-FUNCTION is specified.


Cost to implementors:

The changes to non-conforming implementations should be fairly minor
and localized.


Cost to users:

It can't be any worse than the status quo.


Benefits:

An area of ambiguity in the language will be removed.


Discussion:

Perhaps some way of specifying that #S syntax should be used instead of
inheriting the print function of the parent type should be provided for
(such as specifying :PRINT-FUNCTION with no arguments).
-------

∂05-Aug-88  1024	CL-Cleanup-mailer 	Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Aug 88  10:24:41 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 442651; Fri 5-Aug-88 13:23:51 EDT
Date: Fri, 5 Aug 88 13:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 1)
To: sandra%defun@cs.utah.edu
cc: Cl-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8808051705.AA00261@defun.utah.edu>
Message-ID: <880805132330.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Your writeup looks fine.

Non-preemptive comments:

 * Under Rationale, you could mention that some implementations may be
   using something like CLOS' DEFMETHOD to implement print-function,
   and such methods will naturally be inherited. Your proposal is,
   therefore, more consistent with a CLOS-oriented view of the world
   than a non-inheriting proposal would be.

 * Under Current Practice, both Symbolics Genera and Symbolics Cloe
   implement your proposal.

 * I support DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES.

 * Discussion:

    Perhaps some way of specifying that #S syntax should be used instead of
    inheriting the print function of the parent type should be provided for
    (such as specifying :PRINT-FUNCTION with no arguments).

   Or naming the function that does what the #S printer does.
   
   On the other hand, Waters has requested a function which would return
   the #S information as a list (so he can pretty-print structures). The
   same function could be used for this.
   
   If the CLOS metaclass stuff goes in, this is presumably no longer needed.

∂16-Aug-88  1541	CL-Cleanup-mailer 	Issue: NTH-VALUE (Version 1)   
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 16 Aug 88  15:41:38 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA06408; Tue, 16 Aug 88 18:41:35 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA06571; Tue, 16 Aug 88 18:43:14 EDT
Message-Id: <8808162243.AA06571@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: NTH-VALUE (Version 1)
Date: Tue, 16 Aug 88 18:43:11 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

Issue:         NTH-VALUE
References:    Multiple values, pp. 133-139
Category:      ADDITION
Edit history:  Version 1 by Pierson 8/16/88
Status:        For Internal Discussion

Problem description:

The set of actions on multiple values in Common Lisp is incomplete.

Proposal (NTH-VALUE:ADD):

Add a new macro:

NTH-VALUE n form                                               [Macro]

Evaluates the FORM and returns the Nth value returned by the form as a
single value.  N is 0-based, i.e. the first returned value is value 0,
for compatability with NTH and NTHCDR.

Test Cases/Examples:

With this proposal MOD could be defined as:

(DEFUN MOD (NUMBER DIVISOR)
  (NTH-VALUE 1 (FLOOR NUMBER DIVISOR)))

The same code would currently be:

(DEFUN MOD (NUMBER DIVISOR)
  (MULTIPLE-VALUE-BIND (DIVIDEND REMAINDER)
      (FLOOR NUMBER DIVISOR)
    (DECLARE (IGNORE DIVIDEND))
    REMAINDER))

Rationale:

This fills a hole in the initial definition of Common Lisp and permits
clearer code in some circumstances.

Current practice:

I don't know of any implementation that provides this feature.

Cost to Implementors:

A simple new macro needs to be written.  In addition, most
implementations will choose to implement compiler hooks so that code
written with NTH-VALUE will be as efficient as possible.

Cost to Users:

None, this is an upward-compatible change.

Cost of non-Adoption:

This feature won't be available to portable programs.

Benefits:

This makes some code that uses multiple values easier to read and
write.  In addition, it may be easier for implementations to optimize
expressions which use NTH-VALUE instead of using MULTIPLE-VALUE-BIND
and ignoring the unwanted values.

Aesthetics:

While it does add another function to the language it removes some
need for the hairier multiple-value forms.

Discussion:

Pitman proposed this in the very late pre-CLtL days.  It was rejected
then because it was too late in the cycle.


------- End of Forwarded Message

∂16-Aug-88  1627	CL-Cleanup-mailer 	Issue: NTH-VALUE (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Aug 88  16:27:10 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 447350; Tue 16-Aug-88 19:25:26 EDT
Date: Tue, 16 Aug 88 19:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: NTH-VALUE (Version 1)
To: pierson%mist@MULTIMAX.ARPA
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8808162243.AA06571@mist.UUCP>
Message-ID: <880816192510.3.KMP@GRYPHON.SCRC.Symbolics.COM>

If I recall, I was originally talked down on the argument that I
shouldn't be thinking of values as an array-like vector to be
indexed into -- the argument being that this is not how arguments
to functions are treated. They, by contrast, are named.

However, in practice, I find that I often write things like:
 (SIXTH (MULTIPLE-VALUE-LIST ...))
or
 (NTH 5 (MULTIPLE-VALUE-LIST ...))
just for visual clarity and conciseness (in spite of the consing)
-- especially when picking apart hairy return values such as those
involved with the time functions, but also even in simpler cases.

A sufficiently clever compiler -could- just optimize my idiom,
I suppose, but still it would be nice to provide people with 
something that was both efficient and perspicuous.

So, even though some people may have wished they could reform the way I
think about multiple values in some circumstances, the fact remains that
they didn't change my model. They only managed to make me feel 
inconvenienced every time this comes up... So even after all this time,
I still think this is a good idea and generally support the idea of
this proposal.

However, I would like to see the wording tightened to make it clear that
the order of evaluation is left-to-right. "Evaluates N, then evaluates the
form...." or some such.

∂16-Aug-88  1641	CL-Cleanup-mailer 	Re: Issue: NTH-VALUE (Version 1)    
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 16 Aug 88  16:41:03 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 16 Aug 88 19:39:17 EDT
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: NTH-VALUE (Version 1) 
In-reply-to: Your message of Tue, 16 Aug 88 18:43:11 -0400.
             <8808162243.AA06571@mist.UUCP> 
Date: Tue, 16 Aug 88 19:39:05 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


I'm not strongly opposed to this, but I've certainly never felt the need
for such a form.  The cases where want only one value, but not the first
value, are so rare that I don't mind using the more verbose
multiple-value-bind idiom.

-- Scott

∂18-Aug-88  1114	CL-Cleanup-mailer 	(LET ((var)) ...) and (PROG ((var)) ...) 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 18 Aug 88  11:10:46 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 18 Aug 88 12:56:00 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 18 Aug 88 12:55:08 EDT
Date: Thu, 18 Aug 88 12:55 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: (LET ((var)) ...) and (PROG ((var)) ...)
To: cl-cleanup@sail.stanford.edu
Cc: mincy@Think.COM, massar@Think.COM
Message-Id: <19880818165506.0.BARMAR@OCCAM.THINK.COM>

There seems to be an inconsistency in CLtL regarding the syntax of the
variable lists in LET and PROG.  On page 110 the syntax for LET is
given:

	LET ( { var | (var value) }* ) ...

while on p.131 the syntax for PROG is

	PROG ( {var | (var [init]) }* ) ...

This indicates that (PROG ((FOO)) ...) is allowed as a synonym for (PROG
((FOO NIL)) ...) and (PROG (FOO) ...).  However, in the first paragraph
on p.132 it says that the PROG variable list "is processed exactly as
the list in a LET statement...."

Since the syntax descriptions aren't identical, they can't actually be
processed exactly the same.

Symbolics Common Lisp and KCL allow (var) in both LET and PROG.  Sun CL
2.0.3 (on a Sun-3) gets an error for both (LET ((FOO))) and (PROG
((FOO))), and Sun CL 2.1.1 (on a Sun-4) and Lucid CL 2.1 give warnings
for LET but allow PROG silently.

Has this been addressed by any of the cleanup issues in the past?  If
not, what's the right way to solve this?

                                                barmar

∂18-Aug-88  1406	CL-Cleanup-mailer 	Issue VARIABLE-LIST-ASYMMETRY  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Aug 88  14:06:30 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 448244; Thu 18-Aug-88 17:05:29 EDT
Date: Thu, 18 Aug 88 17:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue VARIABLE-LIST-ASYMMETRY
To: Barmar@Think.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, Mincy@Think.COM, Massar@Think.COM
In-Reply-To: <19880818165506.0.BARMAR@OCCAM.THINK.COM>
Message-ID: <880818170518.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

A cleanup item addressing this problem was created since the last meeting.
I think the issue name is VARIABLE-LIST-ASYMMETRY.

The proposal, which no one has objected to, is that PROG, LET, and DO --
which has its own inconsistency -- be upgraded to uniformly allow
   { var | (var [init       ]) }*         ; PROG, PROG*, LET, LET*
or { var | (var [init [step]]) }*         ; DO, DO*

∂18-Aug-88  1631	CL-Cleanup-mailer 	Issue VARIABLE-LIST-ASYMMETRY  
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 18 Aug 88  16:31:22 PDT
Received: by labrea.stanford.edu; Thu, 18 Aug 88 16:29:46 PDT
Received: from blacksox.lucid.com by edsel id AA08499g; Thu, 18 Aug 88 16:22:10 PDT
Received: by blacksox id AA01097g; Thu, 18 Aug 88 16:23:41 pdt
Date: Thu, 18 Aug 88 16:23:41 pdt
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8808182323.AA01097@blacksox.lucid.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: Barmar@think.com, CL-Cleanup@sail.stanford.edu, Mincy@think.com,
        Massar@think.com
In-Reply-To: Kent M Pitman's message of Thu, 18 Aug 88 17:05 EDT <880818170518.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue VARIABLE-LIST-ASYMMETRY

Let's add COMPILER-LET to the first list.

∂21-Aug-88  1521	CL-Cleanup-mailer 	new item: RANGE-OF-COUNT-KEYWORD    
Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 21 Aug 88  15:20:43 PDT
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 21 Aug 88 18:18:08 EDT
To: cl-cleanup@sail.stanford.edu
cc: fahlman@cs.cmu.edu
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: new item: RANGE-OF-COUNT-KEYWORD
Date: Sun, 21 Aug 88 18:18:00 EDT
Message-ID: <6305.588205080@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU

The Problem:
 CLtL is overly vague about legal values for the :COUNT keyword.  It says
that the keyword specifies "how many occurrences of the item should be
affected" (e.g., for REMOVE, it's the maximum number of items to remove).
If the value is NIL, it means "all occurrences".  CLtL doesn't say
explicitly that the value of :COUNT must be an integer, nor does it say
what to do for negative values.

Current Practice:
 CMU Common Lisp and KCL behave differently when given a negative fixnum
for the :COUNT keyword.  CMU Common Lisp treats any value other than a
non-negative fixnum (e.g., values like -2, or 1.0) as if it were NIL.  KCL
treats negative fixnums as equivalent to zero for lists, but does something
bizarre for vectors (it pads them with n blanks or NILs, where -n is the
value of the :count keyword keyword.)

Proposal RANGE-OF-COUNT-KEYWORD:RESTRICT-TO-INTEGERS
  Add language to CLtL specifying that the only legal values for :COUNT
are integers and NIL.

Rationale:
 Restricting :COUNT to integers most likely reflects CLtL's original
intent.  Similar functions that accept numeric args, like NTH, explicitly
limit them to integers (CLtL, p. 265).  The proposal simply makes this
explicit for the :COUNT keyword.

Proposal RANGE-OF-COUNT-KEYWORD:TREAT-NEGATIVE-LIKE-ZERO
  Require functions that accept a :COUNT keyword to treat negative values
as equivalent to zero.

Rationale:
 The proposed treatment of negative values is consistent with the current
wording of CLtL, which says (p. 253, for REMOVE) "if more than :count
elements satisfy the test, then of these elements only the leftmost are
removed, as many as specified by :count."  Of course, you can't remove -3
items from a sequence, but for that matter you can't remove 3 items from a
sequence of length 2, either.  It is implicitly understood that "as many
as" really means "no more than" as far as :COUNT is concerned.

 The proposal also has the advantage of freeing the user from having to do
an explicit check for negative numbers when the value of :COUNT is computed
by some complex expression.  Example:

  (defun leave-at-most (n item sequence &key (from-end t))
    (remove item sequence 
      :count (- (count item sequence) n)
      :from-end from-end))

  (leave-at-most 2 #\a "bananas")  ==>  "banans"

  (leave-at-most 2 #\s "bananas")  ==>  "bananas"


Alternatives:
 Fahlman suggests declaring "it is an error" for the value of :COUNT to be
negative.  This has the advantage of making all current implementations'
behavior legal, no matter how bizarre.  The disadvantages are that this
will be counterintuitive for beginners; it is less in keeping with the
spirit of the present wording of CLtL; and it will make functions such as
LEAVE-AT-MOST a little more complex, by requiring the user to throw a (MAX
0 ...) expression around the value of :COUNT.

Other things to consider:
 In the past there has been some argument about what SUBSEQ should do when
given positions greater than the length of the sequence.  Currently it "is
an error" to specify positions less than zero or greater than the length of
the sequence.  I don't think the same should apply to the :COUNT keyword.
The inputs to SUBSEQ are ordinal numbers: they specify positions, like
array subscripts.  The value of :COUNT is not an ordinal, it is an upper
bound on the size of the set of affected items (which is a cardinal
number).

Cost of the change:  nonzero, but clearly trivial.  Given the current
wording of CLtL, no code can legally depend on the behavior of sequence
functions given negative values for :COUNT.  In practice it's unlikely
that many programs presently depend on one behavior or the other; if they
do then they're already non-portable.

∂22-Aug-88  0841	CL-Cleanup-mailer 	Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Aug 88  08:41:10 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 449450; Mon 22-Aug-88 11:40:06 EDT
Date: Mon, 22 Aug 88 11:39 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
To: Dave.Touretzky@CS.CMU.EDU
cc: Scott.Fahlman@B.GP.CS.CMU.EDU, CL-Cleanup@SAIL.Stanford.EDU,
    KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: Your message
References: <5787.588152756@DST.BOLTZ.CS.CMU.EDU>,
            The message of 21 Aug 88 15:36 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU
Message-ID: <880822113935.2.KMP@GRYPHON.SCRC.Symbolics.COM>

Your proposal had a few oddities...
 - The proposal named RESTRICT-TO-INTEGERS permitted NIL.
 - The two proposals were orthogonal, and I wanted to vote for both.
   If it were to be broken into two proposals, they should be
   Fahlman's proposal (negatives are an error) and the merger of the
   two you proposed.
 - The proposal was not in the standard format.
For these reasons, I rewrote your proposal into a format I could vote on.
Hope you don't mind.
----------
Issue:        RANGE-OF-COUNT-KEYWORD
References:   :COUNT (p247), REMOVE[-xxx] (p253), DELETE[-xxx] (p254),
	      [N]SUBSTITUTE[-xxx] (pp255-256)
Category:     CLARIFICATION
Edit history: 21-Aug-88, Version 1 by Dave Touretzky
	      22-Aug-88, Version 2 by Pitman
Status:	      For Internal Discussion

Problem Description:

 CLtL is overly vague about legal values for the :COUNT keyword
 parameters to builtin functions such as the sequence functions. It
 says that the keyword ``limits the number of elements [affected]''.
 Implementations have varied in their interpretation of this phrase,
 however.

 CLtL p247 specifies that if the :COUNT parameter to functions such
 as REMOVE and DELETE ``is NIL or is not supplied, all matching items
 are affected.'' Because of the placement of this requirement
 outside of the description of the functions affected, some
 implementations have overlooked this requirement and had to be 
 changed later.
 
 CLtL doesn't say explicitly that the value of :COUNT must be an
 integer, nor does it say what to do for negative values.

 The fact that reasonable implementations disagree on some of the
 details make this an obvious candidate for cleanup.

Proposal (RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER):

 Clarify that for the functions

   REMOVE	REMOVE-IF	REMOVE-IF-NOT
   DELETE	DELETE-IF	DELETE-IF-NOT
   SUBSTITUTE	SUBSTITUTE-IF	SUBSTITUTE-IF-NOT
   NSUBSTITUTE	NSUBSTITUTE-IF	NSUBSTITUTE-IF-NOT

 the following restrictions on the :COUNT keyword parameter exist:

   * The value of this parameter must be NIL or an integer.

   * Using a negative integer value is functionally equivalent to
     using a value of zero.

Test Case:

  #1: (REMOVE 'A '(A B A B) :COUNT  0)   => (A B A B)
  #2: (REMOVE 'A '(A B A B) :COUNT -3)   => (A B A B)
  #3: (REMOVE 'A '(A B A B) :COUNT NIL)  => (B B)
  #4: (REMOVE 'A '(A B A B) :COUNT  1.0) is an error.
  #5: (REMOVE 'A '(A B A B) :COUNT 'FOO) is an error.

Rationale:

 Disallowing non-integer numbers is probably the original intent and
 is consistent with other functions such as NTH (p265) which accept
 count-like arguments that are explicitly required to integers. This
 restriction would presumably permit better optimizations in low-safety
 mode on stock hardware.

 Allowing NIL to be equivalent to no value allows a simplified flow
 of control in some situations. For example, one can write
  (DEFUN MYDEL (ITEM &OPTIONAL COUNT)
    (DELETE ITEM *MYLIST* :COUNT COUNT))
 where otherwise it might be necessary to write something like
  (DEFUN MYDEL (ITEM &OPTIONAL (COUNT NIL COUNT-P))
    (IF COUNT-P
        (DELETE ITEM *MYLIST* :COUNT COUNT)
        (DELETE ITEM *MYLIST*)))

 Allowing negative numbers frees users from having to do an explicit
 check for negative numbers when the value of :COUNT is computed by
 some complicated expression. For example:
  (DEFUN LEAVE-AT-MOST (N ITEM SEQUENCE &KEY (FROM-END T))
    (REMOVE ITEM SEQUENCE 
      :COUNT (PRINT (- (COUNT ITEM SEQUENCE) N))
      :FROM-END FROM-END))
  (LEAVE-AT-MOST 2 #\A "BANANAS")  ==>  "BANANS"
  (LEAVE-AT-MOST 2 #\S "BANANAS")  ==>  "BANANAS"

Current Practice:

 [Note: Pitman didn't try these examples in KCL or CMU Common Lisp. He's
  working from data in Touretzky's last draft of this proposal, so someone
  from those camps might want to test the assertions made here.]

 #1: All correct implementations presumably return (A B A B).
     This value is consisent with this proposal.

 #2: Symbolics Cloe returns (A B A B).
     KCL returns (A B A B) for lists.
     This value is forced by this proposal.

     Symbolics Genera and CMU Common Lisp return (B B).
     KCL does something bizarre for vectors (``pads with n blanks or
      NILs, where -n is the value of the :count keyword parameter'',
      says Touretzky.)
     These implementations would have to change.

 #3: All correct implementations presumably return (B B).
     This value is consisent with this proposal.

     Some implementations have been known to signal a wrong type
     argument error in the past, but have presumably been fixed.

 #4: Symbolics Genera and Symbolics Cloe return (B A B).
     CMU Common Lisp returns (B B).
     These behaviors are consistent with this proposal.
  
 #5: Symbolics Cloe and Symbolics Genera signal an error.
     CMU Common Lisp returns (A B A B).
     These behaviors are consistent with this proposal.


Cost to Implementors:

  Some implementations would have to change. These functions are typically
  heavily optimized by compilers. Not only source code, but also compiler
  optimizers and perhaps even microcode or hardware might have to be
  modified to fully accomodate this change, so it might be quite expensive.

Cost to Users:

  None for Common Lisp users. This change is an upward compatible
  clarification of standard practice.

Cost of Non-Adoption:

  The behavior of these functions when given degenerate keyword values would
  be unintuitive. In many such cases, considerable additional user code must
  be written to watch for and avoid creating such situations.

Benefits:

  More compact, more intuitive, and more portable code.

Aesthetics:

  This change improves language aesthetics.

Discussion:

  Fahlman suggests declaring "it is an error" for the value of :COUNT to be
  negative.  This has the advantage of making all current implementations'
  behavior legal, no matter how bizarre.  The disadvantages are that this
  will be counterintuitive for beginners; it is less in keeping with the
  spirit of the present wording of CLtL; and it will make functions such as
  LEAVE-AT-MOST a little more complex, by requiring the user to throw a 
  (MAX 0 ...) expression around the value of :COUNT.
 
  In the past there has been some argument about what SUBSEQ should do when
  given positions greater than the length of the sequence.  Currently it 
  "is an error" to specify positions less than zero or greater than the
  length of the sequence.  Touretzky doesn't think the same should apply to
  the :COUNT keyword. The inputs to SUBSEQ are ordinal numbers: they specify
  positions, like array subscripts.  The value of :COUNT is not an ordinal,
  it is an upper bound on the size of the set of affected items (which is
  a cardinal number).
 
  Pitman supports this proposal. [Hopefully Touretzky supports it, too?]

∂22-Aug-88  0948	CL-Cleanup-mailer 	Re: Issue: RANGE-OF-COUNT-KEYWORD (Version 2) 
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 22 Aug 88  09:48:00 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 22 Aug 88 12:45:46 EDT
To: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: RANGE-OF-COUNT-KEYWORD (Version 2) 
In-reply-to: Your message of Mon, 22 Aug 88 11:39:00 -0400.
             <880822113935.2.KMP@GRYPHON.SCRC.Symbolics.COM> 
Date: Mon, 22 Aug 88 12:45:40 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


I support this proposal (NIL-OR-INTEGER), as restated by KMP.  I think it
is slightly better than "is an error", though perhaps not if the change
really would cause enormous work for some implementation that has this
microcoded.

Re the first sentence in the discussion section: What Fahlman suggested was
that, in the absence of any clarification by the cleanup committee, users
should assume that "is an error" to give a negative :COUNT value.  But if
we're going to go to the trouble of addressing this issue, we may as well
specify what should happen, and this proposal seems as good as any.

-- Scott

∂22-Aug-88  2241	CL-Cleanup-mailer 	Issue "Eliminate forced consing" re-visited   
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 22 Aug 88  22:40:51 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.30)
	id AA18157; Mon, 22 Aug 88 22:36:40 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
	id AA15416; Mon, 22 Aug 88 21:39:05 PDT
Date: Mon, 22 Aug 88 21:39:05 PDT
Message-Id: <8808230439.AA15416@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: Issue "Eliminate forced consing" re-visited

Wow, what a yawn.  (In response to my original proposal.)  After waiting a
month for comments, flames, whatever, I decided to re-send an edited version
of my original proposal in an attempt to generate some discussion.  Is anyone
else trying to compete with C programs for efficiency?  Here it is:
=======================
Issue:         ELIMINATE FORCED CONSING

References:    CLtL section 14.1,3,5; 15.2,5; 17.4; 18.3; 21.2

Category:      ADDITION

Edit history:  Version 1, 20-Jul-88, Ginder
               Version 2, 22-Aug-88, Ginder
                   Moved discussion to the discussion section.
                   Changed multiple value proposal, clarified
                   certain points.

Problem description:

Some sequence, list, and string functions in CLtL encourage a
programming style that uses excessive storage allocation compared to
libraries of routines with similar functionality in other languages,
notably C.  The only options available to the Common Lisp programmer who
uses these functions are to generate a newly-allocated sequence or to
destructively modify the argument sequence(s) given the function.  The
option of providing a sequence, list, or string into which the result of
a sequence operation should be placed is not available.

Proposal:

Add a :TARGET keyword argument to those sequence, list, and string
functions where such an argument is useful, as specified below, which
allows passing a target argument sequence into which the result of the
sequence computation is to be placed.  The sequence function returns the
target sequence modified as specified below:

(1) The target sequence must accomodate elements of the type(s) in the
source sequence.  Thus it would be an error to give a target string
argument if the source sequence had elements that were not of type
STRING-CHAR.

(2a) A non-list target sequence should have an allocated length long
enough to accomodate the normal result of the sequence function.  It is
permissable for the target sequence to have a fill pointer; in this
case, the fill pointer is set to point immediately after the last
element filled in by the sequence computation.  If the target sequence
is longer than necessary, the unneeded trailing elements are unchanged.

(2b) A list target sequence argument is extended with new conses to be
as long as necessary to accomodate the resulting sequence, if not enough
conses are supplied and the :TARGET-FROM-END keyword is nil.  The last
cons of the target list whose CAR was filled by the computation is
returned as a second value.  The CDR of this cons is that tail of the
target list not used to accomodate the sequence computation.  (I.e., The
unused conses remain as a tail of the target list that is returned.)
This permits the programmer to save the unused conses and then
null-terminate the head of the list used for the result.

(3) A :TARGET-FROM-END keyword is supported.  If non-nil, the target
sequence is filled with new elements starting at the end of the target
seqeunce, effectively reversing the order of elements of the resulting
sequence in the target.  In this case, an error is signalled if the
target sequence is not long enough for the result.  If the target
sequence is longer than necessary, leading elements are unchanged.

(4) :TARGET-START and :TARGET-END keywords are supported.  TARGET-START
and TARGET-END determine where in the target sequence the result of the
sequence computation is placed.  An error is signalled if the sub-length
of the target sequence specified by these arguments is not long enough
to accomodate the resulting sequence computation.  If a longer than
necessary sub-length is specified, then the elements in the unneeded
part of the specified sub-length are unchanged.

Changed sequence functions:
	subseq, copy-seq, reverse, remove, remove-if, remove-if-not,
	remove-duplicates, substitute, substitute-if, substitute-if-not,
	merge

Changed list functions:
	copy-list, butlast

	copy-alist, copy-tree, adjoin, union, intersection, set-difference,
	set-exclusive-or
 	  [no TARGET-START/END or TARGET-FROM-END, just destructive
	   use of the :TARGET conses]

Changed string functions:
	string-trim, string-left-trim, string-right-trim, string-upcase,
	string-downcase, string-capitalize 

Examples:

(copy-seq '(1 2 3) :target '(a b c d e f g))
	=> (1 2 3 d e f g)

(copy-seq '(1 2 3) :target '(a b c d e f g) :target-from-end t :end 5)
	=> (a b 3 2 1 f g)

(remove 'a '(b b a b b a b b a b b) :count 1 :target '(3))
	=> (b b b b a b b a b b)   ; EQ to :TARGET arg, CDR is new conses.

;;; Note, the :TARGET arg has a fill pointer.
(substitute #\a #\b "This is a string with 2 a's"
	    :target "0123456789012345678901234567890123456")
	=> "This is b string with 2 b's"

In a related addition, included here since it addresses the same problem
as the one above, provide extended versions of concatenate, append,
revappend, and make-string-output-stream as follows:

	concatenate-into target &rest sequences
	  Like CONCATENATE, but the result type is determined to be
	  the type of TARGET.  The result is TARGET containing as many
	  of the elements of SEQUENCES as can be accomodated by the
	  allocated length of TARGET.  TARGET's fill pointer, if
	  present is set according to how many elements of TARGET ar
	  filled by this operation.

	concatenate-into-subseq target start end &rest sequences
	  Like concatenate-into, but copied from SEQUENCES into	the
	  sub-sequence of TARGET specified by START and END.

	append-into target &rest lists
	  Like APPEND, but the copied list arguments are copied into
	  conses taken from TARGET.  The last list in LISTS
	  is not copied, as in APPEND, rather, the last cons used
	  from TARGET is given the last list in LISTS as its cdr.
	  The result is EQ to TARGET (unless a single list is appended),
	  but contains only those conses needed to hold the appended
	  lists' elements.  The tail of unused conses from TARGET is
	  returned as a second value; new conses are allocated if
	  TARGET supplies an insufficient number of conses.

	revappend-into target x y
	  Like REVAPPEND, but the new conses are taken from TARGET.
	  The result is EQ to TARGET, but contains only those conses
	  needed to hold X's elements.  The tail of unused conses
	  from TARGET is returned as a second value; new conses are
	  allocated if TARGET supplies an insufficient number of conses.

	make-string-output-stream &optional string
	  Like the current MAKE-STRING-OUTPUT-STREAM, except if STRING
	  is provided, make the string-stream write to it rather than
	  a newly-allocated string.  An error is signalled if the output
	  overflows the supplied string.

Rationale:

It is sometimes better to use a more complex programming construct for
sake of efficiency than to use a less complex, more expensive one.
Providing a set of sequence, list, and string functions that do not
require dynamic storage allocation provides a means for writing programs
that must avoid storage allocation while running as much as possible.
Excessive storage allocation (sometimes expressed as "Lisp garbage
collects too often") is one of Lisp's most widely publicized and least
understood faults.

Current practice:

Similar functionality is provided for bit-vectors, as specified in CLtL
17.4.  A related capability is provided in the destructive versions of
some of the functions extended above (e.g., REMOVE vs. DELETE).

When functionality similar to this is required, users must "roll their
own".

Cost to Implementors:

The cost of implementation of these extra sequence, list, and string
function arguments is significant, in that existing code to implement
these functions must be changed to use storage passed in as an argument
by the user.

Cost to Users:

No cost, this change upwards compatible.

Cost of non-adoption:

Some programmers will continue to "roll their own" storage re-using
code.  Others will not go to this effort, but will write programs that
require much garbage collection.  Lisp will continue to suffer from a
handicap in promoting efficient programs when compared to C.

Benefits:

Those programmers choosing to invest the extra effort needed to
correctly use such facilities can do so with less overhead than
previously required, and will see performance improvement.  Programmers
learning Common Lisp will be challenged to understand the difference
between allocating new storage and re-using old storage as they
understand why these arguments are supported.

Esthetics:

Neutral.  This proposal is syntactically consistent with the existing
keyword arguments to sequence, list, and string functions.  However, it
adds to the plethora of keyword arguments already present for many of
these functions.  Stylistically, it provides stronger support for the
programming style embodied by the use of the "destructive" versions of
many Common Lisp functions.

Discussion:

My experience in several commercial Lisp applications is that avoiding
storage allocation by using programming techniques such as this may be
critical to the success of a project.  The current sequence, list, and
string functions encourage an "expensive", albeit easy to use,
programming style that invites the creation of programs whose
performance suffers greatly in comparison to a C program written to
solve the same problem.  This applies particularly to string-hcaking
programs written using Common Lisp versus those written using the
standard string library for C.

I submit that the cost of NOT implementing this sort of functionality is
that Common Lisp, in many cases, deserves the reputation it is gaining
of being expensive to use, not in programmer productivity, but in the
resources required by the resulting programs.  While it is easier to
write programs that always allocate new storage for results, it is very
expensive compared to what average programmers write in other languages.
(Asside: I realize that this dredges up the functional programming
versus side-effect programming debate.  Common Lisp already supports
"destructive" versions of many functions.  Lisp compiler technology has
not progressed to the point of eliminating unnecessary storage
allocation in programs written in a purely functional style.)  Sometimes
the correct trade-off is to invest extra programming effort in
development of a program in exchange for lowered resource requirements
in the delivered system.  This is particularly true when the deployed
Lisp application may have thousands of instances.  It may well be worth
several extra man-years of effort to use facilities such as those
mentioned above rather than pay the increased cost of deployment
thousands of times!  (These costs are in the form of more expensive
hardware for deployment.  This might be due to higher memory
requirements or larger disk space requirements to support a large
virtual memory image and swap space.) If Common Lisp does not provide
this capability; programmers under serious performance constraints will
choose a different language, such as C.

Many programmers encounter problems writing efficient programs in Lisp.
I've encountered numerous occurances of this problem in helping people
who are trying to write Lisp programs as part of an application that is
intended to be delivered on hardware for which someone must pay real
money.  The superficial problem encountered is that the program is too
slow, or requires hardware too expensive for practical deployment.  The
most common result is that the programmer gives up, proclaiming that
Lisp is too slow or too resource intensive, and rewrites his program in
C.  Although the above enhancements alone are not sufficient to solve
the cited problem, something along these lines is necessary as part of a
more complete solution that might include better training of Lisp
programmers, standard support for stack consing, and ephemeral GC.  The
real benefit of adopting this extension to Common Lisp (and related
extensions) is an increased chance of survival for Lisp as a viable tool
for creating deliverable applications.

A related sort of optimization that compilers should be encouraged to
support is to recognize:

   (concatenate 'string (subseq ...) (subseq ...) (subseq ...) ...)

as being optimizable so as to avoid the allocation of storage for
intermediate SUBSEQ results.  This is a very common programming idiom
that can, of course, be expressed using the proposed extensions to avoid
intermediate consing.  However, the extensions do not provide as concise
and readable a mechanism for re-espressing this idiom as may others.
Other extensions could be considered to address this:

	(1) Provide a CONCATENATE function that takes a &rest
	argument of sequence/start/end triples.

	(2) Provide a special form like:
	       (designate-subseq sequence start end)
	that didn't actually allocate anything but provided an imple-
	mentation-specific "handle" on the subsequence for use
	in such expressions as the CONCATENATE expression above.
	(They'd print as the subseq, and setf's of their elements
	would destructively modify the original sequence.)	

However, there is no precedent in CLtL for (1).  And (2) seems like a
complex, sweeping change (for implementors) of limited benefit.  Also,
it is somewhat in conflict (though more general than) displaced arrays.
Neither are proposed.

I'd likely tolerate any sort of statements in the new CL manual warning
naive users of the dangers of this programming style.  I agree that it
can be mis-used and lead to nasty bugs; but sometimes the benefit is
worth the risk.  I simply want Common Lisp to provide the choice.

A related issue: would adoption of these arguments eliminate the need
for parallel destructive versions for some of the affected functions?
(E.g., does REMOVE with a :TARGET argument eliminate the need for
DELETE.)

An alternative to :TARGET for the keyword name is :DESTROY.

=======================

∂23-Aug-88  0740	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 23 Aug 88  07:39:58 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 23 Aug 88 10:38:02 EDT
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue "Eliminate forced consing" re-visited 
In-reply-to: Your message of Mon, 22 Aug 88 21:39:05 -0700.
             <8808230439.AA15416@trwrb.TRW.COM> 
Date: Tue, 23 Aug 88 10:37:55 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


Let me repeat and amplify the response I made to this proposal when it
first came out.

The destructive versions of the various sequence functions are rather
dangerous to use, and are the source of confusing and hard-to-find bugs in
code written by people who don't appreciate these dangers.  On the other
hand, we are trying to produce and industrial-strength language here, and
we must provide users with SOME way to do non-consing operations on
sequences.  The presence of DELETE in the language shows that were are
willing to accept the added complexity and danger when the only other
choice is inefficiency.  The question is not whether the language should
allow efficient, non-consing sequence operations, but how we can best
package them to reduce the danger.

At present, the principal alternative to using CONS-intensive sequence
functions is to write your own loops in an iterative style.  Unfortunately,
we have poor tools for iterative programming.  I was not at the recent
meeting, but I believe that the iteration committee is now functioning and
plans to propose a version of the LOOP macro as an addition to the
standard.  If this comes to pass, I believe that the sequence functions
will end up being used only for the simplest kinds of loops -- a
kind of shorthand that makes the programmer's intention clear in the most
common cases -- and that the more complex options in the sequence functions
will tend to atrophy from disuse.  If that is right, then it makes little
sense to add another layer of complexity to these things, just at the time
when we are providing a decent alternative in the LOOP facility.

I find that even without the LOOP facility, I tend to use the sequence
functions only in simple ways, and move over to a DO loop if the situation
becomes at all complex.  The positive side of this is that I make fewer
mistakes in coding, because I'm telling the program exactly what I want it
to do rather than guessing what the sequence function would do.  With
sequence functions, it is easier to see at a glance what the programmer is
trying to do, but harder to tell if he's doing it exactly right.  I'm not
sure if others share this preference, however.

So I believe it comes down to two questions:

1. Do we really believe that LOOP or something very close to it will be
adopted in the near future?

2. Do we believe that if the LOOP facility were part of the standard, it
would provide a better way of writing complex, non-consing loops than would
be provided by the sequence functions augmented with :TARGET or whatever?

If the answer to both questions is yes, then it makes no sense to put in
this target stuff right now.  Were it not for the problem of breaking
existing code, we might even want to eliminate some of the more complex
options from the existing sequence functions.  On the other hand, if the
answer to either question is no, then :TARGET or something like it should
go in.

I'd be interested in hearing opinions on this from the people who have been
using LOOP heavily, and also any informed views on when and whether we can
expect a proposal on improved iteration machinery.

-- Scott

∂23-Aug-88  0819	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 23 Aug 88  08:19:29 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA00525; Tue, 23 Aug 88 11:19:14 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA12481; Tue, 23 Aug 88 11:20:55 EDT
Message-Id: <8808231520.AA12481@mist.UUCP>
To: "trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU"@multimax
Cc: cl-cleanup%sail.stanford.edu@Multimax
Subject: Re: Issue "Eliminate forced consing" re-visited 
In-Reply-To: Your message of Mon, 22 Aug 88 21:39:05 -0700.
             <8808230439.AA15416@trwrb.TRW.COM> 
Date: Tue, 23 Aug 88 11:20:52 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

I support the general idea of this proposal.  It fits in our charter,
fills a real need, and is well enough specified to be considered.

However, the form of the proposal needs some more work.

- The name should probably be changed to something like
  "SEQUENCE-FUNCTION-CONSING" to come to fit our naming convention.
  As Larry said about another recent proposal, I doubt that you
  could find "ELIMINATE" in CLtI and even you could it probably
  wouldn't point to sequence functions.

- I'd suggest "SEQUENCE-FUNCTION-CONSING:TARGET-KEYWORDS" as a
  proposal name.

- The proposal text should be rewritten as if it were the new parts
  of the manual/standards document.  I'd certainly understand some
  abbreviation to keep from having to rewrite the whole sequence
  chapter and a large part of the list chapter.

- The CONCATENATE and APPEND additions should either be moved into
  the proposal section or into a second issue (which I would probably
  also support).

All-in-all, this has moved from what I remember as more a philosophical
statement than a cleanup proposal to something that I think we can,
and should, pass unless we are prepared to "depreciate" the sequence
functions entirely.

The main objection to this proposal seems to be Scott's belief that
LOOP can and will replace the sequence functions for most purposes.  I
half agree in that: while I don't think replacing sequence functions by
LOOP is a good thing, I do think that replacing them by OSS would be
good.  The critical difference is that OSS provides the functional
view of these operations that is important for some programming
styles.  You could say that it comes back down to C versus Lisp again;
if I have to write everything as DO-loops, why am I using Lisp?

∂23-Aug-88  1114	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 23 Aug 88  11:13:52 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa04760; 23 Aug 88 18:41 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Tue, 23 Aug 88 18:59:01 BST
Message-Id: <29596.8808231759@subnode.aiai.ed.ac.uk>
To: trwrb.uucp!smpvax1!jrg@ucbvax.berkeley.edu, 
    pierson <@multimax.arpa:pierson@mist>
Subject: Re: Issue "Eliminate forced consing" re-visited
Cc: cl-cleanup@sail.stanford.edu

> Date: Tue, 23 Aug 88 11:20:52 EDT
> From: "Dan L. Pierson" <pierson%mist@arpa.multimax>

> However, the form of the proposal needs some more work.

> - The proposal text should be rewritten as if it were the new parts
>   of the manual/standards document.  I'd certainly understand some
>   abbreviation to keep from having to rewrite the whole sequence
>   chapter and a large part of the list chapter.

Really?  Do we supposedly even know what the format is yet?

> All-in-all, this has moved from what I remember as more a philosophical
> statement than a cleanup proposal to something that I think we can,
> and should, pass unless we are prepared to "depreciate" the sequence
> functions entirely.

I think that is going a bit far.  Surely the sequence functions are
not nearly useless without this change.  (Recall, for example, that
some of them just search.)

I would be interested in an informed opinion on how much of the
excess allocation can be eliminated by soemthing like OSS and how
much still requires destructive operations.  I also wonder whether
OSS-like optimizations could be added to ordinary CL compilers for
some class of operations involving the normal sequence functions.

> The main objection to this proposal seems to be Scott's belief that
> LOOP can and will replace the sequence functions for most purposes.

I do not thing LOOP will really do this.  Think of concatenation.
It's much easier to call CONCATENATE than to write the loop, so
one would probably end up writing a destructive procedure with
LOOP inside it rather than using LOOP directly.

BTW, one useful weapon in the war against C would be the ability to
read n characters into a buffer (string?, array?, I don't care).
It's a pain to scan a file allocating a string for every READ-LINE.
Destructive READ-LINE might do, I suppose.  It also would be useful
(as was suggested in the proposal) to be able to refer to a
subsequence without actually extracting it.  DESIGNATE-SUBSEQ 
can probably be written in CL (sort of like locatives are written
in T), but not efficiently (and you couldn't have the normal
sequence functions work on them (except maybe via CLOS)).

-- Jeff

∂23-Aug-88  1158	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 23 Aug 88  11:57:48 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA03620; Tue, 23 Aug 88 14:57:44 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA12684; Tue, 23 Aug 88 14:59:25 EDT
Message-Id: <8808231859.AA12684@mist.UUCP>
To: Jeff Dalton <"jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK"@multimax>
Cc: cl-cleanup%sail.stanford.edu@Multimax
Subject: Re: Issue "Eliminate forced consing" re-visited 
In-Reply-To: Your message of Tue, 23 Aug 88 18:59:01 -0000.
             <29596.8808231759@subnode.aiai.ed.ac.uk> 
Date: Tue, 23 Aug 88 14:59:23 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    > All-in-all, this has moved from what I remember as more a philosophical
    > statement than a cleanup proposal to something that I think we can,
    > and should, pass unless we are prepared to "depreciate" the sequence
    > functions entirely.
    
    I think that is going a bit far.  Surely the sequence functions are
    not nearly useless without this change.  (Recall, for example, that
    some of them just search.)
    
Sorry, I don't mean that the sequence functions are useless without
this change.  "Depreciate" is a technical term from some other
language standard (Fortran?) that means the feature is left in this
version of the language but may (will?) be removed in a future
version.  My point was that if we consider the sequence functions a
desirable part of the language, this enhancement is worthwhile.  If we
don't want to enhance them because we expect them to become obsolete
we should also make that clear.

    I would be interested in an informed opinion on how much of the
    excess allocation can be eliminated by soemthing like OSS and how
    much still requires destructive operations.  I also wonder whether
    OSS-like optimizations could be added to ordinary CL compilers for
    some class of operations involving the normal sequence functions.
    
The only class of OSS functions that have to cons are some of the
reducers (I don't believe that anything else does cons at run time,
but haven't gone over the source to make sure).  For example:

Rlist items  => list

  This function creates a list of the elements in items in order.

This could easily be extended to:

Rlist items &optional list  => list

  This function creates a list of the elements in items in order.  If
  an optional list is supplied the items are placed in it ...,
  otherwise a new list is created.

There are only two sequence functions not supported by OSS: REVERSE,
and SORT (and their variants).  As I understand it, the problem with
supporting OSS by compiler optimization with no extensions is that
efficient compilation of compositions of OSS functions depends on
adherence to a specific set of constraints.  The OSS package checks
for and either corrects or signals violations of these constraints.

For example (using some examples from part one of Dick's manual):

 This works: 
  (OR (Rfirst (Tpositions (EQ ITEMP (Elist UNIVERSE))))

 This doesn't work:
  (letS* ((VALUES (Evector VALUE-VECTOR))
          (WEIGHTS (Evector WEIGHT-VECTOR))
	  (SQUARES (* VALUES VALUES))
          (WEIGHTED-SQUARES (* SQUARES WEIGHTS)))
    (LIST (Rvector SQUARES) (Rvector WEIGHTED-SQUARES)))

 This works:
  (letS* (((VALUES WEIGHTS) (Tcotruncate (Evector VALUE-VECTOR)
			                 (Evector WEIGHT-VECTOR)))
	  (SQUARES (* VALUES VALUES))
          (WEIGHTED-SQUARES (* SQUARES WEIGHTS)))
    (LIST (Rvector SQUARES) (Rvector WEIGHTED-SQUARES)))

It seems likely that an "ordinary CL compiler" could support some
OSS-style optimization, but it would probably be restricted to a much
smaller subset of compositions of sequence operations than OSS.  It
would also be harder for a compiler to deal with cases it couldn't
optimize because, since the programmer hadn't declared any intent, the
compiler would be unable to distinguish between normal code to which
an optimization didn't apply and a programmer error that prevented an
intended optimization.  For these reasons, I think that something like
OSS is needed.  However anything accepted in CL should certainly fit
better into the CL naming world.  

∂23-Aug-88  1230	CL-Cleanup-mailer 	Issue "Eliminate forced consing" re-visited   
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 23 Aug 88  12:29:48 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA04197; Tue, 23 Aug 88 15:29:38 EDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Tue, 23 Aug 88 15:28:12 EDT
Received: by joplin.think.com; Tue, 23 Aug 88 15:28:08 EDT
Date: Tue, 23 Aug 88 15:28:08 EDT
From: gls@Think.COM
Message-Id: <8808231928.AA03926@joplin.think.com>
To: pierson%mist@multimax.arpa
Cc: "jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK"@multimax.arpa,
        cl-cleanup@sail.stanford.edu@multimax.arpa
In-Reply-To: Dan L. Pierson's message of Tue, 23 Aug 88 14:59:23 EDT <8808231859.AA12684@mist.UUCP>
Subject: Issue "Eliminate forced consing" re-visited 

   Date: Tue, 23 Aug 88 14:59:23 EDT
   From: Dan L. Pierson <pierson%mist@multimax.arpa>

       > All-in-all, this has moved from what I remember as more a philosophical
       > statement than a cleanup proposal to something that I think we can,
       > and should, pass unless we are prepared to "depreciate" the sequence
       > functions entirely.

       I think that is going a bit far.  Surely the sequence functions are
       not nearly useless without this change.  (Recall, for example, that
       some of them just search.)

   Sorry, I don't mean that the sequence functions are useless without
   this change.  "Depreciate" is a technical term from some other
   language standard (Fortran?) that means the feature is left in this
   version of the language but may (will?) be removed in a future
   version. ...

"Deprecate"

--Guy

∂23-Aug-88  1650	CL-Cleanup-mailer 	loop vs. sequence functions    
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 23 Aug 88  16:50:43 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.30)
	id AA07440; Tue, 23 Aug 88 16:46:32 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
	id AA07858; Tue, 23 Aug 88 16:18:22 PDT
Date: Tue, 23 Aug 88 16:18:22 PDT
Message-Id: <8808232318.AA07858@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu, fahlman@c.cs.cmu.edu
Subject: loop vs. sequence functions

At Inference, we've been using an iteration facility based on the Interlisp
iterator facility heavily for several years.  We provide a public, supported
version of this to our customers as part of ART, our expert system building
tool.  The iterator facility is much like the LOOP facility, to my under-
standing, though I believe that the LOOP facility may clean up a few of the
less-clean aspects of using iterators.  My point is that we've had a large
user base writing Common Lisp programs in an environment where a good iteration
facility is available.  They still use sequence functions.  Many write 
iterations, but almost all use sequence functions in addition, often in
preference to iteration.  Sometimes this is based on the judgement that the
sequence functions are easier to read.  Sometimes this is based on the
(almost always mistaken) belief that the Lisp compiler will turn a sequence
operation with appropriate declarations into better code than the iteration
expands into.  More often the reason is the former, for sake of clarity.
I'm arguing that in our experience, a good iteration facility did not eliminate
use of the sequence functions (else I wouldn't have proposed the :target
argument).

In addition, I have another motive in this.  Part of the problem is one of
education.  People take courses that teach them Common Lisp syntax.  These
courses rarely teach how to write reasonably efficient programs -- at least
the students don't come away able to write efficient programs.  These courses
tend to focus on teaching what Common Lisp functions do and what the various
arguments are used for, then ask students to write programs using them to
show that they understand the explanation.  They usually don't get into
performance considerations to any significant degree.  Perhaps if we added
a :target argument for re-using conses, it would be taught and explained as
a way to avoid consing were that is appropriate.  This would provide a
tangible syntactic mechanism that would be taught and explained in a manner
that made it clear to students that storage was being allocated when sequence
functions are used in the straightforward manner versus when the :target
argument was used.  Granted, this depends on the structure of the course,
etc, but at least there would be some piece of syntax that could be matched
with teaching this important concept.

Another part of the proposal was sort of an addendum to address this same
issue in non-sequence, list, or string functions.  This part of the proposal
has parts that are analogous to the :target argument and thus either redundant
or not based on the expected utility of LOOP.  But other parts would not be
addressed by LOOP, namely the make-string-output-stream function.

Just to throw some fuel onto the fire, an alternative to the :target argument
would be to support a FREE-SEQUENCE function that returned a sequence to Lisp
for later re-use.  When the Lisp could make use of this previously-allocated
storage rather than cons new storage, it would, particularly in the sequence,
list, and string functions in preference to new allocation.  The advantage
to this is that it adds less syntactic baggage to the language.  The dis-
advantage is that is makes it less obvious where the underlying implementa-
tion is re-using storage, leaving much to the implementation.  For products
such as ART, which are marketed as minimizing the need for garbage collection,
this might pose a problem since we need to be very sure that the implementation
is re-using storage as much as possible.  Of course, we could have both...

∂23-Aug-88  2308	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Aug 88  23:08:11 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 AUG 88 23:05:42 PDT
From: masinter.PA@Xerox.COM
Date: 23 Aug 88 23:04:02 PDT
Subject: Re: Issue "Eliminate forced consing" re-visited
In-reply-to: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU's message of Mon, 22 Aug 88
 21:39:05 PDT, <8808230439.AA15416@trwrb.TRW.COM>
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.EDU
Message-ID: <880823-230542-1393@Xerox>

I've not been as quick as I should have; the issue name should be something like
SEQUENCE-FUNCTIONS-CONSING and the proposal name something like
SEQUENCE-FUNCTIONS-CONSING:ADD-TARGET.


It might help if you were prepared to offer a portable implementation of these
functions. Do you have evidence that they are implementable efficiently? 

The discussion section is much too long. We've opted for terseness, its helped,
and will be especially important if we have as many issues as I hope we will.
Can the main points be summarized, in outline form?

∂23-Aug-88  2317	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Aug 88  23:17:37 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 AUG 88 23:12:43 PDT
From: masinter.PA@Xerox.COM
Date: 23 Aug 88 23:11:02 PDT
Subject: Re: Issue "Eliminate forced consing" re-visited
In-reply-to: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Tue, 23 Aug 88 10:37:55
 EDT
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU, cl-cleanup@sail.stanford.EDU
Message-ID: <880823-231243-1402@Xerox>

What do you think about the possibility of putting (some/all/most) of the
sequence functions and also the iteration macros in the same category of
"required library"? 

The category is that: any conforming implementation of the standard must provide
them. However, they are only available to programs that REQUIRE them. So, if you
want to use LOOP, you must say (require "LOOP"). If you want to use sequence
functions, you must say (require "SEQUENCE") or some such.

The reason is that it reduces the size of the mimimal image, but allows programs
to assume that the facilities are available if they're really needed. 

∂24-Aug-88  0808	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88  08:07:53 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 24 Aug 88 11:06:24 EDT
To: masinter.PA@Xerox.COM
cc: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU, cl-cleanup@sail.stanford.EDU
Subject: Re: Issue "Eliminate forced consing" re-visited 
In-reply-to: Your message of 23 Aug 88 23:11:02 -0700.
             <880823-231243-1402@Xerox> 
Date: Wed, 24 Aug 88 11:06:09 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


    What do you think about the possibility of putting (some/all/most) of the
    sequence functions and also the iteration macros in the same category of
    "required library"? 
    
I don't see what this suggestion buys us.  If these modules are not
required to be provided by every implementation, then they can't be used in
portable code.  If they are required, as you are proposing, then the
implementors have to do the work and the library modules are
sitting out there taking up disk space.  Implementations are already free
to provide a GC-for-delivery facility that flushes everything not required
by a given application; they are also free to provide an autoload facility
that doesn't load this stuff until someone touches it.  All your proposal
does is to replace this autoload with an explicit require, hassling the
user.

Furthermore, I think that if both iteration and sequence libraries are
standardly available, both will be used to some extent and both libraries
will almost always be loaded.  The problem is that you don't want to drag
in the version with all the hairy optimizers for obscure cases just because
the user happened to call MEMBER.  If you're going to play this
minimal-core game, you want to partition these packages and drag in only
the relevant chunks.  I suspect that sooner or later this business of
creating minimal core images for delivery of finished applications will
become an area of competition among the vendors.  We don't want to
foreclose their options by mandating a single crude partioning.

My objection to including both a LOOP facility and further extensions to
the sequence functions had nothing to do with core image size; the cost I
was worried about was the added conceptual load on the user of learning two
distinct ways of doing the same thing, both of which are rather complex and
dangerous for the careless.

By the way, I don't really buy Ginder's argument that the :target extension
is good because it will force people teaching Common Lisp to mention
consing issues.  I think they will either do that or not, depending on the
interests of the teacher and the goals of the course.  Having some obscure
keyword in the language that drags this in will not make a difference in
very many cases.  DELETE is already present, so if Ginder were right, the
problem is already solved.

However, I do put some weight on his comments about people preferring to
use the sequence functions even when a good iteration facility is
present, largely because it makes it clear what the program is trying to
do.  If others agree with this observation, I'm ready to support this
proposal in principle, though some details need to be fixed up.

-- Scott

∂24-Aug-88  2030	CL-Cleanup-mailer 	required libraries to reduce image size  
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88  20:30:37 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
	id AA06846; Wed, 24 Aug 88 20:25:43 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
	id AA04503; Wed, 24 Aug 88 20:13:39 PDT
Date: Wed, 24 Aug 88 20:13:39 PDT
Message-Id: <8808250313.AA04503@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: required libraries to reduce image size

I see nothing in Common Lisp as it stands that prevents an implementation
from having sequence functions or some other part of Common Lisp auto-loaded
upon demand.  While this does not eliminate the space in the image for the
symbols identifying the autoloaded functions, this overhead should be only
a few K, at most.  Would this suffice as a substitute for Masinter's suggestion
that parts of the standard be in required libraries?  Since it seems permissible
already, perhaps this might eliminate some debate over what should be in such
libraries, etc.
--Joe Ginder
Larry: Sorry for no direct reply, my mailer seems to be unable to parse your
return address!  Sigh.

∂24-Aug-88  2107	CL-Cleanup-mailer 	oops, important mis-speak in previous mail, correction included   
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88  21:06:53 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
	id AA06684; Wed, 24 Aug 88 20:18:07 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
	id AA04497; Wed, 24 Aug 88 20:13:36 PDT
Date: Wed, 24 Aug 88 20:13:36 PDT
Message-Id: <8808250313.AA04497@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: oops, important mis-speak in previous mail, correction included

The first sentence should have been: "Common Lisp programmers need a way
of specifying already-allocated data structures as the **TARGET** of
sequence, list, and string computations."

∂24-Aug-88  2111	CL-Cleanup-mailer 	brief summary of issue "Eliminate Forced Consing"  
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88  21:11:27 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
	id AA06670; Wed, 24 Aug 88 20:17:10 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
	id AA04491; Wed, 24 Aug 88 20:13:32 PDT
Date: Wed, 24 Aug 88 20:13:32 PDT
Message-Id: <8808250313.AA04491@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: brief summary of issue "Eliminate Forced Consing"

Common Lisp programmers need a way of specifying already-allocated data
structures as the source of sequence, list, and string computations.
Allow this via use of a :target keyword argument for those functions
where this is useful.  The TARGET argument should be a sequence of the
appropriate type which is filled in with the result of the computation
This is returned rather than a newly-allocated data structure.  The
proposal also mentioned a couple of analogous additions to allow similar
specification of storage to use as the result of appending and concatenating,
along with allowing specification of a string to use for string-output-
streams.

Jeff Dalton pointed out that you'd like to be able to read into a specified
buffer sometimes instead of consing, particularly with READ-LINE.

The whole idea is to allow re-use of old data structures to minimize GC's
and new allocation.

Skip the discussion and just read the preceding parts of the message to
avoid the admittedly verbose discussion but still get the changes suggested.

∂25-Aug-88  1056	CL-Cleanup-mailer 	Re: Issue "Eliminate forced consing" re-visited    
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 25 Aug 88  10:55:36 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa05999; 25 Aug 88 18:16 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Thu, 25 Aug 88 18:39:00 BST
Message-Id: <16024.8808251739@aiai.ed.ac.uk>
To: pierson <@multimax.arpa:pierson@mist>
Subject: Re: Issue "Eliminate forced consing" re-visited
Cc: cl-cleanup@sail.stanford.edu

> Date: Tue, 23 Aug 88 14:59:23 EDT
> From: "Dan L. Pierson" <pierson%mist@arpa.multimax>
>     
>    > and should, pass unless we are prepared to "depreciate" the sequence
>    > functions entirely.
>   
>    I think that is going a bit far.  Surely the sequence functions are
>    not nearly useless without this change.
>
> Sorry, I don't mean that the sequence functions are useless without
> this change.  "Depreciate" is a technical term [...]  the feature [...]
> may (will?) be removed in a future version.  If we don't want to enhance
> them because we expect them to become obsolete we should also make that
> clear.

I don't see how this explanation invalidates my point.  This change is
not: something we should pass unless we think the sequence functions are
obsolete/perhaps-subject-to-removal anyway (and so not worth bothering to
improve).  That is, we might think the sequence functions are worth having
and still not want this change.

> As I understand it, the problem with supporting OSS by compiler
> optimization with no extensions is that efficient compilation of
> compositions of OSS functions depends on adherence to a specific set
> of constraints.  The OSS package checks for and either corrects or
> signals violations of these constraints.

[I don't insist on *no* extensions.]

> It seems likely that an "ordinary CL compiler" could support some
> OSS-style optimization, but it would probably be restricted to a much
> smaller subset of compositions of sequence operations than OSS.

Why is this?  It can detect the cases where the constraints aren't
met.  Isn't this the same as recognizing the cases where they can be
met?  OK, it can't "correct" any cases that violate the constraints.
How much depends on corrections?

> It would also be harder for a compiler to deal with cases it couldn't
> optimize because, since the programmer hadn't declared any intent, the
> compiler would be unable to distinguish between normal code to which
> an optimization didn't apply and a programmer error that prevented an
> intended optimization.

All that this seems to amount to is that the compiler can't signal an
error: all it can do is not make the optimization.  But that's what
compilers normally do when they can't make an optimization.

∂25-Aug-88  1721	CL-Cleanup-mailer 	Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Aug 88  17:21:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 450864; Thu 25-Aug-88 20:19:38 EDT
Date: Thu, 25 Aug 88 20:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Dave.Touretzky@CS.CMU.EDU, Scott.Fahlman@B.GP.CS.CMU.EDU, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880822113935.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880826001946.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

I approve of RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER.  It's interesting
that Genera fails with a negative count for lists, but not for vectors,
I'll get that added to the test suite.

∂27-Aug-88  1111	CL-Cleanup-mailer 	Issue ELIMINATE FORCED CONSING (Version 2)  [formerly "Eliminate forced consing" re-visited]    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Aug 88  11:11:40 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 451384; Sat 27-Aug-88 14:10:15 EDT
Date: Sat, 27 Aug 88 14:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ELIMINATE FORCED CONSING (Version 2)  [formerly "Eliminate forced consing" re-visited]
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8808230439.AA15416@trwrb.TRW.COM>
Message-ID: <19880827181012.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 22 Aug 88 21:39:05 PDT
    From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU

I think this is a reasonable proposal that needs a bit more work and some
simplification.  One can argue about whether it's better to provide these
storage reusing operations or to provide a good garbage collector, but I
think it makes a great deal of sense, in the context of Common Lisp, to
provide both.

I think the name :OVERWRITE would be more consistent with the rest of
Common Lisp than the name :TARGET.  It makes it clearer that this
argument is storage to be overwritten with new information.

When you say
    (1) The target sequence must accomodate elements of the type(s) in the
    source sequence.
I believe this is wrong.  It should refer to the type of the elements of the
-result- of the function, not the source.

I don't understand the need for the :TARGET-FROM-END feature and I think
you should drop it from the proposal.

    The last cons of the target list whose CAR was filled by the computation is
    returned as a second value.  The CDR of this cons is that tail of the
    target list not used to accomodate the sequence computation.

I think this feature is unnecessary and should be discarded.  I think
extra conses should simply be thrown away.  Most people exploiting this
non-consing feature are more likely to use vectors than lists, I feel.

If the feature is kept, the second value should be the cdr of what you
propose it to be, and the result should be null-terminated in the
correct place; that should not be left to the caller to do.

Another idea would be to allow the user to pass in a function that is
called whenever storage is to be allocated.  Perhaps it would take two
arguments and the default would be #'APPLY.  The first argument would
be one of #'CONS, #'MAKE-LIST, or #'MAKE-ARRAY, the second argument
would be a list of arguments with dynamic extent.  I'm not real fond
of this idea, but it does provide maximum generality.

    (4) :TARGET-START and :TARGET-END keywords are supported.

These seem useful but should be named :OVERWRITE-START and :OVERWRITE-END.

The functions SUBSEQ, COPY-SEQ, COPY-LIST, and BUTLAST need not be
modified, because the functionality is already available from REPLACE.
The functions COPY-ALIST and COPY-TREE should not be modified, because
their use of storage is too complex to fit into this model (they don't
deal in linear sequences).  The function ADJOIN should not be modified,
because a non-consing version is trivial for a user to write, and
because the consumption of storage is conditional, which would
complicate the interface.

I don't think UNION, INTERSECTION, SET-DIFFERENCE, and SET-EXCLUSIVE-OR
should be modified, because their conditional consumption of storage
would complicate the interface (unused storage has to be handed back to
the caller) and because the destructive versions that already exist can
solve the same problem, in my experience.  (They aren't completely
non-consing, but they minimize consing.)  You forgot to mention SUBST,
but I think the same reasoning applies and SUBST should not be modified.

This leaves REVERSE, MERGE, REMOVE, REMOVE-IF, REMOVE-IF-NOT,
REMOVE-DUPLICATES, SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT,
STRING-TRIM, STRING-LEFT-TRIM, STRING-RIGHT-TRIM, STRING-UPCASE,
STRING-DOWNCASE, STRING-CAPITALIZE.  I think it's reasonable to
modify these in the way you suggest.  Doing just these makes for
a much simpler proposal that is easier to understand.

MAKE-STRING-OUTPUT-STREAM should follow the same rules as
WITH-OUTPUT-TO-STRING when a string is supplied, instead of
the different rule you suggested.  With that change to make it
consistent, I support what you propose.

This leaves CONCATENATE, APPEND, REVAPPEND, and MAP (which you forgot,
but which has been discussed in the past), which take &rest arguments
and therefore are a problem.  I don't think the -into-subseq version is
useful enough to justify the extra complexity.  I also don't think the
extra complexity of allowing the caller to pass in too many conses to
APPEND and REVAPPEND and get back the unused ones as a second value is
justified.  In fact, I think I would prefer to omit APPEND-INTO from the
proposal (CONCATENATE-INTO and NCONC should suffice) and therefore to
omit REVAPPEND-INTO also.  I support CONCATENATE-INTO and MAP-INTO.

Current practice:  Symbolics Common Lisp already has MAP-INTO.

	    (2) Provide a special form like:
		   (designate-subseq sequence start end)
	    that didn't actually allocate anything but provided an imple-
	    mentation-specific "handle" on the subsequence for use
	    in such expressions as the CONCATENATE expression above.
	    (They'd print as the subseq, and setf's of their elements
	    would destructively modify the original sequence.)	

This is identical to displaced arrays, unless you propose it to work
for lists as well, in which case it is nearly unimplementable.  I think
it should be dropped.

I'd support your proposal if you simplify it more or less along the lines
I suggested.  I don't support version 2 because there is too much in it.

∂30-Aug-88  1158	CL-Cleanup-mailer 	DISALLOW-CLOSED-STREAM-FUNCTIONS    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 30 Aug 88  11:58:27 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA16097; Tue, 30 Aug 88 11:57:21 PDT
Date: Tue, 30 Aug 88 11:57:21 PDT
Message-Id: <8808301857.AA16097@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: DISALLOW-CLOSED-STREAM-FUNCTIONS

Issue:        DISALLOW-CLOSED-STREAM-FUNCTIONS
References:   CLOSE (p 332)
Category:     CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman


Problem Description:

The description of CLOSE is not completely clear about the functions
which are allowed to be performed on a closed stream.

On p332 it says:
	"The stream is closed. No further Input/output operations may be
	performed on it. However, certain inquiry operations may still
	be performed, ..."
but the list of inquiry operations is not specified.

At least one implementation interpreted the list to include
at least OUTPUT-STREAM-P, while another has disallowed that operation
to be performed on a closed stream. 

Proposal (DISALLOW-CLOSED-STREAM-FUNCTIONS:ALL)

Clarify that it is an error to perform any operation on a closed stream.

Rationale:

This clarification allows existing implementations to maintain the status
quo, while alerting users to the fact that the result of performing
an operation on a closed stream is undefined in the standard.
Also, the descriptions of OUTPUT-STREAM-P and INPUT-STREAM-P indicate
that these functions can only be performed on streams that have not
been closed.

Current Practice:

At least two implementations differ in which functions are allowed to be
performed on a closed stream.

Adoption Cost:

None.

Benefits:

This clarification will assist users in writing portable code.

Conversion Cost:

None.

Aesthetics:

None.

Discussion:


∂30-Aug-88  1201	CL-Cleanup-mailer 	RETURN-VALUES-UNSPECIFIED 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 30 Aug 88  12:00:10 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA16276; Tue, 30 Aug 88 11:59:00 PDT
Date: Tue, 30 Aug 88 11:59:00 PDT
Message-Id: <8808301859.AA16276@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: RETURN-VALUES-UNSPECIFIED


Issue:        RETURN-VALUES-UNSPECIFIED
References:   CLOSE (p 332), IN-PACKAGE (p 183), RENAME-PACKAGE (p 184),
	      TRACE (p 440), UNTRACE (p 440), INSPECT (p 442), 
	      SET-SYNTAX-FROM-CHAR (p 361),
	      LOCALLY (p 156), PROVIDE (p 188), REQUIRE (P 188)
Category:     CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman


Problem Description:

The descriptions of CLOSE, IN-PACKAGE, RENAME-PACKAGE, TRACE, UNTRACE,
INSPECT, SET-SYNTAX-FROM-CHAR, LOCALLY, PROVIDE, and REQUIRE 
are not clear about the values returned from those constructs.

Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)

Clarify that the return values for the listed constructs are as follows:

CLOSE -- the stream argument.
IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the execution
	of IN-PACKAGE.
RENAME-PACKAGE -- the renamed package.
TRACE (when called with arguments) -- implementation-dependent.
UNTRACE -- implementation-dependent.
INSPECT -- implementation-dependent.
SET-SYNTAX-FROM-CHAR -- T
LOCALLY -- the return values of the last form of its body, i.e. the body is
	surrounded by an implicit PROGN.
PROVIDE -- implementation-dependent.
REQUIRE -- implementation-dependent.

Rationale:

This clarification allows users to know when they can and can not
count on the values returned from
these constructs. 

Current Practice:


Adoption Cost:


Benefits:

This clarification will assist users in writing portable code.

Conversion Cost:


Aesthetics:

None.

Discussion:


∂30-Aug-88  1201	CL-Cleanup-mailer 	ARGUMENTS-UNDERSPECIFIED  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 30 Aug 88  12:01:13 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA16405; Tue, 30 Aug 88 12:00:02 PDT
Date: Tue, 30 Aug 88 12:00:02 PDT
Message-Id: <8808301900.AA16405@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: ARGUMENTS-UNDERSPECIFIED

Issue:        ARGUMENTS-UNDERSPECIFIED
References:   LOGBITP (p 224), MAKE-DISPATCH-MACRO-CHARACTER (p 363), 
	      MAKE-HASH-TABLE (p 283), MAKE-SEQUENCE (p 249), READ (p 375)
     	      MAKE-STRING (p 302), NTHCDR (p 267), PARSE-INTEGER (p 381),
	      SET (p 92)
Category:     CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman


Problem Description:

The descriptions of LOGBITP, MAKE-DISPATCH-MACRO-CHARACTER, READ, SET,
MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING, NTHCDR, and PARSE-INTEGER 
are not clear about the types of the arguments supplied to these 
constructs.

Proposal (ARGUMENTS-UNDERSPECIFIED:SPECIFY)

Clarify that the arguments for the listed constructs are as follows:

Construct			Argument	Type
LOGBITP 			index		non-negative integer
MAKE-DISPATCH-MACRO-CHARACTER 	char		character
MAKE-HASH-TABLE			size	 	non-negative integer
MAKE-SEQUENCE	     		size		non-negative integer
MAKE-SEQUENCE	     		type		type specifier
MAKE-STRING			size            non-negative integer
MAKE-STRING			initial-element	string-char
NTHCDR 				n		non-negative integer
PARSE-INTEGER 			start,end       non-negative integers
PARSE-INTEGER 			start,end       non-negative integers
SET-SYNTAX-FROM-CHAR		to-char,from-char
						characters
READ and others			eof-value	T
SET				value		T

Rationale:

This clarification allows predictible results to occur when 
arguments are supplied to these constructs.

Current Practice:


Adoption Cost:


Benefits:

This clarification will assist users in writing portable code.

Conversion Cost:


Aesthetics:

None.

Discussion:

∂31-Aug-88  1513	CL-Cleanup-mailer 	Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 31 Aug 88  15:12:51 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 213745; Wed 31-Aug-88 18:11:53 EDT
Date: Wed, 31 Aug 88 18:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880831181117.6.KMP@GRYPHON.SCRC.Symbolics.COM>

Issue:        TAIL-RECURSION-OPTIMIZATION
References:   5.1 Forms (pp54-59), SYMBOL-FUNCTION (p90)
Category:     CHANGE
Edit history: 31-Aug-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  Useful tail-recursion optimizations are not permitted by CLtL because
  the compiler must assume that any opaque function call might change
  the definition of a function in between calls to that function, so a
  direct jump to the code is not appropriate.

  The best a compiler can do right now is approximately:
    (IF (EQ #'FOO ...what compiler expects...)
        ...fast jump...
        ...standard function calling sequence...)

Proposal (TAIL-RECURSION-OPTIMIZATION:PERMIT):

  Permit tail-recursion optimizations in some situations, but do not
  require them.

  Specifically, with SPEED=0, the compiler should not produce
  tail-recursion optimizations (for the sake of tracing, stack debugging,
  and reloading in interactive debugging), but with in other with higher
  speed settings, it is permitted to make such optimizations.

  Specify that the NOTINLINE declaration can be used within a function
  to inhibit tail recursive calls from within that function, regardless
  of the OPTMIZE SPEED setting.

  Specify that the NOTINLINE proclamation can be used to globally
  inhibit tail recursive calls to a particular function, regardless
  of the OPTMIZE SPEED setting.

Test Cases:

  #1: (DEFUN FACTORIAL-2 (X &OPTIONAL (N 1))
        (COND ((= X 0) N)
	      (T (FACTORIAL-2 (- X 1) (* N X)))))

      The compiler is permitted to (but not required to) treat this
      as if the following had been written instead:

      (DEFUN FACTORIAL-2 (X &OPTIONAL (N 1))
	(LABELS ((FACTORIAL-2 (X &OPTIONAL (N 1)))
		   (COND ((= X 0) N)
			 (T (FACTORIAL-2 (- X 1) (* N X)))))
	  (FACTORIAL-2 X N)))

  #2: (DEFMACRO DEFUN-AUTOLOADING (NAME FILE)
	`(PROGN (PROCLAIM '(NOTINLINE ,NAME))
		(DEFUN ,NAME (&REST ARGUMENTS)
		  (LET ((OLD-ME #',NAME))
		    (LOAD ,FILE)
		    (LET ((NEW-ME #',NAME))
		      (WHEN (EQ OLD-ME NEW-ME)
			(ERROR "Function ~S was undefined after autoload." ',NAME))
		      (APPLY NEW-ME ARGUMENTS))))))
      (DEFUN-AUTOLOADING FOO "foo.lisp")
      (DEFUN BAR (X) (FOO X))

      The compiler must not make assumptions about the contents of FOO,
      so the function BAR will always see the current definition of FOO even
      in the face of runtime redefinition.

Rationale:

  Tail recursion optimization is an important source of speed improvement.

  Program modularity is of key importance to many Common Lisp programmers,
  and it would be rash to say that the compiler could simply violate function
  boundaries at whim. Nevertheless, for Common Lisp to successfully compete
  with other languages, it should be designed in a way that at least permits
  implementations to make this optimization.

  This proposal is designed to achieve a workable compromise between issues of
  speed and debuggability.

  Some implementations do tail recursion removal already even when it is
  not permitted. Such implementations have an unfair benchmark advantage over
  "correct but slow" implementations in the marketplace. This would even the
  odds for those implementations who would do the optimization if only it were
  correct.

Current Practice:

  Symbolics Genera and Symbolics Cloe not currently do tail recursion
  optimization. As such, they are compatible with the proposal.

Cost to Implementors:

  None. This permits action for those interested in taking it, but does
  not require any action.

Cost to Users:

  Small. Some users who do runtime redefinition of functions would have to
  add some declarations if they were compiling code with SPEED>0.

Cost of Non-Adoption:

  Lisp would show up poorly against other languages in certain benchmarks.

  Lisp vendors who do this optimization even though it's technically not
  correct would continue have an unfair business advantage over vendors
  over those who respect the rules of the language.

Benefits:

  Compilers which chose to implement the optimization in question would
  be able to produce better code.

Aesthetics:

  No major aesthetic impact.

Discussion:

  Pitman explored a number of different variants of this proposal before
  sending this one. He's not wedded to the details here, but just tried to
  submit something that would sound plausible. If there are ways to change
  things which would make this proposal more palatable, he's happy to
  hear them.

  Charles Hornig (Symbolics) observes that SPEED=0 is perhaps not quite
  the right criterion. The issue of whether absolute values of the 
  OPTIMIZE qualities are what's of interest or only relative values of
  the different qualities is an open topic. For now, this proposal uses
  SPEED 0 just to be conservative. If everyone can agree on something
  broader, we could change the proposal. Alternatively, we can just 
  adopt that part of the proposal `as is' and work on a separate proposal
  on how to deal with OPTIMIZE qualities.

∂31-Aug-88  1632	CL-Cleanup-mailer 	Issue: PROCLAIM-SCOPE (Version 1)   
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 31 Aug 88  16:32:45 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 213776; Wed 31-Aug-88 19:22:16 EDT
Date: Wed, 31 Aug 88 19:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-SCOPE (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <880831192150.7.KMP@GRYPHON.SCRC.Symbolics.COM>

As indicated in the discussion below, I think this is really a rough
cut, but I think the issue it treats is a real one so I figured I'd
see what others think.
 -kmp

-----
Issue:        PROCLAIM-SCOPE
References:   PROCLAIM (pp156-157)
Category:     ADDITION
Edit history: 26-Aug-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  It would be useful to be able to do PROCLAIM without worrying about cleaning
  up afterward. For example, a file containing:

  In some cases, such as SPECIAL, there is no way to disable the effect of a
  proclamation.

  In other cases, such INLINE and SAFETY, it is possible but inconvenient to
  change the declaration later. Even so, there is no way of inquiring about the
  previous value in order to correctly restore it.

Proposal (PROCLAIM-SCOPE:ADD-KEYWORD-PERVASIVE):

  Introduce a :LOCALLY keyword parameter to PROCLAIM which controls
  the scope of a proclamation.

  (PROCLAIM proclamation :LOCALLY T)
    In a file, this would put the PROCLAMATION into effect for the entire
    rest of time during which the file was being loaded (including
    recursive loads).

    Interactively, it would be the same as :LOCALLY NIL.

  (PROCLAIM proclamation :LOCALLY NIL)
    In a file or interactively, this would put the PROCLAMATION into
    effect permanently. (The declaration would not be retracted when the
    file was done loading.)

Proposal (PROCLAIM-SCOPE:ADD-KEYWORD-NON-PERVASIVE):

  Introduce a :LOCALLY keyword parameter to PROCLAIM which controls
  the scope of a proclamation.

  (PROCLAIM proclamation :LOCALLY T)
    In a file, this would put the PROCLAMATION into effect for the entire
    rest of the current file. Recursive loads or compilations would rebind
    this to the global default.

    Interactively, this would affect interactive work but would not 
    affect the default for files loaded.

  (PROCLAIM proclamation :LOCALLY NIL)
    In a file or interactively, this would put the PROCLAMATION into
    effect permanently, affecting the default for files in which no
    local proclamation overrode it. (The declaration would not be retracted
    when the file was done loading.)

Test Case:

  Given a file "FOO" containing:

   (PROCLAIM '(OPTIMIZE (SPEED 0) (SAFETY 3)) :LOCALLY T)
   ...

  Doing

   (LOAD "FOO")

  would not clobber the global default for SPEED/SAFETY.

Rationale:

  This would address several existing problems with CL...
    - Declarations of optimize qualities such as speed/safety
    - Absence of UNSPECIAL declaration

  Macsyma has a lot of files which do (PROCLAIM '(SPECIAL ...)) at the
  top of the file and then does an implementation-specific
  (PROCLAIM '(UNSPECIAL ...)) at the bottom for implementations that
  support it. It would be both more modular and more portable to do
  something such as what is proposed here.

Current Practice:

  Symbolics Cloe binds optimization qualities (SAFETY, SPEED, 
  COMPILATION-SPEED) in file compilations and doesn't allow
  them to affect the global default.

Cost to Implementors:

  [I imagine the level of difficulty in providing this feature is in the
   low to intermediate difficulty range. It's not likely to be trivial for
   anyone, but I doubt anyone is going to claim that it is prohibitively
   expensive if we can get the details right and show that it satisfies a
   real need. -kmp]

Cost to Users:

  None. This is a compatible change.

Cost of Non-Adoption:

  Programmers would continue to clobber each others environments with pervasive
  SPEED and SAFETY proclamations.

Benefits:

  It would be possible to proclaim SPEED/SAFETY information locally in a file
  without worrying about the pervasive effect on other code compiled/loaded
  subsequently in the same environment.

Aesthetics:

  Probably people would find that this kind of flexibility had a beneficial
  effect on program aesthetics.

Discussion:

  Pitman has no firm opinion on this issue at this time, but believes that
  something like this might be quite useful if we could iron out the details.

∂31-Aug-88  2112	CL-Cleanup-mailer 	3 new cleanups  
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Aug 88  21:12:11 PDT
Date: Wed 31 Aug 88 15:23:03-EDT
From: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
Subject: 3 new cleanups
To: cl-cleanup@sail.stanford.edu
Message-ID: <12426885902.53.BECKERLE@XX.LCS.MIT.EDU>


Following this message are 3 new cleanup issues that I hope are not
too late for consideration at the October x3j13 meeting.
They've been delayed this long because I've been hoping for a real
arpanet connection, but alas, I've decided to kermit to MIT-XX and
revive my account there to do this.


...mike beckerle.

-------

∂31-Aug-88  2112	CL-Cleanup-mailer 	lambda-cleanup  
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Aug 88  21:12:21 PDT
Date: Wed 31 Aug 88 15:24:41-EDT
From: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
Subject: lambda-cleanup
To: cl-cleanup@sail.stanford.edu
cc: beckerle@XX.LCS.MIT.EDU
Message-ID: <12426886201.53.BECKERLE@XX.LCS.MIT.EDU>


Issue:		LAMBDA-IS-OPERATOR
References:     X3J13/86-010, x3j13/86-019 pg 4.
Category: 	Compatible Change
Edit History:   v0 28june88  mike beckerle


Problem Description:

The symbol LAMBDA in common lisp has odd status.  It is not an
operator of any kind, but is recognized by other forms, like
FUNCTION, as a syntactic construct indicating that an expression
represents a function.

One must write (FUNCTION (LAMBDA ...)) or #'(LAMBDA ...)
to indicate an anonymous function in common lisp, where 
simply (LAMBDA ...) would be just as clear.

The proposal FUNCTION-TYPE passed in June 88 by x3j13 takes
significant steps to help clarify the difference between functions,
and lists which "look" like functions. LAMBDA-NON-OPERATOR goes
further in this direction.


Proposal: LAMBDA-IS-SPECIAL-FORM

LAMBDA should be a special form which denotes a function.

In the light of the FUNCTION-TYPE proposal, this means that
lambda-expressions would denote objects of type FUNCTION, and that
quoted lambda expressions would denote objects of type LIST. 

Proposal: LAMBDA-IS-MACRO

Define lambda as a standard macro as follows:

(defmacro lambda (&rest body)
  `(function (lambda ,@body)))


Discussion: 

One of the most confusing aspects of lisp for naive users is the
confusion in lisp between "meta" programming, and "higher-order"
programming. By meta programs I intend programs which manipulate the
lists which are the syntax of other programs; for example, macros are
usually "meta" programs.  Higher-order programs, on the other hand,
are programs which accept functions as arguments and return functions
as results. 

Since meta-programming and higher-order programming are really
orthogonal techniques, it is better to avoid confusing the two.
Particularly since both are difficult programming techniques.

The key characteristic of meta-programming in lisp is use of QUOTE,
quoted expressions, list manipulation, and either explicit or
implicit use of the lisp interpreter, EVAL, (or the compiler).
Higher-order programming does not involve the distinction between
programs and lists that look like programs, hence, whether EVAL is
called or not is irrelevant.  Higher-order programming is currently
confused with meta-programming by many lisp programmers. This cleanup
taken with the FUNCTION-TYPE cleanup would make the distinction much
clearer; hence, make learning and understanding common-lisp programs
easier.


If LAMBDA-IS-SPECIAL-FORM was adopted, then one can explain the
FUNCTION special-form primarily as a way of distinguishing between
the function and value definitions of a variable. It also allows
(FUNCTION (LAMBDA ...)) to be equivalent to (LAMBDA ...) for backward
compatibility. For LAMBDA-IS-MACRO, explaining LAMBDA in terms of
(FUNCTION (LAMBDA ...)) seems conceptually less simple.  Note that
accepting LAMBDA-IS-SPECIAL-FORM still allows all implementations to
define it using the macro definition if they wish.

Note that this change is orthogonal to any changes made to the
language to support '(lambda (...) ...) as an argument to funcall,
apply, etc. This was the subject of much debate when the
FUNCTION-TYPE proposal was considered at the June 88 x3j13 meeting.
Hence, if FUNCTION-TYPE is ammended to allow some common lisp
operations to accept lists and coerce them to functions, 
the LAMBDA-IS-OPERATOR proposal would be unaffected.

Implementation Impact:

LAMBDA-SPECIAL-FORM would require very minor changes to any programs
which have code-walkers.

Some implementations do not allow LAMBDA to be defined as a macro.
These implementations are already not in conformance with CLtL.



-------

∂31-Aug-88  2112	CL-Cleanup-mailer 	list type cleanup    
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Aug 88  21:12:49 PDT
Date: Wed 31 Aug 88 15:25:52-EDT
From: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
Subject: list type cleanup
To: cl-cleanup@sail.stanford.edu
cc: beckerle@XX.LCS.MIT.EDU
Message-ID: <12426886415.53.BECKERLE@XX.LCS.MIT.EDU>


Issue:		LIST-TYPE-SPECIFIER
References:     CLtL, pg 26, 27, 43.
Category: 	Compatible Change
Edit History:   v0 28june88  mike beckerle


Problem Description:

There is a need in common lisp for more accurate type specifiers
for lists. In particular, there is no way to express
the type of a list having particular element types.

Resolving this issue will help resolve FUNCTION-TYPE-REST-LIST-ELEMENT.


Proposal: LIST-TYPE-EXTENDED

(1) The LIST type specifier would be extended to allow 
specification of arguments. e.g.,

(typep x 'list)  => unchanged from current meaning

(typep x '(list <subtype>)) == (and (typep x 'list)
                                    (typep (car x) <subtype>))

(typep x '(list <s1> <s2> ... <sN>)) ==
        (and (typep x 'list)
             (typep (car x) <s1>)
             (typep (cadr x) <s2>)
             ...
             (typep (car (last x)) <sN>))


Hence, the LIST type specifier is extended to allow specification of the
types of the arguments.

(2) A new type specifier is added: LIST-OF.

(typep x 'LIST-OF) = error.

(typep x '(list-of <elttype>)) == (and (typep x 'list)
	                               (dolist (elem x T)
				         (unless (typep x <elttype>)
                                            (return nil))))


Discussion:

The addition of these type specifiers allows resolution of the
FUNCTION-TYPE-REST-LIST-ELEMENT proposal in a way which will allow
type-specifiers to still be highly specific about the types of 
elements passed in &rest arguments.

In particular, (function (&rest (list-of number)) number), can be
distinguished from (function (&rest (list complex fixnum bignum))
number).





					       



-------

∂31-Aug-88  2113	CL-Cleanup-mailer 	CLOS standard class cleanup    
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Aug 88  21:13:01 PDT
Date: Wed 31 Aug 88 15:28:13-EDT
From: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
Subject: CLOS standard class cleanup
To: cl-cleanup@sail.stanford.edu
cc: beckerle@XX.LCS.MIT.EDU
Message-ID: <12426886843.53.BECKERLE@XX.LCS.MIT.EDU>


Issue:		STANDARD-CLASS-OVERHEAD
References:     CLOS 88-002R pg 1-43, 1-46.
Category: 	CHANGE
Edit History:   v0 27june88  mike beckerle


Problem Description:

The class STANDARD-CLASS allows not only for object-oriented
programming, with multiple-inheritance, but also allows for
non-trivial meta-object programming, including the operation
CHANGE-CLASS.

It is likely that many applications will make no use of
class-redefinition. All pre-CLOS common lisp applications are
examples of this. Given the new Condition/Error component of CL they
will have to run in a world which has error/condition objects in it,
yet since they are pre-clos, they will certainly make no-use of
class-redefinition. 

Unfortunately, the code for accessing/updating instance-variables of
an object is significantly more complex if the class can be changed
at run time. See discussion item below on instance-variable-access-
overhead.

Proposal: Standard-class-made-simpler.

The class standard-class should be defined to not-allow
class-redefinition at run time. Compilers would be authorized
to issue compile-time errors if they could determine that
a class of meta-class standard-class was being 
redefined programatically.


Proposal: Change-class-names

The name Standard-class is misleading. Eliminate the
name standard class and introduce two names for "predefined"
classes. One of which does not support class-redefinition
and the other of which does.
Suggested names are:

a)  non redefinable class      redefinable class
b)  standard-class             standard-redefinable-class
c)  simple-class 	       changeable-class
d)  static-class	       dynamic-class
  

Discussion: instance-variable-access-overhead.

This issue of standard-class overhead was raised prior to the
june 88 x3j13 meeting. The CLOS committee replied to this 
issue as follows:

  "In addition, we don't believe that this functionality causes any
   performance problems. Experience with New Flavors and PCL has shown
   that there is no performance penalty incurred by including this
   functionality in CLOS."

This discussion is intended to provide a more detailed notion of the
kinds of overhead involved.
 
Using a simple model of instance variable access, If classes cannot
be redefined at program run-time, then instance-variable access can
be coded into 3 unchecked indirections, and instances can be stored
as linear vectors of slots.

Using similar technology, but allowing class-redefinition requires 2
unchecked indirections, and 1 checked indirection, thereby requiring
a conditional branch.  In addition, instances must be represented
using an extra indirection (or an optional indirection) to the actual
slots, thereby requiring 1 extra pointer in each object
representation.

Example:

(defclass foo
    (x y z))

(defun bar (&optional (obj (make-instance 'foo)))
   (foo-x obj))

Without class redefinition, foo-x can be inline coded as the following 
common-lisp code:

(defmacro foo-x (obj)
  `(let* ((obj ,obj)
          (perm-vector (svref *perm-vectors* (object-class-number obj)))
          (i-v-offset (svref perm-vector ,(i-v-number 'x 'foo)))
      (instance-slot obj i-v-offset)))

where instance-slot is like svref, it just indexes instance objects
directly the way svref indexes simple vectors.  This assumes that
instances have a flat structure, containing no indirections to the
instance variables themselves. They are like structures, but the
access mechanism allows for multiple-inheritance.

Machine-code wise, this can be inline coded as something like:
 
   move r1, <obj>                 ; r1 points at the object.
   move r2, (r1 object-class-num) ; absolute offset from r1 base.
                                  ; r2 = class number
   movad r3, *perm-vectors*       ; absolute address load.
   move r2, (r3+r2)               ; indexed off r3 base.
   				  ; r2 = permutation vector
   move r2, (r2 i-v-number)       ; absolute offset from r3 base 
   				  ; r2 = instance-var offset in object.
   move r1, (r1+r2)               ; indexed off r1 base.
   				  ; r1 = instance-var value.

This is a six instruction sequence involving no jumps, hence, no
pipeline breaks on processors with instruction pipelining.

To support class-redefinition using similar technology:

(defmacro foo-x (obj)
  `(let* ((obj ,obj)
          (perm-vector (svref *perm-vectors* (object-class-number obj)))
          (i-v-offset (svref perm-vector ,(i-v-number 'x 'foo)))
      (if (slot-exists-p i-v-offset)
         (let ((i-v-structure (instance-slot ,i-v-structure-offset)))
           (svref i-v-structure i-v-offset))
	 (error "Slot ~A no longer exists in object ~S"
	        'x obj))))

This assumes that instances have an indirected structure, that is, in
order to get at an instance variable, one must always indirect
through a fixed location in each instance to obtain a vector of the
slots. This allows the number of instance variables to increase if
needed.

Machine-code wise, this would be coded as something like:
 
   move r1, <obj>                 ; r1 points at the object.
   move r2, (r1 object-class-num) ; absolute offset from r1 base.
                                  ; r2 = class number
   movad r3, *perm-vectors*       ; absolute address load.
   move r2, (r3+r2)               ; indexed off r3 base.
   				  ; r2 = permutation vector
   move r2, (r2 i-v-number)       ; absolute offset from r3 base 
   cmp  r2, invalid-slot          ; absolute comparison.
   je :noslot			  ; conditional branch.
   				  ; r2 = instance-var offset in i-v-structure.
   move r1, (r1 i-v-structure)    ; absolute offset from r1 base
   				  ; r1 = i-v-structure.
   move r1, (r1+r2)               ; indexed off r1 base.
   				  ; r1 = instance-var value.
   jmp :done			  ; unconditional jump
:noslot
   .... call error ....
:done       
   
Note that this involves 4 more instructions, not including any
to report the error, plus 1 jump (hence pipeline break on pipelined
processors.). There is no way to rearrange this code so that there
is no branch required. 

I make no claims that these code sequences are optimal, but only that
they are representative of the relative complexity of instance
variable access when supporting and not-supporting class redefinition.
I belive that on conventional machine architectures, instance-variable
access could be twice as fast if the compiler could insure that
the class could not be redefined at run-time. In addition, each
instance can be smaller.

If a CLOS application used only the non-redefinable class, then
the functions involved in the class-change operations can be removed
from run-time systems.

To sumarize, there seems to be significant enough overhead required to
support class-redefinition, both in object representation, code-size,
and execution speed to justify inclusion of a meta-class which 
does not allow class-redefinition in the standard.

Cost of Adoption:

Effectively zero, as CLOS was only accepted into the standard recently.
In addition, an implementation should be free to implement the
non-redefinable class in the exact same way as the redefinable class,
(possibly signaling an error on redefinition attempts).

Cost of Non-Adoption:

Due to runtime delivery considerations it is likely that vendors
will provide implementation specific class definitions which do not
have the class-redefinition capability. 



-------

∂31-Aug-88  2118	CL-Cleanup-mailer 	Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 31 Aug 88  21:17:56 PDT
Received: from kent-state ([192.9.200.24]) by heavens-gate id AA05222g; Wed, 31 Aug 88 20:17:06 PST
Received: by kent-state id AA03523g; Wed, 31 Aug 88 21:15:50 PDT
Date: Wed, 31 Aug 88 21:15:50 PDT
From: Eric Benson <eb@lucid.com>
Message-Id: <8809010415.AA03523@kent-state>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Wed, 31 Aug 88 18:11 EDT <880831181117.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)

This is not tail-recursion optimization.  This is more properly called
EARLY-FUNCTION-BINDING.  As it happens, early function binding is
often combined with tail-recursion optimization in the case of self
calls.  This has led to some confusion between the two, but in fact
they are orthogonal.  To clarify, tail-recursion optimization means
not consuming stack space for a function call when the result of that
call will be the result of the function making the call.  Early
function binding means committing to a particular function definition
for a name before the call itself, in Common Lisp usually referring to
a commitment to a particular definition when there is the possibility
of a redefinition which would invalidate that commitment.  Either or
both of these optimizations may be applied to both self calls and
calls to other functions.

∂01-Sep-88  0847	CL-Cleanup-mailer 	Re: Issue: PROCLAIM-SCOPE (Version 1)    
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Sep 88  08:47:38 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU;  1 Sep 88 11:46:14 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: PROCLAIM-SCOPE (Version 1) 
In-reply-to: Your message of Wed, 31 Aug 88 19:21:00 -0400.
             <880831192150.7.KMP@GRYPHON.SCRC.Symbolics.COM> 
Date: Thu, 01 Sep 88 11:45:55 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU


A problem I see with your suggested use of scoped SPECIAL proclamations is
that it works with "compiled" code and not "interpreted" code.  In our
interpreter, at least, a variable is only considered globally special when
there is a global special declaration currently in effect.

Given that the language currently doesn't address the issue of
compiler/interpreter differences, it seems dangerous to implicitly mandate
a clear compiler/interpreter incompatibility.

I believe that it isn't feasible to define different compiler and
interpreter semantics.  This means that "portable Common Lisp" must
restrict itself to constructs that work both in compiled and interpreted
code.  Either the interpreter must do preprocessing to maintain the
"compiler" semantics, or compiled code must be constrained to do things
that work in the interpreter.

  Rob

∂01-Sep-88  1040	CL-Cleanup-mailer 	Re: CLOS standard class cleanup
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Sep 88  10:40:33 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 01 SEP 88 10:14:50 PDT
Date: Thu, 1 Sep 88 10:13 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: CLOS standard class cleanup
To: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
cc: cl-cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <12426886843.53.BECKERLE@XX.LCS.MIT.EDU>
Message-ID: <19880901171316.8.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: Wed, 31 Aug 88 15:28:13 EDT
    From: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>


    Issue:		STANDARD-CLASS-OVERHEAD
    References:     CLOS 88-002R pg 1-43, 1-46.
    Category: 	CHANGE
    Edit History:   v0 27june88  mike beckerle


    Without class redefinition, foo-x can be inline coded as the following 
    common-lisp code:

    (defmacro foo-x (obj)
      `(let* ((obj ,obj)
	      (perm-vector (svref *perm-vectors* (object-class-number obj)))
	      (i-v-offset (svref perm-vector ,(i-v-number 'x 'foo)))
	  (instance-slot obj i-v-offset)))


    To support class-redefinition using similar technology:

    (defmacro foo-x (obj)
      `(let* ((obj ,obj)
	      (perm-vector (svref *perm-vectors* (object-class-number obj)))
	      (i-v-offset (svref perm-vector ,(i-v-number 'x 'foo)))
	  (if (slot-exists-p i-v-offset)
	     (let ((i-v-structure (instance-slot ,i-v-structure-offset)))
	       (svref i-v-structure i-v-offset))
	     (error "Slot ~A no longer exists in object ~S"
		    'x obj))))

Actually, there is an important bug in this code.  In both the class
redefinition and non class redefinition case there needs to be a check
to make certain the slot exists as a local slot in the instance.  If
not, a trap handler must be called to check whether it could be a shared
slot or just doesn't exist.  There is no way of knowing this at compile
time.  So, these should be re-written as:

; without redefinition
(defmacro foo-x (obj)
  `(let* ((obj ,obj)
	  (perm-vector (svref *perm-vectors* (object-class-number obj)))
	  (i-v-offset (svref perm-vector ,(i-v-number 'x 'foo))))
     (if (null i-v-offset)
	 (trap obj 'x)
	 (instance-slot obj i-v-offset))))


;with redefinition
(defmacro foo-x (obj)
  `(let* ((obj ,obj)
	  (perm-vector (svref *perm-vectors* (object-class-number obj)))
	  (i-v-offset (svref perm-vector ,(i-v-number 'x 'foo))))
     (if (null i-v-offset)
	 (trap obj 'x)
	 (let ((i-v-structure (instance-slot ,i-v-structure-offset)))
	   (svref i-v-structure i-v-offset)))))


So, you can see that both cases involve a test and jump.  The only
difference is one an additional memory read, and in a method which does
multiple slot accesses, this additional read can be amortized over all
those accesses.

In addition, it is worth pointing out that there is a trivial
implementation strategy which uses the faster case and allows
redefinition.  Under this strategy, classes which have been redefined
pay a penalty for instance access, but other classes do not.
-------

∂01-Sep-88  1105	CL-Cleanup-mailer 	Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 1 Sep 88  11:05:09 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 213936; Thu 1-Sep-88 14:04:14 EDT
Date: Thu, 1 Sep 88 14:03 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
To: eb@LUCID.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8809010415.AA03523@kent-state>
Message-ID: <880901140348.9.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Wed, 31 Aug 88 21:15:50 PDT
    From: Eric Benson <eb@lucid.com>

    This is not tail-recursion optimization...

You're right. I'm familiar with the distinctions you're making and am guilty
of sloppy wording.

In the meantime -- while I rewrite the proposal to refer to "early binding"
rather than "tail recursion" where appropriate -- could you please comment on
whether you are likely to support such an ammended proposal, or if not, why
not? (I'll also try to broaden the set of test cases to include a
non-tail-recursive example in which early binding just for clarity.)
Are your objections more than ones of mere terminology and classification?
Do you want to use something other than INLINE? Do you want to contest the
chosen defaults? Do you think this is a non-issue? These are the kinds of
questions I'd like to see answered. I'd like to not have discussion of this
proposal fall off just because of some (admittedly glaring) wording problems.

∂01-Sep-88  1123	CL-Cleanup-mailer 	lambda-cleanup  
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 1 Sep 88  11:23:11 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 213940; Thu 1-Sep-88 14:22:13 EDT
Date: Thu, 1 Sep 88 14:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: lambda-cleanup
To: beckerle@XX.LCS.MIT.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <12426886201.53.BECKERLE@XX.LCS.MIT.EDU>
References: <880622180746.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <880901142148.0.KMP@GRYPHON.SCRC.Symbolics.COM>

A proposal called LAMBDA-FORM is already on the table to address
the issue you raise. I'll forward you a copy. If you find there
are issues which your proposal raises which were not in mine, 
maybe we can do some merging...

∂01-Sep-88  1210	CL-Cleanup-mailer 	Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Sep 88  12:10:51 PDT
Received: from kent-state ([192.9.200.24]) by heavens-gate id AA05438g; Thu, 1 Sep 88 11:10:06 PST
Received: by kent-state id AA03819g; Thu, 1 Sep 88 12:08:50 PDT
Date: Thu, 1 Sep 88 12:08:50 PDT
From: Eric Benson <eb@lucid.com>
Message-Id: <8809011908.AA03819@kent-state>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Thu, 1 Sep 88 14:03 EDT <880901140348.9.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)

I support this proposal completely, assuming it is reworded as you
indicate.  In fact, Lucid has already implemented and documented this
proposal, exactly as you describe it.  Early function binding is done
on all self calls, not just self tail calls, unless the function is
declared or proclaimed NOTINLINE.  In our model, SPEED=0 means
everything is NOTINLINE.  This is in knowing violation of the Law
(civil disobedience?), but we have never to my knowledge received a
bug report from a customer about it.

∂01-Sep-88  1422	CL-Cleanup-mailer 	Re: Issue: PROCLAIM-SCOPE (Version 1)    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 1 Sep 88  14:22:12 PDT
Received: by ti.com id AA29992; Thu, 1 Sep 88 16:19:23 CDT
Received: from Kelvin by tilde id AA11924; Thu, 1 Sep 88 16:04:07 CDT
Message-Id: <2798139957-9660596@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 1 Sep 88  16:05:57 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PROCLAIM-SCOPE (Version 1)
In-Reply-To: Msg of Wed, 31 Aug 88 19:21 EDT from Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

> Proposal (PROCLAIM-SCOPE:ADD-KEYWORD-PERVASIVE):
> 
>   Introduce a :LOCALLY keyword parameter to PROCLAIM which controls
>   the scope of a proclamation.
> 
>   (PROCLAIM proclamation :LOCALLY T)
>     In a file, this would put the PROCLAMATION into effect for the entire
>     rest of time during which the file was being loaded (including
>     recursive loads).

While being loaded or while being compiled?  Most PROCLAIMs affect what
happens at compile-time, not load time.

>     Interactively, it would be the same as :LOCALLY NIL.

This probably should be considered an error since it isn't meaningful, but
some implementations might give it a meaning, such as being local to the
current process.

> Proposal (PROCLAIM-SCOPE:ADD-KEYWORD-NON-PERVASIVE):
> 
>   Introduce a :LOCALLY keyword parameter to PROCLAIM which controls
>   the scope of a proclamation.
> 
>   (PROCLAIM proclamation :LOCALLY T)
>     In a file, this would put the PROCLAMATION into effect for the entire
>     rest of the current file. Recursive loads or compilations would rebind
>     this to the global default.
> 
>     Interactively, this would affect interactive work but would not 
>     affect the default for files loaded.

This approach sounds more like what the user would expect (like lexical
scoping instead of dynamic scoping), although it would be a little harder
to implement.

>   Macsyma has a lot of files which do (PROCLAIM '(SPECIAL ...)) at the
>   top of the file and then does an implementation-specific
>   (PROCLAIM '(UNSPECIAL ...)) at the bottom for implementations that
>   support it. It would be both more modular and more portable to do
>   something such as what is proposed here.

This doesn't seem to be a very convincing example.  There shouldn't be any
need to routinely undo SPECIAL declarations if packages are being used
correctly.

> Current Practice:
> 
>   Symbolics Cloe binds optimization qualities (SAFETY, SPEED, 
>   COMPILATION-SPEED) in file compilations and doesn't allow
>   them to affect the global default.

Likewise on the TI Explorer. (PROCLAIM '(OPTIMIZE ...)) affects the
compilation but is not included in the object file.  (PROCLAIM '(SPECIAL
...) doesn't affect the global environment until the object file is
loaded.

--

This issue interacts with the EVAL-WHEN problems being considered by the
compiler committee.  If EVAL-WHEN can be extended and/or clarified to
permit specifying actions local to COMPILE-FILE, that might make an
extension to PROCLAIM unnecessary.

  -- David Gray

∂01-Sep-88  1437	CL-Cleanup-mailer 	Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1) 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 1 Sep 88  14:37:30 PDT
Received: by ti.com id AA00269; Thu, 1 Sep 88 16:35:15 CDT
Received: from Kelvin by tilde id AA12434; Thu, 1 Sep 88 16:27:48 CDT
Message-Id: <2798141382-9746178@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 1 Sep 88  16:29:42 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
In-Reply-To: Msg of Wed, 31 Aug 88 18:11 EDT from Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>

> Issue:        TAIL-RECURSION-OPTIMIZATION
> References:   5.1 Forms (pp54-59), SYMBOL-FUNCTION (p90)
> Category:     CHANGE
> Edit history: 31-Aug-88, Version 1 by Pitman
> Status:	      For Internal Discussion
> 
> Problem Description:
> 
>   Useful tail-recursion optimizations are not permitted by CLtL because
>   the compiler must assume that any opaque function call might change
>   the definition of a function in between calls to that function, so a
>   direct jump to the code is not appropriate.

"Tail-recursion optimizations" could mean one of two things:  either
a function that calls itself being optimized into a loop, or jumping to
another function while keeping the same stack frame.  Your examples only
mention the first case; I don't see that the second is any problem.  I'm
not even convinced that the first case is really a problem since I haven't
seen an example of meaningful code where it would not be safe to assume
that a function didn't redefine itself (other than the DEFUN-AUTOLOADING
example, which is not a likely candidate for optimization anyway).  In any
case, all one would have to do to insure a run-time indirection is to do 
(FUNCALL (SYMBOL-FUNCTION 'FOO) ...) instead of (FOO ...).

Anyway, I think it would be a mistake to tie this issue with the
SPEED and NOTINLINE declarations since they are intended to affect
efficiency, not the semantics of the code.

> Current Practice:
> 
>   Symbolics Genera and Symbolics Cloe not currently do tail recursion
>   optimization. As such, they are compatible with the proposal.

The TI Explorer does do tail recursion optimization (both kinds) at higher
optimization levels.  It does assume that a function won't redefine
itself, but no one has reported that as being a problem.

  -- David Gray

∂01-Sep-88  2309	CL-Cleanup-mailer 	Issue: PROCLAIM-SCOPE (Version 1)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Sep 88  23:09:37 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate id AA05807g; Thu, 1 Sep 88 22:07:21 PST
Received: by bhopal id AA04511g; Thu, 1 Sep 88 23:06:39 PDT
Date: Thu, 1 Sep 88 23:06:39 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809020606.AA04511@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Wed, 31 Aug 88 19:21 EDT <880831192150.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-SCOPE (Version 1)

re: Proposal (PROCLAIM-SCOPE:ADD-KEYWORD-PERVASIVE):

      Introduce a :LOCALLY keyword parameter to PROCLAIM which controls
      the scope of a proclamation.

      (PROCLAIM proclamation :LOCALLY T)
	In a file, this would put the PROCLAMATION into effect for the entire
	rest of time during which the file was being loaded (including
	recursive loads).

	Interactively, it would be the same as :LOCALLY NIL.

      (PROCLAIM proclamation :LOCALLY NIL)
	In a file or interactively, this would put the PROCLAMATION into
	effect permanently. (The declaration would not be retracted when the
	file was done loading.)


Although you've called this a "scoping" issue, you've really made it an
"extent" issue. (See CLtL Chapter 3).  The phraseology "... would put the 
PROCLAMATION into effect for the entire rest of time during which the file 
was being loaded ..." bears this out.


Lucid Common Lisp has a function called FILE-PROCLAIM, which has essentially
the same semantics as your proposal:  It "retracts" all proclamations
made during the loading/compilation of the file.  But we decided not to
recommend its use, precisely because we thought most users would confuse 
the issue of dynamic extent with local scoping.

In fact, one of the issues in my "private" list of things that we at Lucid
are concerned about, but which have not had a satisfactory submissions to 
the cleanup committee yet, is just the matter of a "Lexical Proclaim".  In 
the hardcopy sheet I handed out to many committee members, at the Palo Alto
meeting in March of this year, there should have been the paragraph:

 (5) Add a lexical "pervasive" declaration special form; e.g, 
	   (locally (pervasive-declare (special foo))
	     ...)
     has syntax like 'declare, but acts more like proclaim; it pertains only
     to the lexical scope indicated -- its action is not dynamically scoped. 
     In particular, it differs from 'declare' in that interior binding forms 
     "inherit" the declaration, rather than forming a "wall" against it.


This is the functionality that I would support, even though wrapping
a 'pervasive-declare' around a 'defun' has implementational consequences
similar to wrapping a non-null 'let' [i.e., there may be a non-null
lexical environment].



-- JonL --

∂02-Sep-88  1357	CL-Cleanup-mailer 	reaching closure on open cleanup items   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88  13:57:48 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 13:49:47 PDT
Date: 2 Sep 88 13:49 PDT
From: Masinter.pa@Xerox.COM
Subject: reaching closure on open cleanup items
To: cl-cleanup@sail.stanford.edu
Message-ID: <880902-134947-7091@Xerox>

I've put off cleanup for a while, but hope to get back to it seriously now. I
think that if we're going to distribute stuff in time for the October meeting
that we need to get resolution in the next three weeks. That's a pretty
heavy-duty schedule. This is to warn you to be prepared for a barrage. 

∂02-Sep-88  1636	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (Version 1) formerly    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88  16:36:47 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 16:15:59 PDT
Date: 2 Sep 88 16:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 1) formerly
 DISALLOW-CLOSED-STREAM-FUNCTIONS
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of Tue, 30 Aug 88
 11:57:21 PDT
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-161559-7391@Xerox>

I'm going to nitpick the name of the issue, and call the it
CLOSED-STREAM-OPERATIONS.

Frankly, I'd be unhappy if there were no way to ask a stream whether it was
closed. I would much prefer OUTPUT-STREAM-P and INPUT-STREAM-P be required to
just answer NIL on closed streams.


∂02-Sep-88  1637	CL-Cleanup-mailer 	Re: RETURN-VALUES-UNSPECIFIED  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88  16:36:55 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 16:21:46 PDT
Date: 2 Sep 88 16:20 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: RETURN-VALUES-UNSPECIFIED
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of Tue, 30 Aug 88
 11:59:00 PDT
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-162146-7401@Xerox>

I might quibble with a few of these:

INSPECT: it is marginally more useful to say that INSPECT returns the item
inspected. Some interactive inspectors might allow you to return a new value as
the value of INSPECT, e.g., (SETQ X (INSPECT X)). 

PROVIDE and REQUIRE are not likely to appear except in the "top level" of files.

∂02-Sep-88  1844	CL-Cleanup-mailer 	Ooops! Issue: LAMBDA-CAR-OF-FORM    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88  18:44:48 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 17:34:13 PDT
Date: 2 Sep 88 17:34 PDT
From: Masinter.pa@Xerox.COM
Subject: Ooops! Issue: LAMBDA-CAR-OF-FORM 
In-reply-to: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>'s message of Wed, 31
 Aug 88 15:24:41 EDT
To: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-173413-7637@Xerox>


Sorry, I also didn't notice the message from Kent about LAMBDA-FORM. I should
have the issues sorted out over the weekend to start summarizing status early
next week.

∂02-Sep-88  1844	CL-Cleanup-mailer 	Issue: LAMBDA-CAR-OF-FORM (was LAMBDA-IS-OPERATOR) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88  18:44:42 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 17:24:33 PDT
Date: 2 Sep 88 17:24 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: LAMBDA-CAR-OF-FORM (was LAMBDA-IS-OPERATOR)
In-reply-to: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>'s message of Wed, 31
 Aug 88 15:24:41 EDT
To: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-172433-7582@Xerox>

I'll take the perogative of renaming the issue. 

I've always had a hard time with the "problem" in this one -- the problem is
that you have to say #'(LAMBDA ...) instead of (LAMBDA ...).  However, the
proposal increases the number of special forms, since it doesn't eliminate the
need for FUNCTION.  Does it make the language better to have more special forms?

Frankly, your argument about Higher-order vs Meta-programming doesn't do much
for me; its an interesting way of looking at the problem, but is it really
relevant to this issue?


∂02-Sep-88  1845	CL-Cleanup-mailer 	Re: Issue: PROCLAIM-SCOPE (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88  18:45:09 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 17:45:34 PDT
Date: 2 Sep 88 17:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PROCLAIM-SCOPE (Version 1)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Thu, 1 Sep 88 23:06:39
 PDT
To: Jon L White <jonl@lucid.com>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-174534-7686@Xerox>

A major concern is that any additions that talk about "file" should have some
reasonable semantic model; currently, the semantics of Common Lisp are described
in terms of expressions, without regard to file boundaries. I've thought that it
might be possible to talk about special "file" forms, that have translations
into things that can be typed in interactively. 

Some possible models for "file" are 

Assume each file is wrapped with an implicit "progn".

Assume each expression in a file is actually preceded with an implicit "(locally
" ...

Otherwise, we're left with an operational semantics that describes what things
*mean* only in terms of what LOAD or COMPILE *does*....


∂02-Sep-88  1845	CL-Cleanup-mailer 	Re: required libraries to reduce image size   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88  18:44:53 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 17:42:24 PDT
Date: 2 Sep 88 17:42 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: required libraries to reduce image size
In-reply-to: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU's message of Wed, 24 Aug 88
 20:13:39 PDT
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-174224-7678@Xerox>

Making something part of the "required library" is a way of deprecating it. It
makes it possible to relegate it to a separate package; the "require" explicitly
will make sure that the package is available before first mention. 

People complain that Common Lisp is too big and complex; you have to know too
much to read a Common Lisp program. When a program is annotated with an explicit
"require", it makes it clear what other things you have to understand to
understand the module in hand. 

While it might also reduce the image size, I don't see that as the primary
benefit -- rather, it helps make the language simpler by making it explicit that
some of the more seldom used features are really part of a "library" rather than
the "language".

∂02-Sep-88  1845	CL-Cleanup-mailer 	Re: required libraries to reduce image size   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88  18:45:01 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 17:42:49 PDT
Date: 2 Sep 88 17:42 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: required libraries to reduce image size
In-reply-to: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU's message of Wed, 24 Aug 88
 20:13:39 PDT
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-174249-7684@Xerox>

Making something part of the "required library" is a way of deprecating it. It
makes it possible to relegate it to a separate package; the "require" explicitly
will make sure that the package is available before first mention. 

People complain that Common Lisp is too big and complex; you have to know too
much to read a Common Lisp program. When a program is annotated with an explicit
"require", it makes it clear what other things you have to understand to
understand the module in hand. 

While it might also reduce the image size, I don't see that as the primary
benefit -- rather, it helps make the language simpler by making it explicit that
some of the more seldom used features are really part of a "library" rather than
the "language".

∂02-Sep-88  1845	CL-Cleanup-mailer 	Re: Issue: PROCLAIM-SCOPE (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88  18:45:19 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 17:45:42 PDT
Date: 2 Sep 88 17:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PROCLAIM-SCOPE (Version 1)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Thu, 1 Sep 88 23:06:39
 PDT
To: Jon L White <jonl@lucid.com>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-174542-7687@Xerox>

A major concern is that any additions that talk about "file" should have some
reasonable semantic model; currently, the semantics of Common Lisp are described
in terms of expressions, without regard to file boundaries. I've thought that it
might be possible to talk about special "file" forms, that have translations
into things that can be typed in interactively. 

Some possible models for "file" are 

Assume each file is wrapped with an implicit "progn".

Assume each expression in a file is actually preceded with an implicit "(locally
" ...

Otherwise, we're left with an operational semantics that describes what things
*mean* only in terms of what LOAD or COMPILE *does*....


∂04-Sep-88  1447	CL-Cleanup-mailer 	[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>: Issue: ALIST-NIL  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Sep 88  14:47:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 88 14:45:03 PDT
Date: 4 Sep 88 14:44 PDT
From: Masinter.pa@Xerox.COM
Subject: [Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>: Issue: ALIST-NIL
 (Version 1)]
To: CL-Cleanup@SAIL.STANFORD.EDU
line-fold: NO
Message-ID: <880904-144503-8857@Xerox>

!
Issue:        ALIST-NIL
References:   Definition of "a-list" (p279), ASSOC (p280)
Category:     CHANGE
Edit history: 20-Jun-88, Version 1 by Pitman
	          4-Sep-88, Version 2 by Masinter (reflect discussion)

Problem Description:

  NIL is permitted to be an element of an a-list but nothing useful
  can be done with such an element. This is confusing to users. 

Proposal ALIST-NIL:DISALLOW:

  Change the definition of an a-list to require all elements to be
  real conses. Uses of ASSOC with non-standard a-list would be an error.

Test Case:

  (ASSOC 'X '(NIL (X . 3)))
  is currently defined to return (X . 3).
  Under this proposal, this would be an error.

Rationale:

  No motivation in CLtL is given for NIL being allowed in an a-list.

  The description of a-lists seem needlessly complicated by this feature.

  FIND (with a :KEY of #'CAR) and ASSOC (with no key) are almost identical
  except for their treatment of this issue. If no one makes significant
  use of the feature, it would be better to be able to simplify the
  relationship between these functions.

Current Practice:

  All valid implementations allow NIL.

Cost to Implementors:

  Since the proposal is to make this an "is an error" situation, no
  implementation would be forced to change.

Cost to Users:

  There are two basic ways in which the author is able to guess this
  feature might be used:

  #1: A user might want a leading NIL on an a-list so that if the list
  were empty, there'd still be a tail to which cells could be attached
  in the future. That is,
   (DEFVAR *MY-ALIST* (CONS NIL '()))
  so that 
   ...(NCONC *MY-ALIST* (LIST new-cell))...
  would always be possible as a side-effect and
   ...(ASSOC element *MY-ALIST*)...
  would always be possible for lookup. It might be argued that this is more
  clearly written:
   (DEFVAR *MY-TABLE* (CONS NIL '()))
   (DEFUN ADD-ENTRY (ENTRY TABLE) (NCONC TABLE (LIST ENTRY)))
   (DEFMACRO MY-TABLE-CONTENTS (X) `(CDR ,X))
   ...(ADD-ENTRY new-cell *MY-TABLE*)...
   ...(ASSOC element (MY-TABLE-CONTENTS *MY-TABLE*))...

  #2: A user might want to splice out an element from an a-list, preserving
  the place that the element occupied in the list. In the very rare cases
  where this was necessary, one could rewrite:
   (DEFUN VOID-FIRST-ENTRY (ALIST) (SETF (CAR ALIST) NIL))
  as:
   (DEFUN VOID-FIRST-ENTRY (ALIST)
     (LET ((ENTRY (CONS NIL NIL)))
       (SETF (CAR ENTRY) ENTRY) ;Something unique
       (SETF (CAR ALIST) ENTRY)))
    This might change the behavior of ASSOC-IF, ASSOC-IF-NOT, 
  RASSOC-IF and RASSOC-IF-NOT depending on the predicate used.

Cost of Non-Adoption:

  There only consequence of non-adoption is the burden of carrying around
  the additional complexity in each implementation, in the documentation,
  and in teaching. The cost of this burden is likely to be a subjective
  matter.

Benefits:

 Simplified documentation. May allow ASSOC to be faster if it is no longer necessary to check explicitly for NIL.

Aesthetics:

  This change would simplify the language.

Discussion:

  Pitman submitted this proposal after looking at the write-up of
  a-lists in the new standard. The description seems needlessly
  cluttered by this unmotivated and he felt that either a motivation
  for this feature should be cited and defended or the feature should
  go away. The degree to which he believes in this feature will be
  determined by any claims made by others in ensuing discussion.

 Putting a NIL in an alist as a way of removing the element might be simpler 
than putting some otherwise useless CONS, and allows for a quick (remove NIL 
alist).

  Some people might consider this change gratuitous.

∂04-Sep-88  1521	CL-Cleanup-mailer 	Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Sep 88  15:21:24 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 88 15:20:18 PDT
Date: 4 Sep 88 15:19 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
Subject: Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)
Message-ID: <880904-152018-8868@Xerox>

I tried to add a current practice, etc. section. 

I added some wording about other constraints to the other arguments.

Saying T as the type of eof-value and SET confused me; one might interpret,
especially since eof-value is optional, and none of the other types are named by
their type specifier. 

I'm not too worried about the distinction of STRING-CHAR vs CHAR since the
character committee will propose to get rid of the distinction, but it might
otherwise come up in SET-SYNTAX-FROM-CHAR and MAKE-DISPATCH-MACRO-CHARACTER.


!
Issue:        ARGUMENTS-UNDERSPECIFIED
References:   LOGBITP (p 224), MAKE-DISPATCH-MACRO-CHARACTER (p 363), 
	      MAKE-HASH-TABLE (p 283), MAKE-SEQUENCE (p 249), READ (p 375)
     	      MAKE-STRING (p 302), NTHCDR (p 267), PARSE-INTEGER (p 381),
	      SET (p 92)
Category:     CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
	 4-Sep-88, version 2 by Masinter

Problem Description:

The descriptions of LOGBITP, MAKE-DISPATCH-MACRO-CHARACTER, READ, SET,
MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING, NTHCDR, and PARSE-INTEGER 
are not clear about the types of the arguments supplied to these 
constructs.

Proposal (ARGUMENTS-UNDERSPECIFIED:SPECIFY)

Clarify that the arguments for the listed constructs are as follows:

Construct			Argument	Type
LOGBITP 			index		non-negative integer
MAKE-DISPATCH-MACRO-CHARACTER 	char		character
MAKE-HASH-TABLE			size	 	non-negative integer
MAKE-SEQUENCE	     		size		non-negative integer
MAKE-SEQUENCE	     		type		type specifier
MAKE-STRING			size            non-negative integer
MAKE-STRING			initial-element	string-char
NTHCDR 				n		non-negative integer
PARSE-INTEGER 			start,end       non-negative integers
PARSE-INTEGER 			start,end       non-negative integers
SET-SYNTAX-FROM-CHAR		to-char,from-char
						characters
READ and others			eof-value	any value
SET				value		any value

(MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING have additional constraints on
their respective SIZE arguments; for example, MAKE-STRING may signal an error if
SIZE is greater than or equal to ARRAY-DIMENSION-LIMIT. PARSE-INTEGER may signal
an error if the START or END arguments are  not in the range of the "string"
argument.)

Rationale:

This clarification allows predictible results to occur when 
arguments are supplied to these constructs.

Current Practice:

We 
Cost to Implementors:

None, since this is consistent with current practice.

Cost to Users:
None, since this is consistent with current practice.

Benefits:

This clarification will assist users in writing portable code.

Aesthetics:

The standard would be less clean were the allowed ranges of its functions not
specified.

Discussion:

∂04-Sep-88  1559	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Sep 88  15:59:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 88 15:56:22 PDT
Date: 4 Sep 88 15:56 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 1)
Message-ID: <880904-155622-8877@Xerox>

This reminds me a little of the PATHNAME issue. I think that CLOSE is only valid
for streams that PATHNAME was valid for

What does it mean to CLOSE a composite stream ( broadcast two-way synonym
concatenated) ? The choices I can think of are:
a) no effect
b) implementation dependent (ugh)
c) closes constituent streams
d) the composite stream is "closed" (no I/O operations allowed) but
	the constituents are not.

What does it mean to close a constructed stream (e.g., STRING)? 
a) no effect
b) implementation dependent (ugh)
c) the constructed stream is "closed" (no I/O operations allowed).


I think the following operations should be as valid after a CLOSE as before
(i.e., they're valid after the close only if they were valid before):

STREAMP, INPUT-STREAM-P, OUTPUT-STREAM-P, TRUENAME, PATHNAME. (In fact, there
are some operating systems where you can *only* get TRUENAME on a closed stream,
since the name isn't true until the stream has been closed.)

Note that the issues STREAM-CAPABILITIES, STREAM-INFO, and  STREAM-CLASS-ACCESS
add functions that take streams.

∂04-Sep-88  1617	CL-Cleanup-mailer 	Issue: COERCE (Version 1) vs COERCE-FROM-TYPE 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Sep 88  16:09:45 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 88 16:05:13 PDT
Date: 4 Sep 88 16:05 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: COERCE (Version 1) vs COERCE-FROM-TYPE
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Mon, 20 Jun 88 12:19 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880904-160513-8886@Xerox>

Kent: I think that the issues COERCE-FROM-TYPE and COERCE-INCOMPLETE are the
same issue, with two separate proposals. I'd like to merge the discussion of
them, since I favor the combination of the two proposals better than either one
alone, that is, add the TYPE argument, use the class precedence list to define
the priority when there is an ambiguity of how to view the type. 

M.Ida brought up a good point in his message of 18 Jul 88; do we need a cleanup
to redefine TYPE-OF to be the same as (CLASS-NAME (CLASS-OF x)) ?

∂05-Sep-88  1324	CL-Cleanup-mailer 	Re: Potential issues?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Sep 88  13:23:57 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 05 SEP 88 13:20:37 PDT
From: masinter.PA@Xerox.COM
Date: 5 Sep 88 13:18:39 PDT
Subject: Re: Potential issues?
In-reply-to: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK's message of Mon, 5 Sep
 88 17:51:08 BST, <7296.8809051651@aiai.ed.ac.uk>
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: Masinter.PA@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <880905-132037-9404@Xerox>

Well, my inclination is to concentrate on ambiguities over additions to the
language, except where there is some agreement in current practice.

In the area of read case sensitivity, I remember that we thought about this
issue a lot in Xerox Common Lisp, since we had to support Interlisp too, and
Interlisp was case sensitive. While Franz handles case sensitivity with a global
parameter (or is it a global state), we made it a property of the read table;
that is, the readtable could be a case sensitive or case insensitive readtable.
This preserved the property that *READTABLE* captured the variations in the
behavior of READ. It has not been a formal cleanup issue; if you want to write
one up, READ-CASE-SENSITIVITY is a good name for it.

As for READ-INTERNAL-CASE, its less clear to me what the problem is -- you
mention embarrassment, but that seems to depend too much on the perspective of
the viewer. Are you embarrassed by parentheses? By names like FMAKUNBOUND or
CADADR? 

I think we withdrew PROCLAIM-LEXICAL because we couldn't figure out how to
procede. If you like, I can send you the back-mail on the issue if you want to
see if you can make some progress.

HASH-TABLE-ENTRY-EXTENT: I was expecting that the discussion on Common Lisp
would wind up as a cleanup proposal. Sounds like a good idea. Will you?

Re Symbol-macro-flet: I'm just not convinced of the utility. At least the
compilers I am familiar with go to some lengths to optimize uses of FLET and
LABELS; having another binding mechanism doesn't seem like a step forward. And
SYMBOL-MACRO-LET is under attack. 


Re what the meaning of (MACROLET ((F () 'A)) #'F) might be: I believe this is an
error; I think we might even find enough evidence to convince ourselves that
CLtL says so, and that the editor merely needs make it more carefully worded.

∂05-Sep-88  1417	CL-Cleanup-mailer 	Potential issues?    
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 5 Sep 88  14:16:06 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa04323; 5 Sep 88 17:22 BST
Date: Mon, 5 Sep 88 17:51:08 BST
Message-Id: <7296.8809051651@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Potential issues?
To: Masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu

I am wondering whether it is worth raising / reviving the following
issues:

1. Read-case-sensitivity: It is difficult to make READ case-sensitive.
(Well, you might try defining lots of character macros, so perhaps it
is possible: hence the "difficult".)  Case-sensitivity is useful for
certain applications.  I should think something like a *READ-PRESERVE-
CASE* variable would be an appropriate solution.  Has this issue been
raised before?

2. Read-internal-case: Upper case is somewhat of an embarrassment these
days and is harder to read besides.  So it's a shame that Common Lisp
uses it internally.  *PRINT-CASE* can be used to hide the internal case
on output, but it still appears from time to time.  ExCL has (or had) a
way of dealing with this, so there is some precedent.  Nonetheless, I
suspect that any attempt to change the internal case would be doomed,
except for one thing: some trick along the lines of the canonical case
suggestion for pathnames could be used to aid conversion or to hide the
internal case for read as well as print.  One consequence is that, in
some setting, all upper case would mean all lower case (and vice versa),
but that may be an acceptable price to pay.

3. Proclaim-lexical: I seem to recall that this is an existing issue.
KMP's PRLCLAIM-SCOPE is related (since it would limit the scope of
special proclamations).

4. Hash-table-extry-extent: This refers to: <something like hash tables
except that entries could be removed if there was no reference to the
key except in such tables>.  This issue been discussed on the CL list
but has not (as far as I know) been raised as an actual suggestion for
change.  Note that such tables can be added with little work: since CL
does not require that there be a GC, it could just as well not require
that any entries actually disappear.  The main question is whether they
should be presented as hash tables or as something else.

5. Symbol-macro-flet: SYMBOL-MACRO-LET lets me have something that
looks like a variable but is really some expression.  It might seem
that MACROLET does the same for function names, but it doesn't.
MACROLET applies to entire calls, not just the name.  This suggests
that SYMBOL-MACRO-LET should have a companion, SYMBOL-MACRO-FLET.

For example:

     (symbol-macro-flet ((f '(g)))
       (list (f (a-list))
             (apply #'f (another-list)))

would be equivalent to:

    (list (funcall (g) (a-list))
          (apply (g) (some-list)))


BTW, what is the meaning of (MACROLET ((F () 'A)) #'F)?  In KCL and
Lucid, it seems to be the same as #'F without the MACROLET; but (F)
in the MACROLET is not the same as (F) without: this seems to be an
inconsistent interpretation of F.

-- Jeff

∂06-Sep-88  1010	CL-Cleanup-mailer 	RETURN-VALUES-UNSPECIFIED 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88  10:09:19 PDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Tue, 6 Sep 88 12:36:09 EDT
Received: by joplin.think.com; Tue, 6 Sep 88 12:31:23 EDT
Date: Tue, 6 Sep 88 12:31:23 EDT
From: gls@Think.COM
Message-Id: <8809061631.AA22700@joplin.think.com>
To: Masinter.pa@xerox.com
Cc: chapman%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 2 Sep 88 16:20 PDT <880902-162146-7401@Xerox>
Subject: RETURN-VALUES-UNSPECIFIED

   Date: 2 Sep 88 16:20 PDT
   From: Masinter.pa@xerox.com

   I might quibble with a few of these:

   INSPECT: it is marginally more useful to say that INSPECT returns the item
   inspected. Some interactive inspectors might allow you to return a new value as
   the value of INSPECT, e.g., (SETQ X (INSPECT X)). 

I disagree.  If one regards INSPECT as a tool in the interactive
interface, it can be a real nuisance to inspect some huge data structure
and then when you finish it insists on printing 300 lines of gobbledygook
at you.
--Guy

∂06-Sep-88  1753	CL-Cleanup-mailer 	Re: RETURN-VALUES-UNSPECIFIED  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88  17:53:09 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 SEP 88 17:42:07 PDT
Date: 6 Sep 88 17:41 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: RETURN-VALUES-UNSPECIFIED
In-reply-to: gls@Think.COM's message of Tue, 6 Sep 88 12:31:23 EDT
To: gls@Think.COM
cc: Masinter.pa@Xerox.COM, chapman%aitg.DEC@decwrl.dec.com,
 cl-cleanup@sail.stanford.edu
Message-ID: <880906-174207-11565@Xerox>

OK

∂07-Sep-88  0001	CL-Cleanup-mailer 	Revised ELIMINATE-CONSING-PROPOSAL, version 3 
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 7 Sep 88  00:01:00 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
	id AA13656; Tue, 6 Sep 88 23:52:14 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
	id AA12438; Tue, 6 Sep 88 15:37:57 PDT
Date: Tue, 6 Sep 88 15:37:57 PDT
Message-Id: <8809062237.AA12438@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: Revised ELIMINATE-CONSING-PROPOSAL, version 3

Issue:         ELIMINATE FORCED CONSING

References:    CLtL section 14.1,3,5; 15.2,5; 17.4; 18.3; 21.2

Category:      ADDITION

Edit history:  Version 1, 20-Jul-88, Ginder
               Version 2, 22-Aug-88, Ginder
                   Moved discussion to the discussion section.
                   Changed multiple value proposal, clarified
                   certain points.
               Version 3, 31-Aug-88, Ginder
                   Revised according to various comments. Much of
                   my original discussion has been eliminated.

Problem description:

Some sequence, list, and string functions in CLtL encourage a
programming style that uses excessive storage allocation compared to
libraries of routines with similar functionality in other languages,
notably C.  The only options available to the Common Lisp programmer who
uses these functions are to generate a newly-allocated sequence or to
destructively modify the argument sequence(s) given the function.  The
option of providing a sequence, list, or string into which the result of
a sequence operation should be placed is not available.

Proposal:

Add mutually exclusive :RECYCLE or :MODIFY keyword arguments to those
sequence, list, and string functions where such arguments are useful.
:RECYCLE is used to pass a sequence to be recycled to hold the result of
the sequence, list, or string operation.  :MODIFY is used to pass a
sequence that is to be modified in some manner to contain the result of
the operation.  The distinction lies in that :MODIFY is akin to
destructively modifying a useful data structure, while :RECYLE is used
to simply recycle a data structure that would otherwise be useless and
possibly garbage (i.e., a data structure whose contents are no longer of
interest and may be altered arbitrarily).  The sequence, list, or string
function returns the MODIFY'd or RECYLE'd sequence as specified below.
It is an error to pass both a :MODIFY and a :RECYCLE argument.

[a] Support a MODIFY argument:

(1) The sequence to be modified must accomodate elements of the type(s)
that would have been stored in a newly-allocated sequence.  Thus it
would be an error to give a target string argument if the result of the
operation would normally have had elements that were not all of type
STRING-CHAR.

(2a) A non-list MODIFY argument should have an allocated length long
enough to accomodate the normal result of the sequence function.  The
sequence to be modified may have a fill pointer.  The fill pointer
remains unchanged by this operation so long as it points after the
modified elements of the sequence.  If the fill pointer points prior to
or in the range of the modified elements, it is set to point immediately
after the last element filled in by the sequence computation.  If the
sequence to be modifed is longer than necessary, the unneeded trailing
elements are unchanged.

(2b) A list MODIFY argument is extended with new conses to be as long as
necessary to accomodate the resulting sequence, if not enough conses are
supplied and the :MODIFY-FROM-END keyword is nil.  Two values are
returned:  the first is the modified list with any unused tail remaining
intact. (I.e., The unused conses remain as a tail of the modified list
that is returned.)  The second is that tail of the original list that
was not modified by the operation.  This second value is useful for
continued modification of the tail.

(3) :MODIFY-START and :MODIFY-END keywords are supported.  MODIFY-START
and MODIFY-END determine where in sequence the result of the sequence
computation is placed.  It is an error if the sub-length of the sequence
specified by these arguments is not long enough to accomodate the
sequence computation.  If a longer than necessary subsequence is
specified, then the elements in the unneeded part of the specified
subsequence are unchanged.

(4) A :MODIFY-FROM-END keyword is supported.  If non-nil, the sequence
to be modified is filled with new elements starting at MODIFY-END (e.g.,
the end of the sequence if MODIFY-END is not specified), effectively
reversing the order of elements of the as the sequence is modified.  It
is an error if the supplied sequence is not long enough for the result.
If the supplied sequence is longer than necessary, leading elements are
unchanged.

Sequence functions changed to include MODIFY, MODIFY-START, MODIFY-END,
MODIFY-FROM-END:
	subseq, copy-seq, reverse, remove, remove-if,
	remove-if-not, remove-duplicates, substitute, substitute-if,
	substitute-if-not, merge

List functions changed to include MODIFY, MODIFY-START, MODIFY-END,
MODIFY-FROM-END:
	copy-list, butlast

String functions changed to include MODIFY, MODIFY-START, MODIFY-END,
MODIFY-FROM-END:
	string-trim, string-left-trim, string-right-trim, string-upcase,
	string-downcase, string-capitalize

[a] Support a RECYLE argument:

(1) The sequence to be recycled must accomodate elements of the type(s)
that would have been stored in a newly-allocated sequence.  Thus it
would be an error to give a RECYLE string argument if the result of the
operation would normally have had elements that were not all of type
STRING-CHAR.

(2a) A non-list RECYCLE argument should have an allocated length long
enough to accomodate the normal result of the sequence function.  The
sequence to be recycled may have a fill pointer.  The fill pointer is
set to point immediately after the last element filled in by the
sequence computation.  If the sequence to be recycled is longer than
necessary, the unneeded trailing elements are unchanged.

(2b) A list RECYCLE argument is extended with new conses to be as long
as necessary to accomodate the resulting list, if not enough conses are
supplied.  Two values are returned:  the first is the result list
terminated with NIL.  (I.e., The unused conses are spliced out of the
recycled list that is returned.)  The second is that tail of the
original list that was not used by the recycling operation.

(3) No :RECYCLE-START, :RECYCLE-END, or :RECYCLE-FROM-END arguments are
supported.

Changed sequence functions:
	subseq, copy-seq, reverse, remove, remove-if,
        remove-if-not, remove-duplicates, substitute, substitute-if,
        substitute-if-not, merge

Changed list functions:
	make-list, copy-list, copy-alist, copy-tree, butlast, subst,
        sublis, adjoin, union, intersection, set-difference,
        set-exclusive-or

Changed string functions:
	string-trim, string-left-trim, string-right-trim, string-upcase,
	string-downcase, string-capitalize 

Examples:

(copy-seq '(1 2 3) :modify '(a b c d e f g))
	=> (1 2 3 d e f g)

(copy-seq '(1 2 3) :modify '(a b c d e f g) :modify-from-end t :modify-end 5)
	=> (a b 3 2 1 f g)

(remove 'a '(b b a b b a b b a b b) :count 1 :recycle '(3))
	=> (b b b b a b b a b b)   ; EQ to :recycle arg, CDR is new conses.

(substitute #\a #\b "This is a string with 2 a's"
	    :modify (make-array 37 :element-type 'string-char :fill-pointer 0))
	=> "This is b string with 2 b's" ; result EQ to MODIFY arg, 
					 ; result has a fill-pointer set to 27 

(substitute #\a #\b "ababa"
	    :modify (make-array 10 :element-type 'string-char
				   :initial-element #'q
	                           :fill-pointer 10))
	=> "aaaaaqqqqq" ; result EQ to MODIFY arg, 
			; result has a fill-pointer set to 10 

(copy-list '(a b c) :recycle '(1 2 3 4 5 6 7))
	=> (a b c)    ; first value
           (4 5 6 7)  ; second value

(copy-list '(a b c) :modify '(1 2 3 4 5 6 7))
	=> (a b c 4 5 6 7)  ; first value
           (4 5 6 7)        ; second value

In related additions, included here since they address the same problem
as above, provide extended versions of concatenate, append, revappend,
make-string-output-stream, and read-line as follows:

  concatenate-into target &rest sequences
    Like CONCATENATE, but the result type is determined to be
    the type of TARGET.  The result is TARGET containing as many
    of the elements of SEQUENCES as can be accomodated by the
    allocated length of TARGET.  TARGET's fill pointer, if
    present is set according to how many elements of TARGET are
    filled by this operation.
  
  map-into target function sequence &rest sequences
    Like MAP, but the result type is determined to be the type
    of TARGET.  The result of MAP-INTO is TARGET such that
    element j is the result of applying FUNCTION to element j
    of each of the argument sequences.  TARGET must be as long
    as the shortest of the input sequences.  TARGET's fill
    pointer, if present is set according to how many elements of
    TARGET are filled by this operation.
  
  append-into target &rest lists
    Like APPEND, but the copied list arguments are copied into
    conses taken from TARGET.  The last list in LISTS
    is not copied, as in APPEND, rather, the last cons used
    from TARGET is given the last list in LISTS as its cdr.
    The result is EQ to TARGET (unless a single list is appended),
    but contains only those conses needed to hold the appended
    lists' elements.  The tail of unused conses from TARGET is
    returned as a second value; new conses are allocated if
    TARGET supplies an insufficient number of conses.
  
  revappend-into target x y
    Like REVAPPEND, but the new conses are taken from TARGET.
    The result is EQ to TARGET, but contains only those conses
    needed to hold X's elements.  The tail of unused conses
    from TARGET is returned as a second value; new conses are
    allocated if TARGET supplies an insufficient number of conses.
  
  make-string-output-stream &optional string
    Like the current MAKE-STRING-OUTPUT-STREAM, except if STRING
    is provided, it must be a string with a fill pointer.  Output
    to the resulting stream is incrementally appended to STRING,
    as if using VECTOR-PUSH-EXTEND if the string is adjustable,
    and otherwise using VECTOR-PUSH.
  
  read-line-into-string string &optional input-stream eof-error-p
			eof-value recursive-p
    Like READ-LINE, but reads into STRING.  STRING must be a string
    with a fill pointer.  The result of READ-LINE-INTO-STRING is
    incrementally appended to STRING, as if using VECTOR-PUSH-EXTEND
    if the string is adjustable,and otherwise using VECTOR-PUSH.

In order to facilitate recycling alists and trees, the following two
functions are proposed.

  flatten-tree tree
    FLATTEN-TREE would take a tree and return a linear list made
    of all the conses in the tree, suitable for recycling via a
    :RECYLE argument.

  flatten-alist alist
    FLATTEN-ALIST would take an alist and return a linear list
    made of all the conses that would be copied by COPY-ALIST,
    suitable for recycling via a :RECYLE argument.

Rationale:

It is sometimes better to use a more complex programming construct for
sake of efficiency than to use a less complex, more expensive one.
Providing a functions that do not require dynamic storage allocation
provides a means for writing programs that must avoid storage allocation
while running as much as possible.  Excessive storage allocation
(sometimes expressed as "Lisp garbage collects too often") is one of
Lisp's most widely publicized faults.

Current practice:

Similar functionality is provided for bit-vectors, as specified in CLtL
17.4.  A related capability is provided in the destructive versions of
some of the functions extended above (e.g., REMOVE vs. DELETE).

When functionality similar to this is required, users must "roll their
own".

[from Moon] Symbolics Common Lisp already has MAP-INTO.

Cost to Implementors:

The cost of implementation of these extra sequence, list, and string
function arguments is significant, in that existing code to implement
these functions must be changed to use storage passed in as an argument
by the user.

Cost to Users:

No cost for existing programs, this change is upwards compatible.  Users
may mis-use the new keyword arguments and end up with buggy code,
similar to the problems encountered when using C library functions that
re-use data structures.

Cost of non-adoption:

Programmers will continue to "roll their own" non-standard storage
re-using code.  Others will not go to this effort, but will write
programs that require much garbage collection.  Lisp will continue to
suffer from a handicap in promoting efficient programs when compared to
C.

Benefits:

Those programmers choosing to invest the extra effort needed to
correctly use such facilities can do so with less overhead than
previously required, and will see performance improvement.

Esthetics:

Neutral.  This proposal is syntactically consistent with the existing
keyword arguments to sequence, list, and string functions.  However, it
adds to the plethora of keyword arguments already present for many of
these functions.  Stylistically, it provides stronger support for the
programming style embodied by the use of the "destructive" versions of
many Common Lisp functions.

Discussion:

My experience in several commercial Lisp applications is that avoiding
storage allocation by using programming techniques such as this may be
critical to the success of a project.  The current sequence, list, and
string functions encourage an "expensive", albeit easy to use,
programming style that invites the creation of programs whose
performance suffers greatly in comparison to a C program written to
solve the same problem.  This applies particularly to string-hcaking
programs written using Common Lisp versus those written using the
standard string library for C.

A related issue: would adoption of these arguments eliminate the need
for parallel destructive versions for some of the affected functions?
(E.g., does REMOVE with a :MODIFY argument eliminate the need for
DELETE.)

Pierson supports the general ideas of an earlier version of this
proposal, but believes the proposal itself should be in the form that
would appear in a revised manual.

Several people responded in the negative to Fahlmans suggestion that
perhaps the new LOOP facility would relieve the need for these
extensions.  Fahlman is ready to support the proposal in principle if
certain details are fixed up.

Moon does not like returning unused conses as a second value as proposed
in previous versions of this proposal.  He also does not believe that
UNION, INTERSECTION, SET-DIFFERENCE, and SET-EXCLUSIVE-OR derive much
benfit from previously suggested extensions similar to those in this
proposal.  Neither should the functions SUBSEQ, COPY-SEQ, COPY-LIST, and
BUTLAST be modified, because the functionality is already available from
REPLACE, he claims.  He thought :TARGET should be changed to :OVERWRITE.

All of the above comments were made prior to version three of this
proposal.

MAPCAR and friends might be considered candidates for modification in
this proposal.  However, these mapping functions likely will be made
obsolete by LOOP if they are not already obsolete.


∂07-Sep-88  0219	CL-Cleanup-mailer 	discussion of Moon's comments re: ELIMINATE-FORCED-CONSING   
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 7 Sep 88  02:18:51 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
	id AA13742; Tue, 6 Sep 88 23:56:28 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
	id AA12484; Tue, 6 Sep 88 15:38:22 PDT
Date: Tue, 6 Sep 88 15:38:22 PDT
Message-Id: <8809062238.AA12484@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: discussion of Moon's comments re: ELIMINATE-FORCED-CONSING


!   I think the name :OVERWRITE would be more consistent with the
!   rest of Common Lisp than the name :TARGET.  It makes it clearer
!   that this argument is storage to be overwritten with new
!   information.

The problem is that the :TARGET argument is used for two different
purposes.  One is to fill a subsequence of a useful sequence, as in
filling in a substring of a longer string.  The other is to recycle
storage (i.e., an obsolete sequence that would otherwise be garbage)
without regard for the previous contents of that storage (except to
insure type compatibility).  It seems useful to regard these as
different operations; although, except for the list case, they often can
be conveniently denoted using the same basic syntax, as in my proposal.
Some of the modifications you suggest to the proposal seem to stem from
assuming one or the other of these uses, disregarding the other.  Thus I
believe I should modify the proposal to have two different keywords that
can reflect the intention of a programmer.

For sake of argument, let's call the two keyword arguments :MODIFY (for
changing a subsequence of a useful sequence) and :RECYCLE (for recycling
a sequence that is otherwise garbage).  A list passed as a :RECYCLE
argument is re-used as a linear list made of conses to recycle.  CAR's
are ignored (i.e., it is not a tree of conses to re-use!).

!   When you say
!       (1) The target sequence must accomodate elements of the
!       type(s) in the source sequence.
!   I believe this is wrong.  It should refer to the type of the
!   elements of the -result- of the function, not the source.

I believe this is correct.  My proposal will be altered to reflect this.

!   I don't understand the need for the :TARGET-FROM-END feature and
!   I think you should drop it from the proposal.

:TARGET-FROM-END specifies that the target sequence is filled from the
end with the result of the operation.  This allows the elements of the
result sequence to be placed into the target argument in reverse order.
This is not essential to the proposal.  It was included for sake of
symetry, in some sense of the word, since one might expect this
capability after surveying the other keywords available.  It would
become :MODIFY-FROM-END given the distinction in usage of the target
sequence already discussed.  I'll take it out if most people think it
excessive.

!       The last cons of the target list whose CAR was filled by the
!       computation is returned as a second value.  The CDR of this cons
!       is that tail of the target list not used to accomodate the
!       sequence computation.
!
!   I think this feature is unnecessary and should be discarded.  I
!   think extra conses should simply be thrown away.  Most people
!   exploiting this non-consing feature are more likely to use vectors
!   than lists, I feel.

I do not agree that this feature will usually be limited to vectors
rather than lists.  It is, however, tied to the :MODIFY/:RECYCLE
distinction.  A new proposal will address the return values in light of
this distinction.

!   If the feature is kept, the second value should be the cdr of
!   what you propose it to be, and the result should be null-terminated
!   in the correct place; that should not be left to the caller to do.

This would prevent the use of the :TARGET argument for filling in a
sublist, since the sublist is terminated.  It also breaks symetry with
other sequence types where a subsequence of a larger-than-needed TARGET
sequence is filled.  The problem is overloading :TARGET with the
semantics of :MODIFY and :RECYCLE.  For :MODIFY semantics, you want to
return a second value which is the tail of the list that was not used,
leaving that tail linked to the head that was used.  For :RECYCLE
semantics, you want as the first value the the null-terminated head of
the list that was used, and as the second value the tail that was not
used.  The difference is whether the first list value is null terminated
or not.  In addition, for a sequence with a fill-pointer used as the
RECYLE argument, the fill-pointer would be adjusted to point after the
last sequence element inserted.  As a MODIFY argument, the fill-pointer
would remain unchanged.  [Would the fill-pointer be extended if filling
the MODIFY argument used elements after the fill-pointer?  Or would
those elements of the MODIFY sequence after the fill pointer remain
unchanged?  I prefer the former.]

I oppose any change to the proposal that causes excess conses to be
thrown away.

!   Another idea would be to allow the user to pass in a function that is
!   called whenever storage is to be allocated.  Perhaps it would take two
!   arguments and the default would be #'APPLY.  The first argument would
!   be one of #'CONS, #'MAKE-LIST, or #'MAKE-ARRAY, the second argument
!   would be a list of arguments with dynamic extent.  I'm not real fond
!   of this idea, but it does provide maximum generality.

This provides maximum generality, but requires function call overhead
that might be avoided if storage is passed directly.  One might achieve
the same effect by supporting storage-freeing operations so Lisp could
keep a "free list" of recyclable storage to re-use rather than
allocating new storage.  Of course this leads to the desire to preserve
storage locality, including free-lists, thus a discussion of storage
allocation areas with free-lists per area, etc.  I would not oppose such
a mechanism, however.

!       (4) :TARGET-START and :TARGET-END keywords are supported.
!
!   These seem useful but should be named :OVERWRITE-START and
!   :OVERWRITE-END.

Well, I'd say :MODIFY-START and :MODIFY-END now.  :RECYCLE-START and
:RECYCLE-END are redundant with the normal :START and :END argument as
:RECYCLE implies the sequence passed in is just for storage recycling.
The :RECYCLE argument should not be used to modify a subsequence of a
useful sequence; use :MODIFY instead.

!   The functions SUBSEQ, COPY-SEQ, COPY-LIST, and BUTLAST need not be
!   modified, because the functionality is already available from
!   REPLACE.

I believe the :RECYCLE argument should be supported for these.

!   The functions COPY-ALIST and COPY-TREE should not be modified,
!   because their use of storage is too complex to fit into this model
!   (they don't deal in linear sequences).

Since it is well-defined when COPY-ALIST copies a cons, and since it is
well-defined that circularities and shared substructure are NOT
preserved in COPY-TREE, I see no reason not to include a :RECYLE
argument for these functions.  While modifiying an existing alist or
tree using the :MODIFY argument is ill-defined, the use of the :RECYLE
argument as a glob of available, linear cons storage is quite useful.

It would be useful, given the semantics above, to provide functions to
"flatten" an alist or a tree.  A new proposal will address this.

!   The function ADJOIN should not be modified, because a non-consing
!   version is trivial for a user to write, and because the 
!   consumption of storage is conditional, which would complicate
!   the interface.

Again, for sake of symetry, I (mildly) disagree.  The unused conses
should be returned, which is the interface complication you mention, I
guess.  Of course, the TARGET argument should be changed to :RECYLE for
ADJOIN.

!   I don't think UNION, INTERSECTION, SET-DIFFERENCE, and                  
!   SET-EXCLUSIVE-OR should be modified, because their
!   conditional consumption of storage would complicate
!   the interface (unused storage has to be handed back to
!   the caller) and because the destructive versions that
!   already exist can solve the same problem, in my
!   experience.  (They aren't completely non-consing, but
!   they minimize consing.)  You forgot to mention SUBST,
!   but I think the same reasoning applies and SUBST
!   should not be modified.

You're correct, I forgot SUBST.  However, I believe :RECYCLE should be
supported for SUBST, UNION, INTERSECTION, SET-DIFFERENCE, and
SET-EXCLUSIVE-OR.

!   This leaves REVERSE, MERGE, REMOVE, REMOVE-IF, REMOVE-IF-NOT,
!   REMOVE-DUPLICATES, SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT,
!   STRING-TRIM, STRING-LEFT-TRIM, STRING-RIGHT-TRIM, STRING-UPCASE,
!   STRING-DOWNCASE, STRING-CAPITALIZE.  I think it's reasonable to
!   modify these in the way you suggest.  Doing just these makes for
!   a much simpler proposal that is easier to understand.

To reflect the clearer set of keywords, these would be changed to
support RECYCLE/MODIFY in my new proposal.

!   MAKE-STRING-OUTPUT-STREAM should follow the same rules as
!   WITH-OUTPUT-TO-STRING when a string is supplied, instead of
!   the different rule you suggested.  With that change to make it
!   consistent, I support what you propose.

I agree.  This was an oversight.

!   This leaves CONCATENATE, APPEND, REVAPPEND, and MAP (which              
!   you forgot, but which has been discussed in the past),
!   which take &rest arguments and therefore are a problem.  I
!   don't think the -into-subseq version is useful enough to
!   justify the extra complexity.  I also don't think the
!   extra complexity of allowing the caller to pass in too
!   many conses to APPEND and REVAPPEND and get back the
!   unused ones as a second value is justified.  In fact, I
!   think I would prefer to omit APPEND-INTO from the proposal
!   (CONCATENATE-INTO and NCONC should suffice) and therefore
!   to omit REVAPPEND-INTO also.  I support CONCATENATE-INTO
!   and MAP-INTO.

OK, I'll remove the -INTO-SUBSEQ stuff.  But I disagree that passing in
too many conses and getting the unused ones back as a second value is
too complex.  I think this is a big win that is extremely useful.

!   I'd support your proposal if you simplify it more or less along 
!   the lines I suggested.  I don't support version 2 because there
!   is too much in it.

I'll submit a modified proposal for discussion.
-- Joe Ginder

∂07-Sep-88  1155	CL-Cleanup-mailer 	ELIMINATE-FORCED-CONSING  
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 7 Sep 88  11:55:13 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU;  7 Sep 88 14:52:18 EDT
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.edu
Subject: ELIMINATE-FORCED-CONSING 
In-reply-to: Your message of Tue, 06 Sep 88 15:38:22 -0700.
             <8809062238.AA12484@trwrb.TRW.COM> 
Date: Wed, 07 Sep 88 14:52:00 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU


Through some fluke of network routing, Ginder's revised proposal reached me
before his detailed response to Moon.  When I saw the :MODIFY and :RECYCLE
arguments and the complexities involved in making the latter do what you
want, my head started spinning.  I think that this is all very confusing,
and I am strongly opposed to this proposal in its current form.  :MODIFY
and :RECYCLE are similar enough to be easily confused, but they differ in
subtle ways in their details; I never want to have to explain to a class
when you use which one.

Once I saw Ginder's other message, I realized what the problem is: I'm
happy enough to accept a :MODIFY or :OVERWRITE option in all of the
appropriate places -- I have no preference for one of these names over the
other -- but I really don't think that any of this recycling nonsense
should be muddled in with the sequence functions.  To have both :MODIFY and
:RECYCLE present, similar but different in subtle ways, is to invite
endless confusion.  If we accept just the :MODIFY part of the proposal, I
think that Moon's prescriptions -- discarding excess conses, for example,
are right.

If there really is a need for recycling of CONS cells, I would support an
explicit RECYCLE call whose argument is a list.  This would authorize (but
not require) and implementation to CDR down the list argument, setting the
CAR of each cell to NIL, and then to splice the whole thing onto a free
list of some sort; CONS would use these free cells before allocating new
ones.  Systems with epehemeral GC might not want to implement this since it
doesn't buy much and might result in worse storage locality than just
dropping the list.  Something similar could be done for arrays, structures,
etc., though that is harder to do.

In the past we always stayed away from such things, since these constructs
lead to very confusing bugs if the program is actually holding onto the
recycled structure somewhere else.  However, many programs end up creating
their own resource managers to reduce garbage-creation, and perhaps it is
time to consider adding this to the language proper.  In any case, I think
that mixing this recycling concept with the sequence functions is the wrong
move.

I would be prepared to support a version of this proposal that just
included the :MODIFY parts.

-- Scott

∂07-Sep-88  1225	CL-Cleanup-mailer 	discussion of Moon's comments re: ELIMINATE-FORCED-CONSING   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  12:25:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455682; Wed 7-Sep-88 15:22:54 EDT
Date: Wed, 7 Sep 88 15:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: discussion of Moon's comments re: ELIMINATE-FORCED-CONSING
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8809062238.AA12484@trwrb.TRW.COM>
Message-ID: <19880907192224.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 6 Sep 88 15:38:22 PDT
    From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU

    !   I'd support your proposal if you simplify it more or less along 
    !   the lines I suggested.  I don't support version 2 because there
    !   is too much in it.

    I'll submit a modified proposal for discussion.

Unfortunately the new proposal is so complicated that I'm not going to
have time to read and understand it in the near future.  I was hoping
for something a lot simpler.  If I get a chance to read it carefully
enough to comment on it, I'll send in some comments.

∂07-Sep-88  1226	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 7 Sep 88  12:26:25 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA03511; Wed, 7 Sep 88 12:25:14 PDT
Date: Wed, 7 Sep 88 12:25:14 PDT
Message-Id: <8809071925.AA03511@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS

Issue:        FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS

References:   CLtL pp 47-48, 158-159

Category:     CHANGE

Edit history: #1, 7 September 1988, Walter van Roggen


Problem description:

The current description of the specialized FUNCTION type specifier is not very
useful to program analysis tools and is not very intuitive to programmers
because the meaning of the argument type specifiers is not restrictive.

Programmers find it useful to add information about the types of the arguments
a function expects and about the type(s) that a function may return. This
information is useful both to human readers of the code as well as to type
checking programs such as compilers and cross referencers. The only apparent
(but false) way of providing this information is with the FTYPE declaration and
FUNCTION type specifier.

Furthermore, implementations may wish to provide additional optimizations based
on avoiding type checking or different methods of argument passing. These
optimizations require the same sort of information about the argument types.

However, the current definition of FUNCTION type specifiers on pages 47-48 of
CLtL states that a function such as CONS that is of type
  (FUNCTION (T T) CONS)
is also of type
  (FUNCTION (FLOAT STRING) LIST).
Unfortunately this information is not useful for the above mentioned purposes.
The problem is that the argument types aren't restrictive, so no interesting
matching of types is possible.

Another way of looking at the problem is that specialized FUNCTION type
specifiers cannot be used in a meaningful way for discrimination (as the second
arg to TYPEP, nor as the first argument to THE). Furthermore functions are
assumed not to be sufficiently self-descriptive that a specialized FUNCTION
type is possible to be known or can be constructed when a function is passed to
TYPE-OF.

Unlike all the other type declarations, which can be used for discrimination
and have an implicit effect on representation, specialized FUNCTION type
specifiers thus appear to have superfluous information.  By changing the
meaning of the argument types to convey additional descriptive information
instead of behavioral information, we can also satisfy the other needs listed
above.

This issue does not address the use of lambda-list-keywords and
argument count matching, nor the reproclamation or additional declaration
of FUNCTION types, nor having TYPEP treat specialized FUNCTION types
as if they were just the same as the atomic FUNCTION type for purposes
of discrimination.


Proposal (FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE)

For specialized FUNCTION type specifiers

  (proclaim '(ftype (function (arg0-type arg1-type ...) val-type) f))
implies
  (the val-type (f (the arg0-type ...) (the arg1-type ...) ...))

If the arguments to F are of the specified types, then the result will be of
the specified type.  If the arguments do not all match the specified types, it
is an error, and then the result is not guaranteed to be of the specified type.


Rationale:

The proposal seems most like what users expect.

Current Practice:

VAX LISP already assumes and makes use of the "restrictive" semantics. Lucid
has a RESTRICTIVE-FTYPE declaration with these semantics and ignores the
standard FTYPE declaration. Gold Hill intends to use these declarations in this
manner.  Many implementations don't make use of these declarations.  At least
several users make use of declarations assuming the new semantics.

Adoption Cost:

None, since making use of FUNCTION declarations is "optional".

Benefits:

Better type checking and more compiler optimizations should be possible.

Conversion Cost:

There may be some existing "imprecise" function declarations. However, the
natural tendency when providing these declarations is to be as "descriptive"
(i.e., restrictive but complete) as possible, both for documentation purposes
as well as for potential compiler benefits. There cannot have been any uses of
the specialized FUNCTION type for discrimination. Thus most existing uses are
probably compatible with this new definition.

Esthetics:

This is the what most programmers expect the specialized FUNCTION type to
mean, particularly those coming from other languages.

Discussion:

∂07-Sep-88  1423	CL-Cleanup-mailer 	Issue: GET-MACRO-CHARACTER-READTABLE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Sep 88  14:23:37 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 07 SEP 88 14:01:32 PDT
Date: 7 Sep 88 14:01 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: GET-MACRO-CHARACTER-READTABLE
To: cl-cleanup@sail.stanford.edu
Message-ID: <880907-140132-13143@Xerox>


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

Return-Path: <@RELAY.CS.NET:yuasa%tutics.tut.junet@UTOKYO-RELAY.CSNET>
Received: from CLI.COM ([10.8.0.62]) by Xerox.COM ; 07 SEP 88 11:54:15 PDT
Received: by CLI.COM (4.0/1); Wed, 7 Sep 88 13:41:37 CDT
Received: from relay2.cs.net by RELAY.CS.NET id ah10518; 7 Sep 88 13:12 EDT
Received: from utokyo-relay by RELAY.CS.NET id bu14361; 7 Sep 88 12:47 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
	id AA21863; Wed, 7 Sep 88 14:28:15 JST
Received: by nttlab.ntt.jp (3.2/6.2NTT.h) with TCP; Wed, 7 Sep 88 12:29:01 JST
Received: by tutics.tut.junet (ver3.3/6.2J/systemV)
        id AA23442; Wed,  7 Sep 88 12:19:46 jst
Message-Id: <8809071219.AA23442@tutics.tut.junet>
Date: Wed,  7 Sep 88 12:19:46 jst
From: Taiichi Yuasa <yuasa%tutics.tut.junet@utokyo-relay.CSNET>
To: kcl@CLI.COM
Subject: get-macro-character

KCL does not accept NIL as the readtable argument for GET-MACRO-CHARACTER
and GET-DISPATCH-MACRO-CHARACTER.  This means the only way in KCL to get
information on macro/dispatch-macro characters is to make a copy of the
standard readtable and send it to these functions.
Although CLtL does not explicitly specify these functions should accept NIL
for standard readtable, some examples in CLtL do not work in KCL.
To fix the "bug", replace the statement

	check_type_readtable(&rdtbl);

in the definition of the C functions get_macro_character and get_dispatch_
macro_character in file c/read.d with

	if (rdtbl == Cnil)
		rdtbl = standard_readtable;
	else
		check_type_readtable(&rdtbl);


This bug fix was suggested by Cesar Quiroz on this mailing list.
Thanks Cesar.

-- Taiichi




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

∂07-Sep-88  1634	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  16:34:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455890; Wed 7-Sep-88 19:33:12 EDT
Date: Wed, 7 Sep 88 19:32 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <19880907233254.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

Here's the issue writeup that I promised months ago, but never had time
to do.  I hope it's not too late to be of any use to anyone.

Issue:         EXIT-EXTENT

References:    CATCH, THROW,
               BLOCK, RETURN, RETURN-FROM,
               TAGBODY, GO, UNWIND-PROTECT,
               Dynamic extent (CLtL p.37),
               Nested dynamic extents (CLtL p.38),
               Blocks can only be exited once (CLtL p.120),
               Catch is disestablished just before the values 
               are returned (CLtL p.139).
               Cleanup issue UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
               by this one.

Category:      CLARIFICATION

Edit history:  Version 1, 5-Sep-88, by Moon, for discussion

Problem description:

CLtL does not specify precisely when the dynamic extent (aka lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.

There are three cases of interest:
(1) Normal exit from a CATCH, BLOCK, TAGBODY, or equivalent such as PROG.
(2) Nonlocal exit from the target of a THROW or RETURN.
(3) Abandonment of an exit passed over by THROW, RETURN, or GO.
The terms "normal exit", "target", and "passed over" will be used with
these meanings for the remainder of the discussion.

CLtL is unambiguous about case 1.  In cases 2 and 3, the extent could
end anywhere from the time the THROW, RETURN, or GO commences, until the
time the transfer of control is completed.  In case 2, it is clear that
the extent of the target ends before the transfer of control completes,
since a block cannot be exited twice, but it is not made clear whether
the extent ends before or after execution of UNWIND-PROTECT cleanup
forms.  CLtL says nothing about case 3, although a note on p.38 implies
that the extent of a passed-over exit should end no later than the end
of the extent of the target exit.

Proposal (EXIT-EXTENT:MINIMAL):

The dynamic extent of an exit, whether target or passed-over, ends as
soon as the THROW, RETURN, or GO commences.  In the language of the
implementation note on p.142, the extent ends at the beginning of the
second pass.  It is an error for an UNWIND-PROTECT cleanup form executed
during a nonlocal transfer of control to attempt to use an exit whose
dynamic extent ended when the nonlocal transfer of control commenced.

This proposal is called "minimal" because it gives exits the shortest
extent consistent with CLtL.

Test Cases/Examples:

Each of the following programs is an error:

(funcall (block nil #'(lambda () (return))))		;case 1

(block nil						;case 2
  (unwind-protect (return)
    (return)))

(block a						;case 3
  (block b
    (unwind-protect (return-from a)
      (return-from b))))

(let ((a nil))						;case 1
  (tagbody t (setq a #'(lambda () (go t))))
  (funcall a))

(funcall (block nil					;case 3
	   (tagbody a (return #'(lambda () (go a))))))

(catch nil						;case 2
  (unwind-protect (throw nil t)
    (throw nil t)))

(catch 'a						;case 3
  (catch 'b
    (unwind-protect (throw 'a t)
      (throw 'b t))))

The above program is an error because the catch of b is passed over by
the first throw, hence portable programs must assume its dynamic extent
is terminated.  The catch is not yet disestablished and therefore it
is the target of the second throw.

The following program is not an error.  It returns 10.  The inner
catch of a is passed over, but this is not case 3 because that catch
is disestablished before the throw to a is executed.

(catch 'a
  (catch 'b
    (unwind-protect (1+ (catch 'a (throw 'b 1)))
      (throw 'a 10))))

Rationale:

Giving exits the shortest extent consistent with CLtL maximizes freedom
for implementations and takes away no useful capability from users.

Current practice:

Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target exit at the moment the values are returned, and end the
extent of a passed-over exit at the moment the THROW, RETURN, or GO
commences.  This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control.  Genera signals an error if an
attempt is made to use an exit that has been passed over.

I have not surveyed any other implementations.

Cost to Implementors:

There is no cost to implementors, as no currently valid implementation
will be made invalid by this proposal.

Cost to Users:

There is no cost to users, as no existing portable program is made invalid
by this proposal.  This proposal will clarify why some existing nonportable
programs are nonportable, which could be viewed as either a cost or a benefit
to users.

Cost of non-adoption:

The semantics of exits will remain ambiguous.

Benefits:

Common Lisp will be more precisely defined, and the precise definition will
be consistent with current practice in a way that has no cost for implementors
nor for users.

Esthetics:

Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.

Discussion:

The goal of this proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation.  An alternative proposal
would define the extent of an exit to end at the last moment possible
within some particular reference implementation.  That alternative would
have a cost to implementors whose implementation is not identical to the
reference implementation.  Another alternative proposal would duck the
issue by outlawing all nonlocal exits from UNWIND-PROTECT cleanup forms.
That alternative would have a substantial cost to some users.

Scheme is cleaner: it ducks this issue by specifying that the extent
of an exit never ends.

CLtL never says in what dynamic environment cleanup forms of
UNWIND-PROTECT are executed.  The implementation note on p.142 may have
been intended to cover this, but since it doesn't define the term
"frame" that it uses, it doesn't actually say anything.  This proposal
could be expanded to cover that issue by discussing the extent of
dynamic-extent entities other than exits, or that issue could be the
subject of a separate proposal.

∂07-Sep-88  1825	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  18:25:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455935; Wed 7-Sep-88 21:23:24 EDT
Date: Wed, 7 Sep 88 21:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8809071925.AA03511@decwrl.dec.com>
Message-ID: <19880908012301.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE sounds good to me.
I have a small wording problem with it: I can't figure out what if
anything your proposal says about use of the FUNCTION type specifier
for discrimination.  The problem description and conversion cost
sections sound as if you're proposing something, but the proposal
section doesn't mention it.

∂07-Sep-88  1840	CL-Cleanup-mailer 	SYMBOL-MACROFLET
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  18:40:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455941; Wed 7-Sep-88 21:38:32 EDT
Date: Wed, 7 Sep 88 21:38 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROFLET
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: Masinter.pa@xerox.com, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <7296.8809051651@aiai.ed.ac.uk>
Message-ID: <19880908013813.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Mon, 5 Sep 88 17:51:08 BST
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

    5. Symbol-macro-flet: SYMBOL-MACRO-LET lets me have something that
    looks like a variable but is really some expression.  It might seem
    that MACROLET does the same for function names, but it doesn't.
    MACROLET applies to entire calls, not just the name.  This suggests
    that SYMBOL-MACRO-LET should have a companion, SYMBOL-MACRO-FLET.

This is Zetalisp's "lambda macros", also available in Symbolics Common
Lisp.  They're called that because they let users write new things that
behave like LAMBDA.  They're pretty useful in a few specialized
circumstances.  You would of course want both a global (DEFMACRO)
version and a local (MACROLET) version.  In SCL, the former is named
DEFLAMBDA-MACRO but the latter doesn't exist.

I don't strongly support adding this feature to Common Lisp, since it's
pretty specialized, but I certainly wouldn't oppose it.  It would
make the language more useful and complete.

    BTW, what is the meaning of (MACROLET ((F () 'A)) #'F)?

The same as the meaning of (DEFMACRO F ...) #'F except for the
scoping of F.  The way this is explained in CLtL is extremely
confusing, but I think it should be an error.  Point 4 of the
pending cleanup issue FUNCTION-TYPE makes it clearly an error.

    In KCL and Lucid, it seems to be the same as #'F without the MACROLET

That's surely not desirable.

∂07-Sep-88  1843	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  18:43:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455943; Wed 7-Sep-88 21:41:50 EDT
Date: Wed, 7 Sep 88 21:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 1)
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880904-155622-8877@Xerox>
Message-ID: <19880908014133.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 4 Sep 88 15:56 PDT
    From: Masinter.pa@Xerox.COM

    This reminds me a little of the PATHNAME issue. I think that CLOSE is only valid
    for streams that PATHNAME was valid for

Certainly not.  Suppose I have a stream that represents a network connection
to another computer.  This stream doesn't go to a file, so it has no pathname,
but it certainly has a well-defined concept of closing.

    What does it mean to CLOSE a composite stream ( broadcast two-way synonym
    concatenated) ? The choices I can think of are:
    a) no effect
    b) implementation dependent (ugh)
    c) closes constituent streams
    d) the composite stream is "closed" (no I/O operations allowed) but
	    the constituents are not.

I prefer c.

    What does it mean to close a constructed stream (e.g., STRING)? 
    a) no effect
    b) implementation dependent (ugh)
    c) the constructed stream is "closed" (no I/O operations allowed).

I prefer a or c.

    I think the following operations should be as valid after a CLOSE as before
    (i.e., they're valid after the close only if they were valid before):

    STREAMP, INPUT-STREAM-P, OUTPUT-STREAM-P, TRUENAME, PATHNAME. (In fact, there
    are some operating systems where you can *only* get TRUENAME on a closed stream,
    since the name isn't true until the stream has been closed.)

Certainly.

    Note that the issues STREAM-CAPABILITIES, STREAM-INFO, and  STREAM-CLASS-ACCESS
    add functions that take streams.

∂07-Sep-88  1853	CL-Cleanup-mailer 	Issue: LAMBDA-FORM (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  18:53:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455948; Wed 7-Sep-88 21:52:15 EDT
Date: Wed, 7 Sep 88 21:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-FORM (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880622180746.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880908015159.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

I favor LAMBDA-FORM:NEW-MACRO.  Note the message I am replying
to was mailed June 22.

∂07-Sep-88  1911	CL-Cleanup-mailer 	ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  19:10:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455952; Wed 7-Sep-88 22:06:19 EDT
Date: Wed, 7 Sep 88 22:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
To: Skona Brittain <skona%csilvax@hub.ucsb.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU, SKONA@csilvax.ucsb
In-Reply-To: The message of 26 Jul 88 19:50 EDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Message-ID: <19880908020559.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

I favor DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR.

∂07-Sep-88  1913	CL-Cleanup-mailer 	[Masinter.pa: Re: questions]   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  19:13:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455955; Wed 7-Sep-88 22:11:19 EDT
Date: Wed, 7 Sep 88 22:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [Masinter.pa: Re: questions]
To: Masinter.pa@Xerox.COM, chapman%aitg.DEC@decwrl.dec.com
cc: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <880721-082056-3692@Xerox>
Message-ID: <19880908021100.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 21 Jul 88 08:20 PDT
    From: Masinter.pa@Xerox.COM
    In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 19 Jul 88 13:55

	On page 354, "When the @xlisp printer types out the name of a
	special character, it uses the same table as the @f[#\] reader;
	therefore any character name you see typed out is acceptable as
	input (in that implementation).  Standard names are always
	preferred over non-standard names for printing."
	I'd like to change the last sentence to read "... are required
	over non-...".  Do you see a problem with that?

    Well, I thought preferred was put there for a reason, and I can imagine
    situations where a short-name might be preferred (the case I have in mind is
    NewLine. If you're running on a system that talks both to cr and lf based file
    systems, you might want to emphasize #\cr #\lf vs #\newline.) 

Symbolics Genera is an example of exactly such a system.  Our user interface
standards require us to print #\Return rather than #\Newline for this character.

In general Common Lisp is weak on portability of the output of the PRINT function.
Adding a new feature to produce output from one implementation that is guaranteed
to be readable by all other implementations might be a good idea, but I think
it raises a lot more issues than just the names-of-characters issue.

∂07-Sep-88  1918	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  19:18:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455961; Wed 7-Sep-88 22:17:37 EDT
Date: Wed, 7 Sep 88 22:17 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880721134308.5.KMP@PEWEE.SCRC.Symbolics.COM>
Message-ID: <19880908021721.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

I am in favor of PATHNAME-WILD:NEW-FUNCTION with one change.
The function name should be PATHNAME-WILD-P rather than WILD-PATHNAME-P;
I think that's more consistent with the rest of Common Lisp.

∂07-Sep-88  1923	CL-Cleanup-mailer 	Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  19:23:23 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455964; Wed 7-Sep-88 22:22:20 EDT
Date: Wed, 7 Sep 88 22:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880627153746.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880908022204.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

I favor PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.  It's interesting to note
that the rationale quoted from the Colander editor is weak and confused,
but the rationale in Kent's proposal (which is actually in the problem
description section) makes a lot more sense.  The problem isn't file
systems that don't have types at all, but file systems that have types
for some pathnames but not for other pathnames, for example Unix.

I suggest that the proposal be extended to allow :UNSPECIFIC in the
version, directory, device, and host fields as well.  The only field
that should not allow :UNSPECIFIC is the name field.

∂07-Sep-88  1935	CL-Cleanup-mailer 	Issue: PATHNAME-CANONICAL-TYPE (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  19:35:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455967; Wed 7-Sep-88 22:34:32 EDT
Date: Wed, 7 Sep 88 22:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880707143558.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880908023415.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

I would favor PATHNAME-CANONICAL-TYPE:NEW-CONCEPT if some small
modifications were made, as follows:

  (PATHNAME-CANONICAL-TYPE (MAKE-PATHNAME :TYPE :LISP)) => :LISP
  [This information may be explicitly represented as an additional slot, or
  computed on demand using a lookup table, as the implementor prefers.]

I'm not sure what your bracketed comment means, but the
important example is
  (PATHNAME-CANONICAL-TYPE (PATHNAME "foo.lisp")) => :LISP
where of course the string is implementation-dependent.  That is,
PATHNAME-CANONICAL-TYPE must produce a canonical type even when the
pathname was not constructed from a canonical type, but instead came
from user typein, the TRUENAME function, the DIRECTORY function,
or some similar source, when the pathname's type is one that a
canonical type maps into.

It would be good to have a facility for users (in addition to
implementations) to extend the set of canonical type names, since users
may well have their own types of files.  In Genera this is named
FS:DEFINE-CANONICAL-TYPE.  The difficulty is that in any system that
supports multiple file systems, FS:DEFINE-CANONICAL-TYPE has to be
complex enough to allow specification of separate mappings for each file
system, which requires a way to name file system types, but maybe that
would be too complex for some people's taste.

  Define the following standard types:
	:LISP		``Lisp'' (source) file
	:BIN		``Compiled Lisp'' (object) file
  Permit implementations to extend the set of canonical type names.

All the comments I saw were opposed to :BIN, and I oppose it too.  In
fact I am opposed to any standardized name for this canonical type,
primarily because this ought to vary based on various
implementation-dependent parameters.  For example, in Genera it varies
depending on the processor type.  I believe that Common Lisp should
standardize only the name of a variable whose value is the canonical
type for the output of COMPILE-FILE.  In Genera this variable is named
SI:*DEFAULT-BINARY-FILE-TYPE*, a really lousy name.  How about
calling it *COMPILE-FILE-OUTPUT-TYPE*?

∂07-Sep-88  1942	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  19:42:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455970; Wed 7-Sep-88 22:40:16 EDT
Date: Wed, 7 Sep 88 22:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
To: Sandra J Loosemore <sandra%cdr@cs.utah.edu>, Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8807221702.AA02408@cdr.utah.edu>
Message-ID: <19880908023959.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 22 Jul 88 11:02:08 MDT
    From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)

    Of the options presented for this issue, I prefer
    PATHNAME-SYNTAX-ERROR-TIME:PATHNAME-CREATION.  The NAMESTRING-COERCION
    option seems like it is really the wrong time, and I would rather not
    leave it EXPLICITLY-VAGUE.

I favor PATHNAME-SYNTAX-ERROR-TIME:PATHNAME-CREATION also.

    However, I would really like to see something completely different --
    namely adding a keyword argument to TRUENAME to allow it to be used
    for explicit syntax checking of filenames without signalling an error
    if the file doesn't exist.  Functions such as OPEN and the ones in
    sections 23.3, 23.4, and 23.5 that actually pass pathnames to the host
    file system would be required to (implictly or explicitly) perform the
    same checking. 

    This would also solve a problem I brought up some time ago, that I was
    having with Lucid Lisp under VMS.  I had defined a logical name like
    LISP$LIBRARY that expanded into something that included a directory
    specifier in its expansion, like disk$login:[loosemore.lisp.library].
    However, I was getting things like

	(namestring (merge-pathnames 
			(pathname "[loosemore]foo.bar")
			(pathname "lisp$library:")))

    =>  "lisp$library:[loosemore]foo.bar"

    which the file system naturally barfed on when I tried to open the
    file.  The problem was that Lucid's PATHNAME function was treating the
    logical name like a device specification instead of expanding it.
    TRUENAME would have expanded the logical name for me, but since
    LISP$LIBRARY was not a complete pathname for an existing file, it
    would also have signalled an error.

I know of no Common Lisp implementation for VMS that doesn't have this
problem.  It's a strange thing about VMS that foo: sometimes implies
a directory and sometimes doesn't, and there's no syntactic way to tell.

I think your suggested extension to TRUENAME is a reasonable way to
cope with this oddity of VMS, and perhaps similar oddities of other
operating systems (although I can't think of any right now).  How about
writing it up as a proposal?

∂07-Sep-88  1956	CL-Cleanup-mailer 	Issue: PROCLAIM-SCOPE (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  19:56:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455983; Wed 7-Sep-88 22:52:31 EDT
Date: Wed, 7 Sep 88 22:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-SCOPE (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880831192150.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880908025215.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

This is too complicated for me.  I think it's better to do nothing
until/unless the compiler committee comes up with a better framework
in which to deal with this.

∂07-Sep-88  2005	CL-Cleanup-mailer 	symbol-macrolet-semantics, symbol-macrolet-utility 
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 7 Sep 88  20:05:22 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA07394; Wed, 7 Sep 88 23:05:14 EDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456000; Wed 7-Sep-88 23:03:21 EDT
Date: Wed, 7 Sep 88 23:03 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: symbol-macrolet-semantics, symbol-macrolet-utility
To: Gregor.pa@Xerox.COM, Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>,
        Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
        Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>,
        Barry Margolin <barmar@Think.COM>,
        cl-cleanup%sail.stanford.edu@MULTIMAX.ARPA
Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU,
        Jeffrey Piazza <"piazza%lisp.DEC@decwrl.dec.com"@MULTIMAX.ARPA>
In-Reply-To: <871123130424.8.GREGOR@SPIFF.parc.xerox.com>,
             <8806222146.AA21530@decwrl.dec.com>,
             <8806281758.AA10391@decwrl.dec.com>,
             <880628165306.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
             <8806291818.AA11107@mist.UUCP>,
             <19880629204455.4.GREGOR@PORTNOY.parc.xerox.com>,
             <19880729021542.8.BARMAR@OCCAM.THINK.COM>,
             <8807292109.AA03546@decwrl.dec.com>,
             <880801135717.1.KMP@PEWEE.SCRC.Symbolics.COM>
Message-Id: <19880908030301.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-Fold: No

I thought it was already well-established that symbol-macrolet has to
be a special form, not a macro, and has to affect the behavior of
macroexpand.  10 months ago I argued that symbol-macrolet didn't
have to be a special form, but I was quite wrong.

I favor the proposal SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM except
for the part about forbidding use of symbol macros with SETQ
(and macros such as MULTIPLE-VALUE-SETQ and PSETQ that presumably
expand into SETQ), which I think is an unnecessary incompatible
change.

∂07-Sep-88  2004	Common-Lisp-Object-System-mailer 	symbol-macrolet-semantics, symbol-macrolet-utility 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  20:04:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456000; Wed 7-Sep-88 23:03:21 EDT
Date: Wed, 7 Sep 88 23:03 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: symbol-macrolet-semantics, symbol-macrolet-utility
To: Gregor.pa@Xerox.COM, Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>,
    Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>,
    Barry Margolin <barmar@Think.COM>, cl-cleanup%sail.stanford.edu@MULTIMAX.ARPA
cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU,
    Jeffrey Piazza <"piazza%lisp.DEC@decwrl.dec.com"@MULTIMAX.ARPA>
In-Reply-To: <871123130424.8.GREGOR@SPIFF.parc.xerox.com>,
             <8806222146.AA21530@decwrl.dec.com>,
             <8806281758.AA10391@decwrl.dec.com>,
             <880628165306.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
             <8806291818.AA11107@mist.UUCP>,
             <19880629204455.4.GREGOR@PORTNOY.parc.xerox.com>,
             <19880729021542.8.BARMAR@OCCAM.THINK.COM>,
             <8807292109.AA03546@decwrl.dec.com>,
             <880801135717.1.KMP@PEWEE.SCRC.Symbolics.COM>
Message-ID: <19880908030301.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

I thought it was already well-established that symbol-macrolet has to
be a special form, not a macro, and has to affect the behavior of
macroexpand.  10 months ago I argued that symbol-macrolet didn't
have to be a special form, but I was quite wrong.

I favor the proposal SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM except
for the part about forbidding use of symbol macros with SETQ
(and macros such as MULTIPLE-VALUE-SETQ and PSETQ that presumably
expand into SETQ), which I think is an unnecessary incompatible
change.

∂07-Sep-88  2027	CL-Cleanup-mailer 	SUBTYPEP-TOO-VAGUE, version 2  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88  20:27:26 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456024; Wed 7-Sep-88 23:26:17 EDT
Date: Wed, 7 Sep 88 23:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SUBTYPEP-TOO-VAGUE, version 2
To: Sandra J Loosemore <sandra%cdr@cs.utah.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8807192041.AA00292@cdr.utah.edu>
Message-ID: <19880908032600.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

I am mostly in favor of SUBTYPEP-TOO-VAGUE:CLARIFY, but have a few
suggestions:

    (1) Clarify that SUBTYPEP is allowed to return a second value of NIL
    only when either of the type specifiers involves the SATISFIES, MEMBER,
    NOT, AND, OR, the list form of FUNCTION, or VALUES type specifiers.

VALUES and the list form of FUNCTION are not valid arguments to SUBTYPEP
(p.72 says the arguments to SUBTYPEP have to be valid for TYPEP, p.47 says
the list form of FUNCTION is invalid for TYPEP, p.48 says VALUES isn't
really a type-specifer [sic] at all).  So you can strike those two from
the list.

I'm a little unhappy about excluding MEMBER.  I think you should exclude
MEMBER only when it's the second argument and the first argument is not
MEMBER.  MEMBER as the first argument is a useful and easy to compute
case: it's just the conjunction of a bunch of calls to TYPEP.

I think if an implementation defines a new type with a name not in CLtL,
the implementation should be permitted to add that type to the list of
types that SUBTYPEP doesn't understand.

The behavior of SUBTYPEP on types defined by DEFSTRUCT and DEFCLASS
should be fully specified.  Require it to be the obvious behavior.

    A related issue is clarifying what kinds of type specifiers must be
    recognized by functions such as MAKE-SEQUENCE and COERCE.  For example,
    HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
    sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
    recognize it to be a subtype of SEQUENCE.  Should this proposal be
    extended to deal with these issues, or is another proposal in order?

I think it's likely to be complex enough that it needs to be another
proposal.  Perhaps acceptance of this proposal will make that one easier
to write, since you can define the behavior in terms of SUBTYPEP.

    Do the rules for comparing the various type specifiers (such as ARRAY)
    need to be spelled out in detail, or are they obvious?

The former.  Fortunately the only difficult cases are COMPLEX, ARRAY and
its subtypes, and numerical ranges.  Just to make matters worse, I
believe there is a proposal on the table to change the ARRAY rules.  I
forget the issue name.

If you don't think numerical ranges are non-obvious, what is

  (subtypep '(single-float 0.0 (1.0))
	    `(single-float 0.0 ,(- 1.0 single-float-epsilon)))

SCL returns NIL T, which is wrong since these two type specifiers
denote identical finite sets.  Once you think you know the answer to that,
translate the example into rationals, replacing (- 1.0 single-float-epsilon)
with a rational that is so close to 1 that any rational that was
closer could not be represented in the implementation because you
would run out of memory!  I think the answer to that is that for floats
there is a concept of the next value, and hence a translation from
exclusive to inclusive ranges, but for non-integer rationals there is not.
I can't predict the mathematical implications of this, though.

∂07-Sep-88  2241	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS  
To:   CL-Cleanup@SAIL.Stanford.EDU    
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>

I have a minor nit to pick with the writeup for this issue. It says:

``Adoption Cost:

None, since making use of FUNCTION declarations is "optional".''

This isn't true because for us it means hooking up the RESTRICTIVE-FTYPE
mechanism to the FTYPE declaration. I object to the reasoning that
says that because making use of something (by implementations, I presume)
is optional, there is no adoption cost for any changes to it. For example,
making use of any declarations but SPECIAL is optional, so any incompatible
change to those type declarations would be a no-cost-for-adoption change.

Let's say that the cost of adoption is insignificant becaue the only two
implementations that do something with FTYPE declarations can be easily
changed to conform.

An alternative worth considering is to say that

  (proclaim '(ftype (function (type1 ... typen) val-type) f))

means:

if arg1,...,argn are of types type1,...,typen, then

(f arg1 ... argn)

is of type val-type.

This provides a means of describing polymorphic functions and
with some added verbiage to obtain even stricter interpretation.
The conditional is impossible to state in a useful way otherwise,
and the polymorphic form has some use for CLOS generic functions
and also arithmetic functions.

			-rpg-

∂08-Sep-88  1143	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Sep 88  11:43:41 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456357; Thu 8-Sep-88 14:42:06 EDT
Date: Thu, 8 Sep 88 14:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880908021721.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Supersedes: <880908144035.1.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <880908144147.2.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Wed, 7 Sep 88 22:17 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    I am in favor of PATHNAME-WILD:NEW-FUNCTION with one change.
    The function name should be PATHNAME-WILD-P rather than WILD-PATHNAME-P;
    I think that's more consistent with the rest of Common Lisp.

I chose modifier-noun-P because of INPUT-STREAM-P, OUTPUT-STREAM-P, 
ADJUSTABLE-ARRAY-P, BOTH-CASE-P, LOWER-CASE-P, UPPER-CASE-P,
ALPHA-CHAR-P, DIGIT-CHAR-P, GRAPHIC-CHAR-P, STANDARD-CHAR-P and
SPECIAL-FORM-P.

Only ARRAY-IN-BOUNDS-P appears not to fit into this pattern, and
arguably because the embedded modifier is a prepositional phrase
and not a simple adjective.

I'm ignoring COMPILED-FUNCTION-P, RANDOM-STATE-P, HASH-TABLE-P,
SIMPLE-VECTOR-P, BIT-VECTOR-P, SIMPLE-BIT-VECTOR-P, SIMPLE-STRING-P,
and STRING-CHAR-P even though they would support my case because
they are really more a hyphenated-type with "-P" appended than
something with three morphemes.

Am I missing something or doesn't this making a compelling case
that WILD-PATHNAME-P is a better name?

∂08-Sep-88  1143	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Sep 88  11:43:42 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456355; Thu 8-Sep-88 14:40:59 EDT
Date: Thu, 8 Sep 88 14:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880908021721.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880908144035.1.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Wed, 7 Sep 88 22:17 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    I am in favor of PATHNAME-WILD:NEW-FUNCTION with one change.
    The function name should be PATHNAME-WILD-P rather than WILD-PATHNAME-P;
    I think that's more consistent with the rest of Common Lisp.

I chose modifier-noun-P because of INPUT-STREAM-P, OUTPUT-STREAM-P, 
ADJUSTABLE-ARRAY-P, BOTH-CASE-P, LOWER-CASE-P, UPPER-CASE-P,
ALPHA-CHAR-P, DIGIT-CHAR-P, GRAPHIC-CHAR-P, STANDARD-CHAR-P,
SPECIAL-FORM-P, and YES-OR-NO-P.

Only ARRAY-IN-BOUNDS-P appears not to fit into this pattern, and
arguably because the embedded modifier is a prepositional phrase
and not a simple adjective.

I'm ignoring COMPILED-FUNCTION-P, RANDOM-STATE-P, HASH-TABLE-P,
SIMPLE-VECTOR-P, BIT-VECTOR-P, SIMPLE-BIT-VECTOR-P, SIMPLE-STRING-P,
and STRING-CHAR-P even though they would support my case because
they are really more a hyphenated-type with "-P" appended than
something with three morphemes.

Am I missing something or doesn't this making a compelling case
that WILD-PATHNAME-P is a better name?

∂08-Sep-88  1147	CL-Cleanup-mailer 	Issue: PROCLAIM-SCOPE (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Sep 88  11:47:01 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 456361; 8 Sep 88 14:46:09 EDT
Date: Thu, 8 Sep 88 14:45 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-SCOPE (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880908025215.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880908144549.3.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Wed, 7 Sep 88 22:52 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    This is too complicated for me.  I think it's better to do nothing
    until/unless the compiler committee comes up with a better framework
    in which to deal with this.

This is a reasonable position. Fyi, I do not plan to push this issue
unless someone else gets on the bandwagon with me. I did think it
important to raise it, though, and I think it should at least be one
of the items mentioned in the new manual's list of "things that should
be expected to vary between implementations".

∂08-Sep-88  1254	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Sep 88  12:53:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456425; Thu 8-Sep-88 15:52:20 EDT
Date: Thu, 8 Sep 88 15:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880908144147.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880908195203.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 8 Sep 88 14:41 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Wed, 7 Sep 88 22:17 EDT
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	I am in favor of PATHNAME-WILD:NEW-FUNCTION with one change.
	The function name should be PATHNAME-WILD-P rather than WILD-PATHNAME-P;
	I think that's more consistent with the rest of Common Lisp.

    I chose modifier-noun-P because of INPUT-STREAM-P, OUTPUT-STREAM-P....
    Am I missing something or doesn't this making a compelling case
    that WILD-PATHNAME-P is a better name?

To me PATHNAME-WILD-P is analogous to PATHNAME-DIRECTORY.  It sounds
like you are thinking of "wild pathname" as a data type whereas I am
thinking of "wildness" as a conceptual slot of a pathname.  CL is
sufficiently inconsistent that we can both find justification.  Neither
case is compelling and I don't have a strong opinion, although I still
lean to my original position.

∂08-Sep-88  1346	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 1)    
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 8 Sep 88  13:46:41 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 280437; Thu 8-Sep-88 16:06:49 EDT
Date: Thu, 8 Sep 88 16:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19880908195203.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880908160726.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

Indeed, just as most people probably think of INPUT-STREAM-P as
partitioning types (rather than accessing a slot), I think the
same of PATHNAME-WILD-P.

I don't have strong moral opposition to positioning it as
a conceptual slot, but then I'd want to call it PATHNAME-WILD
rather than PATHNAME-WILD-P. (I'd also wonder why there was
no :WILD or :WILD-P argument to MAKE-PATHNAME, and I might make
some really awful proposal to fix that... :-)

So I'm gonna leave it alone (unless there's a lot of other
opposition).

∂08-Sep-88  1634	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Sep 88  16:34:05 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 SEP 88 15:03:14 PDT
Date: 8 Sep 88 15:03 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-WILD (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Thu, 8 Sep 88 16:07 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880908-150314-1255@Xerox>

Why don't you add to the discussion something like

"We considered the name PATHNAME-WILD-P instead, which is favored by some
members of the cleanup committee. Precedent for both PATHNAME-WILD-P and
WILD-PATHNAME-P (and PATHNAME-WILD) can be found in Common Lisp."

∂12-Sep-88  1147	CL-Cleanup-mailer 	Issue: DESCRIBE-INTERACTIVE (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88  11:47:38 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 457741; Mon 12-Sep-88 14:46:44 EDT
Date: Mon, 12 Sep 88 14:45 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESCRIBE-INTERACTIVE (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880912144559.0.KMP@GRYPHON.SCRC.Symbolics.COM>

Issue:        DESCRIBE-INTERACTIVE
References:   DESCRIBE (p441)
Category:     CLARIFICATION
Edit history: 12-Sep-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  DESCRIBE is not prohibited from behaving interactively. In some
  implementations it is, and in other implementations it is not.
  Users of systems in which DESCRIBE is not interactive may presume
  that it is safe to call DESCRIBE in a batch applications without
  hanging the application, which can lead to problems.

Proposal (DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE):

  Clarify that DESCRIBE is permitted (though not required) to
  require user input, and that such input should be negotiated
  through *QUERY-IO*.

  [Descriptive information would continue to go to *STANDARD-OUTPUT*.]

Test Case:

  The following kind of interaction would be permissible in
  implementations which chose to do it:

   (DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
   (SETF (GETHASH 'FOO *MY-TABLE*) 1)
   (SETF (GETHASH 'BAR *MY-TABLE*) 2)
   (SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
   (DESCRIBE *MY-TABLE*)
   #<EQ-HASH-TABLE 259> has 3 entries.
   Do you want to see its contents? (Yes or No) Yes

Rationale:

  This implements the status quo.

Current Practice:

  Symbolics Genera asks some questions interactively when describing
  some kinds of structured data structures, such as hash tables.
  Since users can define their own DESCRIBE methods and took their cue
  from the system, describing some user structures also require such
  interactions.

Cost to Implementors:

  None.

Cost to Users:

  User code which depended on DESCRIBE running without user interaction
  would have to be modified. Such code is not currently fully portable,
  however.

Cost of Non-Adoption:

  Users would not know the straight story about whether they should
  expect interaction from DESCRIBE.

Benefits:

  Implementations which don't do interactive querying in DESCRIBE only
  because their not 100% sure it's kosher would be free to do it.

Aesthetics:

  Some people might think it's not aesthetic for DESCRIBE to require user
  intervention. Not saying whether it's permissible is probably less
  aesthetic, though.

Discussion:

  Pitman thinks it's important to clarify this issue, but he isn't fussy
  about the particulars.

  This proposal is the minimal proposal for compatibility with current
  behavior. If anyone is adamant about wanting DESCRIBE not to require
  user intervention, they might want to circulate a competing proposal
  requesting an incompatible change prohibiting current behavior in some
  implementations.

∂12-Sep-88  1334	CL-Cleanup-mailer 	Issue: IN-PACKAGE-FUNCTIONALITY
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88  13:34:21 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA12724; Mon, 12 Sep 88 13:33:02 PDT
Message-Id: <8809122033.AA12724@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 16:21
To: cl-cleanup@sail.stanford.edu
Subject: Issue: IN-PACKAGE-FUNCTIONALITY

This looks OK to me.

∂12-Sep-88  1337	CL-Cleanup-mailer 	Issue: LAMBDA-FORM   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88  13:37:05 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA12854; Mon, 12 Sep 88 13:35:48 PDT
Message-Id: <8809122035.AA12854@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 16:31
To: cl-cleanup@sail.stanford.edu
Subject: Issue: LAMBDA-FORM

Ideally I'd prefer LAMBDA as a special form and changing some "redundant"
special forms to be macros.

But in the interest of minimizing not-too-consequential changes, I'll
support LAMBDA-FORM:NEW-MACRO.

∂12-Sep-88  1341	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88  13:41:49 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA13054; Mon, 12 Sep 88 13:40:33 PDT
Message-Id: <8809122040.AA13054@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 16:35
To: cl-cleanup@sail.stanford.edu
Subject: Issue: FUNCTION-COMPOSITION

This looks OK to me.

Many years ago I suggested we drop -IF-NOT and :TEST-NOT by adding
the proposed COMPLEMENT and supporting the read-macro "#~".

So (FIND-IF-NOT #'ZEROP '(0 0 3)) would be the same as
   (FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3)) would be the same as
   (FIND-IF #~ZEROP '(0 0 3))

∂12-Sep-88  1345	CL-Cleanup-mailer 	Issue: NTH-VALUE
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88  13:45:39 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA13298; Mon, 12 Sep 88 13:44:22 PDT
Message-Id: <8809122044.AA13298@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 16:06
To: cl-cleanup@sail.stanford.edu
Subject: Issue: NTH-VALUE

Although technically this proposal looks OK with me, I think it doesn't
offer increased functionality or potential efficiency.  It does offer
an easier to read (and write!) interface for getting a multiple value
out of many, but this should be easy to construct as a portable macro.

Since we have so many other proposals which to me seem much more
important, I'd prefer that we not submit this to X3J13 as a whole.

			---Walter

∂12-Sep-88  1353	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88  13:53:31 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA13944; Mon, 12 Sep 88 13:52:12 PDT
Message-Id: <8809122052.AA13944@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 16:49
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME

Yes.

I'd be in favor of requiring errors to be signalled, but this isn't too
important to me.

∂12-Sep-88  1417	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Sep 88  14:17:15 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 12 SEP 88 13:54:59 PDT
Date: 12 Sep 88 13:52 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Mon, 12 Sep 88 14:45 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880912-135459-1531@Xerox>

I think having DESCRIBE in the standard is much less useful if it is too vague.
If you want something interactive, use INSPECT.  No?


∂12-Sep-88  1418	CL-Cleanup-mailer 	Issue: BOGUS-FIXNUMS 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88  14:18:24 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA15705; Mon, 12 Sep 88 14:17:02 PDT
Message-Id: <8809122117.AA15705@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 16:39
To: cl-cleanup@sail.stanford.edu
Subject: Issue: BOGUS-FIXNUMS

Is there still a proposal here?  If so, could someone (Sandra?!) update
the proposal to address all the concerns brought out in the mail.
There's too much there for me to assimilate in one sitting.

Thanks			---Walter

PS  Actually, maybe every ought to be updating their proposals so we can
cut down on the work Larry has to do and so that we can get as many
proposals ready in time for the next meeting.

PPS  When/where is the next cleanup subcommittee meeting?  I'd prefer
Monday morning early, to avoid conflict with the editorial mtg, but
such a time might be difficult for people on west-coast time.

∂12-Sep-88  1421	CL-Cleanup-mailer 	Issue: VARIABLE-LIST-ASYMMETRY 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88  14:20:59 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA15913; Mon, 12 Sep 88 14:19:34 PDT
Message-Id: <8809122119.AA15913@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 16:47
To: cl-cleanup@sail.stanford.edu
Subject: Issue: VARIABLE-LIST-ASYMMETRY

I'll support this.  I'll bet most implementations allow LET and LET*
singleton lists, but that it's quite split for DO and DO*.

∂12-Sep-88  1424	CL-Cleanup-mailer 	issue TRUENAME-SYNTAX-ONLY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Sep 88  14:24:43 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA12089; Mon, 12 Sep 88 15:23:32 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA18137; Mon, 12 Sep 88 15:23:29 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809122123.AA18137@defun.utah.edu>
Date: Mon, 12 Sep 88 15:23:28 MDT
Subject: issue TRUENAME-SYNTAX-ONLY
To: cl-cleanup@sail.stanford.edu

Here, at Moon's suggestion, is a formal proposal on something I
brought up earlier in connection with issue PATHNAME-SYNTAX-ERROR-TIME.  
It is a separate issue since it can stand on its own regardless of which
(if any) of the proposals for PATHNAME-SYNTAX-ERROR-TIME is adopted, but
with a slight modification it could also supplant thos proposals and "fix" 
the same problem.

-Sandra


Issue:		TRUENAME-SYNTAX-ONLY
References:	CLtL p. 413-414
		Issue PATHNAME-SYNTAX-ERROR-TIME
Category:	ENHANCEMENT, CLARIFICATION
Edit History:   V1, Sandra Loosemore, 12 Sep 1988


Problem Description:

Filename syntax under VMS does not provide a syntactic distinction
between device names and logical names which may include other
pathname components.  This causes particular problems when a pathname
including a logical name is passed to MERGE-PATHNAMES, since the
implementation may or may not expand the logical name to find the
"hidden" pathname components it includes.  Although the function
TRUENAME performs file-name translation, as currently defined it can
only be used for this purpose if the pathname is a complete file
specification for an existing file, since it will signal an error
otherwise.

Other operating systems may have similar problems.  For example, some
Lisps which run under Unix (notably PSL) use shell variables or
environment variables to serve the same purpose as logical names under
VMS.


Proposal TRUENAME-SYNTAX-ONLY:ADD:

(1) Add a keyword argument :SYNTAX-ONLY to the function TRUENAME.  If
this argument is NIL or not supplied, an error is signalled if an
appropriate file cannot be located within the file systm for the given
pathname.  Otherwise, TRUENAME signals an error only if the pathname
has illegal syntax for its specified host; it may not signal an error
if the file does not exist, if the pathname is not a complete file
specification, or if an attempt to create the file would fail for some
other reason (such as a nonexistent directory).  TRUENAME applies any
file-name translations performed by the file system and returns the
"true name" of the specified file as a pathname.

(2) Clarify that functions OPEN, RENAME-FILE, DELETE-FILE, PROBE-FILE,
FILE-WRITE-DATE, FILE-AUTHOR, LOAD, and DIRECTORY perform the same
syntax-checking and file-name translation on their arguments as
TRUENAME.

(3) Clarify that coercion of a stream to a pathname (either implicitly
or by a call to the function PATHNAME) returns a pathname representing
the "true name" of the file.  However, neither implicit nor explicit
coercion of strings to pathnames causes file-name translation to be
performed.

(4) Clarify that file-name translation on pathnames is not performed
under any other circumstances except those listed above.


Rationale:

This proposal gives the user explicit control over when logical names
are expanded.  Other alternatives would be to require translation to
be performed automatically at pathname coercion time or within
MERGE-PATHNAMES.  Both of these alternatives are unsatisfactory
because correct translation of the logical name depends on the host
and may not be performed correctly on a partial pathname.


Current Practice:

Vax Lisp under VMS expands logical names by default.  (In
MERGE-PATHNAMES?  I no longer have access to this implementation.)
Lucid Common Lisp does not, and provides no mechanism for expanding
logical names.


Cost to implementors:

Minor.  VMS provides an RMS system call to perform the necessary
translation and syntax checking; this is also performed by default by
the system call which opens a file.  Implementations running under
file systems which do not support any concept of logical names need
only perform a syntax check on the pathname within TRUENAME.


Cost to users:

None.  This is a compatible change.


Benefits:

A portable mechanism for dealing with logical names is provided.


Discussion:

This proposal leaves open the possibility that syntax errors in
pathnames might also be detected at other times, such as at pathname
coercion time (see issue PATHNAME-SYNTAX-ERROR-TIME).  However, it
would also be reasonable to restrict checking for syntax errors to the
same places that file name translation is applied.
-------

∂12-Sep-88  1507	CL-Cleanup-mailer 	Issue: ROOM-DEFAULT-ARGUMENT (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88  15:07:22 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 457897; Mon 12-Sep-88 18:06:25 EDT
Date: Mon, 12 Sep 88 18:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880912180516.4.KMP@GRYPHON.SCRC.Symbolics.COM>

Issue:        ROOM-DEFAULT-ARGUMENT
References:   ROOM (p442)
Category:     ADDITION
Edit history: 12-Sep-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  Passing no argument to ROOM is not equivalent to any argument which
  can be passed. This makes data-flow from another function which wants
  to call ROOM inconvenient. Rather than simply passing a value through,
  the correct calling sequence must be selected as well. For example,
  one might have to do something like
  (CASE FLAG
    (:DEFAULT (ROOM))
    ((T NIL) (ROOM FLAG)))
  where (ROOM FLAG) would suffice

Proposal (ROOM-DEFAULT-ARGUMENT:NEW-VALUE):

  Specify that passing an argument of :DEFAULT is equivalent to passing
  no argument to ROOM.

Test Case:

  (ROOM :DEFAULT) is functionally equivalent to (ROOM).

Rationale:

  Minimal change needed to get around the stated problem.

  Allows ROOM to be describable without reference to supplied-p
  information.

Current Practice:

  Symbolics Genera defines ROOM using &REST and looks for NIL, (T), or (NIL).
  [This reduces its ability to do compile-time number-of-argument checking.]

  Some other implementations probably have a magic undocumented value
  to avoid use of a SUPPLIED-P argument.

Cost to Implementors:

  Probably it involves negligible resources to change this.
  In most implementations, the resulting code would probably look better.

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  The description of ROOM will look yucky in the emerging specification.
  The source code for ROOM will look yucky.
  [How's that for objective? -kmp]
  Error checking in some implementations may be sub-optimal.

Benefits:

  The description of ROOM in the now-being-written specification would
  be less complicated.

Aesthetics:

  This proposal would make a minor improvement in aesthetics.

Discussion:

  This is obviously a low-priority issue, but would require such little
  resources to fix that it seems worth doing.

  Pitman supports this addition.

  It's perhaps too bad that keywords like :SHORT, :MEDIUM, and :LONG
  weren't chosen instead of T and NIL, since T and NIL have a bit of a
  binary feel to them and it's hard to think of a good name for the
  default case.

∂12-Sep-88  1706	CL-Cleanup-mailer 	Issue: ROOM-DEFAULT-ARGUMENT (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88  17:03:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 457978; Mon 12-Sep-88 20:02:25 EDT
Date: Mon, 12 Sep 88 20:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880912180516.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880913000129.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

ROOM-DEFAULT-ARGUMENT:NEW-VALUE is okay, but can't we just get
rid of ROOM entirely?  I think it never should have been adopted
from Zetalisp into Common Lisp in the first place.

∂12-Sep-88  1709	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88  17:09:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 457986; Mon 12-Sep-88 20:08:10 EDT
Date: Mon, 12 Sep 88 20:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
To: Masinter.pa@Xerox.COM
cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880912-135459-1531@Xerox>
Message-ID: <19880913000720.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 12 Sep 88 13:52 PDT
    From: Masinter.pa@Xerox.COM

    I think having DESCRIBE in the standard is much less useful if it is too vague.
    If you want something interactive, use INSPECT.  No?

In spite of the name of his proposal, I think Kent was proposing to make
it (slightly) -less- vague.  Right now about all CLtL says is that
DESCRIBE prints "information" that is indented.  Since the output of
DESCRIBE cannot be useful to programs, I think it's better to allow it
to ask questions than to add a bunch of new mechanism, such as keyword
arguments to DESCRIBE, to control what is printed.  Of course a good
implementation would only ask questions when *STANDARD-OUTPUT* is an
interactive stream, if Common Lisp had a way to ask whether a stream is
interactive.

∂12-Sep-88  1727	CL-Cleanup-mailer 	Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88  17:27:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 457999; Mon 12-Sep-88 20:26:15 EDT
Date: Mon, 12 Sep 88 20:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <19880913002519.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

Issue:         HASH-TABLE-KEY-MODIFICATION

References:    CLtL page 282, page 168 (last paragraph in 10.2)

Category:      CLARIFICATION

Edit history:  Version 1, 12-Sep-88, Moon, for discussion

Problem description:

CLtL is silent about what happens if you modify a component of an object
that is used as a hash-table key.

Proposal (HASH-TABLE-KEY-MODIFICATION:SPECIFY):
	  
In EQ and EQL hash tables, components of a key may be freely modified
with no effect on the table.

In EQUAL hash tables, it is an error to modify a component of a key.

If implementations define additional acceptable values for the :TEST
argument to MAKE-HASH-TABLE, the rule is that it is an error to modify
a component of a key if and only if that component affects the test
function.  If that component cannot affect the test function, the hash
table's operation must not be affected by modifying the component.

Test Cases/Examples:

(setq ht (make-hash-table :test #'eq))
(setq a (cons 1 2))
(setf (gethash a ht) 'win)
(setf (cdr a) 3)
(gethash a ht 'lose) => win t

The same example with :test #'equal in the first line would be an
error.

The following example is not an error, because EQUAL does not examine
the components of general vectors:

(setq ht (make-hash-table :test #'equal))
(setq a (vector 1 2))
(setf (gethash a ht) 'win)
(setf (aref a 1) 3)
(gethash a ht 'lose) => win t

Rationale:

EQ and EQL hash tables use the identity of the object as the key, while
EQUAL hash tables use the structure of the object as the key.  Component
modification changes the structure of an object, while the identity of
an object cannot be changed in Common Lisp.

Making component modification of a key of an EQUAL hash table be an error,
rather than requiring it to signal an error, requiring the table to behave
like ASSOC :TEST #'EQUAL, or requiring SETF of GETHASH to copy the key so
that the table is not affected, minimizes the impact on implementations.

This is a generalization of the warning on p.168 of CLtL.

Note that this proposal implies that it is invalid to use an overly
general hash function, such as SXHASH, as the hash function for EQ or
EQL hash tables.  The value of SXHASH can be affected by component
modifications, and this is likely to cause hash table entries to become
inaccessible.

Current practice:

I am not aware of any implementations that do not conform to the proposal.

Cost to Implementors:

Most implementations probably already conform.  It is possible that some
implementations might have to use a different hash function in their
implementation of some hash tables in order to conform.

Cost to Users:

None.

Cost of non-adoption:

Users would not be sure whether they were allowed to perform side effects
on objects that might have been used as keys of hash tables.

Benefits:

More specific language semantics.

Esthetics:

More specific language semantics.

Discussion:

Discussion on the Common-Lisp mailing list was in favor of this.

∂12-Sep-88  1747	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88  17:47:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458005; Mon 12-Sep-88 20:43:49 EDT
Date: Mon, 12 Sep 88 20:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYMBOL-MACROLET-DECLARE (version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Gregor.pa@Xerox.COM, David N Gray <Gray@DSG.csc.ti.com>, Patrick Dussud <edsel!dussud@labrea.stanford.edu>,
    kempf@Sun.COM, Glenn Andrew Kramer <GAK@SPAR-20.SPAR.SLB.COM>, common-lisp-object-system@SAIL.STANFORD.EDU,
    Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>
In-Reply-To: <19880802205147.3.GREGOR@PORTNOY.parc.xerox.com>,
             <2795614606-3753982@Kelvin>,
             <8808031719.AA12130@rainbow-warrior.lucid.com>,
             <8808031847.AA18770@suntana.sun.com>,
             <2795636967-5097451@Kelvin>,
             <GAK.12419581321.BABYL@SPAR-20.SPAR.SLB.COM>,
             <8808041525.AA20536@suntana.sun.com>,
             <2795711083-4281424@Kelvin>,
             <19880808171852.6.GREGOR@PORTNOY.parc.xerox.com>,
             <8808111506.AA11766@suntana.sun.com>
Message-ID: <19880913004248.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

Issue:         SYMBOL-MACROLET-DECLARE

References:    SYMBOL-MACROLET (88-002R page 2-81)
               WITH-ACCESSORS (88-002R page 2-88)
               WITH-SLOTS (88-002R page 2-92)

Category:      ADDITION

Edit history:  Version 1, 12-Sep-88, Moon

Problem description:

It would be both natural and nice to be able to write

  (with-slots (rho theta) point
    (declare (single-float rho theta))
    ...computation...)

Proposal (SYMBOL-MACROLET-DECLARE:ALLOW):
	  
Allow declarations at the head of the body of SYMBOL-MACROLET, and hence
in WITH-ACCESSORS and WITH-SLOTS.  Exactly the same declarations are
allowed as for LET, with one exception: SYMBOL-MACROLET signals an error
if a SPECIAL declaration names one of the symbols being defined as a
symbol-macrolet.  A type declaration of one of these symbols is equivalent
to wrapping a THE expression around the expansion of that symbol.

Test Cases/Examples:

See problem description.

Rationale:

If SYMBOL-MACROLET is intended to resemble LET in syntax, it ought to
allow declarations.  When writing a SYMBOL-MACROLET directly, the user
could just as easily write a THE expression instead of a type
declaration.  However, when invoking a macro such as WITH-SLOTS that
expands into SYMBOL-MACROLET, the user does not have this option since
the expansion is not supplied explicitly by the user.

Current practice:

SYMBOL-MACROLET was only tentatively added to Common Lisp 3 months ago.

Cost to Implementors:

Less than one man-hour.

Cost to Users:

None.

Cost of non-adoption:

Minor wart in the language.

Benefits:

More consistent language definition.

Esthetics:

More consistent language definition.

Discussion:

None.

∂12-Sep-88  1814	CL-Cleanup-mailer 	issue TRUENAME-SYNTAX-ONLY
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88  18:14:40 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458019; Mon 12-Sep-88 21:13:23 EDT
Date: Mon, 12 Sep 88 21:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue TRUENAME-SYNTAX-ONLY
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8809122123.AA18137@defun.utah.edu>
Message-ID: <19880913011221.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 12 Sep 88 15:23:28 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

TRUENAME-SYNTAX-ONLY:ADD seems generally reasonable, however I have a
few comments to offer.  I think the proposal needs to be amended a bit.

    TRUENAME [with the :SYNTAX-ONLY option] applies any
    file-name translations performed by the file system and returns the
    "true name" of the specified file as a pathname.

Should it be left this vague, and specifically defined to be
implementation-dependent, or should some axioms that it must satisfy be
listed?  For example, should TRUENAME with and without the :SYNTAX-ONLY
option be required to return the same answer in the case when the latter
does not signal an error?  I suspect it may have to be vague (see below).

    (3) Clarify that coercion of a stream to a pathname (either implicitly
    or by a call to the function PATHNAME) returns a pathname representing
    the "true name" of the file.

This directly contradicts the example at the top of CLtL p.414.  I think
you should just remove this point.

    (4) Clarify that file-name translation on pathnames is not performed
    under any other circumstances except those listed above.

I can't figure out what this means operationally, but I suspect that if
I could figure it out, I would disagree with it.  I suggest removing this
point, unless you had something specific in mind, in which case I suggest
rewording this point.

What does (TRUENAME <stream> :SYNTAX-ONLY T) mean?

    Cost to implementors:

    Minor.  VMS provides an RMS system call ....

This overlooks the case of implementations that access VMS files via a
network file protocol.  The cost to implementors might be near infinite if
the particular network file protocol they are using does not provide any
way to perform this operation.  This suggests that the definition of the
:SYNTAX-ONLY option to TRUENAME should be left sufficiently vague that
an implementation that always returned its first argument would be valid.
A lot of the Common Lisp file system interface has to be like that.

    However, it
    would also be reasonable to restrict checking for syntax errors to the
    same places that file name translation is applied.

It would be at least as reasonable to argue that checking for syntax
errors is properly done during file name parsing (i.e. conversion from a
string to a pathname object), as with all other Common Lisp syntax.
Perhaps it would be better not to raise that issue in this proposal.

∂13-Sep-88  0232	CL-Cleanup-mailer 	Re: COERCE-FROM-TYPE and TYPE-OF    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Sep 88  02:32:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 SEP 88 02:30:47 PDT
Date: 13 Sep 88 02:31 PDT
From: masinter.pa@Xerox.COM
Subject: Re: COERCE-FROM-TYPE and TYPE-OF
In-reply-to: your message of Mon, 18 Jul 88 16:55:32 JST
To: Masayuki Ida <ida%cc.aoyama.junet%UTOKYO-RELAY.CSNet@relay.cs.net>,
 cl-cleanup@Sail.stanford.edu, peck@sun.com
Message-ID: <880913-023047-2587@Xerox>

I think we need a cleanup item to redefine TYPE-OF to be basically (CLASS-NAME
(CLASS-OF x)) with perhaps a few exceptions for vectors and arrays. 

I agree that "COERCE object to &optional (from (TYPE-OF object))"
 
makes little sense without such a clarification. Certainly it would make sense
to allow a class as well as a name as the optional "from" argument to COERCE.

I'd like to see a merger of the COERCE-INCOMPLETE and COERCE-FROM-TYPE issues
into a single one.

A sample implementation of a conformal COERCE (which resorted to some built-in
primitives for data structure conversion) would be  useful addition to the
proposal.

Volunteers?

This issue has been in the "pipe" too long. I'd like to see it ready in the next
couple of weeks. So sooner rather than later.

∂13-Sep-88  0633	CL-Cleanup-mailer 	Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  06:33:03 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA23000; Tue, 13 Sep 88 06:31:47 PDT
Date: Tue, 13 Sep 88 06:31:47 PDT
Message-Id: <8809131331.AA23000@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE

I'll support this proposal.

I see another complication regarding the #S syntax in the interaction
between the constructor(s) that have been defined and whether the
structures print out with #S or with #<.  I could imagine having
instances of a parent structure printing with #< but wanting to have
instances of a child print with #S.  But I don't think this complication
is too important.

			---Walter

∂13-Sep-88  0637	CL-Cleanup-mailer 	Issue: DEFSTRUCT-REDEFINITION  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  06:37:46 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA23237; Tue, 13 Sep 88 06:36:30 PDT
Date: Tue, 13 Sep 88 06:36:30 PDT
Message-Id: <8809131336.AA23237@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFSTRUCT-REDEFINITION

Although I tend towards the ideas in DEFSTRUCT-REDEFINITION:ERROR-IFF-OLD-USE,
perhaps people would be a little more comfortable if implementations were
encouraged not to treat an "exact" redefinition as an error (either at
definition time or at access time).

There are several references to the proposal alternative ERROR-IFF-USE
rather than ERROR-IFF-OLD-USE.

			---Walter

∂13-Sep-88  0649	CL-Cleanup-mailer 	Issue PROCLAIM-SCOPE 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  06:49:04 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA23595; Tue, 13 Sep 88 06:47:49 PDT
Date: Tue, 13 Sep 88 06:47:49 PDT
Message-Id: <8809131347.AA23595@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue PROCLAIM-SCOPE

I believe adding an option controlling the scope/extent of PROCLAIM would
be confusing--it's simpler to think of PROCLAIM as only being global.  It
would be better to have a separate, specific mechanism to handle "file-local"
things, unless a more general mechanism could be devised.

It's probably worth noting that some things are already "file-local", such
as the binding of *PACKAGE*.

Also, VAX LISP has added some keywords to COMPILE-FILE which are file local,
such as :OPTIMIZE.

A last comment: adding a way of querying for PROCLAIMed information might
avoid the issue by leaving it to the user to manipulate explicitly.

			---Walter

∂13-Sep-88  0703	CL-Cleanup-mailer 	Issue: LIST-TYPE-SPECIFIER
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  07:03:08 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA24506; Tue, 13 Sep 88 07:01:53 PDT
Date: Tue, 13 Sep 88 07:01:53 PDT
Message-Id: <8809131401.AA24506@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: LIST-TYPE-SPECIFIER

Actually, I'd prefer exchanging the proposed type names, so that
(LIST *) could be abbreviated as (LIST) could be abbreviated as LIST,
just as for arrays, and with the same meaning regarding element types.

There's still the issue of what specialized list or array type specifiers
means.  Assuming the proposal regarding array element type upgrading
(what's the latest on this, btw?) I could see specialized LIST type
specifiers in the same way, with the automatic upgrading of the element
type to T in all (!?) current implementations.

Do we need another cleanup issue on whether (ARRAY foo) implies
(TYPEP (AREF x i) 'foo), just as this issue specifies?

			---Walter

∂13-Sep-88  0713	CL-Cleanup-mailer 	Issue: RETURN-VALUES-UNSPECIFIED    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  07:13:11 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA25377; Tue, 13 Sep 88 07:11:55 PDT
Date: Tue, 13 Sep 88 07:11:55 PDT
Message-Id: <8809131411.AA25377@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: RETURN-VALUES-UNSPECIFIED

This looks OK to me.

I think leaving the values of the debugging and module constructs open
to implementation specification is best for allowing experimentation
and growth.

			---Walter

∂13-Sep-88  0714	CL-Cleanup-mailer 	Issue: ARGUMENTS-UNDERSPECIFIED
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  07:14:39 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA25596; Tue, 13 Sep 88 07:13:23 PDT
Date: Tue, 13 Sep 88 07:13:23 PDT
Message-Id: <8809131413.AA25596@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: ARGUMENTS-UNDERSPECIFIED

This looks OK to me too, except that version 2 has an incomplete
"Current Practice" section.

∂13-Sep-88  0708	Common-Lisp-Object-System-mailer 	RE: Issue: SYMBOL-MACROLET-DECLARE (version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  07:08:47 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA24481; Tue, 13 Sep 88 07:06:10 PDT
Date: Tue, 13 Sep 88 07:06:10 PDT
Message-Id: <8809131406.AA24481@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: Moon@stony-brook.scrc.symbolics.com
Subject: RE: Issue: SYMBOL-MACROLET-DECLARE (version 1)

This seems like a reasonable proposal and does make SYMBOL-MACROLET more
consistent with LET.

This may be a separate issue, but somewhere we should nail down the
interpretation of e.g.

	(symbol-macrolet ((foo bar))
	  ...
	  (locally (declare (special foo))
	    ...foo...))

As currently specified, only a new binding for FOO can turn off its
interpretation as a symbol macro.  I'd like to see some language that said that
a SPECIAL declaration also shadows the symbol macro scope.

The limit case, which your proposal makes "an error", might then reasonably
have a null semantics:

	(symbol-macrolet ((foo bar))
	  (declare (special foo))
	  ...)

might be interpreted as

	(locally (declare (special foo))
	  ...)

I don't have strong feelings one way or the other about this part--it doesn't
seem possible to bring SYMBOL-MACROLET into complete consistency with LET here.

/JEP

∂13-Sep-88  0725	CL-Cleanup-mailer 	Re: COERCE-FROM-TYPE and TYPE-OF    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88  07:25:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458237; Tue 13-Sep-88 10:23:15 EDT
Date: Tue, 13 Sep 88 10:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: COERCE-FROM-TYPE and TYPE-OF
To: masinter.pa@Xerox.COM
cc: Masayuki Ida <ida%cc.aoyama.junet%UTOKYO-RELAY.CSNet@relay.cs.net>, cl-cleanup@SAIL.STANFORD.EDU,
    peck@sun.com
In-Reply-To: <880913-023047-2587@Xerox>
Message-ID: <19880913142219.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 13 Sep 88 02:31 PDT
    From: masinter.pa@Xerox.COM

    I think we need a cleanup item to redefine TYPE-OF to be basically (CLASS-NAME
    (CLASS-OF x)) with perhaps a few exceptions for vectors and arrays. 

I don't entirely agree.  CLASS-OF (88-002R pp.1-15 through 1-17) was
carefully defined to require the existence only of built-in classes
on which it is clearly meaningful to put methods in portable programs.
TYPE-OF (CLtL p.53) on the other hand is defined to be for debugging,
not for type-dispatching, and to return as specific an answer as
"convenient and useful."  Thus it seems unlikely that people would
really want these two to return the same answer, since they exist for
different purposes.

Also 88-002R (chapter 2) says CLASS-NAME can return NIL.

I would certainly oppose redefining CLASS-OF to have as vague a
definition as TYPE-OF.

If it's proposed to redefine TYPE-OF to be no more specific than
CLASS-OF, I would counter-propose to eliminate TYPE-OF entirely,
since it would be redundant.

∂13-Sep-88  0825	CL-Cleanup-mailer 	Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  08:25:09 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA28994; Tue, 13 Sep 88 08:23:51 PDT
Date: Tue, 13 Sep 88 08:23:51 PDT
Message-Id: <8809131523.AA28994@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)

Issue:        FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS

References:   CLtL pp 47-48, 158-159

Category:     CHANGE

Edit history: #1, 7 Sept 1988, Walter van Roggen
	      #2, 13 Sept 1988, Walter van Roggen (costs & proposal limitations)


Problem description:

The current description of the specialized FUNCTION type specifier is not very
useful to program analysis tools and is not very intuitive to programmers
because the meaning of the argument type specifiers is not restrictive.

Programmers find it useful to add information about the types of the arguments
a function expects and about the type(s) that a function may return. This
information is useful both to human readers of the code as well as to type
checking programs such as compilers and cross referencers. The only apparent
(but false) way of providing this information is with the FTYPE declaration and
FUNCTION type specifier.

Furthermore, implementations may wish to provide additional optimizations based
on avoiding type checking or different methods of argument passing. These
optimizations require the same sort of information about the argument types.

However, the current definition of FUNCTION type specifiers on pages 47-48 of
CLtL states that a function such as CONS that is of type
  (FUNCTION (T T) CONS)
is also of type
  (FUNCTION (FLOAT STRING) LIST).
Unfortunately this information is not useful for the above mentioned purposes.
The problem is that the argument types aren't restrictive, so no interesting
matching of types is possible.

Another way of looking at the problem is that specialized FUNCTION type
specifiers cannot be used in a meaningful way for discrimination (as the second
arg to TYPEP, nor as the first argument to THE).  Furthermore functions are
assumed not to be sufficiently self-descriptive that a specialized FUNCTION
type is possible to be known or can be constructed when a function is passed to
TYPE-OF.

Thus unlike all the other type declarations, which can be used for
discrimination and have an implicit effect on representation, specialized
FUNCTION type specifiers appear to have superfluous information.  By changing
the meaning of the argument types to convey additional descriptive information
instead of behavioral information, we can also satisfy the other needs listed
above.


Proposal (FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE)

For specialized FUNCTION type specifiers

  (proclaim '(ftype (function (arg0-type arg1-type ...) val-type) f))
implies
  (the val-type (f (the arg0-type ...) (the arg1-type ...) ...))

If the arguments to F are of the specified types, then the result will be of
the specified type.  If the arguments do not all match the specified types, it
is an error, and then the result is not guaranteed to be of the specified type.

This proposal does not alter the status (or lack thereof) of other issues
related to FUNCTION type specifiers: what lambda-list keywords mean, what the
VALUES type means, what implications there are w.r.t. argument counts, doing
multiple PROCLAIMs, doing local DECLAREs that shadow other declarations or
proclamations, describing generic functions incrementally, the result of TYPEP
with a specialized FUNCTION type.


Rationale:

The proposal seems most like what users expect.

Current Practice:

VAX LISP already assumes and makes use of the "restrictive" semantics. Lucid
has a RESTRICTIVE-FTYPE declaration with these semantics and ignores the
standard FTYPE declaration. Gold Hill intends to use these declarations in this
manner.  Many implementations don't make use of these declarations.  At least
several users make use of declarations assuming the new semantics.

Cost to Implementors:

Since most implementations don't make use of function declarations, and since
those known to do so can be changed easily, the cost should be minimal.

Cost to Users:

There may be some existing "imprecise" function declarations.  However, the
natural tendency when providing these declarations is to be as "descriptive"
(i.e., restrictive but complete) as possible, both for documentation purposes
as well as for potential compiler benefits. There cannot have been any uses of
the specialized FUNCTION type for discrimination. Thus most existing uses are
probably compatible with this new definition.

Cost of Non-Adoption:

There already exists user code on many implementations that assume the
proposed semantics.  Not adopting this proposal would continue to render
such code incorrect or at least non-portable.

Benefits:

Better type checking and more compiler optimizations should be possible.

Esthetics:

This is the what most programmers expect the specialized FUNCTION type to
mean, particularly those coming from other languages.

Discussion:

∂13-Sep-88  0916	CL-Cleanup-mailer 	Re: issue TRUENAME-SYNTAX-ONLY 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Sep 88  09:16:24 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA01115; Tue, 13 Sep 88 10:14:56 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA18524; Tue, 13 Sep 88 10:14:48 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809131614.AA18524@defun.utah.edu>
Date: Tue, 13 Sep 88 10:14:47 MDT
Subject: Re: issue TRUENAME-SYNTAX-ONLY
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 12 Sep 88 21:12 EDT

> Date: Mon, 12 Sep 88 21:12 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
>     TRUENAME [with the :SYNTAX-ONLY option] applies any
>     file-name translations performed by the file system and returns the
>     "true name" of the specified file as a pathname.
> 
> Should it be left this vague, and specifically defined to be
> implementation-dependent, or should some axioms that it must satisfy be
> listed?  For example, should TRUENAME with and without the :SYNTAX-ONLY
> option be required to return the same answer in the case when the latter
> does not signal an error?  I suspect it may have to be vague (see below).

The language in CLtL is already vague, but as far as I know nobody has
been complaining about it.  At least for VMS, I'd say that TRUENAME
shouldn't have to return the same answer in both cases; the reason is
that if you don't supply an explicit version number in the input
pathname and you tell TRUENAME to match an existing file, it ought to
fill in the version number for that file; but if you're only checking
syntax it doesn't have any way of knowing what the version number
should be.

>     (3) Clarify that coercion of a stream to a pathname (either implicitly
>     or by a call to the function PATHNAME) returns a pathname representing
>     the "true name" of the file.
> 
> This directly contradicts the example at the top of CLtL p.414.  I think
> you should just remove this point.

Sorry, "clarify" was the wrong word here.  Except for the example you
cite, CLtL doesn't explicitly address the issue of what coercing a
stream to a pathname really does.  The idea is, that since OPEN must
perform the equivalent of TRUENAME anyway, it can just as well create
a stream that remembers the "true name" of the file as the pathname
that was passed to OPEN.  As I recall, VaxLisp already behaves as
proposed.  However, if people would prefer it that way, I could change
this item to leave this behavior explicitly vague.

>     (4) Clarify that file-name translation on pathnames is not performed
>     under any other circumstances except those listed above.
> 
> I can't figure out what this means operationally, but I suspect that if
> I could figure it out, I would disagree with it.  I suggest removing this
> point, unless you had something specific in mind, in which case I suggest
> rewording this point.

What I had in mind was that none of the zillion other pathname
functions (which I was too lazy to list) would be allowed to do file
name translation; nor would coercing a string to a pathname.  For
example, (pathname-device "foo:bar.baz") on VMS would always return
"foo", even if it's defined as a logical name.

>     Cost to implementors:
> 
>     Minor.  VMS provides an RMS system call ....
> 
> This overlooks the case of implementations that access VMS files via a
> network file protocol.  The cost to implementors might be near infinite if
> the particular network file protocol they are using does not provide any
> way to perform this operation.  This suggests that the definition of the
> :SYNTAX-ONLY option to TRUENAME should be left sufficiently vague that
> an implementation that always returned its first argument would be valid.
> A lot of the Common Lisp file system interface has to be like that.

That's a good point -- I'd forgotten about networking from non-VMS
hosts.  However, if an implementation doesn't expand logical names
fully when requested to do so, users are going to run into the same
kind of strange behavior (i.e., within MERGE-PATHNAMES) that prompted
me to bring this up in the first place.  I don't see much point in
adding this functionality to the language unless the spec is tight
enough to ensure that it's going to solve the problem it was intended
to.

> It would be at least as reasonable to argue that checking for syntax
> errors is properly done during file name parsing (i.e. conversion from a
> string to a pathname object), as with all other Common Lisp syntax.

Yes, of course.  However, it's possible to construct pathnames which
might contain "syntax errors" by other means as well.  For instance, if
you merge pathnames from two different hosts you might end up with
subfields that are too long, illegal characters, etc.

-Sandra
-------

∂13-Sep-88  0935	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88  09:35:16 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458341; Tue 13-Sep-88 12:33:18 EDT
Date: Tue, 13 Sep 88 12:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880913000720.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
             <880912-135459-1531@Xerox>
Message-ID: <880913123225.6.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Mon, 12 Sep 88 20:07 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Date: 12 Sep 88 13:52 PDT
	From: Masinter.pa@Xerox.COM

	I think having DESCRIBE in the standard is much less useful if it is too vague.
	If you want something interactive, use INSPECT.  No?

    In spite of the name of his proposal, I think Kent was proposing to make
    it (slightly) -less- vague. ...

Right. It's already vague. I was proposing to make that vagueness apparent
so it wouldn't be a time bomb in some people's code.

A few more thoughts for what they're worth...

 - CLtL (and Kathy's current draft manual) describes INSPECT as an interactive
   version of DESCRIBE. That doesn't quite contractually oblige DESCRIBE to be
   non-interactive, but it does provide an interesting perspective on intent.

 - Another way to go is to provide an argument saying whether it was ok
   to ask questions:

	DESCRIBE thing &OPTIONAL (query-ok (INTERACTIVE-STREAM-P *STANDARD-OUTPUT*))
	 where QUERY-OK would default according to the interactiveness of the
	 stream in question

   or

	DESCRIBE thing &KEY (verbose :QUERY)
	 where VERBOSE might be one of T, NIL, or :QUERY

 - If people are going to be writing CLOS methods for DESCRIBE, we better get
   started early in saying whether they ought to be incorporating queries into
   their code. [Interestingly, though, the CLOS spec requires the methods for
   DESCRIBE to be compatible with CLtL's description of DESCRIBE, not the
   emerging ANSI spec's description. :-]

∂13-Sep-88  1109	CL-Cleanup-mailer 	SYMBOL-MACROFLET
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88  11:09:45 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458411; Tue 13-Sep-88 14:07:28 EDT
Date: Tue, 13 Sep 88 14:06 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROFLET
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, Masinter.pa@xerox.com,
    cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880908013813.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880913140645.0.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Wed, 7 Sep 88 21:38 EDT
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Mon, 5 Sep 88 17:51:08 BST
	From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

	5. Symbol-macro-flet: SYMBOL-MACRO-LET lets me have something that
	looks like a variable but is really some expression.  It might seem
	that MACROLET does the same for function names, but it doesn't.
	MACROLET applies to entire calls, not just the name.  This suggests
	that SYMBOL-MACRO-LET should have a companion, SYMBOL-MACRO-FLET.

    This is Zetalisp's "lambda macros", also available in Symbolics Common
    Lisp.  They're called that because they let users write new things that
    behave like LAMBDA. ...

I don't think what Jeff's talking about is lambda macros. There are currently
really three possibilities:

 (... symbol ...)
 (symbol ...)
 ((symbol ...) ...)

Lambda macros are about the third of these. My impression is that Jeff's
talking about the second. For example, in the Cloe implementation of Flavors,
the implementation of DEFUN-IN-FLAVOR uses a macro which we call
SYMBOL-FMACROLET. That lets
 (DEFUN-IN-FLAVOR (F FOO) ...)
 (DEFMETHOD (ZAP FOO) () (F X))
[effectively] expand into
 (DEFUN |F in FOO| ...)
 (DEFMETHOD (ZAP FOO) () (|F in FOO| ...))
by going through an intermediate step such as:
 (DEFMETHOD (ZAP FOO) ()
   (SYMBOL-FMACROLET ((F |F in FOO|))
     (F X)))

This facility, which I think is the one Jeff is alluding to, is very
different from what lambda macros are for.

Aside: As far as I've been able to discern, DEFUN-IN-FLAVOR has very little
place in CLOS so this example may seem a bit foreign to people not familiar
with Flavors. Sorry about that.

Regardless of the merits of DEFUN-IN-FLAVOR, I think Jeff's right that
this companion special form (SYMBOL-FMACROLET or SYMBOL-MACRO-FLET or
SYMBOL-MACROFLET or whatever) is interesting. Also, for the sake of a
portable implementation of New Flavors and things like it, I think it
would make very good sense to consider adding it now rather than waiting
until we realize we're screwed without it. SYMBOL-MACROFLET is as hard
to write as a macro as SYMBOL-MACROLET, so if you think SYMBOL-MACROLET
really must be a special form, then I argue that so should
SYMBOL-MACROFLET.

∂13-Sep-88  1131	CL-Cleanup-mailer 	SYMBOL-MACROFLET
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  11:31:40 PDT
Received: from edsel ([192.9.200.1]) by heavens-gate.lucid.com id AA00199g; Tue, 13 Sep 88 10:29:42 PST
Received: from blacksox.lucid.com by edsel id AA06153g; Tue, 13 Sep 88 11:24:24 PDT
Received: by blacksox id AA00321g; Tue, 13 Sep 88 11:27:10 pdt
Date: Tue, 13 Sep 88 11:27:10 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809131827.AA00321@blacksox.lucid.com>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM,
        jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, Masinter.pa@xerox.com,
        cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Kent M Pitman's message of Tue, 13 Sep 88 14:06 EDT <880913140645.0.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROFLET

Doesn't this do what you want?

(defmacro fsymbolf-fmacrofletf (renamings &body body)
  `(macrolet ,(mapcar #'(lambda (renaming)
			  `(,(first renaming) (&rest args)
			      `(,',(second renaming) ,@args)))
		      renamings)
     ,@body))

∂13-Sep-88  1145	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-DECLARE (version 1)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  11:45:49 PDT
Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA00217g; Tue, 13 Sep 88 10:43:38 PST
Received: by rainbow-warrior id AA03013g; Tue, 13 Sep 88 11:41:59 PDT
Date: Tue, 13 Sep 88 11:41:59 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8809131841.AA03013@rainbow-warrior>
To: piazza%lisp.DEC@decwrl.dec.com
Cc: Moon@stony-brook.scrc.symbolics.com,
        Common-Lisp-Object-System@SAIL.STANFORD.EDU,
        cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Jeffrey Piazza's message of Tue, 13 Sep 88 07:06:10 PDT <8809131406.AA24481@decwrl.dec.com>
Subject: Issue: SYMBOL-MACROLET-DECLARE (version 1)

   Date: Tue, 13 Sep 88 07:06:10 PDT
   From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)

   This seems like a reasonable proposal and does make SYMBOL-MACROLET more
   consistent with LET.

   This may be a separate issue, but somewhere we should nail down the
   interpretation of e.g.

	   (symbol-macrolet ((foo bar))
	     ...
	     (locally (declare (special foo))
	       ...foo...))

   As currently specified, only a new binding for FOO can turn off its
   interpretation as a symbol macro.  I'd like to see some language that said that
   a SPECIAL declaration also shadows the symbol macro scope.

That seems reasonable.

   The limit case, which your proposal makes "an error", might then reasonably
   have a null semantics:

	   (symbol-macrolet ((foo bar))
	     (declare (special foo))
	     ...)

   might be interpreted as

	   (locally (declare (special foo))
	     ...)

This would be a very bad idea, it would be very inconsistent with LET, and
would introduce a bizarre semantics: Throw away what I just said in the
binding list. I think that it should be an error.

Patrick.




∂13-Sep-88  1212	CL-Cleanup-mailer 	SYMBOL-MACROFLET
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88  12:12:21 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458465; Tue 13-Sep-88 15:06:32 EDT
Date: Tue, 13 Sep 88 15:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROFLET
To: eb@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
    Moon@STONY-BROOK.SCRC.Symbolics.COM,
    jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, Masinter.pa@xerox.com,
    cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8809131827.AA00321@blacksox.lucid.com>
Message-ID: <880913150548.2.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Tue, 13 Sep 88 11:27:10 pdt
    From: Eric Benson <eb@lucid.com>

    Doesn't this do what you want?

    (defmacro fsymbolf-fmacrofletf (renamings &body body)
      `(macrolet ,(mapcar #'(lambda (renaming)
			      `(,(first renaming) (&rest args)
				  `(,',(second renaming) ,@args)))
			  renamings)
	 ,@body))

No: think about #' .

In my experience, a common reason to use DEFUN-IN-FLAVOR (rather than
DEFMETHOD) is to make the name suitable for MAPCAR. That is, to be
able to do (MAPCAR #'local-function things) rather than
(MAPCAR #'method-name (CIRCULAR-LIST SELF) things).

∂13-Sep-88  1213	CL-Cleanup-mailer 	Exponent sign printing with ~E 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88  12:13:24 PDT
Received: from KRYPTON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458477; Tue 13-Sep-88 15:12:33 EDT
Date: Tue, 13 Sep 88 15:11 EDT
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Exponent sign printing with ~E
To: CL-CLeanup@Sail.stanford.edu, Cassels@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870703-173352-132@Xerox>
Message-ID: <19880913191142.7.CASSELS@KRYPTON.SCRC.Symbolics.COM>

Issue:         ~E-EXPONENT-SIGN

References:    CLtL pp. 366, 393

Category:      CLARIFICATION

Edit history:  Bob Cassels, 13 Sep 88

Related issues: <none>

Problem description:

    The result of (format nil "~E" 1.0) is specified in a contradictory way.
    The ambiguity is whether a plus sign should be printed in front of
    the exponent.
    
    The top of page 393 says, "Next, either a plus or a minus sign is
    printed, followed by e digits ... [decimal exponent]"
    
    Later on page 393 we see, "If all of w, d, and e are omitted, then the
    effect is ... [like prin1].
    
    Page 366 [presumably where prin1 is defined] doesn't explicitly say that
    the plus sign is omitted from the exponent, but all the examples (and
    usual practice) indicate that.
    
    So the posssibilities are:

	A. "1.0e+0"
	B. "1.0e0"
    
    The first reference implies that A is correct, the third reference
    implies that B is correct.  The second reference implies that A and B
    are the same.

Proposal (~E-EXPONENT-SIGN:FORCE-SIGN):

    Change the wording on page 393 to:

    "If all of w, d, and e are omitted, then the effect is to print the
    value using ordinary free-format exponential-notation output; PRIN1 uses
    a similar format for any non-zero number whose magnitude is less than
    10**-3 or greater than or equal to 10**7.  The only difference is that
    the ~E directive always prints a plus or minus sign in front of the
    exponent, while PRIN1 omits the plus sign if the exponent is
    non-negative."

Test Case:

    (format nil "~E" 1.0) => "1.0e+0"

Rationale:

    This proposal makes ~E self-consistent.  That is more important than
    making ~E consistent with PRIN1.

Current practice:

    Symbolics Common Lisp, Ibuki Lisp, and VAX Lisp all print the plus
    sign as in the test case above.  Apollo DOMAIN Common Lisp (version
    2.10) produces "1.0", which is simply wrong.

Adoption Cost:

    Minimal changes to one printing routine for non-conforming
    implementations.  (No change to the three implementations mentioned
    above.)

Cost of non-adoption:

    Minor confusion and possible incompatibility among implementations.

Benefits:

    Less confusion, more compatibility.

Conversion Cost:

    Minimal.  It is doubtful that any user programs depend on this
    obscure distinction.

Esthetics:

    A matter of opinion.

Discussion:

    Fortran ~E format requires a sign before the exponent, since the exponent
    mark character may be dropped.  Since Common Lisp ~E always prints
    the exponent marker, the exponent sign may be dropped in the case
    that it would be a plus sign.

∂13-Sep-88  1214	CL-Cleanup-mailer 	SYMBOL-MACROFLET
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  12:14:13 PDT
Received: from edsel ([192.9.200.1]) by heavens-gate.lucid.com id AA00266g; Tue, 13 Sep 88 11:12:48 PST
Received: from blacksox.lucid.com by edsel id AA06258g; Tue, 13 Sep 88 12:07:28 PDT
Received: by blacksox id AA00332g; Tue, 13 Sep 88 12:09:15 pdt
Date: Tue, 13 Sep 88 12:09:15 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809131909.AA00332@blacksox.lucid.com>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM,
        jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, Masinter.pa@xerox.com,
        cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Kent M Pitman's message of Tue, 13 Sep 88 15:05 EDT <880913150548.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROFLET

   Date: Tue, 13 Sep 88 15:05 EDT
   From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

       Date: Tue, 13 Sep 88 11:27:10 pdt
       From: Eric Benson <eb@lucid.com>

       Doesn't this do what you want?

       (defmacro fsymbolf-fmacrofletf (renamings &body body)
	 `(macrolet ,(mapcar #'(lambda (renaming)
				 `(,(first renaming) (&rest args)
				     `(,',(second renaming) ,@args)))
			     renamings)
	    ,@body))

   No: think about #' .

   In my experience, a common reason to use DEFUN-IN-FLAVOR (rather than
   DEFMETHOD) is to make the name suitable for MAPCAR. That is, to be
   able to do (MAPCAR #'local-function things) rather than
   (MAPCAR #'method-name (CIRCULAR-LIST SELF) things).


This will work:

(defmacro fsymbolf-fmacrofletf (renamings &body body)
  `(flet ,(mapcar #'(lambda (renaming)
			  `(,(first renaming) (&rest args)
			      `(apply #',',(second renaming) args)))
		      renamings)
     (declare (inline ,@(mapcar #'first renamings)))
     ,@body))

Of course you won't be happy with

∂13-Sep-88  1216	CL-Cleanup-mailer 	SYMBOL-MACROFLET
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  12:16:48 PDT
Received: from edsel ([192.9.200.1]) by heavens-gate.lucid.com id AA00275g; Tue, 13 Sep 88 11:15:23 PST
Received: from blacksox.lucid.com by edsel id AA06262g; Tue, 13 Sep 88 12:10:00 PDT
Received: by blacksox id AA00335g; Tue, 13 Sep 88 12:12:45 pdt
Date: Tue, 13 Sep 88 12:12:45 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809131912.AA00335@blacksox.lucid.com>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM,
        jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, Masinter.pa@xerox.com,
        cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Kent M Pitman's message of Tue, 13 Sep 88 15:05 EDT <880913150548.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROFLET

   Date: Tue, 13 Sep 88 15:05 EDT
   From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

       Date: Tue, 13 Sep 88 11:27:10 pdt
       From: Eric Benson <eb@lucid.com>

       Doesn't this do what you want?

       (defmacro fsymbolf-fmacrofletf (renamings &body body)
	 `(macrolet ,(mapcar #'(lambda (renaming)
				 `(,(first renaming) (&rest args)
				     `(,',(second renaming) ,@args)))
			     renamings)
	    ,@body))

   No: think about #' .

   In my experience, a common reason to use DEFUN-IN-FLAVOR (rather than
   DEFMETHOD) is to make the name suitable for MAPCAR. That is, to be
   able to do (MAPCAR #'local-function things) rather than
   (MAPCAR #'method-name (CIRCULAR-LIST SELF) things).


Sorry about the premature posting; my fingers slipped.

This will work:

(defmacro fsymbolf-fmacrofletf (renamings &body body)
  `(flet ,(mapcar #'(lambda (renaming)
			  `(,(first renaming) (&rest args)
			      (apply #',(second renaming) args)))
		      renamings)
     (declare (inline ,@(mapcar #'first renamings)))
     ,@body))

Of course you won't be happy with the result unless your compiler
optimizes (APPLY x (LIST a b c)) into (FUNCALL x a b c).

∂13-Sep-88  1232	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  12:32:10 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA14068; Tue, 13 Sep 88 12:30:52 PDT
Date: Tue, 13 Sep 88 12:30:52 PDT
Message-Id: <8809131930.AA14068@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: HASH-TABLE-ACCESS (version 1)

Issue:		HASH-TABLE-ACCESS
References:	hash-tables (Chapter 21 of CLtL)
Category:	ADDITION
Edit History:	13-Sept-88, version 1 by Walter van Roggen

Problem Description:

  There are many characteristics of hash-tables which are specified upon
  creation but are not accessible afterwards.

Proposal: (HASH-TABLE-ACCESS:PROVIDE)

  Add the following functions to the language:

  HASH-TABLE-REHASH-SIZE hash-table

    Returns the current rehash size of a hash table.

  HASH-TABLE-REHASH-THRESHOLD hash-table

    Returns the current rehash threshold of a hash table.

  HASH-TABLE-SIZE hash-table

    Returns the current size of a hash table.

  HASH-TABLE-TEST hash-table

    Returns the test used for comparing keys in the hash table.
    By default the value will be either EQL or #'EQL.


Current Practice:

  VAX LISP implements the proposal.

Cost to Implementors:

  Most of these should be trivial to implement, since the information
  must be present for nearly all types.

Cost to Users:

  None.  This is an upward-compatible extension.

Cost of Non-Adoption:

  The benefits would not be available in a portable fashion.

Benefits:

  Programs would be able to access useful information otherwise hidden.
  For example, it would allow programs to gain statistics about hash
  table usage that might enable better tuning.

Discussion:

  None of these are required to be SETF'able, though that might be
  a reasonable implementation-dependent extension.

  This first appeared in ">GLS>clarifications.text" of 12/06/85.

∂13-Sep-88  1234	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (version 1) 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  12:33:53 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA14180; Tue, 13 Sep 88 12:32:37 PDT
Date: Tue, 13 Sep 88 12:32:37 PDT
Message-Id: <8809131932.AA14180@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: TAGBODY-CONTENTS (version 1)

Issue:		TAGBODY-CONTENTS
References:	TAGBODY (pp 130-131 of CLtL)
Category:	CLARIFICATION
Edit History:	13-Sept-88, version 1 by Walter van Roggen

Problem Description:

  CLtL isn't clear on what may be in the body of a TAGBODY.

Proposal: (TAGBODY-CONTENTS:RESTRICT)

  Anything in a TAGBODY other than a tag (a symbol or an integer) or
  a list is an error.

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

  The same restrictions apply to all forms which implicitly use TAGBODY,
  such as PROG and DO.

Current Practice:

Cost to Implementors:

  A few simple checks are probably all that's needed, and probably
  most implementations (both interpreters and compilers) already perform them.

Cost to Users:

  Unlikely to affect any portable code.  If there are implementations which
  support other objects as tags (floats, for example), there may be simple
  editing necessary.

Benefits:

  A slightly more precise description of the language.

Discussion:

  This first appeared in ">GLS>clarifications.text" of 12/06/85.

∂13-Sep-88  1238	CL-Cleanup-mailer 	Issue: TAILP-NIL (version 1)   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88  12:38:22 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA14339; Tue, 13 Sep 88 12:37:02 PDT
Date: Tue, 13 Sep 88 12:37:02 PDT
Message-Id: <8809131937.AA14339@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: TAILP-NIL (version 1)

Issue:		TAILP-NIL
References:	TAILP (p 275 of CLtL)
Category:	CLARIFICATION/CHANGE
Edit History:	13-Sept-88, version 1 by Walter van Roggen

Problem Description:

  CLtL, in the description of TAILP, states:
    (TAILP sublist list)
  "is true if (NTHCDR n list) is sublist, for some value of n.  See
   LDIFF."

  However, the behavior when sublist is NIL is not what was intended,
  as implied by the description of LDIFF and a common definition of
  TAILP:

  (defun tailp (sublist list)
    (do ((list list (cdr list)))
        ((null list) nil)
      (if (eq sublist list)
          (return t))))

Proposal: (TAILP-NIL:NIL)

  (TAILP NIL X) returns NIL for all lists X.  Qualify the description
  in CLtL by saying that:
    (TAILP sublist list)
  "is true if (NTHCDR n list) is sublist for some value of n, if sublist
   is a non-null list, and is false if sublist is NIL."

Current Practice:

  This is probably what all implementations already do.

Cost to Implementors:

  An implementation is given in the Problem Description.

Cost to Users:

  Unlikely to affect any portable code, due to the Current Practice.

Benefits:

  A slightly more precise description of the language.

Discussion:

  This first appeared in ">GLS>clarifications.text" of 12/06/85.

∂13-Sep-88  1240	CL-Cleanup-mailer 	SYMBOL-MACROFLET
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88  12:40:15 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458509; Tue 13-Sep-88 15:37:08 EDT
Date: Tue, 13 Sep 88 15:36 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROFLET
To: eb@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
    Moon@STONY-BROOK.SCRC.Symbolics.COM,
    jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, Masinter.pa@xerox.com,
    cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8809131912.AA00335@blacksox.lucid.com>
Message-ID: <880913153624.3.KMP@GRYPHON.SCRC.Symbolics.COM>

    Date: Tue, 13 Sep 88 12:12:45 pdt
    From: Eric Benson <eb@lucid.com>

    This will work:

    (defmacro fsymbolf-fmacrofletf (renamings &body body)
      `(flet ,(mapcar #'(lambda (renaming)
			      `(,(first renaming) (&rest args)
				  (apply #',(second renaming) args)))
			  renamings)
	 (declare (inline ,@(mapcar #'first renamings)))
	 ,@body))

    Of course you won't be happy with the result unless your compiler
    optimizes (APPLY x (LIST a b c)) into (FUNCALL x a b c).

Ours happens to do that optimization, but not everyone's does so it's
bad to rely on that for portable code, which is actually what I was
thinking about. If I was only worried about our own implementations, we
could just have our own private implementation of fsymbolf-fmacrofletf 
and be done with it.

Also, INLINE is not required to be processed by everyone, so there's
another place you might take a runtime speed hit.

Also, some compilers complain when you don't use the function. So you
have to put #'name1 #'name2 ... etc. at toplevel in the FLET body. 
[But then you have to worry that some compilers won't remove that.]

Anyway, we used to do DEFUN-IN-FLAVOR by using FLET, but the practical
fact is that all the smarts needed to make FLET work can be a big drain
on the compiler. If you write zillions of DEFUN-IN-FLAVORs (which some
people do), then -every- method on that flavor (whether it uses the 
function or not) must have this enormous FLET in it just so that the
compiler can optimize it out. It is zillions of times more efficient
at compile time (how's that for an exacting metric?) to use our 
SYMBOL-FMACROLET strategy than to use FLET. It forces the compiler to
do semantic analysis only on demand -- which is what you need to make
a thing like this really useful.

(By the way, I -do- like your choice of name. When I finally talk you
into adopting this, I definitely think that fsymbolf-fmacrofletf
will be the icing on the cake. :-)

∂13-Sep-88  1459	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)  
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 13 Sep 88  14:59:12 PDT
Received:  by multimax.ARPA (5.51/25-eef)
	id AA00771; Tue, 13 Sep 88 17:58:58 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
	id AA01990; Tue, 13 Sep 88 18:00:35 EDT
Message-Id: <8809132200.AA01990@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
Date: Tue, 13 Sep 88 18:00:34 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>

Sorry for the delay in this, but I've been waiting for preliminary
comments from an (unnamed) member of this committee...

Issue:         REQUIRE-PATHNAME-DEFAULTS
References:    *MODULES*, PROVIDE, REQUIRE, pp 188-191
Category:      CHANGE
Edit history:  Version 1 by Pierson 9/13/88
Status:        For Internal Discussion

Problem description:

PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
to provide multi-file Common Lisp programs with a single mechanism to
detect and correct incorrect load sequences.  These functions were
also designed to be used for general file inclusion in Common Lisp.
Unfortunately, the file loading feature of REQUIRE is specified such
that it is inherently non-portable and environment dependent.

Proposal (REQUIRE-PATHNAME-DEFAULTS:DECLARATIVE):

Remove the second argument from REQUIRE.  Change the description of
REQUIRE to:

    The REQUIRE function tests whether a module is already present
    (using a case-sensitive comparison); if the module is not present,
    REQUIRE signals a correctable error of type REQUIRE-ERROR.  The
    error can be corrected by loading the appropriate file(s).

Note that there is no requirement that a module consist of exactly one
file. 

Change the "Put in seven extremely random user interface commands"
discussion to suggest that PROVIDE should be put at the end of the
file rather than the beginning.

Test Cases/Examples:

(REQUIRE 'fft)

Would still be legal.

(REQUIRE 'fft "fft")

Would no longer be Common Lisp.  However implementations could still
provide this as an extension.

Rationale:

The file loading feature of REQUIRE is non-portable.  Since we can't
figure out an acceptable portable solution, the feature should be
flushed.  Making REQUIRE signal a correctable error gives the user an
easy out in interactive situations.

Putting PROVIDE at the beginning of a file is a mistake because the
file will still appear to be PROVIDEd if it fails to load.  This may
cause files loaded later to fail mysteriously because the first failed
file didn't define expected constants or macros, etc.

Current practice:

All implementations that I know of currently support a second argument
to REQUIRE.  Lucid and KCL use the second argment at the pathname to
load relative to the current working directory.

Cost to Implementors:

All currently conforming implementations will have to make a small
change.

Cost to Users:

Any (non-portable) user programs that rely on the current behaviour of
REQUIRE will have to change.  On the other hand, porting Common Lisp
programs from one system to another may well be simplified because
REQUIRE errors will always correctable.

Cost of non-Adoption:

Part of the documented functionality of REQUIRE will continue to
unavailable to portable (and many non-portable) programs.

Benefits:

PROVIDE and REQUIRE will be clearly restricted to a portable,
checking role.

Aesthetics:

This simplifies the language by removing an environment-dependent
feature. 

Discussion:

Pierson supports this proposal.

∂13-Sep-88  1502	CL-Cleanup-mailer 	Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88  15:02:46 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458605; Tue 13-Sep-88 18:01:20 EDT
Date: Tue, 13 Sep 88 18:00 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <880904-152018-8868@Xerox>
Message-ID: <880913180032.4.KMP@GRYPHON.SCRC.Symbolics.COM>

I'm happy with most of this but I have one bone to pick.

I believe the END argument to PARSE-INTEGER should be permitted to be
NIL, meaning use the rest of the string.  This is most convenient from
an implementation point of view because one can write

 &KEY (START 0) (END NIL)

If you say the argument must be an integer, you must write:

 &KEY (START 0) (END NIL END-P)

and complain if END is NIL while END-P is T (which seems gratuitous
error checking since the functionality would be useful) or else you must
do

 &KEY (START 0) (END (LENGTH STRING))

which is also gratuitous since the function will not be certain that the
value of END is correct and will have to do (LENGTH STRING) yet again in
order to validate the value of END.

I believe an analogous criterion should be applied to END arguments
across the board. If someone thinks it appropriate, I will write this up
as a separate cleanup.

∂13-Sep-88  1542	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 2)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88  15:42:23 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458628; Tue 13-Sep-88 18:41:32 EDT
Date: Tue, 13 Sep 88 18:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880913184048.5.KMP@GRYPHON.SCRC.Symbolics.COM>

I just can't buy into this. I think it's a big mistake to require a
sublist to be a CONS. It teaches people to confuse the notion of CONS
with the notion of LIST. The latter may include NIL. I have added
another option which I can support.

-----
Issue:		TAILP-NIL
References:	TAILP (p275)
Category:	CLARIFICATION/CHANGE
Edit History:	13-Sep-88, version 1 by Walter van Roggen,
		13-Sep-88, version 2 by Pitman

Problem Description:

  CLtL (p275) specifies TAILP as:

    TAILP sublist list				[Function]

    This predicate is true if SUBLIST is a sublist of LIST (i.e.,
    one of the conses that makes up LIST); otherwise, it is false.
    Another way to look at this is that TAILP is true if
    (NTHCDR n list) is SUBLIST, for some value of N. See LDIFF.

  Two common implementations of this definition are:

   (defun tailp (sublist list)			;Definition "A"
     (do ((list list (cdr list)))
	 ((endp list) nil)
       (if (eq sublist list)
	   (return t))))

   (defun tailp (sublist list)			;Definition "B"
     (do ((list list (cdr list)))
	 ((atom list) (eq list sublist))
       (if (eq sublist list)
	   (return t))))

  They differ only in their treatment of the atomic case.

  At issue is the fact that () is a list, and hence some would
  argue that it is a sublist of all other lists. On the other hand,
  the definition of TAILP seems to imply that being a cons is a
  necessary precondition of being a "sublist".

Proposal (TAILP-NIL:NIL):

  Clarify that the sublist argument to TAILP must be a list
  and that (TAILP NIL X) returns NIL for all lists X.

  Qualify the description in CLtL by saying that (TAILP sublist list)
  is true if SUBLIST is a cons and (NTHCDR n list) is SUBLIST for
  some value of N, and is false otherwise.

  Rationale:

   This is the status quo in a number of implementations.

Proposal (TAILP-NIL:T):

  Strike any text in the definition of TAILP which suggests that a
  sublist must be a cons.

  Clarify that (TAILP any-atom list) returns T iff (NTHCDR n list) is
  SUBLIST for some value of N, and false otherwise.

  Rationale:

   This is more consistent with the definition of LDIFF, which
   gives a useful meaning to arbitrary atomic SUBLIST arguments.

   This gives a more elegant definition of SUBLIST, allowing it to
   refer to any list -- including the empty list -- which is a
   part of another list.

Test Cases:

 #1: (LET ((X '(B C))) (TAILP X (CONS 'A X)))
     should return T in all implementations.

 #2: (TAILP '(X Y) '(A B C))
     should return NIL in all implementations.

 #3: (TAILP '() '(A B C))
     returns NIL under proposal TAILP-NIL:NIL
     returns T   under proposal TAILP-NIL:T

 #4: (TAILP 3 '(A B C))
     is an error under proposal TAILP-NIL:NIL
     returns NIL under proposal TAILP-NIL:T

 #5: (TAILP 3 '(A B C . 3))
     is an error under proposal TAILP-NIL:NIL
     returns T under proposal TAILP-NIL:T

 #6: (TAILP '(X Y) '(A B C . 3))
     is an error under proposal TAILP-NIL:NIL
     returns NIL under proposal TAILP-NIL:T

Current Practice:

  Symbolics Genera is consistent with TAILP-NIL:T.

  [Walter alleges TAILP-NIL:NIL is what all implementations already
   do, but since Genera is not in conformance, KMP regards that
   hypothesis as suspect. We need real data points, folks.]

Cost to Implementors:

  An implementation of TAILP-NIL:NIL is given as Definition "A" in the
  problem description.

  An implementation of TAILP-NIL:T is given as Definition "B" in the
  problem description.

  Some implementations might have compiler optimizers for these definitions
  as well, so a slight amount of additional effort might be required.

Cost to Users:

  Given that current practice varies widely on the disputed case,
  this is unlikely to have a practical effect on existing portable code.

Benefits:

  Either description makes the language more precise.

  [Pitman believes that] TAILP-NIL:T is more consistent with the behavior
  of TAILP and more consistent with what he thinks should be the 
  definition of a sublist.

Discussion:

  This issue was first raised in ">GLS>clarifications.text" of 12/06/85.

  Pitman supports TAILP-NIL:T.

∂13-Sep-88  1550	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88  15:50:48 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458636; Tue 13-Sep-88 18:49:51 EDT
Date: Tue, 13 Sep 88 18:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
To: CL-Cleanup@SAIL.Stanford.EDU, pierson%mist@MULTIMAX.ARPA
In-Reply-To: <8809132200.AA01990@mist.UUCP>
Message-ID: <880913184907.6.KMP@GRYPHON.SCRC.Symbolics.COM>

This is an improvement, but I personally still consider the whole
PROVIDE/REQUIRE feature to be bankrupt for another reason, unrelated
to the file issue. Specifically:

If PROVIDE is at the top of a file, that will make mutually dependent
systems loadable. If it's at the bottom of a file, then mutually
dependent systems will recursively load ad nauseum (or will go back
and forth erring, depending on whether you have Pierson's cleanup).

That would seem to argue for putting PROVIDE at the top. But then, if
a file blows out, you've provided the module already and there is no
provision to have the PROVIDE undone.

Unless we require PROVIDE to cooperate with LOAD and to have the
PROVIDE info persist only if LOAD does a normal 
(i.e., non-erring, non-throwing, ...) return would I really believe
in PROVIDE and REQUIRE. I could -really- get behind PROVIDE and REQUIRE
if we could work out the details of this kind of cooperation to everyone's
satisfaction.

I would also buy into a further restriction on PROVIDE and REQUIRE which
said that it was not to be used for mutually dependent systems, and
that PROVIDE was recommended for use only after having actually done
the providing -- not at the head of the set of file(s).

In the absence of those concessions, I agree that Dan's cleanup is
reasonable, but I don't know to what good end. In my opinion, he's
optimizing a still-worthless utility.

∂13-Sep-88  1604	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88  16:03:59 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458649; Tue 13-Sep-88 19:02:54 EDT
Date: Tue, 13 Sep 88 19:02 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAGBODY-CONTENTS (version 1)
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8809131932.AA14180@decwrl.dec.com>
Message-ID: <880913190211.7.KMP@GRYPHON.SCRC.Symbolics.COM>

I generally support this TAGBODY-CONTENTS:RESTRICT, but have the following comments:

    Cost to Implementors:

      A few simple checks are probably all that's needed, and probably
      most implementations (both interpreters and compilers) already perform them.

Actually, this should be "no cost" since you've only said this "is an error".
You've not required implementations to signal. With my portable-code-writer's hat 
on, I'd applaud any attempts to make implementations really signal in this case,
but my guess is that most implementors (maybe even Symbolics itself) would boo me
on this and would regard this as an imposition of the same caliber as my IF-BODY
suggestion a while back.

    Cost to Users:

      Unlikely to affect any portable code.  If there are implementations which
      support other objects as tags (floats, for example), there may be simple
      editing necessary.

Again, no cost. Users already can't rely on anything more than what's in CLtL.
If they do, they're not writing CL code. Further, since you're not forcing
implementations to change, they are free to continue to rely on this non-portable
extension as long as implementors don't get overzealous and upgrade just for grins.

Bottom line: I don't think this proposal really restricts anything. I think it's
just a restatement of the status quo. If you think there's confusion, I accept that
statement as an existence proof that there is confusion and I'm happy to see it
clarified. 

∂13-Sep-88  1612	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88  16:12:00 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458655; Tue 13-Sep-88 19:10:49 EDT
Date: Tue, 13 Sep 88 19:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-ACCESS (version 1)
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: CL-CLEANUP@SAIL.Stanford.EDU
In-Reply-To: <8809131930.AA14068@decwrl.dec.com>
Message-ID: <880913191005.8.KMP@GRYPHON.SCRC.Symbolics.COM>

I'll support this, though I would -really- like to see this business of
the test (EQ vs #'EQ) resolved.

Personally, I feel that since the set is non-extensible, we ought to
change it to allow only :EQ, :EQL, or :EQUAL (and permit implementations
to accept other values for compatibility). Then the value returned
by HASH-TABLE-TEST could be deterministically :EQ (or whatever) and
we could do away with the popular Trivial Pursuit (TM) question about
how the test is recognized. I think it would simplify a lot of things.
If people buy this, I will write it up as a separate cleanup item.

∂13-Sep-88  2331	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)  
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Sep 88  23:31:39 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA09763@EDDIE.MIT.EDU>; Wed, 14 Sep 88 02:30:16 EDT
Received: by spt.entity.com (smail2.5); 14 Sep 88 02:11:45 EDT (Wed)
To: CL-Cleanup@SAIL.Stanford.EDU
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, pierson%mist@MULTIMAX.ARPA
In-Reply-To: Kent M Pitman's message of Tue, 13 Sep 88 18:49 EDT <880913184907.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
Message-Id: <8809140211.AA10382@spt.entity.com>
Date: 14 Sep 88 02:11:45 EDT (Wed)
From: gz@spt.entity.com (Gail Zacharias)

It would be a lot easier for implementations to give PROVIDE/REQUIRE
reasonable semantics if CL wasn't so damn specific about how these functions
must be implemented.  As I recall CLtL basically states that PROVIDE must
immediately push the module name onto the user-visible variable *MODULES*,
and REQUIRE must check if the module name is on *MODULES*.  This doesn't leave
much room for improvement, in that any divergence from this proscription could
be detected by some theoretical program manipulating/examining *MODULES*
directly.

Coral decided that in practice the mutually dependent systems problem is more
important than strict conformance, so our REQUIRE checks a separately
maintained list of modules being loaded and punts on them even if they're not
on *MODULES*.  Nobody has ever complained.

From my point of view, the ideal solution would be for *MODULES* to be removed
from the language, or at least make its relationship to PROVIDE/REQUIRE less
immediate.  Then we can talk about what PROVIDE/REQUIRE should do without
worrying about explicit manipulation of *MODULES* by user code.

As long as there is a chance that PROVIDE/REQUIRE could be fixed up, I think
it would be a mistake to state, as this proposal does, that PROVIDE should
appear at the bottom of the file.  Much of the descriptive power of PROVIDE is
lost if you have to put it (and hence the module name) out of view.  It's
certainly easy enough for implementations to achive the desired effect
regardless of where the provide happens to physically occur (if only provide
wasn't specified in terms of immediate effects on *modules*), so why put the
burden on the user.

∂14-Sep-88  0007	CL-Cleanup-mailer 	Re: Exponent sign printing with ~E  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  00:07:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 SEP 88 23:59:47 PDT
Date: 14 Sep 88 00:00 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Exponent sign printing with ~E
In-reply-to: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Tue, 13 Sep 88 15:11 EDT
To: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-CLeanup@Sail.stanford.edu
Message-ID: <880913-235947-1036@Xerox>

To make my filing system happier, I'm going to rename this issue FORMAT-E-EXPONENT-SIGN.

∂14-Sep-88  0123	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  01:23:47 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 SEP 88 01:20:05 PDT
Date: 14 Sep 88 01:20 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
In-reply-to: gz@spt.entity.com (Gail Zacharias)'s message of 14 Sep 88 02:11:45
 EDT (Wed)
To: gz@spt.entity.com (Gail Zacharias)
cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM,
 pierson%mist@MULTIMAX.ARPA
Message-ID: <880914-012005-1082@Xerox>

What I remember from a subcommittee meeting (that only included a small subset
of the people on the mailing list, unfortunately) is that we informally agreed
to do something of the sort; that is, to remove any operative definition of
PROVIDE and REQUIRE. The exact wording is tricky. 

The issue I think is whether we think that programs that have recursive
requirements should be portable. I think so -- it is consistent with current
practice and the users issue.

I wonder if part of the way of handling this is to be more explicit about what
we all know: that LOAD, PROVIDE and REQUIRE have to cooperate to make this work
right.

∂14-Sep-88  0244	CL-Cleanup-mailer 	Re: Issue: DECODE-UNIVERSAL-DAYLIGHT (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  02:44:28 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 SEP 88 02:43:10 PDT
Date: 14 Sep 88 02:43 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECODE-UNIVERSAL-DAYLIGHT (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Mon, 20 Jun 88 17:09 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880914-024310-1128@Xerox>

There's been no discussion on this issue since last June.

The wording "If {\arg time-zone\/} is not specified, the current time zone is
used." seems to me to be justification to say that leaving the time zone out is
the same as supplying it.

The Xerox implementor assumed LIKE-ENCODE also.

I'd like a few more words explaining that the test case only is useful when
daylight savings is in effect (or else supplying constant values that are known
to be in the daylight savings time range.)

I think test cases can either be 'automatic' -- you can just run them, but they
take a while to figure out, or 'explanatory' -- they illustrate the point. This
one isn't either yet.


∂14-Sep-88  0635	CL-Cleanup-mailer 	RE: Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88  06:35:16 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA00316; Wed, 14 Sep 88 06:33:39 PDT
Date: Wed, 14 Sep 88 06:33:39 PDT
Message-Id: <8809141333.AA00316@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: KMP@stony-brook.scrc.symbolics.com
Subject: RE: Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)

Allowing END to be NIL across the board is a good idea.  However,
the current PARSE-INTEGER doesn't say NIL is supposed to mean anything,
so I think this would be a change in the functionality.  So another
cleanup item would be appropriate.  You might want to generalize and
talk about the uses of all the normal "sequence" keyword arguments.
For example, I don't think CLtL says that the predicates and :key's
may get called any number of times in any order, except when describing
SEARCH.  I think that should be stated for all the sequence functions.

			---Walter

∂14-Sep-88  0651	CL-Cleanup-mailer 	RE: Issue: TAILP-NIL (Version 2)    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88  06:51:25 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA00737; Wed, 14 Sep 88 06:49:27 PDT
Date: Wed, 14 Sep 88 06:49:27 PDT
Message-Id: <8809141349.AA00737@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: KMP@stony-brook.scrc.symbolics.com
Subject: RE: Issue: TAILP-NIL (Version 2)

Well, that's a surprise.  I thought I had spotted a simple, non-controversial
item from Guy's list, which really needed to be done due to the inconsistency
in CLtL.

I must admit that I hadn't tried TAILP on a Symbolics machine.  I had just
read the description of TAILP in an older manual, which gave the possible
implementation I originally included (definition "A").  I guess I was guilty
of propagating false concepts.

Frankly, I don't really care which way we choose.  If several other would
prefer TAILP-NIL:T, then let's delete the TAILP-NIL:NIL proposal.  But
let's not spend a lot of time on it.

			---Walter

∂14-Sep-88  0721	CL-Cleanup-mailer 	RE: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)   
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88  07:21:29 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA02973; Wed, 14 Sep 88 07:20:09 PDT
Date: Wed, 14 Sep 88 07:20:09 PDT
Message-Id: <8809141420.AA02973@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: pierson%mist@multimax.arpa
Subject: RE: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)

This looks pretty good, except I think many implementations would
prefer not to have a requirement that *TERMINAL-IO* be a Common Lisp
stream.  Already most implementations bind *TERMINAL-IO* to
implementation dependent streams, and I think in this case it's
best to continue the status quo.  Another way to look at this issue
is that I don't see any advantage to forcing *TERMINAL-IO* to
be yet another synonym stream or a two-way-stream (or whatever CL
stream type) which really just uses the implementation dependent
stream after all.

			---Walter

∂14-Sep-88  0730	CL-Cleanup-mailer 	Issue: STREAM-CAPABILITIES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88  07:30:33 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA03471; Wed, 14 Sep 88 07:29:16 PDT
Date: Wed, 14 Sep 88 07:29:16 PDT
Message-Id: <8809141429.AA03471@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: STREAM-CAPABILITIES

I think I mostly agree with Larry that STREAM-SAME-xxx-P (or STREAM-xxx-
ID-LIST) aren't needed.  His reasons aren't clear from the write-up;
I believe that such functionality would be nice but too difficult to
provide in some implementations and therefore shouldn't be part of
the language.  For example, what happens with streams working on
remote files?
			---Walter

∂14-Sep-88  0748	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88  07:48:10 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA04055; Wed, 14 Sep 88 07:46:51 PDT
Date: Wed, 14 Sep 88 07:46:51 PDT
Message-Id: <8809141446.AA04055@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: PACKAGE-CLUTTER

I think this issue also needs to address the default value for :USEd
packages.  (Or else the name should be changed to something more
specific like LISP-PACKAGE-CONTENTS.)

If we allow the default value for :USE to be implementation dependent,
I think users would be most happy.  If someone really wants just Common
Lisp, they would be able to say :USE '("LISP").  Otherwise they would
be able to get the same environment that the USER package has, since
implementations would have the flexibility to make them the same and
as rich as they would like to make them.

I think this is what resulted from those CL discussions a few years ago.
I'd guess that this is also what several implementations do.  Anyone
care to comment?

			---Walter

∂14-Sep-88  0804	CL-Cleanup-mailer 	Issue: ALIST-NIL
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88  08:03:58 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA05199; Wed, 14 Sep 88 08:02:38 PDT
Date: Wed, 14 Sep 88 08:02:38 PDT
Message-Id: <8809141502.AA05199@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: ALIST-NIL

I've put out an open query of our internal users to see if anyone
actually uses this "feature".  I'd like to support the proposal
ALIST-NIL:DISALLOW.

Another reason for adopting this change is that the xASSOCx functions
would typically be faster in many implementations, since they wouldn't
have to explicitly check for atoms or NIL's.  Since association lists
are often heavily used, the proposal would also have a positive impact
on performance.

			---Walter

∂14-Sep-88  0924	CL-Cleanup-mailer 	Issue: ALIST-NIL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Sep 88  09:24:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458961; Wed 14-Sep-88 12:22:48 EDT
Date: Wed, 14 Sep 88 12:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ALIST-NIL
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809141502.AA05199@decwrl.dec.com>
Message-ID: <19880914162223.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 14 Sep 88 08:02:38 PDT
    From: vanroggen%aitg.DEC@decwrl.dec.com

    I've put out an open query of our internal users to see if anyone
    actually uses this "feature".  I'd like to support the proposal
    ALIST-NIL:DISALLOW.

    Another reason for adopting this change is that the xASSOCx functions
    would typically be faster in many implementations, since they wouldn't
    have to explicitly check for atoms or NIL's.  Since association lists
    are often heavily used, the proposal would also have a positive impact
    on performance.

To my surprise, we didn't have any trouble implementing this feature
(ASSOC skips over NILs where it expects conses) in hardware in the
Ivory microprocessor.  It didn't even slow it down.

This is not to say that I think a less tightly integrated Lisp
implementation would not be slowed down by this feature.  Note,
however, that you don't have to check for NIL until after you
think you've found the matching CAAR (assuming you have a typical
implementation where CAR of NIL works with the same open-coded
instructions as CAR of a cons), so the slowdown is not proportional
to the length of the list.

I'm neutral on the cleanup issue.

∂14-Sep-88  0934	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Sep 88  09:33:56 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458973; Wed 14-Sep-88 12:32:42 EDT
Date: Wed, 14 Sep 88 12:32 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809141446.AA04055@decwrl.dec.com>
Message-ID: <19880914163208.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 14 Sep 88 07:46:51 PDT
    From: vanroggen%aitg.DEC@decwrl.dec.com

    I think this issue also needs to address the default value for :USEd
    packages.  (Or else the name should be changed to something more
    specific like LISP-PACKAGE-CONTENTS.)

    If we allow the default value for :USE to be implementation dependent,
    I think users would be most happy.  If someone really wants just Common
    Lisp, they would be able to say :USE '("LISP").  Otherwise they would
    be able to get the same environment that the USER package has, since
    implementations would have the flexibility to make them the same and
    as rich as they would like to make them.

    I think this is what resulted from those CL discussions a few years ago.
    I'd guess that this is also what several implementations do.  Anyone
    care to comment?

Symbolics defaults :USE the way CLtL specifies, that is, to just the
LISP package.  I'm really not sure that I agree with you that the
default should be changed.  A program that wants a specific set of
implementation dependent extensions really ought to ask for them by name
[i.e. (make-package 'foo :use '(gulf-and-western-common-lisp))] so it
can be sure of what it's getting.  A program that wants the same
extensions as the user package can do so [i.e. (make-package 'foo
:use (package-use-list (find-package 'user)))].

I'm not sure how much this default matters.  I don't think I have ever
seen a defpackage that didn't specify :use explicitly.

∂14-Sep-88  0934	CL-Cleanup-mailer 	RE: Issue: ALIST-NIL 
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88  09:33:58 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA09817; Wed, 14 Sep 88 09:32:15 PDT
Date: Wed, 14 Sep 88 09:32:15 PDT
Message-Id: <8809141632.AA09817@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: Moon@stony-brook.scrc.symbolics.com
Subject: RE: Issue: ALIST-NIL

  Note,
  however, that you don't have to check for NIL until after you
  think you've found the matching CAAR (assuming you have a typical
  implementation where CAR of NIL works with the same open-coded
  instructions as CAR of a cons), so the slowdown is not proportional
  to the length of the list.

That's a clever optimization, but I thought it would be improper to
FUNCALL the predicate on an apparent NIL that really isn't in the
association list.  But it would work if we special cased the code
if we knew the predicate was innocous, like EQL or EQ.

			---Walter

∂14-Sep-88  0944	CL-Cleanup-mailer 	Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Sep 88  09:44:36 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458992; Wed 14-Sep-88 12:43:44 EDT
Date: Wed, 14 Sep 88 12:42 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880914124243.1.KMP@GRYPHON.SCRC.Symbolics.COM>

Issue:        RANGE-OF-START-AND-END-PARAMETERS
References:   COUNT (p257), COUNT-IF (p257), COUNT-IF-NOT (p257),
	      DELETE (p257), DELETE-DUPLICATES (p254), DELETE-IF (p254),
	      DELETE-IF-NOT (p254), FILL (p252), FIND (p257), FIND-IF (p257),
	      FIND-IF-NOT (p257), MAKE-STRING-INPUT-STREAM (p330),
	      MISMATCH (p257), NSTRING-CAPITALIZE (p304), 
	      NSTRING-DOWNCASE (p304), NSTRING-UPCASE (p304), SUBSTITUTE (p255),
	      NSUBSTITUTE-IF (p256), NSUBSTITUTE-IF-NOT (p256), 
	      PARSE-INTEGER (p381), PARSE-NAMESTRING (p414), POSITION (p257),
	      POSITION-IF (p257), POSITION-IF-NOT (p257), 
	      READ-FROM-STRING (p381), REDUCE (p251), REMOVE (p253), 
	      REMOVE-DUPLICATES (p254), REMOVE-IF (p253), REMOVE-IF-NOT (p253),
	      REPLACE (p252), SEARCH (p258), STRING-CAPITALIZE (p303),
	      STRING-EQUAL (p301), STRING-DOWNCASE (p303), STRING-GREATERP (p302),
	      STRING-LESSP (p302), STRING-NOT-EQUAL (p302),
	      STRING-NOT-GREATERP (p302), STRING-NOT-LESSP (p302),
	      STRING-UPCASE (p303), STRING/= (p301), STRING< (p301), 
	      STRING<= (p301), STRING= (p300), STRING> (p301), STRING>= (p301),
	      SUBSEQ (p248), SUBSTITUTE (p255), SUBSTITUTE-IF (p255), 
	      SUBSTITUTE-IF-NOT (p255), WRITE-LINE (p384), WRITE-STRING (p384)
Category:     CLARIFICATION
Edit history: 14-Sep-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  CLtL is not always clear about the possible values which the START and END
  parameters of built-in Common Lisp can take.

Proposal (RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL):

  Clarify that for functions permitting a parameter named START, START1,
  or START2 which delimits the beginning point in a sequence to be
  considered for some operation, that paremeter must be a non-negative
  integer. If the argument is optional or key (as is the case for all
  functions referenced above except SUBSEQ), the value will default to
  0 if not supplied. It is not permissible to pass NIL as this argument.

  Clarify that for functions permitting a parameter named END, END1,
  or END2 which delimits the end point in a sequence to be considered
  for some operation, that paremeter must be a non-negative integer
  indicating a termination point or NIL indicating the last element
  in the sequence. If the argument is optional or key (as is the case
  for all functions referenced above), the value will default to NIL
  if not supplied. Supplying NIL is, therefore, equivalent to not
  supplying this argument.

Test Case:

  (SEARCH "F" "FOO" :START1 NIL) is an error.

  (SEARCH "F" "FOO" :START2 0) is permissible and is equivalent to
  (SEARCH "F" "FOO")

  (SEARCH "F" "FOO" :END2 NIL) is permissible and is equivalent to
  (SEARCH "F" "FOO")

Rationale:

  To keep data flow between programs from becoming excessively complicated,
  it's a good idea to specify what the default values are so that they can
  be passed explicitly rather than requiring an alternate calling sequence
  for all possible cases where the value might need to default.

Current Practice:

  Symbolics Genera implements the proposed behavior.

Cost to Implementors:

  Hopefully most implementations already do this. Those that do not will
  probably have to make quite a number of small changes to both the code
  for these functions and to any associated compiler optimizers.

Cost to Users:

  This change is upward compatible with existing user code. Any program
  which did not conform to this proposal was already not portable.

Cost of Non-Adoption:

  Subtle gratuitous differences in the handling of these arguments would
  continue to be a possibility and a barrier to portability.

Benefits:

  The language would be more regular and well-defined.

Aesthetics:

  If it makes things clearer, it's an improvement.

Discussion:

  Pitman supports RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL.

∂14-Sep-88  1010	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Sep 88  10:10:39 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 459027; Wed 14-Sep-88 13:09:24 EDT
Date: Wed, 14 Sep 88 13:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER
To: Moon@STONY-BROOK.SCRC.Symbolics.COM,
    vanroggen%aitg.DEC@decwrl.dec.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19880914163208.0.MOON@EUPHRATES.SCRC.Symbolics.COM>,
             <8809141446.AA04055@decwrl.dec.com>
Message-ID: <880914130830.2.KMP@GRYPHON.SCRC.Symbolics.COM>

I don't think the idea of making the default for :USE be implementation
dependent is a very good one. It introduces incompatibility to no good
end.

In Cloe, LISP:IN-PACKAGE defaults to :USE "LISP" but CLOE:IN-PACKAGE
defaults to :USE "CLOE". Since the USER package uses CLOE, doing
(IN-PACKAGE "FOO") in that package is the same as doing 
(CLOE:IN-PACKAGE "FOO" :USE "CLOE").

Users must do (LISP:IN-PACKAGE "FOO") if they want the effect of
(LISP:IN-PACKAGE "FOO" :USE "LISP") without specifying an explicit
:USE argument.

Or they can, as various people have recommended in this discussion, do
(IN-PACKAGE "FOO" :USE "LISP"). This will get them package something
that uses "LISP" whether they're getting CLOE:IN-PACKAGE or
LISP:IN-PACKAGE.

This may seem a little complicated, but practical experience shows that
it feels like the right thing. After all, we're not changing the meaning
of LISP symbols, so anyone who requests LISP explicitly gets exactly
what CLtL tells them to expect.

∂14-Sep-88  1020	CL-Cleanup-mailer 	RE: Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88  10:20:39 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA12552; Wed, 14 Sep 88 10:19:01 PDT
Date: Wed, 14 Sep 88 10:19:01 PDT
Message-Id: <8809141719.AA12552@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: KMP@stony-brook.scrc.symbolics.com
Subject: RE: Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)

Did anyone write up SUBSEQ-OUT-OF-BOUNDS before?  It seems RANGE...
would subsume the SUBSEQ... proposal if it also stated that the END value
had to be greater than or equal to the START, and also be no greater than
the LENGTH of the sequence.

			---Walter

∂14-Sep-88  1031	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  10:31:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 10:17:45 PDT
Date: Wed, 14 Sep 88 09:55 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU, pierson%mist@MULTIMAX.ARPA
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <880913184907.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880914165511.9.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

I sure would like to see require and provide removed from the language.
As a maintainer of a portable program, people are always asking me to
"use them".  The only thing is that I have never been able to figure out
a way to do that that works in the 14 Common Lisp implementations I know
of.  I also can't understand what it could possibly mean for programs
that span multiple files.

-------

∂14-Sep-88  1130	CL-Cleanup-mailer 	Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Sep 88  11:30:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 459118; Wed 14-Sep-88 14:29:18 EDT
Date: Wed, 14 Sep 88 14:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880914124243.1.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880914182854.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

I approve RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL.
I think it would be good to mention explicitly that an end parameter
must be >= its corresponding start parameter, just to keep things
perfectly clear.

∂14-Sep-88  1226	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (version 2)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  12:25:57 PDT
Received: from Burger.ms by ArpaGateway.ms ; 14 SEP 88 12:08:35 PDT
Date: 14 Sep 88 12:07 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFPACKAGE (version 2)
In-reply-to: Masinter.pa's message of 8 Jun 88 19:16 PDT
To: CL-Cleanup@Sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <880914-120836-2043@Xerox>

There's been no discussion on this proposal since 8 Jun, when it was distributed
in draft form to X3J13. I am taking this to mean that people are not unhappy
with the version of 23-Mar-88 -- at least not unhappy enough to complain or
suggest improvements.


∂14-Sep-88  1233	CL-Cleanup-mailer 	Re: issue TRUENAME-SYNTAX-ONLY 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Sep 88  12:33:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 459177; Wed 14-Sep-88 15:31:43 EDT
Date: Wed, 14 Sep 88 15:31 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue TRUENAME-SYNTAX-ONLY
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809131614.AA18524@defun.utah.edu>
Message-ID: <19880914193105.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 13 Sep 88 10:14:47 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Mon, 12 Sep 88 21:12 EDT
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > 
    >     TRUENAME [with the :SYNTAX-ONLY option] applies any
    >     file-name translations performed by the file system and returns the
    >     "true name" of the specified file as a pathname.
    > 
    > Should it be left this vague, and specifically defined to be
    > implementation-dependent, or should some axioms that it must satisfy be
    > listed?  For example, should TRUENAME with and without the :SYNTAX-ONLY
    > option be required to return the same answer in the case when the latter
    > does not signal an error?  I suspect it may have to be vague (see below).

    The language in CLtL is already vague, but as far as I know nobody has
    been complaining about it.  At least for VMS, I'd say that TRUENAME
    shouldn't have to return the same answer in both cases; the reason is
    that if you don't supply an explicit version number in the input
    pathname and you tell TRUENAME to match an existing file, it ought to
    fill in the version number for that file; but if you're only checking
    syntax it doesn't have any way of knowing what the version number
    should be.

I see.  Okay, let's not try axioms.  Now that I read it again, your
description of :SYNTAX-ONLY can't be right, though.  It refers to
"the specified file" but you aren't specifying any particular file.
Perhaps this can only be defined in terms of a VAX/VMS example.
Or perhaps it can be defined by saying that where file name components
are missing or wild or :NEWEST or :OLDEST, the :SYNTAX-ONLY option
tells you what's common to the truenames of all possible files with
all possible values for those components, whereas without :SYNTAX-ONLY
you specify a single specific file (after merging with a default)
and get just the truename of that exact file.  In fact what I just
said won't work in file systems with links, nor in those with complex
pattern-matching translation mechanisms (ITS has both, for example).
Perhaps you can come up with a better description of what :SYNTAX-ONLY
does?  I appear to have struck out.

    >     (3) Clarify that coercion of a stream to a pathname (either implicitly
    >     or by a call to the function PATHNAME) returns a pathname representing
    >     the "true name" of the file.
    > 
    > This directly contradicts the example at the top of CLtL p.414.  I think
    > you should just remove this point.

    Sorry, "clarify" was the wrong word here.  Except for the example you
    cite, CLtL doesn't explicitly address the issue of what coercing a
    stream to a pathname really does.  The idea is, that since OPEN must
    perform the equivalent of TRUENAME anyway, it can just as well create
    a stream that remembers the "true name" of the file as the pathname
    that was passed to OPEN.  As I recall, VaxLisp already behaves as
    proposed.  However, if people would prefer it that way, I could change
    this item to leave this behavior explicitly vague.

You're proposing that TRUENAME of a stream and PATHNAME of a stream behave
identically.  I think CLtL means for PATHNAME of a stream to return the
argument that was given to OPEN (after merging with the default).  I'm a
little surprised the Cleanup group haven't addressed this already.

    >     (4) Clarify that file-name translation on pathnames is not performed
    >     under any other circumstances except those listed above.
    > 
    > I can't figure out what this means operationally, but I suspect that if
    > I could figure it out, I would disagree with it.  I suggest removing this
    > point, unless you had something specific in mind, in which case I suggest
    > rewording this point.

    What I had in mind was that none of the zillion other pathname
    functions (which I was too lazy to list) would be allowed to do file
    name translation; nor would coercing a string to a pathname.  For
    example, (pathname-device "foo:bar.baz") on VMS would always return
    "foo", even if it's defined as a logical name.

I agree with that, but I think it can only be said explicitly, not by
implication from "any other circumstances."  For example, does "any other
circumstances" include all implementation extensions and all user-written code?

    >     Cost to implementors:
    > 
    >     Minor.  VMS provides an RMS system call ....
    > 
    > This overlooks the case of implementations that access VMS files via a
    > network file protocol.  The cost to implementors might be near infinite if
    > the particular network file protocol they are using does not provide any
    > way to perform this operation.  This suggests that the definition of the
    > :SYNTAX-ONLY option to TRUENAME should be left sufficiently vague that
    > an implementation that always returned its first argument would be valid.
    > A lot of the Common Lisp file system interface has to be like that.

    That's a good point -- I'd forgotten about networking from non-VMS
    hosts.  However, if an implementation doesn't expand logical names
    fully when requested to do so, users are going to run into the same
    kind of strange behavior (i.e., within MERGE-PATHNAMES) that prompted
    me to bring this up in the first place.  

Yes, many network file access protocols are very poorly designed.  I don't
think X3J13 is going to fix that.

					     I don't see much point in
    adding this functionality to the language unless the spec is tight
    enough to ensure that it's going to solve the problem it was intended
    to.

That could be a problem, especially if the problem it's intended to solve
can't be precisely articulated in an implementation-independent way.

    > It would be at least as reasonable to argue that checking for syntax
    > errors is properly done during file name parsing (i.e. conversion from a
    > string to a pathname object), as with all other Common Lisp syntax.

    Yes, of course.  However, it's possible to construct pathnames which
    might contain "syntax errors" by other means as well.  For instance, if
    you merge pathnames from two different hosts you might end up with
    subfields that are too long, illegal characters, etc.

I should have said parsing and merging and component setting, i.e. all
forms of pathname construction.

∂14-Sep-88  1321	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 1)
Received: from ALLEGHENY.SCRC.Symbolics.COM ([128.81.41.45]) by SAIL.Stanford.EDU with TCP; 14 Sep 88  13:21:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106652; Wed 14-Sep-88 15:48:20 EDT
Date: Wed, 14 Sep 88 15:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-ACCESS (version 1)
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809131930.AA14068@decwrl.dec.com>
Message-ID: <19880914194817.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

I don't see anything immediately wrong with this, but I have a vague
recollection that the cleanup committee discussed and rejected a
similar proposal once before.  If so, we should find out why.
Could it be that it's not clear precisely what some of these values
mean?

∂14-Sep-88  1322	CL-Cleanup-mailer 	not about Issue: HASH-TABLE-ACCESS (version 1)
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 14 Sep 88  13:21:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 390886; Wed 14-Sep-88 15:46:40 EDT
Date: Wed, 14 Sep 88 15:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: not about Issue: HASH-TABLE-ACCESS (version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: vanroggen%aitg.DEC@decwrl.dec.com, CL-CLEANUP@SAIL.Stanford.EDU
In-Reply-To: <880913191005.8.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880914194605.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 13 Sep 88 19:10 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    I'll support this, though I would -really- like to see this business of
    the test (EQ vs #'EQ) resolved.

    Personally, I feel that since the set is non-extensible, we ought to
    change it to allow only :EQ, :EQL, or :EQUAL (and permit implementations
    to accept other values for compatibility). Then the value returned
    by HASH-TABLE-TEST could be deterministically :EQ (or whatever) and
    we could do away with the popular Trivial Pursuit (TM) question about
    how the test is recognized. I think it would simplify a lot of things.
    If people buy this, I will write it up as a separate cleanup item.

I am strongly opposed to this.  It would be horrible for this to be
incompatible with every other :TEST keyword argument in the language.
Also I deny that it is non-extensible.  Common Lisp doesn't currently
provide a way to make it extensible, but in fact that is very easy to
add; SCL has it.

∂14-Sep-88  1322	CL-Cleanup-mailer 	Re: issue TRUENAME-SYNTAX-ONLY 
Received: from ALLEGHENY.SCRC.Symbolics.COM ([128.81.41.45]) by SAIL.Stanford.EDU with TCP; 14 Sep 88  13:22:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106654; Wed 14-Sep-88 15:54:21 EDT
Date: Wed, 14 Sep 88 15:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue TRUENAME-SYNTAX-ONLY
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809131614.AA18524@defun.utah.edu>
Supersedes: <19880914193105.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: More information, after delving into KMP's electronic basement on my hands and knees
Message-ID: <19880914195416.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 13 Sep 88 10:14:47 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Date: Mon, 12 Sep 88 21:12 EDT
    > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    > 
    >     TRUENAME [with the :SYNTAX-ONLY option] applies any
    >     file-name translations performed by the file system and returns the
    >     "true name" of the specified file as a pathname.
    > 
    > Should it be left this vague, and specifically defined to be
    > implementation-dependent, or should some axioms that it must satisfy be
    > listed?  For example, should TRUENAME with and without the :SYNTAX-ONLY
    > option be required to return the same answer in the case when the latter
    > does not signal an error?  I suspect it may have to be vague (see below).

    The language in CLtL is already vague, but as far as I know nobody has
    been complaining about it.  At least for VMS, I'd say that TRUENAME
    shouldn't have to return the same answer in both cases; the reason is
    that if you don't supply an explicit version number in the input
    pathname and you tell TRUENAME to match an existing file, it ought to
    fill in the version number for that file; but if you're only checking
    syntax it doesn't have any way of knowing what the version number
    should be.

I see.  Okay, let's not try axioms.  Now that I read it again, your
description of :SYNTAX-ONLY can't be right, though.  It refers to
"the specified file" but you aren't specifying any particular file.
Perhaps this can only be defined in terms of a VAX/VMS example.
Or perhaps it can be defined by saying that where file name components
are missing or wild or :NEWEST or :OLDEST, the :SYNTAX-ONLY option
tells you what's common to the truenames of all possible files with
all possible values for those components, whereas without :SYNTAX-ONLY
you specify a single specific file (after merging with a default)
and get just the truename of that exact file.  In fact what I just
said won't work in file systems with links, nor in those with complex
pattern-matching translation mechanisms (ITS has both, for example).
Perhaps you can come up with a better description of what :SYNTAX-ONLY
does?  I appear to have struck out.

    >     (3) Clarify that coercion of a stream to a pathname (either implicitly
    >     or by a call to the function PATHNAME) returns a pathname representing
    >     the "true name" of the file.
    > 
    > This directly contradicts the example at the top of CLtL p.414.  I think
    > you should just remove this point.

    Sorry, "clarify" was the wrong word here.  Except for the example you
    cite, CLtL doesn't explicitly address the issue of what coercing a
    stream to a pathname really does.  The idea is, that since OPEN must
    perform the equivalent of TRUENAME anyway, it can just as well create
    a stream that remembers the "true name" of the file as the pathname
    that was passed to OPEN.  As I recall, VaxLisp already behaves as
    proposed.  However, if people would prefer it that way, I could change
    this item to leave this behavior explicitly vague.

You're proposing that TRUENAME of a stream and PATHNAME of a stream behave
identically.  I think CLtL means for PATHNAME of a stream to return the
argument that was given to OPEN (after merging with the default).  I'm a
little surprised the Cleanup group haven't addressed this already.
LATER: Ah, I see they have.  Already-accepted issue PATHNAME-STREAM
clarified this, in a way consistent with what I said just above.

    >     (4) Clarify that file-name translation on pathnames is not performed
    >     under any other circumstances except those listed above.
    > 
    > I can't figure out what this means operationally, but I suspect that if
    > I could figure it out, I would disagree with it.  I suggest removing this
    > point, unless you had something specific in mind, in which case I suggest
    > rewording this point.

    What I had in mind was that none of the zillion other pathname
    functions (which I was too lazy to list) would be allowed to do file
    name translation; nor would coercing a string to a pathname.  For
    example, (pathname-device "foo:bar.baz") on VMS would always return
    "foo", even if it's defined as a logical name.

I agree with that, but I think it can only be said explicitly, not by
implication from "any other circumstances."  For example, does "any other
circumstances" include all implementation extensions and all user-written code?

    >     Cost to implementors:
    > 
    >     Minor.  VMS provides an RMS system call ....
    > 
    > This overlooks the case of implementations that access VMS files via a
    > network file protocol.  The cost to implementors might be near infinite if
    > the particular network file protocol they are using does not provide any
    > way to perform this operation.  This suggests that the definition of the
    > :SYNTAX-ONLY option to TRUENAME should be left sufficiently vague that
    > an implementation that always returned its first argument would be valid.
    > A lot of the Common Lisp file system interface has to be like that.

    That's a good point -- I'd forgotten about networking from non-VMS
    hosts.  However, if an implementation doesn't expand logical names
    fully when requested to do so, users are going to run into the same
    kind of strange behavior (i.e., within MERGE-PATHNAMES) that prompted
    me to bring this up in the first place.  

Yes, many network file access protocols are very poorly designed.  I don't
think X3J13 is going to fix that.

					     I don't see much point in
    adding this functionality to the language unless the spec is tight
    enough to ensure that it's going to solve the problem it was intended
    to.

That could be a problem, especially if the problem it's intended to solve
can't be precisely articulated in an implementation-independent way.

    > It would be at least as reasonable to argue that checking for syntax
    > errors is properly done during file name parsing (i.e. conversion from a
    > string to a pathname object), as with all other Common Lisp syntax.

    Yes, of course.  However, it's possible to construct pathnames which
    might contain "syntax errors" by other means as well.  For instance, if
    you merge pathnames from two different hosts you might end up with
    subfields that are too long, illegal characters, etc.

I should have said parsing and merging and component setting, i.e. all
forms of pathname construction.

∂14-Sep-88  1329	CL-Cleanup-mailer 	Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
Received: from ALLEGHENY.SCRC.Symbolics.COM ([128.81.41.45]) by SAIL.Stanford.EDU with TCP; 14 Sep 88  13:29:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106665; Wed 14-Sep-88 16:28:05 EDT
Date: Wed, 14 Sep 88 16:27 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
To: CL-Cleanup@sail.stanford.edu
References: <8807200836.AA02976@bhopal.lucid.com>,
            <19880719152249.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
            <19880719213809.1.GREENWALD@SWALLOW.SCRC.Symbolics.COM>,
            <870402170955.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19880914202753.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

Issue:         CONTAGION-ON-NUMERICAL-COMPARISONS

References:    CLtL p.194

Category:      CHANGE

Edit history:  Version 1, 14-Sep-88, Moon

Problem description:

The numerical contagion rules specified on CLtL p.194 make it impossible
for the numerical comparison functions to be transitive when given
arguments of mixed floating and rational types (see example below).

Proposal (CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE):
	  
Instead of using the same contagion rule both for combining functions
and for comparing functions, make the present rule apply only to
combining functions and add the following rule:  When rational and
floating-point numbers are compared by a numerical function, the
function RATIONAL is called to convert the floating-point number to a
rational and then an exact comparison is performed.  In the case of
complex numbers (RATIONAL is for some unknown reason only allowed on
reals), the real and imaginary parts are handled individually.

It is of course valid to use a more efficient implementation than
actually calling RATIONAL, as long as the result of the comparison is
the same.

Test Cases/Examples:

(defvar a (/ 10.0 single-float-epsilon))

(= a (1+ (floor a)))
should be NIL, since 
(= a (floor a))
is certainly T and
(= (floor a) (1+ (floor a)))
is certainly NIL.  However, by the rule of floating-point contagion,
(= a (1+ (floor a)))
is the same as 
(= a (float (1+ (floor a)) a))
and the latter form is certainly T.

To understand this example better, it helps to realize that
(= a (+ a 1.0))
is always true, by the definition of single-float-epsilon.

Here is a second example:

(defvar i (floor a))

(<= a (+ i 1)) is T.
(< (+ i 1) (+ i 2)) is T.
(<= (+ i 2) a) is T by CLtL, NIL by this proposal.
Thus CLtL requires
  a <= i+1 < i+2 <= a
which ought to imply
  a < a
which is absurd.

Rationale:

Transitivity of = and of < are important to many algorithms.  What CLtL
says now was probably not intentional, but just the result of thinking
that comparing and combining could be lumped together without really
thinking about it.

Without this change, it is impossible to extend the :TEST argument to
MAKE-HASH-TABLE to allow = or EQUALP, since there could be two table
entries with rational keys that are not =, then GETHASH could be
presented with a floating-point argument that is = to both keys.

Current practice:

Lucid is said to implement the proposal.  As far as I know all other
implementations do what CLtL currently says.

Cost to Implementors:

This requires a change in what is likely to be intricate and
implementation-dependent code.  However, the total effort should
be small compared to the cost of writing that code originally.

Cost to Users:

This is an incompatible change.  It's difficult to know if any users
are depending on the current behavior.  It seems likely that most users
would expect the proposed behavior, and may be wondering why their
programs don't quite work when the numbers get large.

Cost of non-adoption:

Comparison functions in Common Lisp will be non-transitive.

Benefits:

Comparison functions in Common Lisp will be transitive.

Esthetics:

Having two rules of floating-point contagion may seem less esthetic,
but I'm certain that having the comparison functions behave in a more
mathematically correct fashion outweighs that esthetically.

Discussion:

Everyone who has expressed an opinion has thought this was the right
thing for years, but we never got around to writing it up as a cleanup
proposal.

∂14-Sep-88  1458	CL-Cleanup-mailer 	Re: issue TRUENAME-SYNTAX-ONLY 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Sep 88  14:58:13 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA15192; Wed, 14 Sep 88 15:56:52 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
	id AA19228; Wed, 14 Sep 88 15:56:45 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809142156.AA19228@defun.utah.edu>
Date: Wed, 14 Sep 88 15:56:44 MDT
Subject: Re: issue TRUENAME-SYNTAX-ONLY
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
        cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 14 Sep 88 15:54 EDT

> Date: Wed, 14 Sep 88 15:54 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> Perhaps you can come up with a better description of what :SYNTAX-ONLY
> does?  I appear to have struck out.
>

This issue seems to be getting bogged down in a morass; therefore, I
would like to withdraw my proposal.  You've already indicated that you
would oppose the proposal on the grounds that it would take a
"near-infinite" amount of time to implement unless the behavior is
explicitly left vague, so there doesn't seem much point to my trying
to further clarify what the function must do. 

> 					     I don't see much point in
>     adding this functionality to the language unless the spec is tight
>     enough to ensure that it's going to solve the problem it was intended
>     to.
> 
> That could be a problem, especially if the problem it's intended to solve
> can't be precisely articulated in an implementation-independent way.

I think you're confusing "implementation-independent" with
"file-system-independent".  As I have grumbled about before, all of
the pathname functions have this problem, not just the proposed
extension to TRUENAME.  I think that the only alternative is to come
up with rules that all implementations must obey for specific file
systems: For files on BSD Unix hosts, the following values may be
supplied for such-and-such a pathname component.  For files on VMS
hosts, this function returns X; for files on an MS-DOS host, the
function returns Y.  Unless and until the standard goes into this kind
of detail, I don't think that *any* of the Common Lisp pathname
functions (except for coercion between namestrings and pathname
objects) can be used portably across implementations, even
implementations running on the same host.  Granted, tightening up the
spec would cause implementors more work, but without it you might as
well throw out the pathname functions entirely, for all the good they
do users who are trying to write portable programs. 

-Sandra
-------

∂14-Sep-88  2011	CL-Cleanup-mailer 	Re: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  20:11:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 20:00:45 PDT
Date: 14 Sep 88 20:00 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
In-reply-to: Masinter.pa's message of 8 Jun 88 15:24 PDT
To: cl-cleanup@sail.stanford.edu
Message-ID: <880914-200045-1692@Xerox>

The minutes from the June meeting say "The discussion of
DEFSTRUCT-DEFAULT-VALUE-EVALUATION led to  no resolution of opinion so it was
decided not to bring the proposal to a motion."

I cannot recall what, if any, controversy was associated with this proposal.
JonL had some additional comments, but I didn't see that they would require any
changes to this issue per se (correct me if I am wrong.)

To refresh your memory:

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


Problem Description:

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

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

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


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

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

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

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


Test Case:

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

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


Rationale:

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

Any existing confusion should be clarified by this proposal.


Current Practice:

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


Cost to Implementors:

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


Cost to Users:

None.


Benefits:

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


Aesthetics:

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


Discussion: 

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

!
Additional notes:

Several members of the cleanup committee endorsed this proposal.

JonL added:

You can add to the "Current Practice:" section:

    LUCID does not evaluate the default initialization form unless it is 
    needed; even when it is needed, the type checking is not done at all.
    However, at structure definition time, if an initial value form is
    constanp and doesn't satisfy the :type specification, a warning message
    is printed.

Oddly enough, Lucid's interpreter ensures that SETF's of slots obey the
:type specifier, even though init-forms aren't checked.  Furthermore, in 
safety levels 2 or higher, the compiled code will do minimal "memory-
integrity" type checking for SETF's (which is what I suspect the various 
special-purpose microcoded machines do); however except for low-level numeric
types, this is rarely equivalent to what a full type check would do.

I have long suggested that there should be at least one mode of operation 
such that all :type information is checked when setting values into structure
slots (setf as well as initialization).  Some have suggested that this mode 
could be "when running interpretively, or when when compiled with the highest
degree of SAFETY and lower degrees of SPEED."  However, since the wording of 
CLtL p310 suggests that the :type slot options is merely a DECLARE, and since
some vendors effectively ignore any and all declarations [except for SPECIAL],
then this suggestion hasn't reached proposal stage yet.

∂14-Sep-88  2207	CL-Cleanup-mailer 	Re: Issue: DEFSTRUCT-REDEFINITION   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  22:07:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 21:31:45 PDT
Date: 14 Sep 88 21:31 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFSTRUCT-REDEFINITION
In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Tue, 13 Sep 88
 06:36:30 PDT
To: cl-cleanup@sail.stanford.edu
Message-ID: <880914-213145-1852@Xerox>

Using the new terminology from the error/CLOS proposals, I would say that the
results of an old-use are undefined.

At the time the proposal was written, the new terminology wasn't around. I'm
looking for the copy of the new "error terminology" but I seem to have misfiled
it...

Xerox Common Lisp implements error-if-old-use: if a structure is redefined
*incompatibly*, old instances become invalid. An incompatible redefinition is
one that changes the number of slots or their type in an incompatible way (i.e.,
the total size or the layout of pointer vs. non-pointer fields changes.) A
warning message is printed if the underlying structure changes. 

We might want to at least reference the redefintion protocol of CLOS.

Skona: there's been several comments; are you up for producing a new version?

Thanks,

Larry


∂14-Sep-88  2207	CL-Cleanup-mailer 	Re: Issue: DOTTED-MACRO-FORMS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  22:07:44 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 22:00:22 PDT
Date: 14 Sep 88 22:00 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DOTTED-MACRO-FORMS (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Tue, 28 Jun 88 16:47 EDT
To: CL-Cleanup@SAIL.Stanford.EDU, goldman@VAXA.ISI.EDU
Message-ID: <880914-220022-1881@Xerox>

I apparently only responded privately to Walter last July, rather than to the
whole list.

I am in favor of DOTTED-MACRO-FORMS:ALLOW, with an addendum that a comment be
added to the standard where appropriate which says that such usage, while
allowed, is not good progamming practice and should be discouraged.

∂14-Sep-88  2207	CL-Cleanup-mailer 	Re: Issue: DESCRIBE-INTERACTIVE (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  22:07:39 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 SEP 88 21:52:51 PDT
Date: 14 Sep 88 21:53 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Tue, 13 Sep 88 12:32 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880914-215251-1875@Xerox>

The description of DESCRIBE says that it prints something on *standard-output*,
just like PRINT. While it doesn't explicitly prohibit DESCRIBE from being
interactive, it also doesn't prohibit PRINT from being interactive too.

So, I don't see any reason to claim that CLtL is any more vague than usual in
asserting that it is output only. If it were me, I'd treat this as a place where
Symbolics Genera diverged from CLtL.

I think that code that uses DESCRIBE to write out an implementation-dependent
description *is* fully portable, and that is part of the reason for having
DESCRIBE in the standard.


∂14-Sep-88  2207	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  22:07:32 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 SEP 88 21:41:19 PDT
Date: 14 Sep 88 21:41 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 2)
TO: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <880914-214119-1869@Xerox>


I've modified the proposal to say that it "should signal an error". This is shakey ground, but the sentiment from all that responded is that error-signalling is the desired behavior. I don't think the current "situations" language covers the distinction between macro expansion and evaluation, but I hope that we can invoke the distinction by reference and hope that it will appear in the standard...


!
Issue:          DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References:     CLtL p.308 & 86-003 p.4
Category:       CLARIFICATION

Edit history:   Version 1 by Skona Brittain 05/13/88
                Version 2 by Larry Masinter 14-Sep-88

Problem Description:

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

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

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

The situation of expanding a DEFSTRUCT macro with a duplicate name should
signal an error. (While not yet formally defined, the intent is that 
the error signalling may occur when compiling a file that contains
duplicate names or when evaluating a DEFSTRUCT form with duplicate names
in an interpreter.)

Test Cases:

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

Rationale:

Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error.

Current Practice:

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

Cost to Implementors:

None.

Cost to Users:

None.

Cost of Non-Adoption:

Possible confusion.

Benefits:

Clarity.

Aethetics:

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

Discussion: 

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

This issue was first circulated to X3J13 June 1988.


∂14-Sep-88  2213	CL-Cleanup-mailer 	ELIMINATE-FORCED-CONSING  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  22:13:16 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 SEP 88 22:11:31 PDT
Date: 14 Sep 88 22:10 PDT
From: masinter.pa@Xerox.COM
Subject: ELIMINATE-FORCED-CONSING
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880914-221131-1891@Xerox>

I'd like to get a sense of the committee on this issue... my guess is that the
best we can do is to report at the October meeting on the state of our
deliberation, and have the final issue ready by January.

My opinion on the issue:

I think the problem is a serious one, and that I don't want to discard the
issue. However, I'm not convinced that any of the proposed solutions actually
solve the stated problem, or are the minimum cost solutions to the problem.

In my mind, making CL more complicated is a very high cost.

What I remember from implementing stuff like this is that a :TARGET keyword just
doubles the size of the code for the functions, because the implementation when
:TARGET is supplied is completely different than the implementation when :TARGET
isn't supplied. This increases the size of the required image (because you can't
selectively compile stuff out) or else increases the complexity of the optimizer
(which has to decide whether the :TARGET is supplied), and increases the size of
error checking (what if :TARGET isn't big enough), increases the size of the
manual and the standard (describing all of these :TARGET arguments), and only
saves conses for a few applications.

∂14-Sep-88  2222	CL-Cleanup-mailer 	re: encourage no side-effect garbage
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  22:22:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 22:19:39 PDT
Date: 14 Sep 88 22:19 PDT
From: masinter.pa@Xerox.COM
Subject: re: encourage no side-effect garbage
In-reply-to: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU's message of Wed, 20 Jul 88
 15:48:35 PDT
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880914-221939-1901@Xerox>

I'd like to withdraw this issue from discussion.

The cleanup committee is constituted to consider changes to the Language that
the standard describes.  Whether the standard should have a (non-binding)
section on implementation notes is really up to the editor and the editorial
committee. 

I think it should, but it doesn't belong as a "cleanup" to the language.

I think this is the sentiment that was expressed by others, but I wanted to give
final notice before moving it to the "withdrawn" category.



∂14-Sep-88  2331	CL-Cleanup-mailer 	ELIMINATE-FORCED-CONSING  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88  22:13:16 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 SEP 88 22:11:31 PDT
Date: 14 Sep 88 22:10 PDT
From: masinter.pa@Xerox.COM
Subject: ELIMINATE-FORCED-CONSING
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880914-221131-1891@Xerox>

I'd like to get a sense of the committee on this issue... my guess is that the
best we can do is to report at the October meeting on the state of our
deliberation, and have the final issue ready by January.

My opinion on the issue:

I think the problem is a serious one, and that I don't want to discard the
issue. However, I'm not convinced that any of the proposed solutions actually
solve the stated problem, or are the minimum cost solutions to the problem.

In my mind, making CL more complicated is a very high cost.

What I remember from implementing stuff like this is that a :TARGET keyword just
doubles the size of the code for the functions, because the implementation when
:TARGET is supplied is completely different than the implementation when :TARGET
isn't supplied. This increases the size of the required image (because you can't
selectively compile stuff out) or else increases the complexity of the optimizer
(which has to decide whether the :TARGET is supplied), and increases the size of
error checking (what if :TARGET isn't big enough), increases the size of the
manual and the standard (describing all of these :TARGET arguments), and only
saves conses for a few applications.

∂15-Sep-88  0018	CL-Cleanup-mailer 	Re: Issue: EXIT-EXTENT (Version 1)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88  00:18:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 23:01:25 PDT
Date: 14 Sep 88 23:01 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXIT-EXTENT (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
 Wed, 7 Sep 88 19:32 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880914-230125-1950@Xerox>

I think this is a valuable generalization of the issue raised in
UNWIND-PROTECT-NON-LOCAL-EXIT. 

My problem with this writeup is that it does not mention the numerous points for
the alternative proposal (which would extend the dynamic extent of an exit until
the exit was actually abandoned) from the  discussion of
UNWIND-PROTECT-NON-LOCAL-EXIT. Since UNWIND-PROTECT-NON-LOCAL-EXIT was never
distributed, I think we at least need to acknowledge that there is an issue and
no small difference of opinion.

∂15-Sep-88  0018	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 2)   
Received: from Xerox.COM by SAIL.Stanford.EDU with