perm filename CLCLEA.MSG[COM,LSP] blob sn#886320 filedate 1990-08-06 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00439 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00062 00002	
C00063 00003	∂13-Mar-89  1254	CL-Cleanup-mailer 	amendments to already passed issues 
C00065 00004	∂13-Mar-89  1352	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 3)
C00072 00005	∂13-Mar-89  1448	CL-Cleanup-mailer 	Issue: LOAD-TRUENAME (Version 1)    
C00080 00006	∂13-Mar-89  1457	CL-Cleanup-mailer 	Issue CLOS-CONDITIONS, v4 
C00082 00007	∂13-Mar-89  1457	CL-Cleanup-mailer 	gls cleanups    
C00084 00008	∂13-Mar-89  1500	CL-Cleanup-mailer 	Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER  
C00086 00009	∂13-Mar-89  1501	CL-Cleanup-mailer 	Issue SUBTYPEP-TOO-VAGUE  
C00089 00010	∂13-Mar-89  1502	CL-Cleanup-mailer 	Issue PEEK-CHAR-READ-CHAR-ECHO 
C00095 00011	∂13-Mar-89  1457	CL-Compiler-mailer 	Issue LOCALLY-TOP-LEVEL, v1   
C00097 00012	∂13-Mar-89  1557	CL-Cleanup-mailer 	Issue LOCALLY-TOP-LEVEL, v1    
C00100 00013	∂13-Mar-89  1726	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL (Version 9)   
C00102 00014	∂13-Mar-89  1737	CL-Compiler-mailer 	Re: Issue: LOAD-OBJECTS (Version 3)
C00107 00015	∂13-Mar-89  1754	CL-Compiler-mailer 	Re: Issue: LOAD-OBJECTS (Version 3)
C00111 00016	∂14-Mar-89  0738	CL-Cleanup-mailer 	Re: Issue PEEK-CHAR-READ-CHAR-ECHO  
C00115 00017	∂14-Mar-89  0738	CL-Cleanup-mailer 	More re: PEEK-CHAR-READ-CHAR-ECHO   
C00117 00018	∂14-Mar-89  0756	CL-Cleanup-mailer 	Re: Issue: DESTRUCTURING-BIND (Version 2)
C00119 00019	∂14-Mar-89  0835	CL-Cleanup-mailer 	Re: Issue: CONDITION-RESTARTS (Version 1)
C00121 00020	∂14-Mar-89  0923	CL-Cleanup-mailer 	More re: PEEK-CHAR-READ-CHAR-ECHO   
C00124 00021	∂14-Mar-89  1104	CL-Cleanup-mailer 	Re: Issue IGNORE-VARIABLE, v1  
C00133 00022	∂14-Mar-89  1253	CL-Cleanup-mailer 	re: PATHNAME-PRINT-READ, v1    
C00136 00023	∂14-Mar-89  1317	CL-Cleanup-mailer 	Re: PATHNAME-PRINT-READ, v1    
C00139 00024	∂14-Mar-89  1344	CL-Cleanup-mailer 	Re: Issue: LOAD-TRUENAME (Version 1)
C00141 00025	∂14-Mar-89  1344	CL-Cleanup-mailer 	Re: Issue: CLOS-CONDITIONS (Version 4)   
C00144 00026	∂14-Mar-89  1344	CL-Cleanup-mailer 	Issue: LOAD-TRUENAME (Version 1)    
C00146 00027	∂14-Mar-89  1358	CL-Cleanup-mailer 	Issue: TIME-ZONE-NON-INTEGER   
C00148 00028	∂14-Mar-89  1505	CL-Cleanup-mailer 	Issue: ERROR-NOT-HANDLED (Version 1)
C00150 00029	∂14-Mar-89  1612	CL-Cleanup-mailer 	TYPE-OF-UNDERCONSTRAINED, version 4 
C00160 00030	∂14-Mar-89  1613	CL-Cleanup-mailer 	SYMBOL-MACROLET-SEMANTICS, version 6
C00172 00031	∂14-Mar-89  1731	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C00175 00032	∂14-Mar-89  1731	CL-Cleanup-mailer 	RE: Cleanup Issue Status  
C00180 00033	∂14-Mar-89  1732	CL-Cleanup-mailer 	revised: Cleanup Issue Status  
C00184 00034	∂14-Mar-89  1732	CL-Cleanup-mailer 	Issue: PRETTY-PRINT-INTERFACE (Version 1)
C00186 00035	∂14-Mar-89  1732	CL-Compiler-mailer 	Re: Potential issue: MACRO-SPECIAL-FORMS
C00188 00036	∂14-Mar-89  1743	CL-Cleanup-mailer 	Issue: FORMAT-PLURALS (not yet submitted)
C00197 00037	∂14-Mar-89  1756	CL-Cleanup-mailer 	Re: Issue: COPY-SYMBOL-PRINT-NAME (Version 1) 
C00199 00038	∂14-Mar-89  1812	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C00202 00039	∂15-Mar-89  0542	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-PRINT-NAME  
C00207 00040	∂15-Mar-89  0549	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 7)  
C00219 00041	∂15-Mar-89  0641	CL-Cleanup-mailer 	Re: Issue: OPTIMIZE-SAFETY (Version 1)   
C00221 00042	∂15-Mar-89  0720	CL-Cleanup-mailer 	Re: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER   
C00224 00043	∂15-Mar-89  0720	CL-Cleanup-mailer   
C00265 00044	∂15-Mar-89  0741	CL-Cleanup-mailer 	Re: Issue: PLUS-ABNORMAL (Version 1)
C00269 00045	∂15-Mar-89  0817	CL-Cleanup-mailer 	Cleanup Issue Status 
C00271 00046	∂15-Mar-89  0845	CL-Cleanup-mailer 	Re: Cleanup Issue Status  
C00274 00047	∂15-Mar-89  0921	CL-Cleanup-mailer 	Re: Cleanup Issue Status  
C00278 00048	∂15-Mar-89  0930	CL-Cleanup-mailer 	Issue: PRETTY-PRINT-INTERFACE (Version 1)
C00281 00049	∂15-Mar-89  0934	CL-Cleanup-mailer 	RE: Cleanup Issue Status  
C00284 00050	∂15-Mar-89  0936	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00286 00051	∂15-Mar-89  0947	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-PRINT-NAME  
C00288 00052	∂15-Mar-89  0959	CL-Cleanup-mailer 	Issue: TIME-ZONE-NON-INTEGER   
C00290 00053	∂15-Mar-89  0948	X3J13-mailer 	Issue: GENSYM-NAME-STICKINESS (Version 1)
C00292 00054	∂15-Mar-89  1045	CL-Cleanup-mailer 	Issue: GENSYM-NAME-STICKINESS (Version 1)
C00297 00055	∂15-Mar-89  1057	CL-Cleanup-mailer 	Issue LOOP-AND-DISCREPANCY, version 1    
C00303 00056	∂15-Mar-89  1111	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-COPY-PLIST  
C00305 00057	∂15-Mar-89  1127	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 3) 
C00318 00058	∂15-Mar-89  1138	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)    
C00338 00059	∂15-Mar-89  1145	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 3) 
C00342 00060	∂15-Mar-89  1147	CL-Cleanup-mailer 	Issue: MAKE-STRING-FILL-POINTER (Version 1)   
C00347 00061	∂15-Mar-89  1208	CL-Cleanup-mailer 	Issue status    
C00349 00062	∂15-Mar-89  1227	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL (Version 9)   
C00352 00063	∂15-Mar-89  1229	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C00355 00064	∂15-Mar-89  1256	CL-Cleanup-mailer 	PRETTY-PRINT-INTERFACE, version 3 (supersedes 2 sent an hour ago!)
C00379 00065	∂15-Mar-89  1306	CL-Cleanup-mailer 	Issue: GENSYM-NAME-STICKINESS, version 2 
C00387 00066	∂15-Mar-89  1449	CL-Cleanup-mailer 	Issue SUBTYPEP-TOO-VAGUE, version 5 
C00397 00067	∂15-Mar-89  1454	CL-Cleanup-mailer 	[gls: Issue SUBTYPEP-TOO-VAGUE, version 5]    
C00408 00068	∂15-Mar-89  1756	CL-Cleanup-mailer 	Re: Issue LOCALLY-TOP-LEVEL, v1
C00410 00069	∂15-Mar-89  1907	CL-Cleanup-mailer 	Re: Issue STREAM-ACCESS   
C00412 00070	∂16-Mar-89  0523	CL-Cleanup-mailer 	Re: Issue: GENSYM-NAME-STICKINESS, version 2  
C00414 00071	∂16-Mar-89  0646	CL-Cleanup-mailer 	Issue: GENSYM-NAME-STICKINESS, version 2 
C00416 00072	∂16-Mar-89  0807	CL-Cleanup-mailer 	Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)  
C00419 00073	∂16-Mar-89  0827	CL-Cleanup-mailer 	Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)  
C00422 00074	∂16-Mar-89  0831	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL (Version 9)   
C00424 00075	∂16-Mar-89  0917	CL-Cleanup-mailer 	Issue LOOP-AND-DISCREPANCY, version 1    
C00426 00076	∂16-Mar-89  0932	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL (Version 9)   
C00429 00077	∂16-Mar-89  1044	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL (Version 9)   
C00431 00078	∂16-Mar-89  1115	CL-Cleanup-mailer 	Issue: GENSYM-NAME-STICKINESS, version 2 
C00434 00079	∂16-Mar-89  1143	CL-Cleanup-mailer 	Re: DRAFT Issue: CONDITION-RESTARTS (Version 1)    
C00436 00080	∂16-Mar-89  1234	CL-Cleanup-mailer 	Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)  
C00440 00081	∂16-Mar-89  1252	CL-Cleanup-mailer 	DEFAULT-CASE    
C00448 00082	∂16-Mar-89  1318	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)    
C00451 00083	∂16-Mar-89  1338	CL-Cleanup-mailer 	Issue: ENVIRONMENT-ENQUIRY (not submitted)    
C00453 00084	∂16-Mar-89  1338	CL-Cleanup-mailer 	Re: Issue EQUALP-GENERIC  
C00454 00085	∂16-Mar-89  1440	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL (Version 9)   
C00456 00086	∂16-Mar-89  1518	CL-Cleanup-mailer 	DEFAULT-CASE    
C00459 00087	∂16-Mar-89  1555	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)    
C00463 00088	∂16-Mar-89  1605	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)    
C00468 00089	∂16-Mar-89  1802	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED, v.5
C00479 00090	∂16-Mar-89  2116	CL-Cleanup-mailer 	Re: Issue: EXPT-ZERO-ZERO (Version 1)    
C00481 00091	∂16-Mar-89  2212	CL-Cleanup-mailer 	Issue: FIXNUM-NON-PORTABLE, v.5
C00490 00092	∂16-Mar-89  2253	CL-Cleanup-mailer 	Re: DEFAULT-CASE     
C00495 00093	∂16-Mar-89  2310	CL-Cleanup-mailer 	Re: Issue: IN-SYNTAX (Version 1)    
C00497 00094	∂17-Mar-89  0009	CL-Cleanup-mailer 	Cleanup Issue Status List 
C00543 00095	∂17-Mar-89  0823	CL-Cleanup-mailer 	Re: DEFAULT-CASE     
C00548 00096	∂17-Mar-89  0838	CL-Cleanup-mailer 	Issue: FUNCTION-COERCE-TIME (Version 2)  
C00550 00097	∂17-Mar-89  0847	CL-Cleanup-mailer 	Re: DEFAULT-CASE     
C00555 00098	∂17-Mar-89  0859	CL-Cleanup-mailer 	Re: issue HASH-TABLE-PRINTED-REPRESENTATION, v.2   
C00560 00099	∂17-Mar-89  0910	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 3) 
C00564 00100	∂17-Mar-89  1032	CL-Cleanup-mailer 	DYNAMIC-EXTENT  
C00567 00101	∂17-Mar-89  1044	CL-Cleanup-mailer 	Re: DEFAULT-CASE
C00572 00102	∂17-Mar-89  1046	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL (Version 9)   
C00575 00103	∂17-Mar-89  1100	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS (Version 1)    
C00578 00104	∂17-Mar-89  1101	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS (Version 1)    
C00581 00105	∂17-Mar-89  1205	CL-Cleanup-mailer 	Issue: IN-SYNTAX (Version 1)   
C00583 00106	∂17-Mar-89  1214	CL-Cleanup-mailer 	Issue LOOP-AND-DISCREPANCY, version 1    
C00585 00107	∂17-Mar-89  1214	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C00588 00108	∂17-Mar-89  1214	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00593 00109	∂17-Mar-89  1229	CL-Cleanup-mailer 	DYNAMIC-EXTENT  
C00597 00110	∂17-Mar-89  1254	CL-Cleanup-mailer 	Re: DEFAULT-CASE     
C00603 00111	∂17-Mar-89  1254	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00606 00112	∂17-Mar-89  1257	X3J13-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00609 00113	∂17-Mar-89  1327	CL-Cleanup-mailer 	DYNAMIC-EXTENT  
C00613 00114	∂17-Mar-89  1337	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
C00628 00115	∂17-Mar-89  1346	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C00633 00116	∂17-Mar-89  1410	CL-Cleanup-mailer 	Re: Issue: EXPT-ZERO-ZERO (Version 1)    
C00636 00117	∂17-Mar-89  1541	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00640 00118	∂17-Mar-89  1555	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C00643 00119	∂17-Mar-89  1618	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS (Version 1)    
C00651 00120	∂17-Mar-89  1627	CL-Cleanup-mailer 	Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)    
C00658 00121	∂17-Mar-89  1600	X3J13-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00660 00122	∂17-Mar-89  1613	X3J13-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00663 00123	∂17-Mar-89  1657	CL-Cleanup-mailer 	Issue: FIXNUM-NON-PORTABLE, v.5
C00666 00124	∂17-Mar-89  1656	X3J13-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00672 00125	∂17-Mar-89  1839	CL-Cleanup-mailer 	Re: Issue: FIXNUM-NON-PORTABLE, v.5 
C00673 00126	∂17-Mar-89  1949	CL-Cleanup-mailer 	Re: Issue: CONDITION-RESTARTS (Version 1)
C00675 00127	∂17-Mar-89  2009	CL-Cleanup-mailer 	Issue: DEFMACRO-LAMBDA-LIST, v.2    
C00684 00128	∂17-Mar-89  2126	CL-Cleanup-mailer 	New issue: WITH-OPEN-FILE-DOES-NOT-EXIST 
C00690 00129	∂17-Mar-89  2128	CL-Cleanup-mailer 	Re: DEFAULT-CASE
C00692 00130	∂17-Mar-89  2140	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED, v.5
C00698 00131	∂17-Mar-89  2153	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C00701 00132	∂17-Mar-89  2223	CL-Cleanup-mailer 	Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5 
C00704 00133	∂17-Mar-89  2235	CL-Cleanup-mailer 	Issue: PRETTY-PRINT-INTERFACE (version 3)
C00711 00134	∂17-Mar-89  2254	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
C00717 00135	∂17-Mar-89  2300	CL-Cleanup-mailer 	Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5 
C00721 00136	∂17-Mar-89  2320	CL-Cleanup-mailer 	Re: Issue: PLUS-ABNORMAL (Version 1)
C00722 00137	∂17-Mar-89  2357	CL-Cleanup-mailer 	Re: environment argument for SUBTYPEP    
C00724 00138	∂18-Mar-89  0026	CL-Cleanup-mailer 	[cl-cleanup@sail.stanford.edu: Issue:    
C00736 00139	∂18-Mar-89  0122	CL-Cleanup-mailer 	Cleanup Issue Status List 
C00780 00140	∂18-Mar-89  0216	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)    
C00801 00141	∂18-Mar-89  1708	CL-Cleanup-mailer 	*DRAFT* Issue: DESTRUCTURING-BIND, v.2   
C00803 00142	∂18-Mar-89  1720	CL-Cleanup-mailer 	Issue DESCRIBE-UNDERSPECIFIED, v.1  
C00806 00143	∂18-Mar-89  2312	CL-Cleanup-mailer 	Issue: DEFMACRO-LAMBDA-LIST, v.2    
C00809 00144	∂19-Mar-89  1058	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 2)
C00812 00145	∂20-Mar-89  1229	CL-Cleanup-mailer 	Re: Issue: PRETTY-PRINT-INTERFACE (version 3) 
C00816 00146	∂20-Mar-89  1236	CL-Cleanup-mailer 	Re: Issue: PRETTY-PRINT-INTERFACE (version 3) 
C00820 00147	∂20-Mar-89  1241	CL-Cleanup-mailer 	Issue: COMPLEX-RATIONAL-RESULT (version 1)    
C00826 00148	∂20-Mar-89  1241	CL-Cleanup-mailer 	Issue: HASH-TABLE-SIZE (version 1)  
C00831 00149	∂20-Mar-89  1242	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE (version 1)   
C00844 00150	∂20-Mar-89  1241	CL-Cleanup-mailer 	Issue: COMMON-TYPE (version 1) 
C00848 00151	∂20-Mar-89  1325	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
C00850 00152	∂20-Mar-89  1415	CL-Cleanup-mailer 	Re: Issue: PRETTY-PRINT-INTERFACE (version 3) 
C00855 00153	∂20-Mar-89  1427	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
C00857 00154	∂20-Mar-89  1437	CL-Cleanup-mailer 	Issue: COMMON-TYPE (version 1) 
C00859 00155	∂20-Mar-89  1438	CL-Cleanup-mailer 	Issue: COMMON-TYPE (version 1) 
C00861 00156	∂20-Mar-89  1507	CL-Cleanup-mailer 	Issue: COMPLEX-RATIONAL-RESULT (version 1)    
C00863 00157	∂20-Mar-89  1512	CL-Cleanup-mailer 	Issue: HASH-TABLE-SIZE (version 1)  
C00865 00158	∂20-Mar-89  1556	CL-Cleanup-mailer 	Issue: PRETTY-PRINT-INTERFACE (version 3)
C00872 00159	∂20-Mar-89  1605	CL-Cleanup-mailer 	Issue: FIXNUM-NON-PORTABLE, v.5
C00876 00160	∂20-Mar-89  1841	CL-Cleanup-mailer 	Issue: PRETTY-PRINT-INTERFACE (version 3)
C00884 00161	∂20-Mar-89  2059	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE (version 1)   
C00888 00162	∂21-Mar-89  0845	CL-Cleanup-mailer 	Issue: GENSYM-NAME-STICKINESS (Version 3)
C00897 00163	∂21-Mar-89  1503	CL-Cleanup-mailer 	New cleanup issues   
C00899 00164	∂21-Mar-89  1601	CL-Cleanup-mailer 	New issue: WITH-OPEN-FILE-DOES-NOT-EXIST 
C00901 00165	∂21-Mar-89  1643	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE (version 1)   
C00908 00166	∂21-Mar-89  1752	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE (version 1)   
C00914 00167	∂21-Mar-89  2227	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE (version 1)   
C00916 00168	∂22-Mar-89  1054	CL-Cleanup-mailer 	PRETTY-PRINT-INTERFACE, version 4   
C00954 00169	∂22-Mar-89  1057	CL-Cleanup-mailer 	PRETTY-PRINT-INTERFACE, version 4   
C01019 00170	∂22-Mar-89  1104	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
C01025 00171	∂22-Mar-89  1612	CL-Cleanup-mailer 	Issue: PRETTY-PRINT-INTERFACE, version 4 
C01027 00172	∂22-Mar-89  2239	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4) 
C01031 00173	∂23-Mar-89  0645	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
C01034 00174	∂23-Mar-89  0804	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)     
C01037 00175	∂23-Mar-89  0805	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)  
C01040 00176	∂23-Mar-89  0820	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)     
C01043 00177	∂23-Mar-89  0919	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
C01046 00178	∂23-Mar-89  1112	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4) 
C01049 00179	∂23-Mar-89  1132	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4) 
C01052 00180	∂23-Mar-89  1205	CL-Cleanup-mailer 	string OK for :CONC-NAME in DEFSTRUCT?   
C01055 00181	∂23-Mar-89  1225	CL-Cleanup-mailer 	Meeting 1 hour before plenary session?   
C01057 00182	∂23-Mar-89  1504	CL-Cleanup-mailer 	Meeting 1 hour before plenary session?   
C01059 00183	∂23-Mar-89  1518	CL-Cleanup-mailer 	Issue: READ-CASE-SENSITIVITY (Version 2) 
C01076 00184	∂23-Mar-89  1534	CL-Cleanup-mailer 	Re: New cleanup issues    
C01078 00185	∂23-Mar-89  1538	CL-Cleanup-mailer 	Re: Issue: FIXNUM-NON-PORTABLE, v.5 
C01087 00186	∂23-Mar-89  1538	CL-Cleanup-mailer 	The Revised Cleanup Issue Status List    
C01121 00187	∂23-Mar-89  1656	CL-Cleanup-mailer 	Issue: READ-CASE-SENSITIVITY (Version 2) 
C01125 00188	∂23-Mar-89  1503	CL-Windows-mailer 	Issue STREAM-DEFINITION-BY-USER (V1)
C01168 00189	∂23-Mar-89  1813	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 2)  
C01171 00190	∂23-Mar-89  1518	CL-Cleanup-mailer 	Issue: DIRECTORY-DOES-TOO-MUCH 
C01178 00191	∂23-Mar-89  1534	CL-Cleanup-mailer 	Re: Issue: GENSYM-NAME-STICKINESS (Version 3) 
C01179 00192	∂23-Mar-89  2050	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 2)  
C01187 00193	∂23-Mar-89  2232	CL-Cleanup-mailer 	Issue: DIRECTORY-DOES-TOO-MUCH 
C01192 00194	∂24-Mar-89  0745	CL-Cleanup-mailer 	Re: Issue: DIRECTORY-DOES-TOO-MUCH  
C01195 00195	∂24-Mar-89  0807	CL-Cleanup-mailer 	Meeting 1 hour before plenary session?   
C01198 00196	∂24-Mar-89  1015	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 2)  
C01200 00197	∂24-Mar-89  1024	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 2)  
C01204 00198	∂24-Mar-89  1344	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 2)  
C01209 00199	∂25-Mar-89  1209	CL-Cleanup-mailer 	Cleanup Meeting 
C01211 00200	∂29-Mar-89  1535	CL-Cleanup-mailer 	new version of LOAD-TRUENAME   
C01221 00201	∂29-Mar-89  1550	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND, v.3 
C01234 00202	∂04-Apr-89  0804	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE  
C01235 00203	∂04-Apr-89  0805	CL-Cleanup-mailer 	Issue: BREAK-ON-WARNINGS-OBSOLETE   
C01237 00204	∂04-Apr-89  0805	CL-Cleanup-mailer 	Issue: CLOS-CONDITIONS    
C01238 00205	∂04-Apr-89  0808	CL-Cleanup-mailer 	Issue: CLOS-MACRO-COMPILATION  
C01240 00206	∂04-Apr-89  0809	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS
C01242 00207	∂04-Apr-89  0809	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE  
C01244 00208	∂04-Apr-89  0816	CL-Cleanup-mailer 	Issue: COMMON-TYPE   
C01245 00209	∂04-Apr-89  0817	CL-Cleanup-mailer 	Issue: COMPILE-FILE-SYMBOL-HANDLING 
C01247 00210	∂04-Apr-89  0817	CL-Cleanup-mailer 	Issue: COMPILE-ENVIRONMENT-CONSISTENCY   
C01249 00211	∂04-Apr-89  0823	CL-Cleanup-mailer 	COMPILE-FILE-SYMBOL-HANDLING, COMPILE-ENVIRONMENT-CONSISTENCY
C01251 00212	∂04-Apr-89  0832	CL-Cleanup-mailer 	Issue: COMPLEX-RATIONAL-RESULT 
C01252 00213	∂04-Apr-89  0833	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS 
C01254 00214	∂04-Apr-89  0834	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-COPY-PLIST  
C01255 00215	∂04-Apr-89  0834	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-COPY-PRINT-NAME  
C01256 00216	∂04-Apr-89  0835	CL-Cleanup-mailer 	Issue: DECLARE-FUNCTION-AMBIGUITY   
C01258 00217	∂04-Apr-89  0842	CL-Cleanup-mailer 	Issue: DEFINE-OPTIMIZER   
C01260 00218	∂04-Apr-89  0852	CL-Cleanup-mailer 	Issue: DEFMACRO-LAMBDA-LIST    
C01262 00219	∂04-Apr-89  0855	CL-Cleanup-mailer 	Issue: DEFMACRO-LAMBDA-LIST    
C01265 00220	∂04-Apr-89  0855	CL-Cleanup-mailer 	Issue: DESCRIBE-UNDERSPECIFIED 
C01267 00221	∂04-Apr-89  0857	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND 
C01269 00222	∂04-Apr-89  1027	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 1 
C01275 00223	∂04-Apr-89  1110	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT
C01279 00224	∂04-Apr-89  1111	CL-Cleanup-mailer 	Issue: EQUALP-GENERIC
C01280 00225	∂04-Apr-89  1114	CL-Cleanup-mailer 	Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER 
C01283 00226	∂04-Apr-89  1115	CL-Cleanup-mailer 	Issue: ERROR-NOT-HANDLED  
C01285 00227	∂04-Apr-89  1117	CL-Cleanup-mailer 	Issue: FUNCTION-COERCE-TIME    
C01286 00228	∂04-Apr-89  1125	CL-Cleanup-mailer 	Issue: EXIT-EXTENT   
C01288 00229	∂04-Apr-89  1127	CL-Cleanup-mailer 	Re: Issue: DYNAMIC-EXTENT 
C01291 00230	∂04-Apr-89  1127	CL-Cleanup-mailer 	Issue: FUNCTION-NAME 
C01294 00231	∂04-Apr-89  1133	CL-Cleanup-mailer 	Re: Issue: DYNAMIC-EXTENT 
C01296 00232	∂04-Apr-89  1133	CL-Cleanup-mailer 	Issue: GENSYM-NAME-STICKINESS  
C01298 00233	∂04-Apr-89  1147	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS  
C01301 00234	∂04-Apr-89  1148	CL-Cleanup-mailer 	Issue: HASH-TABLE-SIZE    
C01303 00235	∂04-Apr-89  1149	CL-Cleanup-mailer 	Issue: IN-PACKAGE-FUNCTIONALITY
C01306 00236	∂04-Apr-89  1153	CL-Cleanup-mailer 	Issue: IN-SYNTAX
C01309 00237	∂04-Apr-89  1156	CL-Cleanup-mailer 	Issue: LISP-PACKAGE-NAME  
C01311 00238	∂04-Apr-89  1200	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION
C01314 00239	∂04-Apr-89  1206	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 4)
C01337 00240	∂04-Apr-89  1217	CL-Cleanup-mailer 	Issue: LOAD-TRUENAME 
C01341 00241	∂04-Apr-89  1219	CL-Cleanup-mailer 	Issue: LOCALLY-TOP-LEVEL  
C01343 00242	∂04-Apr-89  1219	CL-Cleanup-mailer 	Issue: LOOP-AND-DISCREPANCY    
C01344 00243	∂04-Apr-89  1221	CL-Cleanup-mailer 	Issue: MACRO-ENVIRONMENT-EXTENT
C01346 00244	∂04-Apr-89  1221	CL-Cleanup-mailer 	Issue: MAKE-STRING-FILL-POINTER
C01348 00245	∂04-Apr-89  1222	CL-Cleanup-mailer 	Issue: PACKAGE-FUNCTION-CONSISTENCY 
C01350 00246	∂04-Apr-89  1226	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL   
C01352 00247	∂04-Apr-89  1227	CL-Cleanup-mailer 	Issue: PATHNAME-PRINT-READ
C01354 00248	∂04-Apr-89  1227	CL-Cleanup-mailer 	Issue: PATHNAME-CANONICAL-TYPE 
C01356 00249	∂04-Apr-89  1231	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST   
C01357 00250	∂04-Apr-89  1232	CL-Cleanup-mailer 	Issue: PEEK-CHAR-READ-CHAR-ECHO
C01359 00251	∂04-Apr-89  1233	CL-Cleanup-mailer 	Issue: PRETTY-PRINT-INTERFACE  
C01360 00252	∂04-Apr-89  1235	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-CASE 
C01362 00253	∂04-Apr-89  1238	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL   
C01365 00254	∂04-Apr-89  1238	CL-Cleanup-mailer 	Issue: READ-CASE-SENSITIVITY   
C01367 00255	∂04-Apr-89  1240	CL-Cleanup-mailer 	Issue: READ-DELIMITED-LIST-EOF 
C01369 00256	∂04-Apr-89  1242	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 6)    
C01371 00257	∂04-Apr-89  1244	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE
C01372 00258	∂04-Apr-89  1244	CL-Cleanup-mailer 	Issue: SETF-MULTIPLE-STORE-VARIABLES
C01374 00259	∂04-Apr-89  1249	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-SEMANTICS    
C01377 00260	∂04-Apr-89  1249	CL-Cleanup-mailer 	Issue: THE-AMBIGUITY 
C01378 00261	∂04-Apr-89  1252	CL-Cleanup-mailer 	Issue: TIME-ZONE-NON-INTEGER   
C01381 00262	∂04-Apr-89  1253	CL-Cleanup-mailer 	Issue: PATHNAME-SYNTAX-ERROR-TIME   
C01382 00263	∂04-Apr-89  1256	CL-Cleanup-mailer 	Issue: PATHNAME-WILD 
C01383 00264	∂04-Apr-89  1258	CL-Cleanup-mailer 	Issue: WITH-COMPILATION-UNIT   
C01385 00265	∂04-Apr-89  1301	CL-Cleanup-mailer 	Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION    
C01387 00266	∂04-Apr-89  1301	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (version 7) 
C01412 00267	∂04-Apr-89  1301	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-SHARED
C01414 00268	∂04-Apr-89  1304	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE   
C01416 00269	∂04-Apr-89  1309	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS    
C01419 00270	∂04-Apr-89  1309	CL-Cleanup-mailer 	Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS 
C01421 00271	∂04-Apr-89  1309	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED
C01423 00272	∂04-Apr-89  1324	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 1 
C01430 00273	∂04-Apr-89  1531	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-PRINT-NAME (not COPY-SYMBOL-COPY-PRINT-NAME)   
C01432 00274	∂04-Apr-89  2058	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 1 
C01438 00275	∂05-Apr-89  0710	CL-Cleanup-mailer 	Re: issue DYNAMIC-EXTENT-FUNCTION, version 1  
C01442 00276	∂05-Apr-89  0721	CL-Cleanup-mailer 	Re: issue DYNAMIC-EXTENT-FUNCTION, version 1  
C01445 00277	∂05-Apr-89  0805	CL-Cleanup-mailer 	Re: Issue: LISP-SYMBOL-REDEFINITION 
C01447 00278	∂05-Apr-89  0848	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 1 
C01449 00279	∂05-Apr-89  1159	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 4)   
C01468 00280	∂05-Apr-89  1206	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 4)   
C01470 00281	∂05-Apr-89  1731	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 1 
C01473 00282	∂05-Apr-89  2203	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 1 
C01476 00283	∂06-Apr-89  1115	CL-Cleanup-mailer 	Condensed summary of CL Cleanup meeting results    
C01491 00284	∂09-Apr-89  0921	CL-Cleanup-mailer 	Issue COMPLEX-RATIONAL-RESULT, version 2 
C01499 00285	∂09-Apr-89  2155	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION, v.6
C01508 00286	∂09-Apr-89  2239	CL-Cleanup-mailer 	Re: Issue: PACKAGE-FUNCTION-CONSISTENCY  
C01510 00287	∂09-Apr-89  2248	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01512 00288	∂09-Apr-89  2315	CL-Cleanup-mailer 	Re: PRETTY-PRINT-INTERFACE, version 4    
C01514 00289	∂09-Apr-89  2332	CL-Cleanup-mailer 	Issue: READ-DELIMITED-LIST-EOF 
C01518 00290	∂10-Apr-89  0006	CL-Cleanup-mailer 	Re: Issue: TYPE-OF-UNDERCONSTRAINED 
C01520 00291	∂10-Apr-89  0028	CL-Cleanup-mailer 	Cleanup Issue status, 10-Apr-89
C01555 00292	∂10-Apr-89  1025	CL-Cleanup-mailer 	Cleanup Issue status, 10-Apr-89     
C01590 00293	∂10-Apr-89  1303	CL-Cleanup-mailer 	Issue: LOAD-TRUENAME (Version 3)    
C01601 00294	∂10-Apr-89  1349	CL-Cleanup-mailer 	Issue: LOAD-TRUENAME (Version 3)    
C01604 00295	∂10-Apr-89  1621	CL-Cleanup-mailer 	Issue: PATHNAME-CANONICAL-TYPE 
C01613 00296	∂11-Apr-89  0714	CL-Cleanup-mailer 	Issue: LOAD-TRUENAME (Version 4)    
C01625 00297	∂11-Apr-89  2155	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE  
C01629 00298	∂12-Apr-89  1012	CL-Cleanup-mailer 	issue PRETTY-PRINT-INTERFACE   
C01632 00299	∂14-Apr-89  0700	CL-Cleanup-mailer 	Status of CL Condition Handling
C01642 00300	∂17-Apr-89  1301	CL-Cleanup-mailer 	[Robert S. Boyer <boyer@CLI.COM>: Fast IO]    
C01648 00301	∂19-Apr-89  0707	CL-Cleanup-mailer 	[Robert S. Boyer <boyer@CLI.COM>: Fast IO]    
C01651 00302	∂19-Apr-89  1519	CL-Cleanup-mailer 	no :in-file
C01653 00303	∂19-Apr-89  1528	CL-Cleanup-mailer 	[Robert S. Boyer <boyer@CLI.COM>: Fast IO]    
C01656 00304	∂19-Apr-89  1557	CL-Cleanup-mailer 	no :in-file
C01658 00305	∂19-Apr-89  1621	CL-Cleanup-mailer 	no :in-file
C01661 00306	∂20-Apr-89  1454	CL-Cleanup-mailer 	Issue: THE-VALUES [was: intent of (THE <type> <expression>)] 
C01664 00307	∂20-Apr-89  2003	CL-Cleanup-mailer 	Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)    
C01669 00308	∂24-Apr-89  1249	CL-Cleanup-mailer 	Issue COMPLEX-RATIONAL-RESULT, version 2 
C01672 00309	∂28-Apr-89  0944	CL-Cleanup-mailer 	Issue COMPLEX-RATIONAL-RESULT, version 3 
C01681 00310	∂28-Apr-89  1426	CL-Cleanup-mailer 	ISSUE: GCD-LCM-ZERO-ARGS  
C01686 00311	∂28-Apr-89  1606	CL-Cleanup-mailer 	Issue: MULTIPLICATION-ZERO-ARGS
C01695 00312	∂03-May-89  1653	CL-Cleanup-mailer 	[chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]  
C01698 00313	∂04-May-89  0922	CL-Cleanup-mailer 	Issue: SETF-MULTIPLE-STORE-VARIABLE 
C01702 00314	∂04-May-89  1244	CL-Cleanup-mailer 	[chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]  
C01715 00315	∂04-May-89  1251	CL-Cleanup-mailer 	Issue: SETF-MULTIPLE-STORE-VARIABLE 
C01718 00316	∂23-May-89  1013	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-CASE (version 4)    
C01733 00317	∂23-May-89  1014	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE (version 2)   
C01749 00318	∂23-May-89  1015	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL (version 2) 
C01774 00319	∂23-May-89  1017	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (version 6) 
C01796 00320	∂23-May-89  1018	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (version 5)    
C01818 00321	∂23-May-89  1148	CL-Cleanup-mailer 	Issue: DATA-IO (version 6)
C01834 00322	∂23-May-89  1148	CL-Cleanup-mailer 	Issue: STRING-COERCION (version 2)  
C01841 00323	∂23-May-89  1148	CL-Cleanup-mailer 	Issue: BIT-ARRAY-FUNCTIONS (version 5)   
C01859 00324	∂23-May-89  1148	CL-Cleanup-mailer 	Issue: PATHNAME-SYSTEM-TYPE (version 1)  
C01866 00325	∂23-May-89  1228	CL-Cleanup-mailer 	Issue: STREAM-CAPABILITIES (version 3)   
C01873 00326	∂23-May-89  1231	CL-Cleanup-mailer 	Issue: MAP-INTO (version 1)    
C01879 00327	∂23-May-89  1231	CL-Cleanup-mailer 	Issue: FLOAT-UNDERFLOW (version 2)  
C01889 00328	∂24-May-89  0810	CL-Cleanup-mailer 	Issue: STREAM-CAPABILITIES (version 3)   
C01891 00329	∂24-May-89  0816	CL-Cleanup-mailer 	Issue: FLOAT-UNDERFLOW (version 2)  
C01894 00330	∂24-May-89  1013	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-CASE (version 4)    
C01896 00331	∂24-May-89  1024	CL-Cleanup-mailer 	Re: Issue: DATA-IO (version 6) 
C01898 00332	∂24-May-89  1112	CL-Cleanup-mailer 	Re: Issue: PATHNAME-LOGICAL (version 2)  
C01901 00333	∂24-May-89  1115	CL-Cleanup-mailer 	Issue: FLOAT-UNDERFLOW (version 2)  
C01905 00334	∂24-May-89  1117	CL-Cleanup-mailer 	Issue: STREAM-CAPABILITIES (version 3), or Issue: MAP-INTO (version 1) 
C01908 00335	∂24-May-89  1118	CL-Cleanup-mailer 	Issue: STREAM-CAPABILITIES
C01913 00336	∂24-May-89  1334	CL-Cleanup-mailer 	Re: Issue: PATHNAME-LOGICAL (version 2)  
C01920 00337	∂24-May-89  2338	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
C01922 00338	∂24-May-89  2338	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)    
C01924 00339	∂25-May-89  1108	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
C01931 00340	∂25-May-89  1130	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)    
C01934 00341	∂25-May-89  1239	CL-Cleanup-mailer 	Re: Issue: PATHNAME-LOGICAL (version 2)  
C01939 00342	∂25-May-89  1245	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)   
C01941 00343	∂25-May-89  1249	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)    
C01943 00344	∂25-May-89  1249	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
C01955 00345	∂25-May-89  1251	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)  
C01957 00346	∂25-May-89  1258	CL-Cleanup-mailer 	Issue: FLOAT-UNDERFLOW (version 2)  
C01967 00347	∂25-May-89  1303	CL-Cleanup-mailer 	Issue: STREAM-CAPABILITIES (version 3), or Issue: MAP-INTO (version 1) 
C01969 00348	∂25-May-89  1306	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (version 6) 
C01972 00349	∂25-May-89  1306	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (version 5)
C01975 00350	∂25-May-89  1343	CL-Cleanup-mailer 	Issue: FLOAT-UNDERFLOW (version 2)  
C01980 00351	∂25-May-89  1350	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)   
C01983 00352	∂25-May-89  1438	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)   
C01989 00353	∂25-May-89  1458	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-VALUE (version 2)    
C01991 00354	∂25-May-89  1504	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)   
C01996 00355	∂25-May-89  1524	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)   
C01999 00356	∂25-May-89  1557	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (version 4)
C02004 00357	∂26-May-89  0842	CL-Cleanup-mailer 	Re: issue DYNAMIC-EXTENT-FUNCTION, version 1  
C02007 00358	∂26-May-89  0907	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL (version 2) 
C02017 00359	∂26-May-89  0917	CL-Cleanup-mailer 	Re: issue DYNAMIC-EXTENT-FUNCTION, version 1  
C02024 00360	∂26-May-89  0958	CL-Cleanup-mailer 	Re: Issue: PATHNAME-LOGICAL (version 2)  
C02032 00361	∂26-May-89  1002	CL-Cleanup-mailer 	Re: issue DYNAMIC-EXTENT-FUNCTION, version 1  
C02037 00362	∂25-May-89  1249	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (version 4), PATHNAME-COMPONENT-VALUE (version 2)  
C02040 00363	∂27-May-89  1552	CL-Cleanup-mailer 	PARSE-BODY 
C02045 00364	∂29-May-89  1311	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SYSTEM-TYPE (version 1)   
C02049 00365	∂30-May-89  0544	CL-Cleanup-mailer 	PARSE-BODY 
C02055 00366	∂30-May-89  0907	CL-Cleanup-mailer 	Re: Issue: PATHNAME-LOGICAL (version 2)  
C02057 00367	∂04-Jun-89  1215	CL-Cleanup-mailer 	Re: minor point about extract-declarations    
C02063 00368	∂05-Jun-89  1447	CL-Cleanup-mailer 	minor point about extract-declarations   
C02065 00369	∂08-Jun-89  1721	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (version 5)
C02070 00370	∂08-Jun-89  1723	CL-Cleanup-mailer 	Re: Issue: PATHNAME-LOGICAL (version 2)  
C02076 00371	∂08-Jun-89  1723	CL-Cleanup-mailer 	Re: Issue: PATHNAME-LOGICAL (version 2)  
C02080 00372	∂11-Jun-89  1226	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 2 
C02089 00373	∂12-Jun-89  1130	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 2 
C02091 00374	∂12-Jun-89  1522	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (version 5)
C02098 00375	∂12-Jun-89  1601	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL (version 2) 
C02124 00376	∂12-Jun-89  1619	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (version 5)
C02127 00377	∂12-Jun-89  1922	CL-Cleanup-mailer 	Re: Issue: PATHNAME-LOGICAL (version 2)  
C02137 00378	∂13-Jun-89  0755	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (version 5)
C02140 00379	∂13-Jun-89  0906	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (version 5)
C02142 00380	∂13-Jun-89  0936	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (version 5)
C02146 00381	∂13-Jun-89  1148	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (version 5)
C02156 00382	∂13-Jun-89  1155	CL-Cleanup-mailer 	Re: Issue: PATHNAME-LOGICAL (version 2)  
C02162 00383	∂13-Jun-89  1255	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (version 5)
C02166 00384	∂13-Jun-89  1315	CL-Cleanup-mailer 	Re: Issue: PATHNAME-WILD (version 5)
C02168 00385	∂13-Jun-89  1516	CL-Cleanup-mailer 	Issue: BIT-ARRAY-FUNCTIONS (Version 5)   
C02171 00386	∂13-Jun-89  1517	CL-Cleanup-mailer 	Issue: DATA-IO (Version 6)
C02173 00387	∂13-Jun-89  1518	CL-Cleanup-mailer 	Issue: FLOAT-UNDERFLOW (Version 2)  
C02175 00388	∂13-Jun-89  1519	CL-Cleanup-mailer 	Issue: MAP-INTO (Version 1)    
C02178 00389	∂13-Jun-89  1520	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-CASE (Version 4)    
C02180 00390	∂13-Jun-89  1520	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE (Version 2)   
C02182 00391	∂13-Jun-89  1523	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 6) 
C02185 00392	∂13-Jun-89  1525	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL (Version 2) 
C02194 00393	∂13-Jun-89  1526	CL-Cleanup-mailer 	Issue: STRING-COERCION (Version 2)  
C02196 00394	∂13-Jun-89  1528	CL-Cleanup-mailer 	General pathname comments 
C02202 00395	∂13-Jun-89  1528	CL-Cleanup-mailer 	Issue: PATHNAME-SYSTEM-TYPE (Version 1)  
C02204 00396	∂13-Jun-89  1533	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (Version 5)    
C02206 00397	∂13-Jun-89  1533	CL-Cleanup-mailer 	Issue: STREAM-CAPABILITIES (Version 3)   
C02208 00398	∂13-Jun-89  1553	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)    
C02227 00399	∂13-Jun-89  1623	CL-Cleanup-mailer 	General pathname comments 
C02235 00400	∂14-Jun-89  1205	CL-Cleanup-mailer 	Re: Issue: PATHNAME-LOGICAL (Version 2)  
C02241 00401	∂14-Jun-89  1444	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SYSTEM-TYPE (Version 1)   
C02243 00402	∂16-Jun-89  1207	CL-Cleanup-mailer 	Issue: READ-CASE-SENSITIVITY (Version 3) 
C02262 00403	∂16-Jun-89  1329	CL-Cleanup-mailer 	Issue: SEQUENCE-TYPE-LENGTH (version 1)  
C02270 00404	∂16-Jun-89  1335	CL-Cleanup-mailer 	Issue: SEQUENCE-TYPE-LENGTH (version 1)  
C02279 00405	∂16-Jun-89  1617	CL-Cleanup-mailer 	Issue: READ-CASE-SENSITIVITY (Version 3) 
C02286 00406	∂16-Jun-89  2049	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 2 
C02288 00407	∂16-Jun-89  2122	CL-Cleanup-mailer 	Issue: PATHNAME-SYSTEM-TYPE (Version 1)  
C02291 00408	∂17-Jun-89  0851	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 3)  
C02299 00409	∂18-Jun-89  1307	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02302 00410	∂19-Jun-89  0930	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02306 00411	∂19-Jun-89  1007	CL-Cleanup-mailer 	mail lossage (and Issue: READ-CASE-SENSITIVITY (Version 3))  
C02310 00412	∂19-Jun-89  1020	CL-Cleanup-mailer 	Issue: MAP-INTO (version 2)    
C02315 00413	∂19-Jun-89  1021	CL-Cleanup-mailer 	Re: Issue: DATA-IO (version 7) 
C02318 00414	∂19-Jun-89  1032	CL-Cleanup-mailer 	Issue: BIT-ARRAY-FUNCTIONS (version 6)   
C02320 00415	∂19-Jun-89  1046	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 3)  
C02328 00416	∂19-Jun-89  1047	CL-Cleanup-mailer 	Issue: BIT-ARRAY-FUNCTIONS (version 6)   
C02331 00417	∂19-Jun-89  1109	CL-Cleanup-mailer 	Re: Issue: DATA-IO (version 7) 
C02335 00418	∂19-Jun-89  1255	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02339 00419	∂19-Jun-89  1313	CL-Cleanup-mailer 	re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02340 00420	∂19-Jun-89  1349	CL-Cleanup-mailer 	Re: Issue: DATA-IO (version 7) 
C02345 00421	∂19-Jun-89  1540	CL-Cleanup-mailer 	Issue: BIT-ARRAY-FUNCTIONS (version 6)   
C02349 00422	∂19-Jun-89  1545	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02354 00423	∂20-Jun-89  1358	CL-Cleanup-mailer 	Issue: SEQUENCE-TYPE-LENGTH (version 1)  
C02356 00424	∂20-Jun-89  1943	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02360 00425	∂20-Jun-89  2123	CL-Cleanup-mailer 	re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02363 00426	∂20-Jun-89  2347	CL-Cleanup-mailer 	Rejected mail   
C02367 00427	∂21-Jun-89  0703	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (version 10)
C02372 00428	∂21-Jun-89  1507	CL-Cleanup-mailer 	Issue: BIT-ARRAY-FUNCTIONS (version 6)   
C02377 00429	∂21-Jun-89  1511	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 3)  
C02383 00430	∂21-Jun-89  1513	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 3)  
C02389 00431	∂21-Jun-89  1548	CL-Cleanup-mailer 	Issue SUBTYPEP-TOO-VAGUE, version 5 
C02391 00432	∂21-Jun-89  1732	CL-Cleanup-mailer 	Issue: BIT-ARRAY-FUNCTIONS (version 6)   
C02395 00433	∂21-Jun-89  1835	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL (version 3) 
C02400 00434	∂21-Jun-89  2208	CL-Cleanup-mailer 	Re: Issue: MAP-INTO (version 2)
C02402 00435	∂22-Jun-89  1043	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL (version 3) 
C02408 00436	∂22-Jun-89  1131	CL-Cleanup-mailer 	Issue: READ-CASE-SENSITIVITY (Version 4) 
C02425 00437	∂22-Jun-89  1159	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL (version 3) 
C02428 00438	∂22-Jun-89  1403	CL-Cleanup-mailer 	Issue: READ-CASE-SENSITIVITY (Version 4) 
C02438 00439	∂23-Jun-89  0550	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 4)  
C02444 ENDMK
C⊗;
∂13-Mar-89  1254	CL-Cleanup-mailer 	amendments to already passed issues 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89  12:54:30 PST
Received: from fafnir.think.com by Think.COM; Mon, 13 Mar 89 15:50:47 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 13 Mar 89 15:52:12 EST
Received: by verdi.think.com; Mon, 13 Mar 89 15:49:01 EST
Date: Mon, 13 Mar 89 15:49:01 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903132049.AA02739@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 11 Mar 89 17:50 EST <19890311225011.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: amendments to already passed issues

   Date: Sat, 11 Mar 89 17:50 EST
   From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
   ...
   I'm glad -somebody- is double-checking already passed issues.  Also I'm
   glad that -you- are.

Thanks for the compliment.  Maybe someday I will have atoned for ~:{ ~:↑ ~}.

--Quux

∂13-Mar-89  1352	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 3)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89  13:51:55 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA16534; Mon, 13 Mar 89 11:37:16 PST
Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA20771; Mon, 13 Mar 89 11:32:38 PST
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
	id AA00318; Mon, 13 Mar 89 11:35:38 PST
Date: Mon, 13 Mar 89 11:35:38 PST
From: jrose@Sun.COM (John Rose)
Message-Id: <8903131935.AA00318@lukasiewicz.sun.com>
To: sandra%defun@cs.utah.edu
Cc: rpg@lucid.com, CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu,
        Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 11 Mar 89 18:42:56 MST <8903120142.AA00878@defun.utah.edu>
Subject: Issue: LOAD-OBJECTS (Version 3)

   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
   Date: Sat, 11 Mar 89 18:42:56 MST
  ...
   Have two generic functions, not one.  The first would get called by
   compile-file and it would return a list of components (or whatever)
   that are required to reconstruct the object.  The compiler would dump
   this list of objects in its usual way.  The loader would apply the
   second generic function to this list to reconstruct the object.  It
   avoids the nasty syntax you object to, doesn't require functions to be
   dumpable, doesn't require any special support for circular constants,
   and ought to be real easy to add to the compiler/loader.  (You could
   essentially convert the constant into a LOAD-TIME-VALUE expression.)

Two objections here:



One is that this scheme cannot support circular constants.  Since
LOAD-OBJECTS is not the issue which determines circular constants, it
probably should not force or presuppose a decision against circular
constants.

Supporting circular constants requires two phases of object
construction, one which creates at least a valid reference to the
object, and a second one which further initializes the object (at least
by patching in back-references to finish building circularities).

In order for your technique to support circular constants, you still
need #'make-load-form to return two things, not one.  It would return
two argument lists, and there would be two load-time generic functions.



The other objection is that an arglist for a fixed generic function is
less general and more complex than an EVAL-able form (or a thunk, as rpg
suggests).  The programmer must coordinate the construction of the
argument list with the definition of the method to digest it at load
time, which is probably on a different page of the source code.  What's
the advantage to offset the complexity and lack of flexibility?

Perhaps method combination within the load-time generic gives a clean
way to modularize the construction of an object of multiple classes?
Someone will have to show me an example of this before I believe it.
Until then, I think the simplicity of thunks (either EVAL-able or
FUNCALL-able) is far preferable.

By the way, I also share rpg's preference for functions over forms,
because functions are parametrized naturally via captured lexicals,
whereas you've got to use backquote to parametrize forms, a more
error-prone technique.

Here's an example which suggests the relative conciseness of the techniques:

	;; Using functions:
	(defmethod make-load-form ((x myclass))
	  (let ((p <pval>) (q <qval>) (r <rval>))
	    #'(lambda () <code>)))

	;; Using forms:
	(defmethod make-load-form ((x myclass))
	  `(let ((p ',<pval>) (q ',<qval>) (r ',<rval>))
	     <code>))

	;; Using a generic:
	(defmethod make-load-form ((x myclass))
	  `(cookie00012 :p ,<pval> :q ,<qval> :r ,<rval>))

	(defmethod load-time-constructor
	    ((lf (eql 'cookie00012)) &key p q r &allow-other-keys)
	  <code>)


   -Sandra
   -------
					-- John

∂13-Mar-89  1448	CL-Cleanup-mailer 	Issue: LOAD-TRUENAME (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89  14:48:09 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556116; Mon 13-Mar-89 17:45:37 EST
Date: Mon, 13 Mar 89 17:45 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890313174517.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

This one was kind of on the table (due to Touretzky), but never got
written up formally. I think it's important, so I'll risk getting yelled
at by sending it out `new' at the last minute...

-----
Issue:        LOAD-TRUENAME
Forum:	      Cleanup
References:   LOAD (p426), PROVIDE (p188), REQUIRE (p188),
	      Issue REQUIRE-PATHNAME-DEFAULTS
Category:     ADDITION
Edit history: 13-Mar-89, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

 It is difficult to construct sets of software modules which work
 together as a unit and which port between different implementations.

 REQUIRE and PROVIDE were intended to provide this level of support
 but have `failed' to be portable in practice.

 Typical user configurations involve a `system definition' file which
 loads the modules of a `system' (collection of software modules).

 Among the specific problems which arise are:

  - File system types may vary. Different file syntax must be used for
    each site.

  - Even with the same Lisp implementation and host file system type,
    the directory in which a software system resides may differ from
    delivery site to delivery site.

  - Multiple `copies' of the same system may reside in different
    directories on the same machine.

Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):

 Introduce new variables:

   *LOAD-TRUENAME*					[Variable]

   This special variable is initially NIL, but is bound by LOAD to
   hold the truename of the pathname of the file being loaded.

   *COMPILE-FILE-TRUENAME*				[Variable]

   This special variable is initially NIL, but is bound by 
   COMPILE-FILE to hold the truename of the pathname of the file
   being compiled.
   
Example:

 ------ File SETUP ------
 (IN-PACKAGE 'MY-STUFF)
 (DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
 (DEFVAR *SOURCE-FILE* (COMPILE-TRUENAME) "Just for debugging.")
 (DEFVAR *LOADED-FILE* *LOAD-TRUENAME*)
 (DEFUN LOAD-MY-SYSTEM ()
   (DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
     (LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-TRUENAME*))))
 ------------------------

 (LOAD "SETUP")
 (LOAD-MY-SYSTEM)

Rationale:

 This satisfies the most common instances of the frequently reported
 problem in the Problem Description.

Current Practice:

 Wide variation.

 In some implementations, calling LOAD binds or sets 
 *DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
 LOADed will default to being `nearby.'

 Some implementations provide special variables that are similar or
 identical to one or both of those proposed.

 Some implementations have a way to represent the pathname for the
 current working directory, and make the default pathname default
 to that, so that loading without specifying a default again tends to
 get `nearby' files.

 None of these techniques is portable, unfortunately, because there
 is no agreement.

Cost to Implementors:

 Very small.

Cost to Users:

 None. This change is upward compatible.

Cost of Non-Adoption:

 Continued difficulty for anyone trying to put a system of modules
 in a form where they can be conveniently delivered using portable code.

Benefits:

 The cost of non-adoption is avoided.

Aesthetics:

 Negligible.

Discussion:

 Touretzky raised the issue most recently on Common-Lisp. A number
 of people immediately jumped on the bandwagon, indicating it was
 important to them, too.

 Pitman made three suggestions in response, of which the above is
 the first. The others included:
  2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
     lists of the truenames of all files being loaded or compiled,
     respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
 
  3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
    ((LOAD truename) (COMPILE-FILE truename) ...)
    during the dynamic invocation of LOAD and COMPILE-FILE.
 
 Touretzky responded:
 ``I like KMP's proposals.  I like the second one best: have separate
   variables for files being loaded and files being compiled, and use
   them to maintain a stack so we can see the nesting of loads within
   files.''

 Pitman ultimately chose to present the first rather than the second
 because it seemed simpler, easier to explain, and more likely to
 pass at this late date.

∂13-Mar-89  1457	CL-Cleanup-mailer 	Issue CLOS-CONDITIONS, v4 
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89  14:57:13 PST
Date: Sat 11 Mar 89 19:32:37-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue CLOS-CONDITIONS, v4
To: kmp@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477306674.30.IIM@ECLA.USC.EDU>

I would like to second Richard Mlynarik's suggestion of a REPORT-CONDITION
method, for much the same reasons he mentioned.  It's really ugly to have to
always include the check for *PRINT-ESCAPE* with a CALL-NEXT-METHOD every time
you want to define your own report method for a condition.

kab
-------

∂13-Mar-89  1457	CL-Cleanup-mailer 	gls cleanups    
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89  14:57:49 PST
Date: Sun 12 Mar 89 16:03:32-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: gls cleanups
To: gls@THINK.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477530754.30.IIM@ECLA.USC.EDU>

> (2) SYMBOL-MACROLET-SEMANTICS should perhaps also specify that PSETQ of a
>     symbol-macro symbol behaves like PSETF.

This probably isn't strictly necessary.  PSETQ is a macro which presumably
expands into code which uses SETQ (assuming it doesn't expand into code which
uses an implementation-specific special form), which will then be transformed
into SETF.  MULTIPLE-VALUE-SETQ is similar.  Of course, it might be easier for
a compiler to optimize a PSETF than the transformed PSETQ expansion.

kab
-------

∂13-Mar-89  1500	CL-Cleanup-mailer 	Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER  
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89  15:00:48 PST
Date: Sun 12 Mar 89 16:01:13-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER
To: kmp@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477530332.30.IIM@ECLA.USC.EDU>

The question of whether NaNs and such cause TYPE-ERROR or ARITHMETIC-ERROR is
what I feel unsure about.  We currently signal ARITHMETIC-ERROR, but I don't
believe there was a lot of analysis that went into that decision.  I think
that any decision we make on this is likely to be pretty arbitrary.  I can't
think of any strong first-principled arguments either way, so it may be a
matter of which seems more convenient to the people who really care about
an error being signaled for such things.

kab
-------

∂13-Mar-89  1501	CL-Cleanup-mailer 	Issue SUBTYPEP-TOO-VAGUE  
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89  15:01:01 PST
Date: Sun 12 Mar 89 16:05:04-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue SUBTYPEP-TOO-VAGUE
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim%ECLA@ECLC.USC.EDU
Message-ID: <12477531034.30.IIM@ECLA.USC.EDU>

> I don't see any problem here.  My compiler has a type testing function
> that handles VALUES types itself and converts (FUNCTION ...) to just
> FUNCTION before calling SUBTYPEP, so it isn't prevented from doing anything
> that it wants.

And what does it do with a deftype'ed type which expands into a list form
FUNCTION type specifier or into a VALUES type specifier?  Did you remember to
call type-expand before doing the conversion?  Note that a user wouldn't be
able to do that, since type-expand isn't part of the language.  And what about
an OR of several FUNCTION or VALUES type specifiers?  Besides, it's wrong to
have to define the handling of the VALUES type yourself, even ignoring these
problems, since you end up with each user who wants this capability having to
write his own, rather than having the facility built into SUBTYPEP where it
belongs.

> If you want these cases to be permitted, then you will need to define what
> they mean.

Thats an ugly job.  One of us was working on it, but hasn't had much time to
devote to the problem -- probably nobody here at IIM will be able to get to
it any time soon.  Right now we mostly just don't want these to be required
signal error cases, with the intention of fully specifying them later.
(Note: some of the ugliness involves questions about what to do when the
typed lambda-lists aren't congruent (in the CLOS sense)).

kab
-------

∂13-Mar-89  1502	CL-Cleanup-mailer 	Issue PEEK-CHAR-READ-CHAR-ECHO 
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89  15:01:49 PST
Date: Sun 12 Mar 89 16:09:23-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue PEEK-CHAR-READ-CHAR-ECHO
To: kmp@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477531820.30.IIM@ECLA.USC.EDU>

The whole discussion of operating system considerations in the proposal just
confuses the issue, and isn't relevent to what the actual proposal says, so
that's a problem with the proposal.  It may have lead some people to vote for
it because they got confused into thinking that the operating system
considerations were relevent.  Note that I may have fallen into this trap.

When I wrote the example, I was thinking in terms of a reader that used
read-char/unread-char, rather than peek-char.  Looking at the proposal again,
I note that it mentions the reader.

However, I think the discussion of the cost of this proposal is pretty weak.
First, an implication of the proposal is that peek-char is no longer
equivelent to read-char followed by unread-char.  This means that all code
which uses read-char/unread-char needs to be re-examined, and probably
modified.  That's a potentially large amount of code, due to the performance
effect that is not mentioned at all in the proposal.  Namely, it is frequently
the case when parsing input that you get stretches where all the characters
are going to be used.

An example might be a reader's subroutine for reading an extended token.  If
the two forms of 'peeking' are equivelent, then the token reader can iterate
on read-char until it finds a terminator, unreads it, and proceeds.  Under
this proposal, it has to iterate on peek-char, decide if it likes it, and if
so then read-char to really get it.  For such important subroutines in the 
reader as the token reader, the string reader, the whitespace scanner, and 
similar functions, this could mean something on the order of a factor of 2
performance hit.  Slowing down important parts of the reader by a factor of
2 is not likely to make anyone smile (except those C lovers out there :-).

We're not advocating that it be left vague.  I should have taken the time to
present our counter-proposal, but I was in a hurry, and I've had this note on
my desk to do something about this issue for over a month now, so I didn't.
Foolish me.

Our position is that LAST-READ-CHAR is the proper behavior, with an additional
restriction that it is an error to do output to a stream between the calls to
read and unread.  As a hint, here is how we've implemented this behavior.

1. Define two operations on streams, ECHO and UNECHO.
2. echo-streams, when reading a character, apply echo to the output stream and
   the character.  unread on echo-streams calls unecho on the output stream 
   and char, in addition to passing along the unread to the input stream.
3. Other meta-streams simply pass these operations along to their output side.
4. data-streams have two choices, depending on whether they have the
   capability to 'back out' output.  If they can back it out, then echo is
   equivilent to write-char, and unecho backs it out.  If they can't, then
   they record the echo in a slot, writing any already pending echo.  unecho
   clears the pending echo slot.  all normal output operations first write
   pending echo.  a normal close also forces pending echoing.

There is potentially more hair involved, intended to either support or
complain about improper usage, like calling unread after peek, doing output
between the read and the unread, &etc.  Note that this depends on the single
unread restriction in order to work right in all cases.

kab
-------

∂13-Mar-89  1457	CL-Compiler-mailer 	Issue LOCALLY-TOP-LEVEL, v1   
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89  14:57:25 PST
Date: Sat 11 Mar 89 19:34:07-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue LOCALLY-TOP-LEVEL, v1
To: Moon@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, cl-compiler@SAIL.STANFORD.EDU,
    iim%ECLA@ECLC.USC.EDU
Message-ID: <12477306947.30.IIM@ECLA.USC.EDU>

This issue arguably ought to be a compiler issue, rather than cleanup, since
the compiler people seem to be the ones currently mucking about with what we
mean by top-level.  (Besides, Larry is overworked as it is :-)

More seriously, I support this idea, in part because of the frob example.  This
kind of thing was one of the reasons I voted against the DECLARATION-SCOPE
proposals.

By the way, my notes from the Hawaii meeting say that we passed the NO-HOISTING
proposal, and that LIMITED-HOISTING was not even called to a vote.

kab
-------

∂13-Mar-89  1557	CL-Cleanup-mailer 	Issue LOCALLY-TOP-LEVEL, v1    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89  15:55:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556199; Mon 13-Mar-89 18:51:17 EST
Date: Mon, 13 Mar 89 18:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue LOCALLY-TOP-LEVEL, v1
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU, cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: <12477306947.30.IIM@ECLA.USC.EDU>
Message-ID: <19890313235118.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat 11 Mar 89 19:34:07-PST
    From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>

    This issue arguably ought to be a compiler issue, rather than cleanup, since
    the compiler people seem to be the ones currently mucking about with what we
    mean by top-level.  (Besides, Larry is overworked as it is :-)

I may have sent it to the wrong committee by mistake.  If either Sandra or
Larry instructs me to send it to the other committee, I'll do so forthwith.

    More seriously, I support this idea, in part because of the frob example.  This
    kind of thing was one of the reasons I voted against the DECLARATION-SCOPE
    proposals.

    By the way, my notes from the Hawaii meeting say that we passed the NO-HOISTING
    proposal, and that LIMITED-HOISTING was not even called to a vote.

You're right, I copied down the wrong proposal name.  What I said about
it is true of the NO-HOISTING proposal but false of the LIMITED-HOISTING
proposal.  This needs to be fixed before it's distributed more widely.

∂13-Mar-89  1726	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL (Version 9)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89  17:26:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 MAR 89 17:14:49 PST
Date: 13 Mar 89 17:14 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
 message of Mon, 13 Feb 89 20:34:53 GMT
To: cl-cleanup@sail.stanford.edu
Message-ID: <890313-171449-21261@Xerox>

I'm finally getting back to doing some cleanup work, after a long hiatus.

The last version of PROCLAIM-LEXICAL I have is Version 9, which was
distributed before the Hawaii meeting. There were the various comments on
Version 9, amendments proposed but not passed, and, more recently, mail
from Sandra Loosemore, Jeff Dalton, JonL White, Gail Zacharias and David
Moon.

However, there's no new version.

Who will produce one? If we don't have a new version, we probably won't be
able to vote on anything. 

I think that would be a shame.

Larry

∂13-Mar-89  1737	CL-Compiler-mailer 	Re: Issue: LOAD-OBJECTS (Version 3)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89  17:36:36 PST
Received: by ti.com id AA04345; Mon, 13 Mar 89 19:33:22 CST
Received: from Kelvin by tilde id AA09130; Mon, 13 Mar 89 19:25:26 CST
Message-Id: <2814830669-4406064@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89  19:24:29 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Richard P. Gabriel" <rpg@lucid.com>
Cc: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
In-Reply-To: Msg of Sat, 11 Mar 89 16:46:51 PST from Richard P. Gabriel <rpg@lucid.com>

> I was a little surprised to see that this proposal talks about load
> forms instead of load functions (which goes to show how much I've been
> paying attention).

One advantage of sticking with the load form approach is that it has
already been implemented and demonstrated to work.

> I think people will find the macro approach (the current approach)
> baroque, partly because the approach is best understood by thinking of
> an input phase to a compiler or some such program, rather than by
> thinking about an output phase when everything has already been supposedly
> created. For example, when I read the current proposal, I imagined it
> in the FASDUMP phase.

Think of it as input to the loader.

> One drawback of my proposal is that the function approach is a little
> more verbose in some cases. I also think it is subject to more
> circularity errors by novices than the macro approach.  On the other
> hand, the functional approach makes one think about the issues a
> little harder when writing the code, which is possibly a good thing.

This sounds like a clear disadvantage, without a clear advantage.

>   ;; Example 3 (expanded to do a hairy thing that cannot be easily done
>   ;; in the macro approach).
...
> One can imagine the shared lexical environment of the creator and initializer
> being a high-bandwidth channel for information, such as the important
> information passed in the above example.

This example illustrates the following assumptions about dumping
constants: 

  1. Lexical closures can be dumped and loaded.
  2. Two closures that share the same environment at compile-time will
     also share the same environment at load time.
  3. The lexical environment as reconstructed by the loader is not
     write-protected (meaning that closures are not really constants).
  4. It is safe to assume that none of the closed-over variables are
     changed between the time the first closure is dumped and the time
     the last closure that shares that environment is dumped.

It could be argued that all of these would be desirable, but I think
it's a little late to be biting off that much.

∂13-Mar-89  1754	CL-Compiler-mailer 	Re: Issue: LOAD-OBJECTS (Version 3)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89  17:54:05 PST
Received: by ti.com id AA04437; Mon, 13 Mar 89 19:49:49 CST
Received: from Kelvin by tilde id AA09309; Mon, 13 Mar 89 19:36:34 CST
Message-Id: <2814831335-4446073@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89  19:35:35 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: jrose@Sun.COM (John Rose)
Cc: sandra%defun@cs.utah.edu, rpg@lucid.com, CL-Cleanup@sail.stanford.edu,
        CL-Compiler@sail.stanford.edu
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
In-Reply-To: Msg of Mon, 13 Mar 89 11:35:38 PST from jrose@Sun.COM (John Rose)

> One is that this scheme cannot support circular constants.

I second the objection.

> By the way, I also share rpg's preference for functions over forms,
> because functions are parametrized naturally via captured lexicals,
> whereas you've got to use backquote to parametrize forms, a more
> error-prone technique.
> 
> Here's an example which suggests the relative conciseness of the techniques:
> 
> 	;; Using functions:
> 	(defmethod make-load-form ((x myclass))
> 	  (let ((p <pval>) (q <qval>) (r <rval>))
> 	    #'(lambda () <code>)))
> 
> 	;; Using forms:
> 	(defmethod make-load-form ((x myclass))
> 	  `(let ((p ',<pval>) (q ',<qval>) (r ',<rval>))
> 	     <code>))

I don't think that's a completely fair comparison because the LET is
required for the function approach, but would usually not be needed with
the forms approach:

	;; Using functions:
	(defmethod make-load-form ((x myclass))
	  (let ((p <pval>) (q <qval>) (r <rval>))
	    #'(lambda () (make-mine p q r))))

	;; Using forms:
	(defmethod make-load-form ((x myclass))
          `(make-mine ',<pval> ',<qval> ',<rval>))

This is a very simple use of back-quote, while the function approach is
error-prone because it would be too easy to forget to do the LET
binding.

∂14-Mar-89  0738	CL-Cleanup-mailer 	Re: Issue PEEK-CHAR-READ-CHAR-ECHO  
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 14 Mar 89  07:38:43 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac25715; 14 Mar 89 10:16 EST
Received: from draper.com by RELAY.CS.NET id af09120; 14 Mar 89 10:11 EST
Date: Tue, 14 Mar 89 08:19 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue PEEK-CHAR-READ-CHAR-ECHO
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525

> From: "Kim A. Barrett" <IIM%ECLA@eclc.usc.EDU>
> Subject: Issue PEEK-CHAR-READ-CHAR-ECHO
> To: kmp@scrc-stony-brook.ARPA
> Cc: cl-cleanup@sail.stanford.EDU, iim%ECLA@eclc.usc.EDU
 
> 1. Define two operations on streams, ECHO and UNECHO.
> 2. echo-streams, when reading a character, apply echo to the output stream and
>    the character.  unread on echo-streams calls unecho on the output stream 
>    and char, in addition to passing along the unread to the input stream.
> 3. Other meta-streams simply pass these operations along to their output side.
> 4. data-streams have two choices, depending on whether they have the
>    capability to 'back out' output.  If they can back it out, then echo is
>    equivilent to write-char, and unecho backs it out.  If they can't, then
>    they record the echo in a slot, writing any already pending echo.  unecho
>    clears the pending echo slot.  all normal output operations first write
>    pending echo.  a normal close also forces pending echoing.

> There is potentially more hair involved, intended to either support or
> complain about improper usage, like calling unread after peek, doing output
> between the read and the unread, &etc.  Note that this depends on the single
> unread restriction in order to work right in all cases.

There SURE IS more hair involved.  All you're doing is punting the basic
problem down to a lower level.  Maybe the stream internally takes the actual
send-the-character-to-the-output-stream and implements it via SEND-OUT and
UN-SEND-OUT calls, where SEND-OUT buffers the character in case an UN-SEND-OUT
comes along...
 
In the
 
'foo(* a b)
 
example, when the ( is seen, either it gets echoed at that point or it
doesn't.  This ECHO/UNECHO stuff doesn't change anything.  And posing a
restriction on stream output between READ and UNREAD is unreasonable,
in my opinion.

∂14-Mar-89  0738	CL-Cleanup-mailer 	More re: PEEK-CHAR-READ-CHAR-ECHO   
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 14 Mar 89  07:38:47 PST
Received: from relay2.cs.net by RELAY.CS.NET id ad25718; 14 Mar 89 10:16 EST
Received: from draper.com by RELAY.CS.NET id ag09120; 14 Mar 89 10:12 EST
Date: Tue, 14 Mar 89 08:22 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: More re: PEEK-CHAR-READ-CHAR-ECHO
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525

Just for the record, I wouldn't wish to see any proposal adopted that didn't
support the notion of PEEK-CHAR being equivalent to READ-CHAR + UNREAD-CHAR.
Maybe the IIM implementation solves this problem - or thinks it does - but
I don't see quite how.

∂14-Mar-89  0756	CL-Cleanup-mailer 	Re: Issue: DESTRUCTURING-BIND (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  07:56:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 07:48:32 PST
Date: 14 Mar 89 07:48 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DESTRUCTURING-BIND (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Wed, 25 Jan 89 11:38 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890314-074832-22564@Xerox>

Version 2 is the most recent I have. There's been some debate about &WHOLE,
&ENVIRONMENT, NIL and IGNORE in the destructuring list.


&ENVIRONMENT:
	everybody says disallow

&WHOLE:
	Moon said allow (the second time.)

NIL:
	Moon says allow as a way of ignoring.
	KMP says OK.

&BODY:
	KMP makes case for disallowing, but says
	allow.

There was some additional discussion that resulted in the related issue of
DEFMACRO-LAMBDA-LIST. 

I'd be happy with a proposal that said NIL is ignored, &WHOLE and &BODY are
allowed, and that &ENVIRONMENT is disallowed.

KMP made a reference to "the next version" in his message of 30 Jan 89, so
maybe he'll produce one.

Larry

∂14-Mar-89  0835	CL-Cleanup-mailer 	Re: Issue: CONDITION-RESTARTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  08:35:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 08:28:15 PST
Date: 14 Mar 89 08:27 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CONDITION-RESTARTS (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Sat, 11 Mar 89 22:03 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
 CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890314-082815-22614@Xerox>

I don't think there will be any strong objection if, after some
consideration, you want to remove a function from the condition system,
even though it is "incompatible"; the condition system has not been with us
long enough that "tweaks" are out of line.

Should the condition system symbols be in the LISP package or the
CONDITIONS package? The current draft of the standard doesn't distinguish
their package.

∂14-Mar-89  0923	CL-Cleanup-mailer 	More re: PEEK-CHAR-READ-CHAR-ECHO   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  09:23:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556600; Tue 14-Mar-89 12:11:10 EST
Date: Tue, 14 Mar 89 12:11 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: More re: PEEK-CHAR-READ-CHAR-ECHO
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 14 Mar 89 08:22 EST from "Steve Bacher (Batchman)" <SEB1525@draper.com>
Message-ID: <19890314171109.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 14 Mar 89 08:22 EST
    From: "Steve Bacher (Batchman)" <SEB1525@draper.com>

    Just for the record, I wouldn't wish to see any proposal adopted that didn't
    support the notion of PEEK-CHAR being equivalent to READ-CHAR + UNREAD-CHAR.

Such a proposal was already adopted in January by an 11 to 5 vote.  To clarify
the double negatives, PEEK-CHAR-READ-CHAR-ECHO as adopted in January eliminates
the equivalence of PEEK-CHAR to READ-CHAR+UNREAD-CHAR, but only when peeking
from a stream created by MAKE-ECHO-STREAM.

We can reconsider anything, of course, if that's how we want to spend our time.

∂14-Mar-89  1104	CL-Cleanup-mailer 	Re: Issue IGNORE-VARIABLE, v1  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  11:02:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 09:41:14 PST
Date: 14 Mar 89 09:03 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue IGNORE-VARIABLE, v1
In-reply-to: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>'s message of Sun, 19
 Feb 89 15:42:05 PST
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890314-094114-1073@Xerox>

I didn't check the references when this was first proposed, but presumably
pp 55-56 and 59-65 of CLtL have some indication that duplicates are not
allowed. This issue was "withdrawn", i.e., we didn't propose it.

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

Date: Mon, 7 Mar 88 15:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU

Issue:          LAMBDA-LIST-DUPLICATES
References:     5.1.2 Variables (pp55-56)
	        5.2.2 Lambda-Expressions (pp59-65),
	        LET* (p111-112), PROG* (pp131-132)
Category:       ADDITION
Edit history:   07-Mar-88, Version 1 by Pitman
Related Issues: DECLARATION-SCOPE
Status:	        For Internal Discussion

Problem Description:

  CLtL forbids binding the same variable more than once in the same
  binding form. This rule is claimed by some to be overly restrictive
  because there are some well-defined situations in which it would be
  useful to duplicate a variable name in the same binding list.

Proposal (LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE):

  Allow variable names to be repeated in situations where bindings are
  sequential and the binding construct is non-iterative (specifically,
  in the &AUX part of a normal lambda list, in the bindings of LET*, and
  in the bindings of PROG*).

Test Case:

  ((LAMBDA (B &AUX (B (+ B 1)) (B (+ B 1))) B) 0) => 2
  (LET* ((B 0) (B (+ B 1))) B)                    => 1
  (PROG* ((B 0) (B (+ B 1))) (RETURN B))          => 1

Rationale:

  Because these bindings are inherently sequential and non-iterative, there
  would no ambiguity about the intended scope bindings, and it is sometimes
  useful to repeat the name of a binding when doing various kinds of
  encapsulations or successive refinements to the same value.

  The intent of duplicated bindings in "parallel binding" constructs like
  LET or iterative constructs like DO* is less easy to predict, so it is
  not proposed that the current rule be relaxed for such constructs.

Current Practice:

  The Symbolics implementation currently checks for this case and
  signals an error.

  [Others?]

Cost to Implementors:

  Converting would be relatively easy, but not completely trivial.
  There is some interaction with declaration processing which becomes
  involved, too (see issue DECLARATION-SCOPE).

Cost to Users:

  None. This is an upward-compatible change.

Cost of Non-Adoption:

  Some useful expressional style would be lost.

Benefits:

  A useful expressional style would be made available.

Aesthetics:

  The rule for variable duplication would be more syntactically complex
  but pragmatically simpler.

Discussion:

  A request for a discussion of this issue came from the Japanese
community.
  Pitman drafted this formal proposal and supports
  LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE.



     ----- Next Message -----

From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Tue, 8 Mar 88 20:28:54 gmt
To: CL-Cleanup@sail.stanford.edu
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
Cc: KMP@scrc-stony-brook.arpa

Current practice:
  Both PopLog Common Lisp and KCL allow variables to appear more
  than once in a lambda-list.  In the three suggested test cases,
  they both have the later binding current in the body of the form
  and so return the values 2, 1, and 1 respectively.

  In addition, both allow variables in other cases, specifically:

  KCL:
    ((lambda (a a) a) 1 2) => 2
 
  PopLog:
    ((lambda (a a) a) 1 2) => 1



     ----- Next Message -----

Date: Fri, 11 Mar 88 13:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880307150614.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>

I oppose LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE; I think
Common Lisp should continue to forbid binding the same variable more
than once in the same binding form.  I have two reasons:

1. This is an unnecessary complication of the language rules.  Allowing
duplicated variable names doesn't make it possible to write programs
that you couldn't write before, it just allows the programs to be
written in a more obscure way.

2. This would result in an unnecessary complication of the scoping rules
for DECLARE.  Common Lisp would have to define what happens when a
DECLARE of a variable is attached to a form that binds more than one
variable with the declared name.



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

∂14-Mar-89  1253	CL-Cleanup-mailer 	re: PATHNAME-PRINT-READ, v1    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  12:53:02 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 12:33:37 PST
Date: 14 Mar 89 12:32 PST
From: masinter.pa@Xerox.COM
Subject: re: PATHNAME-PRINT-READ, v1
In-reply-to: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>'s message of Thu, 9 Feb
 89 11:25:54 PST
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890314-123337-1569@Xerox>

If this is going to be discussed at the X3j13 meeting, we should have
a new version with all of the various additions to current practice
and discussions appended.


pierson says:
KCL uses #"..."

EB says:
"For Current Practice:

Lucid CL also implements the proposed behavior.

For Cost to Users:

Users who define their own #P read macro may be unhappy.


I weakly support this change. 

..."

Masinter says:

"For Current Practice, Envos Medley prints pathnames with the syntax #.(pathname "asdf").

I like #P"asdf" better, but #.(pathname string) is currently pretty portable.

"

Barrett says:

"For Current Practice, IIM Common Lisp prints pathnames with the syntax
#.(parse-namestring "asdf" "host").  The reason for using this convention is
that for some strings you need to know what parsing conventions to use in order
to get back an equivalent pathname.  And yes, I agree it is ugly and verbose.

"

KMP and kab sent a long messages but I can't summarize easily.

Mly says "I still don't understand why this needs to be standardised upon..."
and "Even if others do feel an urgent need to allow such portablability, I
don't understand why #S(PATHNAME ...) syntax isn't acceptable."

∂14-Mar-89  1317	CL-Cleanup-mailer 	Re: PATHNAME-PRINT-READ, v1    
Received: from multimax.encore.com ([129.91.1.14]) by SAIL.Stanford.EDU with TCP; 14 Mar 89  13:17:08 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA18290; Tue, 14 Mar 89 16:16:11 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA05011; Tue, 14 Mar 89 16:13:03 EST
Message-Id: <8903142113.AA05011@mist.>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: PATHNAME-PRINT-READ, v1 
In-Reply-To: Your message of 14 Mar 89 12:32:00 -0800.
             <890314-123337-1569@Xerox> 
Date: Tue, 14 Mar 89 16:13:01 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    Date: 14 Mar 89 12:32 PST
    From: masinter.pa@Xerox.COM

    If this is going to be discussed at the X3j13 meeting, we should have
    a new version with all of the various additions to current practice
    and discussions appended.
    
    pierson says:
    KCL uses #"..."
    
Absolutely true.  However I don't approve of it for several reasons:

    #P is more prevalent

    Issue: PRETTY-PRINT-INTERFACE puts #"..." to a better use.  This
    is relevant for those of us who will use Water's pretty printer
    whether or not the issue passes.

    #"..." is just too good a "name" to be reserved for pathname syntax.

∂14-Mar-89  1344	CL-Cleanup-mailer 	Re: Issue: LOAD-TRUENAME (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  13:43:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 13:19:26 PST
Date: Tue, 14 Mar 89 13:19 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: LOAD-TRUENAME (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <890313174517.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890314211919.6.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

I favor this.  I would even favor either of the other two ideas even at
this `late date'.  The behavior of each of the proposals is simple, its
easy to see what it will and won't do, and it satisfies a real demand.

I should note that I have never wanted the incremented functionally
offered by the `stack' proposals, but I could still vote for them.
-------

∂14-Mar-89  1344	CL-Cleanup-mailer 	Re: Issue: CLOS-CONDITIONS (Version 4)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  13:43:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 13:23:23 PST
Date: Tue, 14 Mar 89 13:23 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: CLOS-CONDITIONS (Version 4)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Mly@AI.AI.MIT.EDU, CL-Cleanup@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <890313130600.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890314212317.7.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no

    Date: Mon, 13 Mar 89 13:06 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    I do not agree that it is a -necessary- thing to specify the Meta-Class
    of conditions because all intended uses of conditions can be done
    without this information.

I don't agree with this.  If we don't specify the metaclass, then users
won't know what other classes they can mix in when defining condition
classes.  It may seem weird, but I can imagine someone wanting to mix
in an arbitrary class into a condition class.

I think we should just say that the class CONDITION is an instance of
STANDARD-CLASS, and that by default DEFINE-CONDITION defines standard
classes.  Sure it might be nice to do the read only class thing but I
don't think this is a good time to design a special purpose metaclass
for this.  
-------

∂14-Mar-89  1344	CL-Cleanup-mailer 	Issue: LOAD-TRUENAME (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  13:44:43 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 556807; 14 Mar 89 16:42:03 EST
Date: Tue, 14 Mar 89 16:42 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890313174517.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890314214204.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

I favor LOAD-TRUENAME:NEW-PATHNAME-VARIABLES.  I think this
proposal would be greatly improved by adding two more variables,
*LOAD-PATHNAME* and *COMPILE-FILE-PATHNAME*, whose values are
the pathname opened by LOAD or COMPILE-FILE, rather than the
truename.  The need for these is more obvious if you think
about systems where the pathname cannot be easily reconstructed
from the truename.  This includes file systems with symbolic
links and some pathname systems with logical pathnames.

∂14-Mar-89  1358	CL-Cleanup-mailer 	Issue: TIME-ZONE-NON-INTEGER   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  13:57:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556843; Tue 14-Mar-89 16:55:04 EST
Date: Tue, 14 Mar 89 16:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8903131137.AA05944@decwrl.dec.com>
Message-ID: <19890314215504.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

TIME-ZONE-NON-INTEGER:ALLOW is okay with me.

∂14-Mar-89  1505	CL-Cleanup-mailer 	Issue: ERROR-NOT-HANDLED (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89  15:04:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556941; Tue 14-Mar-89 18:02:30 EST
Date: Tue, 14 Mar 89 18:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-NOT-HANDLED (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu
In-Reply-To: <890314-140350-1917@Xerox>
Message-ID: <19890314230224.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

ERROR-NOT-HANDLED:PERMIT-TERMINATION is okay with me.  I would
also support a proposal to replace "the condition system as currently
described insists that the interactive debugger be entered if a
condition is unhandled" with wording that allowed implementations
to do whatever they want, with perhaps an implementation note that
many implementations prefer an interactive debugger.

∂14-Mar-89  1612	CL-Cleanup-mailer 	TYPE-OF-UNDERCONSTRAINED, version 4 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  16:11:32 PST
Received: from fafnir.think.com by Think.COM; Tue, 14 Mar 89 16:46:54 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 14 Mar 89 16:48:13 EST
Received: by verdi.think.com; Tue, 14 Mar 89 16:45:02 EST
Date: Tue, 14 Mar 89 16:45:02 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903142145.AA05320@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: TYPE-OF-UNDERCONSTRAINED, version 4


This is a proposal to amend version 3, passed as amended (to include
RANDOM-STATE) in January 1989 in Kauai.

Version 4 amends version 3 to add SHORT-FLOAT, LONG-FLOAT, and RATIONAL
to the list of types in part (a) of the proposal.


Forum:	Cleanup
Issue:      TYPE-OF-UNDERCONSTRAINED

References: TYPE-OF (CLtL)
            88-002R (Class-of)
            88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
                DATA-TYPE-HIERARCHY-UNDERSPECIFIED
                FUNCTION-TYPE
                ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
                COERCE-INCOMPLETE
			

Category:       CLARIFICATION/CHANGE

Edit history:   Version 1,  1-Dec-88, Masinter
		    Version 2,  9-Dec-88, Masinter
		    Version 3, 12-Dec-88, Masinter (fix "egregious bug")
		Versino 4, 3-14-89 Steele
Problem description:

The specification of TYPE-OF in CLtL is so weak as to leave it 
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.

This means that implementations could return T for all other objects.

Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS): 

Specify that the result of TYPE-OF satisfies the following:

(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of 

INTEGER, RATIO, FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, COMPLEX, NUMBER
SYMBOL, 
STRING, VECTOR, ARRAY, RANDOM-STATE
CONS, 
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
RATIONAL, SHORT-FLOAT, LONG-FLOAT

the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the 
implementation's SUBTYPEP can recognize.)

(b)  For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)

(c) will not be a MEMBER type specifier, or T.

For objects created by the "constructor" function of a structure
defined with DEFSTRUCT without a :TYPE option, TYPE-OF
will return the structure name.

For objects created by MAKE-INSTANCE, giving a named
class, TYPE-OF will return the class name of the class.
 
For objects which are instances of anonymous classes (i.e., where
(CLASS-NAME (CLASS-OF object)) is NIL), the result of TYPE-OF should be the
class object itself.

(The CLOS specification has already specified that class objects are
acceptable wherever type specifiers are, and in particular, as input to
SUBTYPEP and TYPEP.)

This proposal is intended to be consistent with 88-002R, 
and not to conflict with any of the definitions in that document.

Examples:

It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).

 Given:

   (defvar *foo* (make-array 5 :element-type t))
   (class-name (class-of *foo*))  =>  SIMPLE-VECTOR
  It is legal for
   (type-of *foo*)                =>  (SIMPLE-VECTOR 5)


Rationale:

The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended. 

Current practice:

Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.

Cost to Implementors:

Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal. 

Cost to Users:

Apparently none.

Cost of non-adoption:

TYPE-OF would remain potentially inconsistent.

Performance impact:

Likely none.

Benefits:

Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.

Esthetics:

Little effect.

Discussion:

Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.

The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did. 

This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.

If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass, 
and this proposal does pass, it may be that the only way an 
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.

It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable 
implementation-specific value. For example, 
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]

We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.

∂14-Mar-89  1613	CL-Cleanup-mailer 	SYMBOL-MACROLET-SEMANTICS, version 6
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  16:12:48 PST
Received: from fafnir.think.com by Think.COM; Tue, 14 Mar 89 16:42:18 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 14 Mar 89 16:43:40 EST
Received: by verdi.think.com; Tue, 14 Mar 89 16:40:28 EST
Date: Tue, 14 Mar 89 16:40:28 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903142140.AA05308@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: SYMBOL-MACROLET-SEMANTICS, version 6


This is a proposal to amend version 5, passed in January 1989 in Kauai.

Version 6 amends version 5 to require PSETQ to behave like PSETF,
to require MULTIPLE-VALUE-SETQ to accept symbol macros (but not
general SETF places), and to specify the interaction with the
*MACROEXPAND-HOOK* function.


Issue:		SYMBOL-MACROLET-SEMANTICS
References:	SYMBOL-MACROLET (88-002R page 2-81)


Related Issues: SYMBOL-MACROLET-DECLARE
Category:	CHANGE
Edit history:	29-July-88, Version 1 by Piazza
		21-September-88, Version 2 by Piazza
		22-September-88, Version 3 by Piazza 
		22-September-88, Version 4 by Piazza
		30-Nov-88, Version 5 by Masinter
		14-Mar-89, Version 6 by Steele

Problem Description:

    The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
    88-002R, profoundly alters the interpretation of symbols appearing as
    forms in a Common Lisp program--what previously was necessarily a variable
    might now be a symbol macro instead.  Macros which appear in the body of a
    SYMBOL-MACROLET form are currently unable to determine whether a symbol
    form is a variable or a symbol macro, and, if the latter, what the
    expansion of the symbol macro is.  Consequently, complex macros (such as
    SETF or PUSH) which depend on the form of their argument(s), are unable to
    produce their desired results in some cases, as in the following example:

	    (let ((a (make-array 5))
		  (i 0))
	      (symbol-macrolet ((place  (aref a (incf i))))
	        (push x place))
	      i)		==> 2

    In addition, it would be both natural and nice to be able to write

  (with-slots (rho theta) point
    (declare (single-float rho theta))
    ...computation...)

    as well as DECLARE within SYMBOL-MACROLET forms.

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 in the same lexical environment as the
    symbol macro invocation, exactly analogous to normal macros. Clarify that
    within the body of a SYMBOL-MACROLET, SETQ of a symbol defined as
    a symbol macro will be treated as if it were a SETF.

    Furthermore PSETQ of a symbol defined as a symbol macro will
    behave as if it were a PSETF, and MULTIPLE-VALUE-SETQ will behave
    as if SETQ were used on each variable to be set.

    When MACROEXPAND or MACROEXPAND-1 sees a symbol macro, it calls
    the value of *MACROEXPAND-HOOK* in the same manner as for an
    ordinary macro.  The three values given to the hook function
    in this case will be an expansion function, a form (in this case
    the symbol naming the symbol macro), and an environment.  The
    only guaranteed property of the expansion function is that when
    it is applied to the form and the environment it will return the
    correct expansion of the symbol macro.  (In particular, nothing
    it said in this specification whether the expansion is conceptually
    stored in the expansion function, the environment, or both.)

Rationale:

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

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 modified to be a special form, compilers and
    interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
    PUSH, INCF, DECF, and others.

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.

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:SPECIAL-FORM avoids the hairiest problems
    surrounding interaction of macros (like SETF) and side effects, and makes
    SYMBOL-MACROLET consistent with MACROLET.

Aesthetics:

    If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
    by making symbol macros consistent with normal macros.

Discussion:

    A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
    a dual of MACRO-FUNCTION.  However, symbol macros are simpler than normal
    macros: a symbol macro is associated with a single expansion form, rather
    than an arbitrary function which computes the expansion.  For this reason,
    the augmented MACROEXPAND-1 proposed here can also fill the role of
    SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
    T if and only if sym is a symbol macro, while the first value gives the
    expansion of sym, if it has one.

    Rather than extending the existing MACROEXPAND and MACROEXPAND-1
   functions, new functions could be introduced to expand symbol macros. 
   However, there seems to be no particular reason to do this.

∂14-Mar-89  1731	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  17:30:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 89 14:18:15 PST
Date: 14 Mar 89 14:17 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1) 
In-reply-to: David N Gray <Gray@DSG.csc.ti.com>'s message of Thu, 9 Mar 89
 18:01:27 CST
To: David N Gray <Gray@DSG.csc.ti.com>, Jeff Dalton
 <jeff@aiai.edinburgh.ac.uk>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890314-141815-1956@Xerox>

I have 15 replies to version 1, but no version 2.

Personally, I think adding a character translation table is overkill if all
that's wanted is case sensitive or no, and the performance cost unwieldy.
"Gilding the lilly."

Why not just (READTABLE-CASE <readtable>) that accepts/returns :UPCASE (the
default) or :DOWNCASE.

Note that the setting of the READTABLE-CASE in *READTABLE* should affect
printing: if (READTABLE-CASE *READTABLE*) is :DOWNCASE, then *PRINT-CASE*
is ignored; symbols should be printed with the same case as their internal
name.

This is effectively what Medley does; it was necessary to support
readtables with a case sensitive "bit" so that the same environment could
simultaneously support Interlisp (which is case sensitive) and Common Lisp.


If this is going to go anywhere, we'll need a version 2. If you want to
proceed with just the READTABLE-CHARACTER-TRANSLATION, I won't squawk too
loudly (but I think I would vote against all of the proposals, even the one
I outline above, on the grounds that they are 'unnecessary' complications.)

∂14-Mar-89  1731	CL-Cleanup-mailer 	RE: Cleanup Issue Status  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  17:31:21 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 89 15:36:44 PST
Date: 14 Mar 89 15:35 PST
From: masinter.pa@Xerox.COM
Subject: RE: Cleanup Issue Status
In-reply-to: your message of Sun, 19 Feb 89 23:14:37 PST
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890314-153644-2132@Xerox>

I have finally gotten around to reconciling your errata list from my status
list. Our differences are now:


> >+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
> >Version 3, 13-Jan-89
> >Status: passed, Jan 89 X3J13
> I believe this one was amended.

-- I have no amendments marked. Do you know what the amendment was?

> >+ DEFSTRUCT-REDEFINITION
> >Synopsis: what happens if you redefine a DEFSTRUCT?
> >Version 3, 6-Feb-89
> >Status: Passed (as amended) Jan 89 X3J13
> I don't have this one marked as amended.

-- Version 3 is the "amended" version, and was distributed after X3J13.

> >- DELETE-FILE-NONEXISTENT 
> >Version 1, 5-Oct-88
> >Comments: should just signal different errors?
> >Status: withdrawn
> I marked this as tabled.
 
-- I know no-one who intends to raise it. Maybe KMP's error signalling
proposal? I'll check.

> >- ELIMINATE-FORCED-CONSING
> >Synopsis: Add :RECYCLE or :MODIFY to some sequence fns,
> >Version 3, 31-Aug-88
> >Status: withdrawn
> I marked this as tabled.

-- No, I think we all thought this was a bad idea after all.

> >- FORMAT-ROUNDING
> >Synopsis: specify that ~F rounds up
> >Version 1, 5-Oct-88
> >Status: withdrawn
> I marked this as tabled.

-- This was your issue originally. JonL said: "However, both Moon and I
seemed to prefer not trying to specify something in the standard for the
case this issue is addressing." and there was no dissent. Do you want to
re-raise it?

> >+ FUNCTION-COMPOSITION
> >Synopsis: Add new functions
> >Version 5, 10-Feb-89 
> >Status: Passed (as amended) Jan 89 X3J13
> I know this is picky, but I thought it was decided to fail this one
> completely and amend TEST-NOT-IF-NOT (I believe that was the related
> issue).

-- you may be right. I wish we had minutes. I guess I'll stick by my
summary unless I hear otherwise.

> >+ PEEK-CHAR-READ-CHAR-ECHO
> >Version 3, 8-Oct-88, Released 8 Oct 88
> >Synopsis:  PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
> >Status: Passed, Jan 89 X3J13
> I have this marked as amended. 

-- I have no amendments made at the meeting. Do you?

> >- TRACE-ERROR
> >Synopsis: TRACE should signal errors if it doesn't understand
> >Version 1, 20-Jun-88
> >Comments: is this a cleanup?
> >Status: withdrawn
> I marked this as tabled.

-- I don't have anyone willing to bring it up.

∂14-Mar-89  1732	CL-Cleanup-mailer 	revised: Cleanup Issue Status  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  17:31:47 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 16:17:29 PST
Date: 14 Mar 89 16:16 PST
From: masinter.pa@Xerox.COM
Subject: revised: Cleanup Issue Status
In-reply-to: your message of Sun, 19 Feb 89 23:14:37 PST
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890314-161729-2231@Xerox>

Ooops... I missed your later note about "amendments" being just "notes".

Our differences are now only over whether things were "tabled" or
"withdrawn" and whether FUNCTION-COMPOSITION was amended or whether it was
rejected with TEST-NOT-IF-NOT amended to include what was left of it:


> >- DELETE-FILE-NONEXISTENT 
> >Version 1, 5-Oct-88
> >Comments: should just signal different errors?
> >Status: withdrawn
> I marked this as tabled.
 
-- I know no-one who intends to raise it. Maybe KMP's error signalling
proposal? I'll check.

> >- ELIMINATE-FORCED-CONSING
> >Synopsis: Add :RECYCLE or :MODIFY to some sequence fns,
> >Version 3, 31-Aug-88
> >Status: withdrawn
> I marked this as tabled.

-- No, I think we all thought this was a bad idea after all.

> >- FORMAT-ROUNDING
> >Synopsis: specify that ~F rounds up
> >Version 1, 5-Oct-88
> >Status: withdrawn
> I marked this as tabled.

-- This was your issue originally. JonL said: "However, both Moon and I
seemed to prefer not trying to specify something in the standard for the
case this issue is addressing." and there was no dissent. Do you want to
re-raise it?

> >+ FUNCTION-COMPOSITION
> >Synopsis: Add new functions
> >Version 5, 10-Feb-89 
> >Status: Passed (as amended) Jan 89 X3J13
> I know this is picky, but I thought it was decided to fail this one
> completely and amend TEST-NOT-IF-NOT (I believe that was the related
> issue).

-- you may be right. I wish we had minutes. I guess I'll stick by my
summary unless I hear otherwise.

> >- TRACE-ERROR
> >Synopsis: TRACE should signal errors if it doesn't understand
> >Version 1, 20-Jun-88
> >Comments: is this a cleanup?
> >Status: withdrawn
> I marked this as tabled.

-- I don't have anyone willing to bring it up.

∂14-Mar-89  1732	CL-Cleanup-mailer 	Issue: PRETTY-PRINT-INTERFACE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  17:32:09 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 17:05:00 PST
Date: 14 Mar 89 17:04 PST
From: masinter.pa@Xerox.COM
Subject: Issue: PRETTY-PRINT-INTERFACE (Version 1)
In-reply-to: Guy Steele <gls@Think.COM>'s message of Fri, 24 Feb 89
 17:40:25 EST
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890314-170500-2365@Xerox>

Dan Pierson had a few specific comments.

Kim Barrett says

"... The stuff about ~W providing circularity detection, and ~<...~:>
providing
depth abbreviation and circularity detection is wrong.  This functionality
should always be provided, and not require the use of special format
directives
to get it.  See the recently passed issue PRINT-CIRCLE-STRUCTURE...."

Can we get a new version that addresses those comments?

I think if we email things out by Thursday we might have a chance of
avoiding the "two-weekers". 

Thanks,

Larry

∂14-Mar-89  1732	CL-Compiler-mailer 	Re: Potential issue: MACRO-SPECIAL-FORMS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  17:32:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 16:49:34 PST
Date: 14 Mar 89 16:48 PST
From: masinter.pa@Xerox.COM
Subject: Re: Potential issue: MACRO-SPECIAL-FORMS
In-reply-to: Gregor.pa's message of Thu, 9 Mar 89 19:14 PST
To: Gregor.pa@Xerox.COM, David A. Moon
 <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Jeff Dalton
 <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Kent M Pitman
 <KMP@STONY-BROOK.SCRC.Symbolics.COM>, cl-compiler@sail.stanford.edu,
 cl-cleanup@sail.stanford.edu
Message-ID: <890314-164934-2319@Xerox>

a) if anything is going to happen on this at the next meeting, we need a
proposal writeup. This week.


b) I like the proposal (in Jeff's oiginal "potential issue"). I agree that
we might want something stronger -- like extending the list of special
forms to include the ones that a code walker *really* has to know about,
but I don't know if we can reach closure.

c) I'd rather do nothing than do something wrong.

∂14-Mar-89  1743	CL-Cleanup-mailer 	Issue: FORMAT-PLURALS (not yet submitted)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  17:43:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 89 17:31:41 PST
Date: 14 Mar 89 17:31 PST
From: masinter.pa@Xerox.COM
Subject: Issue: FORMAT-PLURALS (not yet submitted)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Mon, 6 Mar 89 23:50 EST
To: Dave.Touretzky@cs.cmu.edu
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890314-173141-2452@Xerox>

Is there a chance you could produce a revised version, in "standard"
writeup format in the next day or two? There have been significant
comments since your original message. There seems to be willingness
in cleanup committee to pursue this.

I don't know how much patience you have for our cumbersome procedures,
especially given your 'hit ratio'. 

!

  Format for proposals to the cleanup committee (Version 14)
                    October 5, 1988


Replace the text below in >> double inverted angle-brackets <<. Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upper-case all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.

Remember that this is a proposal to a change to the standard
for Common Lisp, not recommendations to the editor, not 
a set of recommendations to Common Lisp implementors.

Forum:	Cleanup
Issue:         >>A short descriptive label, which starts with a name
               which occurs in the index of CLtL, and be a suitable
               symbol in the Common Lisp style, e.g., CDR-TERMINATION.
		When in doubt, let the cleanup committee assign the name.
		The name should match the problem description, not the 
		proposal.<<

References:    >>The pages of CLtL which describe the feature being
               discussed, and other references.<<

Related issues: >> names of other cleanup issues about the same topic.<<

Category:      >>One or more of:
               CLARIFICATION -- proposal to resolve an ambiguity or case
               of under-specified situation in CLtL, where this
               ambiguity interferes with portability of code.
               CHANGE -- proposal for an incompatible change.
               ADDITION -- proposal for a compatible extension<<

Edit history:  >>Author and date of submission (version 1), and author
               and date of subsequent versions.<<

Problem description:

>>Describe the problem being addressed -- why is the current situation
unclear or unsatisfactory? Avoid describing the proposal here or arguing
for its adoption. <<

Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing.  This  can take the form of
text that could be dropped into the new specification document.
Proposals should be for changes to Common Lisp, rather than changes to
CLtL.  If necessary, propose a set of labelled alternatives here, rather
than a single proposal. Each proposal must be a complete design; do not
leave out details.  Avoid arguing for the proposal here, just describe
it.<<

Examples:

>> Examples are samples of Common Lisp code that illustrates the issue.
along with explanatory text. Please explain what the examples should
do, do in current implementations, and any special tricks.<<

Test Cases:
>> Test Cases are simple stand-alone expressions which are valid and
do not signal an error if the proposal is adhered to. (Use ASSERT
if needed.)  Omit if you have none.
<<

Rationale:

>> A one or two sentence summary of the arguments that follow. <<

Current practice:

>>Do some/many/no Common Lisp implementations already work this way?
Survey independent Common Lisp implementations - preferably three or
more. What do they do on the test cases or examples?  What do current
user programs do? Are there textbooks which describe this feature? <<

Cost to Implementors:

>>What is the cost to implementors of adopting the proposal?  How much
implementation effort is required?  Is public-domain code available? For
pervasive changes, can the conversion be automated?<<

Cost to Users:

>>For incompatible changes, what is the cost to users of converting
existing user code?  To what extent can the process be automated? How?<<

Cost of non-adoption:

>>How serious is it if nothing is done? <<

Performance impact:

>> what does the proposal do to better or worsen the size or speed
of user programs and implementations? <<

Benefits:

>>What is better if the proposal is adopted? How serious is the problem
if just left as it is? <<

Esthetics:

>>How does this proposal affect the simplicity of the language, ease of
learning, etc. You can spell it aesthetics if you like. <<

Discussion:

>> Additional arguments, discussions, endorsements, testimonials, etc.
should go here. Testimonials are the least effective; the discussion should
be useful to someone not already with the issue or those discussing it.
Avoid a blow-by-blow account of debates or recounting of history. <<

∂14-Mar-89  1756	CL-Cleanup-mailer 	Re: Issue: COPY-SYMBOL-PRINT-NAME (Version 1) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89  17:55:56 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 89 17:46:04 PST
Date: 14 Mar 89 17:45 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: COPY-SYMBOL-PRINT-NAME (Version 1)
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 8 Mar 89 08:22
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Message-ID: <890314-174604-2496@Xerox>

Kathy:

Can you update this to say STRING= and summarize the subsequent discussion?

Thanks

Larry

∂14-Mar-89  1812	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
Received: from PORSCHE.SCRC.Symbolics.COM ([128.81.41.69]) by SAIL.Stanford.EDU with TCP; 14 Mar 89  18:11:58 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by PORSCHE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6566; Tue 14-Mar-89 20:43:54 EST
Date: Tue, 14 Mar 89 20:43 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890314-141815-1956@Xerox>
Message-ID: <890314204336.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 14 Mar 89 14:17 PST
    From: masinter.pa@Xerox.COM

    Why not just (READTABLE-CASE <readtable>) that accepts/returns :UPCASE (the
    default) or :DOWNCASE.

This would be fine, but I would prefer :PRESERVE rather than :DOWNCASE for the
alternate value. One might legitimately want :DOWNCASE as well (although it
would be near useless for CL, it might be useful for other things) so I wouldn't
want to lock down that name.

All in all, though, I like somebody's (Gray's?) suggestion of a function rather
than a table. The default being #'CHAR-UPCASE, and #'IDENTITY being another
obvious choice.

The reason I like the function rather than the keyword is that you don't have
to initially provide the alternate functionality -- user's can add it. In the
case of the keyword, it has to be given by the system so you're at the mercy
of the implementors as to which options you get. I think this feature is worth
the added complexity.

∂15-Mar-89  0542	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-PRINT-NAME  
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 15 Mar 89  05:41:51 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA29246; Wed, 15 Mar 89 05:39:23 PST
Message-Id: <8903151339.AA29246@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-cleanup@sail.stanford.edu; id AA29246; Wed, 15 Mar 89 05:39:23 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 15 Mar 89 08:29
To: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: COPY-SYMBOL-PRINT-NAME

!
From:	DECWRL::AITG::CHAPMAN  "8-Mar-89 0822 GMT"  8-MAR-1989 08:32:30.91
To:	cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
CC:	
Subj:	Issue: COPY-SYMBOL-PRINT-NAME

Issue:        COPY-SYMBOL-PRINT-NAME
References:   COPY-SYMBOL (p. 169)
Category:     CLARIFICATION
Edit history: 1-MAR-89, Version 1 by Chapman
              15-MAR-89, Version 2 by Chapman
 
Problem Description:
 
The description of COPY-SYMBOL states that it "returns a new uninterned
symbol with the same print name as sym (its first argument)". The words
"the same as" are not defined in CLtL. Do they mean EQ, EQUAL, ...?
 
Proposal (COPY-SYMBOL-PRINT-NAME:EQUAL)
 
The description of COPY-SYMBOL should read as follows:
"COPY-SYMBOL returns an uninterned
symbol whose print name is STRING= to
the print name of the symbol that is the first argument to COPY-SYMBOL."
 
Suggested implementation note:
The string should not be copied unnecessarily. In this case, the uninterned
symbol's print name would be EQ to the print name of the argument symbol.
 
Rationale:
 
This clarification resolves any possibility of ambiguity.
 
Current Practice:
 
Medley did this: the symbol names didn't really have a string header and
some symbol names (the "initial symbols" ) had a different place for
storing the actual characters than symbols created later. Unfortunately,
that means that SYMBOL-NAME has to CONS.
It wasn't so much a problem for Interlisp since most of the "string"
functions in Interlisp will take symbols, but in Common Lisp, it is a
performance hit. Poor design, but there's no reason to require SYMBOL-NAME
to return EQ strings. 
In this case, the strings aren't EQ even though the string characters are
shared. (Think of it as strings displaced to a shared area.)
 
 
Adoption Cost:
 
?
 
Benefits:
 
Less ambiguity in the specification, and potentially more portable code.
 
Conversion Cost:
 
?
 
Aesthetics:
 
None.
 
Discussion:
 

∂15-Mar-89  0549	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 7)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  05:49:48 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 05:43:34 PST
Date: 15 Mar 89 05:42 PST
From: masinter.pa@Xerox.COM
Subject: Issue: EQUAL-STRUCTURE (Version 7)
To: cl-cleanup@Sail.Stanford.Edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890315-054335-3530@Xerox>

This is what I believe was voted in at the last meeting.

I'm not sure why we started discussing it again, but
I didn't see anything in the discussion that looked like
a proposal to revisit this issue.
!
Status:	Passed as amended, Jan 89 X3J13
Issue:        EQUAL-STRUCTURE
References:   EQUAL (p80), EQUALP (p81)
Category:     CLARIFICATION/CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
	      08-Jun-88, Version 2 by Masinter (add Benson's proposal)
	      23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
	      01-Oct-88, Version 4 by Masinter (fix description)
	      01-Oct-88, Version 5 by Pitman   (correct wording, add discussion)
	      11-Jan-89, Version 6 by Pitman   (attempt EQUALP correction)
		15-Mar-89, Version 7 by Masinter (amended as per vote at Jan 89 X3J13)

Problem Description:

  The behavior of EQUAL and EQUALP on structures is a subject of controversy.
  At issue are whether these functions should descend the slots of structures
  or use simply the structure's primitive identity (i.e., EQ) to test for
  equivalence.

Proposal (EQUAL-STRUCTURE:MAYBE-STATUS-QUO):

  Clarify that EQUAL and EQUALP do not descend any structures or data types
  other than the ones explicitly specified in CLtL.

   Type                     EQUAL Behavior        EQUALP Behavior
 
   Number                     uses EQL               uses =
   Character                  uses EQL               uses CHAR-EQUAL
   Cons                       descends               descends
   Bit-Vector                 descends               descends
   String                     descends               descends
   Pathname                   magic per CLtL         same as EQUAL
   Structure                  uses EQ                uses EQ
   other Array                uses EQ                descends
   Hash-Table                 uses EQ                (see below)
   Instance (Standard-Object) uses EQ                uses EQ
   Other                      uses EQ                uses EQ

  Note that the order of this table is in some cases important, with upper
  entries taking priority over lower ones.

  EQUALP descends hash tables by first comparing the count of entries
  and the :TEST function; if those are the same, it compares the
  keys of the tables using the :TEST function and then the values
  of the matching keys using EQUALP recursively.


Rationale:

  There seem to be as many different equality primitives as there
  are applications for them. None of the possible ways of changing
  EQUAL or EQUALP are flawless. Given the inability to "fix" them,
  it is better to leave them alone.

Current Practice:

  We are unaware of any extensions to CLtL's set of operations,
  although frequently users request them.

Cost to Implementors:

  Since this seems to be compatible with the status quo, none.

Cost to Users:

  Same

Cost of Non-Adoption:

  Ongoing controversy about whether EQUAL and EQUALP "do the right thing".

Benefits:

  A feeling that EQUAL and EQUALP exist and/or do what they do because serious
  consideration was given and we consciously decided on a particular resolution
  to the numerous questions that have come up about them.

Aesthetics:

  There seems to be wide debate about what the proper aesthetics for
  how equality should work in Common Lisp. While the status quo is not
  aesthetically more pleasing than the various alternatives, aesthetic
  considerations vary widely. Different people model structures
  differently. Sometimes the same person models structures differently in
  different situations. The question of which should be descended and which
  should not is a very personal one, and the aesthetic attractiveness of any
  of these options will vary from person to person or application to
  application.

Discussion:

  An earlier version of this issue with various alternatives was distributed
  at the June 1988 X3J13 meeting. Since
  this is a frequently raised issue, we thought we should submit it
  as a clarification although there is no change to CLtL.

  Options for which we considered proposals were:
    - removing EQUAL and EQUALP from the standard.
    - changing EQUALP to descend structures.
    - changing EQUALP to be case sensitive.
    - adding a :TEST keyword to EQUAL.
    - making EQUAL a generic function
  All of these had some serious problems.

  The cleanup committee supports option STATUS-QUO.

  It would be useful if descriptions of EQUAL and EQUALP contained some sort
  of additional commentary alluding to the complex issues discussed here.
  The following is offered to the Editorial staff as a starting point:

    Object equality is not a concept for which there is a uniquely
    determined correct algorithm. The appropriateness of an equality
    predicate can be judged only in the context of the needs of some
    particular program. Although these functions take any type of
    argument and their names sound very generic, EQUAL and EQUALP are
    not appropriate for every application. Any decision to use or not
    use them should be determined by what they are documented to do
    rather than any abstract characterization of their function. If
    neither EQUAL nor EQUALP is found to be appropriate in a particular
    situation, programmers are encouraged to create another operator
    that is appropriate rather than blame EQUAL or EQUALP for ``doing
    the wrong thing.''

!
Additional Comments to Version 6:

Version 6 attempts to fix some of the problems noted in Version 5.
There are still some open questions. Only the "Proposal"
part has been changed since Version 5; some of the costs,
benefits & other discussion is now incorrect.

Kent says:

Please read this very carefully before voting in favor of it.
There were a lot of Yes votes for the last version, which I think
had some serious bugs in it. This would be a very bad issue for
us to screw up.

Things that might need special attention:

 - Moon contends that standard practice in Symbolics Lisp is
   for instances to be compared using EQ under EQUALP, not by
   descending. There may be performance issues involved here.
   Some agreement needs to be reached.

 - Neither the previous version of the proposal nor CLtL was
   clear on what happens to pathnames under EQUALP. This showed
   up when I converted the presentation below. That issue should
   be addressed as well.

Hopefully if this version of the proposal isn't something you want to
vote yes for, at least it's in a suitable form for easy line-item
changes interactively in the meeting.


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

∂15-Mar-89  0641	CL-Cleanup-mailer 	Re: Issue: OPTIMIZE-SAFETY (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  06:41:30 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 06:37:00 PST
Date: 15 Mar 89 06:36 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: OPTIMIZE-SAFETY (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Mon, 6 Mar 89 17:42 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890315-063700-3610@Xerox>

My reading is that this is currently being pursued as an editorial issue
and that it will not appear on the "cleanup" list.

Y'all let me know if you disagree.


∂15-Mar-89  0720	CL-Cleanup-mailer 	Re: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  07:19:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 07:03:16 PST
Date: 15 Mar 89 07:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER
In-reply-to: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>'s message of Sun, 12
 Mar 89 16:01:13 PST
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: kmp@symbolics.com, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890315-070316-3648@Xerox>

I think NaNs should cause ARITHMETIC-ERROR, since "what's one man's NaN is
another man's number."

To put it another way, TYPE-ERROR is generally a sign of a program error
and the cases in which it is signalled should usually not vary from
implementation to implementation; however, which cases signal
ARITHMETIC-ERROR can vary depending on the implementation's floating number
range.

Should we define specific conditions to correspond to the IEEE conditions
as subtypes of ARITHMETIC-ERROR?

I think that it is important to bring this issue to the X3J13 meeting, even
if it isn't quite ready for vote. 

If there's a new draft soon, we can have it available for discussion there,
and maybe get an "endorse in principle".

∂15-Mar-89  0720	CL-Cleanup-mailer   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  07:20:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 07:15:06 PST
Date: 15 Mar 89 07:14 PST
From: masinter.pa@Xerox.COM
To: alarson@src.honeywell.com (Aaron Larson)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890315-071506-3662@Xerox>

Unfortunately, there is a "nest" of cleanup items on pathnames
that have been postponed. Here's PATHNAME-SUBDIRECTORY-LIST.


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

Date: Wed, 28 Dec 88 14:32 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM

Ok, I've been through and I think successfully merged all the pending
discussion, most of which seemed to center around issues of :UP.

-----
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)
		28-Dec-88, Version 3 by Pitman (merge discussion)
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, keyword symbols may occur
  to deal with special file notations. The following symbols have standard
  meanings; they may not be meaningful for all operating systems, and are
  intended for use only on those operating systems where they have meaning:

   :WILD           - Wildcard match of one level of directory structure.
   :WILD-INFERIORS - Wildcard match of any number of directory levels.
   :UP             - Go upward in directory structure (semantic).
   :BACK 	   - Go upward in directory structure (syntactic).

  The difference between up and back is that if there is a directory
    (:ABSOLUTE "X" "Y" "Z")
  linked to 
    (:ABSOLUTE "A" "B" "C")
  and there also exist directories
    (:ABSOLUTE "A" "B" "Q")
    (:ABSOLUTE "X" "Y" "Q")
  then
    (:ABSOLUTE "X" "Y" "Z" :OUT "Q")
  designates
    (:ABSOLUTE "A" "B" "Q")
  while
    (:ABSOLUTE "X" "Y" "Z" :UP "Q")
  designates
    (:ABSOLUTE "X" "Y" "Q")

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, only the 2nd return value.

  (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
  differences are:
   - 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.
   - Genera represents Unix ".." as :UP, but deals with :UP 
     syntactically, not semantically.

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.



     ----- Next Message -----

Date: Thu, 29 Dec 88 13:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881228143206.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

I approve PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION but note the
following typos and proposed simplifications.  Also, don't you need
functions like Symbolics' DIRECTORY-PATHNAME-AS-FILE and
PATHNAME-AS-DIRECTORY?  The conversion between the name of a directory
and the directory component of a file inferior to that directory is
system-dependent, for example TOPS-20 appends a type field and Unix does
not.  Also in some systems the root directory has a name and in others
it doesn't.  Of course these functions signal an error in
non-hierarchical file systems.  Should there be a separate proposal for
these?

Typos (and some discussion):

    Problem Description:

      - In some implementations "FOO.BAR" might denote the "BAR" subdirectory
        of "FOO" while in other implementations because "." is not the
        separator.

Some words must be missing after "while".

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

       :UP         - Go upward in directory structure (semantic).
       :BACK       - Go upward in directory structure (syntactic).
      The difference between up and back is that if there is a directory
        (:ABSOLUTE "X" "Y" "Z")
      linked to 
        (:ABSOLUTE "A" "B" "C")
      and there also exist directories
        (:ABSOLUTE "A" "B" "Q")
        (:ABSOLUTE "X" "Y" "Q")
      then
        (:ABSOLUTE "X" "Y" "Z" :OUT "Q")
      designates
        (:ABSOLUTE "A" "B" "Q")
      while
        (:ABSOLUTE "X" "Y" "Z" :UP "Q")
      designates
        (:ABSOLUTE "X" "Y" "Q")

Is :OUT a typo for :BACK?  Also I don't understand what your proposed
semantic/syntactic distinction is.  I almost thought I did until I read
the above text carefully and saw that the syntactic one chases links
to the truename and the semantic one does not, which seems backwards.

I also don't think :UP and :BACK are meaningful anywhere except immediately
after :RELATIVE, although I have to concede that Unix disagrees with me
and therefore Symbolics Genera's Unix pathname support also disagrees
with me.  But if they were only allowed immediately after :RELATIVE I
don't think you would need two of them.  I also don't think that
MERGE-PATHNAMES should ever look at what files/directories actually
exist in the file system, which makes me opposed to the existence
of the one that you have called syntactic.  Is this really something
we need, or will TRUENAME do the job?

I think we should only have :UP and not :BACK.

    Current Practice:

       - Genera represents Unix ".." as :UP, but deals with :UP 
         syntactically, not semantically.

After you straighten out the definition of syntactic and semantic, check
whether this statement is true.  (I'm always irked by proposals where
the current practice section is wrong, because someone wrote an original
proposal where the current practice section was right, then the group
changed the proposal all around but didn't update the current practice
section).

    Discussion:

      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.

It seems to me that this fully addresses relative pathnames already.  The
discussion of :UP and :BACK (if freed of typos) seems specific enough that
even though this proposal doesn't explicitly propose what MERGE-PATHNAMES
does with relative pathnames, I think there is only one thing that it could
do that would be consistent.  A pathname with a :RELATIVE directory is
not very different from a pathname with a NIL directory; in either case
you have to merge with a default to find the real directory to use; thus
I don't think there are any other new issues with relative pathnames.



     ----- Next Message -----

Date: Thu, 29 Dec 88 14:54 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19881229182903.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 29 Dec 88 13:29 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    ... don't you need functions like Symbolics' DIRECTORY-PATHNAME-AS-FILE and
    PATHNAME-AS-DIRECTORY?  The conversion between the name of a directory
    and the directory component of a file inferior to that directory is
    system-dependent, for example TOPS-20 appends a type field and Unix does
    not.  Also in some systems the root directory has a name and in others
    it doesn't.  Of course these functions signal an error in
    non-hierarchical file systems.  Should there be a separate proposal for
    these? ...

I guess it's enough related to this topic that it could piggy back.
Certainly these functions made no sense prior to this proposal and
now they are suddenly important, so I'll see about putting them in on
next pass.

    ... Is :OUT a typo for :BACK? ...

Yeah. Sloppy editing. Sorry.

    Also I don't understand what your proposed semantic/syntactic
    distinction ...

Semantic means you have to probe the file system. Syntactic means
looking at the file names themselves is enough. Maybe I screwed up
the presentation. I'll double-check.

Genera is syntactic in that it doesn't probe when processing :UP.
That means that MERGE-PATHNAMES on
 (:ABSOLUTE "X" "Y" "Z")
and
 (:RELATIVE :UP "Q")
returns
 (:ABSOLUTE "X" "Y" "Q")
rather than
 (:ABSOLUTE "X" "Y" "Z" :UP "Q")
If you were going to contract out the :UP, you'd need to probe the
file system to make sure 
 (:ABSOLUTE "A" "B" "Q")
wasn't more correct than
 (:ABSOLUTE "X" "Y" "Q")
so I think Genera has a bug.

I think this because if I do:
 cd /m/n/o
 cd ../q
on Unix I get one place, but in Genera if I visit a file in the
editor named
 /m/n/o/x.lisp
and then I type c-X c-F and when prompted for a filename I type
 ../q/x.lisp
I end up with
 /m/n/o/q/x.lisp
rather than the x.lisp in the directory that Unix itself would have
plopped me in if I'd used the cd commands above.

If you disagree, please reply to me privately so we can avoid
further confusion, quickly iron it out offline, and then report a
joint answer (and rationale) to everyone else once we've achieved
consensus.

    I also don't think :UP and :BACK are meaningful anywhere except immediately
    after :RELATIVE, although I have to concede that Unix disagrees with me
    and therefore Symbolics Genera's Unix pathname support also disagrees
    with me.

When I previously raised this topic, there were a pile of messages on
exactly this subject. My putting these into the proposal was an attempt
to address those topics. Even if I took these out, the current proposal
offers the flexibility that implementations could offer them without being
in violation of the spec. On the other hand, if people -are- going to offer
them, we might as well agree on common names if it's possible to do so.

    But if they were only allowed immediately after :RELATIVE I
    don't think you would need two of them.

I claim my example above refutes this.

    I also don't think that
    MERGE-PATHNAMES should ever look at what files/directories actually
    exist in the file system,

If you permit :UP in absolute pathnames, you don't have to look in the
file system. You just get some funny names. Most file systems that 
have this feature permit such funny names, though. eg, /foo/../bar/x
is valid in Unix, I understand. If memory serves me, Multics permits
>foo>bar>baz<x>y in Multics, no? Our (Symbolics) pathname system doesn't
permit embedded "<", but the error message suggests that this is only
because there's no obvious interpretation. We could define it to mean
:BACK rather than :UP, so that syntactic merges could be done and
unique pathnames would always be generated.

    which makes me opposed to the existence
    of the one that you have called syntactic.

In any case, I'm sympathetic to your desire to not look in the file
system. I just think that if a file system designer has made a
decision that forces you to look in the file system to get the right
answer, I don't know what we the CL designers can do to alter that.
The same issue comes up for logical devices and as Sandra has reminded
us, we've not done a particularly good job of papering over that real
externally-induced issue either.

    Is this really something we need, or will TRUENAME do the job?

TRUENAME and OPEN would, presumably, not return pathnames with :UP
references (except maybe in pathological situations which they tell
me you can make in Unix if you try hard enough where the only way to
get to a directory is to go down first and then dig upward.)

    I think we should only have :UP and not :BACK.

Nothing forces a file system to have both. The question is whether
there are some file systems that have one set of semantics and others
which have the other. If so, then two tokens are needed. In the discussion
leading up to this, people asserted (and I took them at their word) that
there were such competing semantics.

	Current Practice:

	   - Genera represents Unix ".." as :UP, but deals with :UP 
	     syntactically, not semantically.

    After you straighten out the definition of syntactic and semantic, check
    whether this statement is true.  (I'm always irked by proposals where
    the current practice section is wrong, because someone wrote an original
    proposal where the current practice section was right, then the group
    changed the proposal all around but didn't update the current practice
    section).

I'll double-check when I've made the next version.

	Discussion:

	  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.

    It seems to me that this fully addresses relative pathnames already.  The
    discussion of :UP and :BACK (if freed of typos) seems specific enough that
    even though this proposal doesn't explicitly propose what MERGE-PATHNAMES
    does with relative pathnames, I think there is only one thing that it could
    do that would be consistent.  A pathname with a :RELATIVE directory is
    not very different from a pathname with a NIL directory; in either case
    you have to merge with a default to find the real directory to use; thus
    I don't think there are any other new issues with relative pathnames.

Well, there was the whole treatment of :UP. I hadn't really meant for this
proposal to specify that treatment so much as to identify a common representation
so we'd be a little less divergent in the areas we hadn't really specified.
Does anyone think I should add a disclaimer in the proposal body similar to the
one for :OLDEST, :INSTALLED, etc in pathname versions in CLtL that says that
although these are semi-standard names, there is no attached semantics?



     ----- Next Message -----

Date: Thu, 29 Dec 88 16:05 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881229145413.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Thu, 29 Dec 88 14:54 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Thu, 29 Dec 88 13:29 EST
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Also I don't understand what your proposed semantic/syntactic
	distinction ...

    Semantic means you have to probe the file system. Syntactic means
    looking at the file names themselves is enough. Maybe I screwed up
    the presentation. I'll double-check.

OK, I understand, and you did screw up the presentation.

	But if they were only allowed immediately after :RELATIVE I
	don't think you would need two of them.

    I claim my example above refutes this.

Agreed.

	I also don't think that
	MERGE-PATHNAMES should ever look at what files/directories actually
	exist in the file system,

    If you permit :UP in absolute pathnames, you don't have to look in the
    file system. You just get some funny names. Most file systems that 
    have this feature permit such funny names, though. eg, /foo/../bar/x
    is valid in Unix, I understand. If memory serves me, Multics permits
    >foo>bar>baz<x>y in Multics, no? 

No.  Although that's from memory: there are few Multices left, I don't
have an account of any of them, and my manuals are in the attic at home.

I think you got syntactic and semantic mixed up again.  I think you're
saying that MERGE-PATHNAMES of a relative directory against an absolute
directory will remove :UP, since that's purely syntactic, but will leave
:BACK in the middle of the merged directory, since resolving :BACK
"semantically" would require accessing the file system, which
MERGE-PATHNAMES doesn't do.  Okay.

These names are extremely confusing, obviously.  Can anyone think
of better ones than :UP and :BACK?

				     Our (Symbolics) pathname system doesn't
    permit embedded "<", but the error message suggests that this is only
    because there's no obvious interpretation. 

The error message I get doesn't suggest anything, it's just "Embedded <?".

					       We could define it to mean
    :BACK rather than :UP, so that syntactic merges could be done and
    unique pathnames would always be generated.

I don't understand this sentence.  Say it again after we all agree on
which one is :UP and which one is :BACK.

	which makes me opposed to the existence
	of the one that you have called syntactic.

    In any case, I'm sympathetic to your desire to not look in the file
    system. I just think that if a file system designer has made a
    decision that forces you to look in the file system to get the right
    answer, I don't know what we the CL designers can do to alter that.
    The same issue comes up for logical devices and as Sandra has reminded
    us, we've not done a particularly good job of papering over that real
    externally-induced issue either.

	Is this really something we need, or will TRUENAME do the job?

    TRUENAME and OPEN would, presumably, not return pathnames with :UP
    references (except maybe in pathological situations which they tell
    me you can make in Unix if you try hard enough where the only way to
    get to a directory is to go down first and then dig upward.)

	I think we should only have :UP and not :BACK.

    Nothing forces a file system to have both. The question is whether
    there are some file systems that have one set of semantics and others
    which have the other. If so, then two tokens are needed. In the discussion
    leading up to this, people asserted (and I took them at their word) that
    there were such competing semantics.

I don't know enough about the weird file systems out there to dispute this.

    Well, there was the whole treatment of :UP. I hadn't really meant for this
    proposal to specify that treatment so much as to identify a common representation
    so we'd be a little less divergent in the areas we hadn't really specified.
    Does anyone think I should add a disclaimer in the proposal body similar to the
    one for :OLDEST, :INSTALLED, etc in pathname versions in CLtL that says that
    although these are semi-standard names, there is no attached semantics?

Yes, I think :UP and :OLDEST have the same status, but no I don't agree
that that status is that they have no semantics.  I agree with what CLtL
page 412 actually says, which is that either an implementation doesn't
support these keywords or if it does support them they have prescribed
meanings.



     ----- Next Message -----

Date: Thu, 29 Dec 88 14:48:23 PST
From: Jim McDonald <jlm@lucid.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Thu, 29 Dec 88 13:29 EST
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)

>>    Is this really something we need, or will TRUENAME do the job?

If you're trying to create a filename to be used for output, it might
not exist yet (hence TRUENAME would signal an error), but there might
be various funny links in its directory path you would like to
traverse.  Presumably you could use PROBE-FILE on some part of the
name (perhaps recursively down through the super-directories), then
merge in the remaining part, but that seems enough error-prone to be
worth hiding. 

BTW, I think the labelling of semantic/syntactix examples was reversed
in the proposal, independantly of :UP vs. :BACK.

  jlm



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

∂15-Mar-89  0741	CL-Cleanup-mailer 	Re: Issue: PLUS-ABNORMAL (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  07:41:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 07:33:42 PST
Date: 15 Mar 89 07:33 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PLUS-ABNORMAL (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Wed, 8 Mar 89 14:14 EST
To: CL-Cleanup@SAIL.Stanford.EDU, skona%csilvax@hub.ucsb.edu
Message-ID: <890315-073342-3688@Xerox>

I agree with KMP's "... if we want to do anything with +, ++, etc.  it may
be to say that they are reserved for the implementation to assign as it
sees fit, and to give only vague guidelines beyond that -- referring
people to the implementation's manual for specifics."

I'm uncomfortable "pinning" down +, ++ and +++, since they cannot be used
reasonably by any portable code. 

The notion of "evaluation" and "aborting" is fairly complex when there are
separate read-eval-print loops, debuggers, etc.  For example, it seemed
reasonable to update *, ** once the values had been computed but before
they had been printed, in the case that the printing was aborted. The
"input" variables (-, +, ++, ...) are updated immediately after READ,
however.

In fact, the situation was more complicated because of the addition of
interleaved history lists; the history list itself maintains a corrolated
input-output history in "prompt" order, while there's a global ("last
value") IT that is shared by all Execs. ("Prompt" order is different than
"input" order, since the event number in the history list is allocated at
the time the prompt is generated, rather than when the input is complete.)

At one time I wanted to push for removing +, ++, +++, - from the standard
completely for what might be called 'aesthetic' grounds. I think they are
the only symbols in CL with unrelated value & function interpretations, for
example.


∂15-Mar-89  0817	CL-Cleanup-mailer 	Cleanup Issue Status 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  08:15:31 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 11:08:57 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 11:10:06 EST
Received: by verdi.think.com; Wed, 15 Mar 89 11:06:53 EST
Date: Wed, 15 Mar 89 11:06:53 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151606.AA01268@verdi.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 14 Mar 89 15:35 PST <890314-153644-2132@Xerox>
Subject: Cleanup Issue Status


   > >+ FUNCTION-COMPOSITION
   > >Synopsis: Add new functions
   > >Version 5, 10-Feb-89 
   > >Status: Passed (as amended) Jan 89 X3J13
   > I know this is picky, but I thought it was decided to fail this one
   > completely and amend TEST-NOT-IF-NOT (I believe that was the related
   > issue).

   -- you may be right. I wish we had minutes. I guess I'll stick by my
   summary unless I hear otherwise.

My notes show that the COMPLEMENT function was accepted and
all other parts of the proposal failed.
--Guy

∂15-Mar-89  0845	CL-Cleanup-mailer 	Re: Cleanup Issue Status  
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 15 Mar 89  08:45:15 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA23362; Wed, 15 Mar 89 11:42:12 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA05621; Wed, 15 Mar 89 11:40:30 EST
Message-Id: <8903151640.AA05621@mist.>
To: Guy Steele <gls@Think.COM>
Cc: masinter.pa@xerox.com,
        "chapman%aitg.DEC@decwrl.dec.com"@multimax.encore.com,
        cl-cleanup@sail.stanford.edu
Subject: Re: Cleanup Issue Status 
In-Reply-To: Your message of Wed, 15 Mar 89 11:06:53 -0500.
             <8903151606.AA01268@verdi.think.com> 
Date: Wed, 15 Mar 89 11:40:28 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    Date: Wed, 15 Mar 89 11:06:53 EST
    From: Guy Steele <gls@Think.COM>
    To: masinter.pa@xerox.com
    Cc: chapman%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
    Subject: Cleanup Issue Status
    
    
       > >+ FUNCTION-COMPOSITION
       > >Synopsis: Add new functions
       > >Version 5, 10-Feb-89 
       > >Status: Passed (as amended) Jan 89 X3J13
       > I know this is picky, but I thought it was decided to fail this one
       > completely and amend TEST-NOT-IF-NOT (I believe that was the related
       > issue).
    
       -- you may be right. I wish we had minutes. I guess I'll stick by my
       summary unless I hear otherwise.
    
    My notes show that the COMPLEMENT function was accepted and
    all other parts of the proposal failed.
    --Guy
    
My memory agrees with Guy's notes.  We did spend several sessions on
this one and the waters got rather muddy at times.

∂15-Mar-89  0921	CL-Cleanup-mailer 	Re: Cleanup Issue Status  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89  09:21:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557486; Wed 15-Mar-89 12:18:32 EST
Date: Wed, 15 Mar 89 12:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Cleanup Issue Status 
To: Dan L. Pierson <pierson@mist.encore.com>, Guy Steele <gls@Think.COM>,
    masinter.pa@xerox.com, chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8903151640.AA05621@mist.>
Message-ID: <19890315171827.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

My notes agree with Dan and Guy.  It's complicated because the
COMPLEMENT portion of FUNCTION-COMPOSITION was moved into
TEST-NOT-IF-NOT by an amendment, which was where it was
actually passed.  Back in FUNCTION-COMPOSITION, NEW-FUNCTIONS
was voted down unanimously and later COMPLEMENT-AND-CONSTANTLY
was voted down by something to something.

    Date: Wed, 15 Mar 89 11:40:28 EST
    From: Dan L. Pierson <pierson@mist.encore.com>

	Date: Wed, 15 Mar 89 11:06:53 EST
	From: Guy Steele <gls@Think.COM>
    
	   > >+ FUNCTION-COMPOSITION
	   > >Synopsis: Add new functions
	   > >Version 5, 10-Feb-89 
	   > >Status: Passed (as amended) Jan 89 X3J13
	   > I know this is picky, but I thought it was decided to fail this one
	   > completely and amend TEST-NOT-IF-NOT (I believe that was the related
	   > issue).
    
	   -- you may be right. I wish we had minutes. I guess I'll stick by my
	   summary unless I hear otherwise.
    
	My notes show that the COMPLEMENT function was accepted and
	all other parts of the proposal failed.
	--Guy
    
    My memory agrees with Guy's notes.  We did spend several sessions on
    this one and the waters got rather muddy at times.

∂15-Mar-89  0930	CL-Cleanup-mailer 	Issue: PRETTY-PRINT-INTERFACE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89  09:30:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557494; Wed 15-Mar-89 12:28:19 EST
Date: Wed, 15 Mar 89 12:28 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE (Version 1)
To: masinter.pa@Xerox.COM, Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-170500-2365@Xerox>
Message-ID: <19890315172817.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

If you're thinking about making a new version, I intend to comment on
this, but it's so huge that it's taking a long time.  A very brief
summary of some of my likely comments is: I'm in favor of the general
idea of defining a standard pretty printer, but there are some problems
in the details of this proposal; part of this seems to resemble CLOS,
but is gratuitously(?) different; there doesn't seem to be any
concession to variable-width fonts, although I didn't find an explicit
statement of what units indentation and width are measured in; I wish to
God that Dick Waters hated FORMAT, because the grotesque FORMAT-based
syntax is going to make this a lot harder to pass.

∂15-Mar-89  0934	CL-Cleanup-mailer 	RE: Cleanup Issue Status  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89  09:33:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557496; Wed 15-Mar-89 12:30:17 EST
Date: Wed, 15 Mar 89 12:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: RE: Cleanup Issue Status
To: masinter.pa@Xerox.COM, chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-153644-2132@Xerox>
Message-ID: <19890315173018.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 14 Mar 89 15:35 PST
    From: masinter.pa@Xerox.COM

    > >+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
    > >Version 3, 13-Jan-89
    > >Status: passed, Jan 89 X3J13
    > I believe this one was amended.

    -- I have no amendments marked. Do you know what the amendment was?

    > >+ PEEK-CHAR-READ-CHAR-ECHO
    > >Version 3, 8-Oct-88, Released 8 Oct 88
    > >Synopsis:  PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
    > >Status: Passed, Jan 89 X3J13
    > I have this marked as amended. 

    -- I have no amendments made at the meeting. Do you?

My notes from January don't show any amendments to either of these.

∂15-Mar-89  0936	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  09:36:35 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via INTERNET with SMTP id 124413; 15 Mar 89 12:34:29 EST
Date: Wed, 15 Mar 89 12:34 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: cl-cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu
In-Reply-To: <890315-051405-3472@Xerox>
Message-ID: <19890315173420.1.BARMAR@OCCAM.THINK.COM>

    Date: 15 Mar 89 05:13 PST
    From: masinter.pa@xerox.com

    Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):

Hooray!  We finally got our collective acts together on this one!

                                                barmar

∂15-Mar-89  0947	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-PRINT-NAME  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89  09:47:16 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557507; Wed 15-Mar-89 12:44:21 EST
Date: Wed, 15 Mar 89 12:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-PRINT-NAME
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8903151339.AA29246@decwrl.dec.com>
Message-ID: <19890315174412.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

I like COPY-SYMBOL-PRINT-NAME:EQUAL.

∂15-Mar-89  0959	CL-Cleanup-mailer 	Issue: TIME-ZONE-NON-INTEGER   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  09:59:06 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 12:55:14 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 12:56:34 EST
Received: by verdi.think.com; Wed, 15 Mar 89 12:53:22 EST
Date: Wed, 15 Mar 89 12:53:22 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151753.AA02688@verdi.think.com>
To: chapman%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 14 Mar 89 16:55 EST <19890314215504.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER


I strongly support TIME-ZONE-NON-INTEGER:ALLOW.

∂15-Mar-89  0948	X3J13-mailer 	Issue: GENSYM-NAME-STICKINESS (Version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  09:48:17 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 12:44:45 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 12:46:05 EST
Received: by verdi.think.com; Wed, 15 Mar 89 12:42:51 EST
Date: Wed, 15 Mar 89 12:42:51 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151742.AA02653@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 14 Mar 89 14:56 PST <890314-145716-2049@Xerox>
Subject: Issue: GENSYM-NAME-STICKINESS (Version 1)

Does KMP intend that GENSYM not be sticky for an integer argument
as well?  That is, there is no way to reset the counter?
--Guy

∂15-Mar-89  1045	CL-Cleanup-mailer 	Issue: GENSYM-NAME-STICKINESS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89  10:45:16 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557570; Wed 15-Mar-89 13:42:53 EST
Date: Wed, 15 Mar 89 13:42 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS (Version 1)
To: gls@Think.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8903151742.AA02653@verdi.think.com>
Message-ID: <890315134243.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

[X3J13 removed.]

    Date: Wed, 15 Mar 89 12:42:51 EST
    From: Guy Steele <gls@Think.COM>

    Does KMP intend that GENSYM not be sticky for an integer argument
    as well?  That is, there is no way to reset the counter?

The great thing about the idea of a writeup is that it can stand alone,
regardless of what the author thinks.  The writeup is not ambiguous --
it takes away the ability to reset the counter.

Happily, that means I can disagree with the writeup without disagreeing
with myself.  It's obvious now that I think about it, that taking away
the ability to reset the counter makes it nearly useless to be able to
affect the counter, since you cannot simultaneously pass a name and a
counter (probably a mistake itself), and since you'd always get the
same number unless you did (GENSYM (INCF *MY-COUNTER*)) or some such.

I myself have never used the gensym-counter-resetting feature. I
have to say I don't think a lot of people use it either. The only use
I can really think of is for resetting a system so that you can get
the same set of GENSYM names again in a second run to a bunch of code.
If we were going to permit that, I would rather just document the 
variable that holds the counter and not have it be done as a side-effect
of calling the function.

My basic feeling is that the "easy use" of GENSYM is best satisfied
if only a name is permissible, and use of any other kind argument is
starting to get into hair that it best done by people rolling their own
using MAKE-SYMBOL, FORMAT, and INCF.

My inclination at this point would be to document a variable:
 *GENSYM-COUNTER*
which held the GENSYM counter, and to say that GENSYM could only take
a name argument (leaving other situations "undefined" so that 
implementations could provide a graceful transition), and to say the
name argument is not sticky.

However, the only part of this I really care about is that the name
not be sticky.  If you make any reasonable counterproposal that gives
me that one feature, odds are that I'll support it.

∂15-Mar-89  1057	CL-Cleanup-mailer 	Issue LOOP-AND-DISCREPANCY, version 1    
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  10:56:37 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 13:52:49 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 13:54:08 EST
Received: by verdi.think.com; Wed, 15 Mar 89 13:50:51 EST
Date: Wed, 15 Mar 89 13:50:51 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151850.AA02865@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: Issue LOOP-AND-DISCREPANCY, version 1


Issue:		LOOP-AND-DISCREPANCY

References:	Loop Facility document X3J13/89-004

Related issues: 

Category:	CHANGE CLARIFICATION

Edit history:	Version 1, 15-Mar-88 by Steele

Problem description:

The treatment of the AND conjunction in FOR/AS and WITH clauses is not
consistent.  Examples of the use of WITH are also not consistent in this
respect.

Page 2-5 implies by example that when AND is used to join two
FOR/AS clauses, the word FOR or AS must occur after the word AND.

Page 2-31 has formal syntax specifying that when AND is used to join two
WITH clauses, the word WITH must *not* occur after the word AND.  Examples
on that page are consistent with this specification.

Page 2-41 has an example in which WITH is repeated after AND.


Proposal (LOOP-AND-DISCREPANCY:NO-REITERATION):

Let stand the formal syntax for WITH.

Change the description of FOR/AS clauses to specify that when
two or more such clauses are joined with AND, clauses after the
first do not have FOR or AS before them.

The complete formal syntax for FOR/AS may be described as follows:

for-as ::= {FOR | AS} for-as-subclause {AND for-as-subclause}*

for-as-subclause ::= for-as-arithmetic | for-as-in-list
		   | for-as-on-list | for-as-equals-then
		   | for-as-across | for-as-hash | for-as-package

for-as-arithmetic ::= var [type-spec] ...

and so on.

Examples:

> (loop for x from 1 to 10		;Corrected from X3J13/89-004, page 2-5
        and y = nil then x
        collect (list x y))
((1 NIL) (2 1) (3 2) (4 3) (5 4) (6 5) (7 6) (8 7) (9 8) (10 9))

> (loop with (a b) float = '(1.0 2.0)	;Corrected from X3J13/89-004, page 2-41
        and (c d) integer = '(3 4)
        and (e f)
        return (list a b c d e f))
(1.0 2.0 3 4 nil nil)


Rationale:

The treatment of AND should be internally consistent.  There is no reason
to repeat the FOR/AS keyword.  Not repeating the keyword emphasizes that
the subclauses are functionally linked under the heading of WITH or FOR.
(Compare to the third use of AND in LOOP, to link clauses controlled
by WHEN/IF/UNLESS.  One does not repeat the WHEN; rather, the clauses
grouped by AND are controlled by a single WHEN.)


Current practice:

Symbolics LOOP allows FOR to be included or omitted after AND,
with identical meanings.  WITH may not be repeated after AND.


Cost to Implementors: Small?

Cost to Users: Possible incompatibility with existing implementors' extensions.

Cost of non-adoption:  Utter confusion.

Performance impact:  None.

Benefits:  Consistent treatment of AND within LOOP.

Esthetics:

Absolutely none.  We're talking about LOOP here.

Discussion:

Steele supports this proposal.  It is a reversal of his previous
suggestion on the topic, thanks to feedback from Moon.

∂15-Mar-89  1111	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-COPY-PLIST  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89  11:11:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557610; Wed 15-Mar-89 14:09:10 EST
Date: Wed, 15 Mar 89 14:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-COPY-PLIST
To: Masinter.pa@xerox.com
cc: Barry Margolin <barmar@Think.COM>, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890110181742.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890315190909.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

This one was marked with a * on your status report, but I don't
think it was ever brought up to the committee, and I don't think
it needs amendment.  The discussion was just over whether
it's really a cleanup issue or an editorial issue.  Let's just
vote on it as-is.

∂15-Mar-89  1127	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89  11:27:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557635; Wed 15-Mar-89 14:24:27 EST
Date: Wed, 15 Mar 89 14:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 3)
To: Masinter.pa@xerox.com
cc: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>, CL-Cleanup@Sail.Stanford.EDU,
    DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM,
    Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19890113185020.8.CASSELS@GROUSE.SCRC.Symbolics.COM>
Message-ID: <19890315192425.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

Your issue status for this one says
  * REAL-NUMBER-TYPE
  Synopsis: add REAL = (OR RATIONAL FLOAT) & range
  Version 2, 08-Jan-89
  Comment: lengthy dissent; discussion? coercion for comparitor?
  Status: need new version
but I think this version is ready to vote up-or-down.  Note that
there are two proposals; the REALP predicate function has been
separated out from the REAL data type.

Date: Fri, 13 Jan 89 13:50 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>

Issue:        REAL-NUMBER-TYPE
Forum:	      CLEANUP
References:   Table 4-1.
Category:     ADDITION
Edit history: 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,
			 and John Aspinall
	      08-JAN-89, Version 2 by Bob Cassels -- incorporate
			 Masinter's suggestion and make REAL a CLOS class
	      13-JAN-89, Version 3 by Cassels and Aspinall -- incorporate Marc LeBrun's
			 suggestions clarifying the relationship between CL
			 numeric type names and mathematical names
Status:	      For Internal Discussion

Problem Description:

  There is no standard type specifier symbol for the CL type
  '(OR RATIONAL FLOAT). 

Proposal (REAL-NUMBER-TYPE:REAL):

  Make REAL be a CL data type:

  p.13 "Numbers"

    Add:     The NUMBER data type encompasses all of these kinds of
	     numbers.  For convenience, there are names for some
	     subclasses of numbers.  @i[Integers] and @i[ratios] are of
	     type RATIONAL.  @i[Rational numbers] and @[floating-point
	     numbers] are of type REAL.  @i[Real numbers] and @i[complex
	     numbers] are of type NUMBER.

	     Although the names of these types were chosen with the
	     terminology of mathematics in mind, the correspondences
	     are not always exact.  Integers and ratios model the
	     corresponding mathematical concepts directly.  Numbers
	     of the FLOAT type may be used to approximate real
	     numbers, both rational and irrational.  The REAL type
	     includes all Common Lisp numbers which represent
	     mathematical real numbers, though there are
	     mathematical real numbers (irrational numbers)
	     which do not have an exact Common Lisp representation.
	     Only REAL numbers may be ordered using the <, >, <=,
	     and >= functions.

	     Compatibility note:  The Fortran standard defines the term
	     "real datum" to mean "a processor approximation to the value
	     of a real number."  In practice the Fortran "basic real" type
	     is the floating-point data type Common Lisp calls
	     SINGLE-FLOAT.  The Fortran "double precision" type is
	     Common Lisp's DOUBLE-FLOAT.  The Pascal "real" data type is
	     an "implementation-defined subset of the real numbers."  In
	     practice this is usually a floating-point type, often what
	     Common Lisp calls DOUBLE-FLOAT.

	     A translation of an algorithm written in Fortran or Pascal
	     which uses "real" data usually will use some appropriate
	     precision of Common Lisp's FLOAT type.  Some algorithms may
	     gain accuracy and/or flexibility by using Common Lisp's
	     RATIONAL or REAL types instead.

  p.33 "Overlap, Inclusion, and Disjointness of Types":

    Remove:  The types RATIONAL, FLOAT, and COMPLEX are pairwise
	     disjoint subtypes of NUMBER.

	     Rationale: It might be thought that INTEGER and RATIO ...

	     Rationale: It might be thought that FIXNUM and BIGNUM ...

    Add:     The types RATIONAL and FLOAT are pairwise disjoint subtypes
	     of REAL.

	     The types REAL and COMPLEX are pairwise disjoint subtypes
	     of NUMBER.

	     Rationale: It might be thought that FIXNUM and BIGNUM should 
	     form an exhaustive partition of the type INTEGER, that INTEGER
	     and RATIO should form an exhaustive partition of RATIONAL,
	     that RATIONAL and FLOAT should form an exhaustive partition of 
	     REAL, and that REAL and COMPLEX should form an exhaustive
	     partition of NUMBER.  These are all purposely avoided in order 
	     to permit compatible experimentation with extensions to the
	     Common Lisp number system, such as the idea of adding explicit 
	     representations of infinity or of positive and negative infinity.

   p.43 Table 4-1 "Standard Type Specifier Symbols"

    Add:     REAL

   p.49 "Type Specifiers that Abbreviate"

     Add:    (REAL low high)
	     Denotes the set of real numbers between low and high.  ...
	     [As with RATIONAL and FLOAT.]


  Make REAL a built-in CLOS class.

Proposal (REAL-NUMBER-TYPE:REALP):

  Add a specific data type predicate REALP which tests for membership in
  this type.  [By analogy with NUMBERP.]

Test Case:

  If a programmer wishes to test for "a number between 1 and 10", the
  only current CL types would be '(or (rational 1 10) (float 1 10)) or
  something like '(and numberp (not complexp) (satisfies range-1-10))
  with (defun range-1-10 (real) (<= 1 real 10)).  Both of these are
  likely less efficient, and certainly less expressive than '(real 1 10).

Rationale:

  Mathematics has a name for (OR RATIONAL FLOAT) -- it is "real".
  This class is important because it is all the numbers which can be
  ordered.

  Throughout the "Numbers" chapter, the phrase "non-complex number" is
  used.
  MAX, MIN, p. 198 "The arguments may be any non-complex numbers."
  CIS p. 207 "The argument ... may be any non-complex number."

Current Practice:

  Probably nobody does this.

Cost to Implementors:

  Some work is necessary to add this name.  But since the underlying
  type already exists the amount of work should be minimal.

Cost to Users:

  Since this is an upward-compatible extension, it may be ignored by
  users.

Cost of Non-Adoption:

  Occasional inconvenience and/or inefficiency.

Benefits:

  Mathematical clarity.

  Ability to do CLOS method dispatch on the type.

Aesthetics:

  As mentioned under "rationale," this would be a more concise way to
  express a common programming idiom.

Discussion:

  The name "non-complex number" is incorrect because future
  implementations may wish to include numerical types which are neither
  complex nor real.  [e.g. pure imaginary numbers or quaternions]

  The name "scalar" is incorrect because the mathematical concept of
  scalar may indeed include complex numbers.

  Fortran and Pascal use the name "real" to mean what CL calls
  SINGLE-FLOAT.  That should cause no significant problem, since a Lisp
  program written using the type REAL will do mathematically what the
  equivalent Fortran program would do.  This is because Fortran's "real"
  data-type is a subtype of the CL REAL type.  The only differences
  might be that the Lisp program could be less efficient and/or more
  accurate.

  A survey of several Fortran and Pascal books shows that the distinction
  between INTEGER and REAL is that REAL numbers may have fractional
  parts, while INTEGERs do not.  Later discussions explain that REALs
  cover a greater range.  Much later discussions cover precision
  considerations, over/underflow, etc.  So the average Fortran or Pascal
  programmer should be completely comfortable with the proposed Lisp
  concept of REAL.

∂15-Mar-89  1138	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)    
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  11:34:16 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via CHAOS with CHAOS-MAIL id 124421; Wed 15-Mar-89 13:58:59 EST
Date: Wed, 15 Mar 89 13:58 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
To: masinter.pa@xerox.com
cc: kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-144336-2004@Xerox>
Message-ID: <19890315185842.5.BARMAR@OCCAM.THINK.COM>

Sorry for the delay.  Here's a version with my amendments merged in.
Actually, it looks like it might read better if all the NCONC stuff were
pulled out of this proposal and made a separate issue; right now, most
of the sections say general things and then have a paragraph that begins
with "In the NCONC case...".  In that case, I suggest that the text
Amemdment I from my 14 February mail be used verbatim as the proposal.

						barmar

Issue:        REMF-DESTRUCTION-UNSPECIFIED
References:   (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
	      REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
	      DELETE-DUPLICATES, NSUBSTITUTE, NSUBSTITUTE-IF (pp254-256); 
	      NCONC, NRECONC (p269); NUNION, NINTERSECTION,
	      NSET-EXCLUSIVE-OR (pp276-279).
Category:     CLARIFICATION/CHANGE
Edit history: 11-Feb-87, Version 1 by Dave Andre (DLA@Symbolics.COM)
	      29-Oct-87, Version 2 by Pitman (flesh out proposals)
	      28-Nov-88, Version 3 by Pitman (revised presentation)
	      29-Nov-88, Version 4 by Pitman (slight editing per DLA)
	      15-Mar-89, Version 5 by Margolin (amendments discussed in
			 Hawaii, removed -NOT functions)
Status:	      For Internal Discussion

Problem Description:

 Currently, the exact nature of the side-effect performed by list
 modification routines is not specified.

 Either the specific modifications allowed should be specified so that
 programmers can rely on them and implementors can avoid accidentally
 causing problems by introducing well-meaning optimizations, or else
 the documentation should explicitly state that the effects are
 unspecified so that programmers will not depend on them and 
 implementors will feel comfortable about doing interesting optimizations.

Proposal (REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE-EXCEPT-NCONC):

 Clarify that the way in which the destructive behavior of the
 operators below is achieved is explicitly vague in a number of ways,
 in order to provide individual implementations the necessary
 flexibility to do useful optimizations.

 (SETF (GETF place indicator) value)
  is permitted to either SETF place or to SETF any part, CAR or
  CDR, of the top-level list structure held by that place.

 (REMF place indicator)
  is permitted to either SETF place or to SETF any part, CAR or
  CDR, of the top-level list structure held by that place.

 (SETF (GET symbol indicator) value)
  is constrained to behave exactly the same as
  (SETF (GETF (SYMBOL-PLIST symbol) indicator) value).

 (REMPROP symbol indicator)
  is constrained to behave exactly the same as
  (REMF (SYMBOL-PLIST symbol) indicator).

 (NREVERSE sequence)
  when sequence is a list, is permitted to SETF any part, CAR or
   CDR, of the top-level list structure in that sequence.
  when sequence is an array is permitted to re-order the elements
   of the given sequence in order to produce the resulting array.

 (DELETE object sequence ...)
  when sequence is a list, is permitted to SETF any part, CAR or
   CDR, of the top-level list structure held in that sequence.
  when sequence is an array is permitted to change the dimensions
   of the array and to slide its elements into new positions without
   permuting them to produce the resulting array.
  
 (DELETE-IF test sequence ...)
  is constrained to behave exactly like
  (DELETE NIL sequence
	  :TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
	  ...).

 (DELETE-DUPLICATES sequence ...)
  when sequence is a list, is permitted to SETF any part, CAR or
   CDR, of the top-level list structure held in that sequence.
  when sequence is an array is permitted to change the dimensions
   of the array and to slide its elements into new positions without
   permuting them to produce the resulting array.

 (NSUBSTITUTE new-object old-object sequence ...)
 (NSUBSTITUTE-IF new-object test sequence ...)
  when sequence is a list, is permitted to SETF any part, CAR or
   CDR, of the top-level list structure in that sequence.
  when sequence is an array is permitted to SETF the contents of
   any cell in that array which must be replaced by NEW-OBJECT.

  Note, however, that since this side-effect is not required,
  these functions should still not be used in for-effect-only
  positions in portable code.

 (NRECONC list tail)
  is constrained to have side-effect behavior equivalent to:
  (NCONC (NREVERSE list) tail).

 (NUNION list1 list2 ...)
 (NINTERSECTION list1 list2 ...)
 (NSET-EXCLUSIVE-OR list1 list2 ...)
  is permitted to SETF any part, CAR or CDR, of the top-level of
  any of the given lists.

  Note, however, that since this side-effect is not required,
  these functions should still not be used in for-effect-only
  positions in portable code.

 (NCONC . lists)
  is defined using the following recursive relationship:

    (NCONC) => NIL
    (NCONC NIL . args) == (NCONC . args)
    (NCONC arg) => arg
    (NCONC arg1 arg2) has the side effect of (RPLACD (LAST arg1) arg2),
		      and returns arg1 
    (NCONC arg1 arg2 . args) == (NCONC (NCONC arg1 arg2) . args)

  [If a previous cleanup issue prohibited NIL as a non-last argument
   then ignore the (NCONC NIL . args) case.]

 Note: The above clarifications are not intended as complete functional
 descriptions. They are intended to augment (rather than to replace)
 other descriptions already in effect.

Test Cases:

 For GETF...

    (SETQ FOO (LIST 'A 'B 'C 'D 'E 'F))    ==> (A B C D E F)
    (SETQ BAR (CDDR FOO))                  ==> (C D E F)
    (REMF FOO 'C)
    BAR				           ==> ??

    In Symbolics Common Lisp, BAR holds (C D E F).
    CLtL allows other interpretations. eg, BAR might hold
    (C), (NIL), (C NIL) or (C D).
    Under this proposal, any of these interpretations (and others as well)
    would still be valid

 For DELETE...

    (SETQ FOO (LIST 'A 'B 'C))   ==> (A B C)
    (SETQ BAR (CDR FOO))         ==> (B C)
    (SETQ FOO (DELETE 'B FOO))   ==> (A C)
    BAR                          ==> ??
    (EQ (CDR FOO) (CAR BAR))     ==> ??

    In Symbolics Common Lisp, these last two expressions return ((C)) and T.
    Under this proposal, either of these interpretations (and others
    as well) would be valid.

 For NCONC...

    (SETQ FOO (LIST 'A 'B 'C 'D 'E)
	  BAR (LIST 'F 'G 'H 'I 'J)
	  BAZ (LIST 'K 'L 'M)) => (K L M)
    (SETQ FOO (NCONC FOO BAR BAZ)) => (A B C D E F G H I J K L M)
    FOO => (A B C D E F G H I J K L M)
    BAR => (F G H I J K L M)
    BAZ => (K L M)

    (SETQ FOO (LIST 'A 'B 'C 'D 'E)
	  BAR (LIST 'F 'G 'H 'I 'J)
	  BAZ (LIST 'K 'L 'M)) => (K L M)
    (SETQ FOO (NCONC NIL FOO BAR NIL BAZ)) => (A B C D E F G H I J K L M) 
    FOO => (A B C D E F G H I J K L M)
    BAR => (F G H I J K L M)
    BAZ => (K L M)


Rationale:

 Implementations already vary widely on their implementation techniques
 for these functions. This effectively clarifies the status quo, making
 it more clear to programmers what they may rely upon in portable code.

 In the case of NCONC, however, the precise definition is useful because
 it is what users expect, it is how NCONC has been defined for many
 years, and it is how current implementations generally work.  It may
 not always be the most efficient way (e.g. it may result in invisible
 pointers in CDR-coded implementations), but callers of NCONC probably
 use it specifically for its precise side effects.

Current Practice:

 All valid implementations are believed to comply with the vague
 definitions.  Symbolics Genera 7.2 and Sun Common Lisp 2.1.3 appear to
 conform to the NCONC spec.

Cost to Implementors:

 None. This is probably the status quo for most implementors.  If there
 are any implementations that don't implement NCONC as above (which I
 doubt) they will have to be changed.

Cost to Users:

 This change would not affect programs coded with "good programming
 practice".  That is, only programs which rely on currently undocumented
 features would be in any danger of breaking.  In fact, those programs
 are already in such danger, and this change to the documentation would
 just publicize it.  The clarification would -encourage- good programming
 practice by warning people to only obey the published contract of the
 above-mentioned functions.

 There is, however, no automatic technique for making this check for
 programs already in error. Bugs due to unexpected side-effects are in
 general among the hardest to reckon with.

Cost of Non-Adoption:

 Programmers may naively believe there is only one possible or reasonable
 implementation of these functions. Some implementors may shy away from
 reasonable optimizations out of a paranoid belief that deviating from 
 some vague, unspoken rules will lead to programmer unrest. Making these
 things explicitly vague clarifies the implementor's rights in a way that
 permits numerous useful optimizations.

Benefits: 

 Users would be discouraged from taking advantage of subtle details
 of these destructive operations because such details would be explicitly
 not guaranteed to be portable.

 Implementations can improve performance of many of the above-mentioned
 functions when they are not under the constraint to implement them
 in a highly constrained fashion. For example, in Symbolics systems,
 DELETE of a cdr-coded list could use the implementation primitive
 %CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
 pointers.

 Garbage collection effectiveness can also be improved. For example,
 all of the destructive operations which remove objects (eg, REMF)
 could remove CAR pointers to removed objects which are more volatile
 than the list itself, assisting the garbage collector and thereby
 improving memory usage and paging performance.

 Tightening the definition of NCONC permits users to predict their
 programs' behavior more precisely.

Non-Benefits:

 Users who inadvertently depend on side-effect behavior may be rudely
 surprised when moving between implementations.

 Compatibility with older Lisp dialects is diminished.

 Implementors have less flexibility in implementing NCONC efficiently.

Performance Impact:

 Metering in Symbolics test  systems have shown that there are substantial
 performance gains to be had by allowing implementations flexibility in
 these areas.

 In the case of NCONC, this implementation flexibility, and hence
 potential performance improvements, is sacrificed.

Aesthetics:

 Most of these functions implement abstract operations. For example,
 REMPROP implements an abstract operation on a "property list".
 Proper language design should not encourage people to delve below the
 level of abstraction into the nitty gritty.

 NCONC is a "less abstract" function than the rest of the functions
 described above.  It is usually used precisely because of the way it
 interacts with list implementation.

Discussion:

 Andre's original version of this proposal pushed for explicitly vague
 descriptions of these functions' side-effect behavior.  He believes
 that if users want more predictability from these functions, they
 should write private variants that implement whatever predictability
 they require. 

 Pitman originally opposed this position because he weighed portability
 a higher concern. Since the original discussion, however, his views on
 how to resolve this priority have been refined, and he now believes
 that leaving things vague is appropriate. As such, he now supports what
 is effectively Andre's original proposal.

 Pitman and Andre supported version 4.  [I don't know how they feel
 about v5 -- Barmar].

∂15-Mar-89  1145	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89  11:44:52 PST
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557688; Wed 15-Mar-89 14:42:23 EST
Date: Wed, 15 Mar 89 14:42 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 3)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Masinter.pa@xerox.com
cc: Cassels@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@Sail.Stanford.EDU,
    DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM,
    Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19890315192425.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890315194221.4.CASSELS@GROUSE.SCRC.Symbolics.COM>

    Date: Wed, 15 Mar 89 14:24 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    Your issue status for this one says
      * REAL-NUMBER-TYPE
      Synopsis: add REAL = (OR RATIONAL FLOAT) & range
      Version 2, 08-Jan-89
      Comment: lengthy dissent; discussion? coercion for comparitor?
      Status: need new version
    but I think this version is ready to vote up-or-down.  Note that
    there are two proposals; the REALP predicate function has been
    separated out from the REAL data type.

    Date: Fri, 13 Jan 89 13:50 EST
    From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>

    Issue:        REAL-NUMBER-TYPE
    Forum:	      CLEANUP
    References:   Table 4-1.
    Category:     ADDITION
    Edit history: 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,
			     and John Aspinall
		  08-JAN-89, Version 2 by Bob Cassels -- incorporate
			     Masinter's suggestion and make REAL a CLOS class
		  13-JAN-89, Version 3 by Cassels and Aspinall -- incorporate Marc LeBrun's
			     suggestions clarifying the relationship between CL
			     numeric type names and mathematical names
    Status:	      For Internal Discussion

We should change "current practice" to note that TI Lisp includes both
the REAL type and REALP predicate.

∂15-Mar-89  1147	CL-Cleanup-mailer 	Issue: MAKE-STRING-FILL-POINTER (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89  11:47:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557698; Wed 15-Mar-89 14:45:08 EST
Date: Wed, 15 Mar 89 14:45 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-STRING-FILL-POINTER (Version 1)
To: Masinter.pa@xerox.com
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19881021012549.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Message-ID: <19890315194500.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

Your status file says:
  * MAKE-STRING-FILL-POINTER
  Synopsis: extend MAKE-STRING to take a fill-pointer?
  Version 1, 20-Oct-88
  Comments: extend to take other keywords? MAKE-STRING should return
	  simple string always? Interaction with character proposal
  Status: awaiting new version
But I don't have any record of any discussion that would warrant
a new version.  Also I don't believe the comments quoted above
are relevant to this issue.  If you have any discussion I should
see, and suggestions for a new version, could you forward them to
me?  If you send me that I'll make a new version.  Otherwise I
think the old version is ready to vote on, up-or-down.

Date: Thu, 20 Oct 88 21:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

Issue:         MAKE-STRING-FILL-POINTER

References:    CLtL p.302

Related issues: none that I know of

Category:      ADDITION

Edit history:  Version 1, 20-Oct-88, by Moon, for discussion

Problem description:

  Once again I lost because I expected to be able to use MAKE-STRING
  to create a string with a fill-pointer, and I couldn't.  I had to use
  a more long-winded MAKE-ARRAY call instead.

Proposal (MAKE-STRING-FILL-POINTER:ALLOW):

  Give MAKE-STRING a :FILL-POINTER argument, with the same syntax and
  semantics as the :FILL-POINTER argument to MAKE-ARRAY.

Examples:

  (make-string 80 :fill-pointer 0)

Test Cases:

  See examples.

Rationale:

  I frequently expect it to be allowed and am surprised when it's not.

Current practice:

  I know of no implementations that support this.

Cost to Implementors:

  5 cents.

Cost to Users:

  none

Cost of non-adoption:

  none

Performance impact:

  none

Benefits:

  Increased language consistency.

Esthetics:

  Increased language consistency.

Discussion:

Other MAKE-ARRAY options that one might want to allow, but are
not already allowed or proposed, are :INITIAL-CONTENTS, :ADJUSTABLE,
:DISPLACED-TO, and :DISPLACED-INDEX-OFFSET.  A strong case could be
made for :ADJUSTABLE (I use an implementation where it doesn't matter,
so I don't care about that), I don't think anyone would care about the 
other three.

∂15-Mar-89  1208	CL-Cleanup-mailer 	Issue status    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 15 Mar 89  12:07:44 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	id AA29800; Wed, 15 Mar 89 12:05:27 PST
Message-Id: <8903152005.AA29800@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for cl-cleanup@sail.stanford.edu; id AA29800; Wed, 15 Mar 89 12:05:27 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 15 Mar 89 14:29
To: cl-cleanup@sail.stanford.edu
Subject: Issue status

>   > >+ FUNCTION-COMPOSITION
>   > >Synopsis: Add new functions
>   > >Version 5, 10-Feb-89 
>   > >Status: Passed (as amended) Jan 89 X3J13
>   > I know this is picky, but I thought it was decided to fail this one
>   > completely and amend TEST-NOT-IF-NOT (I believe that was the related
>   > issue).
> 
>   -- you may be right. I wish we had minutes. I guess I'll stick by my
>   summary unless I hear otherwise.
> 
>My notes show that the COMPLEMENT function was accepted and
>all other parts of the proposal failed.

Yes but COMPLEMENT was an amendment to TEST-NOT-IF-NOT. This was how Walter
and I both recorded it. Anyway, it seems to be clear what happened even
if the status of the issues isn't.

∂15-Mar-89  1227	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL (Version 9)   
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Mar 89  12:26:28 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa11885; 15 Mar 89 20:13 GMT
Date: Wed, 15 Mar 89 20:10:25 GMT
Message-Id: <2348.8903152010@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
To: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@com.xerox's message of 13 Mar 89 17:14 PST

> The last version of PROCLAIM-LEXICAL I have is Version 9, which was
> distributed before the Hawaii meeting. There were the various comments on
> Version 9, amendments proposed but not passed, and, more recently, mail
> from Sandra Loosemore, Jeff Dalton, JonL White, Gail Zacharias and David
> Moon.
> 
> However, there's no new version.

Last I knew, JonL had said there were "conceptual" problems.  I said
that, if there were, I didn't understand what they were.  And that was
the last I saw on this topic.  Maybe I'd managed to convince JonL?

In Hawaii, some people objected on grounds of efficiency or because
they didn't have a spare bit (see the Rees suggestion in the
proposal).

I think the ammendments proposed in Hawaii might have answered both
kinds of objection, but I remember thinking that some of the
ammendments were unnecessary or wrong.

Perhaps those who still have objections can say what they would like
to change and why.

∂15-Mar-89  1229	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Mar 89  12:27:33 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa09545; 15 Mar 89 15:59 GMT
Date: Wed, 15 Mar 89 15:57:02 GMT
Message-Id: <1423.8903151557@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, Masinter.PA@xerox.com
In-Reply-To: Kent M Pitman's message of Tue, 14 Mar 89 20:43 EST
Cc: CL-Cleanup@sail.stanford.edu

> All in all, though, I like somebody's (Gray's?) suggestion of a
> function rather than a table. The default being #'CHAR-UPCASE, and
> #'IDENTITY being another obvious choice.

It was indeed Gray's suggestion.

I also prefer the function to the keyword.  However, can we allow
arbitrary functions or would that cause problems for the printer?

> The reason I like the function rather than the keyword is that you
> don't have to initially provide the alternate functionality -- user's
> can add it.

Can they or do the functions have to be from a set known to the
printer?

> In the case of the keyword, it has to be given by the system so you're
> at the mercy of the implementors as to which options you get.  I think
> this feature is worth the added complexity.

I am somewhat uneasy about allowing arbitrary translations rather
than just having a case switch.  I would rather have the general
mechanism but not if it would cause prople to oppose an issue they
would otherwise support.

-- Jeff

∂15-Mar-89  1256	CL-Cleanup-mailer 	PRETTY-PRINT-INTERFACE, version 3 (supersedes 2 sent an hour ago!)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  12:54:51 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 15:50:57 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 15:52:16 EST
Received: by verdi.think.com; Wed, 15 Mar 89 15:49:04 EST
Date: Wed, 15 Mar 89 15:49:04 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152049.AA03416@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: PRETTY-PRINT-INTERFACE, version 3 (supersedes 2 sent an hour ago!)


Version 3 is changed from version 1 as follows:
adds a functional interface to supplement the interface through FORMAT,
and reflects comments by Barrett and Pierson.

The document attached to version 1 has been omitted here, as the
mailer choked on it.  It should logically be inserted before the
functional interface attached here.
--Guy


Issue:		PRETTY-PRINT-INTERFACE

References:	Description of XP by Dick Waters (attached)
		*PRINT-PRETTY* (CLtL p. 371)
		WRITE (CLtL p. 382)
		PPRINT (CLtL p. 383)
		FORMAT (CLtL pp. 385-407)
		FORMAT ~T directive (CLtL pp. 398-399)
		FORMAT ~< directive (CLtL pp. 404-406)

Related issues: 

Category:	CLARIFICATION CHANGE ADDITION

Edit history:	Version 1, 24-Feb-89 by Steele
		Version 2, 15-Mar-89 by Steele and Waters
		Version 3, 15-Mar-89 by Steele

Problem description:

At present Common Lisp provides no specification whatsoever of how
pretty-printing is to be accomplished, and no way for the user to control
it.  In particular, there is no protocol by which a user can write a
print-function for a structure, or a method for PRINT-OBJECT, that will
interact smoothly with the built-in pretty-printer in a portable manner.

Proposal (PRETTY-PRINT-INTERFACE:XP):

Adopt the interfaces and protocols of the XP pretty-printer by Dick Waters,
described in full in the attached 12-page document.  Here is a very brief
summary of the proposal.

New variables:	*PRINT-DISPATCH*
		*PRINT-RIGHT-MARGIN*
		*DEFAULT-RIGHT-MARGIN*
		*PRINT-MISER-WIDTH*
		*PRINT-LINES*
		*LAST-ABBREVIATED-PRINTING*

New function:	COPY-PRINT-DISPATCH

New macro:	DEFINE-PRINT-DISPATCH

New FORMAT directives:	~W  ~_  ~I  ~:T  ~/name/  ~<...~:>

New # reader macro:  #"..."

The function WRITE is extended to accept additional keyword arguments
:DISPATCH, :RIGHT-MARGIN, :LINES, and :MISER-WIDTH corresponding to the
first four of the new variables.

Finally, wherever in the attached document it says that certain constructs
support depth abbreviation and circularity detection, it should be noted
that this is so a fortiori, because *all* printing operations support them
properly.  Therefore, while the statements are correct, the possibly
misleading implication that they are the only way to achieve such
detection should be rectified if the text is taken over into the standard.


Examples:	See attached document.


Rationale:

There ought to be a good user interface to the pretty printer.
This is the only proposal for which there is a portable implementation
that has seen extensive use and is being made freely available.


Current practice:

XP son of PP son of GPRINT son of PRINT* is the latest in a line of pretty
printers that goes back 13 years.  All of these printers use essentially
the same basic algorithm and conceptual interface.  Further, except for
PRINT*, which was implemented solely to satisfy the author's personal
needs, each of these printers has had extensive use.  XP has been in
experimental use as the pretty printer in CMU Common Lisp for 6 months.  PP
has been the pretty printer in DEC Common Lisp for the past 3 years.  Prior
to three years ago, GPRINT was used for 2 years as the pretty printer in
DEC Common Lisp.  In addition, GPRINT has been the pretty printer in
various generations of Symbolics Lisp for upwards of 5 years.
(See Waters R.C., "User Format Control in a Lisp Prettyprinter", ACM TOPLAS,
5(4):513--531, October 1983.)


Cost to Implementors:

A fair amount of effort (perhaps a few man-weeks at most).
Source code for XP is available to all comers from Dick Waters, and
the system is documented in great detail:

Waters, Richard C., "XP: A Common Lisp Pretty Printing System",
Artificial Intelligence Laboratory Technical Memo 1102,
Massachusetts Institute of Technology, Cambridge MA, March 1989.


Cost to Users:  None (I think).  This is an upward-compatible extension.

Cost of non-adoption:  Continued inability for user print-functions
to interact with the pretty-printer in a useful and portable manner.


Performance impact:  XP is claimed to be quite fast.

Benefits:  User control of pretty-printing in a portable manner.

Esthetics:

Using ~<...~:> may strike some as uncomfortably close in the syntactic
space of FORMAT directives to the existing ~<...~>.  However, it is very
unlikely that both of these directives (pretty-print logical block and
columnar justification, respectively) will be used in the same call to
FORMAT.  Previous versions of XP used ~!...~. instead of ~<...~:> but this
made FORMAT strings very difficult to read; it is preferable to have
a directive that looks like matching brackets of some sort.

Dan Pierson comments:  You might mention that some people will undoubtedly
find piling more hair on FORMAT ugly (of course these same people may
well find FORMAT in general ugly :-)).

Discussion:

Zetalisp used ~:T to mean pixelwise tabulation, so the use of ~:T
suggested here may be a problem.  If so, another suggestion for naming
this directive would be appropriate.

The ~/.../ directive is already in Zetalisp, and is not an idea new
to this proposal.

Guy Steele and Dick Waters strongly support this proposal.  (As an example,
Guy Steele has a portable simulator for Connection Machine Lisp, and would
like very much to have xappings and xectors pretty-print properly.)

Dan Pierson comments: You can add me to the list of strong supporters of
this proposal.  While the proposal is long and complex, it is supported by
a long history of usage in several different Lisp environments.  Unlike
some earlier members of this family, this version fits cleanly enough into
the rest of Common Lisp to warrant standardization.

The utility of *PRINT-LINES* becomes more obvious if it is pointed out
that Dick's pretty printers are implemented to print each line as it
is computed.  This means that a small value for *PRINT-LINES* saves
significant time as well as output medium space.  In fact, many people
find that a very pleasant REP loop is created by setting *PRINT-LINES*
to a value from 1-4, *PRINT-PRETTY* to T, and defining a short-name
function (say (PP*)) that funcalls *LAST-ABBREVIATED-PRINTING* with
abbreviation bound off.  This is almost as fast and compact as, and
MUCH more readable than, a non-pretty-printing REP loop.

The advantages of compiled format strings (format functions) should be
brought out as benefits in their own right.  The current proposal just
mentions them as a minor feature of XP.

At first this struck me a very cute end run around the failure of
STREAM-INFO, then I realized that one of the problems with STREAM-INFO
may have been that it was a standard at the wrong level.  STREAM-INFO
permitted people to use XP, but not to count on it.  This proposal
makes it possible to write portable code whose new data structures and
language elements print correctly in whatever Common Lisp environment
they're run in.  [End of comments by Pierson]
!
                  Functional Interface  

The primary interface to operations for dynamically determining the
arrangement of output is provided through FORMAT.  This is done,
because FORMAT strings are typically the most convenient way of
interacting with pretty printing.  However, these operations have
nothing inherently to do with FORMAT per se.  In particular, they can
also be accessed via the six functions and macros below.

WITHIN-LOGICAL-BLOCK (&KEY :STREAM :VAR :ARG                     [Macro]
                           :PREFIX :PER-LINE-PREFIX :SUFFIX)
                      &BODY BODY

In the manner of ~<...~:>, this macro causes printing to be
grouped into a logical block.  The value NIL is always returned.

:STREAM specifies the stream the logical block is to be printed on.
:STREAM defaults to *STANDARD-OUTPUT* and follows the standard
conventions for stream arguments to output functions---NIL stands for
*STANDARD-OUTPUT* and T stands for *TERMINAL-IO*.

:VAR (which defaults to *STANDARD-OUTPUT*) must be a symbol other than
T or NIL.  :VAR is bound to a special kind of stream that supports
dynamic decisions about the arrangement of output.

The BODY can contain any arbitrary Lisp forms.  All the standard
printing functions (e.g., WRITE, PRINC, TERPRI) can be used to print
output into :VAR.  All and only the output sent to :VAR is treated as
being in the logical block.  It is an error for the BODY to send any
output directly to :STREAM.

:SUFFIX (which defaults to the null string) specifies a suffix that is
printed just after the logical block.  :PREFIX specifies a prefix to be
printed before the beginning of the logical block.  :PER-LINE-PREFIX
specifies a prefix that is printed before the block and at the
beginning of each new line in the block.  It is an error for :PREFIX
and :PRE-LINE-PREFIX to both be used. If neither is used, a :PREFIX of
the null string is assumed.

:ARG (which defaults to NIL) is interpreted as being a list that BODY
is responsible for printing.  If :ARG is not a list, it is printed
using WRITE.  If *PRINT-CIRCLE* is not NIL and :ARG is a circular
reference to a cons, then an appropriate #n# marker is printed.  If
*PRINT-LEVEL* is not NIL and the logical block is at a dynamic nesting
depth of greater than *PRINT-LEVEL* in logical blocks, # is printed.
If either of the three conditions above occures, the special output is
printed on :STREAM and the BODY is skipped along with the printing of
the prefix and suffix.

CONDITIONAL-NEWLINE KIND &OPTIONAL (STREAM *STANDARD-OUTPUT*)    [Function]

CONDITIONAL-NEWLINE is the functional equivalent of ~_.  STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions.  The KIND argument specifies
the style of conditional newline.  It must be one of :LINEAR, :FILL,
:MISER, or :MANDATORY.  If STREAM is a special stream bound by
WITHIN-LOGICAL-BLOCK, a conditional newline is sent to it.  Otherwise,
CONDITIONAL-NEWLINE has no effect.  The value NIL is always returned.

LOGICAL-BLOCK-INDENT KIND N &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]

LOGICAL-BLOCK-INDENT is the functional equivalent of ~I, STREAM
argument (which defaults to *STANDARD-OUTPUT*) follows the standard
conventions for stream arguments to printing functions.  N specifies
the amount of indentation.  If KIND is :FROM-START, this indentation is
relative to the start of the enclosing block (as for ~I).  If KIND is
:FROM-POSITION, the indentation is relative to the current output
position (as for ~:I).  It is an error for KIND to take on any other
value.  If STREAM is a special stream bound by WITHIN-LOGICAL-BLOCK,
LOGICAL-BLOCK-INDENT sets the indentation in the innermost enclosing
logical block.  Otherwise, LOGICAL-BLOCK-INDENT has no effect.  The
value NIL is always returned.

LOGICAL-BLOCK-TAB KIND COLNUM COLINC &OPTIONAL (STREAM *STANDARD-OUTPUT*)

LOGICAL-BLOCK-TAB is the functional equivalent of ~T.  STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions.  The arguments COLNUM and
COLINC correspond to the two numeric parameters to ~T.  The KIND
argument specifies the style of tabbing.  It must be one of :LINE (tab
using ~T), :BLOCK (tab using ~:T), :LINE-RELATIVE (tab using ~@T), or
:BLOCK-RELATIVE (tab using ~:@T).  If STREAM is a special stream bound
by WITHIN-LOGICAL-BLOCK, tabbing is performed.  Otherwise,
LOGICAL-BLOCK-TAB has no effect.  The value NIL is always returned.

LOGICAL-BLOCK-POP ARGS &OPTIONAL (STREAM *STANDARD-OUTPUT*)      [Macro]
LOGICAL-BLOCK-COUNT &OPTIONAL (STREAM *STANDARD-OUTPUT*)         [Macro]

LOGICAL-BLOCK-POP is identical to POP except that it supports
*PRINT-LENGTH* and *PRINT-CIRCLE*.  It is an error to use
LOGICAL-BLOCK-POP anywhere other than syntactically nested within a
call on WITHIN-LOGICAL-BLOCK.

ARGS must be a symbol or expression acceptable to POP.  STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions.  If STREAM is a special stream
bound by WITHIN-LOGICAL-BLOCK, then LOGICAL-BLOCK-POP performs the
special operations described below.  Otherwise, LOGICAL-BLOCK-POP is
identical to POP.

Each time LOGICAL-BLOCK-POP is called, it performs three tests.  if
ARGS is not a cons, ". " is printed followed by ARGS.  If
*PRINT-LENGTH* is NIL and LOGICAL-BLOCK-POP has already been called
*PRINT-LENGTH* times within the immediately containing logical block,
"..." is printed. If *PRINT-CIRCLE* is not NIL, and ARGS is a circular
reference, then ". " is printed followed by an appropriate #n# marker.
If either of the three conditions above occurs, the special output is
printed on :STREAM and the execution of the immediately containing
WITHIN-LOGICAL-BLOCK is terminated except for the printing of the
suffix.  Otherwise, LOGICAL-BLOCK-POP pops the top value off of ARGS
and returns this value.

LOGICAL-BLOCK-COUNT is identical to LOGICAL-BLOCK-POP except that it
does not take an ARGS argument, always returns NIL, and only performs
the second test discussed above.  It is useful when the components of a
non-list are being printed.

Using the functions above, TABULAR-STYLE could be defined as follows.
    
    (defun tabular-style (stream list &optional (colon? T) atsign? 
						(tabsize nil))
	(declare (ignore atsign?))
      (if (null tabsize) (setq tabsize 16))
      (within-logical-block (:var s :stream stream :arg list
			     :prefix (if colon? "(" "")
			     :suffix (if colon? ")" ""))
       (when list
	 (loop (write (logical-block-pop list s) :stream s)
	       (if (null list) (return nil))
	       (write-char #\space s)
	       (logical-block-tab :block-relative 0 tabsize s)
	       (conditional-newline :fill s)))))

The function below prints a vector using #(...) notation.
    
    (defun print-vector (v *standard-output*)
      (within-logical-block (:prefix "#(" :suffix ")")
	(let ((end (length v)) (i 0))
	  (when (plusp end)
	    (loop (logical-block-count)
		  (write (aref v i))
		  (if (= (incf i) end) (return nil))
		  (write-char #\space)
		  (conditional-newline :fill))))))



[End of attached document]

∂15-Mar-89  1306	CL-Cleanup-mailer 	Issue: GENSYM-NAME-STICKINESS, version 2 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  13:05:38 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 16:01:40 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 16:02:59 EST
Received: by verdi.think.com; Wed, 15 Mar 89 15:59:47 EST
Date: Wed, 15 Mar 89 15:59:47 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152059.AA03501@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: GENSYM-NAME-STICKINESS, version 2
Cc: gls@Think.COM


Version 2 proposes to provide access to the counter state.


Additional Comments include:

"... it's ... late to consider things like this ..."
"YAY!!!    This is what "cleanup" is for. Go For It! "
"Sounds like a good idea to me."

!
Issue:        GENSYM-NAME-STICKINESS
Forum:	      Cleanup
References:   GENSYM (p169)
Category:     CHANGE
Edit history: 14-Feb-89, Version 1 by Pitman
	      15-Mar-89, Version 2 by Steele

Problem Description:

  Many people avoid use of the argument to GENSYM because the argument
  is `sticky' and such stickiness can lead to confusion. The problem is
  that if any application (usually a macro) uses the gensym argument at
  all, then all applications are forced to. If they do not, they risk
  finding that the `helpful' argument supplied in some previous call will
  be harmful to them.

Proposal (GENSYM-NAME-STICKINESS:WASH-HANDS):

  Define that if an optional argument is given to GENSYM, it does NOT
  have a side-effect on GENSYM's internal state.

  Define that the function GENSYM-COUNTER takes a non-negative integer n
  and modifies the internal state of GENSYM so that the next symbol
  generated will be number n.  GENSYM-COUNTER returns the old value
  of the counter.

Rationale:

  Conscientious programmers are forced now to write their own GENSYM
  lookalikes because they know the system's GENSYM has an invasive
  effect. This defeats the primary intended function of GENSYM, which
  is to satisfy the most common idiomatic use of MAKE-SYMBOL.

  The stickiness of the GENSYM prefix was an attempt to be gratuitously
  compatible with Maclisp, at the expense of good programming pratice.

  Users who need the old behavior of GENSYM can trivially implement
  that behavior using MAKE-SYMBOL.

  Occasionally you want to reset the GENSYM counter so that, for example,
  you can get the compiler to generate the same symbol names again
  (good for comparing results to see what really changed).

Test Case:

  (CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
	      #\G)
  => NIL ;under CLtL
  => T   ;under this proposal

  (string= (symbol-name (progn (gensym-counter 43) (gensym "foo")))
           "foo43") => T

Current Practice:

  Symbolics Cloe and Genera are compatible with CLtL, so this would be an
  incompatible change.

Cost to Implementors:

  Very small.

Cost to Users:

  Most uses of GENSYM do not depend on the stickiness of the name, so the
  change would be compatible. In some cases, the change would be an
  improvement. Even in the worst case where someone depends on stickiness,
  it's extremely straightforward to write the couple of lines of code to
  produce an application based on MAKE-SYMBOL that is at least as flexible
  as GENSYM, and often moreso.

Cost of Non-Adoption:

  Good programmers would avoid using the argument to GENSYM (or using 
  GENSYM altogether) in many situations where they ought not have to.

Benefits:

  Gensyms which appear to convey information through their name would not
  accidentally pop out and cause confusion in places where they oughtn't.

Aesthetics:

  Unnecessary global state changes are hard to reason about. This would 
  be a small simplification.

Discussion:

  Pitman claims to have written a non-sticky GENSYM function for nearly
  every one of the dozen or so large systems that he's written or worked
  on in the last decade in order to get around the stated problem.
  Others have suggested similar experience.

  Pitman supported version 1.  In response to a query, he said:
  "... the only part of this I really care about is that the name
  not be sticky.  If you make any reasonable counterproposal that gives
  me that one feature, odds are that I'll support it."

  Steele supports this proposal.


∂15-Mar-89  1449	CL-Cleanup-mailer 	Issue SUBTYPEP-TOO-VAGUE, version 5 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  14:46:57 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 17:43:08 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 17:44:28 EST
Received: by verdi.think.com; Wed, 15 Mar 89 17:41:16 EST
Date: Wed, 15 Mar 89 17:41:16 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152241.AA03730@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue SUBTYPEP-TOO-VAGUE, version 5
Cc: gls@Think.COM


This is a proposed amendment to version 4 passed in January 1989 at Kauai.

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)
                Version 3,  6-Oct-88 (Masinter)
                Version 4,  7-Oct-88 (Masinter, per Moon's comments)

Problem Description:

[From version 4]

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.

[Addition for version 5]

There are two problems with version 4.  First is that of the first three
bulleted points in the version 4 proposal:

    * Clarify that SUBTYPEP will return a second value of NIL
    only when either of the type specifiers involves the SATISFIES, NOT, 
    AND, OR, MEMBER. SUBTYPEP will not return a second
    value of NIL when both arguments involve only the words in Table 4-1, or
    names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes
    that expand into only those words and/or names.

    * SUBTYPEP should signal an error when handed (for either argument)
    a type specifier that involves VALUES or the list form of the FUNCTION
    type.

    * SUBTYPEP must always return values T T in the case where the two
    type specifiers (or their expansions) are EQUAL.

any two have significant overlap, and indeed all three can overlap;
version 4 contained no indication of how this conflict should be resolved.

Second is that version 4 calls for SUBTYPEP to signal an error (at least at
high safety)even when the arguments are valid type specifiers, but this can
make it harder to use SUBTYPEP.  These are cases that returning NIL NIL
was supposed to cover.

This version replaces the three bulleted points above with a single point
and some observations about its consequences.  This version eliminates
the requirement to signal an error.


Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY-MORE

A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a 
DEFTYPE  defined type specifier. 

* Clarify that SUBTYPEP is permitted to return NIL NIL only when
  at least one argument involves SATISFIES, AND, OR, NOT, MEMBER,
  VALUES, or the list form of FUNCTION.

  Note that one consequence of this is that if neither argument
  involves any of these type specifiers, then SUBTYPEP is obliged
  to determine the relationship accurately.  In particular, SUBTYPEP
  must return T T if the arguments are EQUAL and do not involve
  any of the above-stated type specifiers.

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

Specifying the behavior of SUBTYPEP makes it more useful. Otherwise,
programs cannot rely on any more than NIL NIL as return values.

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.   

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:

Its hard to imagine a portable program that depends heavily
on SUBTYPEP. This proposal does not require any implementation
to "handle" fewer cases of SUBTYPEP.

Benefits:

An area of confusion in the language is cleared up.  Usages of SUBTYPEP
will be more portable.

Discussion:

The handling of FLOAT and SINGLE-FLOAT  appeared to be the 
consensus from a discussion on the common-lisp mailing list some
 time ago.

It would not be too onerous to require implementations to handle
the cases where one but not the other type specifier involves
OR, AND, NOT or MEMBER, but the specification becomes 
cumbersome.

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?

The rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail.

∂15-Mar-89  1454	CL-Cleanup-mailer 	[gls: Issue SUBTYPEP-TOO-VAGUE, version 5]    
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  14:50:43 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 17:46:14 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 17:47:25 EST
Received: by verdi.think.com; Wed, 15 Mar 89 17:44:14 EST
Date: Wed, 15 Mar 89 17:44:14 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152244.AA03741@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: [gls: Issue SUBTYPEP-TOO-VAGUE, version 5]


[I forgot to update the edit history.  Here is corrected copy.]



Date: Wed, 15 Mar 89 17:41:16 EST
From: Guy Steele <gls>
To: cl-cleanup@sail.stanford.edu
Subject: Issue SUBTYPEP-TOO-VAGUE, version 5
Cc: gls


This is a proposed amendment to version 4 passed in January 1989 at Kauai.

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)
                Version 3,  6-Oct-88 (Masinter)
                Version 4,  7-Oct-88 (Masinter, per Moon's comments)
		Version 5, 15-Mar-89 Steele

Problem Description:

[From version 4]

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.

[Addition for version 5]

There are two problems with version 4.  First is that of the first three
bulleted points in the version 4 proposal:

    * Clarify that SUBTYPEP will return a second value of NIL
    only when either of the type specifiers involves the SATISFIES, NOT, 
    AND, OR, MEMBER. SUBTYPEP will not return a second
    value of NIL when both arguments involve only the words in Table 4-1, or
    names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes
    that expand into only those words and/or names.

    * SUBTYPEP should signal an error when handed (for either argument)
    a type specifier that involves VALUES or the list form of the FUNCTION
    type.

    * SUBTYPEP must always return values T T in the case where the two
    type specifiers (or their expansions) are EQUAL.

any two have significant overlap, and indeed all three can overlap;
version 4 contained no indication of how this conflict should be resolved.

Second is that version 4 calls for SUBTYPEP to signal an error (at least at
high safety)even when the arguments are valid type specifiers, but this can
make it harder to use SUBTYPEP.  These are cases that returning NIL NIL
was supposed to cover.

This version replaces the three bulleted points above with a single point
and some observations about its consequences.  This version eliminates
the requirement to signal an error.


Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY-MORE

A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a 
DEFTYPE  defined type specifier. 

* Clarify that SUBTYPEP is permitted to return NIL NIL only when
  at least one argument involves SATISFIES, AND, OR, NOT, MEMBER,
  VALUES, or the list form of FUNCTION.

  Note that one consequence of this is that if neither argument
  involves any of these type specifiers, then SUBTYPEP is obliged
  to determine the relationship accurately.  In particular, SUBTYPEP
  must return T T if the arguments are EQUAL and do not involve
  any of the above-stated type specifiers.

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

Specifying the behavior of SUBTYPEP makes it more useful. Otherwise,
programs cannot rely on any more than NIL NIL as return values.

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.   

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:

Its hard to imagine a portable program that depends heavily
on SUBTYPEP. This proposal does not require any implementation
to "handle" fewer cases of SUBTYPEP.

Benefits:

An area of confusion in the language is cleared up.  Usages of SUBTYPEP
will be more portable.

Discussion:

The handling of FLOAT and SINGLE-FLOAT  appeared to be the 
consensus from a discussion on the common-lisp mailing list some
 time ago.

It would not be too onerous to require implementations to handle
the cases where one but not the other type specifier involves
OR, AND, NOT or MEMBER, but the specification becomes 
cumbersome.

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?

The rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail.

∂15-Mar-89  1756	CL-Cleanup-mailer 	Re: Issue LOCALLY-TOP-LEVEL, v1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  17:56:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 17:24:03 PST
Date: 15 Mar 89 17:23 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue LOCALLY-TOP-LEVEL, v1
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Mon, 13 Mar 89 18:51 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>, cl-cleanup@SAIL.STANFORD.EDU,
 cl-compiler@SAIL.STANFORD.EDU
Message-ID: <890315-172403-1288@Xerox>

I don't care what committee you send it to, but since Sandra has already
finished her list of proposals and I'm still working on mine, you might as
well get it on mine. Cleanup has more time, anyway.

It looked like it only needed the minor edit to fix the NO-HOSTING
allusion.


∂15-Mar-89  1907	CL-Cleanup-mailer 	Re: Issue STREAM-ACCESS   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89  19:06:57 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 18:33:15 PST
Date: 15 Mar 89 18:31 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue STREAM-ACCESS
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Fri, 10 Mar 89
 14:41:53 PST
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890315-183315-1621@Xerox>

I don't think we want either

(typecase stream
	(two-way-stream ...)
	(echo-stream ...)


to behave in an implementation-dependent manner, or
to require that echo-stream be a subtype of two-way-stream.

You can always have a class that is their mutual 
superclass, i.e., that they both inherit from.

However, the relation between the streams in
echo and two-way is significantly different.

∂16-Mar-89  0523	CL-Cleanup-mailer 	Re: Issue: GENSYM-NAME-STICKINESS, version 2  
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 16 Mar 89  05:23:07 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab00401; 16 Mar 89 8:13 EST
Received: from draper.com by RELAY.CS.NET id aa08495; 16 Mar 89 8:10 EST
Date: Thu, 16 Mar 89 07:58 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: GENSYM-NAME-STICKINESS, version 2
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525

I like it.  But one suggestion:
 
Instead of (gensym-counter <n>) which updates the gensym counter, why not
(gensym-counter) which returns the current gensym counter, and
(setf (gensym-counter) <n>) ???

∂16-Mar-89  0646	CL-Cleanup-mailer 	Issue: GENSYM-NAME-STICKINESS, version 2 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89  06:46:44 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558309; Thu 16-Mar-89 09:44:17 EST
Date: Thu, 16 Mar 89 09:44 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS, version 2
To: GLS@Think.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890316094401.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

Can you motivate why you want a function rather than a variable
for the counter control? For example, a useful feature of a
variable would be to bind it. 

My basic feeling is that if we need a function rather than variable,
we must need the function for a reason. What is the function providing
that is worth the added descriptive overhead and loss of (binding)
flexibility but that is not stated in the writeup?

∂16-Mar-89  0807	CL-Cleanup-mailer 	Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)  
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89  08:06:57 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA02088; Thu, 16 Mar 89 11:04:37 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA07042; Thu, 16 Mar 89 10:41:17 EST
Message-Id: <8903161541.AA07042@mist.>
To: CL-CLEANUP@Sail.stanford.edu
Subject: Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1) 
In-Reply-To: Your message of 15 Mar 89 17:16:00 -0800.
             <890315-171714-1269@Xerox> 
Date: Thu, 16 Mar 89 10:41:15 EST
From: Dan L. Pierson <pierson@mist.encore.com>

Sorry for the late reply on this.

The only problem with this proposal is that *BREAK-ON-SIGNALS* seems
to implicitly depend on either:

    1. Having all condition types you want to control in one inheritance
       tree.

    2. Or SUBTYPEP supporting MEMBER type specifiers.

For example, suppose you create a new subtype of CONDITION, disjoint
from WARNING, called FROB, that does not break by default.  Now
suppose you want to break on both WARNING and FROB, but not on another
disjoint subtype of CONDITION, say BLAT.  The only way I can see to do
this would be:

    (SETQ *BREAK-ON-SIGNALS* '(MEMBER WARNING FROB))

But this would presumably fail to work in an implementation that
compilied minimally with SUBTYPEP-TOO-VAGUE.

Of course, *BREAK-ON-WARNINGS* doesn't solve this problem, it just
dodges the one occurance of it that involves standard condition types.

∂16-Mar-89  0827	CL-Cleanup-mailer 	Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)  
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89  08:26:55 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA02401; Thu, 16 Mar 89 11:24:37 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA07142; Thu, 16 Mar 89 11:22:55 EST
Message-Id: <8903161622.AA07142@mist.>
Cc: CL-CLEANUP@Sail.stanford.edu
Subject: Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1) 
In-Reply-To: Your message of Thu, 16 Mar 89 10:41:15 -0500.
             <8903161541.AA07042@mist.> 
Date: Thu, 16 Mar 89 11:22:50 EST
From: Dan L. Pierson <pierson@mist.encore.com>

Oops, braino.  The previous version of this message used MEMBER when I
meant OR.  Here is a corrected version:

    Sorry for the late reply on this.
    
    The only problem with this proposal is that *BREAK-ON-SIGNALS* seems
    to implicitly depend on either:
    
        1. Having all condition types you want to control in one inheritance
           tree, or
    
        2. SUBTYPEP supporting OR type specifiers.
    
    For example, suppose you create a new subtype of CONDITION, disjoint
    from WARNING, called FROB, that does not break by default.  Now
    suppose you want to break on both WARNING and FROB, but not on another
    disjoint subtype of CONDITION, say BLAT.  The only way I can see to do
    this would be:
    
        (SETQ *BREAK-ON-SIGNALS* '(OR WARNING FROB))
    
    But this would presumably fail to work in an implementation that
    compilied minimally with SUBTYPEP-TOO-VAGUE.
    
    Of course, *BREAK-ON-WARNINGS* doesn't solve this problem, it just
    dodges the one occurance of it that involves standard condition types.
    

∂16-Mar-89  0831	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL (Version 9)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  08:31:50 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 08:27:48 PST
Date: 16 Mar 89 08:27 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
 message of Wed, 15 Mar 89 20:10:25 GMT
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: <890316-082748-3893@Xerox>

Does anyone at least have a record of the amendments that were proposed at
the last meeting. In lieu of a new version, we are probably obligated to
put version 9, as amended, on the table.


∂16-Mar-89  0917	CL-Cleanup-mailer 	Issue LOOP-AND-DISCREPANCY, version 1    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89  09:17:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558503; Thu 16-Mar-89 12:15:07 EST
Date: Thu, 16 Mar 89 12:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue LOOP-AND-DISCREPANCY, version 1
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8903151850.AA02865@verdi.think.com>
Message-ID: <19890316171508.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

I like LOOP-AND-DISCREPANCY:NO-REITERATION.

∂16-Mar-89  0932	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL (Version 9)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89  09:32:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558521; Thu 16-Mar-89 12:29:32 EST
Date: Thu, 16 Mar 89 12:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
To: masinter.pa@Xerox.COM
cc: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, cl-cleanup@sail.stanford.edu
In-Reply-To: <890316-082748-3893@Xerox>
Message-ID: <19890316172923.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 16 Mar 89 08:27 PST
    From: masinter.pa@Xerox.COM

    Does anyone at least have a record of the amendments that were proposed at
    the last meeting. In lieu of a new version, we are probably obligated to
    put version 9, as amended, on the table.

Maybe I shouldn't take this attitude, but I will anyway.  I have brief
notes on the amendments that were proposed, but since I think all of them
were wrongheaded and braindamaged, I'm not going to help anyone remember
them.  Only one of the amendments was actually voted on, so we're certainly
free to forget the other two.

∂16-Mar-89  1044	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL (Version 9)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  10:44:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 10:26:03 PST
Date: 16 Mar 89 10:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Thu, 16 Mar 89 12:29 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, Jeff Dalton
 <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, cl-cleanup@sail.stanford.edu
Message-ID: <890316-102603-4543@Xerox>

What I meant to ask was: what amendments actually passed? If none, then we
can just bring up version 9 again. I think we can certainly ignore
amendments that were were voted on and failed or did not come far enough to
get to a vote.

 


∂16-Mar-89  1115	CL-Cleanup-mailer 	Issue: GENSYM-NAME-STICKINESS, version 2 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  11:15:10 PST
Received: from fafnir.think.com by Think.COM; Thu, 16 Mar 89 13:52:43 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 16 Mar 89 13:53:38 EST
Received: by verdi.think.com; Thu, 16 Mar 89 13:50:26 EST
Date: Thu, 16 Mar 89 13:50:26 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903161850.AA04888@verdi.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: GLS@Think.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Thu, 16 Mar 89 09:44 EST <890316094401.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS, version 2

   Date: Thu, 16 Mar 89 09:44 EST
   From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>

   Can you motivate why you want a function rather than a variable
   for the counter control? For example, a useful feature of a
   variable would be to bind it. 

   My basic feeling is that if we need a function rather than variable,
   we must need the function for a reason. What is the function providing
   that is worth the added descriptive overhead and loss of (binding)
   flexibility but that is not stated in the writeup?

So that at the time the counter is changed I can convert it to
packed decimal on a VAX and use string instructions.

Seriously, I had in mind doing error-checking at counter-setting time
and thus avoiding questions of what happens when if you supply a bogus
counter value.

But if that is not worth it, then I will settle for a variable.
--Guy

∂16-Mar-89  1143	CL-Cleanup-mailer 	Re: DRAFT Issue: CONDITION-RESTARTS (Version 1)    
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89  11:42:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA02340; Thu, 16 Mar 89 12:39:36 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA05919; Thu, 16 Mar 89 12:39:34 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161939.AA05919@defun.utah.edu>
Date: Thu, 16 Mar 89 12:39:32 MST
Subject: Re: DRAFT Issue: CONDITION-RESTARTS (Version 1)
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM, 16 Mar 89 10:24 PST

This issue impacts the cl-compiler issue COMPILER-DIAGNOSTICS.  The
current proposal we have on that issue requires COMPILE-FILE to establish
a condition handler that resignals conditions.  Obviously we have a 
problem if resignalling is forbidden.

-Sandra
-------

∂16-Mar-89  1234	CL-Cleanup-mailer 	Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89  12:34:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558776; Thu 16-Mar-89 15:30:56 EST
Date: Thu, 16 Mar 89 15:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1) 
To: Dan L. Pierson <pierson@mist.encore.com>
cc: CL-CLEANUP@Sail.stanford.edu
In-Reply-To: <8903161622.AA07142@mist.>
Message-ID: <19890316203057.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 16 Mar 89 11:22:50 EST
    From: Dan L. Pierson <pierson@mist.encore.com>

    Oops, braino.  The previous version of this message used MEMBER when I
    meant OR.  Here is a corrected version:

	Sorry for the late reply on this.
    
	The only problem with this proposal is that *BREAK-ON-SIGNALS* seems
	to implicitly depend on either:
    
	    1. Having all condition types you want to control in one inheritance
	       tree, or
    
	    2. SUBTYPEP supporting OR type specifiers.
    
	For example, suppose you create a new subtype of CONDITION, disjoint
	from WARNING, called FROB, that does not break by default.  Now
	suppose you want to break on both WARNING and FROB, but not on another
	disjoint subtype of CONDITION, say BLAT.  The only way I can see to do
	this would be:
    
	    (SETQ *BREAK-ON-SIGNALS* '(OR WARNING FROB))
    
	But this would presumably fail to work in an implementation that
	compilied minimally with SUBTYPEP-TOO-VAGUE.
    
I don't believe this is a real problem, because the signaller has a
condition object in its hand, so it would be calling TYPEP, not SUBTYPEP.
TYPEP has no problems working with OR.

In fact SUBTYPEP has no problems working with OR as the second argument,
so you have also pointed out a bug in SUBTYPEP-TOO-VAGUE; it should not
allow SUBTYPEP to fail when just the second argument involves OR.  I think
this has been pointed out before.

∂16-Mar-89  1252	CL-Cleanup-mailer 	DEFAULT-CASE    
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 89  12:52:43 PST
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
	id AA18242; Thu, 16 Mar 89 12:24:16 -0800
Received: from frisky by franz (3.2/3.14)
	id AA21310; Thu, 16 Mar 89 12:23:04 PST
Received: by frisky (3.2/3.14)
	id AA08568; Thu, 16 Mar 89 12:21:59 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8903162021.AA08568@frisky>
To: franz!sail.stanford.edu!CL-Cleanup
Subject: DEFAULT-CASE
Date: Thu, 16 Mar 89 12:21:57 PST


    I brought up the issue of case-sensitive programming a few weeks
ago and there was no negative mail.   My message was part of the
discussion on the  READ-CASE-SENSITIVITY issue but in thinking it over
I believe that it makes more sense to look at what is needed to make
Common Lisp more useful in case-sensitive environments as two
separate things:  1. allow to the reader to be case-sensitive, and
2. make the names be lower-case by default.   Item 1 is already being
worked on, here is item 2:

						john foderaro
						franz inc.
						jkf%franz.uucp@berkeley.edu

	 

Issue:	DEFAULT-CASE
Forum:	Cleanup
References: CLtL p 334 ff: What the Read Function Accepts;
                especially p 337.
	    Issue: READ-CASE-SENSITIVITY
Category:   CHANGE
Edit History: 16-Mar-89, Version 1 by jkf

Problem Description:

    In most programming/operating-system environments where the case
    of names of functions, programs, identifiers, and files *does*
    matter, the case of most characters used for such purposes
    is lower case.   One example of such an environment is the Unix
    operating system.

    The resolution of the READ-CASE-SENSITIVITY will permit
    one to write case-sensitive Lisp code however since the 
    the case of characters in the print names of all standard
    functions and symbols is upper, this will make using
    the Lisp in a case-sensitive mode difficult.
    
Proposal (DEFAULT-CASE:LOWER)

    The case of all characters in the names of standard
    functions, symbols, and packages is lower.

Rationale:

    People running in a case-insensitive mode shouldn't care
    which case is the default case.

    People running in a case-sensitive mode care very much
    which case is default, and for most of these people
    lower case is preferred.

    Furthermore there are a large number of users
    of Lisp in case-sensitive environments and it is important
    that the desires of these users be met.

Current Practice:

    Franz Inc's Allegro Common Lisp supports a case-sensitive
    reader with either a upper-case default for names
    or a lower-case default.   A number of people use the
    case-sensitive feature with a lower-case default.  I don't
    know anyone that uses the lisp in a case-sensitive mode
    with an upper-case default.

Cost to Implementors:

    In case-insensitive mode, the cost to make characters downcase
    rather than upcase should be small.

    The cost of locating and fixing all of the places where
    the default case of symbol names actually matters will be moderate
    (I suspect that the older the Lisp the more numerous
    the instances of dependency on the case of the names).

Cost to Users:

    Again, the cost of locating and fixing all of the places where
    the default case of symbol names actually matters will be moderate.

    As an example, to find and fix all of the places in the PCL
    source (~15000 lines) that depend on the default case took
    me 15 minutes.

Cost of Non-Adoption:

    Using Lisp in case-sensitive environments will continue to be
    awkward.
    
    It will continue to be hard for Lisp to interact
    with programs written in case-sensitive languages (such as C).
    
    The use of case sensitivity as a tool for writing programs
    will continue to be unavailable to Lisp programmers.

    Vendors will invent their own methods of adding case-sensitivity,
    each in their own different way.
        
Benefits:

    See 'Cost of Non-Adoption'.

Aesthetics:

    Most Lisp books (including CLtL) put Lisp code in lower case.
    I believe that most people prefer to read text written in lower case.

    
Discussion:

    The best solution would be for there to be a way to make the
    reader case-sensitive (i.e. a resolution to the READ-CASE-SENSITIVITY
    issue) and for DEFAULT-CASE:LOWER to pass.  If for some
    reason the READ-CASE-SENSITIVITY should not be resolved in
    a manner that results in a case-sensitive reader option, it would
    still be good to pass DEFAULT-CASE:LOWER since that would
    bring Common Lisp one giant step closer to supporting the
    case-sensitive environment.

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

    
  
    

∂16-Mar-89  1318	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89  13:18:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558836; Thu 16-Mar-89 16:11:38 EST
Date: Thu, 16 Mar 89 16:11 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
To: Barry Margolin <barmar@FAFNIR.THINK.COM>
cc: masinter.pa@xerox.com, kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890315185842.5.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890316211129.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

I don't have the mail message you referred to ("I suggest that the text
Amemdment I from my 14 February mail be used verbatim as the proposal.").
However, I like the way you dealt with NCONC in version 5, I don't
see any need for a separate proposal.

Generally this looks okay.  I thought you were going to remove this:

 (NSUBSTITUTE new-object old-object sequence ...)
 (NSUBSTITUTE-IF new-object test sequence ...)
  when sequence is a list, is permitted to SETF any part, CAR or
   CDR, of the top-level list structure in that sequence.
  when sequence is an array is permitted to SETF the contents of
   any cell in that array which must be replaced by NEW-OBJECT.

since in fact there is no need to give NSUBSTITUTE the freedom
to modify anything more than what it is required to modify.  I
still think it should be removed, just as NSUBST was removed.

∂16-Mar-89  1338	CL-Cleanup-mailer 	Issue: ENVIRONMENT-ENQUIRY (not submitted)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  13:38:11 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 13:17:03 PST
Date: 16 Mar 89 13:16 PST
From: masinter.pa@Xerox.COM
Subject: Issue: ENVIRONMENT-ENQUIRY (not submitted)
To: cl-cleanup@sail.stanford.edu
Message-ID: <890316-131703-5387@Xerox>

I had this on my status list:

* ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
   value in consistent format across implementations. This makes
   them virtually useless. I would like to constrain the values
   enough so that implementors knew what to provide as return
   values, and provide some examples of intended uses."
Status: need volunteer to submit


I don't have much to say on this issue and cannot find message from which I
excerpted the quote. Who is the "I" here? Do you want to submit a proposal?

∂16-Mar-89  1338	CL-Cleanup-mailer 	Re: Issue EQUALP-GENERIC  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  13:38:24 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 13:23:03 PST
Date: 16 Mar 89 13:22 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue EQUALP-GENERIC
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Thu, 9 Mar 89
 23:11:34 PST
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: Moon@SCRC-STONY-BROOK.ARPA, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890316-132303-5408@Xerox>

I didn't think this was ready for release. Will there be a new version very soon?


∂16-Mar-89  1440	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL (Version 9)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89  14:40:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558955; Thu 16-Mar-89 17:36:38 EST
Date: Thu, 16 Mar 89 17:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
To: masinter.pa@Xerox.COM
cc: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, cl-cleanup@sail.stanford.edu
In-Reply-To: <890316-102603-4543@Xerox>
Message-ID: <19890316223630.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 16 Mar 89 10:02 PST
    From: masinter.pa@Xerox.COM

    What I meant to ask was: what amendments actually passed?

One amendment actually passed, but I'm still going to be a jerk and not
tell you what it was.  If someone wants to propose the same amendment
again, I don't think that will waste very much time.

∂16-Mar-89  1518	CL-Cleanup-mailer 	DEFAULT-CASE    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89  15:18:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559010; Thu 16-Mar-89 18:15:06 EST
Date: Thu, 16 Mar 89 18:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DEFAULT-CASE
To: John Foderaro <franz!frisky!jkf@ucbarpa.Berkeley.EDU>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8903162021.AA08568@frisky>
Message-ID: <19890316231500.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

  Proposal (DEFAULT-CASE:LOWER)

    The case of all characters in the names of standard
    functions, symbols, and packages is lower.

You're proposing a huge incompatible change that is bound to
get you into a religious war that can't do anyone any good.
I claim that this proposal addresses the internal representation
of programs but all you care about is the external representation.
I also claim that the choice of case in internal representation
is arbitrary and need not prejudice the external representation
at all.

If you believe what I just said, you would propose that the reader get
an option to flip case instead of up-casing when converting from
external representation to internal representation, and would propose
another value for *print-case* that does the inverse transformation.
This would be compatible with everybody, would make everybody happy
except for those who might insist that one internal representation
is better than the other, and hopefully would avoid spending a lot
of time on discussion.  What do you think?

∂16-Mar-89  1555	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)    
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  15:54:23 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 16 Mar 89 17:24:17 EST
Date: Thu, 16 Mar 89 17:22 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: masinter.pa@xerox.com, kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890316211129.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890316222229.3.BARMAR@OCCAM.THINK.COM>

    Date: Thu, 16 Mar 89 16:11 EST
    From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>

    I don't have the mail message you referred to ("I suggest that the text
    Amemdment I from my 14 February mail be used verbatim as the proposal.").
    However, I like the way you dealt with NCONC in version 5, I don't
    see any need for a separate proposal.

    Generally this looks okay.  I thought you were going to remove this:

     (NSUBSTITUTE new-object old-object sequence ...)
     (NSUBSTITUTE-IF new-object test sequence ...)
      when sequence is a list, is permitted to SETF any part, CAR or
       CDR, of the top-level list structure in that sequence.
      when sequence is an array is permitted to SETF the contents of
       any cell in that array which must be replaced by NEW-OBJECT.

    since in fact there is no need to give NSUBSTITUTE the freedom
    to modify anything more than what it is required to modify.  I
    still think it should be removed, just as NSUBST was removed.

I think I remember my reason (it's been a month since I wrote the
amendment).  I removed NSUBST because CLtL was already very specific
about what it does.  CLtL's description of NSUBSTITUTE isn't very
specific; removing it from the proposal would just leave it implicitly
vague instead of making it explicitly vague, and I'd prefer to be
explicit.

I would support a version that makes NSUBSTITUTE* be explicitly
specific.  I see no reason not to require it to use SETF of CAR or AREF,
as appropriate.  Unless someone is working on CAR-coding, I don't think
it precludes any known optimizations.

                                                barmar

∂16-Mar-89  1605	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89  16:05:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559069; Thu 16-Mar-89 19:02:17 EST
Date: Thu, 16 Mar 89 19:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
To: Barry Margolin <barmar@Think.COM>
cc: masinter.pa@xerox.com, kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890316222229.3.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890317000217.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Thu, 16 Mar 89 17:22 EST
    From: Barry Margolin <barmar@Think.COM>

	Date: Thu, 16 Mar 89 16:11 EST
	From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>

	I don't have the mail message you referred to ("I suggest that the text
	Amemdment I from my 14 February mail be used verbatim as the proposal.").
	However, I like the way you dealt with NCONC in version 5, I don't
	see any need for a separate proposal.

	Generally this looks okay.  I thought you were going to remove this:

	 (NSUBSTITUTE new-object old-object sequence ...)
	 (NSUBSTITUTE-IF new-object test sequence ...)
	  when sequence is a list, is permitted to SETF any part, CAR or
	   CDR, of the top-level list structure in that sequence.
	  when sequence is an array is permitted to SETF the contents of
	   any cell in that array which must be replaced by NEW-OBJECT.

	since in fact there is no need to give NSUBSTITUTE the freedom
	to modify anything more than what it is required to modify.  I
	still think it should be removed, just as NSUBST was removed.

    I think I remember my reason (it's been a month since I wrote the
    amendment).  I removed NSUBST because CLtL was already very specific
    about what it does.  CLtL's description of NSUBSTITUTE isn't very
    specific; removing it from the proposal would just leave it implicitly
    vague instead of making it explicitly vague, and I'd prefer to be
    explicit.

I see.

    I would support a version that makes NSUBSTITUTE* be explicitly
    specific.  I see no reason not to require it to use SETF of CAR or AREF,
    as appropriate.  Unless someone is working on CAR-coding, I don't think
    it precludes any known optimizations.

I'd support that too.  In other words, describe NSUBSTITUTE with language
similar to the description of NSUBST.

∂16-Mar-89  1802	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED, v.5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  18:02:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 17:54:51 PST
Date: 16 Mar 89 17:40 PST
From: masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
Subject: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
Message-ID: <890316-175451-6328@Xerox>

I think Guy missed a couple of the amendments that passed
at the last meeting. This is what I started to send out
to X3J13, but since I've tried to "patch" the wording a bit
since it seems that some of the constraints put on TYPE-OF
by this proposal are overlapping, I thought I would send
it to cl-cleanup first. (Since this was raised at the last
meeting, there's not a problem about the 'two-week' rule,
I think.)


Version 3 of this proposal was raised at the January 1989
X3J13, and passed with three amendments:

a) add RANDOM-STATE to the list of types
b) add the requirement that TYPE-OF is a subtype of CLASS-OF
c) change the relation to CLOS to say
 "for all objects
  for which CLASS-OF returns a class with a proper name, TYPE-OF returns
  that proper name."

It was noted that SHORT-FLOAT, LONG-FLOAT and RATIONAL were 
omitted inadvertently. We would like to ask that the proposal
be reconsidered so that these types could also be included.
This version includes those amendments, and also
adds SHORT-FLOAT, LONG-FLOAT, and RATIONAL
to the list of types in part (a) of the proposal.



!
Forum:	Cleanup
Issue:      TYPE-OF-UNDERCONSTRAINED

References: TYPE-OF (CLtL)
            88-002R (Class-of)
            88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
                DATA-TYPE-HIERARCHY-UNDERSPECIFIED
                FUNCTION-TYPE
                ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
                COERCE-INCOMPLETE
			

Category:       CLARIFICATION/CHANGE

Edit history:   Version 1,  1-Dec-88, Masinter
		    Version 2,  9-Dec-88, Masinter
		    Version 3, 12-Dec-88, Masinter (fix "egregious bug")
		Version 4, 3-14-89 Steele
		Version 5, 16-Mar-89, Masinter (add other amendments)

Problem description:

The specification of TYPE-OF in CLtL is so weak as to leave it 
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.

This means that implementations could return T for all other objects.

Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS): 

Specify that the result of TYPE-OF satisfies the following:

(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of 

INTEGER, RATIO, FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, COMPLEX, NUMBER,
SYMBOL, 
STRING, VECTOR, ARRAY, RANDOM-STATE,
CONS, 
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
RATIONAL, SHORT-FLOAT, LONG-FLOAT

the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the 
implementation's SUBTYPEP can recognize.)

(b)  For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)

(c) will not be a MEMBER type specifier, or T.

The type returned by TYPE-OF is always a subtype of the class
returned by CLASS-OF.

For all objects for which CLASS-OF returns a class with a proper name,
TYPE-OF returns that proper name.

In particular, for objects created by the "constructor" function
of a structure defined with DEFSTRUCT without a :TYPE option,
TYPE-OF will return the structure name.

For all objects for which (CLASS-NAME (CLASS-OF object)) is NIL),
the result of TYPE-OF will return the class object itself.

(The CLOS specification has already specified that class objects are
acceptable wherever type specifiers are, and in particular, as input to
SUBTYPEP and TYPEP.)

This proposal is intended to be consistent with 88-002R, 
and not to conflict with any of the definitions in that document.

Examples:

It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).

 Given:

   (defvar *foo* (make-array 5 :element-type t))
   (class-name (class-of *foo*))  =>  SIMPLE-VECTOR
  It is legal for
   (type-of *foo*)                =>  (SIMPLE-VECTOR 5)


Rationale:

The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended. 

Current practice:

Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.

Cost to Implementors:

Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal. 

Cost to Users:

Apparently none.

Cost of non-adoption:

TYPE-OF would remain potentially inconsistent.

Performance impact:

Likely none.

Benefits:

Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.

Esthetics:

Little effect.

Discussion:

Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.

The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did. 

This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.

If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass, 
and this proposal does pass, it may be that the only way an 
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.

It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable 
implementation-specific value. For example, 
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]

We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.



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

∂16-Mar-89  2116	CL-Cleanup-mailer 	Re: Issue: EXPT-ZERO-ZERO (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  21:16:33 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 21:10:42 PST
Date: 16 Mar 89 21:10 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXPT-ZERO-ZERO (Version 1)
To: KMP@symbolics.com, CL-Cleanup@sail.stanford.edu,
 Cyphers@jasper.scrc.symbolics.com
Message-ID: <890316-211042-6708@Xerox>

Kent, do you want to proceed with this one? I don't think it is necessary
or even a good idea. What do other programming languages do? 

If you do, I think we should leave (EXPT 0 0) = 1 and (EXPT 0.0 0) = 1 and
only deal with (EXPT 0.0 0.0) and (EXPT 0 0.0). 

Doesn't this fit into the ERRORS-IN-NUMBERS-CHAPTER spectrum?

∂16-Mar-89  2212	CL-Cleanup-mailer 	Issue: FIXNUM-NON-PORTABLE, v.5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  22:11:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 22:09:33 PST
Date: 16 Mar 89 21:51 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: FIXNUM-NON-PORTABLE, v.5
line-fold: NO
Message-ID: <890316-220933-6804@Xerox>

This is my rewrite to capture the 'intent' of the amendment
at the January X3J13. I say 'intent' because the relation
between MOST-POSITIVE-FIXNUM (which is an inclusive bound)
and ARRAY-DIMENSION-LIMIT (which is an exclusive bound) is not
> but rather (>= MOST-POSITIVE-FIXNUM (1- ARRAY-DIMENSION-LIMIT)).


A minor nit. I wonder if we need to bring copies of the issues
that were passed at the last meeting for the 'approval of
the minutes' part.

!
Status: Passed Jan 89 X3J13, as amended
Issue: FIXNUM-NON-PORTABLE
References:	CLtL p. 14, 34, 43, 231
Category:	CHANGE, CLARIFICATION

Edit History:   Version 1, 11-Jul-88, Sandra Loosemore
		    Version 2, 15-Sep-88, Masinter
		    Version 3, 23-Sep-88, Masinter
		    Version 4,  7-Dec-88, Masinter (two proposals)
		    Version 5, 16-Mar-89, Masinter (incorporate amendments)

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

While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges.  The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.

CLtL p14 and p34 disagree about BIGNUM. One says that
 FIXNUM and BIGNUM are an exhaustive partition of the
integer space, the other says they might not be!

Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION

(1) Change the description of the type FIXNUM to reflect that it is
 required to be a supertype of (SIGNED-BYTE 16).

(2) Define BIGNUM to be exactly (AND INTEGER (NOT FIXNUM))

(3) require that MOST-POSITIVE-FIXNUM be large enough
  to hold all array indices, i.e.,
	(>= MOST-POSITIVE-FIXNUM (1- ARRAY-DIMENSION-LIMIT))

Example:

Consider an implementation with three numeric representations:

	Fast                (INTEGER -1024 1023)
	Immediate           29 bits
	Extended            Multi-precision

Such an implementation would have to define
FIXNUM to be (OR Fast Immediate). BIGNUM
would then refer to multi-precision integers. 

Rationale:

Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable. 

However, there is little portable use for the type BIGNUM, and it
is inconsistent with many current implementation techniques.
Removing it is an incompatible change for a weak reason.

Current Practice:

Xerox Common Lisp has 17-bit fixnums.  Most other Common Lisp
 implementations have  fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum 
size.

Several existing Common Lisp implementations have more than two 
representations for integers, such that the FIXNUM/BIGNUM distinction
is confusing; they define BIGNUM to cover all of the larger number
types.

Cost to implementors:

Slight.  All implementations we know of already define FIXNUMs to be at
least 16 bits.

Cost to users:

Slight.  

Benefits:

The FIXNUM type specifier would have a portable interpretation.

The language would be less confusing.

Discussion:

There was little consensus on whether to leave BIGNUM in the language.

Earlier discussion of a related proposal contained several other more controversial
components (adding a constant MAX-INTEGER-LENGTH, allowing 
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree on.

It is possible that an implementation have a single  representation for all
integers, and no way to identify any efficient range of integers. Those
implementations might need to set MOST-POSITIVE-FIXNUM
 and MOST-NEGATIVE-FIXNUM to arbitrary values, consistent with 
the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM.

Other alternatives considered (and not necessarily mutually exclusive
with this proposal):

  remove the FIXNUM type specifier entirely, while leaving a way
  to query what is the most efficient range of integers

   leave the range of FIXNUMs unconstrained  and introduce a 
   SMALL-INTEGER type with a fixed range (but no promises about
   efficiency) . 

It might be possible to specify the required performance behavior
of FIXNUMs more concretely, e.g., specify 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. This might be a useful way to describe
the intent of the FIXNUM range, if not its specification.

∂16-Mar-89  2253	CL-Cleanup-mailer 	Re: DEFAULT-CASE     
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 89  22:53:03 PST
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
	id AA29249; Thu, 16 Mar 89 22:20:22 -0800
Received: from frisky by franz (3.2/3.14)
	id AA22529; Thu, 16 Mar 89 21:39:21 PST
Received: by frisky (3.2/3.14)
	id AA09727; Thu, 16 Mar 89 21:38:16 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8903170538.AA09727@frisky>
To: David A. Moon <franz!ucbarpa!STONY-BROOK.SCRC.Symbolics.COM!Moon>
Cc: franz!sail.stanford.edu!CL-Cleanup
Subject: Re: DEFAULT-CASE 
In-Reply-To: Your message of Thu, 16 Mar 89 18:15:00 EST.
             <19890316231500.7.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Thu, 16 Mar 89 21:38:14 PST

 I'm not trying to start a religious war.  I'm not saying that
case-sensitive is better or worse than case-insensitive.   I'm just
saying that there are large numbers of people who favor each position
and that Common Lisp should support both.    

  Regarding internal vrs external:  The internal representation shows
through in a number of places.   For example the functions symbol-name
and make-symbol let the user deal with the actual internal
representation of the names of symbols.   The idea of having a
*print-case* value that inverts the case on output is interesting but 
that would make things awkward:  To make the symbol FooBar you 
would have to (make-symbol "fOObAR").   Also examining the characters
of a print-name with aref would give confusing results.  

>> I also claim that the choice of case in internal representation
>> is arbitrary and need not prejudice the external representation
>> at all.

 For a case-insensitive Lisp I completely agree.  For a case-sensitive
Lisp, as I've shown above, this just isn't true.   Thus if the needs
of the case-sensitive Lisp are met, then the needs of both are met.

 

-john foderaro


[it might be interesting to explore the possiblity of explicitly
stating that the internal representation of print-names was undefined
with respect to case, and further providing two new functions: one
which took a string and converted it to the internal representation
just as the reader would do and the other which took a symbol-name 
and converted it to a string just as the printer would do.  
I suspect that this would lead to programs that worked on a few
Common Lisps but failed on others due to accidental reliance on the
actual case of the printnames. ]

∂16-Mar-89  2310	CL-Cleanup-mailer 	Re: Issue: IN-SYNTAX (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89  23:10:33 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 23:05:56 PST
Date: 16 Mar 89 23:05 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: IN-SYNTAX (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Fri, 21 Oct 88 14:01 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890316-230556-6907@Xerox>

The discussion of this Issue quickly evolved into a discussion of the
default environment for LOAD. I don't see much in the way of the discussion
of the issue itself except "far too narrowly focused."

Under the circumstances -- and given that I'm not that thrilled by adding
Yet Another Puppy that We Aren't Sure We Need -- can we drop this?

∂17-Mar-89  0009	CL-Cleanup-mailer 	Cleanup Issue Status List 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  00:09:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 23:57:10 PST
Date: 16 Mar 89 23:56 PST
From: masinter.pa@Xerox.COM
cc: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Cleanup Issue Status List
Message-ID: <890316-235710-7002@Xerox>

I'm out of steam and only in the middle of the alphabet. I'll try to slug
through M-Z tomorrow. I'm travelling or unavailable most of next week, and
so this has to get done now.


! ready for vote
+ passed
!+: passed, but up for reconsideration
 - withdrawn, failed, etc.
* pending, passed but need version as amended, etc.

+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988

+ ADJUST-ARRAY-FILL-POINTER
 Version 1, 15-MAR-88
Status: passed, 1988

! ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments:  amendment had wording problem.
Version 8, 11-Mar-89, Released 15-Mar-89
Status: ready for vote 

- ALIST-NIL
Version 4, 1-Oct-88
Status: Withdrawn, recommend editorial

- APPEND-ATOM
Synopsis: atom case of APPEND (left out of APPEND-DOTTED)
Version 1, 6-Dec-88, Released 12-Jan-89
Status: withdrawn 18-Jan-89 because APPEND-DOTTED withdrawn

- APPEND-DOTTED
14-JAN-88, Version 5
Status: Passed Nov 88 X3J13, reconsidered & withdrawn Jan 89 X3J13

+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13

+ AREF-1D
14-NOV-87, Version 7
Status: Passed, 1988?

+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13

+ AREF-1D
Version 7, 14-NOV-87
Status: Passed, 1988?

+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13

+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?

- BACKQUOTE-COMMA-ATSIGN-DOT
Synopsis:  `(... ,@x) vs `(... . ,x). Same, different, is error?
Version 1, 22-Dec-88, DRAFT released
Comments: proposals INTERCHANGABLE and DIVERGENT comments not in writeup 
Status: Withdrawn, since APPEND-DOTTED withdrawn. Default is IS ERROR

! BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Comment: leaves out a case
Status: ready for vote

! CLOS-CONDITIONS
Version 4, 10-Mar-89
Comments: define metaclass of conditions? 
Status: pending

+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13

!+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at meeting
Version 7, 14-Feb-89
Status: Passed, as amended, Jan 89 X3J13
Comment: amendment bad; reconsider version 5?
	amend 5 to say that INPUT-STREAM-P and OUTPUT-STREAM-P
	are undefined on closed streams?

! COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: ready for voting

+ COLON-NUMBER
Synopsis:  :123 is an error
22-OCT-87, Version 1
Status: Passed, 1988?

+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988?

+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13

! CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: vote w/amendments or new version

+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13

! COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: ready for vote

! COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: ready for vote

+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
4-SEP-88 Version 2
Status: Passed, 1988?

+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13

+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89
Status: passed, Jan 89 X3J13
kc: amended?

+ DECLARE-FUNCTION-AMBIGUITY
Version 4,  5-Dec-88, Released  5-Dec-88
Status: passed, Jan 89 X3J13

+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13

+ DECLARE-MACROS
5-FEB-88, Version 3
Status: Passed, 1988?

- DECLARE-TYPE-USER-DEFINED
Synopsis: allow (declare ((signed-byte 8) x y z)) for all type specifiers?
Status: Withdrawn (never submitted)

+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13

- DEFINITION-DELETE
Synopsis: provide a way to get rid of structures, etc. 
Status: not submitted

* DEFMACRO-LAMBDA-LIST
Version 1, 30-Jan-89
Status: *** NEED NEW VERSION ***

+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13

- DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
Synopsis: defstruct accessors are proclaimed inline
Version 2,  7-Jan-89, released 10-Jan-89
Status: rejected, Jan 89 X3J13 

+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 3, 6-Feb-89
Status: Passed (as amended) Jan 89 X3J13

+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13

+ DEFVAR-DOCUMENTATION
23-NOV-87, Version 2
Status: Passed, 1988?

+ DEFVAR-INIT-TIME
29-MAR-87, Version 2
Status: Passed, 1988?

+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988?

- DELETE-FILE-NONEXISTENT 
Version 1, 5-Oct-88
Comments: should just signal different errors? 
Status: withdrawn/tabled?

+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13

! DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
status: ready for vote

!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Status: might need new version before vote

+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988

+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988?

+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13

+ DRIBBLE-TECHNIQUE
14-FEB-88, Version 2
Status: Passed, 1988?

! DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Comments: still some holes
Status: ready for vote?

- ELIMINATE-FORCED-CONSING
Synopsis: Add :RECYCLE or :MODIFY to some sequence fns,
Version 3, 31-Aug-88
Status: withdrawn

- ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
   value in consistent format across implementations. This makes
   them virtually useless. I would like to constrain the values
   enough so that implementors knew what to provide as return
   values, and provide some examples of intended uses."
Status: no volunteer to submit

+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Status: Passed with amendments
Version 7, 15-Mar-89
Status: Passed Jan 89 X3J13 as amended.

* EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Comments: Various problems being worked on
Status: ** NEED NEW VERSION ***

* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: in progress, "endorse in principle"?

! ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: ready for vote

+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?

! EXIT-EXTENT
Version 6,  8-Jan-89, distributed at Jan89 X3J13
Rereleased 16-Mar-89
Status: tabled Jan89; ready for vote

+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13

* EXPT-ZERO-ZERO
Synopsis: (EXPT 0.0 0.0) should be undefined
Version 1, 27-Feb-89
Status: need new version?

- FILE-LENGTH-PATHNAME 
Synopsis: extend FILE-LENGTH to work on pathnames
Status: not submitted/ withdrawn

* FILE-WRITE-DATE-IF-NOT-EXISTS
Synopsis: What does FILE-WRITE-DATE do if no such file?
Version: no proposal
Status:  => ERRORS-IN-FILE-SYSTEM-CHAPTER????

+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Status: Accepted with amendment
Version 5, 16-Mar-89, "as amended"
Comment: minor off-by-one in amendment
Status: voice approval for off-by-one?

+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988?

+ FLET-IMPLICIT-BLOCK
Version 6 5-JUN-87
Status: Passed, 1988?

- FOLLOW-SYNONYM-STREAM
Comment: lost in STREAM-ACCESS.
Status: Withdrawn?

+ FORMAT-ATSIGN-COLON
Version 4 5-JUN-87
Status: Passed, 1988?

+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988?

+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988?

+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13

+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988?

- FORMAT-NEGATIVE-PARAMETERS
Synopsis: What does FORMAT do when it gets negative numbers for count?
Version: No proposal
Comment: KMP will incorporate in the list-of-signals part of the signal
proposal?
Status: not submitted

* FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: no proposal

+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13

- FORMAT-ROUNDING
Synopsis: specify that ~F rounds up
Version 1, 5-Oct-88
Status: withdrawn

* FUNCTION-ARGUMENT-LIST
Synopsis: want way to get argument list
Status: not submitted

+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988

! FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: vote?

+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89 
Status: Passed (as amended) Jan 89 X3J13?
Status: maybe this was passed as amendment to TEST-NOT-IF-NOT instead
	but in either case, we have the content.

+ FUNCTION-DEFINITION
Version 3, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13

+ FUNCTION-TYPE
4-SEP-88, Version 12
Status: Passed, 1988

+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released  12-Dec-88
Status: Passed, Jan 89 X3J13

+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88 
Status: Passed, 1988

+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13

- GCD-NO-ARGUMENTS
Synopsis: make (GCD) undefined
Status: not submitted

*! GENSYM-NAME-STICKINESS
Version 1, 14-Feb-89, Released 14-Mar-89
Synopsis: no side effects if optional arg supplied
Status: need new version

- GET-MACRO-CHARACTER-DISPATCHING
Synopsis: What does GET-MACRO-CHARACTER return for dispatching macros?
Status: not submitted

+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89
Status: Passed (as amended) Jan 89 X3J13

+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988?

! HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88, released 16-Mar-89
status: vote 

- HASH-TABLE-GC
Synopsis: allow hash tables with GCable keys
Status: no proposal

+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
 from the generator in  the wrong order.
Status: passed, Jan 89 X3J13

* HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal

- HASH-TABLE-STABILITY
Version 1, 11-Nov-88, Released 12 Dec 88
Comments: superceded HASH-TABLE-KEY-MODIFICATION
Status: Rejected Jan 89 X3J13

+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 8 8
Status: passed Jan 89 X3J13

+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13

* IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89

+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5 ??-MAY-87
Status: Passed, 1988?

! IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Status: tabled
Version 8, 15-Mar-89, Released 15-Mar-89
Status: ready for vote

- IN-SYNTAX
Synopsis: like IN-PACKAGE but for readtables
Version 1, 21-Oct-88
Comments: important issue: default environment for LOAD
Status: can we withdraw?

- INPUT-STREAM-P-CLOSED
Synopsis: What do INPUT-STREAM-P and OUTPUT-STREAM-P do on closed streams?
Status: not submitted

- INPUT-STREAM-P-EXAMPLE
Synopsis: (input-stream-p (make-broadcast-stream)) is NIL
Version 1, 26-Oct-88
Status: bug report, needs no clarification?

+ KEYWORD-ARGUMENT-NAME-PACKAGE
8-NOV-87, Version 8
Status: Passed, 1988?

- LAMBDA-FORM
Version 4, 22-Nov-88, Released 8-Dec-88
Status: rejected, Jan 89 X3J13

+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?

+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13

- LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION 
Synopsis: should LEAST-POSITIVE- and MOST-POSITIVE-XXX-FLOAT
   numbers include denormalized ones in those implementations
   that admit them?
Status: Not submitted

! LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: tabled; version 1 still ready for vote

! LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Comments: Don't like (DEFVAR CAR ...) example
	14: Like simpler "Redefining any documented
  definition on a symbol in the LISP package -- such as variables, 
  functions, constants, properties and property-lists, etc -- is
  undefined, except for the explicitly allowed cases (e.g. dynamic
  binding of variables)."
Status: tabled; version 5 still ready for vote

- LIST-TYPE-SPECIFIER
Synopsis: add a type specifier (LIST NUMBER)
Version 1, 28 Jun 88
Status: withdrawn

! LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled
files
Version 3, 9-Mar-89, released 16-Mar-89
Status: ready for vote?

! LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote

! LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: ready for vote

+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988

* MACRO-SPECIAL-FORMS
Synopsis: macros expanding to implementation-dependent special forms
doesn't work
Status: not yet submitted

- MAKE-CONCATENATED-STREAM-EXAMPLE
Synopsis: (read (make-concatenated-stream (make-string-input-stream "1")
(make-string-input-stream "2"))) => 12?
Version 1, 26-Oct-88
Status: withdrawn, no issue (bug report to one implementation)

+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended 

! MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: vote?

+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13

* NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comments: Accepted (9 to 7), with amendment to clarify what happens if n is
out of range
Status: need new version as amended

- OUTPUT-STREAM-P-EXAMPLE
Synopsis: Clarify (output-stream-p (make-concatenated-stream)) is NIL?
Version 1, 26-Oct-88
Comment: already clear; just bug report for one implementation

* PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment that the forbidden property indicators
are
	   external symbols in all packages defined by this standard plus all
           symbols accessible in the USER package or in packages defined by
           the user.
Status: need writeup as amended

+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Comments: Minor glitches? Remove the description of "correctable" error to
be signalled and
handled.
Status: passed, Jan 89 X3J13

* PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: Accepted MORE-PERMISSIVE (v2), as amended
           ----- Moon 21-Jan-89 (Version 2) -----
           MORE-PERMISSIVE is like PERMISSIVE except that the four
functions
           identified by CLtL as "package structure accessors" that don't
allow
           names are changed to allow names.  
           Amendments made at the meeting added DELETE-PACKAGE and
DEFPACKAGE
           to the list of functions and removed the paragraph beginning
           with the words "If IN-PACKAGE...".
Status: need new version as amended

* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME;
	require PATHNAME-TYPE to return same?
Version 1, 07-Jul-88
Comments: only add the :TYPE :SOURCE-LISP, not PATHNAME-CANONICAL-TYPE?
Status: => "pathname" committee?

* PATHNAME-COMPONENT-CASE
Synopsis: allow ALL UPPER CASE to mean "use the 'right' case
Comments: lots of heat?
Status: => "pathname" committee

* PATHNAME-EXTENSIONS
Synopsis: allow a way of telling whether a pathname is a pattern, a "funny"
file
Comments: necessary in standard?
Status: => "pathname" committee

* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet

* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous, pro, con. Print like #S(pathname ...)?
Status: need new version

+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988?

+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988?

* PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Version 3, 29-Dec-88
Comments: typos and proposed simplifications
Status: need new version

* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88
Comments: various
Status: need new version

- PATHNAME-TYPE-UNSPECIFIC
Version 1 27-Jun-88, Released 7 Oct 88
Comments: may be subsumed
Status:  withdrawn; superceded by PATHNAME-UNSPECIFIC-COMPONENT

*  PATHNAME-UNSPECIFIC-COMPONENT
Version 1, 29-Dec-88, Released 12-Jan-89
Synopsis: More extensions to :UNSPECIFIC
Comment: Accepted (14 to 4), with amendments to allow any field to be
           :UNSPECIFIC including host and name, and to say that "To use
	   :UNSPECIFIC in an operating system for which it does not make
           sense, the results are undefined."
           ----- Moon 21-Jan-89 -----
           RWK pointed out that :UNSPECIFIC has two meanings: the component
           is omitted in this particular pathname (type in Unix) or the
           component is not meaningful for this system (version in Unix).
           Cross-host defaulting needs to treat those differently, so
           :UNSPECIFIC can't get into a field where it is not allowed.
           In the end RWK suggested people should vote for the proposal
	   anyway, as it was a net improvement.
Status: needs new version as amended

* PATHNAME-WILD
Version 2, 6-Oct-88
Synopsis: Portable way to ask about "wildcard" pathnames?
Comments: consistent with PATHNAME-COMPONENT-CASE?
Status: => "pathname" committee

+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis:  PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13

+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?

* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted

* PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment to apply to methods on PRINT-OBJECT in
           addition to :PRINT-FUNCTION options
Status: need new version as amended

* PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: tabled, *** NEED NEW VERSION ***

+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988?

+ RANGE-OF-COUNT-KEYWORD
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13

+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Status: ready for release???

* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission

! REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Status: vote?

+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988?

* REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 2, 29-Oct-87, Released 8-Oct-88
Version 4, 29-Nov-88, Released 12-Jan-89
Status: There was a straw vote in favor of this, then BarMar was appointed
           to make some amendments and put it on the letter ballot.  I
think the
	   amendments are to tighten up NCONC and remove NBUTLAST, NSUBSTx,
	   and NSUBSTITUTEx.

- REMF-MULTIPLE 
Synopsis: What does REMF do if it sees more than one INDICATOR?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: withdrawn ("only applies in 'cannot happen' situation")

+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13

+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13

- REST-LIST-EXTENT
Synopsis: allow way to declare dynamic extent &REST
Comment: superseded by DYNAMIC-EXTENT
Status: withdrawn

+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released  9-Dec-88
Status: passed, Jan 89 X3J13

+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13

- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Version 6, 06-Oct-88, Released 11-Jan-89
Comments: New version scales down previously rejected version
Status: Version 6 rejected Jan 89 X3J13

! SETF-FUNCTION-VS-MACRO, SETF-PLACES, FUNCTION-NAME
Comment: either renaming or separate proposals, depending 
	on your point of view
SETF-FUNCTION-VS-MACRO
Version 3, 4-Nov-87, Released Nov 87
SETF-PLACES
Version 1, 11-Nov-88, Released 9-Dec-88
FUNCTION-NAME
Version 1, 27-Jan-89, Released 16-Mar-89
Status: ready for vote

* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 1, 5-Dec-88
Status: awaiting new version

+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...) 
Status: passed, Jan 89 X3J13

+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?

+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?

* SINGLE-FLOAT-NON-PORTABLE
Synopsis: remove SINGLE-FLOAT, DOUBLE-FLOAT a la FIXNUM?
Status: Not submitted

+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13

SPECIAL-VARIABLE-TEST
Synopsis: Add SPECIAL-VARIABLE-P?
Version 2, 31-May-88
Status: "On hold pending SYNTACTIC-ENVIRONMENT-ACCESS"

+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

* STANDARD-VALUE
Synopsis: user can say binding is "temporary" 
Version 1, 21-Oct-88
Comments: not worth trying to standardize now?
Status: ready for release?

* STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released  7 Oct 88
Comments: Passed, Jan 89.
		Verbally this was explained to mean that the body of the STEP would
           not be stepped when compiled, but if it just happened to call an
           interpreted function, that function would get stepped.  Also the
           word "evaluation" in that sentence was amended to "computation."
Status: need new version as amended

+ STREAM-ACCESS
Version 2, 30-Nov-88, Released  9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13

* STREAM-CAPABILITIES
Version 1, 7/5/88
Synopsis: SAME-SOURCE-P, SAME-DESTINATION-P, etc
Status: awaiting new version, from "pathname/file" committee?

* STREAM-DEFINITION-BY-USER
Synopsis: Want user-definable stream types.
Status: not submitted

* STREAM-ELEMENT-TYPE-EXAMPLES
Version 1, 26-Oct-88
Synopsis: clarify STREAM-ELEMENT-TYPE may return different values?
Status: editorial? Need new proposal?

- STREAM-INFO
Version 6, 30-Nov-88, Released 9 dec 88
Status: Rejected, Jan 89 X3J13

+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2 
Status: Passed, 1988?

* SUBTYPEP-ENVIRONMENT

SUBTYPEP-EMPTY-NIL
Version 1
Status: => editorial, no cleanup needed

+ SUBTYPEP-TOO-VAGUE
Version 4,  7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

* SYMBOL-MACROFLET
Version 1, 30 Sep 88
Synopsis: Add SYMBOL-MACROFLET gives lexical function expansion
Status: need new version

+ SYMBOL-MACROLET-DECLARE
Version 2,  9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13

!+ SYMBOL-MACROLET-SEMANTICS
Version 5, 30-Nov-88, Released 9 Dec 88
Status: Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: ready for vote

- TAGBODY-CONTENTS
Version 5, 9-Dec-88, Released 9 Dec 88
Comments: "good that this failed, but we still need a clarification"
Status: Failed, Jan 89 X3J13

+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13

* TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec 
Comments: passed, Jan 89 X3J13 FLUSH-ALL, amended to deprecate instead of
removing
Status: Need new version as amended.

* THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: tabled

! TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote

- TRACE-ERROR
Synopsis: TRACE should signal errors if it doesn't understand
Version 1, 20-Jun-88
Comments: is this a cleanup?
Status: withdrawn

- TRACE-FUNCTION-ONLY
Synopsis: extend TRACE to handle other specs
Comment: we don't like it
Status: withdrawn

* TRUENAME-SYNTAX-ONLY
Version 1, 12-Sep-88
Synopsis: when does TRUENAME perform checking?
Comments: other options? leave more vague? Other questions?
Status: need new version => "pathname" committee

+* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Status: Ready for release?

Status: need new version as amended

* TYPE-SPECIFIER-PREDICATE
Synopsis: "Add a new function TYPE-SPECIFIER-P that is true of valid type
   specifiers and false of all other Lisp objects.  Note that the use of
   DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
   time."
Comments: considerable discussion on common lisp mailing list.
Status: Not yet submitted

* UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: Lumping SLOT-UNBOUND in with unbound special variables was a
mistake,
           as SLOT-UNBOUND is an extension mechanism, not only a safety
checking
           mechanism.  Also there were some wording problems.  Gabriel and
Gregor
           are to submit a revised proposal.
Status: pending

+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13

+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13

+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88 
Status: Passed, 1988?



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


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


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


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


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


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


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

∂17-Mar-89  0823	CL-Cleanup-mailer 	Re: DEFAULT-CASE     
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89  08:23:49 PST
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 17 Mar 89 11:19:44 EST
To: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
cc: cl-cleanup@sail.stanford.edu
Subject: Re: DEFAULT-CASE 
In-reply-to: Your message of Thu, 16 Mar 89 21:38:14 -0800.
             <8903170538.AA09727@frisky> 
Date: Fri, 17 Mar 89 11:19:37 EST
From: Scott.Fahlman@B.GP.CS.CMU.EDU


     I'm not trying to start a religious war.  I'm not saying that
    case-sensitive is better or worse than case-insensitive.   I'm just
    saying that there are large numbers of people who favor each position
    and that Common Lisp should support both.    
    
I'm trying to stay out of most cleanup discussions these days, but feel
compelled to say something about this one, especially since John indicated
that he was reading silence as non-disagreement.

The argument here is that we should make it easy for those people who
prefer case-sensitivity to write their code that way and for those who like
case-insensitivity (with symbols being bashed into some canonical case) to
write their code that way.  I think that this is a recipe for consfusion
and major portability problems.  As soon as there is code around that
assumes case sensitivity, anyone who wants to use that code in conjuction
with code of his own has to go along with case sensitivity.  Attempts to
mix the two styles will break.  It would be like the old days when half the
Lisp world used octal and the other half used decimal.  So if this measure
is adopted, it won't be a matter of "freedom of choice".  We'll either have
two incompatible software words within Common Lisp, or it will drag us all
through a major incompatible change we don't want.

I think we have to choose one style or the other for code if portability is
to be maintained.  For better or for worse, we made that choice in favor of
a case-bashing convention.  I don't think I'd favor the same choice again
if compatibility with the past were not an issue, but I don't think we can
make such a sweeping incompatible change now.  And we can't straddle the
fence.

I've got no problem with a proposal that would allow the Common Lisp reader
to go into some non-case-smashing mode.  This would be useful when the
reader is reading code for some embedded language with different case
rules, building up a dtabase, or doing other tasks.  But we should make it
clear that when reading Common Lisp code, the case-bashing convention still
holds.

-- Scott

∂17-Mar-89  0838	CL-Cleanup-mailer 	Issue: FUNCTION-COERCE-TIME (Version 2)  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  08:38:32 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 11:34:48 EST
Date: Fri, 17 Mar 89 11:35 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: FUNCTION-COERCE-TIME (Version 2)
To: cl-cleanup@sail.stanford.edu
Cc: Masinter.pa@xerox.com
In-Reply-To: <890316-221804-6820@Xerox>
Message-Id: <19890317163539.1.BARMAR@OCCAM.THINK.COM>

I favor LAZY, and then HYBRID.  I don't think performance is a
significant issue, as programmers can always get ambitious semantics by
specifying #'symbol or (symbol-function 'symbol) explicitly instead of
'symbol.  I believe that anyone who specifies the symbol instead of the
function is doing it precisely for its lazy semantics.

I like LAZY best because it makes all functions that take functional
arguments consistent.

                                                barmar

∂17-Mar-89  0847	CL-Cleanup-mailer 	Re: DEFAULT-CASE     
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  08:47:29 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559518; Fri 17-Mar-89 11:44:50 EST
Date: Fri, 17 Mar 89 11:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: DEFAULT-CASE 
To: John Foderaro <franz!frisky!jkf@ucbarpa.Berkeley.EDU>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8903170538.AA09727@frisky>
Message-ID: <19890317164453.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 16 Mar 89 21:38:14 PST
    From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)

     I'm not trying to start a religious war.  I'm not saying that
    case-sensitive is better or worse than case-insensitive.   I'm just
    saying that there are large numbers of people who favor each position
    and that Common Lisp should support both.    

Agreed.  I'm trying to help you not start a religious war.

      Regarding internal vrs external:  The internal representation shows
    through in a number of places.   For example the functions symbol-name
    and make-symbol let the user deal with the actual internal
    representation of the names of symbols.   The idea of having a
    *print-case* value that inverts the case on output is interesting but 
    that would make things awkward:  To make the symbol FooBar you 
    would have to (make-symbol "fOObAR").   Also examining the characters
    of a print-name with aref would give confusing results.  

The internal representation is accessible to programs, but I don't think
it's particularly important.  You seem to disagree.  It might be that we
have different experience with how often these primitives are used in
portable programs.  I don't think they are used enough that having an
internal representation in the opposite case from the external one would
cause bugs, but I do think they are used often enough that an incompatible
change would cause bugs in the medium term.

    >> I also claim that the choice of case in internal representation
    >> is arbitrary and need not prejudice the external representation
    >> at all.

     For a case-insensitive Lisp I completely agree.  For a case-sensitive
    Lisp, as I've shown above, this just isn't true.   Thus if the needs
    of the case-sensitive Lisp are met, then the needs of both are met.

True, but if the discussion gets side-tracked by flaming controversy over
the relatively unimportant issue of internal representation, I suspect
that the only outcome will be that everyone will give up on reaching a
concensus and we will be stuck with the status quo.  On the other hand,
if you compromise and keep the internal representation compatible, I
predict that you can very easily get what you really want, at the cost
of having a language 0.01% more inelegant than it would otherwise be.

∂17-Mar-89  0859	CL-Cleanup-mailer 	Re: issue HASH-TABLE-PRINTED-REPRESENTATION, v.2   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  08:59:00 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAR 89 08:53:42 PST
Date: 17 Mar 89 08:52 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue HASH-TABLE-PRINTED-REPRESENTATION, v.2
In-reply-to: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Fri, 09 Dec 88
 04:43:36 EST
To: Dave.Touretzky@cs.cmu.edu, cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890317-085342-8373@Xerox>

If someone brings a new draft to the March 89 X3J13, we can
put it on the agenda and discuss it. 

- - - - - - - -

Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 08 DEC 88 12:24:47 PST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88  12:21:22 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 12:00:50 PST
Date: 8 Dec 88 12:00 PST
From: masinter.pa
Subject: Re: issue HASH-TABLE-PRINTED-REPRESENTATION
In-reply-to: masinter.pa's message of 14 Nov 88 15:50 PST
To: cl-cleanup@sail.stanford.edu, Dave.Touretzky@B.GP.CS.CMU.EDU
Message-ID: <881208-120050-4123@Xerox>

I like Kent's idea 

" I (KMP) made a note to myself that since #S(ARRAY ...) and 
 #S(HASH-TABLE ...) couldn't possibly be meaningful, one might define
 #S to be the generalized constructor for things other than structures.
 So #S(ARRAY ...) could be used to print arrays with attributes that
 would otherwise be lost. eg, #S(ARRAY :CONTENTS ... :FILL-POINTER ...).
 Similarly, #S(HASH-TABLE :CONTENTS ... :SIZE ...) for the cases where
 hairy options wanted to be shown. #A and the simpler #H notation could
 then be used unless some option variable were set that said to really
 print the full-blown info."


However, this issue is not going anywhere -- there were certainly
more No's than Yes's to proceed with the latest draft.


Return-Path: <Dave.Touretzky@dst.boltz.cs.cmu.edu>
Received: from DST.BOLTZ.CS.CMU.EDU ([128.2.220.61]) by Xerox.COM ; 09 DEC 88 01:44:26 PST
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU;  9 Dec 88 04:43:48 EST
To: masinter.pa
cc: cl-cleanup@sail.stanford.edu
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: Re: issue HASH-TABLE-PRINTED-REPRESENTATION 
In-reply-to: Your message of 08 Dec 88 12:00:00 -0800.
	     <881208-120050-4123@Xerox> 
Date: Fri, 09 Dec 88 04:43:36 EST
Message-ID: <3932.597663816@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU

I like KMP's idea too.  In fact, if KMP's extension to #S were passed, I
would be happy to shelve the #H proposal.  I want hash tables to have a
READable printed representation, but I don't want to squander the remaining
# macro dispatch characters on obscure bits of syntax.  People will want to
type in arrrays as constants (with #A) much more frequently than hash
tables, so #A is needed but #H is diposable.

-- Dave

∂17-Mar-89  0910	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  09:09:51 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559547; Fri 17-Mar-89 12:05:36 EST
Date: Fri, 17 Mar 89 12:05 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: COERCE-INCOMPLETE (Version 3)
To: sandra%defun@cs.utah.edu
cc: barmar@Think.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
    masinter.pa@xerox.com, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8903171654.AA06800@defun.utah.edu>
Message-ID: <890317120519.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

[X3J13 removed as overkill for this level of discussion; CL-Cleanup added]

    Date: Fri, 17 Mar 89 09:54:35 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    ... BarMar is right. I have a hardcopy of the FUNCTION-TYPE writeup that
    was mailed on 4 Sep 88, with a note from Larry indicating that it's
    the final version as passed at the June meeting.  It includes
    COERCE'ing of lambda expressions to functions as item 6b. ...

Yeah, it's the same in my copy. Sorry about that. I just stopped reading
too soon. Thanks for catching this.

    I don't think this is a valid argument for not getting rid of COERCE,
    since it is easy to coerce a lambda expression to a function using
    (EVAL `(FUNCTION ,x)).

I mostly agree, but I admit that most other coercion operators don't force
you to cons unnecessary intermediate structure in order to do the coercion.
Having something like the original SCHEME's ENCLOSE operator wouldn't bother
me at all.  Too bad we didn't pick the name DISCLOSE for what ended up being
FUNCTION-LAMBDA-EXPRESSION.  I guess the right name for the ENCLOSE function
at this point is LAMBDA-EXPRESSION-FUNCTION.

∂17-Mar-89  1032	CL-Cleanup-mailer 	DYNAMIC-EXTENT  
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89  10:32:06 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182328; Fri 17-Mar-89 13:26:45 EST
Date: Fri, 17 Mar 89 13:29 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: DYNAMIC-EXTENT
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <890316-120057-5042@Xerox>
Message-ID: <19890317182930.6.MLY@ISABEL-PERON.AI.MIT.EDU>

I don't see any way in the proposal to declare that a closure itself, rather than
its arguments, has dynamic extent.  My greatest single use for dynamic-extent
declarations is to ensure stack-consing of closures.

Symbolics have a declaration SYS:DOWNWARD-FUNCTION for this case.
Perhaps CL could use DYNAMIC-EXTENT-FUNCTION

(flet ((test (a b)
         (declare (dynamic-extent-function))
         ...))
  (foo #'test))

(foo (lambda (a b)
       (declare (dynamic-extent-function))
       ...))



Another feature which I find sorely needed (and which nobody seems
to support) is a way to declare that the result of a form
has dynamic extent.  For example,
  (defmacro with-frob (thunk &body body)
    `(let ((*frob-stack* (cons (the dynamic-extent-object ,thunk) *frob-stack*)))
       (declare (dynamic-extent *frob-stack*))
       ,@body))
The idea is to avoid making all users of the with-frob macro
put in explicit dynamic-extent-function declarations.

∂17-Mar-89  1044	CL-Cleanup-mailer 	Re: DEFAULT-CASE
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 17 Mar 89  10:43:34 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa08901; 17 Mar 89 18:19 GMT
Date: Fri, 17 Mar 89 18:18:11 GMT
Message-Id: <4955.8903171818@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: DEFAULT-CASE
To: "David A. Moon" <Moon@scrc-stony-brook.arpa>, 
    John Foderaro <@NSS.Cs.Ucl.AC.UK,@aiai.edinburgh.ac.uk,@ucbarpa.berkeley.edu,@franz:jkf@frisky>
In-Reply-To: David A. Moon's message of Thu, 16 Mar 89 18:15 EST
Cc: CL-Cleanup@sail.stanford.edu

>   Proposal (DEFAULT-CASE:LOWER)
> 
>     The case of all characters in the names of standard
>     functions, symbols, and packages is lower.
> 
> You're proposing a huge incompatible change that is bound to
> get you into a religious war that can't do anyone any good.
> I claim that this proposal addresses the internal representation
> of programs but all you care about is the external representation.
> I also claim that the choice of case in internal representation
> is arbitrary and need not prejudice the external representation
> at all.

That is almost true, but not compeletly.  What about FIND-SYMBOL and
the like?  So the programmer sometimes still has to know that, internally,
the default is upper case.  And if the internal case has so little
significance, why should there be a religious war about it?

> If you believe what I just said, you would propose that the reader get
> an option to flip case instead of up-casing when converting from
> external representation to internal representation, and would propose
> another value for *print-case* that does the inverse transformation.

Something like this was suggested in the "discussion" section of
READ-CASE-SENSITIVITY (Version 1).  But maybe it shouldn't just
flip everything:

  An interesting possibility would be to disguise the preferred
  internal case by defining a value for *READ-CASE* called :INVERT.
  If the value were :INVERT, mixed-case symbols would remain the same
  (or perhaps they would be inverted too) but all-upper-case input
  would specify a lower-case name internally, and vice versa.

One problem with such proposals is that (I suspect) most people
most of the time will write code in lower case.  Having the reader
always invert what they type seems a bit perverse.  I'd be surprised
if this convinced anyone to change their mind, though.

> This would be compatible with everybody, would make everybody happy
> except for those who might insist that one internal representation
> is better than the other, and hopefully would avoid spending a lot
> of time on discussion.  What do you think?

I'd prefer to change the internal case, but this is a reasonable
alternative if a change can't happen or would cause hard feelings
or extensive difficulty if it did.

∂17-Mar-89  1046	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL (Version 9)   
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 17 Mar 89  10:46:17 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa08933; 17 Mar 89 18:26 GMT
Date: Fri, 17 Mar 89 18:25:09 GMT
Message-Id: <5014.8903171825@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
To: "David A. Moon" <Moon@scrc-stony-brook.arpa>, masinter.pa@xerox.com
In-Reply-To: David A. Moon's message of Thu, 16 Mar 89 12:29 EST
Cc: cl-cleanup@sail.stanford.edu

> Maybe I shouldn't take this attitude, but I will anyway.  I have brief
> notes on the amendments that were proposed, but since I think all of them
> were wrongheaded and braindamaged, I'm not going to help anyone remember
> them.  Only one of the amendments was actually voted on, so we're certainly
> free to forget the other two.

I didn't much like the ammendments either.  They were drafted on the
spot and probably not very well thought-out.

However, it would be nice to know if there are still strong objections
to version 9 (and what they are if they exist) so there will be time
to consider them before the meeting.

∂17-Mar-89  1100	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS (Version 1)    
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89  11:00:09 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182335; Fri 17-Mar-89 13:54:53 EST
Date: Fri, 17 Mar 89 13:57 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-082536-2261@Xerox>
Message-ID: <19890317185733.7.MLY@ISABEL-PERON.AI.MIT.EDU>

    Date: 14 Mar 89 08:24 PST
    From: masinter.pa@xerox.com

    Your thoughts?

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

    [...]

The proposal doesn't compensate for the mistake of having
disassociated restarts from context in the first place.

All restarts should have associated with them a real predicate
(not just a screwy wired-in (lambda (c) (eq c associated-condition)))
In general the applicability of a restart depends on the dynamic
environment in which it invoked as well as that in which it
was established.

All restarting forms should require a condition argument (-not- NIL.)

Why on earth do ABORT, USE-VALUE, etc still exist?

The business about COPY-CONDITION is completely confused.

I don't care for the syntax, though it isn't worse than
that of the rest of the condition system.

∂17-Mar-89  1101	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS (Version 1)    
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89  11:01:07 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182336; Fri 17-Mar-89 13:55:49 EST
Date: Fri, 17 Mar 89 13:58 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-082536-2261@Xerox>
Supersedes: <19890317185733.7.MLY@ISABEL-PERON.AI.MIT.EDU>
Message-ID: <19890317185835.8.MLY@ISABEL-PERON.AI.MIT.EDU>

    From: masinter.pa@xerox.com
    Subject: Issue: CONDITION-RESTARTS (Version 1)
    To: Richard Mlynarik <Mly@ai.ai.mit.edu>, Daniels.PA@xerox.com
    Reply-To: cl-cleanup@sail.stanford.edu

    Your thoughts?

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

    [...]

The proposal doesn't compensate for the mistake of having
disassociated restarts from context in the first place.

All restarts should have associated with them a real predicate
(not just a screwy wired-in (lambda (c) (eq c associated-condition)))
In general the applicability of a restart depends on the dynamic
environment in which it invoked as well as that in which it
was established.

All restarting forms should require a condition argument (-not- NIL.)

Why on earth do ABORT, USE-VALUE, etc still exist?

The business about COPY-CONDITION is completely confused.

I don't care for the syntax, though it isn't worse than
that of the rest of the condition system.

∂17-Mar-89  1205	CL-Cleanup-mailer 	Issue: IN-SYNTAX (Version 1)   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  12:05:22 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 15:01:32 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 15:02:43 EST
Received: by verdi.think.com; Fri, 17 Mar 89 14:59:31 EST
Date: Fri, 17 Mar 89 14:59:31 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903171959.AA09035@verdi.think.com>
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 16 Mar 89 23:05 PST <890316-230556-6907@Xerox>
Subject: Issue: IN-SYNTAX (Version 1)

Yet Another Puppy--YAP!

So let us define a "yapper" to mean someone who proposes Yet Another Puppy.
--Q

∂17-Mar-89  1214	CL-Cleanup-mailer 	Issue LOOP-AND-DISCREPANCY, version 1    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89  12:14:03 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01428g; Wed, 15 Mar 89 23:55:31 PST
Received: by bhopal id AA11642g; Wed, 15 Mar 89 23:56:18 PST
Date: Wed, 15 Mar 89 23:56:18 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903160756.AA11642@bhopal>
To: gls@Think.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Guy Steele's message of Wed, 15 Mar 89 13:50:51 EST <8903151850.AA02865@verdi.think.com>
Subject: Issue LOOP-AND-DISCREPANCY, version 1

The document 89-004 followed what the code does (the "code" being that 
portable version that used to come from MIT), but at the Hawaii meeting,
I remember suggesting that it ought to be made formal as to whether or not 
the WITH or the FOR/AS is to be repeated.  I'm glad you took the time to 
write up the issue (which I approve of).  It's really a very minor point,
so there is very little risk involved.


-- JonL --

∂17-Mar-89  1214	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89  12:14:13 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01417g; Wed, 15 Mar 89 23:39:01 PST
Received: by bhopal id AA11617g; Wed, 15 Mar 89 23:39:49 PST
Date: Wed, 15 Mar 89 23:39:49 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903160739.AA11617@bhopal>
To: gls@Think.COM
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Guy Steele's message of Tue, 28 Feb 89 14:13:37 EST <8902281913.AA03555@verdi.think.com>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)

re: I conclude that the strict interpretation may be preferred, but not for the
    reasons Jonl has advanced!  The liberal interpretation does *not* prevent
    compilers for stock hardware from producing good code, and therefore the
    code example does not support his claim to the contrary.


Guy, I fear that you have made an error of logic in analyzing my example.
You use the "strict" interpretation to conclude that the example is
incorrect code (as it should be!); but the whole point of the example is 
to show that under the "liberal" interpretation, it's correctness depends 
on the implementation rather than on a implementation-independent definition.

If you don't see this, then perhaps we should talk about it "off line".


-- JonL --

∂17-Mar-89  1214	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89  12:14:37 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01413g; Wed, 15 Mar 89 23:32:00 PST
Received: by bhopal id AA11607g; Wed, 15 Mar 89 23:32:47 PST
Date: Wed, 15 Mar 89 23:32:47 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903160732.AA11607@bhopal>
To: cl-cleanup@sail.stanford.edu
Cc: X3J13@Sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 15 Mar 89 05:13 PST <890315-051405-3472@Xerox>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)

Although I haven't had time to join the overly-lengthy discussion on this
matter,  I did point out one particularly confusing direction -- that this
proposal to "fix" the function ADJUST-ARRAY has become a proposal to alter 
the semantics of the type SIMPLE-ARRAY.  Compare CLtL, p28, with the
sentence in the Rationale Section:
  "Specifying the points left unspecified (requiring all simple arrays to be
   non-adjustable and all adjustable arrays to be non-simple) would require
   large changes to some implementations and would be of little benefit to
   ..."
and with an item in the Clarification section:
  "a. Whether an array can be both simple and adjustable is unspecified."
[CLtL definition *does* specify it].

I suggested that a simple statement be added to the proposal as follows:
  "This proposal does not attempt to alter the meaning of the type
   SIMPLE-ARRAY in any way"
Moon expressed approval of adding that statement.

Altered semantics would mean that it is no longer a portable type.  I 
have sent out several trivially small examples that show this.  Some 
people have interpreted those examples as simply showing what happens 
with "broken" code; but quite to the contrary, they show how code can be 
"correct" on one implementation and "broken" on another ****** when the 
definition of SIMPLE-ARRAY is allowed to vary between one implementation 
and the other ******.  Very carefully, CLtL spells out that implementations 
may vary on the efficiency with which they implement SIMPLE-ARRAYS; but 
nowhere does it provide for optional exclusion of some parts of the 
definition thereof.


Also, I note that all of the discussion on the Cl-cleanup list was by
persons other than the half-dozen or so maintainers of "stock hardware"
compilers.  I personally spoke with three others (not including myself)
at Hawaii, and we all have identical requirements for the type SIMPLE-ARRAY,
and identical resolve that it must not be changed.  Our compilers will
continue to offer this C-level optimization capability; the only 
question is whether or not the CL1989 Standard will be cognizant of it.



-- JonL --

∂17-Mar-89  1229	CL-Cleanup-mailer 	DYNAMIC-EXTENT  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  12:27:59 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 15:23:26 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 15:24:37 EST
Received: by verdi.think.com; Fri, 17 Mar 89 15:21:24 EST
Date: Fri, 17 Mar 89 15:21:24 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172021.AA09135@verdi.think.com>
To: Mly@ai.ai.mit.edu
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Richard Mlynarik's message of Fri, 17 Mar 89 13:29 EST <19890317182930.6.MLY@ISABEL-PERON.AI.MIT.EDU>
Subject: DYNAMIC-EXTENT

   Date: Fri, 17 Mar 89 13:29 EST
   From: Richard Mlynarik <Mly@ai.ai.mit.edu>

   I don't see any way in the proposal to declare that a closure itself, rather than
   its arguments, has dynamic extent.  My greatest single use for dynamic-extent
   declarations is to ensure stack-consing of closures.

   Symbolics have a declaration SYS:DOWNWARD-FUNCTION for this case.
   Perhaps CL could use DYNAMIC-EXTENT-FUNCTION

   (flet ((test (a b)
	    (declare (dynamic-extent-function))
	    ...))
     (foo #'test))

   (foo (lambda (a b)
	  (declare (dynamic-extent-function))
	  ...))

This is a genuine need.  I suggest

(flet ((test (a b) ...))
  (declare (dynamic-fextent test))	;So pick a better name
  (foo #'test))


   Another feature which I find sorely needed (and which nobody seems
   to support) is a way to declare that the result of a form
   has dynamic extent.  For example,
     (defmacro with-frob (thunk &body body)
       `(let ((*frob-stack* (cons (the dynamic-extent-object ,thunk) *frob-stack*)))
	  (declare (dynamic-extent *frob-stack*))
	  ,@body))
   The idea is to avoid making all users of the with-frob macro
   put in explicit dynamic-extent-function declarations.


This proposal has problems.  It is not enough to say
"foo has dynamic extent extent".  You have to say something
about when it starts and ends.  For executable constructs
we implicitly refer to the time execution enters the
construct and the time execution leaves it.  For objects
it is more difficult, and I claim you need to tie it to
code execution.  How do I know that the "thunk" is supposed
to last for the duration of the LET, rather than just the
duration of the call to CONS, or the duration of the caller
of the macro?
--Guy

∂17-Mar-89  1254	CL-Cleanup-mailer 	Re: DEFAULT-CASE     
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89  12:54:27 PST
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
	id AA10420; Fri, 17 Mar 89 12:23:10 -0800
Received: from frisky by franz (3.2/3.14)
	id AA24300; Fri, 17 Mar 89 11:37:25 PST
Received: by frisky (3.2/3.14)
	id AA11169; Fri, 17 Mar 89 11:36:17 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8903171936.AA11169@frisky>
To: franz!ucbarpa!B.GP.CS.CMU.EDU!Scott.Fahlman
Cc: franz!sail.stanford.edu!cl-cleanup
Subject: Re: DEFAULT-CASE 
In-Reply-To: Your message of Fri, 17 Mar 89 11:19:37 EST.
             <8903171622.AA04031@ucbarpa.Berkeley.EDU> 
Date: Fri, 17 Mar 89 11:36:14 PST




Scott,
    
    I completely agree that all 'official' Common Lisp symbol names should
be use one case, and should there ever be a library of contributed programs
only those program that work in a case-insensitive mode should be
accepted.   When Common Lisp starts up it should be case-insensitive
just like it is now.

>>  I think that this is a recipe for confusion
>>  and major portability problems.  As soon as there is code around that
>>  assumes case sensitivity, anyone who wants to use that code in conjunction
>>  with code of his own has to go along with case sensitivity. 

 This is incorrect.   I've had ten years of experience with using
code written in both case-sensitive and insensitive-modes in the same Lisp 
(first it was debugging Macsyma in Franz Lisp, and now it is working 
with programs like PCL in Common Lisp).   The only difficulties
I had were due to the default case of symbol names (and that is what 
my proposal is directed to fix).   Keep in mind that if you 
decide to live solely in the case-insensitive world you still have
access to all symbols, you may just have to type extra backslashes or
vertical bars sometimes.  


>>  We'll either have two incompatible software words within Common Lisp, 
>>  or it will drag us all through a major incompatible change we don't want.
 
 I honestly don't know what you mean by this.  Perhaps you could describe some 
of your experiences or just some scenarios that you imagine might happen.   
Keep in mind that there is already considerable freedom in 
how people write programs.   What if we started getting flooded with 
great programs written in French, or Spanish or Italian which 
many of us couldn't understand.  Should we mandate that for portability 
all programs shall be written in English (or perhaps Esperanto)?
What if someone developed a loop macro that half the users loved and half 
despised?  Should we not include that macro in Common Lisp because people 
might start using it and then write code that half the users can't read
without feeling ill?

 Remember, the only thing that will change if this and the 
READ-CASE-SENSITIVITY proposal pass is that the default case for symbol
names will be lower.   Absolutely nothing else about your world or 
the way you program need change.   

 If you want, we can privately correspond on these issues and then 
send a summary of what we've concluded to this mailing list.


- john foderaro

∂17-Mar-89  1254	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  12:54:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559814; Fri 17-Mar-89 15:51:33 EST
Date: Fri, 17 Mar 89 15:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu, X3J13@Sail.stanford.edu
In-Reply-To: <8903160732.AA11607@bhopal>
Message-ID: <19890317205125.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 15 Mar 89 23:32:47 PST
    From: Jon L White <jonl@lucid.com>

    Although I haven't had time to join the overly-lengthy discussion on this
    matter,  I did point out one particularly confusing direction -- that this
    proposal to "fix" the function ADJUST-ARRAY has become a proposal to alter 
    the semantics of the type SIMPLE-ARRAY.

Adding the discussion of SIMPLE-ARRAY was at *+*YOUR*+* request, JonL.
There is !!NO!! change to the semantics, as I thought you had agreed in
the last message you sent on the topic.  If now you're taking that back
and saying that you still think what this proposal says is a change to
the semantics, okay, but I have yet to figure out why you think that or
what you think is changed.

∂17-Mar-89  1257	X3J13-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  12:57:27 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 15:52:50 EST
Date: Fri, 17 Mar 89 15:53 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <8903160732.AA11607@bhopal>
Message-Id: <19890317205329.0.BARMAR@OCCAM.THINK.COM>

What happens in implementations that allow all arrays to be adjusted?
If you require that (typep x 'simple-array) implies (not
(adjustable-array-p x)), I see two possible resolutions: 1) such
implementations are not conforming; 2) the type SIMPLE-ARRAY is empty.
I find (1) distasteful, because non-adjustable arrays and the
SIMPLE-ARRAY type exist solely for the benefit of implementations that
need them, and this would require support of these concepts in
implementations that don't derive any benefit from them.  I think (2)
makes the SIMPLE-ARRAY type pretty useless, since a portable program
can't expect anything to be of this type (FIXNUM had this problem until
we fixed it in Hawaii).

                                                barmar

∂17-Mar-89  1327	CL-Cleanup-mailer 	DYNAMIC-EXTENT  
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89  13:27:36 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182401; Fri 17-Mar-89 16:22:14 EST
Date: Fri, 17 Mar 89 16:24 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: DYNAMIC-EXTENT
To: gls@think.com
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8903172021.AA09135@verdi.think.com>
Message-ID: <19890317212454.9.MLY@ISABEL-PERON.AI.MIT.EDU>

    Date: Fri, 17 Mar 89 15:21:24 EST
    From: Guy Steele <gls@think.com>

    This is a genuine need.  I suggest

    (flet ((test (a b) ...))
      (declare (dynamic-fextent test))	;So pick a better name
      (foo #'test))


A declaration in the body of the function feels preferable to me
as a user -- otherwise it is necessary to create a name for a function
simply to declare something about it.  There may indeed be semantic
reasons to decide otherwise.

       Another feature which I find sorely needed (and which nobody seems
       to support) is a way to declare that the result of a form
       has dynamic extent.

    This proposal has problems.  It is not enough to say
    "foo has dynamic extent extent".  [...]

Forget it.  I was confused (probably by the fact that I use a lisp
implementation which has a dynamic-extent declaration within closures
but no general dynamic-extent declaration in the sense of the proposal.)

I should have written my sample macro as
(defmacro with-frob (thunk &body body)
  (let ((tem (gensym)))
    `(let ((,tem ,thunk))
       (declare (dynamic-extent ,tem))
       (let ((*frob-stack* (cons ,tem *frob-stack*)))
         ...))))
where I assume that the implementation knows to stack-allocate the `y' in
(let* ((foo 1)
       (y (lambda () foo)))
  (declare (dynamic-extent y))
  ... y ...)

∂17-Mar-89  1337	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  13:37:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559887; Fri 17-Mar-89 16:33:57 EST
Date: Fri, 17 Mar 89 16:33 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
To: Jon L White <jonl@lucid.com>, Masinter.pa@Xerox.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8903160732.AA11607@bhopal>
Message-ID: <19890317213333.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

This version is edited to reflect the changes I think JonL wants,
which I had thought were already in.  I'll mail this to X3J13 to
supersede version 8, unless one of you asks me not to.  That would
probably be more constructive than the intemperate message I already
sent.

Issue:        ADJUST-ARRAY-NOT-ADJUSTABLE
References:   ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
              MAKE-ARRAY (pp286-289), simple arrays (p28, 289)
Category:     CLARIFICATION
Edit history: 22-Apr-87, Version 1 by Pitman
              15-Nov-88, Versions 2a,2b,2c by Pitman
              02-Dec-88, Version 3 by Pitman
              11-Jan-89, Version 4 by Pitman
              16-Jan-89, Version 5, by Gabriel.  Amended at the meeting to shorten.
              23-Jan-89, Version 6, by Moon.  Shorten without the bug introduced
                        by the amendment, add clarification of SIMPLE-ARRAY type.
	      15-Feb-89, Version 7, by Pitman. Minor changes per comments from
			RPG and Dalton.
	      11-Mar-89, Version 8, by Pitman. Change category, add endorsements.
              17-Mar-89, Version 9, by Moon, fix wording and examples to make it
			clear that the semantics of simple-array is unchanged.

Problem Description:

  The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
  says that ``the argument, if specified and not NIL, indicates that
  it must be possible to alter the array's size dynamically after
  it is created. This argument defaults to NIL.''

  The description of the :ADJUSTABLE option does not say what 
  MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.

  The description of ADJUSTABLE-ARRAY-P on p293 says that it is
  true ``if the argument (which must be an array) is adjustable, and
  otherwise false.'' However, the description of MAKE-ARRAY makes
  it clear that this is not necessarily the same as asking if
  the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
  returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
  :ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
  T, then there is no information about whether :ADJUSTABLE was used.

  The description of ADJUST-ARRAY on pp297-298 says that it is
  ``not permitted to call ADJUST-ARRAY on an array that was not
  created with the :ADJUSTABLE option.'' This is inconsistent with
  ADJUSTABLE-ARRAY-P.
  
  A problem which comes up in practice is that some programmers
  expect runtime error checking if they have done
  (MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
  the array using ADJUST-ARRAY.

  The definition of the SIMPLE-ARRAY type and its subtypes needs
  clarification of its relationship to adjustability.


Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):

  1. ADJUSTABLE-ARRAY-P is true of all arrays created with a true
  :ADJUSTABLE option to MAKE-ARRAY.  Whether ADJUSTABLE-ARRAY-P is
  true of some other arrays is unspecified.
 
  2. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER, 
  and :DISPLACED-TO arguments each either unspecified or false, the
  resulting array is a simple array.  (This just repeats what CLtL
  says on page 289, it's here to aid in understanding the next point.)
      
  3. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
  :FILL-POINTER, or :DISPLACED-TO arguments true, whether the
  resulting array is simple is unspecified.
      
  4. ADJUST-ARRAY ``should signal'' an error if ADJUSTABLE-ARRAY-P
  of its first argument is false.  ADJUST-ARRAY must not signal an
  `array not adjustable' error if ADJUSTABLE-ARRAY-P of its first
  argument is true.

  5. The value of ADJUSTABLE-ARRAY-P on a simple array is unspecified.

  Note: ``should signal'' is taken from the new error terminology.
  It means that in ``safe code'' (code compiled with highest safety)
  an error must be signalled, but that in unsafe code (code not compiled
  with highest safety), an error might or might not be signalled.

Clarifications and Logical Consequences:

  a. Whether an array can be both simple and adjustable is unspecified.

  b. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
     definitely returns NIL.

  c. There is no specified way to create an array that is non-simple.

  d. This legitimizes ADJUSTABLE-ARRAY-P as an appropriate predicate to
     determine whether ADJUST-ARRAY will reliably succeed.

  e. If ADJUST-ARRAY is invoked on an array that was created without
     supplying :ADJUSTABLE true, an `array not adjustable' error
     ``should be signalled'' unless ADJUSTABLE-ARRAY-P returns true on
     that array (in which case it must not signal an `array not adjustable'
     error).

  f. There is no change to the meaning of the type SIMPLE-ARRAY, only
     a clarification that a conforming program cannot assume that any
     array is not simple.

Rationale:

  This effectively makes the status quo explicit.  This preserves the
  raison d'etre of simple arrays, which is to provide a portable interface
  to implementation-dependent specialized arrays that trade decreased
  functionality for faster access.

  A proposed alternative was to specify a way to create an array that is
  guaranteed not to be simple.  This would have required large changes
  to some implementations and would be of little benefit to users.
  Users need to know that certain arrays are simple, so they can put in
  declarations and get higher performance, but users have no need to be
  able to create arrays that are definitely non-simple (for lower
  performance) or definitely non-adjustable (to cause errors).

Examples:

  1. The following program is conforming.  It is unspecified which branch
  of the IF it follows.
  
    (defun double (a)
       (if (adjustable-array-p a)
           (adjust-array a (* (length a) 2))
           (let ((new (make-array (* (length a) 2))))
             (replace new a :end1 (length a))
             new)))
  
    (double (make-array 30))

  2. The following program is conforming.  In no implementation is the
  type declaration violated.

    (let ((a (make-array 100)))
      (declare (simple-array a))
      (frob a))

  3. The following program is non-conforming.  The consequences of this
  program are undefined because the type declaration is violated in some
  valid implementations.

    (let ((a (make-array 100 :adjustable t)))
      (declare (simple-array a))
      (frob a))


Current Practice:

  Probably everyone is compatible with this proposal. 

  Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
  and ignores adjustability in deciding whether an array is simple,
  and is compatible with this proposal.

  Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
  in all cases, and make all arrays non-simple unless the Common Lisp
  language requires them to be simple, and are compatible with this proposal.

Cost to Implementors:

  It's in principle possible that some implementation would have to change,
  but in practice there are no known implementations that would have to change.

Cost to Users:

  None. This is a fully compatible change from the user's standpoint.

Benefits:

  Users would know what to expect.

Non-Benefits:

  Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
  an error would not get the desired error checking.

Aesthetics:

  Most people believe the status quo is unaesthetic.  Having an aspect of
  the language explicitly unspecified is more aesthetic than having it
  implicitly unspecified on account of vague or inconsistent documentation.

Discussion:

  Pitman, Moon, Gabriel, and Steele support this amended proposal.

  MACSYMA ran into portability problems due to the status quo.
  If the issue had been documented, that would have helped.
  Encouraging implementations that are able to at least make
  (MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
  where possible would help, too.

  We considered proposals to incompatibly change this primitive in a
  variety of ways, but the community was very split with strong proponents
  and opponents of each alternate proposal.

  The overriding concern driving this proposal is that Symbolics 
  has asserted that most of the other really interesting proposals would
  likely involve a sizable cost to implementors (and their installed bases)
  to implement what were judged by some as gratuitous changes from the
  status quo.

  Pitman wishes some of the other proposals were economically feasible to
  pursue but reluctantly agrees that maintaining (and clearly documenting)
  the status quo is probably the most reasonable avenue left to us.

∂17-Mar-89  1346	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  13:45:46 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 16:41:06 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 16:42:07 EST
Received: by verdi.think.com; Fri, 17 Mar 89 16:38:55 EST
Date: Fri, 17 Mar 89 16:38:55 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172138.AA09505@verdi.think.com>
To: jonl@lucid.com
Cc: gls@Think.COM, masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Wed, 15 Mar 89 23:39:49 PST <8903160739.AA11617@bhopal>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)

   Date: Wed, 15 Mar 89 23:39:49 PST
   From: Jon L White <jonl@lucid.com>

   re: I conclude that the strict interpretation may be preferred, but not for the
       reasons Jonl has advanced!  The liberal interpretation does *not* prevent
       compilers for stock hardware from producing good code, and therefore the
       code example does not support his claim to the contrary.


   Guy, I fear that you have made an error of logic in analyzing my example.
   You use the "strict" interpretation to conclude that the example is
   incorrect code (as it should be!); but the whole point of the example is 
   to show that under the "liberal" interpretation, it's correctness depends 
   on the implementation rather than on a implementation-independent definition.

   If you don't see this, then perhaps we should talk about it "off line".

I respectfully disagree with your assessment; I believe that you have
erred in analyzing my analysis.  Specifically, I do *not* conclude
that the example is incorrect code.  Let me quote further from my
message of Feb 28:

	I argue that the program is correct under both interpretations....

	Under the strict interpretation implementation (A) is incorrect by
	definition.  Under the liberal interpretation implementation (A) is
	correct, and accomplishes a useful purpose. ...

According to my analysis, the correctness of the code does not depend
on the choice of strict or liberal interpretation; rather, the
correctness of implementation (A) depends on the choice of interpretation.

I conclude: (1) Under the strict interpretation only some
implementations are correct, but under the liberal interpretation many
more are correct.  (2) You can get good code on stock hardware
regardless of the choice of interpretation.

Therefore unless some other argument can be advanced for the strict
interpretation, the liberal interpretation is to be preferred because it
invalidates fewer implementation strategies.

So there you have a concise summary of my argument that may make it
easier for you to find the hole in it (if any).

--Guy

∂17-Mar-89  1410	CL-Cleanup-mailer 	Re: Issue: EXPT-ZERO-ZERO (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  14:10:35 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559948; Fri 17-Mar-89 17:07:44 EST
Date: Fri, 17 Mar 89 17:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: EXPT-ZERO-ZERO (Version 1)
To: masinter.pa@Xerox.COM
cc: KMP@symbolics.com, CL-Cleanup@sail.stanford.edu,
    Cyphers@JASPER.SCRC.Symbolics.COM
In-Reply-To: <890316-211042-6708@Xerox>
Message-ID: <890317170725.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 16 Mar 89 21:10 PST
    From: masinter.pa@Xerox.COM

    Kent, do you want to proceed with this one? I don't think it is necessary
    or even a good idea. What do other programming languages do? 

    If you do, I think we should leave (EXPT 0 0) = 1 and (EXPT 0.0 0) = 1 and
    only deal with (EXPT 0.0 0.0) and (EXPT 0 0.0). 

Let's table it.

I asked a bunch of the people here about it and they didn't really buy
all the arguments advanced for why it was such a good idea to have 1
come out, but they didn't really care a lot since it was pretty easy to
special case zero before it ever got into EXPT in the first place.

    Doesn't this fit into the ERRORS-IN-NUMBERS-CHAPTER spectrum?

If we were going to pursue it, I guess it could.

∂17-Mar-89  1541	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  15:40:34 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 16:23:16 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 16:24:05 EST
Received: by verdi.think.com; Fri, 17 Mar 89 16:20:53 EST
Date: Fri, 17 Mar 89 16:20:53 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172120.AA09400@verdi.think.com>
To: jonl@lucid.com
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: Jon L White's message of Wed, 15 Mar 89 23:32:47 PST <8903160732.AA11607@bhopal>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)

   Date: Wed, 15 Mar 89 23:32:47 PST
   From: Jon L White <jonl@lucid.com>
   ...
   Also, I note that all of the discussion on the Cl-cleanup list was by
   persons other than the half-dozen or so maintainers of "stock hardware"
   compilers.  I personally spoke with three others (not including myself)
   at Hawaii, and we all have identical requirements for the type SIMPLE-ARRAY,
   and identical resolve that it must not be changed.  Our compilers will
   continue to offer this C-level optimization capability; the only 
   question is whether or not the CL1989 Standard will be cognizant of it.

I am very concerned about the stock hardware, but also very confused.
I understand that the stock-hardware implementors adamantly oppose
the proposed change, but I still have not seen a single convincing
example of why the proposed change would prevent them from accomplishing
the desired optimizations or why the proposed change would defeat
portability.  I acknowledge that JonL has provided an example or two,
but I have not found them convincing.  So either these examples are
wrong, or I am badly wedged; in either case I need further explanation.
--Guy

∂17-Mar-89  1555	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89  15:55:19 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02075g; Fri, 17 Mar 89 15:47:55 PST
Received: by bhopal id AA19349g; Fri, 17 Mar 89 15:50:11 PST
Date: Fri, 17 Mar 89 15:50:11 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903172350.AA19349@bhopal>
To: gls@Think.COM
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Guy Steele's message of Fri, 17 Mar 89 16:38:55 EST <8903172138.AA09505@verdi.think.com>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)

re: 	Under the strict interpretation implementation (A) is incorrect by
	definition.  Under the liberal interpretation implementation (A) is
	correct, and accomplishes a useful purpose. ...

Guy, I'm totally confused by your "analysis" now;  the whole point of
the example is to show that portability is sacrificed under what you are
calling the "liberal" interpretation -- that altering the CLtL semantics
of SIMPLE-ARRAY makes it non portable.  As I look back into your
previous msg, I see that you did say:
    Now, the two implementations behave differently on the example, and that 
    is a cause for concern.
Also, your statement just quoted above shows the variations possible under
implementation (A) and (B), thus reiterating the non-portability question
I brought up.   Thus you'll have to admit that my example showed *exactly* 
what I claimed it did.  

However, I disagree with your judgement -- that it is better to accept an 
interpretation that allows more variation among implementations -- because 
the variation you are thereby accommodating means that the type is no longer 
portable.  We may be stuck with that position, but I don't agree that it
is a good thing.


-- JonL --




∂17-Mar-89  1618	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  16:18:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560081; Fri 17-Mar-89 19:15:40 EST
Date: Fri, 17 Mar 89 19:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: Richard Mlynarik <Mly@AI.AI.MIT.EDU>, KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <19890317185835.8.MLY@ISABEL-PERON.AI.MIT.EDU>
Message-ID: <19890318001531.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 17 Mar 89 13:58 EST
    From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>

    The proposal doesn't compensate for the mistake of having
    disassociated restarts from context in the first place.

    All restarts should have associated with them a real predicate
    (not just a screwy wired-in (lambda (c) (eq c associated-condition)))
    In general the applicability of a restart depends on the dynamic
    environment in which it invoked as well as that in which it
    was established.

You're absolutely right.  In all the hoopla I had forgotten about this.
I think it's quite reasonable to have some convenient syntax for the
common case where the predicate is to test for a particular condition
object, but the underlying primitives should allow an arbitrary
predicate.  RESTART-BIND needs to be enhanced with a :TEST argument,
which is a predicate function that COMPUTE-RESTARTS calls.

    All restarting forms should require a condition argument (-not- NIL.)

I disagree with this, because it does make sense to restart a program
in response to some situation other than the signalling of a condition.

    Why on earth do ABORT, USE-VALUE, etc still exist?

I don't know either.

    The business about COPY-CONDITION is completely confused.

I agree with this.  The argument against resignalling a condition
is wrong; there is no confusion of identity if a condition is signalled,
this results in some transfer of control, and then the same condition
object, representing the same situation that is still happening, is
signalled again.  There is also no harm in a system keeping a particular
pre-created condition object around and using that same object every
time it signals a particular condition, so long as it keeps its restarts
straight.  Since it is the program that signals a condition that
establishes restarts bound to that particular condition, it knows what
it is doing, and if it knows that it doesn't establish any restarts
that are associated to the particular condition object, it knows there
is no harm in reusing the condition object.

    I don't care for the syntax, though it isn't worse than
    that of the rest of the condition system.

I don't like the syntax in the version that got mailed to X3J13, which
I don't think was really ready for mailing.  I had some alternate syntax
proposals, but I don't much like them either.

Here is what I would suggest doing to the proposal to make it ready
for X3J13:

  1. Define that it is an error for SIGNAL to be called on a condition
     more than once.

  2. Introduce a function COPY-CONDITION

Remove items 1 and 2.
 
Add a :TEST argument to RESTART-BIND.
Add a :TEST argument to RESTART-CASE.

  3. Introduce a macro WITH-CONDITION-RESTARTS

If we can't think of a better syntax for this, leave it out.  It can
always be done, awkwardly, by first making the condition object and
binding it to a variable, then doing a RESTART-CASE with :TEST predicates
that check for the condition being that one and with the expression
just being a call to SIGNAL of that condition.

  4. Extend COMPUTE-RESTARTS, FIND-RESTART, ABORT, CONTINUE, USE-VALUE,
     and STORE-VALUE to permit an optional condition object as an argument.

OK.

  5. Add two new macros SIGNAL-WITH-RESTARTS and ERROR-WITH-RESTARTS:

Same comment as #3.

  6. Define that Common Lisp macros such as CHECK-TYPE, which are defined
     to signal and to make restarts available, use the equivalent of
     WITH-CONDITION-RESTARTS to associate the conditions they signal with
     the defined restarts, so that users can make reliable tests not only
     for the restarts being available, but also for them being available
     for the right reasons.

OK (except don't use the name WITH-CONDITION-RESTARTS).

∂17-Mar-89  1627	CL-Cleanup-mailer 	Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  16:26:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560089; Fri 17-Mar-89 19:24:33 EST
Date: Fri, 17 Mar 89 19:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <890317-102812-1247@Xerox>
Message-ID: <19890318002424.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

I think this one is more correct than the one Larry mailed
to X3J13, in its reflection of the amendments voted in at
the last meeting.  I'll mail it to X3J13 if no one disagrees.

!
Issue:        PACKAGE-FUNCTION-CONSISTENCY
References:   11.7 Package System Functions and Variables (pp182-188)
Category:     CLARIFICATION/CHANGE
Edit history: 21-Oct-88, Version 1 by Pitman
		12-Jan-89, Version 2 by Masinter (add MORE-PERMISSIVE option)
		17-Mar-89, Version 3, by Masinter, MORE-PERMISSIVE as
			amended & adopted at Jan 89 X3j13
		17-Mar-89, Version 4, by Moon, correct amended wording

Problem Description:

  CLtL is vague about whether either or both of package or package name
  are permissible in some cases.

Proposal (PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE):

  Clarify that it is permissible to pass either a package object
  or a package name (symbol or string) in the following situations:
    - the :USE argument to MAKE-PACKAGE or IN-PACKAGE
    - the first argument to IN-PACKAGE, FIND-PACKAGE, RENAME-PACKAGE
			or DELETE-PACKAGE
    - the second argument to INTERN, FIND-SYMBOL, UNINTERN
    - the second argument to EXPORT, UNEXPORT, IMPORT,
      SHADOWING-IMPORT, and SHADOW
    - the first argument (or a member of the list which is the first
      argument) to USE-PACKAGE or UNUSE-PACKAGE.
    - all package-name arguments in DEFPACKAGE except for the name and
      nicknames of the package being defined.
    - the first argument to PACKAGE-NAME, PACKAGE-NICKNAMES, 
      PACKAGE-USE-LIST, or PACKAGE-USED-BY-LIST
    - the PACKAGE argument to DO-SYMBOLS.
    - the PACKAGE argument to DO-EXTERNAL-SYMBOLS.
    - the PACKAGE argument to DO-ALL-SYMBOLS.

  If FIND-PACKAGE is given a package object as an argument, it simply
  returns it.

  Clarify that the function MAKE-PACKAGE permits only a package name
  as an argument since it does not make sense to create an existing
  package.

  Clarify that package nicknames must always be expressed as package
  names (symbols or strings) and may never be actual package objects.

  In the list above, IN-PACKAGE may be changed to SELECT-PACKAGE
  if IN-PACKAGE-FUNCTIONALITY:NEW-MACRO passes.

Examples:

  (INTERN "FOO" "KEYWORD") => :FOO

  (DEFVAR *FOO-PACKAGE* (MAKE-PACKAGE "FOO"))
  (RENAME-PACKAGE "FOO" "FOO0")
  (PACKAGE-NAME *FOO-PACKAGE*) => "FOO0"


  (PACKAGE-NAME "SYS") might return "SYSTEM".

Rationale:

   This makes things more consistent.
   It also adds a generally useful capability.


Current Practice:

  Symbolics Genera & Lucid permit strings as package names.
  Symbolics Cloe does not permit strings as package names.
  In Lucid FIND-PACKAGE and IN-PACKAGE require names.

Cost to Implementors:

  Small.

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  Implementations would continue to vary gratuitously, leaving a potential
  for portability problems.

Benefits:

  The cost of non-adoption is avoided.

Aesthetics:

  This makes things more regular, and so presumably more aesthetic.

Discussion:

  Pitman ran across this problem while trying to port Macsyma to various
  implementations. Discussion with other maintainers of portable programs
  shows this is a common source of aggravation in portable code.

  It would be possible to say that MAKE-PACKAGE took package objects as
  arguments and just returned that package. That might have limited
  usefulness on rare occasions, but mostly seemed too far out in left
  field to bother suggesting it.

∂17-Mar-89  1600	X3J13-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89  16:00:33 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02088g; Fri, 17 Mar 89 15:53:13 PST
Received: by bhopal id AA19366g; Fri, 17 Mar 89 15:55:29 PST
Date: Fri, 17 Mar 89 15:55:29 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903172355.AA19366@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, X3J13@Sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 17 Mar 89 15:51 EST <19890317205125.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)

re: Adding the discussion of SIMPLE-ARRAY was at *+*YOUR*+* request, JonL.

Sorry, Dave, I only ever made a request to add precisely the one statement
that you have already now added -- that the proposal *does not* alter
the CLtL semantics of SIMPLE-ARRAY.  What I critiqued were statements
of the proposal that under reasonable interpretation could be taken to
mean that the CLtL p.28 definition of SIMPLE-ARRAY is being abrogated.

At any rate, thanks for the one-line addition.


-- JonL --

∂17-Mar-89  1613	X3J13-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89  16:13:52 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02119g; Fri, 17 Mar 89 16:06:33 PST
Received: by bhopal id AA19436g; Fri, 17 Mar 89 16:08:50 PST
Date: Fri, 17 Mar 89 16:08:50 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903180008.AA19436@bhopal>
To: barmar@Think.COM
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Fri, 17 Mar 89 15:53 EST <19890317205329.0.BARMAR@OCCAM.THINK.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)

re: I find (1) distasteful, because non-adjustable arrays and the
    SIMPLE-ARRAY type exist solely for the benefit of implementations that
    need them, and this would require support of these concepts in
    implementations that don't derive any benefit from them.  

Barry, SIMPLE-ARRAY is certainly not the only concept in CLtL that exists
"solely for the benefit of implementations that [can really use it]".  I
know that numerous array capabilities are present but not very useful
in Lucid Common Lisp primarily for compatiblity with Lisp Machine stuff.

That's the price to pay for portability.  It just may be that we will have 
to confess that we didn't succeed at portability in some areas of CL.


-- JonL --

∂17-Mar-89  1657	CL-Cleanup-mailer 	Issue: FIXNUM-NON-PORTABLE, v.5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  16:57:14 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560137; Fri 17-Mar-89 19:54:04 EST
Date: Fri, 17 Mar 89 19:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FIXNUM-NON-PORTABLE, v.5
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890316-220933-6804@Xerox>
Message-ID: <19890318005344.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 16 Mar 89 21:51 PST
    From: masinter.pa@Xerox.COM

    This is my rewrite to capture the 'intent' of the amendment
    at the January X3J13. I say 'intent' because the relation
    between MOST-POSITIVE-FIXNUM (which is an inclusive bound)
    and ARRAY-DIMENSION-LIMIT (which is an exclusive bound) is not
    > but rather (>= MOST-POSITIVE-FIXNUM (1- ARRAY-DIMENSION-LIMIT)).

No, the amendment was (<= ARRAY-DIMENSION-LIMIT MOST-POSITIVE-FIXNUM),
and this was not a mistake nor an off-by-one error.  What you've
put in the proposal here is incorrect, I think.  I think it was
fully intended that not only every valid array index and every
array dimension, but also array-dimension-limit itself would be
a fixnum.  Someone might want to write an arithmetic iteration
whose upper bound was array-dimension-limit.

∂17-Mar-89  1656	X3J13-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  16:56:32 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 19:52:28 EST
Date: Fri, 17 Mar 89 19:53 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <8903180008.AA19436@bhopal>
Message-Id: <19890318005322.4.BARMAR@OCCAM.THINK.COM>

    Date: Fri, 17 Mar 89 16:08:50 PST
    From: Jon L White <jonl@lucid.com>

    re: I find (1) distasteful, because non-adjustable arrays and the
	SIMPLE-ARRAY type exist solely for the benefit of implementations that
	need them, and this would require support of these concepts in
	implementations that don't derive any benefit from them.  

    Barry, SIMPLE-ARRAY is certainly not the only concept in CLtL that exists
    "solely for the benefit of implementations that [can really use it]".  I
    know that numerous array capabilities are present but not very useful
    in Lucid Common Lisp primarily for compatiblity with Lisp Machine stuff.

    That's the price to pay for portability.  It just may be that we will have 
    to confess that we didn't succeed at portability in some areas of CL.

    -- JonL --

The general rule has been that implementations that don't need (or don't
provide) these types of optimizations can safely ignore the language
features that support them.  Some implementations can optimize array
access by knowing that the array can't be adjusted; other
implementations should not be required to remember this information if
they don't need it.  Quoting from CLtL: "features that are useful only
on certain 'ordinary' or 'commercial' processors are avoided or made
optional."

Any feature of the language that provides access to facets of the
implementation allows somewhat non-portable code, meaning that it is
possible to write conforming code that produces different results in
different implementations.  The simple program (PROGN
MOST-POSITIVE-FIXNUM) is conforming but produces many different results,
although the program (TYPEP MOST-POSITIVE-FIXNUM 'FIXNUM) is guaranteed
to return T in all conforming implementations.  To paraphrase Moon, it
would be wonderful if all conforming programs were portable, but that's
unrealistic (it would be like expecting the grammar of a language to
only permit sensible sentences to be formed -- I suspect Godel's
Incompleteness Theorem comes into play here, pointing out that if the
grammar allows you to say everything you'd want to say, it must also
include some nonsense).  The best I think we can do is provide enough
tools in the language to allow programs to detect implementation
differences and deal with them.

One thing that would help me is if you would post an example of code
that you feel is affected by this issue.  I think you described such
things to me in words at the last meeting, but I (like GLS) am having a
hard time figuring out precisely what the problem is (I had the same
difficulty with the FIXNUM stuff that started the moby flame session in
the car on the way to the Japanese restaurant).

                                                barmar

∂17-Mar-89  1839	CL-Cleanup-mailer 	Re: Issue: FIXNUM-NON-PORTABLE, v.5 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  18:39:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 18:09:23 PST
Date: 17 Mar 89 18:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FIXNUM-NON-PORTABLE, v.5
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Fri, 17 Mar 89 19:53 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <890317-180923-2962@Xerox>

OK, I'll fix it. Thanks.

Larry



∂17-Mar-89  1949	CL-Cleanup-mailer 	Re: Issue: CONDITION-RESTARTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  19:49:18 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 19:24:08 PST
Date: 17 Mar 89 19:23 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CONDITION-RESTARTS (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Fri, 17 Mar 89 19:15 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@sail.stanford.edu, Mly@AI.AI.MIT.EDU
Message-ID: <890317-192408-3127@Xerox>

I was mailing the "best draft" of all issues we want to discuss to X3J13 in
the hopes that, even if there are new proposals brought to the meeting,
they won't get the "two week" rule applied if they are minor adjustments.

Now that its less than two-weeks until the end of the meeting, I think I'll
stop trying, if the issues aren't ready.

∂17-Mar-89  2009	CL-Cleanup-mailer 	Issue: DEFMACRO-LAMBDA-LIST, v.2    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  20:05:27 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAR 89 19:50:34 PST
Date: 17 Mar 89 19:44 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFMACRO-LAMBDA-LIST, v.2
Message-ID: <890317-195034-3172@Xerox>

I didn't mean to do this, but I started. It took more time
because the last writeup really presumed that &WHOLE wasn't
allowed at inner levels, so I had to mung it to change
that assumption.

However, I really think this is just a clarification of
'current practice'; I'd be suprised to find an implementation
didn't really already conform to this. 

So I rewrote the cost/benefit section; do you know any
counterexamples?

!
Issue:        DEFMACRO-LAMBDA-LIST
Forum:	      Cleanup
References:   8.1 Macro Definition (CLtL pp144-151),
	      Issue DESTRUCTURING-BIND
Category:     CLARIFICATION/CHANGE
Edit history: 30-Jan-89, Version 1 by Pitman
			17-Mar-89, Version 2 by Masinter

Problem Description:

  The description of the DEFMACRO lambda list currently contains some 
  mis-statements and leaves some ambiguities:

  1. Can &BODY, &WHOLE, and &ENVIRONMENT appear at recursive levels of the
     DEFMACRO lambda list?

     The description of &WHOLE (p145) specifies that &WHOLE must occur ``first
     in the lambda list,'' but the description of a lambda list says that 
     ``a lambda may [recursively] appear in place of the parameter name.''
     Consequently, the question arises whether &WHOLE should be permitted to
     be a synonym for &REST at inner levels of a DEFMACRO lambda list.

     The descriptions of &BODY and &ENVIRONMENT do not contain syntactic
     restrictions on where they may appear.

  2. Does using &WHOLE affect the pattern of arguments permitted by DEFMACRO.

Proposal (DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION):

  1. a. Specify that &BODY may appear at any level of a DEFMACRO lambda list.

     b. Specify that &WHOLE may only appear at any level of a DEFMACRO
        lambda list. At inner levels, the &WHOLE variable is bound to
		the corresponding part of the argument, as with &REST, but
		unlike &REST, other arguments are also allowed.

     c. Specify that &ENVIRONMENT may only appear at the top level of a
	DEFMACRO lambda list.

  2. Clarify that using &WHOLE does not affect the pattern of arguments
     specified by DEFMACRO.

Examples:

  1. (DEFMACRO DM1A (&WHOLE FORM A B)  ...) is defined.
     (DEFMACRO DM1B (A (&WHOLE B C &OPTIONAL D) E) ...) is defined.
		It allows simultaneousaccess to the THIRD of the whole
		form as B and to the destructuring of that list into
		C and D.

     (DEFMACRO DM1C (A B &ENVIRONMENT ENV) ...)     is defined.
     (DEFMACRO DM1D (A (B &ENVIRONMENT ENV) C) ...) is undefined.

     (DEFMACRO DM1E (A B &BODY X) ...)     is defined.
     (DEFMACRO DM1F (A (B &BODY X) C) ...) is defined.

  2. (DEFMACRO DM2A (&WHOLE X) `',X)

     (MACROEXPAND '(DM2A))   => (QUOTE (DM2A))
     (MACROEXPAND '(DM2A A)) is an error.

     (DEFMACRO DM2B (&WHOLE X A &OPTIONAL B) `'(,X ,A ,B))
     
     (MACROEXPAND '(DM2B))       is an error.
     (MACROEXPAND '(DM2B Q))     => (QUOTE ((DM2B Q) Q NIL))
     (MACROEXPAND '(DM2B Q R))   => (QUOTE ((DM2B Q R) Q R))
     (MACROEXPAND '(DM2B Q R S)) is an error.

Rationale:

  1. a. An example on p151 makes it clear that this was the intent.

	b. There's no cogent reason to forbid &WHOLE at inner levels.
     The example on p.150 uses &WHOLE in a non-top-level position.

	This simplifies the implementation of DEFMACRO if we introduce a
        DESTRUCTURING-BIND which does not understand &ENVIRONMENT.

     c. The environment is never different at top level than embedded.
	Permitting &ENVIRONMENT to occur embedded would only encourage
	the misconception that there was a potential difference.

	This simplifies the implementation of DEFMACRO if we introduce a
        DESTRUCTURING-BIND which does not understand &ENVIRONMENT.

  2. This allows useful syntax checking.

     One can always trivially write
	(DEFMACRO ... (&WHOLE FORM &REST IGNORE) ...)
     to get around the error checking this forces.

Current Practice:

  1. a. Symbolics Genera permits &BODY at any level. This is compatible.
     b. Symbolics Genera seems to permit &WHOLE at any level. When embedded,
	it is treated as a synonym for &REST. 
     c. Symbolics Genera does not permit &ENVIRONMENT except at top level.
	This is compatible.

  2. Symbolics Genera has this behavior when &WHOLE appears at top level,
     but not at recursive levels (where &WHOLE is treated as a synonym for
     &REST).

Cost to Implementors:

  This seems to be what CLtL intended and what most implementations
  perform.

Cost to Users:

  We think this is possibly (probably) upward compatible with most
  current practice.

Cost of Non-Adoption:

  Some fuzzy places in DEFMACRO continue to exist.

  It's harder to introduce DESTRUCTURING-BIND because describing its relation
  to DEFMACRO is difficult.

Benefits:

  The language is a little tighter.

Aesthetics:

  Negligible impact.

Discussion:

  Part 2 of this issue came up during the discussion of DOTTED-MACRO-FORMS
  but was not pursued until now.

  Pitman supports these clarifications.

  A previous version disallowed &WHOLE at inner levels, because
  of the mistaken impression that &WHOLE was equivalent to &REST.
  However, additional arguments are not allowed after &REST,
  while they are for &WHOLE.

∂17-Mar-89  2126	CL-Cleanup-mailer 	New issue: WITH-OPEN-FILE-DOES-NOT-EXIST 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  21:25:40 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA23966; Fri, 17 Mar 89 21:26:15 PST
Received: from denali.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA08587; Fri, 17 Mar 89 21:22:28 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
	id AA21223; Fri, 17 Mar 89 21:25:44 PST
Message-Id: <8903180525.AA21223@denali.sun.com>
To: cl-cleanup@sail.stanford.edu
Subject: New issue: WITH-OPEN-FILE-DOES-NOT-EXIST
Date: Fri, 17 Mar 89 21:25:42 PST
From: peck@Sun.COM

    Really a request for an editorial change, so users will know what
to expect. A user actually reported this as a bug...
Unless someone believes that STREAM-IS-NIL is wrong, this could just
be forwarded to editorial.

Issue:         WITH-OPEN-FILE-DOES-NOT-EXIST
References:    CLtL page 422
Category:      Clarify
Edit history:  17-Mar-89, Version 1

Problem description:
The documentation for WITH-OPEN-FILE (p 422) says:
  "WITH-OPEN-FILE evaluates the Forms of the body (an implict PROGN)
with the variable Stream bound to a stream that reads or writes the
file named by the value of Filename. The options are evaluated and
used as keyword arguments to the function OPEN."

  It is not clear what to do when there is no stream
"that reads or writes the file" named by Filename.
  Is the body evaluated? What is Stream bound to?

Proposal: WITH-OPEN-FILE-DOES-NOT-EXIST:DONT-EVALUATE
  If the result of OPEN does not return a stream (eg returns NIL)
Then the body of WITH-OPEN-FILE is not evaluated, NIL is returned.

Rationale:
  The contract that "the body is evaluated with ... bound to a stream"
is maintained in the sense of a vacuous evalation.
  The alternatives are:
    To let the stream variable be bound to NIL (unintuitive and dangerous).
    If users want to Signal-An-Error in this case, they can use
    :if-does-not-exist :error  
  The test for (STREAMP Stream) is probably done anyway,
    since the UNWIND-PROTECT cleanup form can't call CLOSE on NIL.

Proposal: WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL
  Clarify the documentation to explain that:
    Stream is bound to the value returned by OPEN.
    Users of :if-does-not-exist NIL should check for a valid stream.

Rationale:
  This simple to implement, no extra testing is done.
  Users who use :if-does-not-exist NIL  can wrap their body forms
with (when (STREAMP Stream) ...)

Examples:
1. (WITH-OPEN-FILE (foo "no-such-file" :IF-DOES-NOT-EXIST nil)
	(READ foo) t)
   DONT-EVALUATE: => NIL, no I/O is done, do not read from *standard-input*
   STREAM-IS-NIL: => T, reads from *standard-input*

2. (WITH-OPEN-FILE (foo "/no-dir" :direction :output :IF-DOES-NOT-EXIST nil)
	(format foo t) t)
   DONT-EVALUATE: => NIL, no string is created.
   STREAM-IS-NIL: => T, creates a string and writes to it.

Current practice:
    Symbolics and Lucid apparently implement STREAM-IS-NIL.

Cost to Implementors:
    STREAM-IS-NIL: no cost.
    DONT-EVALUATE:
        Trivial? to test for :if-does-not-exist NIL and supply a 
        test for (STREAMP Stream) in that case [or in every case].

Cost to Users:
    DONT-EVALUATE: System tests for (STREAMP Stream), possibly extraneously.
    STREAM-IS-NIL: User must write a test for (STREAMP Stream).
  Probably no portable code uses :if-does-not-exist NIL without
  testing explicitly for (STREAMP Stream).

Cost of non-adoption:
    The current situation is non-intuitive and/or confusing.

Benefits:
    Users would know if the STREAMP test has been done or whether 
they must supply it.

Esthetics:

Discussion:

∂17-Mar-89  2128	CL-Cleanup-mailer 	Re: DEFAULT-CASE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  21:28:18 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 21:25:52 PST
Date: 17 Mar 89 21:25 PST
From: masinter.pa@Xerox.COM
Subject: Re: DEFAULT-CASE
In-reply-to: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)'s
 message of Thu, 16 Mar 89 12:21:57 PST
To: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
cc: CL-Cleanup@sail.stanford.EDU
Message-ID: <890317-212552-3367@Xerox>

I'm going to unilaterally declare that this issue is not a "cleanup".

If you or someone else wants to raise it at X3J13, you should request
time on the agenda to bring it up and discuss it.

∂17-Mar-89  2140	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED, v.5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  21:40:20 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 560258; 18 Mar 89 00:37:50 EST
Date: Sat, 18 Mar 89 00:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <890316-175451-6328@Xerox>
Message-ID: <19890318053740.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

This version looks okay as far as making the amendments goes, but
in reading it over I noticed some problems that are really with
the original proposal.  If we have to go over this issue again,
I think we should consider fixing these problems too.

(1) Why are the following types omitted from part (a), the list
of types for which TYPE-OF must be specific:
  BIT-VECTOR NULL SEQUENCE

I constructed this list from 88-002R pp.1-16 and 1-17, and from the
specifications of which types are exhaustive partitions, I didn't
make it up randomly.

(2) Why are the following types omitted from part (a), the list
of types for which TYPE-OF must be specific:
  BIGNUM FIXNUM KEYWORD STANDARD-CHAR STRING-CHAR
  (replace STRING-CHAR with BASE-CHARACTER if that proposal passes)

Unlike the first list, I constructed this one randomly out of my head.
It's all the standard "interesting" subtypes of the types that are
already listed in part (a), excluding the simple array subtypes.

(3) The statement "For all objects for which CLASS-OF returns a class
with a proper name, TYPE-OF returns that proper name." is questionable.
For example, part (a) requires that TYPE-OF a single-float must return
SINGLE-FLOAT or a subtype of it, but 88-002R requires that CLASS-OF a
single-float be a class whose proper name is FLOAT, or an implementation
dependent subclass of that class.  This proposal will force
implementations to create such subclasses, which should be done on its
own merits, not through the back door.  Another example is that for
arrays, TYPE-OF will not be able to return a list that encodes the
element-type and dimensions, unless there are implementation dependent
classes corresponding to every such type specifier.  There is a really
baroque way to get around this, which is to define an implementation
dependent subclass of ARRAY that has a non-null name that is not its
proper name; this slips through a loophole in the proposal and allows
TYPE-OF to return any subtype of ARRAY.  I claim that loophole is a
bug too.

To fix these bugs, I suggest removing the four paragraphs that contain
the three references to CLASS-OF, and replacing them with:

(d) The type returned by TYPE-OF is always a subtype of the class
returned by CLASS-OF, and is a subtype that the implementation's
SUBTYPEP can recognize.

(e) For objects of metaclass STRUCTURE-CLASS or STANDARD-CLASS,
TYPE-OF returns the proper name of the class returned by CLASS-OF
if it has a proper name, and otherwise returns the class itself.

In particular, for objects created by the "constructor" function
of a structure defined with DEFSTRUCT without a :TYPE option,
TYPE-OF will return the structure name.

(4) I suggest modifying part (c) to exclude SATISFIES, AND, OR,
NOT, and VALUES in addition to MEMBER and T.  Of course part (c)
is a very weak restriction, since TYPE-OF is perfectly free to
return a symbol that is DEFTYPEd to one of these type specifiers,
as long as the other requirements are met.

∂17-Mar-89  2153	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  21:53:22 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 21:50:37 PST
Date: 17 Mar 89 21:50 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
 message of Wed, 15 Mar 89 15:57:02 GMT
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: Kent M Pitman <KMP@scrc-stony-brook.arpa>, Masinter.PA@Xerox.COM,
 CL-Cleanup@sail.stanford.edu
Message-ID: <890317-215037-3421@Xerox>

I think the issue is the handling of the printer. PRINT, when
*PRINT-ESCAPE* is set. needs to look at the case of the readtable to know
how to print out things so they will read in correctly.

Take symbols with symbol-name "Frob" and "FROB" respectively.

	               print	            print
Symbol-name    case-sensitive    case-insensitive

Frob	            Frob	               |Frob|
FROB	            FROB	               frob, Frob, or FROB
	            	                     (depending on *PRINT-CASE*)

     

I think this is a "cleanup" issue, since it is a minor extension
to the feature of readtables and is upward compatible. 

∂17-Mar-89  2223	CL-Cleanup-mailer 	Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  22:23:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 22:14:13 PST
Date: 17 Mar 89 22:09 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Sat, 18 Mar 89 00:37 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890317-221413-3463@Xerox>

I think BIT-VECTOR might have been an omission.

NULL was left out because it seemed silly and at odds with current practice
to require that (TYPE-OF 'NIL) = NULL.  However, if (CLASS-OF 'NIL) is the
special NULL class, then we would have to reconsider.

SEQUENCE was left out because it is an 'abstract' class and is (as far as
the standard is concerned) exhaustively partitioned by VECTOR and LIST
which are already "lower bounds" of TYPE-OF.

BIGNUM and FIXNUM were left out because their division was implementation
dependent.

KEYWORD was left out because under odd circumstances it is possible to
dynamically change the 'type' (e.g., by UNINTERN).

STANDARD-CHAR and STRING-CHAR were left out for the same reasons they
aren't built-in classes.

- - - - -
I like your proposed fixes to the CLASS-OF wording.

- - - - -

About part (c): the restriction on T is meaningless, since the CLASS-OF
restriction dominates it. The restriction on MEMBER is OK, just to keep
TYPE-OF from being the silly definition that (type-of x) = `(member ,x).  I
think we're running out of good reasons to leave out SATISFIES, AND, OR,
NOT, and VALUES; they're probably no more useful, but we're probably
overspecifying for no good reason.

However, I'll be happy to go along with whatever you feel is right on this
one...

∂17-Mar-89  2235	CL-Cleanup-mailer 	Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  22:35:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560283; Sat 18-Mar-89 01:32:31 EST
Date: Sat, 18 Mar 89 01:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE (version 3)
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8903152049.AA03416@verdi.think.com>
Message-ID: <19890318063223.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

In general I like this.  Certainly I like the idea of having a
standardized interface for extending the pretty-printer, and I believe
that this particular pretty-printer is based on a good underlying
theory, certainly the best theory that I have seen.  However, I don't
think this is ready to go into the standard in its current form.  Some
of these comments are on the programmer interface, others are just on
the way the proposal is presented.

I could not find any specification of the units of measurement for
*PRINT-RIGHT-MARGIN*, *DEFAULT-RIGHT-MARGIN*, *PRINT-MISER-WIDTH*,
indentation, and tabulation.  It's not even clear that margins,
indentation, and tabulation can't be measured in three different
units.  Analysis of the examples suggests that the units are
assumed to be characters and all characters are assumed to be the
same width.  This is not an implementation-independent assumption.
In any case the proposal has to be specific about the units.  I
would prefer something that seamlessly accomodates variable-width
characters, but don't have enough experience with pretty-printers
to propose anything myself.

I would like to be able to vote on the FORMAT-based interface and
the functional interface separately.

I would like to see the DEFINE-PRINT-DISPATCH mechanism recast in terms
of DEFMETHOD and a PRETTY-PRINT-OBJECT generic function.  If DEFMETHOD
is deficient and unable to provide all the necessary features, I think
we need to know that before it's too late to amend CLOS.  I don't see
any problems myself, other than the need to replace the funny extension
to the CONS type-specifier with passing of the CAR of the CONS as a
separate argument so an EQL parameter specializer can be used.

I'd like to suggest some improvements to the syntax of
WITHIN-LOGICAL-BLOCK, based on Symbolics experience with similar macros:

  Instead of separate :STREAM and :VAR keywords, it works better to have
  only a :STREAM keyword, whose value must be a symbol.  This symbol
  is evaluated to get the stream, and also is bound around the body to
  a (possibly new) stream.  This simplifies the syntax and avoids the
  risk of accidentally writing to the wrong stream.
  Defaulting to *STANDARD-OUTPUT* and handling T and NIL is correct here
  (:STREAM NIL means *STANDARD-OUTPUT* is the variable that gets bound.)
  
  Since the :ARG argument appears to be mandatory, it should be a
  required argument preceding the keyword arguments.  This would also
  eliminate the meaningless keyword name for this argument.
  
  It would be nice if the :PREFIX, :PER-LINE-PREFIX, and :SUFFIX
  arguments could be functions as well as strings, to allow more control
  over the printing of this information.  That's not essential, but it
  would for example make it easier to print special characters.

The :FROM-START and :FROM-POSITION values for KIND in LOGICAL-BLOCK-INDENT
are too easily confused.  I suggest renaming them to :BLOCK and :CURRENT
and renaming the argument to RELATIVE-TO.

The functional interface is missing equivalents for the
~/TABULAR-STYLE/, ~/FILL-STYLE/, and ~/LINEAR-STYLE/ features.
I think it's better to provide these as predefined functions
than to make the user define them himself.

∂17-Mar-89  2254	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  22:54:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560294; Sat 18-Mar-89 01:50:31 EST
Date: Sat, 18 Mar 89 01:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel <rpg@lucid.com>
cc: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: <8903120142.AA00878@defun.utah.edu>
Message-ID: <19890318065022.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

There are a couple of small changes that seem warranted:

   MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
   SLOT-VALUE-USING-CLASS.  MAKE-LOAD-FORM-FROM-SLOTS is better,
   except for form/from dyslexia.  MAKE-LOAD-FORM-FOR-SLOTS ?

   Maybe there should be a SIMILAR-AS-CONSTANTS generic function
   for the benefit of CONSTANT-COLLAPSING.  In the absence of that
   we're just using EQ.

On the subject of this proposed alternative:

    Date: Sat, 11 Mar 89 18:42:56 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    Have two generic functions, not one.  The first would get called by
    compile-file and it would return a list of components (or whatever)
    that are required to reconstruct the object.  The compiler would dump
    this list of objects in its usual way.  The loader would apply the
    second generic function to this list to reconstruct the object.  

This is exactly the way I did the first implementation of this idea,
back in about 1978.  It didn't work very well, basically for two reasons.
One is that representing information in the form of lists is pretty
impoverished and it's very easy to get the list the wrong length or
out of order; it's also more difficult than it should be to make
upward-compatible changes, because the new format always has to be
a superset of the old format.  Forms are more general.  You can make
upward-compatible changes by inventing a new function name and keeping
the old function name around forever with the old semantics; this also
ensures an undefined-function error if the new format is loaded into
the old system.

The second reason is more serious.  The way you propose cannot be nicely
extended to deal with circular structures, because it fails to separate
object creation from object initialization.  The second generic function
does both operations.  My application used circular structures
extensively and had a fairly horrible kludge for them, involving standin
objects that were replaced with the correct objects later in loading;
this was fragile and permeated the reconstruction methods, all the worst
characteristics for this kind of thing.

On the subject of forms versus functions as the interface, I think
David Gray has expressed very well the reasons why that is not
practical, at least at Common Lisp's present stage of development.

I've read all the mail on the subject, but I stand by LOAD-OBJECTS
version 3.  There may be more thought behind this proposal than is
apparent at first glance.

∂17-Mar-89  2300	CL-Cleanup-mailer 	Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89  23:00:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560300; Sat 18-Mar-89 01:57:45 EST
Date: Sat, 18 Mar 89 01:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890317-221413-3463@Xerox>
Message-ID: <19890318065727.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 17 Mar 89 22:09 PST
    From: masinter.pa@Xerox.COM

    I think BIT-VECTOR might have been an omission.

    NULL was left out because it seemed silly and at odds with current practice
    to require that (TYPE-OF 'NIL) = NULL.  However, if (CLASS-OF 'NIL) is the
    special NULL class, then we would have to reconsider.

In Symbolics Genera 7.4, (TYPE-OF 'NIL) => NULL, so that's some current
practice.  88-002R mandates (SUBTYPEP (CLASS-OF 'NIL) (FIND-CLASS 'NULL)).

    SEQUENCE was left out because it is an 'abstract' class and is (as far as
    the standard is concerned) exhaustively partitioned by VECTOR and LIST
    which are already "lower bounds" of TYPE-OF.

It is not an exhaustive partition, according to CLtL p.35.  I put
SEQUENCE in so that if an implementation adds a third kind of SEQUENCE,
TYPE-OF can't be any less specific than SEQUENCE.  This is the same reason
that RATIONAL, FLOAT, and NUMBER are in.

    BIGNUM and FIXNUM were left out because their division was implementation
    dependent.

    KEYWORD was left out because under odd circumstances it is possible to
    dynamically change the 'type' (e.g., by UNINTERN).

    STANDARD-CHAR and STRING-CHAR were left out for the same reasons they
    aren't built-in classes.

I'll buy the above three paragraphs, although I don't think any of them
are 100% compelling.

∂17-Mar-89  2320	CL-Cleanup-mailer 	Re: Issue: PLUS-ABNORMAL (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  23:20:10 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 23:17:01 PST
Date: 17 Mar 89 23:16 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PLUS-ABNORMAL (Version 1)
In-reply-to: masinter.pa's message of 15 Mar 89 07:33 PST
To: CL-Cleanup@SAIL.Stanford.EDU, skona%csilvax@hub.ucsb.edu
Message-ID: <890317-231701-3536@Xerox>

Can we drop this one? Complaints only.

∂17-Mar-89  2357	CL-Cleanup-mailer 	Re: environment argument for SUBTYPEP    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89  23:57:39 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 23:54:56 PST
Date: 17 Mar 89 23:54 PST
From: masinter.pa@Xerox.COM
Subject: Re: environment argument for SUBTYPEP
In-reply-to: David N Gray <Gray@DSG.csc.ti.com>'s message of Wed, 11 Jan 89
 15:57:47 CST
To: David N Gray <Gray@DSG.csc.ti.com>, cl-cleanup@sail.stanford.edu, "Kim
 A. Barrett" <IIM@ECLA.USC.EDU>
Message-ID: <890317-235456-3561@Xerox>

Somehow I dropped some mail; I don't have the proposal, although there's a
reference to version 1 of SUBTYPEP-ENVIRONMENT. Is this ready?

∂18-Mar-89  0026	CL-Cleanup-mailer 	[cl-cleanup@sail.stanford.edu: Issue:    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Mar 89  00:26:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 18 MAR 89 00:24:02 PST
Date: 18 Mar 89 00:22 PST
From: masinter.pa@Xerox.COM
Subject: [cl-cleanup@sail.stanford.edu: Issue:
 UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)]
To: rpg@lucid.com, gregor.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890318-002402-3587@Xerox>

Moon's notes from Jan 89 X3J13:

"Lumping SLOT-UNBOUND in with unbound special variables was a mistake,
as SLOT-UNBOUND is an extension mechanism, not only a safety checking
mechanism.  Also there were some wording problems.  Gabriel and Gregor
are to submit a revised proposal."

No revised proposal has been submitted.

Now that you know what "safe" is, you can safely do so. Eh?



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

Date: 11 Jan 89 23:45 PST
Sender: masinter.pa
Subject: Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter
line-fold: No

It was believed that this issue might be controversial.
!
Issue:        UNDEFINED-VARIABLES-AND-FUNCTIONS
References:   5.1.2 Variables (CLtL pp55-56),
	      Slots (88-002R, p1-10)
Category:     CHANGE
Edit history: 29-Nov-88, Version 1 by Pitman

Problem Description:

  CLtL does not specify what happens if you attempt to call a named function
  which is in fact undefined. In most implementations, it would be devastating to
  actually jump to code which you had not verified to be a function, so this error
  should be easily caught -- yet, CLtL does not guarantee that an error will be
  signalled even in the safest, least fast OPTIMIZE settings.

  CLtL (p56) specifies that "it is an error to refer to a variable that is unbound."

  CLOS (p1-10) specifies that "when an unbound slot is read, the generic function
  SLOT-UNBOUND is invoked. The system-supplied primary method for SLOT-UNBOUND
  signals an error."

  CLOS and CLtL are not in agreement on their treatment of unbound variables.

  CLtL is very weak in that it guarantees no support for reliably detecting
  and signalling an error when the error situation occurs, even in the safest,
  least fast OPTIMIZE setting.

  CLOS is very strong in that it forces detection of the error in all
  situations -- even in the fastest, least safe OPTIMIZE setting.

  The disparate positions for treatment of variables and slots should be
  reconciled, either by finding a compromise or by justifying the apparent
  inconsistency. The final story should explain function references as well.

Proposal (UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE):

  Define that reading an undefined function, an unbound variable, or 
  an unbound slot must be detected in the highest safety setting,
  but the effect is undefined in any other safety setting. That is,
   - Reading an undefined function should signal an error.
   - Reading an an unbound variable should signal an error.
   - Reading an unbound slot should invoke the function SLOT-UNBOUND.

  By ``reading an undefined function'' in the above, we mean to 
  include both references to the function using the FUNCTION 
  special form, such as F in (FUNCTION F) and references to the
  function in a call, such as F in (F X).

  For the case of INLINE functions (in implementations where they are
  supported), it is permissible to consider that performing the inlining
  constitutes the read, so that an FBOUNDP check need not be done at
  execution time. Put another way, the effect of FMAKUNBOUND of a function
  on potentially inlined references to that function is undefined.

  Specify that the type of error signalled when an undefined function
  is detected is UNDEFINED-FUNCTION, and that the NAME slot of the
  UNDEFINED-FUNCTION condition is initialized to the name of the
  offending function.

  Specify that the type of error signalled when a unbound variable 
  is detected is UNBOUND-VARIABLE, and that the NAME slot of the
  UNBOUND-VARIABLE condition is initialized to the name of the
  offending variable.

  Introduce a new condition type, UNBOUND-SLOT, which inherits from
  CELL-ERROR. This new type has an additional slot, INSTANCE, which
  can be initialized using the :INSTANCE keyword to MAKE-CONDITION.
  Introdue a new function UNBOUND-SLOT-INSTANCE to access INSTANCE slot.

  Specify that the type of error signalled by the default primary
  method for the SLOT-UNBOUND generic function is UNBOUND-SLOT,
  and that the NAME slot of the UNBOUND-SLOT condition is initialized
  to the name of the offending variable, and that the INSTANCE slot
  of the UNBOUND-SLOT condition is initialized to the offending instance.

Test Case:

  (PROCLAIM '(OPTIMIZE (SAFETY 3) (SPEED 0)))
  (DEFUN FOO () X)
  (FOO)
  >>Error: The variable X is not bound.
  ...

Rationale:

  This makes it easier to treat slots like variables.

  This makes it possible to better rely on an unbound variable error being
  signalled when one has occurred.

  This makes it possible to compile out useless error checking in CLOS
  code where the code is debugged and the checking is redundant.

  For the case of undefined functions, blindly jumping to an undefined
  function is an incredibly dangerous thing to do. Every implementation
  should guarantee at least some way to get error checking of undefined
  functions.

Current Practice:

  Until recently, Symbolics Cloe did not ever signal an error on unbound
  variable, even in the safest case. The excuse was that this was a CLtL
  didn't require it, but it was sometimes an impediment to debugging.

  Some benchmarks for Symbolics Cloe (which currently only claims to
  implement New Flavors, not CLOS) could be faster if checking for unbound
  instance variables could be optimized away.

  Symbolics Genera doesn't care about safety issues in variable access
  because the check can be done by microcode.

Cost to Implementors:

  This change does not force a change to any current implementation, except
  those which do not yet signal unbound variable or undefined function errors
  even in the safest setting.

Cost to Users:

  This checking might slow down some code which is written for the safest
  setting yet does not need this check.

  Any implementation-specific code which depended on these references not
  signalling would be broken. Such code was not portable, of course.

  Any CLOS code which depends on SLOT-UNBOUND being called even in low safety
  settings would be broken. The amount of such code at this point is likely
  to be little or none. If such cases did exist, local or global changes to
  safety settings would correct the problem (at some cost in speed).

Cost of Non-Adoption:

  Some important error checking would not occur.
  Some important optimizations could not be done.
  The language would seem internally less consistent.

Benefits:

  The costs of non-adoption would be avoided.

Aesthetics:

  This would regularize things a little.

Discussion:

  Pitman thinks this would be a good idea.


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

∂18-Mar-89  0122	CL-Cleanup-mailer 	Cleanup Issue Status List 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Mar 89  01:22:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 18 MAR 89 01:19:53 PST
Date: 18 Mar 89 01:19 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Cleanup Issue Status List
Message-ID: <890318-011953-3626@Xerox>

I think this issue status is up to date.

I think I have updated versions of all pending and passed
issues stored on arisia.xerox.com under the
	clcleanup/pending
	clcleanup/passed

directories respectively.


I'm pretty much unavailable (travelling, etc.)
until the meeting. If there are new versions
of any issues that are ready for release, or any
new issues that are important, please email to X3J13.

I'll try to read my mail while on the road, but
it will be difficult to handle the quantity we've
seen in the last week.

I'll send a short version of this list to X3J13.

Codes:

! released for Jan 89 meeting
+ passed
- withdrawn, failed, tabled indefinitely, etc.
* need new version


!*: released, but I know we'll need a new version
+*: passed, but need to reconsider
!*: passed, but need a new version to reconsider

!

+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988

+ ADJUST-ARRAY-FILL-POINTER
 Version 1, 15-MAR-88
Status: passed, 1988

! ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments:  amendment had wording problem.
Version 8, 11-Mar-89, Released 15-Mar-89
Status: ready for vote 

- ALIST-NIL
Version 4, 1-Oct-88
Status: Withdrawn, recommend editorial

- APPEND-ATOM
Synopsis: atom case of APPEND (left out of APPEND-DOTTED)
Version 1, 6-Dec-88, Released 12-Jan-89
Status: withdrawn 18-Jan-89 because APPEND-DOTTED withdrawn

- APPEND-DOTTED
14-JAN-88, Version 5
Status: Passed Nov 88 X3J13, reconsidered & withdrawn Jan 89 X3J13

+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13

+ AREF-1D
14-NOV-87, Version 7
Status: Passed, 1988?

+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13

+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13

+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?

- BACKQUOTE-COMMA-ATSIGN-DOT
Synopsis:  `(... ,@x) vs `(... . ,x). Same, different, is error?
Version 1, 22-Dec-88, DRAFT released
Comments: proposals INTERCHANGABLE and DIVERGENT comments not in writeup 
Status: Withdrawn, since APPEND-DOTTED withdrawn. Default is IS ERROR

! BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Comment: leaves out a case
Status: ready for vote

! CLOS-CONDITIONS
Version 4, 10-Mar-89
Comments: define metaclass of conditions? 
Status: pending

+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13

!+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at meeting
Version 7, 14-Feb-89
Status: Passed, as amended, Jan 89 X3J13
Comment: amendment bad; reconsider version 5.
	say that INPUT-STREAM-P and OUTPUT-STREAM-P
	are undefined on closed streams?

! COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: ready for voting

+ COLON-NUMBER
Synopsis:  :123 is an error
22-OCT-87, Version 1
Status: Passed, 1988?

+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988?

+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13

!* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version

+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13

! COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: ready for vote

! COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: ready for vote

+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
4-SEP-88 Version 2
Status: Passed, 1988?

+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13

+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89
Status: passed, Jan 89 X3J13

+ DECLARE-FUNCTION-AMBIGUITY
Version 4,  5-Dec-88, Released  5-Dec-88
Status: passed, Jan 89 X3J13

+ DECLARE-MACROS
5-FEB-88, Version 3
Status: Passed, 1988?

+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13

- DECLARE-TYPE-USER-DEFINED
Synopsis: allow (declare ((signed-byte 8) x y z)) for all type specifiers?
Status: Withdrawn (never submitted)

+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13

- DEFINITION-DELETE
Synopsis: provide a way to get rid of structures, etc. 
Status: not submitted

* DEFMACRO-LAMBDA-LIST
Version 2, 17-Mar-89
Status: ready for release?

+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13

- DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
Synopsis: defstruct accessors are proclaimed inline
Version 2,  7-Jan-89, released 10-Jan-89
Status: rejected, Jan 89 X3J13 

+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988

+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 3, 6-Feb-89
Status: Passed (as amended) Jan 89 X3J13

+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988

+ DEFVAR-DOCUMENTATION
23-NOV-87, Version 2
Status: Passed, 1988?

+ DEFVAR-INIT-TIME
29-MAR-87, Version 2
Status: Passed, 1988?

+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988?

- DELETE-FILE-NONEXISTENT 
Version 1, 5-Oct-88
Comments: should just signal different errors? 
Status: withdrawn/tabled?

+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13

! DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
status: ready for vote

!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Status: might need new version before vote

+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988

+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988?

+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13

+ DRIBBLE-TECHNIQUE
14-FEB-88, Version 2
Status: Passed, 1988?

! DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Comments: still some holes
Status: ready for vote?

- ELIMINATE-FORCED-CONSING
Synopsis: Add :RECYCLE or :MODIFY to some sequence fns,
Version 3, 31-Aug-88
Status: withdrawn

- ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
   value in consistent format across implementations. This makes
   them virtually useless. I would like to constrain the values
   enough so that implementors knew what to provide as return
   values, and provide some examples of intended uses."
Status: no volunteer to submit

+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Status: Passed with amendments
Version 7, 15-Mar-89
Status: Passed Jan 89 X3J13 as amended.

* EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Comments: Various problems being worked on
Status: ** NEED NEW VERSION ***

* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: ** NEED NEW VERSION **

! ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: ready for vote

+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?

! EXIT-EXTENT
Version 6,  8-Jan-89, distributed at Jan89 X3J13
Rereleased 16-Mar-89
Status: tabled Jan89; ready for vote

+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13

- EXPT-ZERO-ZERO
Synopsis: (EXPT 0.0 0.0) should be undefined
Version 1, 27-Feb-89
Status: withdrawn

- FILE-LENGTH-PATHNAME 
Synopsis: extend FILE-LENGTH to work on pathnames
Status: not submitted/ withdrawn

- FILE-WRITE-DATE-IF-NOT-EXISTS
Synopsis: What does FILE-WRITE-DATE do if no such file?
Version: no proposal
Status:  => ERRORS-IN-FILE-SYSTEM-CHAPTER????

+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended

+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988?

+ FLET-IMPLICIT-BLOCK
Version 6 5-JUN-87
Status: Passed, 1988?

- FOLLOW-SYNONYM-STREAM
Comment: lost in STREAM-ACCESS.
Status: Withdrawn?

+ FORMAT-ATSIGN-COLON
Version 4 5-JUN-87
Status: Passed, 1988?

+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988?

+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988?

+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13

+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988?

- FORMAT-NEGATIVE-PARAMETERS
Synopsis: What does FORMAT do when it gets negative numbers for count?
Version: No proposal
Comment: KMP will incorporate in the list-of-signals part of the signal
proposal?
Status: not submitted

* FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: no proposal

+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13

- FORMAT-ROUNDING
Synopsis: specify that ~F rounds up
Version 1, 5-Oct-88
Status: withdrawn

- FUNCTION-ARGUMENT-LIST
Synopsis: want way to get argument list
Status: not submitted

+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988

! FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: ready for vote?

+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89 
Status: Passed (as amended) Jan 89 X3J13
     maybe this was passed as amendment to TEST-NOT-IF-NOT instead

+ FUNCTION-DEFINITION
Version 3, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13

! FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
SETF-FUNCTION-VS-MACRO
 Version 3, 4-Nov-87, Released Nov 87
SETF-PLACES
 Version 1, 11-Nov-88, Released 9-Dec-88
FUNCTION-NAME
 Version 1, 27-Jan-89, Released 16-Mar-89
Status: ready for vote

+ FUNCTION-TYPE
Version 12, 4-SEP-88
Status: Passed, June 1988 X3J13, as amended

+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released  12-Dec-88
Status: Passed, Jan 89 X3J13

+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88 
Status: Passed, 1988

+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13

- GCD-NO-ARGUMENTS
Synopsis: make (GCD) undefined
Status: not submitted

! GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 1, 14-Feb-89, Released 14-Mar-89
Status: comments
Version 2, 16-Mar-89
Status: ready for release? 

- GET-MACRO-CHARACTER-DISPATCHING
Synopsis: What does GET-MACRO-CHARACTER return for dispatching macros?
Status: not submitted

+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89
Status: Passed (as amended) Jan 89 X3J13

+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988?

! HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88, released 16-Mar-89
status: vote 

- HASH-TABLE-GC
Synopsis: allow hash tables with GCable keys
Status: no proposal

+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
 from the generator in  the wrong order.
Status: passed, Jan 89 X3J13

* HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal

- HASH-TABLE-STABILITY
Version 1, 11-Nov-88, Released 12 Dec 88
Comments: superceded HASH-TABLE-KEY-MODIFICATION
Status: Rejected Jan 89 X3J13

+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 8 8
Status: passed Jan 89 X3J13

+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13

* IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89

+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5 ??-MAY-87
Status: Passed, 1988?

! IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Status: tabled
Version 8, 15-Mar-89, Released 15-Mar-89
Status: ready for vote

- IN-SYNTAX
Synopsis: like IN-PACKAGE but for readtables
Version 1, 21-Oct-88
Comments: important issue: default environment for LOAD
Status: can we withdraw?

- INPUT-STREAM-P-CLOSED
Synopsis: What do INPUT-STREAM-P and OUTPUT-STREAM-P do on closed streams?
Status: not submitted

- INPUT-STREAM-P-EXAMPLE
Synopsis: (input-stream-p (make-broadcast-stream)) is NIL
Version 1, 26-Oct-88
Status: bug report, needs no clarification?

+ KEYWORD-ARGUMENT-NAME-PACKAGE
8-NOV-87, Version 8
Status: Passed, 1988?

- LAMBDA-FORM
Version 4, 22-Nov-88, Released 8-Dec-88
Status: rejected, Jan 89 X3J13

+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?

+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13

- LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION 
Synopsis: should LEAST-POSITIVE- and MOST-POSITIVE-XXX-FLOAT
   numbers include denormalized ones in those implementations
   that admit them?
Status: Not submitted

! LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: tabled; version 1 still ready for vote

! LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Comments: Don't like (DEFVAR CAR ...) example
	14: Like simpler "Redefining any documented
  definition on a symbol in the LISP package -- such as variables, 
  functions, constants, properties and property-lists, etc -- is
  undefined, except for the explicitly allowed cases (e.g. dynamic
  binding of variables)."
Status: tabled; version 5 still ready for vote

- LIST-TYPE-SPECIFIER
Synopsis: add a type specifier (LIST NUMBER)
Version 1, 28 Jun 88
Status: withdrawn

! LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Status: ready for vote?

! LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote

! LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: ready to vote

! LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: ready for vote

+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988

* MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: *** NEED PROPOSAL SUBMITTED ****

- MAKE-CONCATENATED-STREAM-EXAMPLE
Synopsis: (read (make-concatenated-stream (make-string-input-stream "1")
(make-string-input-stream "2"))) => 12?
Version 1, 26-Oct-88
Status: withdrawn, no issue (bug report to one implementation)

+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended 

! MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: ready for vote

+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13

+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89
Status: passed, as amended

- OUTPUT-STREAM-P-EXAMPLE
Synopsis: Clarify (output-stream-p (make-concatenated-stream)) is NIL?
Version 1, 26-Oct-88
Comment: already clear; just bug report for one implementation

+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended

+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Comments: Minor glitches? Remove the description of "correctable" error to be signalled and
handled.
Status: passed, Jan 89 X3J13

!+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: Accepted MORE-PERMISSIVE with amendments
Version 3, 17-Mar-89, released 17-Mar-89
Status: vote to accept wording as intent of amendment

* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME;
	require PATHNAME-TYPE to return same?
Version 1, 07-Jul-88
Comments: only add the :TYPE :SOURCE-LISP, not PATHNAME-CANONICAL-TYPE?
Status: => "pathname" committee?

- PATHNAME-COMPONENT-CASE
Synopsis: allow ALL UPPER CASE to mean "use the 'right' case
Comments: lots of heat?
Status: withdraw?

- PATHNAME-EXTENSIONS
Synopsis: allow a way of telling whether a pathname is a pattern, a "funny"
file
Comments: necessary in standard?
Status: => "pathname" committee

* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet

* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous, pro, con. Print like #S(pathname ...)?
Status: *** NEED NEW VERSION ***

+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988?

+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988?

* PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Version 3, 29-Dec-88
Comments: typos and proposed simplifications
Status: *** NEED NEW VERSION ***

* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88
Comments: various
Status: need new version? ==> ERRORS-IN-FILE-CHAPTERS?

- PATHNAME-TYPE-UNSPECIFIC
Version 1 27-Jun-88, Released 7 Oct 88
Comments: may be subsumed
Status:  withdrawn; superceded by PATHNAME-UNSPECIFIC-COMPONENT

+  PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89
Status: Passed, Jan 89 X3j13, as amended

- PATHNAME-WILD
Version 2, 6-Oct-88
Synopsis: Portable way to ask about "wildcard" pathnames?
Comments: consistent with PATHNAME-COMPONENT-CASE?
Status: => "pathname" committee

+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis:  PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13

- PLUS-ABNORMAL
Version 1, 1-Mar-89
Synopsis: say what happens to + when evaluation aborts
Status: withdraw?

* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: Need new version

+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?

* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted yet ** NEED WRITEUP **

+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended

! PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: tabled, vote on version 9 (w/o amendments)

+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988?

+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13

+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Comments: use function or keyword?
Status: need new version

* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission

! REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Status: vote?

+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988?

!* REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 4, 29-Nov-88, Released 12-Jan-89
Status: straw vote in favor of this, BarMar will make amendments
Version 5, 15-Mar-89
Comment: needs a little work
Status: *** NEARLY READY -- NEED NEW VERSION ****

- REMF-MULTIPLE 
Synopsis: What does REMF do if it sees more than one INDICATOR?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: withdrawn ("only applies in 'cannot happen' situation")

+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13

+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13

- REST-LIST-EXTENT
Synopsis: allow way to declare dynamic extent &REST
Comment: superseded by DYNAMIC-EXTENT
Status: withdrawn

+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released  9-Dec-88
Status: passed, Jan 89 X3J13

+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13

- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Version 6, 06-Oct-88, Released 11-Jan-89
Comments: New version scales down previously rejected version
Status: Version 6 rejected Jan 89 X3J13

* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 1, 5-Dec-88
Status: *** NEED NEW VERSION ****

+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...) 
Status: passed, Jan 89 X3J13

+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?

+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?

- SINGLE-FLOAT-NON-PORTABLE
Synopsis: remove SINGLE-FLOAT, DOUBLE-FLOAT a la FIXNUM?
Status: Not submitted

+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13

- SPECIAL-VARIABLE-TEST
Synopsis: Add SPECIAL-VARIABLE-P?
Version 2, 31-May-88
Status: withdrawn (subsumed by SYNTACTIC-ENVIRONMENT-ACCESS)

+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

- STANDARD-VALUE
Synopsis: user can say binding is "temporary" 
Version 1, 21-Oct-88
Comments: not worth trying to standardize now?
Status: withdrawn

+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released  7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended

+ STREAM-ACCESS
Version 2, 30-Nov-88, Released  9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13

- STREAM-CAPABILITIES
Version 1, 7/5/88
Synopsis: SAME-SOURCE-P, SAME-DESTINATION-P, etc
Status: => pathname/file bucket. Withdraw?

- STREAM-DEFINITION-BY-USER
Synopsis: Want user-definable stream types.
Status: not submitted => CL-Windows

- STREAM-ELEMENT-TYPE-EXAMPLES
Version 1, 26-Oct-88
Synopsis: clarify STREAM-ELEMENT-TYPE may return different values?
Status: => editorial

- STREAM-INFO
Version 6, 30-Nov-88, Released 9 dec 88
Status: Rejected, Jan 89 X3J13

+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2 
Status: Passed, 1988?

- SUBTYPEP-EMPTY-NIL
Version 1, March 89
Status: => editorial, no cleanup needed

* SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: ** missing writeup ***

+ SUBTYPEP-TOO-VAGUE
Version 4,  7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

- SYMBOL-MACROFLET
Version 1, 30 Sep 88
Synopsis: Add SYMBOL-MACROFLET gives lexical function expansion
Status: withdraw? Please?

+ SYMBOL-MACROLET-DECLARE
Version 2,  9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13

!+ SYMBOL-MACROLET-SEMANTICS
Version 5, 30-Nov-88, Released 9 Dec 88
Status: Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: ready for vote

- TAGBODY-CONTENTS
Version 5, 9-Dec-88, Released 9 Dec 88
Comments: "good that this failed, but we still need a clarification"
Status: Failed, Jan 89 X3J13

+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13

+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec 
Version 4, 18-Mar-89
Status: Need new version as amended.

! THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: tabled, vote on 2

! TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote

- TRACE-ERROR
Synopsis: TRACE should signal errors if it doesn't understand
Version 1, 20-Jun-88
Comments: is this a cleanup?
Status: withdrawn

- TRACE-FUNCTION-ONLY
Synopsis: extend TRACE to handle other specs
Comment: we don't like it
Status: withdrawn

- TRUENAME-SYNTAX-ONLY
Version 1, 12-Sep-88
Synopsis: when does TRUENAME perform checking?
Comments: other options? leave more vague? Other questions?
Status: => "pathname"?

+* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: constraints wrong
Status: ** NEED NEW VERSION ***

- TYPE-SPECIFIER-PREDICATE
Synopsis: "Add a new function TYPE-SPECIFIER-P that is true of valid type
   specifiers and false of all other Lisp objects.  Note that the use of
   DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
   time."
Comments: considerable discussion on common lisp mailing list.
Status: probably not

! UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: Lumping SLOT-UNBOUND in with unbound special variables was a mistake,
           as SLOT-UNBOUND is an extension mechanism, not only a safety checking
           mechanism.  Also there were some wording problems.  Gabriel and Gregor
           are to submit a revised proposal.
		No version arrived.
Status: vote on 1?

+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13

+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13

+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88 
Status: Passed, 1988?

∂18-Mar-89  0216	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)    
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 18 Mar 89  02:16:20 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 15:14:23 EST
Date: Fri, 17 Mar 89 15:14 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: masinter.pa@xerox.com, kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890317000217.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890317201410.8.BARMAR@OCCAM.THINK.COM>

    Date: Thu, 16 Mar 89 19:02 EST
    From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>

	Date: Thu, 16 Mar 89 17:22 EST
	From: Barry Margolin <barmar@Think.COM>

	I would support a version that makes NSUBSTITUTE* be explicitly
	specific.  I see no reason not to require it to use SETF of CAR or AREF,
	as appropriate.  Unless someone is working on CAR-coding, I don't think
	it precludes any known optimizations.

    I'd support that too.  In other words, describe NSUBSTITUTE with language
    similar to the description of NSUBST.

OK, here goes:

Issue:        REMF-DESTRUCTION-UNSPECIFIED
References:   (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
	      REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
	      DELETE-DUPLICATES, NSUBSTITUTE, NSUBSTITUTE-IF (pp254-256); 
	      NCONC, NRECONC (p269); NUNION, NINTERSECTION,
	      NSET-EXCLUSIVE-OR (pp276-279).
Category:     CLARIFICATION/CHANGE
Edit history: 11-Feb-87, Version 1 by Dave Andre (DLA@Symbolics.COM)
	      29-Oct-87, Version 2 by Pitman (flesh out proposals)
	      28-Nov-88, Version 3 by Pitman (revised presentation)
	      29-Nov-88, Version 4 by Pitman (slight editing per DLA)
	      15-Mar-89, Version 5 by Margolin (amendments discussed in
			 Hawaii, removed -NOT functions)
	      17-Mar-89, Version 6 by Margolin (make NSUBSTITUTE* less vague)
Status:	      For Internal Discussion

Problem Description:

 Currently, the exact nature of the side-effect performed by list
 modification routines is not specified.

 Either the specific modifications allowed should be specified so that
 programmers can rely on them and implementors can avoid accidentally
 causing problems by introducing well-meaning optimizations, or else
 the documentation should explicitly state that the effects are
 unspecified so that programmers will not depend on them and 
 implementors will feel comfortable about doing interesting optimizations.

Proposal (REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE-EXCEPT-NCONC-AND-NSUBSTITUTE):

 [This proposal name is getting way out of hand!]

 Clarify that the way in which the destructive behavior of the
 operators below is achieved is explicitly vague in a number of ways,
 in order to provide individual implementations the necessary
 flexibility to do useful optimizations.

 (SETF (GETF place indicator) value)
  is permitted to either SETF place or to SETF any part, CAR or
  CDR, of the top-level list structure held by that place.

 (REMF place indicator)
  is permitted to either SETF place or to SETF any part, CAR or
  CDR, of the top-level list structure held by that place.

 (SETF (GET symbol indicator) value)
  is constrained to behave exactly the same as
  (SETF (GETF (SYMBOL-PLIST symbol) indicator) value).

 (REMPROP symbol indicator)
  is constrained to behave exactly the same as
  (REMF (SYMBOL-PLIST symbol) indicator).

 (NREVERSE sequence)
  when sequence is a list, is permitted to SETF any part, CAR or
   CDR, of the top-level list structure in that sequence.
  when sequence is an array is permitted to re-order the elements
   of the given sequence in order to produce the resulting array.

 (DELETE object sequence ...)
  when sequence is a list, is permitted to SETF any part, CAR or
   CDR, of the top-level list structure held in that sequence.
  when sequence is an array is permitted to change the dimensions
   of the array and to slide its elements into new positions without
   permuting them to produce the resulting array.
  
 (DELETE-IF test sequence ...)
  is constrained to behave exactly like
  (DELETE NIL sequence
	  :TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
	  ...).

 (DELETE-DUPLICATES sequence ...)
  when sequence is a list, is permitted to SETF any part, CAR or
   CDR, of the top-level list structure held in that sequence.
  when sequence is an array is permitted to change the dimensions
   of the array and to slide its elements into new positions without
   permuting them to produce the resulting array.

 (NRECONC list tail)
  is constrained to have side-effect behavior equivalent to:
  (NCONC (NREVERSE list) tail).

 (NUNION list1 list2 ...)
 (NINTERSECTION list1 list2 ...)
 (NSET-EXCLUSIVE-OR list1 list2 ...)
  is permitted to SETF any part, CAR or CDR, of the top-level of
  any of the given lists.

  Note, however, that since this side-effect is not required,
  these functions should still not be used in for-effect-only
  positions in portable code.

 (NCONC . lists)
  is defined using the following recursive relationship:

    (NCONC) => NIL
    (NCONC NIL . args) == (NCONC . args)
    (NCONC arg) => arg
    (NCONC arg1 arg2) has the side effect of (RPLACD (LAST arg1) arg2),
		      and returns arg1 
    (NCONC arg1 arg2 . args) == (NCONC (NCONC arg1 arg2) . args)

  [If a previous cleanup issue prohibited NIL as a non-last argument
   then ignore the (NCONC NIL . args) case.]

 (NSUBSTITUTE new-object old-object sequence ...)
 (NSUBSTITUTE-IF new-object test sequence ...)
  is required to SETF any CAR (if SEQUENCE is a list) or VREF (if it's
  a vector) of SEQUENCE which is required to be replaced with
  NEW-OBJECT.  If SEQUENCE is a list, it none of the CDRs of the
  top-level list may be modified.  These functions, therefore, may be
  used in for-effect-only positions in code (some may find this
  stylistically distasteful, though).

 Note: The above clarifications are not intended as complete functional
 descriptions. They are intended to augment (rather than to replace)
 other descriptions already in effect.

Test Cases:

 For GETF...

    (SETQ FOO (LIST 'A 'B 'C 'D 'E 'F))    ==> (A B C D E F)
    (SETQ BAR (CDDR FOO))                  ==> (C D E F)
    (REMF FOO 'C)
    BAR				           ==> ??

    In Symbolics Common Lisp, BAR holds (C D E F).
    CLtL allows other interpretations. eg, BAR might hold
    (C), (NIL), (C NIL) or (C D).
    Under this proposal, any of these interpretations (and others as well)
    would still be valid

 For DELETE...

    (SETQ FOO (LIST 'A 'B 'C))   ==> (A B C)
    (SETQ BAR (CDR FOO))         ==> (B C)
    (SETQ FOO (DELETE 'B FOO))   ==> (A C)
    BAR                          ==> ??
    (EQ (CDR FOO) (CAR BAR))     ==> ??

    In Symbolics Common Lisp, these last two expressions return ((C)) and T.
    Under this proposal, either of these interpretations (and others
    as well) would be valid.

 For NCONC...

    (SETQ FOO (LIST 'A 'B 'C 'D 'E)
	  BAR (LIST 'F 'G 'H 'I 'J)
	  BAZ (LIST 'K 'L 'M)) => (K L M)
    (SETQ FOO (NCONC FOO BAR BAZ)) => (A B C D E F G H I J K L M)
    FOO => (A B C D E F G H I J K L M)
    BAR => (F G H I J K L M)
    BAZ => (K L M)

    (SETQ FOO (LIST 'A 'B 'C 'D 'E)
	  BAR (LIST 'F 'G 'H 'I 'J)
	  BAZ (LIST 'K 'L 'M)) => (K L M)
    (SETQ FOO (NCONC NIL FOO BAR NIL BAZ)) => (A B C D E F G H I J K L M) 
    FOO => (A B C D E F G H I J K L M)
    BAR => (F G H I J K L M)
    BAZ => (K L M)


Rationale:

 Implementations already vary widely on their implementation techniques
 for these functions. This effectively clarifies the status quo, making
 it more clear to programmers what they may rely upon in portable code.

 In the case of NCONC, however, the precise definition is useful because
 it is what users expect, it is how NCONC has been defined for many
 years, and it is how current implementations generally work.  It may
 not always be the most efficient way (e.g. it may result in invisible
 pointers in CDR-coded implementations), but callers of NCONC probably
 use it specifically for its precise side effects.

 In the case of NSUBSTITUTE, this seems like the only reasonable
 implementation mechanism, and there doesn't seem to be a reason not to
 guarantee it.

Current Practice:

 All valid implementations are believed to comply with the vague
 definitions.  Symbolics Genera 7.2 and Sun Common Lisp 2.1.3 appear to
 conform to the NCONC spec.

Cost to Implementors:

 None. This is probably the status quo for most implementors.  If there
 are any implementations that don't implement NCONC and NSUBSTITUTE as
 above (which I doubt) they will have to be changed.

Cost to Users:

 This change would not affect programs coded with "good programming
 practice".  That is, only programs which rely on currently undocumented
 features would be in any danger of breaking.  In fact, those programs
 are already in such danger, and this change to the documentation would
 just publicize it.  The clarification would -encourage- good programming
 practice by warning people to only obey the published contract of the
 above-mentioned functions.

 There is, however, no automatic technique for making this check for
 programs already in error. Bugs due to unexpected side-effects are in
 general among the hardest to reckon with.

Cost of Non-Adoption:

 Programmers may naively believe there is only one possible or reasonable
 implementation of these functions. Some implementors may shy away from
 reasonable optimizations out of a paranoid belief that deviating from 
 some vague, unspoken rules will lead to programmer unrest. Making these
 things explicitly vague clarifies the implementor's rights in a way that
 permits numerous useful optimizations.

Benefits: 

 Users would be discouraged from taking advantage of subtle details
 of these destructive operations because such details would be explicitly
 not guaranteed to be portable.

 Implementations can improve performance of many of the above-mentioned
 functions when they are not under the constraint to implement them
 in a highly constrained fashion. For example, in Symbolics systems,
 DELETE of a cdr-coded list could use the implementation primitive
 %CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
 pointers.

 Garbage collection effectiveness can also be improved. For example,
 all of the destructive operations which remove objects (eg, REMF)
 could remove CAR pointers to removed objects which are more volatile
 than the list itself, assisting the garbage collector and thereby
 improving memory usage and paging performance.

 Tightening the definition of NCONC and NSUBSTITUTE permits users to
 predict their programs' behavior more precisely.

Non-Benefits:

 Users who inadvertently depend on side-effect behavior may be rudely
 surprised when moving between implementations.

 Compatibility with older Lisp dialects is diminished.

 Implementors have less flexibility in implementing NCONC efficiently.
 This is true of NSUBSTITUTE, but this is less likely to cause problems.

Performance Impact:

 Metering in Symbolics test  systems have shown that there are substantial
 performance gains to be had by allowing implementations flexibility in
 these areas.

 In the case of NCONC, this implementation flexibility, and hence
 potential performance improvements, is sacrificed.

 If anyone ever invents CAR-coding, the required implementation of
 NSUBSTITUTE could be a performance hindrance.

Aesthetics:

 Most of these functions implement abstract operations. For example,
 REMPROP implements an abstract operation on a "property list".
 Proper language design should not encourage people to delve below the
 level of abstraction into the nitty gritty.

 NCONC is a "less abstract" function than the rest of the functions
 described above.  It is usually used precisely because of the way it
 interacts with list implementation.  Similarly for NSUBSTITUTE.

Discussion:

 Andre's original version of this proposal pushed for explicitly vague
 descriptions of these functions' side-effect behavior.  He believes
 that if users want more predictability from these functions, they
 should write private variants that implement whatever predictability
 they require. 

 Pitman originally opposed this position because he weighed portability
 a higher concern. Since the original discussion, however, his views on
 how to resolve this priority have been refined, and he now believes
 that leaving things vague is appropriate. As such, he now supports what
 is effectively Andre's original proposal.

 Pitman and Andre supported version 4.  [I don't know how they feel
 about v6 -- Barmar].

 Moon supports version 6.

∂18-Mar-89  1708	CL-Cleanup-mailer 	*DRAFT* Issue: DESTRUCTURING-BIND, v.2   
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 18 Mar 89  17:08:07 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
	Sat, 18 Mar 89 19:07:01 CST id AA09942 for cl-cleanup@sail.stanford.edu
Posted-Date: Sat, 18 Mar 89 19:05:07 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
	id AA20299; Sat, 18 Mar 89 19:05:07 CST
Date: Sat, 18 Mar 89 19:05:07 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903190105.AA20299@pavo.src.honeywell.com>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 16 Mar 89 11:46 PST <890316-114911-4982@Xerox>
Subject: *DRAFT* Issue: DESTRUCTURING-BIND, v.2

   If the result of evaluating the expression does not match the 
   destructuring pattern, the consequences are undefined. Implementations
   are not required to signal an error in this case, but neither are they
   permitted to extend the behavior by defining it to be harmless.

At the risk of getting rpg started again, what does it mean?

∂18-Mar-89  1720	CL-Cleanup-mailer 	Issue DESCRIBE-UNDERSPECIFIED, v.1  
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 18 Mar 89  17:20:52 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
	Sat, 18 Mar 89 19:19:40 CST id AA10441 for cl-cleanup@SAIL.STANFORD.EDU
Posted-Date: Sat, 18 Mar 89 19:17:51 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
	id AA20309; Sat, 18 Mar 89 19:17:51 CST
Date: Sat, 18 Mar 89 19:17:51 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903190117.AA20309@pavo.src.honeywell.com>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 16 Mar 89 08:19 PST <890316-082029-3881@Xerox>
Subject: Issue DESCRIBE-UNDERSPECIFIED, v.1

  REMARKS:

   Methods on DESCRIBE-OBJECT may recursively call DESCRIBE.  Indentation,
   depth limits, and circularity detection are all taken care of automatically,
   provided that each method handles exactly one level of structure and calls
   DESCRIBE recursively argument if there are more structural levels.

Something is missing on the last line.  Was there supposed to be a
recursivep argument?

∂18-Mar-89  2312	CL-Cleanup-mailer 	Issue: DEFMACRO-LAMBDA-LIST, v.2    
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Mar 89  23:12:38 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182861; Sun 19-Mar-89 01:25:45 EST
Date: Sun, 19 Mar 89 01:28 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue: DEFMACRO-LAMBDA-LIST, v.2
To: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <890317-195034-3172@Xerox>
Message-ID: <19890319062819.3.MLY@ISABEL-PERON.AI.MIT.EDU>

      1. a. Specify that &BODY may appear at any level of a DEFMACRO lambda list.

	 b. Specify that &WHOLE may only appear at any level of a DEFMACRO
	    lambda list. At inner levels, the &WHOLE variable is bound to

``May only appear at any level'' sounds like a control-Y bug.

	 c. Specify that &ENVIRONMENT may only appear at the top level of a
	    DEFMACRO lambda list.

Something else which needs to be clarified is where the &ENVIRONMENT
keyword may appear.

Which of the following are legal?

1. (defmacro foo (&whole w &environment e a b) ...)
2. (defmacro foo (&environment e &whole w a b) ...)
3. (defmacro foo (&whole w a b &environment e) ...)
4. (defmacro foo (&whole w a &environment e b) ...)

I'd like to say 1,2 and 3 only, even though case 2 would require some
modification of the ``first in the lambda-list'' terminology.

∂19-Mar-89  1058	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS (version 2)
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 19 Mar 89  10:58:19 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
	Sun, 19 Mar 89 12:57:12 CST id AA11401 for cl-cleanup@sail.stanford.edu
Posted-Date: Sun, 19 Mar 89 12:55:24 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
	id AA20779; Sun, 19 Mar 89 12:55:24 CST
Date: Sun, 19 Mar 89 12:55:24 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903191855.AA20779@pavo.src.honeywell.com>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 16 Mar 89 22:51 PST <890316-225136-6875@Xerox>
Subject: Issue: HASH-TABLE-ACCESS (version 2)

  HASH-TABLE-REHASH-SIZE hash-table
 
    Returns the current rehash size of a hash table.

Two minor nits, first the wording should say "of the hash-table", and
secondly the results of passing in a non hash table should be described,
e.g. signals an error, or is undefined.  I think having portable access to
the HASH-TABLE-TEST is quite important, I would hate to loose the chance to
get that because of the other functions, but I guess that an ammendment on
the floor could remove the ones people have trouble with.

∂20-Mar-89  1229	CL-Cleanup-mailer 	Re: Issue: PRETTY-PRINT-INTERFACE (version 3) 
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 20 Mar 89  12:29:22 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA00470; Mon, 20 Mar 89 10:13:54 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA01358; Mon, 20 Mar 89 10:15:47 EST
Message-Id: <8903201515.AA01358@mist.>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: PRETTY-PRINT-INTERFACE (version 3) 
In-Reply-To: Your message of Sat, 18 Mar 89 01:32:00 -0500.
             <19890318063223.0.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Mon, 20 Mar 89 10:15:45 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    Date: Sat, 18 Mar 89 01:32 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
    I could not find any specification of the units of measurement for
    *PRINT-RIGHT-MARGIN*, *DEFAULT-RIGHT-MARGIN*, *PRINT-MISER-WIDTH*,
    indentation, and tabulation.  It's not even clear that margins,
    indentation, and tabulation can't be measured in three different
    units.  Analysis of the examples suggests that the units are
    assumed to be characters and all characters are assumed to be the
    same width.  This is not an implementation-independent assumption.
    In any case the proposal has to be specific about the units.  I
    would prefer something that seamlessly accomodates variable-width
    characters, but don't have enough experience with pretty-printers
    to propose anything myself.
    
I think that all three clearly have to be in the same units; the
writeup should be changed to specify this.  After thinking about it
for a while, it's not clear that the exact unit matters much as long
as it's not to small.  Pixels are too small; "n"'s or "m"'s aren't.
Personally I'd suggest an "m" as the standard unit.

Other than that, I don't think the propsal has terrible problems with
variable width (even kerned) fonts because most indentation is done
relative to the position of the start of another word.  This common
case can be handled with arbitrary precision; a variable width font
implementation would presumably indent to the exact pixel position of
the relevant character (how would that be expressed in Postscript?).

Of course parts of the proposal won't work for right-to-left or
top-to-bottom languages.  I think that rejecting the proposal because
of that would be ridiculous.

∂20-Mar-89  1236	CL-Cleanup-mailer 	Re: Issue: PRETTY-PRINT-INTERFACE (version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  12:36:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561205; Mon 20-Mar-89 15:35:05 EST
Date: Mon, 20 Mar 89 15:34 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PRETTY-PRINT-INTERFACE (version 3) 
To: Dan L. Pierson <pierson@mist.encore.com>
cc: cl-cleanup@SAIL.STANFORD.EDU, disk@wheaties.ai.mit.edu
In-Reply-To: <8903201515.AA01358@mist.>
Message-ID: <19890320203457.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 20 Mar 89 10:15:45 EST
    From: Dan L. Pierson <pierson@mist.encore.com>

	Date: Sat, 18 Mar 89 01:32 EST
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
	I could not find any specification of the units of measurement for
	*PRINT-RIGHT-MARGIN*, *DEFAULT-RIGHT-MARGIN*, *PRINT-MISER-WIDTH*,
	indentation, and tabulation.
    
    I think that all three clearly have to be in the same units; the
    writeup should be changed to specify this.  After thinking about it
    for a while, it's not clear that the exact unit matters much as long
    as it's not to small.  Pixels are too small; "n"'s or "m"'s aren't.
    Personally I'd suggest an "m" as the standard unit.

I don't see anything wrong with that, although I can't claim to be an
expert in this area.

    Other than that, I don't think the propsal has terrible problems with
    variable width (even kerned) fonts because most indentation is done
    relative to the position of the start of another word.  This common
    case can be handled with arbitrary precision; a variable width font
    implementation would presumably indent to the exact pixel position of
    the relevant character (how would that be expressed in Postscript?).

I think what you're saying is that the argument to LOGICAL-BLOCK-INDENT
(or ~I) is almost always zero?  In the examples given in version 1
of the proposal, zero is in the majority, there are also two 1's and
a 2.  I didn't find any cases where the number given to ~I seemed to
be intended to correspond to the number of characters in some word.
There might need to be a style suggestion for writers of pretty print
methods telling them to use relative indentation instead of counting
characters.  Given that, your suggestion sounds plausible to me.

∂20-Mar-89  1241	CL-Cleanup-mailer 	Issue: COMPLEX-RATIONAL-RESULT (version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  12:40:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560964; Mon 20-Mar-89 11:41:43 EST
Date: Mon, 20 Mar 89 11:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPLEX-RATIONAL-RESULT (version 1)
To: CL-Cleanup@sail.stanford.edu
cc: chapman%aitg.DEC@decwrl.dec.com
Message-ID: <19890320164136.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

This issue came up while reviewing section 2.2 of the draft standard.
Does anyone object if I mail this to X3J13 and bring it up at the
March meeting?  I couldn't find any sign that it has already been addressed.

Issue:         COMPLEX-RATIONAL-RESULT

References:    CLtL p.203

Category:      CLARIFICATION

Edit history:  Version 1, 20-Mar-89, by Moon

Problem description:
  
  Referring to irrational and transcendental functions, CLtL says:
    
    When the arguments to a function in this section are all rational and
    the true mathematical result is also (mathematically) rational, then
    unless otherwise noted an implementation is free to return either an
    accurate result of type rational or a single-precision floating-point
    approximation.  If the arguments are all rational but the result cannot
    be expressed as a rational number, then a single-precision
    floating-point approximation is always returned.

  Referring to EXPT, CLtL says:

    If the base-number is of type RATIONAL and the power-number is an
    INTEGER, the calculation will be exact and the result will be of
    type RATIONAL; otherwise a floating-point approximation may result.

  What about arguments of type (complex rational)?

Proposal (COMPLEX-RATIONAL-RESULT:EXTEND):

  Extend the paragraph quoted above to cover the components of complex
  numbers.  For (complex rational) arguments, a mathematically rational
  result can be rational, (complex rational), or (complex float) at the
  discretion of the implementation.  For EXPT of a (complex rational) to
  an integer power, the calculation must be exact and the result will
  be rational or (complex rational).

Examples:

  (log #c(-16 16) #c(2 2)) => 3 or approximately #c(3.0 0.0)
  (expt #c(2 2) 3) => #c(-16 16)
  (expt #c(2 2) 4) => -64 

Rationale:
  
  This seems most consistent with the treatment of real numbers.

Current practice:
  
  Symbolics Genera 7.4 returns a (complex float) for the first example
  and returns the specified answers for the second and third examples.
  Other implementations were not surveyed.

Cost to Implementors:

  Only EXPT would have to change, since the type of the other results
  is at the discretion of the implementation.

Cost to Users:

  Probably none, but it is hard to predict.

Cost of non-adoption:
  
  Slightly less self-consistent language.

Performance impact:

  None of any significance.

Benefits/Esthetics:

  More self-consistent language.

Discussion:

  None.

∂20-Mar-89  1241	CL-Cleanup-mailer 	Issue: HASH-TABLE-SIZE (version 1)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  12:41:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560978; Mon 20-Mar-89 11:55:18 EST
Date: Mon, 20 Mar 89 11:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-SIZE (version 1)
To: CL-Cleanup@sail.stanford.edu
cc: chapman%aitg.DEC@decwrl.dec.com
Message-ID: <19890320165503.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

This issue came up while reviewing section 2.2 of the draft standard.
Does anyone object if I mail this to X3J13 and bring it up at the
March meeting?  I couldn't find any sign that it has already been addressed.

Issue:         HASH-TABLE-SIZE

References:    CLtL p.283

Category:      CLARIFICATION

Edit history:  Version 1, 20-Mar-89, by Moon

Problem description:
  
  CLtL contradicts itself on the meaning of the :SIZE argument to
  MAKE-HASH-TABLE.  At the top of p.283, it says that the size is "the
  maximum number of entries it can hold.  Usually the actual capacity of
  the table is somewhat less."  At the bottom of the page it says "this
  argument serves as a hint to the implementation of approximately how
  many entries you intend to store."  So does the :SIZE intended to be the
  actual capacity of the table, or the amount of storage allocated to hold
  the table.  For example, if the implementation of hash tables is
  designed for a loading of 65%, and the user specifies :SIZE 100, does
  the table returned have space allocated for 100 entries, so that it
  overflows and becomes bigger when 65 entries are inserted, or does the
  table have space allocated for 154 entries, so that it overflows and
  becomes bigger when 100 entries are inserted?

Proposal (HASH-TABLE-SIZE:INTENDED-ENTRIES):

  Believe the bottom of p.283 rather than the top.  The :SIZE argument
  is approximately the number of entries that can be inserted without
  the table having to grow.

Rationale:
  
  The bottom of p.283 is user-oriented, the top is implementation-oriented.
  User-oriented seems more appropriate.

Current practice:
  
  Symbolics Genera 7.4 adheres to HASH-TABLE-SIZE:INTENDED-ENTRIES.
  Other implementations were not surveyed.

Cost to Implementors:

  At worst adding a multiplication to MAKE-HASH-TABLE.

Cost to Users:

  Probably none, but it is hard to predict.

Cost of non-adoption:
  
  Implementations will probably vary in which of the two interpretations
  they believe.  The language standard will not be self-consistent.

Performance impact:

  None of any significance.

Benefits/Esthetics:

  More self-consistent language.

Discussion:

  None.

∂20-Mar-89  1242	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE (version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  12:41:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561033; Mon 20-Mar-89 13:04:18 EST
Date: Mon, 20 Mar 89 13:04 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
To: CL-Cleanup@sail.stanford.edu
cc: chapman%aitg.DEC@decwrl.dec.com
Message-ID: <19890320180405.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

This issue came up while reviewing section 2.2 of the draft standard.
Does anyone object if I mail this to X3J13 and bring it up at the
March meeting?  I couldn't find any sign that it has already been addressed.

Issue:         PATHNAME-COMPONENT-VALUE

Related Issues:PATHNAME-CANONICAL-TYPE,
               PATHNAME-SUBDIRECTORY-LIST,
               PATHNAME-UNSPECIFIC-COMPONENT,
               PATHNAME-WILD

References:    CLtL pp.410-3

Category:      CLARIFICATION and CHANGE

Edit history:  Version 1, 20-Mar-89, by Moon

Problem description:
  
  CLtL is overly restrictive on the possible values for pathname components.
  These restrictions are described in a funny way that makes it unclear
  whether they are requirements, guidelines, or just an example.
  
  The restrictions are not all written down in one place, but they appear
  to be as follows:

  Host		nil, :wild, string, or list of strings
  Device	nil, :wild, string, or something else ("structured")
  Directory	nil, :wild, string, or something else ("structured")
  Name		nil, :wild, string, or something else ("structured")
  Type		nil, :wild, or string
  Version	nil, :wild, :newest, positive integer, implementation
		dependent symbol, or implementation-dependent integer
		less than or equal to zero.  Suggestions include :oldest,
		:previous, :installed, 0, and -1.

  PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN allowed implementations to
  allow any component to be :UNSPECIFIC.  This has been voted in.

  PATHNAME-SUBDIRECTORY-LIST proposes a list of strings and keyword
  symbols for the directory component.

  PATHNAME-CANONICAL-TYPE proposes some new operations but does not
  change the possible values of the type component.

  PATHNAME-WILD proposes a portable way to test for implementation
  dependent component values that indicate wildcard matching.  It
  does not change the possible values of any component.

Proposal (PATHNAME-COMPONENT-VALUE:SPECIFY):

  The points of the proposal have been numbered to facilitate
  amendments to remove or modify individual points.

  When examining pathname components, conforming programs must be
  prepared to encounter any of the following values:

  1. Any component can be NIL, which means the component has not
  been specified.

  2. Any component can be :UNSPECIFIC, which means the component has
  no meaning in this particular pathname.

  3. Any component can be :WILD, which matches any component value.
  Wild pathnames can be used with DIRECTORY but not with OPEN.

  4. The host, device, directory, name, and type can be strings.

  5. The host and device can be a list, a structure, or a
  standard-object at the discretion of the implementation.

  6. The directory can be a list of strings and symbols as detailed in
  PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)

  7. The version can be any symbol or any integer.  The symbol :NEWEST
  refers to the largest version number that already exists in the file
  system when reading, overwriting, appending, superseding, or directory
  listing an existing file, and refers to the smallest version number
  greater than any existing version number when creating a new file.

  When constructing a pathname from components, conforming programs
  must follow these rules:
  
  11. Any component can be NIL.  NIL in the host may mean a default host
  rather than an actual NIL in some implementations.

  12. Any component can be :WILD, which matches any component value.
  Wild pathnames can be used with DIRECTORY but not with OPEN.
  
  13. The host, device, directory, name, and type can be strings.

  14. The directory can be a list of strings and symbols as detailed in
  PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)

  15. The version can be :NEWEST.

  16. Any component can be taken from the corresponding component
  of another pathname on the same host and device.

  17. An implementation might support other values for some
  components, but a portable program cannot use those values.  
  An implementation might allow values to be transferred between
  pathnames on different hosts or different devices, but a portable
  program cannot rely on that.
  A conforming program can use implementation-dependent values
  but this can make it non-portable, for example, it might work
  only with Unix file systems.

  18. It is suggested, but not required, that implementations use
  positive integers starting at 1 as version numbers, recognize
  the symbol :oldest to designate the smallest existing version
  number, and use keyword symbols for other special versions.

Consequences:

  The changes relative to CLtL plus PATHNAME-UNSPECIFIC-COMPONENT
  are as follows:

  The definition of "structured" component is restricted to lists,
  structures, and standard-objects, rather than allowing any object
  whatsoever.
  
  "Structured" hosts are allowed, a generalization of CLtL's list
  of strings.

  "Structured" directories are replaced by PATHNAME-SUBDIRECTORY-LIST.

  "Structured" names are forbidden.

  The difference between what component values a program can depend
  on being able to use, versus what component values a program must
  be prepared to encounter, is clarified.

Rationale:
  
  This should make it easier to write portable programs that deal with
  pathnames and make it easier for implementors by clarifying the
  framework into which they must fit.  Also it should make it easier
  to write the Common Lisp language specification by resolving some
  things that were unclear about the status quo.

  Adding "structured" hosts conforms to current practice.

  Substituting a default host for NIL conforms to current practice
  in implementations that require all pathnames to have a specific host.

  Removing "structured" names should improve portability without causing
  any harm, assuming no implementation uses structured names.  This will
  improve portability by allowing programs to do string manipulation on
  names, although such programs still have to be careful since the valid
  characters and maximum length of a name are implementation-dependent.

  Disallowing transferral of nonstandard component values between
  different hosts or different devices allows implementations to support
  multiple incompatible file systems.

Current practice:
  
  All versions of Symbolics Genera violate CLtL in the matter of hosts,
  since it uses standard-objects as the host component.  Genera deviates
  slightly from PATHNAME-SUBDIRECTORY-LIST, but otherwise conforms to
  PATHNAME-COMPONENT-VALUE:SPECIFY.

  Other implementations were not surveyed.

  This proposal assumes that no current or planned implementation
  uses structured names, not even for wildcards.

Cost to Implementors:

  Most implementations already conform, except for the changes required
  by PATHNAME-UNSPECIFIC-COMPONENT and PATHNAME-SUBDIRECTORY-LIST, so
  the cost of this proposal itself should be minimal.  It is conceivable
  that an implementation may exist that has to change its pathname
  representation, for example one that uses numbers as structured devices.

Cost to Users:

  None.

Cost of non-adoption:
  
  Pathnames will continue to be a poorly specified part of the language.

Performance impact:

  None of any significance.

Benefits/Esthetics:

  The boundary between the specified behavior of pathnames and the
  implementation-dependent behavior of pathnames will be more clear.

Discussion:

  None.

∂20-Mar-89  1241	CL-Cleanup-mailer 	Issue: COMMON-TYPE (version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  12:40:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560953; Mon 20-Mar-89 11:24:20 EST
Date: Mon, 20 Mar 89 11:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMMON-TYPE (version 1)
To: CL-Cleanup@sail.stanford.edu
cc: chapman%aitg.DEC@decwrl.dec.com
Message-ID: <19890320162410.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

This issue came up while reviewing section 2.2 of the draft standard.
Does anyone object if I mail this to X3J13 and bring it up at the
March meeting?  I couldn't find any sign that it has already been addressed.

Issue:         COMMON-TYPE

References:    CLtL p.35, p.76

Category:      CHANGE

Edit history:  Version 1, 20-Mar-89, by Moon

Problem description:
  
  The type COMMON is defined in a very peculiar way and does not seem to
  be useful for anything.  It can be extended by users using DEFSTRUCT,
  but not DEFTYPE nor DEFCLASS, but it cannot be extended by implementations.
  Whether certain types such as NUMBER and ARRAY are subtypes of COMMON
  is implementation-dependent.  The goal of having the COMMON type was
  probably to improve portability, but it is unclear how it could actually
  be used in that way.

Proposal (COMMON-TYPE:REMOVE):

  Remove COMMON and COMMONP from the language.

Rationale:
  
  Keeping the definition of COMMON accurate in the new specification, in
  the face of changes elsewhere in the language such as the introduction
  of CLOS and the possible introduction of character registries, is
  difficult when no one is sure what COMMON is for.  If no one uses COMMON,
  it would be less work to just get rid of it.

Current practice:
  
  Every implementation probably implements COMMON.  Moon has never seen it
  used except in a program to test whether its implementation matched CLtL.

Cost to Implementors:

  None.

Cost to Users:

  None unless they are actually using COMMON.

Cost of non-adoption:
  
  Implementors would have to maintain COMMON.  Users would have to try to
  understand it, or figure out that they didn't care about it.

Performance impact:

  None.

Benefits:

  Simpler language.

Esthetics:

  Simpler language.

Discussion:

  None.

∂20-Mar-89  1325	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89  13:24:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 20 MAR 89 13:17:33 PST
Date: 20 Mar 89 13:16 PST
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Sat, 18 Mar 89 01:50 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel
 <rpg@lucid.com>, CL-Cleanup@sail.stanford.edu,
 CL-Compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
Message-ID: <890320-131733-6488@Xerox>

   MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
   SLOT-VALUE-USING-CLASS.  MAKE-LOAD-FORM-FROM-SLOTS is better,
   except for form/from dyslexia.  MAKE-LOAD-FORM-FOR-SLOTS ?

How about MAKE-LOAD-FORM-SAVING-SLOTS

  danny

∂20-Mar-89  1415	CL-Cleanup-mailer 	Re: Issue: PRETTY-PRINT-INTERFACE (version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  14:15:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561357; Mon 20-Mar-89 17:13:50 EST
Date: Mon, 20 Mar 89 17:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PRETTY-PRINT-INTERFACE (version 3) 
To: Dan L. Pierson <pierson@mist.encore.com>
cc: cl-cleanup@SAIL.STANFORD.EDU, dick@wheaties.ai.mit.edu
In-Reply-To: <8903201515.AA01358@mist.>
Supersedes: <19890320203457.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Resend after correcting misspelling in Dick Waters' mailbox name.
Message-ID: <19890320221342.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 20 Mar 89 10:15:45 EST
    From: Dan L. Pierson <pierson@mist.encore.com>

	Date: Sat, 18 Mar 89 01:32 EST
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
	I could not find any specification of the units of measurement for
	*PRINT-RIGHT-MARGIN*, *DEFAULT-RIGHT-MARGIN*, *PRINT-MISER-WIDTH*,
	indentation, and tabulation.
    
    I think that all three clearly have to be in the same units; the
    writeup should be changed to specify this.  After thinking about it
    for a while, it's not clear that the exact unit matters much as long
    as it's not to small.  Pixels are too small; "n"'s or "m"'s aren't.
    Personally I'd suggest an "m" as the standard unit.

I don't see anything wrong with that, although I can't claim to be an
expert in this area.

    Other than that, I don't think the propsal has terrible problems with
    variable width (even kerned) fonts because most indentation is done
    relative to the position of the start of another word.  This common
    case can be handled with arbitrary precision; a variable width font
    implementation would presumably indent to the exact pixel position of
    the relevant character (how would that be expressed in Postscript?).

I think what you're saying is that the argument to LOGICAL-BLOCK-INDENT
(or ~I) is almost always zero?  In the examples given in version 1
of the proposal, zero is in the majority, there are also two 1's and
a 2.  I didn't find any cases where the number given to ~I seemed to
be intended to correspond to the number of characters in some word.
There might need to be a style suggestion for writers of pretty print
methods telling them to use relative indentation instead of counting
characters.  Given that, your suggestion sounds plausible to me.

∂20-Mar-89  1427	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  14:27:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561368; Mon 20-Mar-89 17:23:27 EST
Date: Mon, 20 Mar 89 17:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
To: Danny Bobrow <Bobrow.pa@XEROX.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel <rpg@lucid.com>,
    CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: <890320-131733-6488@Xerox>
Message-ID: <19890320222313.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 20 Mar 89 13:16 PST
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>

       MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
       SLOT-VALUE-USING-CLASS.  MAKE-LOAD-FORM-FROM-SLOTS is better,
       except for form/from dyslexia.  MAKE-LOAD-FORM-FOR-SLOTS ?

    How about MAKE-LOAD-FORM-SAVING-SLOTS

I like that name.

∂20-Mar-89  1437	CL-Cleanup-mailer 	Issue: COMMON-TYPE (version 1) 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89  14:36:39 PST
Received: from fafnir.think.com by Think.COM; Mon, 20 Mar 89 17:27:04 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 20 Mar 89 17:28:00 EST
Received: by verdi.think.com; Mon, 20 Mar 89 17:24:46 EST
Date: Mon, 20 Mar 89 17:24:46 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903202224.AA19319@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu, chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: David A. Moon's message of Mon, 20 Mar 89 11:24 EST <19890320162410.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: COMMON-TYPE (version 1)

I support COMMON-TYPE:REMOVE.

∂20-Mar-89  1438	CL-Cleanup-mailer 	Issue: COMMON-TYPE (version 1) 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Mar 89  14:38:37 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA05260g; Mon, 20 Mar 89 14:33:18 PST
Received: by blacksox id AA00779g; Mon, 20 Mar 89 14:38:08 PST
Date: Mon, 20 Mar 89 14:38:08 PST
From: Eric Benson <eb@lucid.com>
Message-Id: <8903202238.AA00779@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu, chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: David A. Moon's message of Mon, 20 Mar 89 11:24 EST <19890320162410.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: COMMON-TYPE (version 1)

Yes, yes, yes.  COMMON is useless.  I'm sure Guy thought it would be
useful, but it isn't.  Burn it.  It has not survived the test of time.

∂20-Mar-89  1507	CL-Cleanup-mailer 	Issue: COMPLEX-RATIONAL-RESULT (version 1)    
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89  15:06:39 PST
Received: from fafnir.think.com by Think.COM; Mon, 20 Mar 89 17:29:50 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 20 Mar 89 17:30:06 EST
Received: by verdi.think.com; Mon, 20 Mar 89 17:26:47 EST
Date: Mon, 20 Mar 89 17:26:47 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903202226.AA19323@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu, chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: David A. Moon's message of Mon, 20 Mar 89 11:41 EST <19890320164136.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: COMPLEX-RATIONAL-RESULT (version 1)

I support COMPLEX-RATIONAL-RESULT:EXTEND.

∂20-Mar-89  1512	CL-Cleanup-mailer 	Issue: HASH-TABLE-SIZE (version 1)  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89  15:10:34 PST
Received: from fafnir.think.com by Think.COM; Mon, 20 Mar 89 17:31:49 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 20 Mar 89 17:31:12 EST
Received: by verdi.think.com; Mon, 20 Mar 89 17:27:56 EST
Date: Mon, 20 Mar 89 17:27:56 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903202227.AA19331@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu, chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: David A. Moon's message of Mon, 20 Mar 89 11:55 EST <19890320165503.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-SIZE (version 1)

I support HASH-TABLE-SIZE:INTENDED-ENTRIES.

∂20-Mar-89  1556	CL-Cleanup-mailer 	Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89  15:55:52 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Mon, 20 Mar 89 18:54:57 EST
Received: from localhost by wheat-chex.ai.mit.edu; Mon, 20 Mar 89 18:54:55 EST
Date: Mon, 20 Mar 89 18:54:55 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903202354.AA04220@wheat-chex.ai.mit.edu>
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: gls@think.com, cl-cleanup@sail.stanford.edu, dick@wheaties.ai.mit.edu
Subject: Issue: PRETTY-PRINT-INTERFACE (version 3)


RE: your recent comments.

(1) Clearly, the right statements about length units need to be put in
the proposal.  A note advising programmers to use explicit lengths as
little as possible also sounds like a good idea.

(2) I agree that it was a severe error to omit the funcional interface.
However, I also think it would be a severe error to omit the format interface.

(3) I understand why you would like to have define-print-dispatch
    merged with the CLOS stuff.  I will look into that.  (Can you
    remind me of the issue of SIGPLAN notices that CLOS was described
    in?  Is that accurate?)  However, I think there may be problems.
      First, although not particularly shown in the examples, I have
    found very elaborate type specifies for printing things (e.g.,
    including satisfies clauses) to be quite useful.  In the proposal
    note the use of the specifier (CONS (AND SYMBOL (SATISFIES FBOUNDP))).
      Also note the use of priorities to disambiguate between overlapping
    type specifiers.  This is very important to get propper
    defaulting---i.e. specifying how to print lists in general as well
    as particular special forms.  Maybe some inheretence things can
    make that work in CLOS, but it is not clear to me.
      Finally although it can certainly work, passing style of
    printing arguments around does not appeal to me anywhere near as
    much as multiple dispatch tables, because 
    when you write your first style, you have to set things up to
    allow for more styles even if you never have more styles, or else
    face a lot of work when you make a second style.  It is also not
    clear how this would all fit in with having a standard predefined
    style that users can modify as they wish.
      It seems to me that the pretty printer and CLOS just do not have
    the same idea of what an object is, and that while CLOS primarily
    has a quasi-static association of methods to objects, the pretty
    printer wants to support rapid wholesale change.  Given these
    differences, unification may not work as well as one might hope.

(4) Your suggestions for improving the functional interface basically
sound good to me, however I differ slightly with a couple of them.

  Combining the :stream and :var sounds like a good idea.
  However, The :arg argument is not mandatory.  It is not used in the
    second example I sent around with the functional interface proposal.
  I think that making :prefix, :per-line-prefix, and :suffix functions
    is overkill.  One can always use #. after all.
  Changing the name of :from-start and :from-position and the argument 
    sounds fine to me.
  note that ~/tabular-style/ etc. uses the format interface for
    calling a function.  Therefore it has already been implicitly
    stated that tabular-style, fill-style, and linear-style, are
    functions and what their arguments are.  The definition of the
    function linear-style is given as an example, and fill-style is
    used as a function in another example in the original proposal.
    Nevertheless, the functional interface part should note that they
    are functions.


∂20-Mar-89  1605	CL-Cleanup-mailer 	Issue: FIXNUM-NON-PORTABLE, v.5
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89  16:04:01 PST
Received: from fafnir.think.com by Think.COM; Mon, 20 Mar 89 11:47:53 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 20 Mar 89 11:48:52 EST
Received: by verdi.think.com; Mon, 20 Mar 89 11:45:31 EST
Date: Mon, 20 Mar 89 11:45:31 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903201645.AA17143@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 17 Mar 89 19:53 EST <19890318005344.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: FIXNUM-NON-PORTABLE, v.5

   Date: Fri, 17 Mar 89 19:53 EST
   From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>

       Date: 16 Mar 89 21:51 PST
       From: masinter.pa@Xerox.COM

       This is my rewrite to capture the 'intent' of the amendment
       at the January X3J13. I say 'intent' because the relation
       between MOST-POSITIVE-FIXNUM (which is an inclusive bound)
       and ARRAY-DIMENSION-LIMIT (which is an exclusive bound) is not
       > but rather (>= MOST-POSITIVE-FIXNUM (1- ARRAY-DIMENSION-LIMIT)).

   No, the amendment was (<= ARRAY-DIMENSION-LIMIT MOST-POSITIVE-FIXNUM),
   and this was not a mistake nor an off-by-one error.  What you've
   put in the proposal here is incorrect, I think.  I think it was
   fully intended that not only every valid array index and every
   array dimension, but also array-dimension-limit itself would be
   a fixnum.  Someone might want to write an arithmetic iteration
   whose upper bound was array-dimension-limit.

I agree with Moon's observations and assessment; this was my understanding
of the amendment.

Pascal-type languages have had no end of grief because iteration counters
take on "invalid" (read "non-fixnum" here and you'll get the idea) values
at the end of the last iteration.

--Guy

∂20-Mar-89  1841	CL-Cleanup-mailer 	Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  18:41:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561599; Mon 20-Mar-89 21:39:43 EST
Date: Mon, 20 Mar 89 21:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE (version 3)
To: dick@wheaties.ai.mit.edu
cc: gls@think.com, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8903202354.AA04220@wheat-chex.ai.mit.edu>
Message-ID: <19890321023936.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 20 Mar 89 18:54:55 EST
    From: dick@wheaties.ai.mit.edu
    ....
    (Can you
    remind me of the issue of SIGPLAN notices that CLOS was described
    in?  Is that accurate?)  

SIGPlan Notices (ISSN 0362-1340)
Volume 23
Special Issue -- September 1988
ISBN 0-89791-289-6
ACM Order Number 548883

I don't know whether it's accurate, I haven't looked at it.  I imagine
it is an exact copy of X3J13 document 88-002R, which is pretty close.

    (3) I understand why you would like to have define-print-dispatch
	merged with the CLOS stuff.  I will look into that.  However, I think there may be problems.
	  First, although not particularly shown in the examples, I have
	found very elaborate type specifies for printing things (e.g.,
	including satisfies clauses) to be quite useful.  In the proposal
	note the use of the specifier (CONS (AND SYMBOL (SATISFIES FBOUNDP))).
	  Also note the use of priorities to disambiguate between overlapping
	type specifiers.  This is very important to get propper
	defaulting---i.e. specifying how to print lists in general as well
	as particular special forms.  Maybe some inheretence things can
	make that work in CLOS, but it is not clear to me.

So what you're saying is that you want to use type specifiers that have
unclear subtype/supertype relationships, and compensate for that by
using numerical priorities.  I understand now.  CLOS cannot currently
handle that through the normal parameter specializer mechanism, because
it requires clear subtype/supertype relationships from the type
specifiers alone.  On the other hand, one could make a form of method
combination that did the same thing as define-print-dispatch, but that
would be going through the back door.  On the third hand, some of the
applicability testing could be moved into the body of the method and
call-next-method employed.

At this point I don't know what to say; expediency and elegance seem
to be in direct conflict.  Maybe someone else has an idea.  I certainly
will not block the thing for this point of esthetics, but it does raise
a red flag for me that something somewhere is inadequate.

	  Finally although it can certainly work, passing style of
	printing arguments around does not appeal to me anywhere near as
	much as multiple dispatch tables, because 
	when you write your first style, you have to set things up to
	allow for more styles even if you never have more styles, or else
	face a lot of work when you make a second style.  It is also not
	clear how this would all fit in with having a standard predefined
	style that users can modify as they wish.

I think if you think about this harder you'll realize that dispatch tables
and style-of-printing arguments are isomorphic and differ only in some
minor internal implementation details.

	  It seems to me that the pretty printer and CLOS just do not have
	the same idea of what an object is, and that while CLOS primarily
	has a quasi-static association of methods to objects, the pretty
	printer wants to support rapid wholesale change.  Given these
	differences, unification may not work as well as one might hope.

I think this is a non-issue, but the real problem is what you said above
complex type specifiers.

    (4) Your suggestions for improving the functional interface basically
    sound good to me, however I differ slightly with a couple of them.

      Combining the :stream and :var sounds like a good idea.
      However, The :arg argument is not mandatory.  It is not used in the
	second example I sent around with the functional interface proposal.

I don't recall seeing any examples of the functional interface.  Let me
ask, how frequently is the :arg argument omitted?  If it's omitted very
infrequently, it would be better to supply an explicit nil in those cases
than to say :arg in all the rest of the cases.

      I think that making :prefix, :per-line-prefix, and :suffix functions
	is overkill.  One can always use #. after all.

No, the issue is a function that decides at run time what to output, rather
than having a canned string.  Whether the string appears in the source or
is generated at compile time is of no moment.  But if you don't want to
put in the extra flexibility, I won't complain, I don't have a specific
use for it in mind, I only proposed it on general principles.

∂20-Mar-89  2059	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE (version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89  20:59:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561655; Mon 20-Mar-89 23:36:27 EST
Date: Mon, 20 Mar 89 23:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: <19890320180405.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890321043621.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

      When constructing a pathname from components, conforming programs
      must follow these rules:
  
      16. Any component can be taken from the corresponding component
      of another pathname on the same host and device.

A possible alternative that's worth considering is:

      16. Any component can be taken from the corresponding component
      of another pathname.  When the two pathnames are for incompatible
      file systems (in implementations that support multiple file
      systems), an appropriate translation occurs.  If no meaningful
      translation is possible, an error is signalled.  The definition
      of "appropriate" and "meaningful" is implementation-dependent.

This provides more useful behavior that conforming programs can 
depend upon, but the behavior cannot be as precisely specified.
A significant amount of the Symbolics Genera pathname facility is
related to this capability, and it's used a lot in heterogeneous
networks, so maybe this is a useful capability that ought to be
called for in the language.  The cost to implementors is small since
they could define "appropriate" and "meaningful" to be whatever is
easiest for them, if their users don't complain.

∂21-Mar-89  0845	CL-Cleanup-mailer 	Issue: GENSYM-NAME-STICKINESS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89  08:45:45 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561958; Tue 21-Mar-89 11:45:31 EST
Date: Tue, 21 Mar 89 11:45 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890321114510.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

Hopefully this is a final version, ready for vote.
Guy has already reviewed it and approves of the changes
(removing GENSYM-COUNTER, adding variable *GENSYM-COUNTER*).
 -kmp

-----
Issue:        GENSYM-NAME-STICKINESS
Forum:	      Cleanup
References:   GENSYM (p169)
Category:     CHANGE
Edit history: 14-Feb-89, Version 1 by Pitman
	      15-Mar-89, Version 2 by Steele (add GENSYM-COUNTER function)
	      20-Mar-89, Version 3 by Pitman (make it a variable)

Problem Description:

  Many people avoid use of the argument to GENSYM because the argument
  is `sticky' and such stickiness can lead to confusion. The problem is
  that if any application (usually a macro) uses the gensym argument at
  all, then all applications are forced to. If they do not, they risk
  finding that the `helpful' argument supplied in some previous call will
  be harmful to them.

Proposal (GENSYM-NAME-STICKINESS:LIKE-TEFLON)

  Define that if an optional argument [either a string or a number] is
  given to GENSYM, it does NOT have a side-effect on GENSYM's internal state.

  Introduce a new variable, *GENSYM-COUNTER*, which holds the state of
  the gensym counter. That is, the next symbol generated by GENSYM will
  be number n.  The initial value of this variable is not defined, but
  must always be a non-negative integer. This variable may be either 
  assigned or bound by users at any time, but always to a non-negative
  integer.

  Deprecate the use of a numeric argument to GENSYM.

Rationale:

  Conscientious programmers are forced now to write their own GENSYM
  lookalikes because they know the system's GENSYM has an invasive
  effect. This defeats the primary intended function of GENSYM, which
  is to satisfy the most common idiomatic use of MAKE-SYMBOL.

  The stickiness of the GENSYM prefix was an attempt to be gratuitously
  compatible with Maclisp, at the expense of good programming pratice.

  Users who need the old behavior of GENSYM can trivially implement
  that behavior using MAKE-SYMBOL.

  Occasionally you want to reset the GENSYM counter so that, for example,
  you can get the compiler to generate the same symbol names again
  (good for comparing results to see what really changed).

Test Case:

  ;; #1: Test stickiness of name part.
  (CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
	      #\G)
  => NIL ;under CLtL
  => T   ;under this proposal

  ;; #2: Test stickiness of number part.
  (= (PARSE-INTEGER (PROGN (GENSYM 6789) (STRING (GENSYM "G"))) :START 1)
     6790)
  => T   ;under CLtL
  => NIL ;under this proposal (except when *gensym-counter* happens to align)

  ;; #3: Illustrate use of new variable.
  (STRING= (SYMBOL-NAME (LET ((*GENSYM-COUNTER* 43)) (GENSYM "FOO")))
           "FOO43")
  => T   ;under this proposal (not meaningful previously)

Current Practice:

  Symbolics Cloe and Genera are compatible with CLtL, so this would be an
  incompatible change.

Cost to Implementors:

  Very small.

  If any implementations currently use a more compact representation for
  the internal state of GENSYM than a variable holding a string and a
  separate variable holding an integer, they might be forced to change.
  Even then, the change would proabably still be quite small.

Cost to Users:

  Most uses of GENSYM do not depend on the stickiness of the name, so the
  change would be compatible. In some cases, the change would be an
  improvement. Even in the worst case where someone depends on stickiness,
  it's extremely straightforward to write the couple of lines of code to
  produce an application based on MAKE-SYMBOL that is at least as flexible
  as GENSYM, and often moreso.

Cost of Non-Adoption:

  Good programmers would avoid using the argument to GENSYM (or using 
  GENSYM altogether) in many situations where they ought not have to.

Benefits:

  Gensyms which appear to convey information through their name would not
  accidentally pop out and cause confusion in places where they oughtn't.

  Making the gensym counter visible as a variable means that people will
  be able to bind the gensym counter locally when they don't want to affect
  the global counter.

Aesthetics:

  Unnecessary global state changes are hard to reason about. This would 
  be a small simplification.

Discussion:

  Pitman claims to have written a non-sticky GENSYM function for nearly
  every one of the dozen or so large systems that he's written or worked
  on in the last decade in order to get around the stated problem.
  Others have suggested similar experience.

  Pitman and Steele support LIKE-TEFLON.

∂21-Mar-89  1503	CL-Cleanup-mailer 	New cleanup issues   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89  15:02:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562318; Tue 21-Mar-89 18:01:47 EST
Date: Tue, 21 Mar 89 18:01 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New cleanup issues
To: Masinter.pa@XEROX.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <19890321230141.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

Since you were on travel, I took the liberty of mailing a few
additional issues to X3J13.  I'll bring at least one copy of
these to the meeting, and I hope if there is time we can discuss
them and vote to get them out of the way.  None should be controversial.

∂21-Mar-89  1601	CL-Cleanup-mailer 	New issue: WITH-OPEN-FILE-DOES-NOT-EXIST 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89  16:01:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562394; Tue 21-Mar-89 18:59:52 EST
Date: Tue, 21 Mar 89 18:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New issue: WITH-OPEN-FILE-DOES-NOT-EXIST
To: peck@Sun.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8903180525.AA21223@denali.sun.com>
Message-ID: <19890321235935.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

I think WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL is clearly correct,
although I agree that CLtL doesn't really say.

∂21-Mar-89  1643	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE (version 1)   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 21 Mar 89  16:43:10 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Tue, 21 Mar 89 19:20:00 EST
Date: Tue, 21 Mar 89 19:21 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <19890321225242.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890322002110.7.BARMAR@OCCAM.THINK.COM>

This is all well and good, but it doesn't address the BIGGEST obstacle
to portable use of MAKE-PATHNAME: uppercase vs lowercase.  If I can't
write something as simple as

	(setq dp (pathname "/u/barmar/foo.lisp"))
	(namestring (make-pathname :name "bar" :defaults dp))

and have it mean the same thing in Lucid and Genera, what good is all
the rest?  Anyone trying to deal with pathnames portably needs to write
a set of wrapper functions, as Thinking Machines has.  Your proposals
don't really make this much easier.

The only effect of the various pathname proposals is to extend the
standard so that Symbolics's implementation conforms.  I have no problem
with this goal, but I think the approach is wrong.  What's the point of
rules 1-8, which specify the data types that the pathname accessors may
return, but don't specify the semantics of the values?  If we're not
going to specify all the semantics, we might as well just say that they
can return any type, since there's nothing that a portable program can
do besides stick the values in another pathname.  I think the only
useful rules in the whole list are 11 (any component can be NIL), 12
(any component can be :WILD), 15 (the version can be :NEWEST), and 16
(any component may be copied to the corresponding component of another
pathname on the same (EQL?  EQUAL?) host and device).  Rule 13 (most
components can be strings) is not useful because it doesn't define the
relationship between the string specified and the name of the file that
will be accessed (CLtL doesn't say whether (make-pathname :name "FOO")
accesses a file named "FOO", "foo", or "BAR").

Background:

For those of you not familiar with Genera's mechanism for dealing with
pathname case (with which I can't really find fault, because it is the
only way to solve problem of name translation across OS types, but it
does result in portability problems), the above sequence results in
"/u/barmar/BAR.lisp" in Genera, but "/u/barmar/bar.lisp" in most Unix
implementations.  In Genera, the string arguments to MAKE-PATHNAME, and
the results of the PATHNAME-<component> functions, are not necessarily
in the same case the actual pathname, but in a format called
"interchange case".  In interchange format, uppercase represents the
preferred case for the OS, lowercase represents the opposite case, and
mixed case is used verbatim.  This allows you to do

	(make-pathname :name (pathname-name <unix-path>) :defaults <vms-path>)

and have the lowercase Unix name translated to an uppercase VMS name
automatically.

Unfortunately, I can't think of any way to solve this problem in the
standard without incorporating the whole concept of interchange case
into it.  There might not be too much opposition to it if we change the
design so that lowercase were used to represent the preferred case,
though.  How many uppercase-preferred systems are used much for Common
Lisp?  Are there any besides VAX/VMS?  (Uppercase-only systems such as
MS-DOS and case-insensitive systems such as Macintosh don't count, since
they can use uppercase or lowercase interchangeably without affecting
the semantics.)

By the way, there should probably be a rule somewhere that says that
portable programs shouldn't expect to be able to create and/or access
distinct files whose pathname components differ only in case.

∂21-Mar-89  1752	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE (version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89  17:52:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562499; Tue 21-Mar-89 20:49:08 EST
Date: Tue, 21 Mar 89 20:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
To: Barry Margolin <barmar@Think.COM>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19890322002110.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890322014857.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 21 Mar 89 19:21 EST
    From: Barry Margolin <barmar@Think.COM>

    This is all well and good, but it doesn't address the BIGGEST obstacle
    to portable use of MAKE-PATHNAME: uppercase vs lowercase.  

PATHNAME-COMPONENT-CASE addresses that; it's a separate issue.  I don't
know whether it's on the agenda for next week, but I hope it is.

    The only effect of the various pathname proposals is to extend the
    standard so that Symbolics's implementation conforms.  

Well, I certainly hope that with all the pathname proposals together, 
that is not the only effect!  The goal is to constrain the semantics
of pathnames enough to allow writing portable pathname-using programs,
so people will stop complaining that pathnames are a useless wart.

Maybe it was wrong to break it up into separate issues.

							   I have no problem
    with this goal, but I think the approach is wrong.  What's the point of
    rules 1-8, which specify the data types that the pathname accessors may
    return, but don't specify the semantics of the values?  If we're not
    going to specify all the semantics, we might as well just say that they
    can return any type, since there's nothing that a portable program can
    do besides stick the values in another pathname.  I think the only
    useful rules in the whole list are 11 (any component can be NIL), 12
    (any component can be :WILD), 15 (the version can be :NEWEST), and 16
    (any component may be copied to the corresponding component of another
    pathname on the same (EQL?  EQUAL?) host and device).  Rule 13 (most
    components can be strings) is not useful because it doesn't define the
    relationship between the string specified and the name of the file that
    will be accessed (CLtL doesn't say whether (make-pathname :name "FOO")
    accesses a file named "FOO", "foo", or "BAR").

I think you're partly right here.  It was probably a mistake to try to
constrain the types of "structured" values, because there is nothing
that a portable program can do with a "structured" value that depends on
the type.

As for strings, the intent was that with PATHNAME-COMPONENT-CASE the
relation between the string and the name of the file is fully specified;
I guess that wasn't at all clear from the PATHNAME-COMPONENT-VALUE
writeup.  Similarly, with PATHNAME-SUBDIRECTORY-LIST the relation
between the list and the name of the directory is fully specified.

I see the proposal for PATHNAME-COMPONENT-CASE is rather stale, I'll
see if I can work up a version updated from the discussion tonight or
tomorrow.

    By the way, there should probably be a rule somewhere that says that
    portable programs shouldn't expect to be able to create and/or access
    distinct files whose pathname components differ only in case.

Good point.

∂21-Mar-89  2227	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE (version 1)   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 21 Mar 89  22:27:46 PST
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Wed, 22 Mar 89 00:54:22 EST
Received: by kulla.think.com; Wed, 22 Mar 89 00:54:37 EST
Date: Wed, 22 Mar 89 00:54:37 EST
From: barmar@Think.COM
Message-Id: <8903220554.AA25095@kulla.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 21 Mar 89 20:48 EST <19890322014857.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)

Not being on cl-cleanup, I wasn't aware of PATHNAME-COMPONENT-CASE.
You may be right that it was wrong to break up the issues.  On the
other hand, merging them all together would probably result in a
2K-line issue, which is no fun, either.

						barmar

∂22-Mar-89  1054	CL-Cleanup-mailer 	PRETTY-PRINT-INTERFACE, version 4   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89  10:54:13 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Wed, 22 Mar 89 13:54:36 EST
Received: from localhost by wheat-chex.ai.mit.edu; Wed, 22 Mar 89 13:54:34 EST
Date: Wed, 22 Mar 89 13:54:34 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903221854.AA10669@wheat-chex.ai.mit.edu>
To: cl-cleanup@sail.stanford.edu
Subject: PRETTY-PRINT-INTERFACE, version 4


Version 3 (by Guy Steele Jr) supersedes version 2 and is changed from
version 1 as follows: adds a functional interface to supplement the
interface through FORMAT, and reflects comments by Barrett and
Pierson.

Version 4 (by Dick Waters) is changed from version 3 as follows: The
short summary is updated to reflect the functional interface.  The
functional interface is changed following suggestions made by Dave Moon.
The proposal is amended in a few minor ways to increase the
compatibility with variable width fonts.  Additional discussion has been
added with regard to the advantages of XP with regard to handling
circularity detection and abbreviation, the interaction with CLOS, and
the extended type specifier CONS used by XP.

The document attached to version 1 has also been fully revised, but is
sent in a separate message due to mailer problems.
--Dick

Issue:		PRETTY-PRINT-INTERFACE

References:	Description of XP by Dick Waters (attached)
		*PRINT-PRETTY* (CLtL p. 371)
		WRITE (CLtL p. 382)
		PPRINT (CLtL p. 383)
		FORMAT (CLtL pp. 385-407)
		FORMAT ~T directive (CLtL pp. 398-399)
		FORMAT ~< directive (CLtL pp. 404-406)

Related issues: 

Category:	CLARIFICATION CHANGE ADDITION

Edit history:	Version 1, 24-Feb-89 by Steele
		Version 2, 15-Mar-89 by Steele and Waters
		Version 3, 15-Mar-89 by Steele
		Version 4, 22-Mar-89 by Waters

Problem description:

At present, Common Lisp provides no specification whatsoever of how
pretty-printing is to be accomplished, and no way for the user to control
it.  In particular, there is no protocol by which a user can write a
print-function for a structure, or a method for PRINT-OBJECT, that will
interact smoothly with the built-in pretty-printer in a portable manner.

Proposal (PRETTY-PRINT-INTERFACE:XP):

Adopt the interfaces and protocols of the XP pretty-printer by Dick Waters,
described in full in the attached 12-page document.  Here is a very brief
summary of the proposal.

New variables:	*PRINT-DISPATCH*
		*PRINT-RIGHT-MARGIN*
		*DEFAULT-RIGHT-MARGIN*
		*PRINT-MISER-WIDTH*
		*PRINT-LINES*
		*LAST-ABBREVIATED-PRINTING*

New functions:	COPY-PRINT-DISPATCH
		FILL-STYLE
		LINEAR-STYLE
		TABULAR-STYLE
		CONDITIONAL-NEWLINE
		LOGICAL-BLOCK-TAB
		LOGICAL-BLOCK-INDENT

New macros:	DEFINE-PRINT-DISPATCH
		WITHIN-LOGICAL-BLOCK
		LOGICAL-BLOCK-COUNT
		LOGICAL-BLOCK-POP

New FORMAT directives:	~W  ~_  ~I  ~:T  ~/name/  ~<...~:>

New # reader macro:  #"..."

The function WRITE is extended to accept additional keyword arguments
:DISPATCH, :RIGHT-MARGIN, :LINES, and :MISER-WIDTH corresponding to the
first four of the new variables.


Examples:	See attached document.

Rationale:

There ought to be a good user interface to the pretty printer.
This is the only proposal for which there is a portable implementation
that has seen extensive use and is being made freely available.


Current practice:

XP son of PP son of GPRINT son of PRINT* is the latest in a line of pretty
printers that goes back 13 years.  All of these printers use essentially
the same basic algorithm and conceptual interface.  Further, except for
PRINT*, which was implemented solely to satisfy the author's personal
needs, each of these printers has had extensive use.  XP has been in
experimental use as the pretty printer in CMU Common Lisp for 6 months.  PP
has been the pretty printer in DEC Common Lisp for the past 3 years.  Prior
to three years ago, GPRINT was used for 2 years as the pretty printer in
DEC Common Lisp.  In addition, GPRINT has been the pretty printer in
various generations of Symbolics Lisp for upwards of 5 years.
(See Waters R.C., "User Format Control in a Lisp Prettyprinter", ACM TOPLAS,
5(4):513--531, October 1983.)


Cost to Implementors:

A fair amount of effort (perhaps a few man-weeks at most).
Source code for XP is available to all comers from Dick Waters, and
the system is documented in great detail:

Waters, Richard C., "XP: A Common Lisp Pretty Printing System",
Artificial Intelligence Laboratory Technical Memo 1102,
Massachusetts Institute of Technology, Cambridge MA, March 1989.


Cost to Users:  None (I think).  This is an upward-compatible extension.

Cost of non-adoption:  Continued inability for user print-functions
to interact with the pretty-printer in a useful and portable manner.


Performance impact:  XP is claimed to be quite fast.

Benefits:  User control of pretty-printing in a portable manner.

Aesthetics:

Using ~<...~:> may strike some as uncomfortably close in the syntactic
space of FORMAT directives to the existing ~<...~>.  However, it is very
unlikely that both of these directives (pretty-print logical block and
columnar justification, respectively) will be used in the same call to
FORMAT.  Previous versions of XP used ~!...~. instead of ~<...~:> but this
made FORMAT strings very difficult to read; it is preferable to have
a directive that looks like matching brackets of some sort.

Dan Pierson comments:  You might mention that some people will undoubtedly
find piling more hair on FORMAT ugly (of course these same people may
well find FORMAT in general ugly :-)).

Discussion:

Zetalisp used ~:T to mean pixelwise tabulation, so the use of ~:T
suggested here may be a problem.  If so, another suggestion for naming
this directive would be appropriate.

The ~/.../ directive is already in Zetalisp, and is not an idea new
to this proposal.  However, it should be noted that the proposal for
~/.../ here is simpler than, and incompatible with, the current Zatalisp
practice.

Guy Steele and Dick Waters strongly support this proposal.  (As an example,
Guy Steele has a portable simulator for Connection Machine Lisp, and would
like very much to have xappings and xectors pretty-print properly.)


Dan Pierson comments: You can add me to the list of strong supporters of
this proposal.  While the proposal is long and complex, it is supported by
a long history of usage in several different Lisp environments.  Unlike
some earlier members of this family, this version fits cleanly enough into
the rest of Common Lisp to warrant standardization.

The utility of *PRINT-LINES* becomes more obvious if it is pointed out
that Dick's pretty printers are implemented to print each line as it
is computed.  This means that a small value for *PRINT-LINES* saves
significant time as well as output medium space.  In fact, many people
find that a very pleasant REP loop is created by setting *PRINT-LINES*
to a value from 1-4, *PRINT-PRETTY* to T, and defining a short-name
function (say (PP*)) that funcalls *LAST-ABBREVIATED-PRINTING* with
abbreviation bound off.  This is almost as fast and compact as, and
MUCH more readable than, a non-pretty-printing REP loop.

The advantages of compiled format strings (format functions) should be
brought out as benefits in their own right.  The current proposal just
mentions them as a minor feature of XP.

At first this struck me a very cute end run around the failure of
STREAM-INFO, then I realized that one of the problems with STREAM-INFO
may have been that it was a standard at the wrong level.  STREAM-INFO
permitted people to use XP, but not to count on it.  This proposal
makes it possible to write portable code whose new data structures and
language elements print correctly in whatever Common Lisp environment
they're run in.  [End of comments by Pierson]


It has been noted by Guy Steele that some places in the initial document
where it says that circularity detection is handled correctly, this is
true a fortiori following the decision on PRINT-CIRCLE-STRUCTURE.
However, Waters notes that the vote on PRINT-CIRCLE-STRUCTURE said
nothing about the handling of *PRINT-LEVEL*.  Therefore, the fact that
XP handles *PRINT-LEVEL* correctly is an improvement.

In addition, PRINT-CIRCLE-STRUCTURE is also silent on what is supposed
to happen if a user program decomposes a list itself (e.g., with DOLIST
or ~{~}) rather than calling a print function.  Assumedly *PRINT-CIRCLE*
etc. is not handled in this case.  In contrast, if one uses
WITHIN-LOGICAL-BLOCK or ~<~:>, then *PRINT-CIRCLE*, *PRINT-LEVEL*, and
*PRINT-LENGTH* are all automatically handled correctly.

For example, (format nil "-~1{~A ~A ~A ~A ~A ~}-" '#1=(1 #1# 2 . #1#))?
produces "-1 #1=(1 #1# 2 . #1#) 2 1 #1=(1 #1# 2 . #1#) -"
even under PRINT-CIRCLE-STRUCTURE and
(format nil "-~1{~A ~}-" '#1=(1 #1# 2 . #1#)) 
cause infinite looping.  However, in XP,
(format nil "-~:<~W ~W ~W ~W ~W~:>-" '#1=(1 #1# 2 . #1#))
produces "-#1=(1 #1# 2 . #1#)-".
This proves to be very useful when writing pretty printing functions for things.
Note also that ~<~:> supports *print-level* and *print-length* correctly.
All the same things can be said about the functional interface and using
WITHIN-LOGICAL-BLOCK rather than traversing a list yourself in some fashion.

All in all, Waters claims that PRINT-CIRCLE-STRUCTURE covers at most 1/4
of what XP does in support of *print-circle* and does not cover anything
of what XP does to support *print-level*, *print-length*, and
robustness in the face of malformed arguments.  These are vital
features for writing printing functions that really work right all the time.


It has been noted by Dave Moon that things would be much more elegant if
DEFINE-PRINT-DISPATCH could be expressed directly as a CLOS DEFMETHOD
for an appropriate generic function.  Dick Waters agrees with this.
However, DEFINE-PRINT-DISPATCH depends on type specifiers that are more
complex than the ones CLOS deals with and ones that do not have clear
subtype/supertype relationships, compensating for the latter problem by
supporting numerical priorities to disambiguate things.  (The defaulting
behavior is a key feature of the pretty printer.)  At the very least,
this means that DEFINE-PRINT-DISPATCH will not fit into CLOS in a simple way.

Given the problems, Moon suggests that "it does seem that right now it
might be best to keep a separate DEFINE-PRINT-DISPATCH macro, with the
idea that the expansion is implementation-dependent at the moment, but
might some day be changed to be defined to expand into DEFMETHOD.  I
haven't looked to see whether any syntactic changes would be appropriate
to make that transition smoother."

(Waters also worries that the overhead needed to locate the right CLOS
method would seriously degrade the pretty printer, because the printer
has to do this for every part of every object printed.  This dispatching is
currently done by very fast code that is tuned to take advantage of the
observed distribution of kinds of objects that have special pretty
printers attached to them.  Even with this special purpose code,
dispatching takes a significant part of the pretty printer's time.)


Dave Moon also comments that it is not good to have something that looks
like a type specifier (i.e., the extended form of the CONS type specifier
used by DEFINE-PRINT-DISPATCH) and yet is not a real type specifier.  He
suggests that we should either amend Common Lisp to accept the extended
form of the CONS type specifier, or stop having DEFINE-PRINT-DISPATCH
use it.  

Waters supports any course of action that retains the use of the
extended CONS type specifier in conjunction with DEFINE-PRINT-DISPATCH.
However, he notes that the trade-off is clear.  One could avoid the
complex CONS type specifier without any significant loss of
functionality by introducing a new macro DEFINE-LIST-PRINT-DISPATCH that
is identical to DEFINE-PRINT-DISPATCH except that it is relevant only to
conses and the type specifier applies to the CAR of the object to be
printed rather than to the object as a whole.  However, this appears to
him to be significantly less elegant than the current approach.

-------------------- detailed documentation --------------------

The full description is too large to fit in with everything else in this
message.  A fully correct version follows in a separate message.  The
stuff below summarizes all of the changes from the full description in
version 1.
                          Amendments

To a considerable extent, the design of the XP interface is completely
neutral about the issue of variable- versus fixed- width fonts.  In
particular, most of the discussion of how the formating proceeds either
talks about absolute positions of zero or talks about something being
in the same horizontal position as something else.  These statements are
all font-independent.  (Further, although Waters' current implementation
does not support variable-width fonts, the algorithms used could be
extended to support them without radical changes.)

Nevertheless, there are 9 places where users specify explicit
non-zero lengths: the variables *PRINT-RIGHT-MARGIN*,
*DEFAULT-RIGHT-MARGIN*, and *PRINT-MISER-WIDTH*, the numeric
arguments to ~T, ~I, and ~/tabular-style/ and their associated functions
LOGICAL-BLOCK-TAB, LOGICAL-BLOCK-INDENT, and TABULAR-STYLE.

It is proposed that all of these lengths be in the same units, and that
this unit be ems (the length of an "m" in the font currently being used
to output characters to the relevant output stream at the moment that
the command is encountered or a variable is consulted).

It is further proposed that users and implementors be advised to set
things up so that explicit lengths do not have to be specified.  For
implementors, this means making streams smart enough that they know how
wide they are.  (This avoids the use of *PRINT-RIGHT-MARGIN* and
*DEFAULT-RIGHT-MARGIN* in most situations.)  For users, this means
relying on streams knowing their own widths (which is a good idea for
adaptability in any case) and using ~:I to specify indentations wherever
possible.  Further, it should be noted that since *PRINT-MISER-WIDTH* is
essentially heuristic in nature, it does not matter if its value is only
an approximate length and users will only need to change the
value of *PRINT-MISER-WIDTH* in unusual situations.  This leaves only
tabbing as an area where explicit lengths have to be specified on a
regular basis.  Fortunately, approximate lengths are often acceptable in
this situation as well.

                  Functional Interface  

The primary interface to operations for dynamically determining the
arrangement of output is provided through FORMAT.  This is done,
because FORMAT strings are typically the most convenient way of
interacting with pretty printing.  However, these operations have
nothing inherently to do with FORMAT per se.  In particular, they can
also be accessed via the six functions and macros below.

WITHIN-LOGICAL-BLOCK (STREAM-SYMBOL LIST                     [Macro]
                      :PREFIX :PER-LINE-PREFIX :SUFFIX)
                      &BODY BODY

In the manner of ~<...~:>, this macro causes printing to be
grouped into a logical block.  The value NIL is always returned.

STREAM-SYMBOL must be a symbol.  If it is NIL, it is treated the same as
if it were *STANDARD-OUTPUT*.  If it is T, it is treated the same as if
it were *TERMINAL-IO*.  The run-time value of STREAM-SYMBOL must be a
stream.  The logical block is printed into this destination stream.

The BODY can contain any arbitrary Lisp forms.  Within the BODY,
STREAM-SYMBOL is bound to a special kind of stream that supports dynamic
decisions about the arrangement of output and then forwards the output
to the destination stream.  All the standard printing functions (e.g.,
WRITE, PRINC, TERPRI) can be used to print output into STREAM-SYMBOL.
All and only the output sent to STREAM-SYMBOL is treated as being in the
logical block.  (It is an error to send any output directly to the
underlying destination stream.)

The :SUFFIX, :PREFIX, and :PER-LINE-PREFIX must all be expressions that
(at run time) evaluate to strings.  :SUFFIX (which defaults to the null
string) specifies a suffix that is printed just after the logical block.
:PREFIX specifies a prefix to be printed before the beginning of the
logical block.  :PER-LINE-PREFIX specifies a prefix that is printed
before the block and at the beginning of each new line in the block.  It
is an error for :PREFIX and :PRE-LINE-PREFIX to both be used. If neither
is used, a :PREFIX of the null string is assumed.

LIST is interpreted as being a list that BODY is responsible for
printing.  If LIST does not (at run time) evaluate to a list, it is
printed using WRITE.  If *PRINT-CIRCLE* is not NIL and LIST is a
circular reference to a cons, then an appropriate #n# marker is printed.
If *PRINT-LEVEL* is not NIL and the logical block is at a dynamic
nesting depth of greater than *PRINT-LEVEL* in logical blocks, # is
printed.  If either of the three conditions above occures, the indicated
special output is printed on STREAM-SYMBOL and the BODY is skipped along
with the printing of the prefix and suffix.  (If the BODY is
not responsible for printing a list, then the first two tests above can
be turned off by supplying NIL for the LIST argument.)

CONDITIONAL-NEWLINE KIND &OPTIONAL (STREAM *STANDARD-OUTPUT*)    [Function]

CONDITIONAL-NEWLINE is the functional equivalent of ~_.  STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions (i.e., NIL stands for
*STANDARD-OUTPUT* and T stands for *TERMINAL-IO*).  The KIND argument
specifies the style of conditional newline.  It must be one of :LINEAR,
:FILL, :MISER, or :MANDATORY.  If STREAM is a special stream bound by
WITHIN-LOGICAL-BLOCK, a conditional newline is sent to it.  Otherwise,
CONDITIONAL-NEWLINE has no effect.  The value NIL is always returned.

LOGICAL-BLOCK-INDENT RELATIVE-TO N &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]

LOGICAL-BLOCK-INDENT is the functional equivalent of ~I.  STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions.  N specifies the indentation in
ems.  If RELATIVE-TO is :BLOCK, this indentation is relative to the
start of the enclosing block (as for ~I).  If RELATIVE-TO is :CURRENT,
the indentation is relative to the current output position (as for ~:I).
It is an error for RELATIVE-TO to take on any other value.  If STREAM is
a special stream bound by WITHIN-LOGICAL-BLOCK, LOGICAL-BLOCK-INDENT
sets the indentation in the innermost enclosing logical block.
Otherwise, LOGICAL-BLOCK-INDENT has no effect.  The value NIL is always
returned.

LOGICAL-BLOCK-TAB KIND COLNUM COLINC &OPTIONAL (STREAM *STANDARD-OUTPUT*)

LOGICAL-BLOCK-TAB is the functional equivalent of ~T.  STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions.  The arguments COLNUM and COLINC
correspond to the two numeric parameters to ~T and are in terms of ems.
The KIND argument specifies the style of tabbing.  It must be one of
:LINE (tab using ~T), :BLOCK (tab using ~:T), :LINE-RELATIVE (tab using
~@T), or :BLOCK-RELATIVE (tab using ~:@T).  If STREAM is a special
stream bound by WITHIN-LOGICAL-BLOCK, tabbing is performed.  Otherwise,
LOGICAL-BLOCK-TAB has no effect.  The value NIL is always returned.

LOGICAL-BLOCK-POP ARGS &OPTIONAL (STREAM *STANDARD-OUTPUT*)      [Macro]
LOGICAL-BLOCK-COUNT &OPTIONAL (STREAM *STANDARD-OUTPUT*)         [Macro]

LOGICAL-BLOCK-POP is identical to POP except that it supports
*PRINT-LENGTH* and *PRINT-CIRCLE*.  It is an error to use
LOGICAL-BLOCK-POP anywhere other than syntactically nested within a
call on WITHIN-LOGICAL-BLOCK.

ARGS must be a symbol or expression acceptable to POP.  STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions.  If STREAM is a special stream
bound by WITHIN-LOGICAL-BLOCK, then LOGICAL-BLOCK-POP performs the
special operations described below.  Otherwise, LOGICAL-BLOCK-POP is
identical to POP.

Each time LOGICAL-BLOCK-POP is called, it performs three tests.  if
ARGS is not a cons, ". " is printed followed by ARGS.  If
*PRINT-LENGTH* is NIL and LOGICAL-BLOCK-POP has already been called
*PRINT-LENGTH* times within the immediately containing logical block,
"..." is printed.  If *PRINT-CIRCLE* is not NIL, and ARGS is a circular
reference, then ". " is printed followed by an appropriate #n# marker.
If either of the three conditions above occurs, the special output is
printed on :STREAM and the execution of the immediately containing
WITHIN-LOGICAL-BLOCK is terminated except for the printing of the
suffix.  Otherwise, LOGICAL-BLOCK-POP pops the top value off of ARGS
and returns this value.

LOGICAL-BLOCK-COUNT is identical to LOGICAL-BLOCK-POP except that it
does not take an ARGS argument, always returns NIL, and only performs
the second test discussed above.  It is useful when the components of a
non-list are being printed.

Using the functions above, TABULAR-STYLE could be defined as follows.

  (defun tabular-style (s list &optional (colon? T) atsign? (tabsize nil))
      (declare (ignore atsign?))
    (if (null tabsize) (setq tabsize 16))
    (within-logical-block (s list :prefix (if colon? "(" "")
				  :suffix (if colon? ")" ""))
     (when list
       (loop (write (logical-block-pop list s) :stream s)
	     (if (null list) (return nil))
	     (write-char #\space s)
	     (logical-block-tab :block-relative 0 tabsize s)
	     (conditional-newline :fill s)))))

    
The function below prints a vector using #(...) notation.
    
  (defun print-vector (v *standard-output*)
    (within-logical-block (nil nil :prefix "#(" :suffix ")")
      (let ((end (length v)) (i 0))
	(when (plusp end)
	  (loop (logical-block-count)
		(write (aref v i))
		(if (= (incf i) end) (return nil))
		(write-char #\space)
		(conditional-newline :fill))))))

FILL-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN?
LINEAR-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN?
TABULAR-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN? (TABSIZE 16)

The directives ~/fill-style/, ~/linear-style/, and ~/tabular-style/ are
supported by the three functions above.  These functions can also be
called directly by the user.  Each function prints parentheses around
the output if an only if COLON? (default T) is not NIL.  Each function
ignores its ATSIGN? argument and returns NIL.  (These arguments are
optional to facilitate the direct use of the three functions.)  Each
function handles abbreviation and circularity detection correctly, and
uses WRITE to print LIST when given a non-list argument.

The function LINEAR-STYLE prints a list either all on one line, or with
each element on a separate line.  The function FILL-STYLE prints a list
with as many elements as possible on each line.  The function
TABULAR-STYLE is the same as FILL-STYLE except that it prints the
elements so that they line up in columns.  This function takes an
additional argument TABSIZE (default 16) that specifies the column
spacing in ems.

[End of attached document]

∂22-Mar-89  1057	CL-Cleanup-mailer 	PRETTY-PRINT-INTERFACE, version 4   
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89  10:56:27 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Wed, 22 Mar 89 13:56:35 EST
Received: from localhost by wheat-chex.ai.mit.edu; Wed, 22 Mar 89 13:56:33 EST
Date: Wed, 22 Mar 89 13:56:33 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903221856.AA10674@wheat-chex.ai.mit.edu>
To: cl-cleanup@sail.stanford.edu
Subject: PRETTY-PRINT-INTERFACE, version 4


Issue:		PRETTY-PRINT-INTERFACE

Full description of XP accompanying version 4 of the proposal

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

			   Pretty Printing

			  Richard C. Waters


Pretty printing has traditionally been a black box process, displaying
program code using a set of fixed layout rules.  Its utility can be greatly
enhanced by opening it up to user control.

By providing direct access to the mechanisms within the pretty printer that
make dynamic decisions about layout, the FORMAT directives ~_, ~I, and
~<...~:> make it possible to specify pretty printing layout rules as a part
of any function that produces output.  They also make it very easy for
circularity detection and abbreviation based on length and nesting depth to
be supported by the function.  The construct DEFINE-PRINT-DISPATCH makes it
possible to associate a user-defined pretty printing function with any type
of object.  Together, these facilities enable users to redefine the way
code is displayed and allow the full power of pretty printing to be applied
to complex combinations of data structures.

		  Pretty Printing Control Variables

*PRINT-DISPATCH*                                                 [variable]

When *PRINT-PRETTY* is not NIL, the print dispatch table in
*PRINT-DISPATCH* controls the way objects are printed.  The initial value
of *PRINT-DISPATCH* causes traditional pretty printing of Lisp code.

*PRINT-RIGHT-MARGIN*                                             [variable]
*DEFAULT-RIGHT-MARGIN*                                           [variable]

The goal of dynamic layout decisions (when pretty printing or when directly
specified via ~_, ~I, and ~<...~:>) is to keep the output between a pair of
margins.  The left margin is set at the column where the output begins.  If
this cannot be determined, the left margin is set to zero.

When *PRINT-RIGHT-MARGIN* is not NIL, it specifies the right margin to use
when making layout decisions.  When *PRINT-RIGHT-MARGIN* is NIL (the
initial value), the right margin is set at the maximum line length that can
be displayed by the output stream without wraparound or truncation.  If
this cannot be determined, the right margin is set to
*DEFAULT-RIGHT-MARGIN*.  The initial value of *DEFAULT-RIGHT-MARGIN* is
implementation-dependent.

To allow for the possibility of variable-width fonts, both of these
variables are interpreted in terms of ems---the length of an "m"
in the font being used to display characters on the relevant output
stream at the moment when the variables are consulted.

*PRINT-MISER-WIDTH*                                              [variable]

If *PRINT-MISER-WIDTH* is not NIL, the pretty printer switches to a compact
style of output (called miser style) whenever the width available for
printing a substructure is less than or equal to *PRINT-MISER-WIDTH* ems.  The
initial value of *PRINT-MISER-WIDTH* is implementation-dependent.
!
*PRINT-LINES*                                                    [variable]

When given a value other than its initial value of NIL, *PRINT-LINES*
limits the number of output lines produced when something is printed.  If
an attempt is made to go beyond *PRINT-LINES* lines, " ---" is printed at
the end of the last line and printing stops.

(let ((*print-right-margin* 20) (*print-lines* 3))
  (pprint '(setq a 1 b 2 c 3 d 4)))

(SETQ A 1
      B 2
      C 3 ---

*LAST-ABBREVIATED-PRINTING*                                      [variable]

This variable records the last printing event where abbreviation occurred.
Funcalling its value (e.g., after turning off abbreviation) causes the
printing to happen a second time.

The function WRITE accepts keyword arguments :DISPATCH, :RIGHT-MARGIN,
:LINES, and :MISER-WIDTH corresponding to *PRINT-DISPATCH*,
*PRINT-RIGHT-MARGIN*, *PRINT-LINES*, and *PRINT-MISER-WIDTH*.


		   Compiling Format Control Strings

The control strings used by FORMAT are essentially programs that perform
printing.  The readmacro character #"..." provides the efficiency of using
a compiled function for printing without losing the conciseness of FORMAT
control strings.  In the notation #"...", the string following # is
identical to a FORMAT control string.  However, the readmacro translates it
into an equivalent sharp-quoted function.  The first expression below is
equivalent to the second.

#"~%~@{~S~↑, ~}"

#'(lambda (stream &rest args)
    (terpri stream)
    (loop (prin1 (pop args) stream)
          (if (null args) (return nil))
          (write-string ", " stream)))

In support of the above, FORMAT accepts functions as its second argument as
well as strings.  When a function is provided, it is called with the
appropriate output stream as its first argument and the data arguments to
FORMAT as its remaining arguments.  The function should perform whatever
output is necessary.  The values returned by the function are ignored.  The
directive ~? also accepts functions as well as control strings.
!
	     Dynamic Control of the Arrangement of Output

The following FORMAT directives support precise control of what should be
done when a piece of output is too large to fit in the space available.
Three concepts underlie the way these directives work---`logical blocks',
`conditional newlines', and `sections'.

The first line of Figure 1 shows a schematic piece of output.  The
characters in the output are represented by "-".  The positions of
conditional newlines are indicated by digits.  The beginnings and ends of
logical blocks are indicated by "<" and ">" respectively.

The output as a whole is a logical block and the outermost section.  This
section is indicated by the 0's on the second line of Figure 1.  Logical
blocks nested within the output are specified by ~<...~:> directives.
Conditional newline positions are specified by ~_ directives.  Each
conditional newline defines two sections (one before it and one after it)
and is associated with a third (the section immediately containing it).

The section after a conditional newline consists of: all the output up to,
but not including, (a) the next conditional newline immediately contained
in the same logical block; or if (a) is not applicable, (b) the next
newline that is at a lesser level of nesting in logical blocks; or if (b)
is not applicable, (c) the end of the output.

The section before a conditional newline consists of: all the output back
to, but not including, (a) the previous conditional newline that is
immediately contained in the same logical block; or if (a) is not
applicable, (b) the beginning of the immediately containing logical block.
The last four lines in Figure 1 indicate the sections before and after the
four conditional newlines.

The section immediately containing a conditional newline is the shortest
section that contains the conditional newline in question.  In Figure 1,
the first conditional newline is immediately contained in the section
marked with 0's, the second and third conditional newlines are immediately
contained in the section before the fourth conditional newline, and the
fourth conditional newline is immediately contained in the section after
the first conditional newline.


                 <-1---<--<--2---3->--4-->->
                 000000000000000000000000000
                 11 111111111111111111111111
                           22 222
                              333 3333
                        44444444444444 44444

Figure 1: Example of logical blocks, conditional newlines, and sections.

Whenever possible, the pretty printer displays the entire contents of a
section on a single line.  However, if the section is too long to fit in
the space available, line breaks are inserted at conditional newline
positions within the section.
!
~W                                                          [format directive]

WRITE -- An arg, any Lisp object, is printed obeying every printer control
variable (as by WRITE).  In addition, ~W interacts correctly with depth
abbreviation, by not resetting the depth counter to zero.  ~W does not
accept parameters.  If given the colon modifier, ~W binds *PRINT-PRETTY* to
T.  If given the atsign modifier, ~W binds *PRINT-LEVEL* and *PRINT-LENGTH*
to NIL.

~W provides automatic support for circularity detection.  If *PRINT-CIRCLE*
is T and ~W is applied to an argument that has already been encountered
during the printing process, an appropriate #n# marker is inserted in the
output instead of printing the argument.

Circularity detection is supported by effectively doing the printing twice.
On the first pass, circularities are detected and the actual outputting of
characters is suppressed.  On the second pass, the appropriate #n= and #n#
markers are inserted and characters are output.

~_                                                          [format directive]

CONDITIONAL NEWLINE -- Without any modifiers, ~_ specifies a
`linear-style' conditional newline.  A line break is inserted if and only
if the immediately containing section cannot be printed on one line.  The
effect of this is that line breaks are either inserted at every
linear-style conditional newline in a logical block or at none of them.

~@_ specifies a `miser-style' conditional newline.  A line break is
inserted if and only if the immediately containing section cannot be
printed on one line and miser style is in effect in the immediately
containing logical block.  The effect of this is that miser-style
conditional newlines act like linear-style conditional newlines, but only
when miser style is in effect.  Miser style is in effect for a logical
block if and only if the the starting column of the logical block is less
than or equal to *PRINT-MISER-WIDTH* columns from the right margin.

~:_ specifies a `fill-style' conditional newline.  A line break is
inserted if and only if either (a) the following section cannot be printed
on the end of the current line, (b) the preceding section was not printed
on a single line, or (c) the immediately containing section cannot be
printed on one line and miser style is in effect in the immediately
containing logical block.  If a logical block is broken up into a number
of subsections by fill-style conditional newlines, the basic effect is
that the logical block is printed with as many subsections as possible on
each line.  However, if miser style is in effect, fill-style conditional
newlines act like linear-style conditional newlines.

~:@_ specifies a `mandatory-style' conditional newline.  A line break is
always inserted.  This implies that none of the containing sections can be
printed on a single line and will therefore trigger the insertion of line
breaks at linear-style conditional newlines in these sections.

When a line break is inserted by any type of conditional newline, any
blanks that immediately precede the conditional newline are omitted from
the output and indentation is introduced at the beginning of the next line.
By default, the indentation causes the following line to begin in the same
column as the first character in the immediately containing logical block.
The indentation can be changed via ~I.

There are a variety of ways unconditional newlines can be introduced into
the output (e.g., via ~% or by printing a string containing a newline
character).  As with mandatory conditional newlines, this prevents any of
the containing sections from being printed on one line.  In general, when
an unconditional newline is encountered, it is printed out without
suppression of the preceding blanks and without any indentation following
it.  However, if a per-line prefix has been specified (see ~<...~:>), this
prefix will always be printed no matter how a newline originates.
!
~<...~:>                                                    [format directive]

LOGICAL BLOCK -- If ~:> is used to terminate a ~<...~>, the directive
delimits a logical block.  In addition, ~<...~:> descends into the
corresponding FORMAT argument (a list) in the same way as the directive
~1{...~:}.  ~↑ can be used to exit from ~<...~:> just as it can be used to
exit from ~{...~}.

The portion of a FORMAT control string enclosed in ~<...~:> can be divided
into segments ~<prefix~;body~;suffix~:> by ~; directives.  It is an error
for the enclosed portion to be divided into more than three segments.  If
the enclosed portion is divided into only two segments, the suffix defaults
to the null string.  If the enclosed portion consists of only a single
segment, both the prefix and the suffix default to the null string.  If the
colon modifier is used with ~<...~:>, the prefix and suffix default to "("
and ")" (respectively) instead of to the null string.

The prefix and suffix must both be constant strings.  They cannot contain
FORMAT directives.  The body can be any arbitrary FORMAT control string.
The prefix is printed out just before the logical block is started and the
suffix is printed out just after the logical block ends.  This is done even
when the argument corresponding to ~<...~:> is an empty list.

If ~<...~:> is applied to an argument that is not a list, the directive is
ignored (suppressing the output of the prefix and suffix) and the offending
argument is printed using ~W.  This makes it easier to write FORMAT strings
that are robust in the face of malformed arguments.

During the processing of the FORMAT string nested in ~<...~:>, arguments
are taken one by one from the list passed to ~<...~:>.  If an attempt is
made to access an argument at a time when the remaining portion of this
argument list is not a cons, then ". " is inserted in the output, ~W is
used to print out the remaining argument list, and the processing of the
logical block is terminated, except for printing the suffix (if any).  This
makes it easier to write FORMAT strings that are robust in the face of
malformed argument lists.  (Note that ~↑ exits only when the remaining
argument list is NIL.)

~<...~:> provides automatic support for depth abbreviation.  If
*PRINT-LEVEL* is not NIL and ~<...~:> is encountered at a dynamic nesting
depth in logical blocks greater than *PRINT-LEVEL*, "#" is inserted in the
output and the ~<...~:> and its associated argument are ignored.

~<...~:> provides automatic support for length abbreviation.  If
*PRINT-LENGTH* is not NIL, a count is kept of the number of arguments used
within the ~<...~:>.  If this count ever reaches *PRINT-LENGTH*, " ..." is
inserted in the output and the processing of the logical block is
terminated, except for printing the suffix (if any).

~<...~:> also provides automatic support for circularity detection.  If
*PRINT-CIRCLE* is T and ~<...~:> (without the atsign modifier) is applied
to a list argument that has already been encountered during the printing
process, an appropriate #n# marker is inserted in the output and the
~<...~:> and its associated argument are ignored.
!
In addition, if an attempt is made to access an argument from the list
passed to ~<...~:>, at a time when the remaining portion of this list has
already been encountered during the printing process, ". #n#" is inserted
in the output and the processing of the logical block is terminated, except
for printing the suffix (if any).  This catches instances of CDR
circularity in lists.

For circularity detection to work correctly when printing an object, every
part of the object that is a cons must be printed using ~<...~:> and every
non-cons must be printed using ~W.  If some part is printed some other way
(e.g., using ~S), circularities involving this part will be missed.

If the atsign modifier is used with ~<...~:>, the entire remaining argument
list is passed to the directive as its argument.  Unlike ~1@{...~} all of
the remaining arguments are always consumed by ~@<...~:>, even if they are
not all used by the FORMAT string nested in the directive.

As an example of the interaction of conditional newlines and logical
blocks, consider the following.  The FORMAT string specifies how to pretty
print a LET.  The outermost ~:<...~:> decomposes the input and specifies
that parentheses should be printed in the output.  The
~:<~@{~:<~@{~W~↑~ _~}~:>~↑ ~:_~}~:> decomposes the list of binding pairs.
Each pair in the list is itself decomposed and printed using
~:<~@{~W~↑ ~_~}~:>.  (An iteration is used in this FORMAT string instead of
merely decomposing the pair into two elements so that a malformed pair
containing more than two elements will print readably.)  A space and a
fill-style conditional newline are placed after each pair except the last.
The ~@{~↑~_ ~W~} prints out the forms in the body of the LET separated by
spaces and linear-style conditional newlines.

(format T #"~:<~W~↑ ~:<~@{~:<~@{~W~↑ ~_~}~:>~↑ ~:_~}~:>~
            ~@{~↑~_ ~W~}~:>"
        '#1=(let (x (*print-length* (f (g 3))) 
                  (z . 2) (k (car y)))
              (setq x (sqrt z)) #1#))

Suppose that *PRINT-PRETTY* is T, *PRINT-LEVEL* is 4, and *PRINT-CIRCLE* is
T.  If the line length is greater than or equal to 77, the output produced
by the FORMAT above appears on one line.  However, if the line length is
76, line breaks are inserted at the linear-style conditional newlines
separating the forms in the body and the output below is produced.  Note
that, the degenerate binding pair X is printed readably even though it
fails to be a list; a depth abbreviation marker is printed in place of
(G 3); the binding pair (Z . 2) is printed readably even though it fails
to be a proper list; and appropriate circularity markers are printed.

#1=(LET (X (*PRINT-LENGTH* (F #)) (Z . 2) (K (CAR Y))) 
     (SETQ X (SQRT Z))
     #1#)

If the line length is reduced to 35, a line break is inserted at one of the
fill-style conditional newlines separating the binding pairs.

#1=(LET (X (*PRINT-PRETTY* (F #))
         (Z . 2) (K (CAR Y)))
     (SETQ X (SQRT Z))
     #1#)
!
Suppose that the line length is further reduced to 22 and *PRINT-LENGTH* is
set to 3. In this situation, line breaks are inserted after both the first
and second binding pairs.  In addition, the second binding pair is itself
broken across two lines.  Clause (b) of the description of fill-style
conditional newlines prevents the binding pair (Z . 2) from being printed
at the end of the third line.  Note that the length abbreviation hides the
circularity from view and therefore the printing of circularity markers
disappears as well.

(LET (X
      (*PRINT-LENGTH*
       (F #))
      (Z . 2) ...)
  (SETQ X (SQRT Z))
  ...)

If ~@; is used to terminate the prefix in ~<...~:>, the prefix is a
`per-line' prefix.  A per-line prefix is printed at the beginning of every
line in the logical block, rather than just before the start of the block
as a whole.  Each instance of the prefix is lined up below the occurrence
of the prefix on the first line.  With a line length of 25, the form below
produces the output shown.

(format T #"~<;;; ~@;Roads ~<= ~@;~W, ~:_~W~:>  ~:_ Town ~W~:>"
           '((elm cottonwood) boston))

;;; Roads = ELM,
;;;       = COTTONWOOD
;;;  Town BOSTON

If ~<...~:> is terminated with ~:@>, then a fill-style conditional newline
is automatically inserted after each group of blanks immediately contained
in the body (except for blanks after a ~<newline> directive).  This makes
it easy to achieve the equivalent of paragraph filling.  With a line length
of 12, the form below produces the output shown.

(format T #"~<~:(~W~) street goes to ~:(~W~).~:@>" 
        '(main boston))

Main street
goes to
Boston.

To a considerable extent, the basic form of the directive ~<...~> is
incompatible with the dynamic control of the arrangement of output by ~W,
~_, ~<...~:>, ~I, and ~:T.  As a result, it is an error for any of these
directives to be nested within ~<...~>.  Beyond this, it is also an error
for the ~<...~:;...~> form of ~<...~> to be used at all in conjunction with
any of these directives.
!
~I                                                          [format directive]

INDENT -- ~nI specifies that the indentation within the immediately
containing logical block should be set to the column position of the
first character in the block plus n ems.  If omitted, n defaults to
zero.  The parameter can be negative; however, the total indentation
cannot be moved left of the beginning of the line or left of the end of
the rightmost per-line prefix.  ~n:I is exactly the same as ~nI except
that it operates relative to the position in the output of the directive
itself, rather than relative to the first character in the block.  (For
robustness in the face of variable-width fonts, it is advisable to use
~:I with a parameter of zero instead of ~I whenever possible.)  Changes
in indentation caused by a ~I directive do not take effect until after
the next line break.  Consider the following example:

(format T #"~:<~W ~@_~:I~W ~:_~W ~1I~_~W~:>" 
        '(defun prod (x y) (* x y)))

If the line width available is 15, both the ~:_ and the ~_ are replaced by
line breaks.  The ~:I directive before the ~W that prints the function name
causes the argument list to be lined up under the function name.  The ~1I
directive before the ~_ specifies that the statement in the body of the
DEFUN should be printed at a relative indentation of 1 in the logical
block.

(DEFUN PROD
       (X Y)
  (* X Y))

In miser style, all ~I directives are ignored, forcing the lines
corresponding to the logical block to line up under the first character in
the block.  If *PRINT-MISER-WIDTH* were greater than or equal to 14 (the
block begins in the second column, after the prefix "(" IS printed), the
example output above would have been as follows.

(DEFUN
 PROD
 (X Y)
 (* X Y))


~:T                                                         [format directive]

TABULATE -- If the colon modifier is used with the ~T directive, the
tabbing computation is done relative to the column where the section
immediately containing the directive begins, rather than with respect to
column zero.  The numerical parameters are both interpreted as being in
units of ems.  Consider the following example.  Each street name is
followed by a ~8:T, which ensures that the total width taken up will be
a multiple of 8.  With a line width of 25, the output shown is produced.

(format T #"~<Roads ~:I~@_~@{~W~↑~8:T~:_~}~:>"
        '(elm main maple center))

Roads ELM     MAIN
      MAPLE   CENTER
!
~/name/                                                     [format directive]

CALL FUNCTION -- User defined functions can be called from within a FORMAT
string by using the directive ~/name/.  The colon modifier, the atsign
modifier, and arbitrarily many parameters can be specified with the ~/name/
directive.  The name can contain a package prefix, but it cannot contain
"/".  If the readmacro #"..." is used, the default package associated with
name will be the value of *PACKAGE* at the moment the #"..." is read.  If
an ordinary FORMAT control string is used, the default package will be the
value of *PACKAGE* at the moment the string is processed by FORMAT.

When a ~/name/ directive is encountered, the indicated function is called
with four or more arguments.  The first four arguments are: the output
stream, the FORMAT argument corresponding to the directive, the value T if
the colon modifier was used (NIL otherwise), and the value T if the atsign
modifier was used (NIL otherwise).  The remaining arguments consist of any
parameters specified with the directive.  The function should print the
argument appropriately.  Any values returned by the function are ignored.

~/LINEAR-STYLE/                                             [format directive]

An argument, a list, is printed so that either all of the elements are on
one line or each element is on a separate line.  Parentheses are printed
around the list if the colon modifier is specified.  As an example of a
function intended to be called from within a FORMAT string, the definition
of LINEAR-STYLE is shown below.

(defun linear-style (stream list &optional (colon? T) atsign?)
    (declare (ignore atsign?))
  (if colon?
      (format stream #"~:<~@{~W~↑ ~_~}~:>" list)
      (format stream #"~<~@{~W~↑ ~_~}~:>" list)))

~/FILL-STYLE/                                               [format directive]

An argument, a list, is printed with as many elements as possible on each
line.  Parentheses are printed around the list if the colon modifier is
specified.

~/TABULAR-STYLE/                                            [format directive]

An argument, a list, is printed in a tabular form with as many elements as
possible on each line.  In addition to the colon modifier, which causes
parentheses to be printed, ~/TABULAR-STYLE/ takes a parameter
(default 16) that specifies the width in ems of columns in the table.
!
                  Functional Interface  

The primary interface to operations for dynamically determining the
arrangement of output is provided through FORMAT.  This is done,
because FORMAT strings are typically the most convenient way of
interacting with pretty printing.  However, these operations have
nothing inherently to do with FORMAT per se.  In particular, they can
also be accessed via the six functions and macros below.

WITHIN-LOGICAL-BLOCK (STREAM-SYMBOL LIST                     [Macro]
                      :PREFIX :PER-LINE-PREFIX :SUFFIX)
                      &BODY BODY

In the manner of ~<...~:>, this macro causes printing to be
grouped into a logical block.  The value NIL is always returned.

STREAM-SYMBOL must be a symbol.  If it is NIL, it is treated the same as
if it were *STANDARD-OUTPUT*.  If it is T, it is treated the same as if
it were *TERMINAL-IO*.  The run-time value of STREAM-SYMBOL must be a
stream.  The logical block is printed into this destination stream.

The BODY can contain any arbitrary Lisp forms.  Within the BODY,
STREAM-SYMBOL is bound to a special kind of stream that supports dynamic
decisions about the arrangement of output and then forwards the output
to the destination stream.  All the standard printing functions (e.g.,
WRITE, PRINC, TERPRI) can be used to print output into STREAM-SYMBOL.
All and only the output sent to STREAM-SYMBOL is treated as being in the
logical block.  (It is an error to send any output directly to the
underlying destination stream.)

The :SUFFIX, :PREFIX, and :PER-LINE-PREFIX must all be expressions that
(at run time) evaluate to strings.  :SUFFIX (which defaults to the null
string) specifies a suffix that is printed just after the logical block.
:PREFIX specifies a prefix to be printed before the beginning of the
logical block.  :PER-LINE-PREFIX specifies a prefix that is printed
before the block and at the beginning of each new line in the block.  It
is an error for :PREFIX and :PRE-LINE-PREFIX to both be used. If neither
is used, a :PREFIX of the null string is assumed.

LIST is interpreted as being a list that BODY is responsible for
printing.  If LIST does not (at run time) evaluate to a list, it is
printed using WRITE.  If *PRINT-CIRCLE* is not NIL and LIST is a
circular reference to a cons, then an appropriate #n# marker is printed.
If *PRINT-LEVEL* is not NIL and the logical block is at a dynamic
nesting depth of greater than *PRINT-LEVEL* in logical blocks, # is
printed.  If either of the three conditions above occures, the indicated
special output is printed on STREAM-SYMBOL and the BODY is skipped along
with the printing of the prefix and suffix.  (If the BODY is
not responsible for printing a list, then the first two tests above can
be turned off by supplying NIL for the LIST argument.)
!
CONDITIONAL-NEWLINE KIND &OPTIONAL (STREAM *STANDARD-OUTPUT*)    [Function]

CONDITIONAL-NEWLINE is the functional equivalent of ~_.  STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions (i.e., NIL stands for
*STANDARD-OUTPUT* and T stands for *TERMINAL-IO*).  The KIND argument
specifies the style of conditional newline.  It must be one of :LINEAR,
:FILL, :MISER, or :MANDATORY.  If STREAM is a special stream bound by
WITHIN-LOGICAL-BLOCK, a conditional newline is sent to it.  Otherwise,
CONDITIONAL-NEWLINE has no effect.  The value NIL is always returned.

LOGICAL-BLOCK-INDENT RELATIVE-TO N &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]

LOGICAL-BLOCK-INDENT is the functional equivalent of ~I.  STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions.  N specifies the indentation in
ems.  If RELATIVE-TO is :BLOCK, this indentation is relative to the
start of the enclosing block (as for ~I).  If RELATIVE-TO is :CURRENT,
the indentation is relative to the current output position (as for ~:I).
It is an error for RELATIVE-TO to take on any other value.  If STREAM is
a special stream bound by WITHIN-LOGICAL-BLOCK, LOGICAL-BLOCK-INDENT
sets the indentation in the innermost enclosing logical block.
Otherwise, LOGICAL-BLOCK-INDENT has no effect.  The value NIL is always
returned.

LOGICAL-BLOCK-TAB KIND COLNUM COLINC &OPTIONAL (STREAM *STANDARD-OUTPUT*)

LOGICAL-BLOCK-TAB is the functional equivalent of ~T.  STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions.  The arguments COLNUM and COLINC
correspond to the two numeric parameters to ~T and are in terms of ems.
The KIND argument specifies the style of tabbing.  It must be one of
:LINE (tab using ~T), :BLOCK (tab using ~:T), :LINE-RELATIVE (tab using
~@T), or :BLOCK-RELATIVE (tab using ~:@T).  If STREAM is a special
stream bound by WITHIN-LOGICAL-BLOCK, tabbing is performed.  Otherwise,
LOGICAL-BLOCK-TAB has no effect.  The value NIL is always returned.

LOGICAL-BLOCK-POP ARGS &OPTIONAL (STREAM *STANDARD-OUTPUT*)      [Macro]
LOGICAL-BLOCK-COUNT &OPTIONAL (STREAM *STANDARD-OUTPUT*)         [Macro]

LOGICAL-BLOCK-POP is identical to POP except that it supports
*PRINT-LENGTH* and *PRINT-CIRCLE*.  It is an error to use
LOGICAL-BLOCK-POP anywhere other than syntactically nested within a
call on WITHIN-LOGICAL-BLOCK.

ARGS must be a symbol or expression acceptable to POP.  STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions.  If STREAM is a special stream
bound by WITHIN-LOGICAL-BLOCK, then LOGICAL-BLOCK-POP performs the
special operations described below.  Otherwise, LOGICAL-BLOCK-POP is
identical to POP.
!
Each time LOGICAL-BLOCK-POP is called, it performs three tests.  if
ARGS is not a cons, ". " is printed followed by ARGS.  If
*PRINT-LENGTH* is NIL and LOGICAL-BLOCK-POP has already been called
*PRINT-LENGTH* times within the immediately containing logical block,
"..." is printed.  If *PRINT-CIRCLE* is not NIL, and ARGS is a circular
reference, then ". " is printed followed by an appropriate #n# marker.
If either of the three conditions above occurs, the special output is
printed on :STREAM and the execution of the immediately containing
WITHIN-LOGICAL-BLOCK is terminated except for the printing of the
suffix.  Otherwise, LOGICAL-BLOCK-POP pops the top value off of ARGS
and returns this value.

LOGICAL-BLOCK-COUNT is identical to LOGICAL-BLOCK-POP except that it
does not take an ARGS argument, always returns NIL, and only performs
the second test discussed above.  It is useful when the components of a
non-list are being printed.

Using the functions above, TABULAR-STYLE could be defined as follows.

  (defun tabular-style (s list &optional (colon? T) atsign? (tabsize nil))
      (declare (ignore atsign?))
    (if (null tabsize) (setq tabsize 16))
    (within-logical-block (s list :prefix (if colon? "(" "")
				  :suffix (if colon? ")" ""))
     (when list
       (loop (write (logical-block-pop list s) :stream s)
	     (if (null list) (return nil))
	     (write-char #\space s)
	     (logical-block-tab :block-relative 0 tabsize s)
	     (conditional-newline :fill s)))))
    
The function below prints a vector using #(...) notation.
    
  (defun print-vector (v *standard-output*)
    (within-logical-block (nil nil :prefix "#(" :suffix ")")
      (let ((end (length v)) (i 0))
	(when (plusp end)
	  (loop (logical-block-count)
		(write (aref v i))
		(if (= (incf i) end) (return nil))
		(write-char #\space)
		(conditional-newline :fill))))))

FILL-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN?
LINEAR-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN?
TABULAR-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN? (TABSIZE 16)

The directives ~/fill-style/, ~/linear-style/, and ~/tabular-style/ are
supported by the three functions above.  These functions can also be
called directly by the user.  Each function prints parentheses around
the output if an only if COLON? (default T) is not NIL.  Each function
ignores its ATSIGN? argument and returns NIL.  (These arguments are
optional to facilitate the direct use of the three functions.)  Each
function handles abbreviation and circularity detection correctly, and
uses WRITE to print LIST when given a non-list argument.

The function LINEAR-STYLE prints a list either all on one line, or with
each element on a separate line.  The function FILL-STYLE prints a list
with as many elements as possible on each line.  The function
TABULAR-STYLE is the same as FILL-STYLE except that it prints the
elements so that they line up in columns.  This function takes an
additional argument TABSIZE (default 16) that specifies the column
spacing in ems.
!
			Print Dispatch Tables

Pretty printing is directed by print dispatch tables.

COPY-PRINT-DISPATCH &optional (table *PRINT-DISPATCH*)           [function]

A copy is made of table, which defaults to the current print dispatch
table.  If table is NIL, a copy is made of the initial print dispatch
table.

DEFINE-PRINT-DISPATCH type-specifier options &body function      [macro]

This puts an entry into a print dispatch table.  The type-specifier
(which is implicitly quoted) is the key of the entry.  The function
specifies how to pretty print the indicated type of object.  When
appropriate, the function is called with two arguments: an output
stream and the object to print.  Any values returned by the function are
ignored.  The options are a list of pairs containing a keyword and a
value.  Three different keywords are supported:

(:TABLE table) 
Specifies the table (default *PRINT-DISPATCH*) to put the dispatch entry
into.

(:PRIORITY number)
Specifies a priority (default 0) used to resolve conflicts when an object
matches more than one entry.

(:NAME name)
Specifies a name to be given to function.  This makes it possible to
reuse the function---e.g., in another call on DEFINE-PRINT-DISPATCH.


Before doing anything else, DEFINE-PRINT-DISPATCH removes any existing
entry with a type specifier EQUAL to the given type specifier.  A new
entry containing the given priority and function is then created.

The function in a DEFINE-PRINT-DISPATCH call can be specified in five
different ways.  First, the function can be NIL.  In this case, no new
entry is made after the old entry (if any) is removed.  Second, the
function can be omitted altogether.  In this case, the standard pretty
printing function (if any) corresponding to the type specifier is entered
into the table.  Third, the function can be an argument list followed by a
body consisting of one or more statements.  (The use of &REST X in the
argument list below makes it possible to use ~/RATIO-PRINT/ in a FORMAT
string.)

(define-print-dispatch ratio ((:name ratio-print)) 
                       (s obj &rest x)
    (declare (ignore x))
  (format s #"#.(/ ~W ~W)" (numerator obj) (denominator obj)))

(pprint '(2/3 -4/5)) prints: (#.(/ 2 3) #.(/ -4 5))
!
Fourth, the function can be an instance of #"...".

(define-print-dispatch (and ratio (satisfies plusp)) 
                       ((:priority 1))
  #"(+ ~/ratio-print/)")

(pprint '(2/3 -4/5)) prints: ((+ #.(/ 2 3)) #.(/ -4 5))

Fifth, the function can be a sharp-quoted function name.  The definition
below shows the default method used for printing lists that represent data,
rather than programs.  (As shown in the definition of LINEAR-STYLE above,
LINEAR-STYLE, FILL-STYLE, and TABULAR-STYLE are all defined with their
COLON? and ATSIGN? arguments optional so that they can be used as
DEFINE-PRINT-DISPATCH functions.)

(define-print-dispatch cons ((:priority -10)) #'fill-style)

The entry to use for printing an object is selected by looking at the
entries in *PRINT-DISPATCH* in the order of their priorities.  The first
entry whose type specifier matches the object is chosen.  If an object
matches two entries with the same priority, an arbitrary choice is made.
If no entry matches the object, the object is printed as if *PRINT-PRETTY*
were NIL.

(CONS car-type cdr-type)                                    [type specifier]

When used simply as the symbol CONS, this type specifier matches any
cons cell.  When used in the form above, it matches a cons cell only if the
car of the cell matches the type specifier car-type and the cdr of
the cell matches the type specifier cdr-type.  The cdr-type can
be omitted in which case it defaults to T.

The examples below show three of the predefined pretty printing functions
for Lisp code.  By default, function calls are printed in the standard
way---i.e, either all on one line or with the arguments one to a line
indented after the function name.

(define-print-dispatch (cons (and symbol (satisfies fboundp)))
                       ((:priority -5))
  #"~:<~W~↑ ~:I~@_~@{~W~↑ ~_~}~:>")

Lists beginning with COND are printed the same way as function calls,
except that the clauses are always printed in linear style, rather than in
the format suggested by their cars.

(define-print-dispatch (cons (member cond)) ()
  #"~:<~W~↑ ~:I~@_~@{~:/linear-style/~↑ ~_~}~:>")

Lists beginning with QUOTE are printed using the standard "'" syntax.  Note
the care taken to ensure that data lists that happen to begin with QUOTE
will be printed legibly.

(define-print-dispatch (cons (member quote)) () (s list)
  (if (and (consp (cdr list)) (null (cddr list)))
      (format s #"'~W" (cadr list))
      (fill-style s list)))
!
In addition to the last four entries shown above, the initial print
dispatch table contains approximately fifty additional entries with type
specifiers of the form (CONS (MEMBER symbol)) and priority zero for various
Lisp special forms and macros.  There are no other predefined pretty
printing functions for data structures other than lists.  However, as shown
below, such entries can easily be defined.

(defstruct family mom kids)

(define-print-dispatch family () (s f)
  (format s #"~@<#<~;~W and ~2I~_~/fill-style/~;>~:>" 
            (family-mom f) (family-kids f)))

The pretty printing function for the structure FAMILY specifies how to
adjust the layout of the output so that it can fit aesthetically into a
variety of line widths.  In addition, it obeys the printer control
variables *PRINT-LEVEL*, *PRINT-LENGTH*, *PRINT-LINES*, *PRINT-CIRCLE*, and
*PRINT-ESCAPE*, and can tolerate several different kinds of malformity in
the data structure.  The output below shows what happens with line width
25, *PRINT-PRETTY T, *PRINT-ESCAPE* NIL, and a malformed KIDS list.

(write (list 'principle-family
             (make-family :mom "Lucy"
                          :kids '("Mark" "Bob" . "Dan"))))

(PRINCIPLE-FAMILY
 #<Lucy and
     Mark Bob . Dan>)
 
Note that a pretty printing function for a structure is different from the
structure's print function.  While print functions are permanently
associated with a structure, pretty printing functions are stored in print
dispatch tables and can be rapidly changed to reflect different printing
needs.  If there is no pretty printing function for a structure in the
current print dispatch table, the print function (if any) is used instead.

[End of attached document]

∂22-Mar-89  1104	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 22 Mar 89  11:01:59 PST
Received: from fafnir.think.com by Think.COM; Wed, 22 Mar 89 13:05:17 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 22 Mar 89 12:56:48 EST
Received: by verdi.think.com; Wed, 22 Mar 89 12:53:33 EST
Date: Wed, 22 Mar 89 12:53:33 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903221753.AA26200@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 21 Mar 89 19:28 EST <19890322002858.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)

After yet more careful study I conclude that the version 9 proposal
is not a clarification but a change.  Here is the reasoning.

There is only one way in Common Lisp to adjust an array, and that is by
calling ADJUST-ARRAY.  (The definition of VECTOR-PUSH-EXTEND, p. 296,
specifically says that it uses ADJUST-ARRAY, and other places in the
language, such as FORMAT with a string as first argument, refer to
VECTOR-PUSH-EXTEND.)

Hence it is senseless to speak of an array that is "adjustable" but cannot
under any circumstances legitimately be given to ADJUST-ARRAY.

Now look at the definition of ADJUST-ARRAY, pp. 297-98.

  It is not permitted to call ADJUST-ARRAY on an array that was not
  created with the :ADJUSTABLE option.  The predicate ADJUSTABLE-ARRAY-P
  may be used to determine whether or not an array is adjustable.

I reason that the first sentence prohibits any array not created with
the :ADJUSTABLE option from being given to ADJUST-ARRAY under any
circumstances.  This includes having been tested with ADJUSTABLE-ARRAY-P.
Therefore any array not created with the :ADJUSTABLE option must be
not adjustable.  Therefore ADJUSTABLE-ARRAY-P must return NIL when
given such an array.  Therefore the following items of the proposal
cannot be true of the current (CLtL) specification:

  1.                                    ... Whether ADJUSTABLE-ARRAY-P is
  true of some other arrays is unspecified.

  b. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
     definitely returns NIL.

Therefore the proposal is a change and not a clarification, and
should be labeled as such.

----------------------------------------------------------------
I think that the following points also require clarification or comment:

(1) What is a compiler permitted to conclude from the declarations
	(DECLARE (SIMPLE-ARRAY FOO)
	         (TYPE (AND ARRAY (NOT SIMPLE-ARRAY)) BAR))
    ?

(2) What is a program permitted to conclude from the test
	(TYPEP X 'SIMPLE-ARRAY)
    both when it returns true and when it returns false?

(3) I believe that much of the controversy stems from disagreement over
    whether the definition on page 28 is considered to be an implication
    or an equivalence.  That is, I think everyone agrees that the
    sentence could be rephrased as:

	An array is simple __________ it is is not displaced to another
	array, has no fill pointer, and is not adjustable.

    but they disagree on whether the blank should read "if" or "iff".
    The proposal should state explicitly which of these two interpretations
    (or what third interpretation) is assumed.

--Guy

∂22-Mar-89  1612	CL-Cleanup-mailer 	Issue: PRETTY-PRINT-INTERFACE, version 4 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89  16:11:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563289; Wed 22-Mar-89 19:11:28 EST
Date: Wed, 22 Mar 89 19:11 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE, version 4
To: dick@wheaties.ai.mit.edu
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8903221854.AA10669@wheat-chex.ai.mit.edu>
Message-ID: <19890323001116.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

Version 4 of the proposal looks good to me.  I noticed one typo,
in the arguments of WITHIN-LOGICAL-BLOCK the word &KEY is missing.
I still think that the FORMAT-based interface and the functional
interface should be separated for voting purposes.

∂22-Mar-89  2239	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4) 
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 22 Mar 89  22:39:31 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
	Thu, 23 Mar 89 00:40:28 CST id AA25401 for cl-cleanup@SAIL.STANFORD.EDU
Posted-Date: Thu, 23 Mar 89 00:38:34 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
	id AA25833; Thu, 23 Mar 89 00:38:34 CST
Date: Thu, 23 Mar 89 00:38:34 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903230638.AA25833@pavo.src.honeywell.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Wed, 22 Mar 89 21:59 EST <19890323025928.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)

    Allow the value of a pathname's directory component to be a list.  The
    car of the list may be either of the symbols :ABSOLUTE or :RELATIVE.
    Each remaining element of the list is a string or one of the keyword
    symbols listed below...

I picked on Kent for not specifying that the elements of the list should be
either strings or keywords, then after reading PATHNAME-WILD, I think that
we should not preclude implmentations from defining "regular expression",
or "user home directory"components.  E.g. 

  (pathname-directory x) => (:absolute "foo" #<regexp "Fo" :wild "bar">)
  (pathname-directory x) => (#<user-homedir "alarson"> "bar" "baz")

I'm not advocating adding such a feature, just not precluding us from
defining one in the future.  Perhaps we should add a line something like:

  "Implementations may permit objects of types other than keywords and
  strings as elements of the pathname-directory list." 

Even without a statement of this kind, I support the proposal.

∂23-Mar-89  0645	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89  06:45:08 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA00648; Thu, 23 Mar 89 07:45:05 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA12384; Thu, 23 Mar 89 07:44:50 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903231444.AA12384@defun.utah.edu>
Date: Thu, 23 Mar 89 07:44:49 MST
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 22 Mar 89 23:30 EST

[removed x3j13; added cl-cleanup]

I don't really like any of these proposals.

Proposal CANONICALIZE is broken because it doesn't provide any way to
specify that a pathname component should be in *exactly* the case you
provide (including all upper or all lower) on file systems that
support mixed case.

Proposals NEW-COMMON-ACCESSORS and NEW-LOCAL-ACCESSORS add too many
functions to the language. 

Proposal KEYWORD-ARGUMENT is the least objectionable of the bunch, but
I still don't like it.  I still claim that there is no portable way to
use MAKE-PATHNAME (even if the problems with case are involved),
because there are other problems with things like the lengths of
strings and what characters are valid in the various pathname fields
on different file systems. 

-Sandra
-------

∂23-Mar-89  0804	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)     
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 23 Mar 89  08:03:56 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA10286; Thu, 23 Mar 89 11:03:37 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA04203; Thu, 23 Mar 89 11:05:32 EST
Message-Id: <8903231605.AA04203@mist.>
To: "sandra%defun@cs.utah.edu"@Multimax.encore.com (Sandra J Loosemore)
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 2) 
In-Reply-To: Your message of Thu, 23 Mar 89 07:44:49 -0700.
             <8903231444.AA12384@defun.utah.edu> 
Date: Thu, 23 Mar 89 11:05:29 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
    Date: Thu, 23 Mar 89 07:44:49 MST

    Proposal KEYWORD-ARGUMENT is the least objectionable of the bunch, but
    I still don't like it.  I still claim that there is no portable way to
    use MAKE-PATHNAME (even if the problems with case are involved),
    because there are other problems with things like the lengths of
    strings and what characters are valid in the various pathname fields
    on different file systems. 
    
Are you saying that there is no portable way to make any desired
pathname or that even if you limit your program to a "portable" subset
of file names that there is no portable way to manipulate them.  

Such a portable subset might be a single alphabetic case, digits, 0 or
1 period, and no more than 14 characters total.  You might be able to
add underscore are well.

∂23-Mar-89  0805	CL-Cleanup-mailer 	Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)  
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 23 Mar 89  08:05:17 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA10302; Thu, 23 Mar 89 11:05:08 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA04217; Thu, 23 Mar 89 11:07:03 EST
Message-Id: <8903231607.AA04217@mist.>
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4) 
Date: Thu, 23 Mar 89 11:07:02 EST
From: Dan L. Pierson <pierson@mist.encore.com>

Date: Thu, 23 Mar 89 10:53:28 EST
From: Dan L. Pierson <pierson>

    I'm not advocating adding such a feature, just not precluding us from
    defining one in the future.  Perhaps we should add a line something like:
    
      "Implementations may permit objects of types other than keywords and
      strings as elements of the pathname-directory list." 
    
    Even without a statement of this kind, I support the proposal.
    
Since we seem to be adopting an overall conformance extensions
position of "everything not explicity permitted is forbidden", I
strongly support this change.  While I will probably vote for the
proposal without the change, note that raising this issue then
rejecting the change amounts to an explicit statement by X3J13 that
such extensions are prohibited.  I think this would be very
unfortunate. 

∂23-Mar-89  0820	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)     
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89  08:20:42 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA03358; Thu, 23 Mar 89 09:20:38 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA12460; Thu, 23 Mar 89 09:20:35 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903231620.AA12460@defun.utah.edu>
Date: Thu, 23 Mar 89 09:20:34 MST
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 2) 
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Dan L. Pierson <pierson@mist.encore.com>, Thu, 23 Mar 89 11:05:29 EST

> Date: Thu, 23 Mar 89 11:05:29 EST
> From: Dan L. Pierson <pierson@mist.encore.com>
> 
> Are you saying that there is no portable way to make any desired
> pathname or that even if you limit your program to a "portable" subset
> of file names that there is no portable way to manipulate them.  
> 
> Such a portable subset might be a single alphabetic case, digits, 0 or
> 1 period, and no more than 14 characters total.  You might be able to
> add underscore are well.

Yup, that's what I'm saying.  We ran into this problem while trying to
port PCLS to the Cray running CTSS a few years ago.  The file system
had no concept of directories or file types, and file names were
restricted to 6 characters. 

Also, the Atari ST's file system (and MS-DOS also?) supports only
1-character device names, 8-character file names and 3-character file
types.  As I recall, IBM's VM/CMS (and I think MVS/TSO too) delimits
the file name and file type with a space instead of a period.

-Sandra
-------

∂23-Mar-89  0919	CL-Cleanup-mailer 	Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89  09:18:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563625; Thu 23-Mar-89 12:18:26 EST
Date: Thu, 23 Mar 89 12:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
To: Sandra J Loosemore <sandra%defun@CS.UTAH.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8903231444.AA12384@defun.utah.edu>
Message-ID: <19890323171821.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 23 Mar 89 07:44:49 MST
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    I still claim that there is no portable way to
    use MAKE-PATHNAME (even if the problems with case are involved),
    because there are other problems with things like the lengths of
    strings and what characters are valid in the various pathname fields
    on different file systems. 

I think there is a big difference between "it is possible to write
non-portable programs using MAKE-PATHNAME" and "it is impossible
to write any useful portable programs using MAKE-PATHNAME."

∂23-Mar-89  1112	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4) 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Mar 89  11:12:20 PST
Received: from pitney-bowes ([192.9.200.50]) by heavens-gate.lucid.com id AA03428g; Thu, 23 Mar 89 11:06:43 PST
Received: by pitney-bowes id AA26285g; Thu, 23 Mar 89 11:04:50 PST
Date: Thu, 23 Mar 89 11:04:50 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8903231904.AA26285@pitney-bowes>
To: pierson@mist.encore.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dan L. Pierson's message of Thu, 23 Mar 89 11:07:02 EST <8903231607.AA04217@mist.>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4) 

I'm also disturbed by the proposed restrictions on the elements of a
pathname-directory list.  Why, for example, is it necessary to
preclude a feature that allows variables to appear?  E.g., the
following seems like a plausibly useful pair of pathnames:

  (:ABSOLUTE *top-of-source-tree*      "a" "b" "c") 
  (:ABSOLUTE *top-of-destination-tree* "a" "b" "c") 

or even:

  (:ABSOLUTE *top-of-source-tree*      . *relative-dir-path*)
  (:ABSOLUTE *top-of-destination-tree* . *relative-dir-path*)

[There's probably better syntax than a dotted pair, but you know what
 I mean.]

I'm not saying I need or even want this particular feature, but I'm
pretty sure I don't want to have it prohibited just because it hadn't
occurred to anyone yet.

[Btw, I think Alarson's example for home dir could be accomomdated as 
 (... :HOME "alarson" ...) in the spirit of the proposal.  Most
 plausible structures could probably be handled similarly, but perhaps
 clumsily.]

   jlm

∂23-Mar-89  1132	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89  11:32:32 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563772; Thu 23-Mar-89 14:31:25 EST
Date: Thu, 23 Mar 89 14:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
To: jlm@Lucid.COM
cc: pierson@Mist.Encore.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8903231904.AA26285@pitney-bowes>
Message-ID: <890323143103.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

Please see the issue writeup for PATHNAME-EXTENSIONS which I'm mailing out to
X3J13 in a little while.  I think it is the correct way to deal with
`[not] precluding extensions.'  It basically allows us to establish a model
for how CL pathnames work, and then to selectively violate that model in a
way that is detectable by portable programs. My hope is that it will allow
you to vote in favor of the PATHNAME-SUBDIRECTORY-LIST proposal in some form
(and perhaps other pathname proposals as well) without worrying that it's going
overly constrain you for some idiosyncratic feature that you wanted but couldn't
get group approval for.

∂23-Mar-89  1205	CL-Cleanup-mailer 	string OK for :CONC-NAME in DEFSTRUCT?   
Received: from arisia (arisia.Xerox.COM) by SAIL.Stanford.EDU with TCP; 23 Mar 89  12:04:54 PST
Received: from bopp.parc.Xerox.COM by arisia with SMTP
	(5.59++/IDA-1.2.6) id AA27611; Thu, 23 Mar 89 12:03:36 PST
Received: by bopp.parc.xerox.com
	(5.61+/IDA-1.2.8/gandalf) id AA00266; Thu, 23 Mar 89 12:04:10 PST
Message-Id: <8903232004.AA00266@bopp.parc.xerox.com>
Reply-To: cutting.pa@bopp.parc.xerox.com
Errors-To: <postmaster@bopp.parc.xerox.com>
Date: Thu, 23 Mar 89 12:04:10 PST
From: cutting.pa@bopp.parc.xerox.com
To: cl-cleanup@SAIL.STANFORD.EDU
Cc: cutting.pa@bopp.parc.xerox.com
Subject: string OK for :CONC-NAME in DEFSTRUCT?

CLtL does not specify whether the :CONC-NAME option to DEFSTRUCT must
be a symbol, or whether strings are allowed.  Its example uses a
symbol, but the default name construction for :COPIER and :PREDICATE
are described in terms of strings, providing some precedence for strings.

Xerox & Lucid allow strings, while Franz does not.  Allowing strings
seems reasonable to me, as no aspect of the symbol is used except for
its name.

Has this question been addressed previously by the cleanup committee?
If not I will gladly writeup a proposal.

	Doug

∂23-Mar-89  1225	CL-Cleanup-mailer 	Meeting 1 hour before plenary session?   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89  12:25:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAR 89 12:21:34 PST
Date: 23 Mar 89 12:19 PST
From: masinter.pa@Xerox.COM
Subject: Meeting 1 hour before plenary session?
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890323-122134-5313@Xerox>

I'm back near a mailbox. Can we get together an hour before the main
session to go over the cleanup report agenda? I want to order the cleanup
issues so that we handle the "important" ones first. I roughly think that
means:

a) fix the cleanups that were previously broken

b) clarifications

c) changes

c) additions


within each category, order mainly by age: handle oldest issues first. But
then, there are some of these that are more 'important' that we'll want to
mess up the order. 

I plan to put together a proposal for dealing with these over the next few
days and will mail it out, but you might want to come prepared with your
own list of "things that are critically important to get voted on this
meeting".


∂23-Mar-89  1504	CL-Cleanup-mailer 	Meeting 1 hour before plenary session?   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89  12:25:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAR 89 12:21:34 PST
Date: 23 Mar 89 12:19 PST
From: masinter.pa@Xerox.COM
Subject: Meeting 1 hour before plenary session?
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890323-122134-5313@Xerox>

I'm back near a mailbox. Can we get together an hour before the main
session to go over the cleanup report agenda? I want to order the cleanup
issues so that we handle the "important" ones first. I roughly think that
means:

a) fix the cleanups that were previously broken

b) clarifications

c) changes

c) additions


within each category, order mainly by age: handle oldest issues first. But
then, there are some of these that are more 'important' that we'll want to
mess up the order. 

I plan to put together a proposal for dealing with these over the next few
days and will mail it out, but you might want to come prepared with your
own list of "things that are critically important to get voted on this
meeting".


∂23-Mar-89  1518	CL-Cleanup-mailer 	Issue: READ-CASE-SENSITIVITY (Version 2) 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 23 Mar 89  15:17:15 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa11717; 23 Mar 89 23:10 GMT
Date: Thu, 23 Mar 89 23:11:13 GMT
Message-Id: <2240.8903232311@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Issue: READ-CASE-SENSITIVITY (Version 2)
To: CL-Cleanup@sail.stanford.edu
Cc: Kent M Pitman <KMP@scrc-stony-brook.arpa>, Masinter.PA@xerox.com, 
    richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK

It's very late, but here it is.

Issue:        READ-CASE-SENSITIVITY

Forum:	      Cleanup

References:   CLtL p 334 ff: What the Read Function Accepts,
                especially p 337, step 8, point 1.
              CLtL p 360 ff: The Readtable
              COPY-READTABLE (CLtL, p 361)
              *PRINT-CASE* (CLtL, p 372)

Category:     ADDITION/CHANGE

Edit history: Version 1, 15-Feb-89, by Dalton
              Version 2, 23-Mar-89, by Dalton,
                (completely new proposal after comments from
                 Pitman, Gray, Masinter, and R.Tobin@uk.ac.ed)

Problem Description:

  The Common Lisp reader always converts unescaped constituent
  characters to upper case.  (See CLtL, p 337, step 8, point 1.)
  This behavior is not always desirable.

  1.  Lisp applications often use the Lisp reader to read their data.
  This is often significantly easier than writing input routines
  from scratch, especially if the input can be structured as lists.
  However, certain applications want to make use of case distinctions,
  and Common Lisp makes this unreasonably difficult.  (You must define
  every letter as a read macro and have the macro function read the
  rest of the symbol, or else you must write a reader from scratch.)

  2.  Some programming languages distinguish between upper and lower
  case in identifiers, and useful conventions are often built around
  such distinctions.  For example, in C, constants are often written
  in upper case and variables in lower.  In Mesa(?) and Smalltalk(?),
  a capital letter is used to indicate the beginning of a new word
  in identifiers made up of several words.  In Edinburgh Prolog,
  variables begin with upper-case letters and constant symbols do
  not.  The case-insensitivity of the Common Lisp reader makes
  it difficult to use conventions of this sort.

Proposal (READ-CASE-SENSITIVITY:READTABLE-KEYWORDS)

  Define a new settable function, (READTABLE-CASE <readtable>) to
  control the reader's interpretation of case.  The following values
  may be given:

    :UPCASE   --  convert unescaped characters to upper-case, as now.
    :DOWNCASE --  convert unescaped characters to lower-case.
    :PRESERVE --  don't convert, leaving lower-case letters in lower
                  case and upper-case characters in upper case.
    :INVERT   --  convert lower-case to upper and upper-case to lower.

  COPY-READTABLE copies the setting of READTABLE-CASE.  The value of
  READTABLE-CASE for the standard readtable is :UPCASE.

  The READTABLE-CASE of a readtable also has significance when
  printing.  The case in which letters are printed is determined as
  follows:

    When READ-CASE is :UPCASE, upper-case letters are printed in the
    case specified by *PRINT-CASE*.

    When READ-CASE is :DOWNCASE, lower-case letters are printed in
    the case specified by *PRINT-CASE*.

    When READ-CASE is :PRESERVE, letters are printed in their own
    case.

    When READ-CASE is :INVERT, the case of all letters is inverted.

  (The behavior when *PRINT-CASE* is :CAPITALIZE is like :UPCASE for
  the first character and :DOWNCASE for the rest.)

  The rules for escaping letters are also affected by the READTABLE-CASE.
  If *PRINT-ESCAPE* is true, letters are escaped as follows:

    When READ-CASE is :UPCASE, all lower-case letters must be escaped.
    When READ-CASE is :DOWNCASE, all upper-case letters must be escaped.
    Otherwise, no letters need be escaped.

Proposal (READ-CASE-SENSITIVITY:READTABLE-FUNCTION)

  Define a new settable function (READTABLE-CHARACTER-TRANSLATION
  <readtable>) to control the reader's interpretation of unescaped
  constituent characters.  The value may be any function of type
  (FUNCTION (CHARACTER) CHARACTER).  Where the reader now converts
  such characters to upper case it should instead call the function
  that is the value of READTABLE-CHARACTER-TRANSLATION for the current
  readtable.  (See CLtL, page 337, step 8, point 1.)

  COPY-READTABLE copies the setting of READTABLE-CHARACTER-TRANSLATION.
  The value for the standard readtable is CHAR-UPCASE.

  The READTABLE-CHARACTER-TRANSLATION of a readtable also has
  significance when printing.  The reader recognizes certain functions
  which control the reader's interpretation of case and alters its
  behavior accordingly.  This behavior is given by the following
  correspondence between functions and the keywords described above.
  [This is just to avoid repeating a lot of text.]

    function           keyword
    CHAR-UPCASE        :UPCASE
    CHAR-DOWNCASE      :DOWNCASE
    IDENTITY           :PRESERVE
    CHAR-INVERT-CASE   :INVERT

  The function can be given either as a symbol or as one of the values
  #'CHAR-UPCASE, #'CHAR-DOWNCASE, #'IDENTITY, #'CHAR-INVERT-CASE.

  If the READTABLE-CHARACTER-TRANSLATION is not one of the functions
  listed above, letters are always printed in their own case (in
  particular, *PRINT-CASE* has no effect), and all characters in
  symbol names are escaped if *PRINT-ESCAPE* is true.

  Define a new function CHAR-INVERT-CASE of type (FUNCTION (CHARACTER)
  CHARACTER) analogous to CHAR-UPCASE and CHAR-DOWNCASE.  It attempts
  to convert its argument to upper-case if the argument is lower-case
  and to lower-case if the argument is upper-case.

Rationale:

  There are a number of different ways to achieve case-sensitivity.
  These proposals are fairly simple but provide all of the
  functionality that one could reasonably expect.

  By using a property of the readtable, we avoid introducing a new
  special variable.  Any code that wishes to control all of the
  reader's parameters already takes *READTABLE* into account.  A new
  special variable would require such code to change.

  :DOWNCASE is included for symmetry with :UPCASE.  :INVERT is
  included so that case conventions could be used in Common Lisp code
  without requiring that the names symbols in the "LISP" package be
  written in upper case.  (Opinions vary as to whether is is advisable
  to use such conventions, but this proposal leaves that choice to the
  user.)

  In order to avoid complex interactions between the case setting of
  the readtable and *PRINT-CASE*, this proposal specifies a
  significance for *PRINT-CASE* only when the case setting is :UPCASE
  or :DOWNCASE.  The meaning of *PRINT-CASE* when the readtable
  setting is :DOWNCASE was chosen for its simplicity and for symmetry
  with :UPCASE while still being useful.

Test Case:

  ;; keyword version
  (let ((rt (copy-readtable nil)))
    (mapcar
      #'(lambda (case)
          (setf (readtable-case rt) case)
          (read-from-string "Zebra"))
      '(:upcase :downcase :preserve :invert)))

    => (ZEBRA |zebra| |Zebra| |zEBRA|) ;as printed with the standard
                                       ;readtable and *print-case* :upcase

Current Practice:

  While there may not be any current implementation that supports
  exactly this proposal, several implementations provide some means
  for changing case sensitivity.

  Franz Inc's ExCL has a function, EXCL:SET-CASE-MODE, that sets both
  the "preferred case" (the case of character in the print names of
  standard symbols such as CAR) and whether or not the reader is case-
  sensitive.

  In Symbolics Common Lisp, the function SET-CHARACTER-TRANSLATION
  can be used to make the translation of a letter be that same letter,
  thus achieving case-sensitivity.

  Xerox Medley has a function for setting a readtable flag that
  determines case sensitivity.

Cost to Implementors:

  Fairly small.  The reader will be slightly slower and readtables
  will be slightly more complex.

Cost to Users:

  Slight.  Programmers must already take into account the possibility
  that *READTABLE* will be a non-standard readtable.  Case-sensitivity
  is no worse than character macros in this respect.

Cost of Non-Adoption:

  Applications that want to read mixed-case expressions will not
  be able to use the Common Lisp reader to do so (except, perhaps,
  by tortuous use of read macros).

  Programming styles that rely on case distinctions (without escape
  characters) will be effectively impossible in Common Lisp.

Benefits:

  Applications will be able to read mixed-case expressions.

  Programmers will be able to make use of case distinctions.

Aesthetics:

  For the proposals: 

    The language will have greater symmetry, because it will be
    possible to control the treatment of case on both input and output
    instead of only on output (as is now the case).

    The language will look less old-fashioned.

  Against the proposals:
  
    It is, perhaps, inconsistent to control case-sensitivity by a
    readtable operation when other aspects of the reader, such as the
    input base and the default float format (not to mention the
    package), are controlled by special variables.  However, it can be
    argued that character-level syntax is determined chiefly by the
    readtable.  Case-sensitivity can be seen as analogous to character
    macros in this respect.

  Keywords vs function

    The keyword proposal is somewhat simpler and avoids raising the
    possibility of character translation that applies in general and
    not just for unescaped constituents.

    The function proposal is perhaps more elegant.

Discussion:

  Dalton supports both proposals but slightly prefers READTABLE-CASE.

  Version 1 of the proposal suggested a new global variable rather
  than a property of the readtable.  Pitman was strongly opposed to
  that proposal and gave convincing arguments that it should be
  dropped.  Gray suggested that the readtable property should be a
  function.

∂23-Mar-89  1534	CL-Cleanup-mailer 	Re: New cleanup issues    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89  15:32:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 89 13:01:56 PST
Date: 23 Mar 89 13:01 PST
From: masinter.pa@Xerox.COM
Subject: Re: New cleanup issues
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Tue, 21 Mar 89 18:01 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.pa@Xerox.COM, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <890323-130156-5430@Xerox>

Thanks. I'm merging them into the master list, and hope to get a master
hardcopy off to Mathis sometime today...

∂23-Mar-89  1538	CL-Cleanup-mailer 	Re: Issue: FIXNUM-NON-PORTABLE, v.5 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89  15:32:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 89 13:14:25 PST
Date: 23 Mar 89 13:13 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FIXNUM-NON-PORTABLE, v.5
In-reply-to: Guy Steele <gls@Think.COM>'s message of Mon, 20 Mar 89
 11:45:31 EST
To: Guy Steele <gls@Think.COM>
cc: Moon@stony-brook.scrc.symbolics.com, masinter.pa@Xerox.COM,
 cl-cleanup@sail.stanford.edu
Message-ID: <890323-131425-5460@Xerox>

Sorry, yes, I blew it. This is what I've saved as "passed":


Status: Passed Jan 89 X3J13, as amended
Issue: FIXNUM-NON-PORTABLE
References:	CLtL p. 14, 34, 43, 231
Category:	CHANGE, CLARIFICATION

Edit History:   Version 1, 11-Jul-88, Sandra Loosemore
		    Version 2, 15-Sep-88, Masinter
		    Version 3, 23-Sep-88, Masinter
		    Version 4,  7-Dec-88, Masinter (two proposals)
		    Version 5, 16-Mar-89, Masinter (incorporate amendments)
		    Version 6, 17-Mar-89, Masinter (incorporate amendments correctly)

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

While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges.  The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.

CLtL p14 and p34 disagree about BIGNUM. One says that
 FIXNUM and BIGNUM are an exhaustive partition of the
integer space, the other says they might not be!

Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION

(1) Change the description of the type FIXNUM to reflect that it is
 required to be a supertype of (SIGNED-BYTE 16).

(2) Define BIGNUM to be exactly (AND INTEGER (NOT FIXNUM))

(3) require that (<= ARRAY-DIMENSION-LIMIT MOST-POSITIVE-FIXNUM)

Example:

Consider an implementation with three numeric representations:

	Fast                (INTEGER -1024 1023)
	Immediate           29 bits
	Extended            Multi-precision

Such an implementation would have to define
FIXNUM to be (OR Fast Immediate). BIGNUM
would then refer to multi-precision integers. 

Rationale:

Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable. 

However, there is little portable use for the type BIGNUM, and it
is inconsistent with many current implementation techniques.
Removing it is an incompatible change for a weak reason.

Current Practice:

Xerox Common Lisp has 17-bit fixnums.  Most other Common Lisp
 implementations have  fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum 
size.

Several existing Common Lisp implementations have more than two 
representations for integers, such that the FIXNUM/BIGNUM distinction
is confusing; they define BIGNUM to cover all of the larger number
types.

Cost to implementors:

Slight.  All implementations we know of already define FIXNUMs to be at
least 16 bits.

Cost to users:

Slight.  

Benefits:

The FIXNUM type specifier would have a portable interpretation.

The language would be less confusing.

Discussion:

There was little consensus on whether to leave BIGNUM in the language.

Earlier discussion of a related proposal contained several other more
controversial components (adding a constant MAX-INTEGER-LENGTH, allowing 
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree
on.

It is possible that an implementation have a single  representation for all
integers, and no way to identify any efficient range of integers. Those
implementations might need to set MOST-POSITIVE-FIXNUM
 and MOST-NEGATIVE-FIXNUM to arbitrary values, consistent with 
the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM.

Other alternatives considered (and not necessarily mutually exclusive
with this proposal):

  remove the FIXNUM type specifier entirely, while leaving a way
  to query what is the most efficient range of integers

   leave the range of FIXNUMs unconstrained  and introduce a 
   SMALL-INTEGER type with a fixed range (but no promises about
   efficiency) . 

It might be possible to specify the required performance behavior
of FIXNUMs more concretely, e.g., specify 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. This might be a useful way to
describe
the intent of the FIXNUM range, if not its specification.

∂23-Mar-89  1538	CL-Cleanup-mailer 	The Revised Cleanup Issue Status List    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89  15:33:50 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 89 13:44:52 PST
Date: 23 Mar 89 13:43 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: The Revised Cleanup Issue Status List
to: X3J13@sail.stanford.edu
Message-ID: <890323-134452-5540@Xerox>

This is the revised (as of 23-Mar-89 13:43:08) complete list of
Cleanup issues that are either:

passed: passed at *any* previous meeting, including Jan 89

pending: have been distributed for the March meeting

in progress: might possibly be distributed for the March meeting,
	or that I think are worth pursuing.

Of course, some more might come up or be revived.

I think I have updated versions of all pending and passed
issues stored on arisia.xerox.com under the
	clcleanup/pending
	clcleanup/passed

directories respectively.

Codes:

! released for Jan 89 meeting
+ passed
* need new version


!*: released, but I know we'll need a new version
+*: passed, but need to reconsider
!*: passed, but need a new version to reconsider

!

+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988

+ ADJUST-ARRAY-FILL-POINTER
 Version 1, 15-MAR-88
Status: passed, 1988

! ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments:  amendment had wording problem.
Version 8, 11-Mar-89, Released 15-Mar-89
Version 9, 17-Mar-89, released 21-mar-89
Comments: (whew!)
Status: ready for vote 

+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13

+ AREF-1D
14-NOV-87, Version 7
Status: Passed, 1988?

+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13

+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13

+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?

! BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Comment: leaves out a case
Status: ready for vote

! CLOS-CONDITIONS
Version 4, 10-Mar-89
Comments: define metaclass of conditions? 
Status: pending

+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13

!+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at meeting
Version 7, 14-Feb-89
Status: Passed, as amended, Jan 89 X3J13
Comment: amendment bad; reconsider version 5.
	say that INPUT-STREAM-P and OUTPUT-STREAM-P
	are undefined on closed streams?

! COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: ready for voting

+ COLON-NUMBER
Synopsis:  :123 is an error
22-OCT-87, Version 1
Status: Passed, 1988?

! COMMON-TYPE
Version 1, 20-Mar-89, released 21-Mar-89
Status: vote

! COMPLEX-RATIONAL-RESULT
Version 1, 20-Mar-89, released 21-Mar-89
Status: vote

+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988?

+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13

!* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version

+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13

! COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: ready for vote

! COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: ready for vote

+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
4-SEP-88 Version 2
Status: Passed, 1988?

+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13

+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89
Status: passed, Jan 89 X3J13

+ DECLARE-FUNCTION-AMBIGUITY
Version 4,  5-Dec-88, Released  5-Dec-88
Status: passed, Jan 89 X3J13

+ DECLARE-MACROS
5-FEB-88, Version 3
Status: Passed, 1988?

+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13

+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13

* DEFMACRO-LAMBDA-LIST
Version 2, 17-Mar-89
Status: ** NEED NEW VERSION **

+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988

+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 3, 6-Feb-89
Status: Passed (as amended) Jan 89 X3J13

+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988

+ DEFVAR-DOCUMENTATION
23-NOV-87, Version 2
Status: Passed, 1988?

+ DEFVAR-INIT-TIME
29-MAR-87, Version 2
Status: Passed, 1988?

+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988?

+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13

! DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
Comments: "and calls DESCRIBE recursively argument if there are ... "
status: need to strike "argument"; then vote

!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Comments: (at end) + "can't extend by defining harmless...????"
Status: might need new version before vote

+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988

+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988?

+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13

+ DRIBBLE-TECHNIQUE
14-FEB-88, Version 2
Status: Passed, 1988?

! DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Comments: still some holes
Status: ready for vote?

+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Status: Passed with amendments
Version 7, 15-Mar-89
Status: Passed Jan 89 X3J13 as amended.

* EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Comments: Various problems being worked on
Status: ** NEED NEW VERSION ***

* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: ** NEED NEW VERSION **

! ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: ready for vote

+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?

! EXIT-EXTENT
Version 6,  8-Jan-89, distributed at Jan89 X3J13
Rereleased 16-Mar-89
Status: tabled Jan89; ready for vote

+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13

+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended

+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988?

+ FLET-IMPLICIT-BLOCK
Version 6 5-JUN-87
Status: Passed, 1988?

+ FORMAT-ATSIGN-COLON
Version 4 5-JUN-87
Status: Passed, 1988?

+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988?

+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988?

+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13

+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988?

* FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: no proposal

+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13

+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988

! FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: ready for vote?

+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89 
Status: Passed (as amended) Jan 89 X3J13
     maybe this was passed as amendment to TEST-NOT-IF-NOT instead

+ FUNCTION-DEFINITION
Version 3, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13

! FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
SETF-FUNCTION-VS-MACRO
 Version 3, 4-Nov-87, Released Nov 87
SETF-PLACES
 Version 1, 11-Nov-88, Released 9-Dec-88
FUNCTION-NAME
 Version 1, 27-Jan-89, Released 16-Mar-89
Status: ready for vote

+ FUNCTION-TYPE
Version 12, 4-SEP-88
Status: Passed, June 1988 X3J13, as amended

+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released  12-Dec-88
Status: Passed, Jan 89 X3J13

+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88 
Status: Passed, 1988

+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13

! GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 1, 14-Feb-89, Released 14-Mar-89
Status: comments
Version 3, 20-Mar-89
Status: vote? 

+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89
Status: Passed (as amended) Jan 89 X3J13

+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988?

! HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88, released 16-Mar-89
status: vote 

+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
 from the generator in  the wrong order.
Status: passed, Jan 89 X3J13

* HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal

! HASH-TABLE-SIZE
Version 1, 20-Mar-89, released 21-Mar-89

+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 88
Status: passed Jan 89 X3J13

+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13

* IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89

+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5 ??-MAY-87
Status: Passed, 1988?

! IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Status: tabled
Version 8, 15-Mar-89, Released 15-Mar-89
Status: ready for vote

+ KEYWORD-ARGUMENT-NAME-PACKAGE
8-NOV-87, Version 8
Status: Passed, 1988?

+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?

+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13

! LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: tabled; version 1 still ready for vote

! LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Comments: Don't like (DEFVAR CAR ...) example
	14: Like simpler "Redefining any documented
  definition on a symbol in the LISP package -- such as variables, 
  functions, constants, properties and property-lists, etc -- is
  undefined, except for the explicitly allowed cases (e.g. dynamic
  binding of variables)."
Status: tabled; version 5 still ready for vote

! LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Comments: How about MAKE-LOAD-FORM-SAVING-SLOTS?
Status: ready for vote w/ name change?

! LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote

! LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: ready to vote

! LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: ready for vote

+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988

* MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: *** NEED PROPOSAL SUBMITTED ****

+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended 

! MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: ready for vote

+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13

+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89
Status: passed, as amended

+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended

+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Comments: Minor glitches? Remove the description of "correctable" error to be signalled and
handled.
Status: passed, Jan 89 X3J13

!+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: Accepted MORE-PERMISSIVE with amendments
Version 3, 17-Mar-89, released 17-Mar-89
Status: vote to accept wording as intent of amendment

* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME;
	require PATHNAME-TYPE to return same?
Version 1, 07-Jul-88
Comments: only add the :TYPE :SOURCE-LISP, not PATHNAME-CANONICAL-TYPE?
Status: => "pathname" committee?

! PATHNAME-COMPONENT-CASE
Version 2, 22-Mar-89, released 22-Mar-89
Status: vote???

! PATHNAME-COMPONENT-VALUE
Version 1, 20-Mar-89, released 21-Mar-89
Status: vote?

* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet

* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous, pro, con. Print like #S(pathname ...)?
Status: *** NEED NEW VERSION ***

+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988?

! PATHNAME-SUBDIRECTORY-LIST
Version 4, 22-Mar-89, released 22-mar-89

+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988?

* PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Version 3, 29-Dec-88
Comments: typos and proposed simplifications
Status: *** NEED NEW VERSION ***

* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88
Comments: various
Status: need new version? ==> ERRORS-IN-FILE-CHAPTERS?

+  PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89
Status: Passed, Jan 89 X3j13, as amended

+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis:  PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13

* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: Need new version

+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?

* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted yet ** NEED WRITEUP **

+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended

! PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: tabled, vote on version 9 (w/o amendments)

+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988?

+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13

+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Comments: use function or keyword?
Status: need new version

* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission

! REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Status: vote?

+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988?

! REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 4, 29-Nov-88, Released 12-Jan-89
Status: straw vote in favor of this, BarMar will make amendments
Version 6, 17-Mar-89
Status: ready for vote?

+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13

+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13

+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released  9-Dec-88
Status: passed, Jan 89 X3J13

+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13

! SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 2, 22-Mar-89, released 22-Mar-89
Status: ready for vote?

+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...) 
Status: passed, Jan 89 X3J13

+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?

+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?

+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13

+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released  7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended

+ STREAM-ACCESS
Version 2, 30-Nov-88, Released  9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13

+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2 
Status: Passed, 1988?

* SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: ** missing writeup ***

+ SUBTYPEP-TOO-VAGUE
Version 4,  7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

+ SYMBOL-MACROLET-DECLARE
Version 2,  9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13

!+ SYMBOL-MACROLET-SEMANTICS
Version 5, 30-Nov-88, Released 9 Dec 88
Status: Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: ready for vote

+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13

+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec 
Version 4, 18-Mar-89
Status: Need new version as amended.

! THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: tabled, vote on 2

! TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote

+* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: constraints wrong
Status: ** NEED NEW VERSION ***

! UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: Lumping SLOT-UNBOUND in with unbound special variables was a mistake,
           as SLOT-UNBOUND is an extension mechanism, not only a safety checking
           mechanism.  Also there were some wording problems.  Gabriel and Gregor
           are to submit a revised proposal.
		No version arrived.
Status: vote on 1?

+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13

+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13

+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88 
Status: Passed, 1988?

! WITH-OPEN-FILE-DOES-NOT-EXIST
Version 1, 17-Mar-89
Status: ready?

∂23-Mar-89  1656	CL-Cleanup-mailer 	Issue: READ-CASE-SENSITIVITY (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89  15:56:54 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 564146; Thu 23-Mar-89 18:56:34 EST
Date: Thu, 23 Mar 89 18:56 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: READ-CASE-SENSITIVITY (Version 2)
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
cc: CL-Cleanup@sail.stanford.edu, KMP@STONY-BROOK.SCRC.Symbolics.COM,
    Masinter.PA@xerox.com, richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
In-Reply-To: <2240.8903232311@subnode.aiai.ed.ac.uk>
Message-ID: <890323185605.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Thu, 23 Mar 89 23:11:13 GMT
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

    It's very late, but here it is.

    Issue:        READ-CASE-SENSITIVITY
    ...

The write-up looks quite good to me.  Even though it's late, I plan to
support it.

I prefer option READTABLE-KEYWORDS for two reasons:
(1) your recent arguments about printer issues being simpler that way
(2) the lack of need to add CHAR-INVERT-CASE (which I don't think is very 
    useful outside of this context).

I do want to mention that I think having an arbitrary function is not as
hard on the printer as you might expect, so I'm not sure READTABLE-FUNCTION
really needs to restrict its inputs.  When the system sees an unknown
function, it could iterate over both-case-p characters, calling the function
and figuring out the mappings. Since we're talking about the system, it will
know which chars those are even in the face of international char sets.
It can determine from such a table whether the mapping is one-to-one for
a particular character (so it will know if escaping is needed) as well as
whether the mapping is case-preserving for any given character.  However,
even though I think this is possible, I admit it is a pain and probably
just plain not worth the effort so I don't think it's the way to go. Based
on this, I don't really oppose READTABLE-FUNCTION, but I'd much prefer the
simpler READTABLE-KEYWORDS proposal anyway.

Btw, there may be some overlap between this and 
PRINT-CASE-PRINT-ESCAPE-INTERACTION. I don't have time to check this to be
sure, but you might want to double-check to avoid last-minute snags.

∂23-Mar-89  1503	CL-Windows-mailer 	Issue STREAM-DEFINITION-BY-USER (V1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Mar 89  09:08:32 PST
Received: by ti.com id AA12307; Wed, 22 Mar 89 21:38:08 CST
Received: from Kelvin by tilde id AA27213; Wed, 22 Mar 89 21:21:09 CST
Message-Id: <2815615116-2334006@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 22 Mar 89  21:18:36 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Cleanup@SAIL.Stanford.edu
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
        Bartley@MIPS.csc.ti.com, Waldrum@Tilde.csc.ti.com, salem@Think.COM
Subject: Issue STREAM-DEFINITION-BY-USER (V1)

Following is a more detailed write-up of the idea of a generic function
I/O interface that allows users to create their own streams.  I have put
this in the format of a cleanup proposal because that seems like a good
way of presenting the information, but I realize that the timing isn't
right for including this in the standard now.  Hopefully, though, this
can be used as a guideline for implementors to avoid unnecessarily
coming up with different names for the same thing, and after some
experience has been gained, this feature could be considered for
inclusion in a revision of the standard.  I wanted to get this in your
hands before the X3J13 meeting in case anyone was interested in
discussing it, but I don't expect any official action to be taken.



Issue:		STREAM-DEFINITION-BY-USER

References:	CLtL pages 329-332, 378-381, and 384-385.

Related issues:	STREAM-INFO, CLOSED-STREAM-FUNCTIONS, STREAM-ACCESS,
		STREAM-CAPABILITIES

Category:	ADDITION

Edit history:	Version 1, 22-Mar-89 by David N. Gray
  
Status:		For discussion and evaluation; not proposed for
		inclusion in the standard at this time.

Problem description:

  Common Lisp does not provide a standard way for users to define their
  own streams for use by the standard I/O functions.  This impedes the
  development of window systems for Common Lisp because, while there are
  standard Common Lisp I/O functions and there are beginning to be
  standard window systems, there is no portable way to connect them
  together to make a portable Common Lisp window system.

  There are also many applications where users might want to define
  their own filter streams for doing things like printer device control,
  report formatting, character code translation, or
  encryption/decryption.

Proposal STREAM-DEFINITION-BY-USER:GENERIC-FUNCTIONS

 Overview:

  Define a set of generic functions for performing I/O.  These functions
  will have methods that specialize on the stream argument; they would
  be used by the existing I/O functions.  Users could write additional
  methods for them in order to support their own stream classes.

  Define a set of classes to be used as the superclass of a stream class
  in order to provide some default methods.

 Classes:

  The following classes are to be used as super classes of user-defined
  stream classes.  They are not intended to be directly instantiated; they
  just provide places to hang default methods.

  FUNDAMENTAL-STREAM				[Class]

    This class is a subclass of STREAM and of STANDARD-OBJECT.  STREAMP
    will return true for an instance of any class that includes this.  (It
    may return true for some other things also.)

  FUNDAMENTAL-INPUT-STREAM			[Class]

    A subclass of FUNDAMENTAL-STREAM.  Its inclusion causes INPUT-STREAM-P
    to return true.

  FUNDAMENTAL-OUTPUT-STREAM			[Class]

    A subclass of FUNDAMENTAL-STREAM.  Its inclusion causes OUTPUT-STREAM-P
    to return true.  Bi-direction streams may be formed by including both
    FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-INPUT-STREAM.

  FUNDAMENTAL-CHARACTER-STREAM			[Class]

    A subclass of FUNDAMENTAL-STREAM.  It provides a method for
    STREAM-ELEMENT-TYPE which returns CHARACTER.

  FUNDAMENTAL-BINARY-STREAM			[Class]
    
    A subclass of FUNDAMENTAL-STREAM.  Any instantiable class that
    includes this needs to define a method for STREAM-ELEMENT-TYPE.

  FUNDAMENTAL-CHARACTER-INPUT-STREAM		[Class]

    Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
    It provides default methods for several generic functions used for
    character input.

  FUNDAMENTAL-CHARACTER-OUTPUT-STREAM		[Class]

    Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
    It provides default methods for several generic functions used for
    character output.

  FUNDAMENTAL-BINARY-INPUT-STREAM		[Class]

    Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.

  FUNDAMENTAL-BINARY-OUTPUT-STREAM		[Class]

    Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.


 Character input:

  A character input stream can be created by defining a class that
  includes FUNDAMENTAL-CHARACTER-INPUT-STREAM and defining methods for the
  generic functions below.

  STREAM-READ-CHAR  stream			[Generic Function]

    This reads one character from the stream.  It returns either a
    character object, or the symbol :EOF if the stream is at end-of-file.
    Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define a
    method for this function.

    Note that for all of these generic functions, the stream argument
    must be a stream object, not T or NIL.

  STREAM-UNREAD-CHAR  stream  character		[Generic Function]

    Un-does the last call to STREAM-READ-CHAR, as in UNREAD-CHAR.  Returns
    NIL.  Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define
    a method for this function.

  STREAM-READ-CHAR-NO-HANG  stream		[Generic Function]

    This is used to implement READ-CHAR-NO-HANG.  It returns either a
    character, or NIL if no input is currently available, or :EOF if
    end-of-file is reached.  The default method provided by
    FUNDAMENTAL-CHARACTER-INPUT-STREAM simply calls STREAM-READ-CHAR; this
    is sufficient for file streams, but interactive streams should define
    their own method.
  
  STREAM-PEEK-CHAR  stream			[Generic Function]

    Used to implement PEEK-CHAR; this corresponds to peek-type of NIL.
    It returns either a character or :EOF.  The default method
    calls STREAM-READ-CHAR and STREAM-UNREAD-CHAR.

  STREAM-LISTEN  stream				[Generic Function]

    Used by LISTEN.  Returns true or false.  The default method uses
    STREAM-READ-CHAR-NO-HANG and STREAM-UNREAD-CHAR.  Most streams should 
    define their own method since it will usually be trivial and will
    always be more efficient than the default method.

  STREAM-READ-LINE  stream			[Generic Function]

    Used by READ-LINE.  A string is returned as the first value.  The
    second value is true if the string was terminated by end-of-file
    instead of the end of a line.  The default method uses repeated
    calls to STREAM-READ-CHAR.

  STREAM-CLEAR-INPUT  stream			[Generic Function]

    Implements CLEAR-INPUT for the stream, returning NIL.  The default
    method does nothing.


 Character output:

  A character output stream can be created by defining a class that
  includes FUNDAMENTAL-CHARACTER-OUTPUT-STREAM and defining methods for the
  generic functions below.

  STREAM-WRITE-CHAR  stream character		[Generic Function]

    Writes character to the stream and returns the character.  Every
    subclass of FUNDAMENTAL-CHARACTER-OUTPUT-STREAM must have a method
    defined for this function.

  STREAM-LINE-COLUMN  stream			[Generic Function]

    This function returns the column number where the next character
    will be written, or NIL if that is not meaningful for this stream.
    The first column on a line is numbered 0.  This function is used in
    the implementation of PPRINT and the FORMAT ~T directive.  For every
    character output stream class that is defined, a method must be
    defined for this function, although it is permissible for it to
    always return NIL.

  STREAM-START-LINE-P  stream			[Generic Function]

    This is a predicate which returns T if the stream is positioned at the
    beginning of a line, else NIL.  It is permissible to always return
    NIL.  This is used in the implementation of FRESH-LINE.  Note that
    while a value of 0 from STREAM-LINE-COLUMN also indicates the
    beginning of a line, there are cases where STREAM-START-LINE-P can be
    meaningfully implemented although STREAM-LINE-COLUMN can't be.  For
    example, for a window using variable-width characters, the column
    number isn't very meaningful, but the beginning of the line does have
    a clear meaning.  The default method for STREAM-START-LINE-P on class
    FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses STREAM-LINE-COLUMN, so if
    that is defined to return NIL, then a method should be provided for
    either STREAM-START-LINE-P or STREAM-FRESH-LINE.

  STREAM-WRITE-STRING stream string &optional start end [Generic Function]

    This is used by WRITE-STRING.  It writes the string to the stream,
    optionally delimited by start and end, which default to 0 and NIL.
    The string argument is returned.  The default method provided by
    FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses repeated calls to
    STREAM-WRITE-CHAR.

  STREAM-TERPRI  stream				[Generic Function]

    Writes an end of line, as for TERPRI.  Returns NIL.  The default
    method does (STREAM-WRITE-CHAR stream #\NEWLINE).

  STREAM-FRESH-LINE  stream			[Generic Function]

    Used by FRESH-LINE.  The default method uses STREAM-START-LINE-P and
    STREAM-TERPRI.

  STREAM-FINISH-OUTPUT  stream			[Generic Function]

    Implements FINISH-OUTPUT.  The default method does nothing.

  STREAM-FORCE-OUTPUT  stream			[Generic Function]

    Implements FORCE-OUTPUT.  The default method does nothing.

  STREAM-CLEAR-OUTPUT  stream			[Generic Function]

    Implements CLEAR-OUTPUT.  The default method does nothing.

  STREAM-ADVANCE-TO-COLUMN  stream column	[Generic Function]

    Writes enough blank space so that the next character will be written
    at the specified column.  Returns true if the operation is
    successful, or NIL if it is not supported for this stream.    
    This is intended for use by by PPRINT and FORMAT ~T.  The default
    method uses STREAM-LINE-COLUMN and repeated calls to
    STREAM-WRITE-CHAR with a #\SPACE character; it returns NIL if
    STREAM-LINE-COLUMN returns NIL.


 Other functions:
 
  CLOSE  stream &key abort			[Generic Function]

    The existing function CLOSE is redefined to be a generic function, but
    otherwise behaves the same.  The default method provided by class
    FUNDAMENTAL-STREAM sets a flag for OPEN-STREAM-P.  The value returned
    by CLOSE will be as specified by the issue CLOSED-STREAM-OPERATIONS.

  OPEN-STREAM-P stream				[Generic Function]

    This function [from proposal STREAM-ACCESS] is made generic.  A
    default method is provided by class FUNDAMENTAL-STREAM which returns
    true if CLOSE has not been called on the stream.

  STREAMP  object				[Generic Function]
  INPUT-STREAM-P  stream			[Generic Function]
  OUTPUT-STREAM-P  stream			[Generic Function]

    These three existing predicates may optionally be implemented as
    generic functions for implementations that want to permit users to
    define streams that are not STANDARD-OBJECTs.  Normally, the default
    methods provided by classes FUNDAMENTAL-INPUT-STREAM and
    FUNDAMENTAL-OUTPUT-STREAM are sufficient.  Note that, for example,
    (INPUT-STREAM-P x) is not equivalent to (TYPEP x
    'FUNDAMENTAL-INPUT-STREAM) because implementations may have
    additional ways of defining their own streams even if they don't
    make that visible by making these predicates generic.

  STREAM-ELEMENT-TYPE  stream			[Generic Function]

    This existing function is made generic, but otherwise behaves the
    same.  Class FUNDAMENTAL-CHARACTER-STREAM provides a default method
    which returns CHARACTER.

  PATHNAME and TRUENAME are also permitted to be implemented as generic
  functions.  There is no default method since these are not valid for
  all streams.


 Binary streams:

    Binary streams can be created by defining a class that includes either
    FUNDAMENTAL-BINARY-INPUT-STREAM or FUNDAMENTAL-BINARY-OUTPUT-STREAM
    (or both) and defining a method for STREAM-ELEMENT-TYPE and for one or
    both of the following generic functions.

  STREAM-READ-BYTE  stream			[Generic Function]

    Used by READ-BYTE; returns either an integer, or the symbol :EOF if the
    stream is at end-of-file.

  STREAM-WRITE-BYTE stream integer		[Generic Function]

    Implements WRITE-BYTE; writes the integer to the stream and returns
    the integer as the result.


Rationale:

  The existing I/O functions cannot be made generic because, in nearly
  every case, the stream argument is optional, and therefore cannot be
  specialized.  Therefore, it is necessary to define a lower-level
  generic function to be used by the existing function.  It also isn't
  appropriate to specialize on the second argument of PRINT-OBJECT because
  it is a higher-level function -- even when the first argument is a
  character or a string, it needs to format it in accordance with
  *PRINT-ESCAPE*.

  In order to make the meaning as obvious as possible, the names of the
  generic functions have been formed by prefixing "STREAM-" to the
  corresponding non-generic function.

  Having the generic input functions just return :EOF at end-of-file, with
  the higher-level functions handling the eof-error-p and eof-value
  arguments, simplifies the generic function interface and makes it more
  efficient by not needing to pass through those arguments.  Note that the
  functions that use this convention can only return a character or
  integer as a stream element, so there is no possibility of ambiguity.

  Functions STREAM-LINE-COLUMN, STREAM-START-LINE-P, and
  STREAM-ADVANCE-TO-COLUMN may appear to be a reincarnation of the
  defeated proposal STREAM-INFO, but the motivation here is different.
  This interface needs to be defined if user-defined streams are to be
  able to be used by PPRINT and FORMAT ~T, which could be viewed as a
  separate question from whether the user can call then on
  system-defined streams.

Current practice:

  No one currently supports exactly this proposal, but this is very
  similar to the stream interface used in CLUE.

  On descendants of the MIT Lisp Machine, streams can be implemented
  by users as either flavors, with methods to accept the various
  messages corresponding to the I/O operations, or as functions, which
  take a message keyword as their first argument.

Examples:

  ;;;; Here is an example of how the default methods could be
  ;;;; implemented (omitting the most trivial ones):

  (defmethod STREAM-PEEK-CHAR ((stream fundamental-character-input-stream))
    (let ((character (stream-read-char stream)))
      (unless (eq character :eof)
	(stream-unread-char stream character))
      character))

  (defmethod STREAM-LISTEN ((stream fundamental-character-input-stream))
    (let ((char (stream-read-char-no-hang stream)))
      (and (not (null char))
	   (not (eq char :eof))
	   (progn (stream-unread-char stream char) t))))

  (defmethod STREAM-READ-LINE ((stream fundamental-character-input-stream))
    (let ((line (make-array 64 :element-type 'string-char 
			    :fill-pointer 0 :adjustable t)))
      (loop (let ((character (stream-read-char stream)))
	      (if (eq character :eof)
		  (return (values line t))
		(if (eql character #\newline)
		    (return (values line nil))
		  (vector-push-extend character line)))))))

  (defmethod STREAM-START-LINE-P ((stream fundamental-character-output-stream))
    (equal (stream-line-column stream) 0))

  (defmethod STREAM-WRITE-STRING ((stream fundamental-character-output-stream)
				  string &optional (start 0) 
				  (end (length string)))
    (do ((i start (1+ i)))
	((>= i end) string)
      (stream-write-char stream (char string i))))

  (defmethod STREAM-TERPRI ((stream fundamental-character-output-stream))
    (stream-write-char stream #\newline)
    nil)

  (defmethod STREAM-FRESH-LINE ((stream fundamental-character-output-stream))
    (if (stream-start-line-p stream)
	nil
      (progn (stream-terpri stream) t)))

  (defmethod STREAM-ADVANCE-TO-COLUMN ((stream fundamental-character-output-stream) 
				       column)
    (let ((current (stream-line-column stream)))
      (unless (null current)
	(dotimes (i (- current column) t)
	  (stream-write-char stream #\space)))))

  (defmethod INPUT-STREAM-P ((stream fundamental-input-stream)) t)
  (defmethod INPUT-STREAM-P ((stream fundamental-output-stream))
    ;; allow the two classes to be mixed in either order
    (typep stream 'fundamental-input-stream))
  (defmethod OUTPUT-STREAM-P ((stream fundamental-output-stream)) t)
  (defmethod OUTPUT-STREAM-P ((stream fundamental-input-stream))
    (typep stream 'fundamental-output-stream))

  ;;;; Following is an example of how the existing I/O functions could
  ;;;; be implemented using standard Common Lisp and the generic
  ;;;; functions specified above.  The standard functions being defined
  ;;;; are in upper case.

  ;;  Internal helper functions

  (proclaim '(inline decode-read-arg decode-print-arg check-for-eof))
  (defun decode-read-arg (arg)
    (cond ((null arg) *standard-input*)
	  ((eq arg t) *terminal-io*)
	  (t arg)))
  
  (defun decode-print-arg (arg)
    (cond ((null arg) *standard-output*)
	  ((eq arg t) *terminal-io*)
	  (t arg)))
  
  (defun check-for-eof (value stream eof-errorp eof-value)
    (if (eq value :eof)
	(report-eof stream eof-errorp eof-value)
      value))
  
  (defun report-eof (stream eof-errorp eof-value)
    (if eof-errorp
	(error 'end-of-file :stream stream)
      eof-value))
  
  ;;;  Common Lisp input functions
  
  (defun READ-CHAR (&optional input-stream (eof-errorp t) eof-value recursive-p)
    (declare (ignore recursive-p)) ; a mistake in CLtL?
    (let ((stream (decode-read-arg input-stream)))
      (check-for-eof (stream-read-char stream) stream eof-errorp eof-value)))
  
  (defun PEEK-CHAR (&optional peek-type input-stream (eof-errorp t) 
			eof-value recursive-p)
    (declare (ignore recursive-p))
    (let ((stream (decode-read-arg input-stream)))
      (if (null peek-type)
	  (check-for-eof (stream-peek-char stream) stream eof-errorp eof-value)
        (loop
	  (let ((value (stream-peek-char stream)))
	    (if (eq value :eof)
		(return (report-eof stream eof-errorp eof-value))
	      (if (if (eq peek-type t)
		      (not (member value '(#\space #\tab #\newline
					   #\page #\return #\linefeed)))
		    (char= peek-type value))
		  (return value)
		(stream-read-char stream))))))))
  
  (defun UNREAD-CHAR (character &optional input-stream)
    (stream-unread-char (decode-read-arg input-stream) character))
  
  (defun LISTEN (&optional input-stream)
    (stream-listen (decode-read-arg input-stream)))
  
  (defun READ-LINE (&optional input-stream (eof-error-p t) 
			eof-value recursive-p)
    (declare (ignore recursive-p))
    (let ((stream (decode-read-arg input-stream)))
      (multiple-value-bind (string eofp)
	  (stream-read-line stream)
	(if eofp
	    (if (= (length string) 0)
		(report-eof stream eof-error-p eof-value)
	      (values string t))
	  (values string nil)))))
  
  (defun CLEAR-INPUT (&optional input-stream)
    (stream-clear-input (decode-read-arg input-stream)))
  
  (defun READ-CHAR-NO-HANG (&optional input-stream (eof-errorp t) 
				eof-value recursive-p)
    (declare (ignore recursive-p))
    (let ((stream (decode-read-arg input-stream)))
      (check-for-eof (stream-read-char-no-hang stream)
		     stream eof-errorp eof-value)))
  
  ;;;  Common Lisp output functions
  
  (defun WRITE-CHAR (character &optional output-stream)
     (stream-write-char (decode-print-arg output-stream) character))
  
  (defun FRESH-LINE (&optional output-stream)
    (stream-fresh-line (decode-print-arg output-stream)))
  
  (defun TERPRI (&optional output-stream)
    (stream-terpri (decode-print-arg output-stream)))
  
  (defun WRITE-STRING (string &optional output-stream &key (start 0) end)
    (stream-write-string (decode-print-arg output-stream) string start end))
  
  (defun WRITE-LINE (string &optional output-stream &key (start 0) end)
    (let ((stream (decode-print-arg output-stream)))
      (stream-write-string stream string start end)
      (stream-terpri stream)
      string))
  
  (defun FORCE-OUTPUT (&optional stream)
    (stream-force-output (decode-print-arg stream)))
  
  (defun FINISH-OUTPUT (&optional stream)
    (stream-finish-output (decode-print-arg stream)))
  
  (defun CLEAR-OUTPUT (&optional stream)
    (stream-clear-output (decode-print-arg stream)))
  
  ;;;  Binary streams

  (defun READ-BYTE (binary-input-stream &optional (eof-errorp t) eof-value)
    (check-for-eof (stream-read-byte binary-input-stream) 
		   binary-input-stream eof-errorp eof-value))
  
  (defun WRITE-BYTE (integer binary-output-stream)
    (stream-write-byte binary-output-stream integer))

  ;;;  String streams
  
  (defclass string-input-stream (fundamental-character-input-stream)
    ((string :initarg :string :type string)
     (index :initarg :start :type fixnum)
     (end :initarg :end :type fixnum)
     ))
  
  (defun MAKE-STRING-INPUT-STREAM (string &optional (start 0) end)
    (make-instance 'string-input-stream :string string 
		   :start start :end (or end (length string))))
  
  (defmethod stream-read-char ((stream string-input-stream))
    (with-slots (index end string) stream
      (if (>= index end)
	  :eof
	(prog1 (char string index)
	       (incf index)))))
  
  (defmethod stream-unread-char ((stream string-input-stream) character)
    (with-slots (index end string) stream
      (decf index)
      (assert (eql (char string index) character))
      nil))
  
  (defmethod stream-read-line ((stream string-input-stream))
    (with-slots (index end string) stream
      (let* ((endline (position #\newline string :start index :end end))
	     (line (subseq string index endline)))
	(if endline
	    (progn (setq index (1+ endline))
		   (values line nil))
	  (progn (setq index end)
		 (values line t))))))
  
  (defclass string-output-stream (fundamental-character-output-stream)
    ((string :initform nil :initarg :string)))

  (defun MAKE-STRING-OUTPUT-STREAM ()
    (make-instance 'string-output-stream))

  (defun GET-OUTPUT-STREAM-STRING (stream)
    (with-slots (string) stream
      (if (null string)
	  ""
	(prog1 string (setq string nil)))))
  
  (defmethod stream-write-char ((stream string-output-stream) character)
    (with-slots (string) stream
      (when (null string)
	(setq string (make-array 64. :element-type 'string-char 
				 :fill-pointer 0 :adjustable t)))
      (vector-push-extend character string)
      character))
  
  (defmethod stream-line-column ((stream string-output-stream))
    (with-slots (string) stream
      (if (null string)
	  0
	(let ((nx (position #\newline string :from-end t)))
	  (if (null nx)
	      (length string)
	    (- (length string) nx 1))
	  ))))

Cost to Implementors:

  Given that CLOS is supported, adding the above generic functions and
  methods is easy, since most of the code is included in the examples
  above.  The hard part would be re-writing existing I/O functionality in
  terms of methods on these new generic functions.  That could be
  simplified if methods can be defined to forward the operations to the
  old representation of streams.  For a new implementation, the cost could
  be zero since an approach similar to this would likely be used anyway.

Cost to Users:

  None; this is an upward-compatible addition.   Users won't even
  need to know anything about this unless they actually need this feature.

Cost of non-adoption:

  Development of portable I/O extensions will be discouraged.

Performance impact:

  This shouldn't affect performance of new implementations (assuming an
  efficient CLOS implementation), but it could slow down I/O if it were
  clumsily grafted on top of an existing implementation.

Benefits:

  A broader domain of programs that can be written portably.

Esthetics:

  This seems to be a simple, straight-forward approach.

Discussion:

  This proposal incorporates suggestions made by several people in
  response to an earlier outline.  So far, no one has expressed opposition
  to the concept.  There are some differences of opinion about whether
  certain operations should have default methods or required methods:
  STREAM-LISTEN, STREAM-READ-CHAR-NO-HANG, STREAM-LINE-COLUMN,
  and STREAM-START-LINE-P.

  An experimental prototype of this has been successfully implemented on
  the Explorer.

  This proposal does not provide sufficient capability to implement
  forwarding streams such as for MAKE-SYNONYM-STREAM,
  MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-TWO-WAY-STREAM, or
  MAKE-ECHO-STREAM.  The generic function approach does not lend itself as
  well to that as a message passing model where the intermediary does not
  need to know what all the possible messages are.  A possible way of
  extending it for that would be to define a class 

    (defclass stream-generic-function (standard-generic-function) ())

  to be used as the :generic-function-class option for all of the I/O
  generic functions.  This would then permit doing something like

  (defmethod no-applicable-method ((gfun stream-generic-function) &rest args) 
    (if (streamp (first args))
	(apply #'stream-operation-not-handled (first args) gfun (rest args))
      (call-next-method)))

  where stream-operation-not-handled is a generic function whose default
  method signals an error, but forwarding streams can define methods that
  will create a method to handle the unexpected operation.  (Perhaps
  NO-APPLICABLE-METHOD should be changed to take two required arguments
  since all generic functions need at least one required argument, and
  that would make it unnecessary to define a new generic function class
  just to be able to write this one method.)

  Another thing that is not addressed here is a way to cause an instance
  of a user-defined stream class to be created from a call to the OPEN
  function.  That should be part of a separate issue for generic functions
  on pathnames.  If that capability were available, then PATHNAME and
  TRUENAME should be required to be generic functions.

  An earlier draft defined just two classes, FUNDAMENTAL-INPUT-STREAM and
  FUNDAMENTAL-OUTPUT-STREAM, that were used for both character and binary
  streams.  It isn't clear whether that simple approach is sufficient or
  whether the larger set of classes is really needed.

∂23-Mar-89  1813	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 2)  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89  18:13:26 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA08865; Thu, 23 Mar 89 18:15:31 PST
Received: from denali.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA14491; Thu, 23 Mar 89 18:11:37 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
	id AA04765; Thu, 23 Mar 89 18:14:55 PST
Message-Id: <8903240214.AA04765@denali.sun.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2) 
In-Reply-To: Your message of Thu, 23 Mar 89 18:56:00 -0500;
	<890323185605.7.KMP@BOBOLINK.SCRC.Symbolics.COM> .
Date: Thu, 23 Mar 89 18:14:53 PST
From: peck@Sun.COM

>(2) the lack of need to add CHAR-INVERT-CASE (which I don't think is very 
>    useful outside of this context).
 I guess i don't see how this is useful even in this context.
Is this a Symbolics'ism?
If :preserve is an option, why would someone want :INVERT?
dOES SOMEONE THINK :invert IS EASIER TO TYPE THAN eSCAPES or vERTICAL-bARS?
dO YOU HAVE files WRITTEN WITH :invert?

How about throwing out :INVERT *and* CHAR-INVERT-CASE?
Which of READTABLE-KEYWORDS or READTABLE-FUNCTIONS would you prefer then?

  [given a sufficiently powerful Emacs that can escape the chars before
   passing them to the Lisp reader, does any of this matter to X3J13?]

  While we are busy trying to be KSR33 compatible, the rest of the world
  may zoom on by.  The Japanese won't be interested in much of this code.
  Oops, sorry, that is not a cleanup issue.

∂23-Mar-89  1518	CL-Cleanup-mailer 	Issue: DIRECTORY-DOES-TOO-MUCH 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Mar 89  15:13:59 PST
Received: from pitney-bowes ([192.9.200.50]) by heavens-gate.lucid.com id AA03822g; Thu, 23 Mar 89 15:08:24 PST
Received: by pitney-bowes id AA26773g; Thu, 23 Mar 89 15:06:47 PST
Date: Thu, 23 Mar 89 15:06:47 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8903232306.AA26773@pitney-bowes>
To: CL-Cleanup@SAIL.Stanford.edu
Subject: Issue: DIRECTORY-DOES-TOO-MUCH

While thinking about pathnames, I was reminded of this possible small
addition:

Issue:          DIRECTORY-DOES-TOO-MUCH
Forum:	        Cleanup
References:     DIRECTORY (p427)
Related issues: NONE
Category:       ADDITION
Edit history:   14-Mar-89, Version 1 by James L. McDonald
Status:         For Internal Discussion

Problem description:

  According to CLtL, DIRECTORY returns a list of truenames, "one for
  each file in the file system that matches the given pathname".

  The problem is that sometimes one wants the truenames for just one
  or a few of the files that match, or one wants to interleave
  processing of each file as it is found, to minimize the start-up
  time when processing large directories. 

Proposal (DIRECTORY-DOES-TOO-MUCH:ADD-GENERATOR):

  Add the function DIRECTORY-GENERATOR which would accept the same
  argument spectrum as DIRECTORY and return a function which, when
  successively applied, would yield each of truenames in the list
  of truenames that DIRECTORY would have returned, and then NIL to
  indicate no more files are available. 

Examples:

  This example illustrates how wasted effort could be avoided:

  (DEFUN FIND-DEFINING-FILE (MUMBLE)
    (LET ((FN (DIRECTORY-GENERATOR "/moby-dir/*.lisp")))
      (DO ((TRUENAME (FUNCALL FN) (FUNCALL FN)))
          ((NULL TRUENAME)
           NIL)
        (WHEN (FILE-DEFINES-P TRUENAME MUMBLE)
          (RETURN TRUENAME)))))

  This example shows how a system with some distributed processing 
  ability might interleave file accessing and processing:

  (DEFUN COMPILE-WORLD ()
    (LET ((FN (DIRECTORY-GENERATOR "/moby-dir/*.lisp")))
      (DO ((TRUENAME (FUNCALL FN) (FUNCALL FN)))
          ((NULL TRUENAME)
           NIL)
        (INITIATE-DISTRIBUTED-COMPILATION TRUENAME))))

Test Cases:

  This should return true for all arguments, assuming that during
  the execution of the test files are not added to or removed from
  the file-system being accessed.

  (DEFUN FOO (X)
    (OR (NOT (PATHNAMEP X))
        (NULL (SET-EXCLUSIVE-OR ; why doesn't CL have SET-EQUAL ?
                 (DIRECTORY X)
                 (LET ((FN (DIRECTORY-GENERATOR X))
         	       (DIR '()))
                   (DO ((TRUENAME (FUNCALL FN) (FUNCALL FN)))
                       ((NULL TRUENAME)
			(REVERSE DIR))
                     (PUSH TRUENAME DIR)))))))

Rationale:

  This seems simple, useful, and uncontroversial.  For many file 
  systems, it provides a CL primitive that maps more directly to
  underlying OS primitives.  

Current practice:

  Lucid Common Lisp has always implemented DIRECTORY in much this way.

Cost to Implementors:

  Minimal.  Any port could come into compliance by defining
  DIRECTORY-GENERATOR as:

  (DEFUN DIRECTORY-GENERATOR (X)
    (LET ((DIR (DIRECTORY X)))
      #'(LAMBDA () (POP DIR))))

  Implementing it more directly is probably either a fairly small task
  or clearly impossible.  Either way, not much work.

Cost to Users:

  None.

Cost of non-adoption:

  DIRECTORY continues to be needlessly inefficient in some cases.

Performance impact:

  Some programs may run faster or reduce the maximum delay visible
  to users. 

Benefits:

  See performance impact.

Esthetics:

  Minor.

Discussion:

  The test case presumes truenames are generated in the same order
  that DIRECTORY now lists them.  This is a minor restriction but
  would fail for systems that explicitly sort their results or file
  systems that randomly reorder directories (e.g. on every access).
  Set equivalence is probably just as good a test if anyone cares.  

∂23-Mar-89  1534	CL-Cleanup-mailer 	Re: Issue: GENSYM-NAME-STICKINESS (Version 3) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89  15:32:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 89 12:59:59 PST
Date: 23 Mar 89 12:59 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: GENSYM-NAME-STICKINESS (Version 3)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Tue, 21 Mar 89 11:45 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890323-125959-5425@Xerox>

please release to X3J13; thanks.

∂23-Mar-89  2050	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 2)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89  20:50:36 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 564301; Thu 23-Mar-89 23:49:43 EST
Date: Thu, 23 Mar 89 23:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2) 
To: peck@Sun.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
    jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK,
    CL-Cleanup@sail.stanford.edu
In-Reply-To: <8903240214.AA04765@denali.sun.com>
Message-ID: <890323234914.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

I shouldn't even be bothering to reply to a message like this at this late
date.  I have better things to be doing.  However, I'll let this be my one
for the day -- if only to lend a little support to Jeff because I think
the tone of ridicule in your message to be somewhat out of line. In spite
of this, I've tried to keep my tone constructive and to answer your questions
in earnest.

    Date: Thu, 23 Mar 89 18:14:53 PST
    From: peck@Sun.COM

    >(2) the lack of need to add CHAR-INVERT-CASE (which I don't think is very 
    >    useful outside of this context).
     I guess i don't see how this is useful even in this context.
    Is this a Symbolics'ism?

I didn't find this remark to be particularly professional. I wish we could
just avoid that kind of thing.

The answer happens to be "no", it is not something we use here.
It's something Jeff dreamed up, I guess.

I didn't oppose it because I'm not in the habit of out-of-hand opposing
things just because I personally don't see as having practical value. I
think the real acid test of willingness to cooperate on compatibility is
a willingness to tolerate noops and useless features because they turn
out to be useful to someone else.

My offhand guess is that it is in fact useful in some implementations.
Your example below which uses mixed case doesn't give it fair play.
Suppose there's an intermediate situation where you implement an embedded
language in which you can only use all-uppercase or all-lowercase names.
Suppose you want the all-lowercase names to be the ones that correspond to
Lisp names. I don't happen to want to do that, but it seemed plausible to
me that someone might -- and it might be what Jeff had in mind.

The cost of the feature he's asking for is very small, especially if you
consider the hair someone would have to go through to write that embedded
language portably if you didn't offer the feature.

    If :preserve is an option, why would someone want :INVERT?
    dOES SOMEONE THINK :invert IS EASIER TO TYPE THAN eSCAPES or vERTICAL-bARS?
    dO YOU HAVE files WRITTEN WITH :invert?

    How about throwing out :INVERT *and* CHAR-INVERT-CASE?

How about being civil and first asking Jeff politely why he wanted the feature.

    Which of READTABLE-KEYWORDS or READTABLE-FUNCTIONS would you prefer then?

It doesn't affect my vote. I still prefer the former over the latter, and I
still don't seriously oppose the latter.

      [given a sufficiently powerful Emacs that can escape the chars before
       passing them to the Lisp reader, does any of this matter to X3J13?]

The issue is not text editors. Given a sufficiently powerful Emacs, you could
code in C and still pass your information off to Lisp.  ``It's only software''
as they say. The issue is that the language must be defined as the interface
between the outside world and Lisp. The language is exactly what you can expect
to be held constant as you move from system to system, text editor to text editor.
Either the language handles case conversion or the text editor does.
Jeff is suggesting that he would like the text editor to do so. I don't happen
to want to do that, but I can't deny that he is making a fair request.

      While we are busy trying to be KSR33 compatible, the rest of the world
      may zoom on by. 

I have never used a KSR33. I think I've seen one. I have no particular desire
to be compatible with one. I can't imagine why this remark is relevant here.

      The Japanese won't be interested in much of this code.
      Oops, sorry, that is not a cleanup issue.

In my mind, it is not our purpose to design a language suitable for the Japanese.
It is our purpose to design a language suitable for us, and to try to listen
to the Japanese (and anyone else) about problems what we do might cause. While
this feature might not be interesting to them, it's hard to see how it could 
cause them any problem.

The Japanese will have their opportunity to speak, and I will pay close attention.

If you say what you personally want and why, sans ridicule, I will try to pay
close attention to that, too.

∂23-Mar-89  2232	CL-Cleanup-mailer 	Issue: DIRECTORY-DOES-TOO-MUCH 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89  22:32:44 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 564358; Fri 24-Mar-89 01:32:03 EST
Date: Fri, 24 Mar 89 01:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DIRECTORY-DOES-TOO-MUCH
To: jlm@lucid.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8903232306.AA26773@pitney-bowes>
Message-ID: <890324013136.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

I don't oppose your proposal, but I have some non-preemptive remarks
that you might want to consider factoring into a revision if you have
time to pursue the issue. (I really don't know how much I believe these
suggestions, but they occurred to me and I thought I would share them.)

Criticisms:

 - I think the name DIRECTORY-GENERATOR is a bit long
   and not startlingly perspicuous.

 - I think that returning a function means that some common
   cases will seem unduly complicated because of the need to
   FUNCALL the result to turn it into a useable form.

These are not fatal flaws, but they drive the following suggestions:

You might want an interface like

 (DIRECTORY-1 pathname) => pathname-or-nil, function-or-nil

[Actually, it's clear that first return value has to be NIL.
 The second return value doesn't have to be NIL -- it could be
 a function which returns NIL when called, but people might want
 to optimize that case.]

The name is by analogy with MACROEXPAND-1. You'd get a useful 
primary value and some more-p information in the secondary value
that you could discard if you didn't want.

The really nice feature of the data flow is, of course, that you can
directly use the single return value without further fuss or funcall.

You might even want to allow it to taken an optional argument saying
you didn't want the second return value (i.e., that NIL was ok) to
avoid consing.

 (DIRECTORY-1 pathname NIL) => pathname-or-nil, nil

Alternatively, or additionally, you might want to think about
extending DIRECTORY to take a keyword requesting the indicated
functionality. e.g.,
  (DIRECTORY pathname :COUNT 1)
might want to return just the first pathname, presumably as a list
to be compatible with the normal style of DIRECTORY, and to generalize
nicely to :COUNT arguments like 0 or 2.
If this were an alternative to DIRECTORY-1, it could also return a
second return value which was the stepper function (or NIL if none).
If this were just in addition to DIRECTORY-1, then it could arguably
not bother with the second return value and make you call DIRECTORY-1
if you needed that much power.

∂24-Mar-89  0745	CL-Cleanup-mailer 	Re: Issue: DIRECTORY-DOES-TOO-MUCH  
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 24 Mar 89  07:44:59 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa08010; 24 Mar 89 10:29 EST
Received: from draper.com by RELAY.CS.NET id aa00637; 24 Mar 89 10:25 EST
Date: Fri, 24 Mar 89 09:17 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: DIRECTORY-DOES-TOO-MUCH
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525

> Date: Fri, 24 Mar 89 01:31 EST
> From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.COM>
> Subject: Issue: DIRECTORY-DOES-TOO-MUCH
> To: jlm@lucid.COM
>
> You might want an interface like
>
>  (DIRECTORY-1 pathname) => pathname-or-nil, function-or-nil
>
> [Actually, it's clear that first return value has to be NIL.
>  The second return value doesn't have to be NIL -- it could be
>  a function which returns NIL when called, but people might want
>  to optimize that case.]
>
[...]
>
> You might even want to allow it to taken an optional argument saying
> you didn't want the second return value (i.e., that NIL was ok) to
> avoid consing.
>
>  (DIRECTORY-1 pathname NIL) => pathname-or-nil, nil

Now that's a slippery slope.  If we start allowing functions to take an
optional argument telling them how many values {not} to return, where do
we stop?  In any case, it's the job of the compiler and its many optimizers,
in most cases, to determine when and if it is possible/feasible/desirable to
generate code that avoids returning unused values.  
 
Plus, which is more painful - a few extra conses, or the directory lookup
in the first place?  (Answer: implementation-dependent.)


∂24-Mar-89  0807	CL-Cleanup-mailer 	Meeting 1 hour before plenary session?   
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 24 Mar 89  08:07:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 325694; Fri 24-Mar-89 11:06:59 EST
Date: Fri, 24 Mar 89 11:07 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Meeting 1 hour before plenary session?
To: masinter.pa@XEROX.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <890323-122134-5313@Xerox>
Message-ID: <19890324160717.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 23 Mar 89 12:19 PST
    From: masinter.pa@Xerox.COM

    I'm back near a mailbox. Can we get together an hour before the main
    session to go over the cleanup report agenda? I want to order the cleanup
    issues so that we handle the "important" ones first. I roughly think that
    means:

    a) fix the cleanups that were previously broken

    b) clarifications

    c) changes

    c) additions

    within each category, order mainly by age: handle oldest issues first. But
    then, there are some of these that are more 'important' that we'll want to
    mess up the order. 

This sounds good.  Also we may want to move related issues next to each
other (although the pathname issues will be next to each other in alphabetical
order).

    I plan to put together a proposal for dealing with these over the next few
    days and will mail it out, but you might want to come prepared with your
    own list of "things that are critically important to get voted on this
    meeting".

It's too late to mail any more things out, at least for me.  I hope not to
work this weekend.

∂24-Mar-89  1015	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 2)  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 24 Mar 89  10:14:11 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa03563; 24 Mar 89 16:30 GMT
Date: Fri, 24 Mar 89 16:32:37 GMT
Message-Id: <3273.8903241632@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2) 
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, peck@sun.com
Cc: CL-Cleanup@sail.stanford.edu

> How about throwing out :INVERT *and* CHAR-INVERT-CASE?
> Which of READTABLE-KEYWORDS or READTABLE-FUNCTIONS would you prefer then?

Probably FUNCTIONS.  But then for a random function (e.g., a
CHAR-INVERT-CASE defined by me), I'd want output to leave case
intact, without escapes.

-- Jeff

∂24-Mar-89  1024	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 2)  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 24 Mar 89  10:24:32 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa03359; 24 Mar 89 15:59 GMT
Date: Fri, 24 Mar 89 16:01:12 GMT
Message-Id: <2935.8903241601@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2) 
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, peck@sun.com
Cc: CL-Cleanup@sail.stanford.edu

I do not understand why this proposal causes such confusion.  Perhaps
my writing isn't as clear as it might be, but I don't think it's that
bad.

> >(2) the lack of need to add CHAR-INVERT-CASE (which I don't think is very 
> >    useful outside of this context).
>  I guess i don't see how this is useful even in this context.
> Is this a Symbolics'ism?

No.

> If :preserve is an option, why would someone want :INVERT?

It's in the rationale.  If I set the readtable to :PRESERVE and
then want to use it to keep case distinctions in my Lisp code --
some people do want to do this -- I may also want to type the names
of symbols in the "LISP" package in lower case rather than upper.
There are two ways to get that: change the internal case to lower
or invert what's typed in.

> dOES SOMEONE THINK :invert IS EASIER TO TYPE THAN eSCAPES or vERTICAL-bARS?
> dO YOU HAVE files WRITTEN WITH :invert?

No, someone thinks (car x) is nicer than (CAR x).

One may well have files written in :INVERT.  Any file that uses only
lower case for Lisp code relies on case-insensitivity to convert the
names to upper case.  Those same files could just as well be read
with :INVERT.

>   [given a sufficiently powerful Emacs that can escape the chars before
>    passing them to the Lisp reader, does any of this matter to X3J13?]

Given sufficiently powerful tools other than Lisp, why does anything
matter to X3J13?

Besides, is Emacs going to read all of my streams for me?

>   While we are busy trying to be KSR33 compatible, the rest of the world
>   may zoom on by.  The Japanese won't be interested in much of this code.
>   Oops, sorry, that is not a cleanup issue.

The only thing in any of this that's could reasonably be called KSR33
compatible is the choice of upper case for the internal preferred
case.  This proposal is trying to make that choice less significant.

-- Jeff

∂24-Mar-89  1344	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 2)  
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 24 Mar 89  13:44:38 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
	id AA00368; Fri, 24 Mar 89 13:46:08 PST
Received: from denali.sun.com by snail.Sun.COM (4.1/SMI-4.1)
	id AA19874; Fri, 24 Mar 89 13:42:14 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
	id AA07858; Fri, 24 Mar 89 13:45:29 PST
Message-Id: <8903242145.AA07858@denali.sun.com>
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2) 
In-Reply-To: Your message of Fri, 24 Mar 89 16:01:12 +0000;
	<2935.8903241601@subnode.aiai.ed.ac.uk> .
Date: Fri, 24 Mar 89 13:45:27 PST
From: peck@Sun.COM

Assuming that my confusion about :invert is resolved offline,
I have another, more positive suggestion for getting CommonLisp
into the case-sensitive world:

 The biggest block that i've found to writting portable code
in the mixed/preserve case world is those times when you want
intern a symbol from a string.  If the string is either hard-coded
(as a prefix string or :conc-name) or as entered from a user with
a readline equivalent, then the application should have a means
of converting the string as the reader would.  I have found use
for the function (CASE-CONVERT-NAME <string>) which returns a 
string which would be the name of a symbol if <string> were read
by the reader.

;;; This definition returns mostly the correct value,
;;; but has numerous unwanted side-effects, 
;;; I.E. creates and interns a symbol, chokes on by colons, etc.
  (defun CASE-CONVERT-NAME (string)
    (symbol-name (read-from-string string)))

;;; this is much closer, with READTABLE-CASE-SENSITIVITY:READTABLE-KEYWORDS
  (defun CASE-CONVERT-NAME (string)
    (case (readtable-case-sensitivity *readtable*)
      (:preserve string)
      (:upcase  (string-upcase string))
      (:downcase (string-downcase string))
      (:invert  (string-invertcase string)) ;; uses char-invert-case?
    ))

;;; or this, with READTABLE-CASE-SENSITIVITY:READTABLE-FUNCTIONS
   (defun CASE-CONVERT-NAME (string)
      (map 'string (readtable-case-sensitivity *readtable*) string))

If we could have a function such as this in the, maybe folks
would use it: (intern (concatentate 'string
			(case-convert-name "foo-")
			(case-convert-name sym) )
		     pkg)
Instead of: (intern (concatentate 'string "FOO-" sym) pkg)

With this extra layer, writing protable code to case-sensitive lisp 
is very much easier.  The version i use even has an extra arguement
to control whether destructive (in-place) or copying conversion is done.

∂25-Mar-89  1209	CL-Cleanup-mailer 	Cleanup Meeting 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Mar 89  12:09:47 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 565298; Sat 25-Mar-89 15:09:31 EST
Date: Sat, 25 Mar 89 15:09 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Cleanup Meeting
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890325150902.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

Larry asked me to send mail clarifying that the Cleanup meeting will
be Tuesday morning at 8am at Contel, with full X3J13 to meet at 9am.
Probably all we'll have time to do at the early Cleanup meeting is
discuss strategy/priority for presentation--not discuss individual 
issues.

∂29-Mar-89  1535	CL-Cleanup-mailer 	new version of LOAD-TRUENAME   
Received: from ctc.contel.com (goofy.ctc.contel.com) by SAIL.Stanford.EDU with TCP; 29 Mar 89  15:35:10 PST
Received: from mickey.ctc.contel.com by ctc.contel.com (4.0/870914.1{Enger})
	id AA11354; Wed, 29 Mar 89 18:35:27 EST
Received: by mickey.ctc.contel.com (4.0/SMI-4.0)
	id AA01906; Wed, 29 Mar 89 18:36:33 EST
Date: Wed, 29 Mar 89 18:36:33 EST
From: mathis@mickey.ctc.contel.com (Bob Mathis)
Message-Id: <8903292336.AA01906@mickey.ctc.contel.com>
To: mathis@mickey.ctc.contel.com
Subject: new version of LOAD-TRUENAME
Cc: cl-cleanup@sail.stanford.edu

(composed by Moon w/editing by Masinter in Mathis office)
Issue:        LOAD-TRUENAME
Forum:	      Cleanup
References:   LOAD (p426), PROVIDE (p188), REQUIRE (p188),
	      Issue REQUIRE-PATHNAME-DEFAULTS
Category:     ADDITION
Edit history: 13-Mar-89, Version 1 by Pitman
	      29-Mar-89, Version 2 by Moon (add -PATHNAME vars)

Problem Description:

 It is difficult to construct sets of software modules which work
 together as a unit and which port between different implementations.

 REQUIRE and PROVIDE were intended to provide this level of support
 but have `failed' to be portable in practice.

 Typical user configurations involve a `system definition' file which
 loads the modules of a `system' (collection of software modules).

 Among the specific problems which arise are:

  - File system types may vary. Different file syntax must be used for
    each site.

  - Even with the same Lisp implementation and host file system type,
    the directory in which a software system resides may differ from
    delivery site to delivery site.

  - Multiple `copies' of the same system may reside in different
    directories on the same machine.

Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):

 Introduce new variables:

   *LOAD-TRUENAME*					[Variable]

   This special variable is initially NIL, but is bound by LOAD to
   hold the truename of the pathname of the file being loaded.

   *COMPILE-FILE-TRUENAME*				[Variable]

   This special variable is initially NIL, but is bound by 
   COMPILE-FILE to hold the truename of the pathname of the file
   being compiled.
    
  *LOAD-PATHNAME*					[Variable]

   This special variable is initially NIL, but is bound by LOAD to
   hold the pathname of the file being loaded.

   *COMPILE-FILE-PATHNAME*				[Variable]

   This special variable is initially NIL, but is bound by 
   COMPILE-FILE to hold the pathname of the file being compiled.

Example:

 ------ File SETUP ------
 (IN-PACKAGE 'MY-STUFF)
 (DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
 (DEFVAR *SOURCE-FILE* (COMPILE-TRUENAME) "Just for debugging.")
 (DEFVAR *LOADED-FILE* *LOAD-TRUENAME*)
 (DEFUN LOAD-MY-SYSTEM ()
   (DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
     (LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-TRUENAME*))))
 ------------------------

 (LOAD "SETUP")
 (LOAD-MY-SYSTEM)

Rationale:

 This satisfies the most common instances of the frequently reported
 problem in the Problem Description.

Current Practice:

 Wide variation.

 In some implementations, calling LOAD binds or sets 
 *DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
 LOADed will default to being `nearby.'

 Some implementations provide special variables that are similar or
 identical to one or both of those proposed.

 Some implementations have a way to represent the pathname for the
 current working directory, and make the default pathname default
 to that, so that loading without specifying a default again tends to
 get `nearby' files.

 None of these techniques is portable, unfortunately, because there
 is no agreement.

Cost to Implementors:

 Very small.

Cost to Users:

 None. This change is upward compatible.

Cost of Non-Adoption:

 Continued difficulty for anyone trying to put a system of modules
 in a form where they can be conveniently delivered using portable code.

Benefits:

 The cost of non-adoption is avoided.

Aesthetics:

 Negligible.

Discussion:

 Touretzky raised the issue most recently on Common-Lisp. A number
 of people immediately jumped on the bandwagon, indicating it was
 important to them, too.

 Pitman made three suggestions in response, of which the above is
 the first. The others included:
  2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
     lists of the truenames of all files being loaded or compiled,
     respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
 
  3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
    ((LOAD truename) (COMPILE-FILE truename) ...)
    during the dynamic invocation of LOAD and COMPILE-FILE.
 
 Touretzky responded:
 ``I like KMP's proposals.  I like the second one best: have separate
   variables for files being loaded and files being compiled, and use
   them to maintain a stack so we can see the nesting of loads within
   files.''

 Pitman ultimately chose to present the first rather than the second
 because it seemed simpler, easier to explain, and more likely to
 pass at this late date.


!
Additional Comments:


"I favor LOAD-TRUENAME:NEW-PATHNAME-VARIABLES.  I think this
proposal would be greatly improved by adding two more variables,
*LOAD-PATHNAME* and *COMPILE-FILE-PATHNAME*, whose values are
the pathname opened by LOAD or COMPILE-FILE, rather than the
truename.  The need for these is more obvious if you think
about systems where the pathname cannot be easily reconstructed
from the truename.  This includes file systems with symbolic
links and some pathname systems with logical pathnames."


"I favor this.  I would even favor either of the other two ideas even at
this `late date'.  The behavior of each of the proposals is simple, its
easy to see what it will and won't do, and it satisfies a real demand.

I should note that I have never wanted the incremented functionally
offered by the `stack' proposals, but I could still vote for them."

∂29-Mar-89  1550	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND, v.3 
Received: from ctc.contel.com (goofy.ctc.contel.com) by SAIL.Stanford.EDU with TCP; 29 Mar 89  15:50:01 PST
Received: from mickey.ctc.contel.com by ctc.contel.com (4.0/870914.1{Enger})
	id AA11389; Wed, 29 Mar 89 18:50:08 EST
Received: by mickey.ctc.contel.com (4.0/SMI-4.0)
	id AA01917; Wed, 29 Mar 89 18:51:15 EST
Date: Wed, 29 Mar 89 18:51:15 EST
Message-Id: <8903292351.AA01917@mickey.ctc.contel.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DESTRUCTURING-BIND, v.3
From: moon@symbolics.com

Issue:        DESTRUCTURING-BIND
Forum:	      Cleanup
References:   DEFMACRO (CLtL pp145-151),
	      The LOOP Facility (X3J13/89-004)
Category:     ADDITION
Edit history: 24-Jan-89, Version 1 by Pitman
	      25-Jan-89, Version 2 by Pitman
	      29-Mar-89, Version 3, by Moon, amended based on poll

Problem Description:

  Common Lisp programmers have frequently complained that the
  destructuring facility used by DEFMACRO is not made available
  for use in ordinary programming situations involving list data.

  The presence of a destructuring facility in the recently adopted
  LOOP facility will be likely to make the absence of a separable
  destructuring facility all the more apparent.

  Prior to the introduction of LET into Maclisp, many people wrote
  their own LET macros. A popular expansion was in terms of a DO
  which did not iterate. eg,
    (LET ((A 3)) (+ A A)) ==> (DO ((A 3)) () (RETURN (+ A A)))
  While this practice `worked,' it was not perspicuous and contributed 
  substantially to non-readability: not only were the macros hard to
  understand, but the surface interface itself was not standardized
  and varied in subtle ways. For example, some LET macros allowed GO
  statements while others did not.

  There is now considerable danger that a lot of people will write
  DESTRUCTURING-BIND variants in terms of a LOOP expression that
  immediately returns.
    (DESTRUCTURING-BIND ((A B) C) (FOO) (LIST A B C))
    ==> (LOOP FOR ((A B) C) ON (FOO) DO (RETURN (LIST A B C)))
  Since the destructuring offered by LOOP is different in subtle ways
  from the destructuring offered by DESTRUCTURING-BIND in implementations
  offering that primitive natively, gratuitous headaches could result.

Proposal (DESTRUCTURING-BIND:NEW-MACRO):

  Provide a macro called DESTRUCTURING-BIND which behaves like the
  destructuring bind in DEFMACRO. Specifically...

  DESTRUCTURING-BIND lambda-list expression {decl}* {form}*   [Macro]

   Binds the variables specified in LAMBDA-LIST to the corresponding
   values in the tree structure resulting from evaluating EXPRESSION,
   then evaluates the FORMS in the body.

   Anywhere in the LAMBDA-LIST where a parameter name may appear, and
   where ordinary lambda-list syntax (as described in CLtL section 5.2.2)
   does not otherwise allow a list, a lambda-list may appear in place of
   the parameter name. When this is done, then 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.

   If any of the lambda list keywords &OPTIONAL, &REST, &KEY,
   &ALLOW-OTHER-KEYS and &AUX appears in the lambda list, it is treated
   as with any other lambda-list.

   If the lambda list keyword &BODY appears, it is treated as a synonym
   for &REST.

   The lambda list keyword &ENVIRONMENT is not allowed.

   If the lambda list keyword &WHOLE appears, it must be followed by a
   single variable that is bound to the entire expression at the current
   level. &WHOLE and its following variable should appear first in the
   list, before any other parameter or lambda-list keyword.

   It is also permissible for any level of the LAMBDA-LIST to be dotted,
   ending in a parameter name. This situation is treaed exactly as if
   the aprameter name that ends the list had appeared preceded by &REST
   in a proper list. For example, the notation (X Y . Z) is equivalent
   to (X Y &REST Z).

   If the result of evaluating the expression does not match the 
   destructuring pattern, an error should be signaled. 

Test Case:

  (DEFUN IOTA (N) (LOOP FOR I FROM 1 TO N COLLECT I)) ;helper

  (DESTRUCTURING-BIND ((A &OPTIONAL (B 'BEE)) ONE TWO THREE)
		      `((ALPHA) ,@(IOTA 3))
    (LIST A B THREE TWO ONE))
  => (ALPHA BEE 3 2 1)

Rationale:

  The proposal directly addresses the stated problem, and is current practice
  in numerous implementations. Our charter effectively dictates that where
  feasible we should try to head off the widespread development of uselessly
  different variants of commonplace tools.

   The intent of the specification is to make DESTRUCTURING-BIND lambda-lists
   compatible with inner-list elements of a macro lambda-list.

Current Practice:

  Symbolics Genera, Envos Medley, TI Explorer, and Lucid CL all offer
  DESTRUCTURING-BIND, though the details vary slightly.

  The DESTRUCTURING-BIND offered by Symbolics Genera signals an error if
  the pattern is not matched. The TI Explorer version does not.

Cost to Implementors:

  Very small. In most cases, it's a matter of renaming and/or exporting an
  already existing symbol. In a few cases, a very small amount of 
  `program interface' code would have to be written.

Cost to Users:

  None. This is an upward compatible change.

Cost of Non-Adoption:

  Loss of the Benefits and Aesthetics cited below.

Benefits:

  Users will get a powerful feature they have asked for on many occassions.

  In implementations which `autoload' code, it would be better for this
  support to be separable so that people could do DESTRUCTURING-BIND
  without demand loading all other LOOP support.

Aesthetics:

  Defining this macro centrally for the Common Lisp community will reduce
  subtle deviations, which will in turn have positive aesthetic impact.

Discussion:

  JonL observes that although LOOP does destructuring, it can't directly
  make use of the DESTRUCTURING-BIND interface suggested here.

  Pitman and Gray think a facility of this sort is a good idea, though
  obviously the details may still need a little fleshing out before the
  proposal is ready for vote.

  To date, the excuse for not satisfying this request has been a
  religious war between factions who want to destructure lists by
  writing
    (DESTRUCTURING-BIND (var1 var2 var3) exp . body)
  and those who want to destructure lists by writing
    (DESTRUCTURING-BIND (LIST var1 var2 var3) exp . body)

  The advantage of the former approach is that it is notationally
  concise for the common case of destructuring a list. The disadvantage
  is that it is not extensible to accomodate abstract kinds of
  destructuring.

  The advantage of the latter approach is that it allows interesting
  extensions that accomodate data-hiding, such as:
    (DEFMACRO MAKE-FOO (&REST ELEMENTS) `(LIST ,@ELEMENTS))
    (DESTRUCTURING-BIND (MAKE-FOO var1 var2 var3) exp . body)
  and later the ability to change the representation of a FOO without
  updating the associated binding forms. The disadvantage is that it
  is more verbose in the common case of destructuring a list, and still
  even more verbose for nested lists.

  Although destructuring has always existed in DEFMACRO, this has not
  been adequate precedence for deciding the outcome of the religious war
  because DEFMACRO only needs to destructure programs, and programs are
  generally made up only of lists -- not arbitrary user-defined abstract
  data types.

  The lambda-list form of DESTRUCTURING-BIND in this version is
  not completely compatible with the destructuring done by LOOP
  in three areas: LOOP allows NIL elements of a list to be ignored,
  LOOP does not allow &-keywords, and LOOP destructuring ignores
  extra elements in the list being matched.

∂04-Apr-89  0804	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:04:40 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570859; Tue 4-Apr-89 11:04:34 EDT
Date: Tue, 4 Apr 89 11:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110402.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say this was deferred to next meeting.

∂04-Apr-89  0805	CL-Cleanup-mailer 	Issue: BREAK-ON-WARNINGS-OBSOLETE   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:05:10 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570860; Tue 4-Apr-89 11:05:11 EDT
Date: Tue, 4 Apr 89 11:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: BREAK-ON-WARNINGS-OBSOLETE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110447.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say this passed unanimously with friendly amendment to
"remove" rather than "deprecate".

∂04-Apr-89  0805	CL-Cleanup-mailer 	Issue: CLOS-CONDITIONS    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:05:45 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570862; Tue 4-Apr-89 11:05:44 EDT
Date: Tue, 4 Apr 89 11:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOS-CONDITIONS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110518.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say this passed on a vote of N-0-3.

∂04-Apr-89  0808	CL-Cleanup-mailer 	Issue: CLOS-MACRO-COMPILATION  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:08:08 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570863; Tue 4-Apr-89 11:08:06 EDT
Date: Tue, 4 Apr 89 11:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOS-MACRO-COMPILATION
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110742.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say that several amendments by Gregor were discussed but eventually
the issue was tabled until the next meeting. (A new version should be written
incorporating those amendments.)

Moon's notes add that on the issue of when forms are evaluated, Gregor's
amendment covered it for EQL parameter specializer names, but not for
DEFCONSTANT; perhaps DEFCONSTANT should be brought up as another cleanup.

∂04-Apr-89  0809	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:09:00 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570864; Tue 4-Apr-89 11:09:01 EDT
Date: Tue, 4 Apr 89 11:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOSED-STREAM-OPERATIONS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110837.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say...

 A motion to reconsider this issue passed N-2.
 A motion to revoke version 7 and replace it with version 5 was made.
  Walter van Roggen proposed we amend it to make all CLOSE return values
  unspecified.
  The motion to amend failed on a 3-4-N vote.
  A recount was requested because people aren't permitted to abstain on
  technical issues.
  The motion still failed on a 6-8 vote.
 The original motion (to replace v7 with v5) passed unamended 12-0.

∂04-Apr-89  0809	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:09:35 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570867; Tue 4-Apr-89 11:09:31 EDT
Date: Tue, 4 Apr 89 11:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COERCE-INCOMPLETE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110907.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say that someone made a motion for option DEPRECATE but it
died for lack of a second. This issue was marked withdrawn.

∂04-Apr-89  0816	CL-Cleanup-mailer 	Issue: COMMON-TYPE   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:10:06 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570871; Tue 4-Apr-89 11:10:01 EDT
Date: Tue, 4 Apr 89 11:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMMON-TYPE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110930.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say this passed unanimously.

∂04-Apr-89  0817	CL-Cleanup-mailer 	Issue: COMPILE-FILE-SYMBOL-HANDLING 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:13:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570885; Tue 4-Apr-89 11:13:56 EDT
Date: Tue, 4 Apr 89 11:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPILE-FILE-SYMBOL-HANDLING
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404111332.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

Moon's notes (mine were less complete) say there was disagreement about
which approach was worthwhile, so the committee will pursue option
REQUIRE-CONSISTENCY.  They will delete ``must ensure'' since that is in
general impossible.  People were asked to comment in mail (on the issue
of where SELECT-PACKAGE can go?).

This was deferred to next meeting.

∂04-Apr-89  0817	CL-Cleanup-mailer 	Issue: COMPILE-ENVIRONMENT-CONSISTENCY   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:11:16 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570878; Tue 4-Apr-89 11:11:16 EDT
Date: Tue, 4 Apr 89 11:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPILE-ENVIRONMENT-CONSISTENCY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404111052.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say 
  ``Gregor--Omit (g) 2nd sentence and say "structure or deftype" type specs''
Moon's notes agree and add
  ``For defclass, no info is compiled in, so superclass, metaclass, slots
    can be different at load time.  Change 3rd sentence not to apply to
    DEFCLASS-defined types.''
This was tabled.

I also have a note to myself that I wondered if NOTINLINE and the FTYPE
declaration restrictions should interact.

∂04-Apr-89  0823	CL-Cleanup-mailer 	COMPILE-FILE-SYMBOL-HANDLING, COMPILE-ENVIRONMENT-CONSISTENCY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:23:23 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570902; Tue 4-Apr-89 11:23:20 EDT
Date: Tue, 4 Apr 89 11:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: COMPILE-FILE-SYMBOL-HANDLING, COMPILE-ENVIRONMENT-CONSISTENCY
To: CL-Cleanup@SAIL.Stanford.EDU
References: <890404111332.7.KMP@BOBOLINK.SCRC.Symbolics.COM>,
            <890404111052.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890404112256.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

Oops--wrong list. Those were compiler issues. Please ignore them. Thanks.

∂04-Apr-89  0832	CL-Cleanup-mailer 	Issue: COMPLEX-RATIONAL-RESULT 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:32:12 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570916; Tue 4-Apr-89 11:32:14 EDT
Date: Tue, 4 Apr 89 11:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPLEX-RATIONAL-RESULT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113150.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say this passed n-0-2.

∂04-Apr-89  0833	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:33:21 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570918; Tue 4-Apr-89 11:33:23 EDT
Date: Tue, 4 Apr 89 11:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-RESTARTS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113259.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say this wasn't ready for a vote.
 GZ wants us to flush COPY-CONDITION, which we're already planning to do.
 IIM wants a :TEST keyword for restarts to allow them to selectively apply.
 Loosemore wants not to forbid resignalling or any new version should relate
 itself to item 3 of COMPILER-DIAGNOSTICS, which discusses resignalling.
Deferred to next meeting.

∂04-Apr-89  0834	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-COPY-PLIST  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:34:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570919; Tue 4-Apr-89 11:34:14 EDT
Date: Tue, 4 Apr 89 11:33 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-COPY-PLIST
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113350.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say this passed unanimously.

∂04-Apr-89  0834	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-COPY-PRINT-NAME  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:34:43 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570920; Tue 4-Apr-89 11:34:43 EDT
Date: Tue, 4 Apr 89 11:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-COPY-PRINT-NAME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113419.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say this passed unanimously.

∂04-Apr-89  0835	CL-Cleanup-mailer 	Issue: DECLARE-FUNCTION-AMBIGUITY   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:35:21 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570921; Tue 4-Apr-89 11:35:24 EDT
Date: Tue, 4 Apr 89 11:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-FUNCTION-AMBIGUITY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113500.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

There was confusion about how this had worked out at the late meeting.
An incredibly weird vote on the question ``How many favor saying it passed
at the last meeting?'' passed N-0-M.

∂04-Apr-89  0842	CL-Cleanup-mailer 	Issue: DEFINE-OPTIMIZER   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:42:28 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570934; Tue 4-Apr-89 11:42:22 EDT
Date: Tue, 4 Apr 89 11:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFINE-OPTIMIZER
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404114158.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

After some fooling around with various amendments, this was brought to
a vote with the names DEFINE-COMPILER-MACRO (and I guess 
COMPILER-MACROEXPAND and COMPILER-MACROEXPAND-1, though I realized later
that it was never made explicit) and failed 8-11-0.

I believe the issue may get re-opened. The reason is that I recently
realized that (a) users cannot write thing that ``should signal''
and (b) all they need to write things that ``should signal'' is
this functionality plus that provided in SYNTACTIC-ENVIRONMENT-ACCESS.

That's all I have to say for now. But don't be surprised if I have more
to say later.

∂04-Apr-89  0852	CL-Cleanup-mailer 	Issue: DEFMACRO-LAMBDA-LIST    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:52:40 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570949; Tue 4-Apr-89 11:52:39 EDT
Date: Tue, 4 Apr 89 11:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFMACRO-LAMBDA-LIST
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404115215.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

There were hardcopy amendments distributed. The hardcopy said:

  Proposed amendments to DEFMACRO-LAMBDA-LIST     KMP 3/30/89
						  (from MLY)

  A. [Friendly] In 1b, change "may only appear at any level"
			   to "may appear at any level".

  B. [Vote separately]

     1.  Prohibit/Permit (&whole W &environment E A B)
     2.  Prohibit/Permit (&environment E &whole W A B)
     3.  Prohibit/Permit (&whole W A B &environment E)
     4.  Prohibit/Permit (&whole W A &environment E B)

My notes say that we approved amendments A & B (``permit all four'')
and we added an amendment that said that &ENVIRONMENT would not be
duplicated in a DEFMACRO lambda-list.

The amended proposal was passed N-0-1.

∂04-Apr-89  0855	CL-Cleanup-mailer 	Issue: DEFMACRO-LAMBDA-LIST    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:54:55 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570953; Tue 4-Apr-89 11:54:56 EDT
Date: Tue, 4 Apr 89 11:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFMACRO-LAMBDA-LIST
To: CL-Cleanup@SAIL.Stanford.EDU
Supersedes: <890404115215.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890404115432.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

There were hardcopy amendments distributed. The hardcopy said:

  Proposed amendments to DEFMACRO-LAMBDA-LIST     KMP 3/30/89
						  (from MLY)
 
  A. [Friendly] In 1b, change "may only appear at any level"
			   to "may appear at any level".
 
  B. [Vote separately]
 
     1.  Prohibit/Permit (&whole W &environment E A B)   ``After &Whole''
     2.  Prohibit/Permit (&environment E &whole W A B)   ``Before &Whole''
     3.  Prohibit/Permit (&whole W A B &environment E)   ``Last''
     4.  Prohibit/Permit (&whole W A &environment E B)   ``Middle''

My notes say that we approved amendments A & B (``permit all four'')
and we added an amendment that said that &ENVIRONMENT would not be
duplicated in a DEFMACRO lambda-list.

The amended proposal was passed N-0-1.

∂04-Apr-89  0855	CL-Cleanup-mailer 	Issue: DESCRIBE-UNDERSPECIFIED 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:55:17 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570954; Tue 4-Apr-89 11:55:17 EDT
Date: Tue, 4 Apr 89 11:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESCRIBE-UNDERSPECIFIED
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404115453.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

An amendment was made (I think by Barrett) to make DESCRIBE deal with 
its second argument in the same way as PRINT does (that is, permitting
arguments of NIL and T).

The amended proposal passed 15-0.

∂04-Apr-89  0857	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  08:57:16 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570958; Tue 4-Apr-89 11:57:09 EDT
Date: Tue, 4 Apr 89 11:56 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESTRUCTURING-BIND
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404115645.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say that discussion on this was broken over two days with
quite a number of possible amendments discussed.

I came up with a written set of amendments for Thursday which were
discarded because Moon submitted a coherent revised proposal 
(consistent with those amendments, and adding at least one other
feature not covered in those separate amendments) on Thursday.

The revised proposal was Moon's v3, already mailed.
The revised proposal was voted on, and passed 15-1.

∂04-Apr-89  1027	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 1 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Apr 89  10:27:27 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA29744; Tue, 4 Apr 89 11:27:25 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA19101; Tue, 4 Apr 89 11:27:23 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904041727.AA19101@defun.utah.edu>
Date: Tue, 4 Apr 89 11:27:21 MDT
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: cl-cleanup@sail.stanford.edu

As promised, here's a first cut at this issue.  I'm not particularly
attached to the name DYNAMIC-EXTENT-FUNCTION, but I'm still feeling
too burned out from arguing over what to rename DEFPROCLAIM to want to
waste a lot of time on thinking up alternate names for this one too. :-(


Forum:		CLEANUP
Issue:          DYNAMIC-EXTENT-FUNCTION
References:     Scope and Extent
		Issue DYNAMIC-EXTENT
Category:       ADDITION
Edit history:   04-Apr-89, Version 1 by Loosemore

Problem Description:

  Proposal DYNAMIC-EXTENT:NEW-DECLARATION, passed at the March 89 
  meeting, provides a mechanism for declaring that the values of
  variables have only dynamic (rather than indefinite) extent.  It
  would be useful to have similar functionality to indicate that
  functional bindings may have only dynamic extent.  (For example,
  this would permit compilers to stack-allocate closures.)

Proposal (DYNAMIC-EXTENT:NEW-DECLARATION):

  Introduce a new declaration called DYNAMIC-EXTENT-FUNCTION.  This is
  identical to the DYNAMIC-EXTENT declaration, except that the
  arguments name functions instead of variables.

Rationale:

  This permits a programmer to offer advice to an implementation about
  what functions may be stack-allocated for efficiency.

  It may be difficult or impossible for a compiler to infer this
  same information statically.

Current Practice:

  JonL says that Lucid's compiler can stack-allocate closures, but they
  have no mechanism for programmers to give the compiler permission to
  do so.

  HPCL-I has an UPWARD-CLOSURES declaration that pervasively affects
  all closures created within the scope of the declaration.

Cost to Implementors:

  No cost is forced since implementations are permitted to simply
  ignore the DYNAMIC-EXTENT-FUNCTION declaration.

Cost to Users:

  None. This change is upward compatible.

  There may be some hidden costs to debugging using this declaration (or any
  feature which permits the user to access dynamic extent objects without
  the compiler proving that they are appropriate). If the user misdeclares
  something and returns a pointer into the stack (or stores it in the heap),
  an undefined situation may result and the integrity of the Lisp storage
  mechanism may be compromised. Debugging these situations may be tricky,
  but users who have asked for this feature have indicated a willingness
  to deal with such costs. Nevertheless, the perils should be clearly
  documented and casual users should not be encouraged to use this
  declaration.

Cost of Non-Adoption:

  Some portable code would be forced to run more slowly (due to
  GC overhead), or to use non-portable language features.

Benefits:

  The cost of non-adoption is avoided.

Aesthetics:

  This declaration allows a fairly low level optimization to work
  by asking the user to provide only very high level information.
  The alternatives (sharpsign conditionals, some of which may
  lead to more bit-picky abstractions) are far less aesthetic.

Discussion:

  Loosemore supports DYNAMIC-EXTENT-FUNCTION:NEW-DECLARATION.
-------

∂04-Apr-89  1110	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:10:38 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571083; Tue 4-Apr-89 14:10:29 EDT
Date: Tue, 4 Apr 89 14:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT
To: CL-Cleanup@SAIL.Stanford.EDU
cc: sandra%defun@CS.Utah.EDU
Message-ID: <890404141003.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

Sandra and Gabriel initially claimed to oppose this even in principle.

However, Steele and I drafted a revised proposal over lunch Thursday.
The text of the revised proposal was:

 GLS and KMP 3/30/89

 Amendment to DYNAMIC-EXTENT:NEW-DECLARATION

 * Strike sentences 3 and 4 of paragraph 1.
 * Move paragraphs 3 through n-1 to the examples.
 * Strike last paragraph.
 * Add this text after paragraph 1:

   _Definition_: Object _x_ is an _otherwise_inaccessible_part_ (OIP)
    of _y_ iff making _y_ inaccessible would make _x_ inaccessible.
    (Note that every object is an OIP of itself.)

   Suppose that construct _c_ contains a DYNAMIC-EXTENT declaration
   for variable _v_ (which need not be bound by _c_).  Consider the
   values _w1_, ..., _wN_ taken on by _v_ during the course of some
   execution of _c_.  The declaration asserts that if object _x_ is
   an OIP of _wI_ when _wI_ ever becomes the value of _v_, then
   just after execution of _c_ terminates _x_ will be either 
   inaccessible or still an OIP of _v_.

The proposal was also amended in the meeting to say:

 "If the assertion is ever violated, the conseqeuences are undefined."

The fully amended proposal passed 17-0.

It was generally agreed that we would also like to consider a proposal
on dynamic extent functions at the next meeting. (Sandra said she would
prepare one, and has already done so. See issue DYNAMIC-EXTENT-FUNCTION.)

∂04-Apr-89  1111	CL-Cleanup-mailer 	Issue: EQUALP-GENERIC
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:11:49 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571085; Tue 4-Apr-89 14:11:46 EDT
Date: Tue, 4 Apr 89 14:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EQUALP-GENERIC
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141117.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say this issue was withdrawn by Barrett.

∂04-Apr-89  1114	CL-Cleanup-mailer 	Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:14:07 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571087; Tue 4-Apr-89 14:13:58 EDT
Date: Tue, 4 Apr 89 14:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141334.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes show the following...

 The major roadblocks were that GZ (and a few others) were hung up on the
 presentation of ``should signal.''

 GZ cited the example of (LOCALLY (DECLARE (OPTIMIZE (SAFETY 0))) #'+).
 She wanted to know if the resulting function could fail to do error checking.
 (RPG and KMP will pursue this.)

 JonL really hated the presentation of the boole arguments using #.

 RWK said we should definitely do this kind of stuff (error type identification)
 now if possible, and not wait for the next standard.

 Walter van Roggen was worried that some of this stuff might be controversial,
 but I assured him that we would back off to a more vague error type
 rather than dispute endlessly about controversial cases. He seemed happy with
 that.

 Haflich seemed to believe that this was especially important for numbers, so
 he was happy to see this chapter done.

 Masinter said that with his implementor's hat on, he thought this was a pain,
 but that with his user's hat on, he liked it.  He was letting his user side
 dominate and being very supportive.

There was consensus that we should discuss this (and similar proposals) at
the next meeting.

∂04-Apr-89  1115	CL-Cleanup-mailer 	Issue: ERROR-NOT-HANDLED  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:15:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571089; Tue 4-Apr-89 14:15:16 EDT
Date: Tue, 4 Apr 89 14:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-NOT-HANDLED
To: CL-Cleanup@SAIL.Stanford.EDU
cc: chapman%aitg.dec@decwrl.dec.com
Message-ID: <890404141451.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say this issue was withdrawn in favor of providing Kathy with
editorial advice to `minimize implicit requirements on debuggers' in the
presentation of the debugger in the standard.

Kathy- if the implication of that is not clear, let me know privately
and I'll help you get that in order.

∂04-Apr-89  1117	CL-Cleanup-mailer 	Issue: FUNCTION-COERCE-TIME    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:16:47 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571092; Tue 4-Apr-89 14:16:48 EDT
Date: Tue, 4 Apr 89 14:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COERCE-TIME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141624.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes show this as withdrawn.
The editors were instructed to be explicitly vague 16-1.

∂04-Apr-89  1125	CL-Cleanup-mailer 	Issue: EXIT-EXTENT   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:16:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571091; Tue 4-Apr-89 14:16:18 EDT
Date: Tue, 4 Apr 89 14:15 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141553.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was characterized by someone as ``the unstoppable throw meeting the
immovable catch.''

I offered a "one time only" offer to support option MINIMAL if we could
just get this off the table this week and not keep deferring it.

Moon offered some amendments the effect of which were to allow you to throw again
to the same tag as you were already throwing to; specifically:
In the first paragraph of the MINIMAL proposal, delete "or is itself the
target exit" and change "events (c) and (d) at" to "event (c) occurs at".
After the first paragraph add a new paragraph "The event (d) occurs at the
end of the transfer of control."

The proposal was amended, and the amended option MINIMAL passed 11-5.

∂04-Apr-89  1127	CL-Cleanup-mailer 	Re: Issue: DYNAMIC-EXTENT 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:26:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 571107; 4 Apr 89 14:21:42 EDT
Date: Tue, 4 Apr 89 14:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DYNAMIC-EXTENT
To: sandra%defun@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8904041817.AA19138@defun.utah.edu>
Message-ID: <890404142113.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Tue, 4 Apr 89 12:17:17 MDT
    From: sandra%defun@cs.utah.edu (Sandra J Loosemore)

    > Sandra and Gabriel initially claimed to oppose this even in principle.

    Gack -- I've been misquoted!  The principle is fine with me and the
    revision fixed the thing that bugged me the most (making the
    declaration apply to *any* value assigned to the variable instead of
    just its initial value) about the original proposal.

Ok, I stand corrected -- and I'm glad to see you're happy with what
we decided.

The whole reason I'm distributing this stuff is to make sure my view of
what happened aligns with other people's.  I guess if it's catching
discrepancies, that's a sign that the process is worthwhile. :-}

∂04-Apr-89  1127	CL-Cleanup-mailer 	Issue: FUNCTION-NAME 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:17:21 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571095; Tue 4-Apr-89 14:17:15 EDT
Date: Tue, 4 Apr 89 14:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-NAME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141651.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes show the following...

 We voted in order SMALL, MEDIUM, then LARGE.
 Each time, the attempt was to replace the previous.
 Option SMALL passed 15-2.
 Option MEDIUM passed 9-6, superseding SMALL.
 Option LARGE passed 13-2-3, superseding MEDIUM.
 The minutes probably just reflect LARGE having been passed.
 Moon then moved that we reconsider parts of LARGE -- parts 4,7,8,9.
 We agreed to reconsider.
 Sandra moved to retract 4,7,8,9.
  RPG amended the proposal to affect GENERIC-FLET and GENERIC-LABELS, too,
  for consistency.
  RPG's amendment to Sandra's motion passed.
 We voted on each part of Sandra's motion separately:
  Strike 4? No.  (Failed 3-15)
  Strike 7? Yes. (Passed 16-1)
  Strike 8? Yes. (Passed 16-0)
  Strike 9? Yes  (Passed 17-0-1)
   There was some question about 9's relation to SYNTACTIC-ENVIRONMENT-ACCESS.
 The net effect is that option LARGE passed with amendments to strike 7,8,9.

∂04-Apr-89  1133	CL-Cleanup-mailer 	Re: Issue: DYNAMIC-EXTENT 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:17:25 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA02524; Tue, 4 Apr 89 12:17:20 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA19138; Tue, 4 Apr 89 12:17:18 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904041817.AA19138@defun.utah.edu>
Date: Tue, 4 Apr 89 12:17:17 MDT
Subject: Re: Issue: DYNAMIC-EXTENT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU, sandra%defun@cs.utah.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 4 Apr 89 14:10 EDT

> Sandra and Gabriel initially claimed to oppose this even in principle.

Gack -- I've been misquoted!  The principle is fine with me and the
revision fixed the thing that bugged me the most (making the
declaration apply to *any* value assigned to the variable instead of
just its initial value) about the original proposal.

-Sandra
-------

∂04-Apr-89  1133	CL-Cleanup-mailer 	Issue: GENSYM-NAME-STICKINESS  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:17:42 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571096; Tue 4-Apr-89 14:17:43 EDT
Date: Tue, 4 Apr 89 14:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141718.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

Option LIKE-TEFLON passed 17-0.

There was general agreement that the issue name was an example of good marketing
and helped the proposal slide right through.

∂04-Apr-89  1147	CL-Cleanup-mailer 	Issue: HASH-TABLE-ACCESS  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:47:01 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571158; Tue 4-Apr-89 14:46:59 EDT
Date: Tue, 4 Apr 89 14:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-ACCESS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404144633.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say this passed 17-0 with hand-written amendments by me
(and agreement that the `obvious' write-o's would be corrected).

The [corrected] hand-written text says:

 Amendment to HASH-TABLE-ACCESS		KMP 3/30/89

 Add:	Define that the results of HASH-TABLE-REHASH-SIZE,
	HASH-TABLE-REHASH-THRESHOLD, and HASH-TABLE-SIZE
	are suitable for use in a call to MAKE-HASH-TABLE
	in order to produce a hash table with state
	corresponding to the current state of the hash table.

 Clarify that the result of HASH-TABLE-TEST is always a
 symbol naming a function rather than the function itself if
 the test is one of those defined by this standard.
 (Implementations which provide additional tests for hash
 tables may determine how this function relates to such 
 extended tests.)

∂04-Apr-89  1148	CL-Cleanup-mailer 	Issue: HASH-TABLE-SIZE    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:48:15 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 571161; 4 Apr 89 14:47:57 EDT
Date: Tue, 4 Apr 89 14:47 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-SIZE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404144729.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

It was suprising to me how much controversy there was on this.

Moon thinks the basic disagreement is that some people (JonL) think that
the hash nature of tables should be explicitly exposed and other people
(Moon) think it should be hidden; consider a fixnum value for 
:rehash-threshold, which interacts with the value of :size, according
to JonL.

This issue was deferred to the next meeting on a 13-2 vote.

∂04-Apr-89  1149	CL-Cleanup-mailer 	Issue: IN-PACKAGE-FUNCTIONALITY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:48:54 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571162; Tue 4-Apr-89 14:48:52 EDT
Date: Tue, 4 Apr 89 14:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-PACKAGE-FUNCTIONALITY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404144827.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

From my notes...

 On Tuesday, we took a straw poll.
   0 opposed both proposals.
  15 liked NEW-MACRO.
   7 liked SELECT-ONLY.
 ``Keeping IN-PACKAGE makes no difference to compatibility.'' --Moon
 Pitman moved to amend this to say "deprecate" instead of remove.
 The motion to amend failed 3-N.
 The NEW-MACRO proposal passed unamended 12-4.

 On Thursday, Aaron Larson and JonL asked that the issue be reconsidered.
 The motion to reconsider passed N-1.
 There was a motion to rename the SELECT-PACKAGE which we'd voted in to
 IN-PACKAGE -- so that the compatible syntax (IN-PACKAGE "FOO") would work
 in CLtL and ANSI CL.
 Steele requested verbal clarification that we were not trying to solve
 the ``dusty file'' problem but rather to make it possible to write new code
 that worked in old and new situations -- it was agreed that this was a
 correct characterization of the proposal.
 JonL's amendment passed 13-1.
 Then the amended proposal was voted in 14-0.

The net effect is that NEW-MACRO passed with the name of SELECT-PACKAGE
changed to IN-PACKAGE.

∂04-Apr-89  1153	CL-Cleanup-mailer 	Issue: IN-SYNTAX
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:53:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571174; Tue 4-Apr-89 14:53:10 EDT
Date: Tue, 4 Apr 89 14:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404145245.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

Version 2, which makes LOAD and *COMPILE-FILE* bind *READTABLE* (and
which does -not- introduce the IN-SYNTAX macro mentioned in version 1)
passed 12-0-3.  This version was distributed by KMP in handwritten form.

The full text of the hand-written proposal was:

  Issue IN-SYNTAX (Version 2)		KMP 3/30/89

  Proposal (IN-SYNTAX:MINIMAL):

   Define that COMPILE-FILE and LOAD bind *READTABLE* to its
   current value.

  Rationale:

   This allows portable programs to do

     (IN-PACKAGE "FOO")
     (EVAL-WHEN (EVAL LOAD COMPILE)
       (SETQ *READTABLE* FOO:MY-READTABLE))

   at the top of a file without globally side-effecting the
   environment.

   Currently, there is no portable way to change the syntax only for
   the duration of a file, which in turn makes customized syntax
   difficult to use safely.

∂04-Apr-89  1156	CL-Cleanup-mailer 	Issue: LISP-PACKAGE-NAME  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:56:22 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571175; Tue 4-Apr-89 14:56:13 EDT
Date: Tue, 4 Apr 89 14:55 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-PACKAGE-NAME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404145549.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say...

 Steele suggested amending this to rename package USER to COMMON-LISP-USER.
 The amendment was accepted as a friendly amendment.
 The proposal was passed 12-4.

 Barry Margolin wanted the package COMMON-LISP-USER to have nickname CL-USER.
 Amendment accepted (after the original proposal was approved) 11-0-n.

The net effect is that this passed with amendment to rename package USER to 
COMMON-LISP-USER with nickname CL-USER.

∂04-Apr-89  1200	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  11:59:22 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571187; Tue 4-Apr-89 14:59:17 EDT
Date: Tue, 4 Apr 89 14:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-SYMBOL-REDEFINITION
To: CL-Cleanup@SAIL.Stanford.EDU
cc: sandra%defun@SAIL.Stanford.EDU
Message-ID: <890404145850.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

I need some help here. My notes say:

 GZ wanted an amendment to strike item 8 from this list.

 Sandra had some concern about the penultimate paragraph where she wanted a
 prohibition on the ability to trace local functions (in implementations that
 permit that).  Moon thinks the proposal was amended to explicitly allow
 tracing of such local function bindings.

>> Sandra: Please resolve this!

 We went round in circles about item 8.  A straw poll to send this back for
 more work failed 6-10, so we kept on.

 A motion was made to terminate discussion. This passed by 2/3 vote.

 Moon's notes say item 8 may need further refinement, as for instance by GLS's
 amendment.  The goal is to separate properties into the ones the user can
 bash and the ones the user cannot bash. [Anyway, we should expect that item 8
 may come up in some form at the next meeting.]

 Ultimately, I have written in my notes that we voted on
   ``proposal replaced by RPG, item 8 struck, w/ Sandra's prohibition
     to trace local functions''
 and that it passed 14-3.

>> This might not be accurate depending on how the discrepancy above is resolved.

∂04-Apr-89  1206	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:06:42 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571193; Tue 4-Apr-89 15:06:37 EDT
Date: Tue, 4 Apr 89 15:06 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404150611.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

Moon proposed friendly amendment to use the name MAKE-LOAD-FORM-SAVING-SLOTS.

The amended proposal passed 18-0.

I had to produce a revised writeup for my own purposes anyway, so it's 
attached below.
-----
Issue:         LOAD-OBJECTS

References:    none

Related issues: LOAD-TIME-EVAL,
                CONSTANT-COMPILABLE-TYPES,
                CONSTANT-CIRCULAR-COMPILATION

Category:      ADDITION

Forum:         Cleanup

Edit history:  Version 1, 2-Jan-89, by Moon (for discussion)
               Version 2, 13-Jan-89, by Moon (draft updated from discussion)
               Version 3,  9-Mar-89, by Moon (changes suggested by discussion)
	       Version 4, 4-Apr-89, by Pitman (changes per X3J13 Mar 89; 
		 MAKE-LOAD-FORM-USING-SLOTS => MAKE-LOAD-FORM-SAVING-SLOTS)

Status:  Accepted by an 18-0 vote, March 1989.

Problem description:

  Common Lisp doesn't provide any way to use an object of a user-defined
  type (defined with DEFCLASS or DEFSTRUCT) as a constant in a program
  compiled with COMPILE-FILE.  The problem is that LOAD has to be able
  to "reconstruct" an equivalent object when the compiled-code file is
  loaded, but the programmer has no way to tell LOAD how to do that.


Proposal (LOAD-OBJECTS:MAKE-LOAD-FORM):
          
  Define a new generic function named MAKE-LOAD-FORM, which takes one
  argument and returns two values.  The argument is an object that is
  referenced as a constant or as a self-evaluating form in a file being
  compiled by COMPILE-FILE.  The objective is to enable LOAD to
  construct an equivalent object.

  The first value, called the "creation form," is a form that, when
  evaluated at load time, should return an object that is equivalent to
  the argument.  The exact meaning of "equivalent" depends on the type
  of object and is up to the programmer who defines a method for
  MAKE-LOAD-FORM.  This is the same type of equivalence discussed
  in issue CONSTANT-COMPILABLE-TYPES.

  The second value, called the "initialization form," is a form that,
  when evaluated at load time, should perform further initialization of
  the object.  The value returned by the initialization form is ignored.
  If the MAKE-LOAD-FORM method returns only one value, the
  initialization form is NIL, which has no effect.  If the object used
  as the argument to MAKE-LOAD-FORM appears as a constant in the
  initialization form, at load time it will be replaced by the
  equivalent object constructed by the creation form; this is how the
  further initialization gains access to the object.

  Both the creation form and the initialization form can contain
  references to objects of user-defined types (defined precisely below).
  However, there must not be any circular dependencies in creation forms.
  An example of a circular dependency is when the creation form for the
  object X contains a reference to the object Y, and the creation form
  for the object Y contains a reference to the object X.  A simpler
  example would be when the creation form for the object X contains
  a reference to X itself.  Initialization forms are not subject to
  any restriction against circular dependencies, which is the entire
  reason that initialization forms exist.  See the example of circular
  data structures below.

  The creation form for an object is always evaluated before the
  initialization form for that object.  When either the creation form or
  the initialization form references other objects of user-defined types
  that have not been referenced earlier in the COMPILE-FILE, the
  compiler collects all of the creation and initialization forms.  Each
  initialization form is evaluated as soon as possible after its
  creation form, as determined by data flow.  If the initialization form
  for an object does not reference any other objects of user-defined
  types that have not been referenced earlier in the COMPILE-FILE, the
  initialization form is evaluated immediately after the creation form.
  If a creation or initialization form F references other objects of
  user-defined types that have not been referenced earlier in the
  COMPILE-FILE, the creation forms for those other objects are evaluated
  before F, and the initialization forms for those other objects are
  also evaluated before F whenever they do not depend on the object
  created or initialized by F.  Where the above rules do not uniquely
  determine an order of evaluation, which of the possible orders of
  evaluation is chosen is unspecified.

  While these creation and initialization forms are being evaluated, the
  objects are possibly in an uninitialized state, analogous to the state
  of an object between the time it has been created by ALLOCATE-INSTANCE
  and it has been processed fully by INITIALIZE-INSTANCE.  Programmers
  writing methods for MAKE-LOAD-FORM must take care in manipulating
  objects not to depend on slots that have not yet been initialized.

  It is unspecified whether LOAD calls EVAL on the forms or does some
  other operation that has an equivalent effect.  For example, the
  forms might be translated into different but equivalent forms and
  then evaluated, they might be compiled and the resulting functions
  called by LOAD, or they might be interpreted by a special-purpose
  interpreter different from EVAL.  All that is required is that the
  effect be equivalent to evaluating the forms.

  COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
  a constant or as a self-evaluating form, if the object's metaclass is
  STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
  subclass of BUILT-IN-CLASS), or any of a possibly-empty
  implementation-defined list of other metaclasses.  COMPILE-FILE will
  only call MAKE-LOAD-FORM once for any given object (compared with EQ)
  within a single file.

  It is valid for user programs to call MAKE-LOAD-FORM in other
  circumstances, providing the argument's metaclass is not BUILT-IN-CLASS
  or a subclass of BUILT-IN-CLASS.

  Define a new function named MAKE-LOAD-FORM-SAVING-SLOTS, which takes
  one required argument and one optional argument and returns two
  values.  This can be useful in user-written MAKE-LOAD-FORM methods.
  The first argument is the object.  The optional second argument is a
  list of the names of the slots to preserve; it defaults to all of the
  local slots.  MAKE-LOAD-FORM-SAVING-SLOTS returns forms that construct
  an equivalent object using MAKE-INSTANCE and SETF of SLOT-VALUE for
  slots with values, or SLOT-MAKUNBOUND for slots without values, or
  using other functions of equivalent effect.
  MAKE-LOAD-FORM-SAVING-SLOTS returns two values, thus it can deal with
  circular structures.  MAKE-LOAD-FORM-SAVING-SLOTS works for any object
  of metaclass STANDARD-CLASS or STRUCTURE-CLASS.  Whether the result is
  useful in an application depends on whether the object's type and slot
  contents fully capture the application's idea of the object's state.

  MAKE-LOAD-FORM of an object of metaclass STANDARD-CLASS or
  STRUCTURE-CLASS for which no user-defined method is applicable signals
  an error.  It is valid to implement this either by defining default
  methods on STANDARD-OBJECT and STRUCTURE-OBJECT that signal an error
  or by having no applicable method for those classes.


Examples:

  ;; Example 1
  (defclass my-class ()
     ((a :initarg :a :reader my-a)
      (b :initarg :b :reader my-b)
      (c :accessor my-c)))
  (defmethod shared-initialize ((self my-class) ignore &rest ignore)
    (unless (slot-boundp self 'c)
      (setf (my-c self) (some-computation (my-a self) (my-b self)))))
  (defmethod make-load-form ((self my-class))
    `(make-instance ',(class-name (class-of self))
                    :a ',(my-a self) :b ',(my-b self)))

  In this example, an equivalent instance of my-class is reconstructed
  by using the values of two of its slots.  The value of the third slot
  is derived from those two values.

  Another way to write the last form in the above example would have been

  (defmethod make-load-form ((self my-class))
     (make-load-form-saving-slots self '(a b)))

  ;; Example 2
  (defclass my-frob ()
     ((name :initarg :name :reader my-name)))
  (defmethod make-load-form ((self my-frob))
    `(find-my-frob ',(my-name self) :if-does-not-exist :create))

  In this example, instances of my-frob are "interned" in some way.
  An equivalent instance is reconstructed by using the value of the
  name slot as a key for searching existing objects.  In this case
  the programmer has chosen to create a new object if no existing
  object is found; alternatively she could have chosen to signal an
  error in that case.

  ;; Example 3
  (defclass tree-with-parent () ((parent :accessor tree-parent)
                                 (children :initarg :children)))
  (defmethod make-load-form ((x tree-with-parent))
    (values
      ;; creation form
      `(make-instance ',(class-of x) :children ',(slot-value x 'children))
      ;; initialization form
      `(setf (tree-parent ',x) ',(slot-value x 'parent))))

  In this example, the data structure to be dumped is circular, because
  each parent has a list of its children and each child has a reference
  back to its parent.  Suppose make-load-form is called on one object in
  such a structure.  The creation form creates an equivalent object and
  fills in the children slot, which forces creation of equivalent
  objects for all of its children, grandchildren, etc.  At this point
  none of the parent slots have been filled in.  The initialization form
  fills in the parent slot, which forces creation of an equivalent
  object for the parent if it was not already created.  Thus the entire
  tree is recreated at load time.  At compile time, MAKE-LOAD-FORM is
  called once for each object in the true.  All of the creation forms
  are evaluated, in unspecified order, and then all of the
  initialization forms are evaluated, also in unspecified order.

  ;; Example 4
  (defstruct my-struct a b c)
  (defmethod make-load-form ((s my-struct))
     (make-load-form-saving-slots s))

  In this example, the data structure to be dumped has no special
  properties and an equivalent structure can be reconstructed
  simply by reconstructing the slots' contents.


Rationale:

  Only the programmer who designed a class can know the correct
  way to reconstruct objects of that class at load time, therefore
  the reconstruction should be controlled by a generic function.
  Using EVAL as the interface for telling LOAD what to do provides
  full generality.

  MAKE-LOAD-FORM returns two values so that circular structures can
  be handled.  If CONSTANT-CIRCULAR-COMPILATION is rejected,
  MAKE-LOAD-FORM will only return one value, although implementations
  that make an extension to support circular constants will probably
  also make the extension to accept two values from MAKE-LOAD-FORM.

  The default for class objects and structures is to signal an error,
  rather than picking some particular object reconstruction technique,
  because no reconstruction technique is appropriate for all objects.
  It only takes two lines of code, as in example 4, to instruct the
  compiler to use the technique that most often has been suggested
  as the default.

  MAKE-LOAD-FORM has a natural resemblance to PRINT-OBJECT, as a hook
  for the programmer to control the system's actions.

  The order of evaluation rules for creation and initialization forms
  eliminate the possibility of partially initialized objects in the
  absence of circular structures, and reduce it to the minimum possible
  in the presence of circular structures.  This allows nodes in
  non-circular structures to be built out of fully initialized subparts.


Current practice:

  Symbolics Flavors has something like this, but under a different name.
  The name Symbolics uses is not suitable for standardization.

  JonL reports that Lucid is getting more and more requests for this.

Cost to Implementors:

  This seems like only a few one-line changes in the compiled-code
  file writer and reader.  MAKE-LOAD-FORM-SAVING-SLOTS is a couple
  dozen lines of code, assuming the presence of the CLOS metaobject
  protocol or an implementation-dependent equivalent.

Cost to Users:

  None.

Cost of non-adoption:

  Serious impairment of the ability to use extended-type objects.  Each
  implementation will probably make up its own version of this as an
  extension.

Performance impact:

  None.

Benefits:

  See Cost of non-adoption.

Esthetics:

  No significant positive or negative impact.

Discussion:

  It would be possible to define an additional level of protocol that
  allows multiple classes to contribute to the reconstruction of an
  object, combining initialization arguments contributed by each class.
  Since a user can easily define that in terms of MAKE-LOAD-FORM without
  modifying the Lisp system, it is not being proposed now.

  Any type that has a read syntax is likely to appear as a quoted
  constant or inside a quoted constant.  Pathnames are one example, user
  programs often define others.  Also many implementations provide a way
  to create a compiled-code file full of data (rather than compiled Lisp
  programs), and such data probably include extended-type objects.

  Moon supports this.  David Gray and John Rose made major contributions
  to the discussion that produced this improved version 2 proposal.

∂04-Apr-89  1217	CL-Cleanup-mailer 	Issue: LOAD-TRUENAME 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:17:37 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571207; Tue 4-Apr-89 15:17:27 EDT
Date: Tue, 4 Apr 89 15:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME
To: CL-Cleanup@SAIL.Stanford.EDU
cc: Loeffler@MCC.Com
Message-ID: <890404151703.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say that Moon wanted some other variables. I wrote this up as
an amendment, but neither the amendment nor the proposal was ever voted on.

Moon mailed out a version 2 but then withdrew it in favor of my amendment.

The text of my amendment was:

 Proposed amendment to LOAD-TRUENAME			KMP 3/30/89

  Also introduce new variables:
 
  *LOAD-PATHNAME*
 
  This special variable is initially NIL but is bound by LOAD
  to hold a pathname which represents the filename given as the
  first argument to LOAD.  That is, (PATHNAME arg1).
 
  *COMPILE-FILE-PATHNAME*
 
  This special variable is initially NIL but is bound by COMPILE-FILE
  to hold a pathname which represents the filename given as the
  first argument to COMPILE-FILE.  That is, (PATHNAME arg1).
 
  Rationale:

   The truename may be useful to tell the real file being loaded,
   but sometimes information about the link names or logical devices
   traversed is important, too.

   Note that these new variables alone are not adequate since
   TRUENAME on these pathnames might not yield the value of the
   -TRUENAME* variables if the file has been deleted or protected
   since the open occurred (in some implementations).

The problem is whether the values of the -pathname variables is the
original argument or the merged, defaulted value. Moon thinks it
should be the latter. I think there are arguments for either
one, but also think that this sub-issue is "in the noise" and 
should not hold up progress. Loeffler volunteered to work on this.

By a 14-1 vote, we deferred this to the next meeting.

∂04-Apr-89  1219	CL-Cleanup-mailer 	Issue: LOCALLY-TOP-LEVEL  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:19:22 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571209; Tue 4-Apr-89 15:19:16 EDT
Date: Tue, 4 Apr 89 15:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOCALLY-TOP-LEVEL
To: CL-Cleanup@SAIL.Stanford.EDU
cc: Dick@Wheaties.AI.MIT.EDU
Message-ID: <890404151849.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

[Waters added for sake of amusing story at end.]

My notes say this passed unanimously.

I also noted that this took 15 seconds to vote in. In fact, we did it
while in the middle of PRETTY-PRINT-INTERFACE sort of at ``interrupt level''
in a way that confused Mary's taking of the minutes and we -almost- got
the pretty printer marked as voted in because she didn't realize we'd 
shifted topics.

∂04-Apr-89  1219	CL-Cleanup-mailer 	Issue: LOOP-AND-DISCREPANCY    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:19:40 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571210; Tue 4-Apr-89 15:19:35 EDT
Date: Tue, 4 Apr 89 15:19 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOOP-AND-DISCREPANCY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404151910.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say this passed 14-0.

∂04-Apr-89  1221	CL-Cleanup-mailer 	Issue: MACRO-ENVIRONMENT-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:21:23 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571211; Tue 4-Apr-89 15:21:17 EDT
Date: Tue, 4 Apr 89 15:20 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MACRO-ENVIRONMENT-EXTENT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152045.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say...

 Gregor says "the cartel" thinks CLOS is unaffected by this proposal.

 In a straw poll, we checked which option people favor.
   11 DYNAMIC
    7 `not DYNAMIC'
 It later became clear that some people thought DYNAMIC-WITH-COPIER
 was in the `not DYNAMIC' set.

 In spite of the confusion, option DYNAMIC passed 15-1.

 A motion to replace option DYNAMIC with option DYNAMIC-WITH-COPIER
 failed 1-12.

∂04-Apr-89  1221	CL-Cleanup-mailer 	Issue: MAKE-STRING-FILL-POINTER
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:21:38 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571212; Tue 4-Apr-89 15:21:32 EDT
Date: Tue, 4 Apr 89 15:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-STRING-FILL-POINTER
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152107.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

Someone (GZ?) objected that this would change the result type from MAKE-STRING
from being a simple-string, and would break type inferencing code.

It was agreed that this should be withdrawn.

∂04-Apr-89  1222	CL-Cleanup-mailer 	Issue: PACKAGE-FUNCTION-CONSISTENCY 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:22:38 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571216; Tue 4-Apr-89 15:22:10 EDT
Date: Tue, 4 Apr 89 15:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152140.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was on the agenda but not discussed.

Since it is just a clarification, I assume it could still come
up at the next meeting.

∂04-Apr-89  1226	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:25:09 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571228; Tue 4-Apr-89 15:25:06 EDT
Date: Tue, 4 Apr 89 15:24 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-LOGICAL
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152441.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was deferred to the next meeting.

Moon says that Masinter "tried manfully" to encourage him to write up a
proposal, but I doubt anyone really expects it to happen.

∂04-Apr-89  1227	CL-Cleanup-mailer 	Issue: PATHNAME-PRINT-READ
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:27:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571237; Tue 4-Apr-89 15:27:19 EDT
Date: Tue, 4 Apr 89 15:26 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-PRINT-READ
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152654.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was deferred from Tuesday to Thursday but then didn't come
around for discussion due to lack of time.

I guess I think it's possible that this could still come up at
the next meeting since it can at least be argued to be a clarification.
Others might disagree though.

∂04-Apr-89  1227	CL-Cleanup-mailer 	Issue: PATHNAME-CANONICAL-TYPE 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:23:18 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571220; Tue 4-Apr-89 15:23:07 EDT
Date: Tue, 4 Apr 89 15:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-CANONICAL-TYPE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152241.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was identified as `medium' importance in the pathname world
and deferred to the next meeting.

∂04-Apr-89  1231	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:28:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571239; Tue 4-Apr-89 15:28:55 EDT
Date: Tue, 4 Apr 89 15:28 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152831.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was identified as `important' and deferred to the
next meeting.

∂04-Apr-89  1232	CL-Cleanup-mailer 	Issue: PEEK-CHAR-READ-CHAR-ECHO
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:31:23 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571244; Tue 4-Apr-89 15:31:19 EDT
Date: Tue, 4 Apr 89 15:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PEEK-CHAR-READ-CHAR-ECHO
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153055.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

Kim Barrett mentioned again that he wants to reopen this, but nothing
was done at this meeting.

∂04-Apr-89  1233	CL-Cleanup-mailer 	Issue: PRETTY-PRINT-INTERFACE  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:31:42 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571245; Tue 4-Apr-89 15:31:40 EDT
Date: Tue, 4 Apr 89 15:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153114.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say this was deferred to the next meeting by a vote of N-2.

∂04-Apr-89  1235	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-CASE 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:24:06 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571225; Tue 4-Apr-89 15:23:56 EDT
Date: Tue, 4 Apr 89 15:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-CASE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152331.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was identified as `important' and deferred to
the next meeting (with explicit exception to cut-off
date on 18-0 vote).

∂04-Apr-89  1238	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:36:44 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571257; Tue 4-Apr-89 15:36:39 EDT
Date: Tue, 4 Apr 89 15:36 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: CL-Cleanup@SAIL.Stanford.EDU
cc: JAR@AI.AI.MIT.EDU
Message-ID: <890404153614.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say...

 KMP made a friendly amendment to clarify the status of undeclared
 free variables (as undefined). The text of the amendment was:
 -----
   Proposed amendment to PROCLAIM-LEXICAL    KMP 3/30/89

   Add:   Referencing a free variable that is neither proclaimed
	  nor declared LEXICAL nor SPECIAL has undefined
	  consequences.

   Rationale:

    This enables existing implementations to persist in permitting,
    for example,

	(SETQ X 3)

    without defining X as lexical or special, yet allows those
    implementations that want to warn about

	(DEFUN F (X) (+ X Y))

    when Y is undeclared/proclaimed to legitimately do so.
 ----- 

 GZ wanted an amendment that would make it an error to use the LEXICAL
 declaration when there was not a lexically visible binding to which
 it might refer.  Her amendment failed 5-12.
 
 The proposal (with friendly amendment by KMP but without GZ's 
 amendment) finally failed 6-11.

∂04-Apr-89  1238	CL-Cleanup-mailer 	Issue: READ-CASE-SENSITIVITY   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:38:11 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571263; Tue 4-Apr-89 15:37:46 EDT
Date: Tue, 4 Apr 89 15:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: READ-CASE-SENSITIVITY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153716.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was deferred to the next meeting by a 13-3 vote.
The drafters were requested to present only a single alternative.

∂04-Apr-89  1240	CL-Cleanup-mailer 	Issue: READ-DELIMITED-LIST-EOF 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:38:46 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571265; Tue 4-Apr-89 15:38:36 EDT
Date: Tue, 4 Apr 89 15:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: READ-DELIMITED-LIST-EOF
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153809.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

This issue was mentioned but was not on my list of possible topics.
No action was taken.

Since it's probably a clarification (?) and I assume it might still
come up later.

∂04-Apr-89  1242	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 6)    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:41:09 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571273; Tue 4-Apr-89 15:41:04 EDT
Date: Tue, 4 Apr 89 15:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 6)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: DLA@JASPER.SCRC.Symbolics.COM
Message-ID: <890404154038.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say I suggested friendly amendments to change "VREF" to "AREF"
and  "it none" to "none" in the NSUBSTITUTE-xxx part.

Then the amended proposal was passed 16-1.

∂04-Apr-89  1244	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:24:23 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571227; Tue 4-Apr-89 15:24:18 EDT
Date: Tue, 4 Apr 89 15:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152354.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was deferred to the next meeting.

∂04-Apr-89  1244	CL-Cleanup-mailer 	Issue: SETF-MULTIPLE-STORE-VARIABLES
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:44:43 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571286; Tue 4-Apr-89 15:44:42 EDT
Date: Tue, 4 Apr 89 15:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-MULTIPLE-STORE-VARIABLES
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154416.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was on the agenda but never gotten to.
I think it might come up at the next meeting since it's mostly just a clarification.

∂04-Apr-89  1249	CL-Cleanup-mailer 	Issue: SYMBOL-MACROLET-SEMANTICS    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:45:39 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 571287; 4 Apr 89 15:45:32 EDT
Date: Tue, 4 Apr 89 15:45 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYMBOL-MACROLET-SEMANTICS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154506.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say...

 People wanted PSETQ added with SETQ in the list of things SYMBOL-MACROLET
 hacks specially.

 RWK wants changes to deal with *MACRO-EXPANSION-HOOK* to clarify how it gets
 called when PSETQ and SETQ are used.  He seemed to want it called with the
 SETF expander and a consed-up SETF form. I'd rather it be called with a special
 magic expander and the actual SETQ form.

 RPG wants to flush SYMBOL-MACROLET altogether and have people just use 
 WITH-SLOTS. Many people didn't want to give up the flexibility of
 SYMBOL-MACROLET.

 A vote on Version 6 "as is" passed 16-2.

 A straw poll was taken on the question ``should we ask RPG to draft a proposal
 for flushing SYMBOL-MACROLET.''  On a 6-8 vote, we opted not to write such
 a proposal. [That doesn't preclude him from doing it anyway, of course.]

∂04-Apr-89  1249	CL-Cleanup-mailer 	Issue: THE-AMBIGUITY 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:46:09 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571288; Tue 4-Apr-89 15:46:07 EDT
Date: Tue, 4 Apr 89 15:45 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: THE-AMBIGUITY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154542.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was on the agenda but didn't come up.
Being a clarification, I assume it might come up next meeting.

∂04-Apr-89  1252	CL-Cleanup-mailer 	Issue: TIME-ZONE-NON-INTEGER   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:46:43 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571290; Tue 4-Apr-89 15:46:41 EDT
Date: Tue, 4 Apr 89 15:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154616.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say...

 We managed to waste lots of valuable time on this.

 Haflich seemed to want to use incredibly large negative time zones in
 order to reason about the first century A.D. or some such thing. He
 asked ``Can I make the time zone be most-positive-bignum*5?'' JonL 
 responded ``most-positive-bignum--my favorite number!''

 Moon proposed time zones be multiples of 1/3600 so that they were
 even numbers of seconds.  (Some people suspected this was a subtle
 marketing ploy for Symbolics.) This amendment was accepted 11-0.

 Pitman proposed that we limit time zone to the range [-24,24], inclusive.
 The inclusive was to allow countries to disagree on which end was open,
 since it was agreed that the correct value here is a largely political,
 rather than technical issue.  The amendment was accepted 8-5.

 The full proposal with both amendments passed 18-0.

∂04-Apr-89  1253	CL-Cleanup-mailer 	Issue: PATHNAME-SYNTAX-ERROR-TIME   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:29:16 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571240; Tue 4-Apr-89 15:29:14 EDT
Date: Tue, 4 Apr 89 15:28 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYNTAX-ERROR-TIME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152844.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was deferred to the next meeting.

∂04-Apr-89  1256	CL-Cleanup-mailer 	Issue: PATHNAME-WILD 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:29:31 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571241; Tue 4-Apr-89 15:29:26 EDT
Date: Tue, 4 Apr 89 15:29 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152902.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was deferred to the next meeting.

∂04-Apr-89  1258	CL-Cleanup-mailer 	Issue: WITH-COMPILATION-UNIT   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:49:03 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571301; Tue 4-Apr-89 15:48:50 EDT
Date: Tue, 4 Apr 89 15:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: WITH-COMPILATION-UNIT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154825.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say...

 Users wanting to write a portable DEFSYSTEM want this.
 
 This passed 11-6 with an amendment to say it defers "warnings" rather
 than "actions" and with an amendment to say it does not apply to the
 COMPILE function (only to COMPILE-FILE).

∂04-Apr-89  1301	CL-Cleanup-mailer 	Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:32:04 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 571246; 4 Apr 89 15:32:01 EDT
Date: Tue, 4 Apr 89 15:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153136.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say this was deferred from Tuesday to Thursday but then didn't
come up for discussion.

Being a clarification, I expect it to come up at the next meeting.

∂04-Apr-89  1301	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (version 7) 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  13:01:17 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571323; Tue 4-Apr-89 16:01:09 EDT
Date: Tue, 4 Apr 89 16:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT (version 7)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890404200056.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

This contains the amendments that were voted in at the X3J13 meeting last week.
I also edited the rationale and the examples to make them consistent with the
amended proposal.  The MINIMAL proposal here passed 11-5.

Issue:         EXIT-EXTENT

References:    CATCH, THROW (p 142),
               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).
             
Related issues: UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
                by this one.

Category:      CLARIFICATION

Edit history:  ... Version 5 of UNWIND-PROTECT-NON-LOCAL-EXIT, 23-May-88 ...
               Version 1, 5-Sep-88, by Moon, for discussion
               Version 2, 1-Oct-88, by Masinter, minor edits
               Version 3, 7-Oct-88, by Moon, wording improvements
               Version 4,  7-Dec-88, by Masinter, add MEDIUM from
                                        UNWIND-PROTECT-NON-LOCAL-EXIT, discussion.
               Version 5, 12-Dec-88, Masinter, clarify MINIMAL allows MEDIUM
               Version 6,  8-Jan-89, Masinter, fix some bugs
               Version 7,  4-Apr-89, Moon, amend per X3J13 Mar-89, and make
                                rationale and examples consistent with that

Problem description:

CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends. 
For example, at what point is it no longer possible to RETURN-FROM
a particular BLOCK?

An "exit" refers to a point from which control can be transferred.
For a THROW or RETURN-FROM, the "exit" is the corresponding CATCH
or BLOCK body. For a GO, the "exit" is the form within the TAGBODY
which was being executed at the time the GO is performed.

The extent of an exit is dynamic; it is not indefinite. The extent
of an exit begins when the corresponding form (CATCH, BLOCK or TAGBODY
clause) is entered.  When the extent of an exit has ended, it is no
longer legal to return from it.

The extent of an exit is not the same thing as the scope of the
designator by which the exit is identified. For example, a BLOCK
name has lexical scope but the extent of its exit is dynamic; the
scope of a CATCH tag could differ from the extent of the CATCH's
return point. (That's part of what is at issue here.)

The ambiguity at issue arises for the case where there are transfers
of control from the cleanup clauses of an UNWIND-PROTECT.

When a transfer of control is initiated by GO, RETURN-FROM or THROW,
a variety of events occur before the transfer of control is complete.
In particular, 

(a) the cleanup clauses of any intervening UNWIND-PROTECT clauses
    are evaluated,

(b) intervening dynamic bindings of special variables and catch tags
    are undone,

(c) intervening exits are "abandoned", i.e., their extent ends and it
    is no longer legal to attempt to transfer control through them,

(d) the extent of the exit being invoked ends,

(e) control is finally passed to the target.

The order of these events is not explicit in CLtL, however. The 
implementation note on p.142 gives a clue about the interweaving
of (a) and (b), but there are differing opinions about the times
at which (c) and (d) may occur. In particular,

Is it legal for an implementation to end the extent of all 
intervening exits before processing the cleanup clauses of intervening 
UNWIND-PROTECTs?

What is the dynamic context at the time UNWIND-PROTECT clauses are 
evaluated: how is the unwinding of dynamic bindings intertwined with 
evaluation of UNWIND-PROTECT cleanup clauses? 

Proposal (EXIT-EXTENT:MINIMAL):

The extent of an exit being "abandoned" because it is being passed over
ends as soon as the transfer of control is initiated. That is, the
event (c) occurs at the beginning of the initiation of the transfer of
control. In the language of the implementation note on p.142, the
extent ends at the beginning of the second pass.  It is an error to
attempt a transfer of control to an exit whose dynamic extent has
ended.

The event (d) occurs at the end of the transfer of control.

Otherwise, events (a) and (b)--the undoing of dynamic binding of special
variables and CATCH tags, and the execution of UNWIND-PROTECT cleanup
clauses--are performed in the order corresponding to the reverse order
in which they were established, as implied by the implementation note
on p.142. The effect of this is that the cleanup clauses of an UNWIND-PROTECT
will see the same dynamic bindings of variables and CATCH tags as were
visible when the UNWIND-PROTECT was entered.

This proposal is called "minimal" because it gives exits the smallest
extent consistent with CLtL, except that event (d) occurs later than
CLtL requires.  A program that presumed a longer extent would be in
error. Implementations may support longer extents for exits than is
required by this proposal; in particular, an implementation which
allowed the larger extent of the MEDIUM proposal below would still
conform.

Proposal (EXIT-EXTENT:MEDIUM):

The events of (a), (b), (c) and (d) are interwoven in the reverse 
order in which they were established. In particular, the extent of 
a passed-over exit ends when control reaches a frame that was 
established before the exit was established.  

In particular, it is legal, during the evaluation of an UNWIND-PROTECT 
cleanup form executed because of a non-local transfer of control, to
initiate a new transfer of control to an exit intervening between the 
UNWIND-PROTECT and the original target; the original processing of 
transfer of control is abandoned.  

Examples:

;; Error under either proposal: BLOCK exits normally before RETURN
(funcall (block nil #'(lambda () (return))))

;; Error under either proposal: normal exit before GO
(let ((a nil)) 
  (tagbody t (setq a #'(lambda () (go t))))
  (funcall a))

;; Error under either proposal: TAGBODY is passed over, before GO
(funcall (block nil
           (tagbody a (return #'(lambda () (go a))))))


;;returns 2 under MEDIUM and MINIMAL, was error under MINIMAL version 6
(block nil   
  (unwind-protect (return 1)
    (return 2)))

;;returns 2 under MEDIUM, is error under MINIMAL
(block a    
  (block b
    (unwind-protect (return-from a 1)
      (return-from b 2))))

;; returns 2 under MEDIUM and MINIMAL, was error under MINIMAL version 6
(catch nil 
  (unwind-protect (throw nil 1)
    (throw nil 2)))

;; returns 2 under MEDIUM, is error under MINIMAL
;; because the catch of B is passed over by
;; the first THROW, hence portable programs must assume its dynamic extent
;; is terminated.  The binding of the catch tag is not yet disestablished
;; and therefore it is the target of the second throw.
(catch 'a
  (catch 'b
    (unwind-protect (throw 'a 1)
      (throw 'b 2))))


;; the following was an error under MINIMAL version 6; the extent of
;; the inner catch terminates as soon as the THROW commences, even
;; though it remains in scope. Thus, the THROW of :SECOND-THROW
;; sees the inner CATCH, but its extent has ended.
;; under MEDIUM and MINIMAL version 7,
;; it prints "The inner catch returns :SECOND-THROW"
;; and then returns :OUTER-CATCH.
(catch 'foo
        (format t "The inner catch returns ~s.~%"
                (catch 'foo
                    (unwind-protect (throw 'foo :first-throw)
                        (throw 'foo :second-throw))))
        :outer-catch))


;; Following returns 10 under either proposal.  The inner
;; CATCH of A is passed over, but because that CATCH
;; is disestablished before the THROW to A is executed,
;; it isn't seen.
(catch 'a
  (catch 'b
    (unwind-protect (1+ (catch 'a (throw 'b 1)))
      (throw 'a 10))))


;; Following is an error under MINIMAL because the extent of
;; the (CATCH 'BAR ...) exit ends when the (THROW 'FOO ...)
;; commences.
;; Under MEDIUM, the pending exit to tag FOO is discarded by the
;; second THROW to BAR and the value 4 is transferred to
;; (CATCH 'BAR ...), which returns 4. The (CATCH 'FOO ...)
;; then returns the 4 because its first argument has returned
;; normally.  XXX is not printed.

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

 
;; Following returns 4 under either proposal; XXX is not printed.
;; The (THROW 'FOO ...) has no effect on the scope of the BAR
;; catch tag or the extent of the (CATCH 'BAR ...) exit.
(CATCH 'BAR
    (CATCH 'FOO
        (UNWIND-PROTECT (THROW 'FOO 3)
          (THROW 'BAR 4)
          (PRINT 'XXX))))


;;The following are legal and print 5 under either proposal:
    (block nil
      (let ((x 5))
        (declare (special x))
        (unwind-protect (return)
          (print x))))          

    (block nil
      (let ((x 5))
        (declare (special x))
        (unwind-protect
            (if (test) (return))
          (print x))))  


Rationale:

For MINIMAL: Giving exits the smallest extent consistent with CLtL
maximizes freedom for implementations; there are few applications,
if any, that require a longer extent.  Delaying event (d) until
the transfer of control is completed allows multiple attempts to
exit from a single exit, if the first attempt is interrupted,
possibly by an error.

For MEDIUM: Giving exits a longer extent has cleaner semantics.

Current practice:

Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target BLOCK or CATCH 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.

In some implementations, it is possible for a throw or non-local exit
to be effectively "stopped" by an UNWIND-PROTECT cleanup clause that
performs a non-local transfer of control to a passed-over exit.

Some implementations crash or otherwise generate garbage code for
non-local exits from cleanup clauses of UNWIND-PROTECT.

Cost to Implementors:

No currently valid implementation will be made invalid by the MINIMAL
proposal. Some implementors may wish to add error checks if they
do not already have them.

MEDIUM would have a high cost for those implementations that currently
have shorter extent.

Cost to Users:

Most user programs don't do this, so there is likely little cost
of converting existing code in any case. In any case, current implementations
differ enough that this issue ostensibly does not
affect current portable programs. Some users might have code that
relies on the "unstoppable loops" that can be created with the MEDIUM
proposal.

Benefits:

Either proposal would make Common Lisp more precisely defined.

Cost of non-adoption :

The semantics of exits will remain ambiguous.

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:

This issue is controversial. It was first discussed under the issue 
named UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT. The issue was recast as
the more global one of "extent of exits" rather than the specific 
one of "what happens if a cleanup in an UNWIND-PROTECT does a non-
local exit", but the problem cases for both topics are the same.

The goal of the MINIMAL proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. The MEDIUM proposal
defines the extent of an exit to end at the last moment possible
within some particular reference implementation.  It has
a cost to implementors whose implementation is not identical to the
reference implementation.  Another alternative proposal, not considered
here, would duck the issue by outlawing all non-local exits from UNWIND-PROTECT
cleanup forms. That alternative would have a substantial cost to some users.

Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.

An argument for the MEDIUM proposal was made based on the example:

  (block foo
    (block bar
      (unwind-protect
          (return-from foo 'foo)
        (return-from bar 'bar))))

Since there is no reason for FOO and BAR not to be treated interchangeably,
calling this an error would be inappropriate. 

It was argued that the MINIMAL proposal is equivalent to practically
outlawing non-local exits from UNWIND-PROTECT cleanup clauses, because
there is no general way to determine the target of the non-local exit
that caused the cleanup clause to be invoked. 

The following example was offered as an argument against MINIMAL. Given:

    (block nil
      (handler-case
          (unwind-protect (return)
            (error "foo"))             ;probably an error, under the proposal
        (error ()
          (print "foo"))))

If the ERROR handler has the same scope and extent a CATCH in the same place
would have (and that seems reasonable, though I'm not certain that the
condition system specifically requires that interpretation), then the handler
will be apparent to the call to ERROR, but will no longer be a valid target
(its extent was exited by the RETURN in the UNWIND-PROTECT body).

The extent of an object with dynamic extent is the extent of the form 
which created it.  Code which is executed "within" that form is within
the extent of the object(s).  This applies to all dynamic objects, such
as special variable bindings, not just exits.  Actually, I think the intent
of the implementation note on p.142 is fairly clear and supports this
interpretation.  The supposedly ambiguous use of "frame" should be read
as something like "form which establishes a dynamic extent".  It might be
clearer if the last sentence were changed to read something like:

"On the second pass the stack is actually unwound.  Each form which establishes
a dynamic extent is undone in reverse order of creation until the matching
CATCH is reached.  The meaning of undoing a form depends on the type of form.
For UNWIND-PROTECT, it means executing the cleanup forms.  For CATCH it means
removing the CATCH tag.  For dynamic bindings it means undoing the binding,
restoring the previous saved value. {This is not an exhaustive listing of the
possibilities.}"

∂04-Apr-89  1301	CL-Cleanup-mailer 	Issue: PRINT-CIRCLE-SHARED
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:32:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571250; Tue 4-Apr-89 15:32:49 EDT
Date: Tue, 4 Apr 89 15:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRINT-CIRCLE-SHARED
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153225.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was deferred from Tuesday to Thursday but then didn't come up
for discussion.

Since some people (myself included, I think) consider this almost
a clarification, my feeling is that it could still come up at the
next meeting.

∂04-Apr-89  1304	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:39:35 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571267; Tue 4-Apr-89 15:39:27 EDT
Date: Tue, 4 Apr 89 15:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE
To: CL-Cleanup@SAIL.Stanford.EDU
cc: Cassels@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890404153856.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say...

 Barmar moved we accept ``both proposals'' (since one was obviously trying
 to include the other, but the wording didn't really make that clear).

 The motion to approve both passed 12-3.

∂04-Apr-89  1309	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:41:57 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571274; Tue 4-Apr-89 15:41:50 EDT
Date: Tue, 4 Apr 89 15:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154124.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

My notes say...

 A motion to reconsider this issue was made.
 The motion to reconsider passed 5-4.

 A motion was made to deprecate rather than to remove.
  Pitman proposed an amendment to make these macros instead of functions,
  thinking that REQUIRE and PROVIDE were part of the magic functions we
  were trying to eliminate.  He tried to withdraw the motion to amend
  when someone observed that they are not supposed to be specially treated
  but others still wanted them to be macros for some reason. Anyway, the
  amendment failed on a vote of 4-11.
 The original motion to deprecate instead of remove was voted on.
 The first count was 7-7, but someone asked for a recount.
 The next count was 7-8, but someone was late raising his hand and didn't
 think his vote had counted right.
 The next vote was 8-7. At this point, Pitman requested a roll call vote
 so there would be no dispute later.
 The results were:
  IBM		   No
  DEC		   Yes
  RWK(!)	   Yes
  TI		   No
  IIM		   Yes
  Univ of Utah     No
  Apple		   Yes
  Franz		   Yes
  Think		   Yes
  Encore	   Yes
  Honeywell	   No
  Johnson Controls No
  MCC		   No
  Xerox		   No
  Lucid		   Yes
  SMBX		   No
 The motion failed 8-8, so the result voted on at the previous meeting stands.

∂04-Apr-89  1309	CL-Cleanup-mailer 	Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:48:24 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571297; Tue 4-Apr-89 15:48:21 EDT
Date: Tue, 4 Apr 89 15:47 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154756.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

Deferred until next meeting.

There was some ``off-line'' discussion of slot-unbound with no real resolution.
That part of the issue promises to be a controversial one.

Moon seems to think that one idea that had some support is to say that the
system-defined method "should signal an error", depending on the safety level
of the original call to SLOT-VALUE, so the generic function is only called if
the SLOT-VALUE is safe or user-defined methods might be applicable. I haven't
had time to decide whether I understand this enough to either agree or disagree.

∂04-Apr-89  1309	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  12:47:07 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571292; Tue 4-Apr-89 15:46:55 EDT
Date: Tue, 4 Apr 89 15:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TYPE-OF-UNDERCONSTRAINED
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154630.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

Some people had some concerns about a previous version of this that passed.
We wanted to reconsider this, but didn't have the right hardcopy.
No action was taken. This will probably come up next meeting.

∂04-Apr-89  1324	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 1 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  13:24:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571355; Tue 4-Apr-89 16:23:51 EDT
Date: Tue, 4 Apr 89 16:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8904041727.AA19101@defun.utah.edu>
Message-ID: <19890404202338.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

Comments on current practice:

This is very different from Symbolics Genera current practice, which
I would describe as follows:

First, if a function A has a DYNAMIC-EXTENT declaration for one of its
parameters F, and a caller of A passes a function B as the argument
corresponding to the parameter F, then B is used in a "downward" way.
Calling a function directly or via FUNCALL or APPLY is a "downward" use
too.  If every use of a function is "downward", then the compiler
implements the function with dynamic extent (provided the function is
not globally named, but is only locally named or not named at all, i.e.
defined with FLET, LABELS, or LAMBDA).  We currently use a different
name for the declaration, instead of DYNAMIC-EXTENT, but that is
unimportant.

Does the compiler committee's model of compilation permit compilation of
one function to be affected by declarations in the current definition of
another function that it calls?  I hope so.

Second, if a function has a SYS:DOWNWARD-FUNCTION declaration in front of
its body, then the function is implemented with dynamic extent regardless
of whether the compiler thinks all uses are "downward".  This feature is
used less often than the first feature, but is still used pretty often.
An example would be

  (funcall (computation-that-returns-a-function)
           (function (lambda (...)
                       (declare (sys:downward-function))
                       ...))
           ...other args...)

Here the function being called is not known at compile time, so there
is no place from which to obtain a DYNAMIC-EXTENT declaration.  In
your proposal, the declaration cannot be made unless the function is
given a name, so this example would have to be rewritten as:

  (flet ((dummy-name (...)
           ...))
    (declare (dynamic-extent-function dummy-name))
    (funcall (computation-that-returns-a-function)
             (function dummy-name)
             ...other args...))

Third, there is a variation of the first feature by which a function can
declare that all of its arguments are used "downward"; this is
especially useful for declaring arguments that are elements of a list
that is the value of an &rest parameter, since there is no parameter
name corresponding to those arguments.  We do this by using * instead of
a parameter name, but I don't see any way to map that into the
DYNAMIC-EXTENT declaration.  However, if we were willing to say that the
&rest list also had to have dynamic extent in this case, then a
DYNAMIC-EXTENT declaration of the &rest parameter would imply downward
use of the functions, since otherwise they would not be OIPs (in the
language of the amended DYNAMIC-EXTENT proposal that we just passed).
So I don't think we need this third feature.

The fact that your proposal is different from Symbolics Genera current
practice doesn't mean the proposal is wrong, after all it is also very
different from the current practices of the two implementations listed
in the proposal.  But we should think hard about dynamic extent for
anonymous lambdas, which can be quite important in practice.

On a sillier note, should we minimize proliferation of names by
replacing

   (declare (dynamic-extent-function name))

with

   (declare (dynamic-extent #'name)) ?

This is a serious proposal, although I suspect that some people
will think it is a stupid idea.

∂04-Apr-89  1531	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-PRINT-NAME (not COPY-SYMBOL-COPY-PRINT-NAME)   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89  15:31:00 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571454; Tue 4-Apr-89 18:30:52 EDT
Date: Tue, 4 Apr 89 18:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-PRINT-NAME (not COPY-SYMBOL-COPY-PRINT-NAME)
To: CL-Cleanup@SAIL.Stanford.EDU
Supersedes: <890404113419.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890404183026.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Tue, 4 Apr 89 11:34 EDT
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
    Subject: Issue: COPY-SYMBOL-COPY-PRINT-NAME
    To: CL-Cleanup@SAIL.Stanford.EDU
    Message-ID: <890404113419.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

    My notes say this passed unanimously.

The issue name was COPY-SYMBOL-PRINT-NAME, of course.
Sorry for the typo. Hope this didn't confuse anyone.

∂04-Apr-89  2058	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 1 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Apr 89  20:58:35 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA17233g; Tue, 4 Apr 89 20:52:50 PDT
Received: by bhopal id AA11925g; Tue, 4 Apr 89 20:59:22 PDT
Date: Tue, 4 Apr 89 20:59:22 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904050359.AA11925@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 4 Apr 89 11:27:21 MDT <8904041727.AA19101@defun.utah.edu>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1

re:   Introduce a new declaration called DYNAMIC-EXTENT-FUNCTION.  This is
      identical to the DYNAMIC-EXTENT declaration, except that the
      arguments name functions instead of variables.

This is not sufficiently clear for a "specification".  I think you should
at least talk about how the DYNAMIC-EXTENT-FUNCTION declaration only applies 
to lexical functions defined via FLET and LABELS, and is not to be used in
a proclamation.  

Additionally, you will have to say, for a form like:

    (locally (declare (dynamic-extent-function f g))
      (labels ((f (x) ...)
               (g (y) ...)
               (h (z) ...))
	(declare <more-declarations>)
       ...))

whether or not the declaration in the LOCALLY is to apply to the two
functions, or whether it has to be supplied in the place indicated by
<more-declarations>  [my first inclination is that it doesn't apply,
since similar program structure for type declarations wouldn't apply.]

Similarly, you will have to say whether or not there is such a thing
as a "free"  dynamic-extent-function  declaration.  E.g., what does
the following mean:

    (flet ((f (x) ...))
      (funcall f gobbledygook)
      (locally (declare (dynamic-extent-function f))
        (cogitate #'f))
      t)

Here, my inclination is that unless the dynamic-extent-function declaration
is applied to the name binding, it is useless to the compiler.  It's a bit
like allowing the compiler to represent FLOATs in specialized storage,
providing it knows that during the entire lifetime of the variable -- 
including the binding time -- the value will only be FLOAT [hence, it can, 
e.g., use the flonum pdl instead of "boxing up" the value in the heap]

Finally, you have to say how you handle a case like:

    (mapcar (the dynamic-extent-function #'(lambda (x) <capture-stuff>))
            ...)

and if so, how to specify the particular dynamic scope of interest.
Or, maybe you don't want to handle "anonymous" lexical functions. [By
the bye, I realize that 'dynamic-extent-function' isn't a type -- I
only wanted to illustrate the problem for "anonymous" functions.]


If the places where the two declarations DYNAMIC-EXTENT-FUNCTION and
DYNAMIC-EXTENT can be legitimately used don't overlap, then I don't 
see anything wrong with using the same name.  E.g.,

   (let ((x (make-list n :initial-element 0)))
     (declare (dynamic-extent x))
     (labels ((f (y z) ...))
       (declare (dynamic-extent f))
       . . . ))

should be unambiguous.



-- JonL --



P.S. The fact that I'm replying to a msg sent today doesn't mean that
     I'm not still 4 weeks behind (in general) in mail reading.

∂05-Apr-89  0710	CL-Cleanup-mailer 	Re: issue DYNAMIC-EXTENT-FUNCTION, version 1  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Apr 89  07:10:33 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA14298; Wed, 5 Apr 89 08:10:27 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA19876; Wed, 5 Apr 89 08:10:22 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904051410.AA19876@defun.utah.edu>
Date: Wed, 5 Apr 89 08:10:21 MDT
Subject: Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
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>, Tue, 4 Apr 89 16:23 EDT

> Date: Tue, 4 Apr 89 16:23 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> 
> Does the compiler committee's model of compilation permit compilation of
> one function to be affected by declarations in the current definition of
> another function that it calls?  I hope so.

Issue COMPILE-ENVIRONMENT-CONSISTENCY talks about situations in which
the compiler is allowed to assume that functions defined in the
compiletime environment retain the same definitions at runtime.  I
don't see anything wrong with applying this technique in those
situations.

> Second, if a function has a SYS:DOWNWARD-FUNCTION declaration in front of
> its body, then the function is implemented with dynamic extent regardless
> of whether the compiler thinks all uses are "downward".  This feature is
> used less often than the first feature, but is still used pretty often.

I vaguely remembered seeing this in some ancient Symbolics
documentation.  It seems a little strange to me to have a declaration
that is only valid in one particular place, but this would indeed take
care of the problem with anonymous lambdas.

> On a sillier note, should we minimize proliferation of names by
> replacing
> 
>    (declare (dynamic-extent-function name))
> 
> with
> 
>    (declare (dynamic-extent #'name)) ?

I wouldn't have any strong objection to doing this, but maybe I'm
being silly too.  :-)

-Sandra
-------

∂05-Apr-89  0721	CL-Cleanup-mailer 	Re: issue DYNAMIC-EXTENT-FUNCTION, version 1  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Apr 89  07:21:47 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA14975; Wed, 5 Apr 89 08:21:43 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA19890; Wed, 5 Apr 89 08:21:40 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904051421.AA19890@defun.utah.edu>
Date: Wed, 5 Apr 89 08:21:39 MDT
Subject: Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Tue, 4 Apr 89 20:59:22 PDT

I don't want to downplay your concerns, but it ought to be pointed out
that all of the problems you mention also apply to the DYNAMIC-EXTENT
declaration proposal that we have already accepted.  (The only
difference between the two is that DYNAMIC-EXTENT declarations apply
to variable bindings and DYNAMIC-EXTENT-FUNCTION declarations apply to
function bindings.)  Maybe I'm extrapolating beyond what was actually
stated in issue DECLARATION-SCOPE, but there's no confusion in my mind
about the scope of these two particular declarations, or what it means
for them to appear "free". 

-Sandra
-------

∂05-Apr-89  0805	CL-Cleanup-mailer 	Re: Issue: LISP-SYMBOL-REDEFINITION 
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 5 Apr 89  08:05:21 PDT
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
	id AA05665; Wed, 5 Apr 89 11:05:04 -0400
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA04672; Wed, 5 Apr 89 11:06:53 EDT
Message-Id: <8904051506.AA04672@mist.>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: "sandra%defun@SAIL.Stanford.EDU"@multimax.encore.com,
        CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: LISP-SYMBOL-REDEFINITION 
In-Reply-To: Your message of Tue, 04 Apr 89 14:58:00 -0400.
Date: Wed, 05 Apr 89 11:06:51 EDT
From: Dan L. Pierson <pierson@mist.encore.com>

     Ultimately, I have written in my notes that we voted on
       ``proposal replaced by RPG, item 8 struck, w/ Sandra's prohibition
         to trace local functions''
     and that it passed 14-3.
    
My note agree with this interpretation.
    

∂05-Apr-89  0848	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 1 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Apr 89  08:47:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571732; Wed 5-Apr-89 11:47:23 EDT
Date: Wed, 5 Apr 89 11:47 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: Jon L White <jonl@lucid.com>
cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <8904050359.AA11925@bhopal>
Message-ID: <19890405154713.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

It's my belief that a close reading of the GLS and KMP amendment to
DYNAMIC-EXTENT (which was passed out at the meeting last week and
was unanimously adopted by X3J13 provides an unambiguous answer to
each of your concerns.

∂05-Apr-89  1159	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 4)   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Apr 89  11:59:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571894; Wed 5-Apr-89 14:59:05 EDT
Date: Wed, 5 Apr 89 14:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890405145837.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

This was approved but it was so piecemeal it was hard to read so I produced
a new copy for reference.

I made the changes per our meeting and also changed some usages of
"proper part" in the examples to refer to OIP's instead. I trimmed
from the Discussion and Additional Discussion those things which seemed
no longer relevant.

I hope this fairly represents the current state of what was approved.

-----
Forum:	      Cleanup
Issue:        DYNAMIC-EXTENT
References:   Scope and Extent
Category:     ADDITION
Edit history: 27-Jun-88, Version 1 by Pitman (as issue STACK-LET)
  	      15-Nov-88, Version 2 by Pitman (issue renamed, major revision)
	      11-Jan-89, Version 3 by Masinter (Moon's proposal)
	      05-Apr-89, Version 4 by Pitman and Steele (changes per X3J13)
Related-Issues: REST-ARGUMENT-EXTENT, WITH-DYNAMIC-EXTENT
Status:	Accepted DYNAMIC-EXTENT:X3J13-MAR-89, 30-Mar-89 on a 17-0 vote.

Problem Description:

  Sometimes a programmer knows that a particular data structure
  will have only dynamic extent. In some implementations, it is
  possible to allocate such structures in a way that will make them
  easier to reclaim than by general purpose garbage collection
  (eg, on the stack or in some temporary area). Currently, however,
  there is no way to request the use of such an allocation mechanism.

Proposal (DYNAMIC-EXTENT:NEW-DECLARATION):

  Introduce a new declaration called DYNAMIC-EXTENT. The arguments to
  this declaration are names of variables.

  It is permissible for an implementation to simply ignore this declaration.
  In implementations which do not ignore it, the compiler (or interpreter)
  is free to make whatever optimizations are appropriate given this
  information; the most common optimization is to stack-allocate the
  initial value of the object. What data types (if any) can have dynamic
  extent will can vary from implementation to implementation.

  Definition: Object <x> is an ``otherwise inaccessible part'' (OIP)
    of <y> iff making <y> inaccessible would make <x> inaccessible.
    (Note that every object is an OIP of itself.)

  Suppose that construct <c> contains a DYNAMIC-EXTENT declaration for
  variable <v> (which need not be bound by <c>).  Consider the values
  <w1>, ..., <wN> taken on by <v> during the course of some execution of
  <c>.  The declaration asserts that if object <x> is an OIP of <wI>
  when <wI> ever becomes the value of <v>, then just after execution of
  <c> terminates <x> will be either inaccessible or still an OIP of <v>.

  If the assertion is ever violated, the conseqeuences are undefined.

Examples:

  Since stack allocation of the initial value entails knowing at the
  object's creation time that the object can be stack-allocated, it is
  not generally useful to declare DYNAMIC-EXTENT for variables for
  which have no lexically apparent initial value. For example,

	(DEFUN F ()
	  (LET ((X (LIST 1 2 3)))
	    (DECLARE (DYNAMIC-EXTENT X))
	    ...))

  would permit those compilers which wish to do so to stack-allocate the
  list in X. However,

	(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
	(DEFUN F () (G (LIST 1 2 3)))

  could not typically permit a similar optimization in G because it would
  be a modularity violation for the compiler to assume facts about G from
  within F. Only an implementation which was willing to be responsible for
  recompiling F if G's definition changed incompatibly could stack-allocate
  the list argument to G in F.

  Other interesting cases are:

	(PROCLAIM '(INLINE G))
	(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
	(DEFUN F () (G (LIST 1 2 3)))

    and	(DEFUN F ()
	  (FLET ((G (X) (DECLARE (DYNAMIC-EXTENT X)) ...))
	    (G (LIST 1 2 3))))

  where some compilers might realize the optimization was possible and others
  might not.

  An interesting variant of this is the so-called `stack allocated rest list'
  which can be achieved (in implementations supporting the optimization) by:

	(DEFUN F (&REST X)
	  (DECLARE (DYNAMIC-EXTENT X))
	  ...)

  Note here that although the initial value of X is not explicit, the F
  function is responsible for assembling the list X from the passed arguments,
  so the F function can be optimized by the compiler to construct a 
  stack-allocated list instead of a heap-allocated list in implementations
  which support such.


In
            (LET ((X (LIST 'A1 'B1 'C1))
                  (Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
              (DECLARE (DYNAMIC-EXTENT X Y))
              ...)
The OIP's of X are three conses, and the OIP's of Y are three other
conses.  None of the symbols A1, B1, C1, A2, B2, C2, or NIL is an
OIP of X or Y.  However, if a freshly allocated uninterned symbol had
been used, it would have been an OIP.

- - - - - - - -
          (DOTIMES (I N) 
            (DECLARE (DYNAMIC-EXTENT I))

This is particularly instructive.  Since I is an integer by the
definition of DOTIMES, but EQ and EQL are not necessarily equivalent for
integers, what are the OIP's of I, which this declaration
requires the body of the DOTIMES not to "save"?  If the value of I is 3,
and the body does (SETQ FOO 3), is that an error?  The answer is no, but
the interesting thing is that it depends on the implementation-dependent
behavior of EQ on numbers.  In an implementation where EQ and EQL are
equivalent for 3, then 3 is not an OIP because (EQ I (+ 2 1)) is true,
and therefore there is another way to access the object besides
going through I.  On the other hand, in an implementation where EQ and
EQL are not equivalent for 3, then the particular 3 that is the value of
I is an OIP, but any other 3 is not.  Thus (SETQ FOO 3) is valid
but (SETQ FOO I) is erroneous.  Since (SETQ FOO I) is erroneous in some
implementations, it is erroneous in all portable programs, but some other
implementations may not be able to detect the error.

- - - - - - - -

  (LET ((X (LIST 1 2 3)))
    (DECLARE (DYNAMIC-EXTENT X))
    (PRINT X)
    NIL)
  PRINT does not "save" any part of its input.
  This prints (1 2 3)

- - - - - - - -

  (DO ((L (LIST-ALL-PACKAGES) (CDR L)))
      ((NULL L))
    (DECLARE (DYNAMIC-EXTENT L))
    (PRINT (CAR L)))
  prints all packages; none of the newly-allocated list structures are saved.
- - - - - - - -
  (DEFUN ADD (&REST X) (DECLARE (DYNAMIC-EXTENT X)) (APPLY #'+ X))
  (ADD 1 2 3) => 6

I.e., useful way to declare that &REST lists have dynamic extent
- - - - - - - -
  (DEFUN ZAP (X Y Z)
    (DO ((L (LIST X Y Z) (CDR L)))
	((NULL L))
      (DECLARE (DYNAMIC-EXTENT L))
      (PRIN1 (CAR L))))
  (ZAP 1 2 3)
  prints 123

- - - - - - - -
  (DEFUN ZAP (N M)
    ;; Computes (RANDOM (+ M 1)) at relative speed of roughly O(N).
    ;; It may be slow, but with a good compiler at least it
    ;; doesn't waste much heap storage.  :-)
    (LET ((A (MAKE-ARRAY N)))
      (DECLARE (DYNAMIC-EXTENT A))
      (DOTIMES (I N) 
	(DECLARE (DYNAMIC-EXTENT I))
	(SETF (AREF A I) (RANDOM (+ I 1))))
      (AREF A M)))
  (< (ZAP 5 3) 3) => T

- - - - - - - -
The following are in error, since the value of X is used outside of its
extent:

       (LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))

  (PROGN (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)
         NIL)

- - - - - - - -

Rationale:

  This permits a programmer to offer advice to an implementation about
  what may be stack-allocated for efficiency.

  It may be difficult or impossible for a compiler to infer this
  same information statically.

  Since a number of implementations offer this capability and there
  is demand from users for access to the capability, this ``codifies
  existing practice.''

  Because this approach is purely lexical, it does not interact badly with
  other programs in the way that the macro WITH-DYNAMIC-EXTENT (see issue
  by same name) would.

Current Practice:

  Symbolics Genera and Symbolics Cloe offer stack allocation, though not
  in this strategy.

  [KMP thinks that] Lucid supports the proposal.

Cost to Implementors:

  No cost is forced since implementations are permitted to simply
  ignore the DYNAMIC-EXTENT declaration.

Cost to Users:

  None. This change is upward compatible.

  There may be some hidden costs to debugging using this declaration (or any
  feature which permits the user to access dynamic extent objects without
  the compiler proving that they are appropriate). If the user misdeclares
  something and returns a pointer into the stack (or stores it in the heap),
  an undefined situation may result and the integrity of the Lisp storage
  mechanism may be compromised. Debugging these situations may be tricky,
  but users who have asked for this feature have indicated a willingness
  to deal with such costs. Nevertheless, the perils should be clearly
  documented and casual users should not be encouraged to use this
  declaration.

Cost of Non-Adoption:

  Some portable code would be forced to run more slowly (due to
  GC overhead), or to use non-portable language features.

Benefits:

  The cost of non-adoption is avoided.

Aesthetics:

  This declaration allows a fairly low level optimization to work
  by asking the user to provide only very high level information.
  The alternatives (sharpsign conditionals, some of which may
  lead to more bit-picky abstractions) are far less aesthetic.

Discussion:

  A previous version of this proposal suggested primitives STACK-LET
  and STACK-LET*. Consensus was that the more general declaration facility
  would be more popular.

  Moon came up with a description of something called a "proper part" which
  Steele formalized into the idea of an "otherwise inaccessible part". The
  two are essentially interchangeable, but Steele's description was more
  rigorous.

  KMP: ... it still raises the question of whether we should define 
       per-function for every CL function whether any of the arguments is
       permitted to be "saved" so that CL programs don't get any funny
       surprises. If we don't, it ends up being implementor's discretion how
       to resolve cases ... and everyone might not agree that all cases are
       ... obvious ...

  JonL: PDP10 MacLisp had a similar problem w.r.t pdlnums.  That is why
	"identity" functions were so troublsome for it -- in order to
        return a guaranteed safe value, it typically had to copy it's
	pdlnum argument, thereby making some cases of "fast arithmetic" 
	code much worse than interpreted code!  [Remember PRINT in MacLisp?
	it returns T rather than it's argument for just this reason.]

	It is necessary for an optimizing compiler to know something about
	what happens to the data it passes along to "system" functions; for
	example, it could assume that GET doesn't clobber the list given
	to it, nor does it retain pointers to any part of it [what was the
	terminology in the revised proposal?  "saved"? and "proper part"?]
	The issue LISP-SYMBOL-REDEFINITION might help here, in that an
	implementation's compilers could depend upon it's own internal
	database.  But it wouldn't hurt at all to have some of these
	requirements "up front" in the standard.

  It was generally agreed that we would also like to consider a proposal
  on dynamic extent functions at the next meeting. (Sandra said she would
  prepare one, and has already done so. See issue DYNAMIC-EXTENT-FUNCTION.)

∂05-Apr-89  1206	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 4)   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Apr 89  12:06:04 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571908; Wed 5-Apr-89 15:06:07 EDT
Date: Wed, 5 Apr 89 15:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890405145837.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890405150540.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

Sigh. As you can probably tell, I meant to change the name of the
proposal from NEW-DECLARATION to X3J13-MAR-89 like Masinter's been
doing and I only did it half-way. There's only one proposal so
please don't be confused. Anyway, the text is right so I'm gonna
leave it...

∂05-Apr-89  1731	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 1 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Apr 89  17:31:35 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00786g; Wed, 5 Apr 89 17:25:35 PDT
Received: by bhopal id AA04722g; Wed, 5 Apr 89 17:32:08 PDT
Date: Wed, 5 Apr 89 17:32:08 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904060032.AA04722@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 5 Apr 89 11:47 EDT <19890405154713.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1

re: It's my belief that a close reading of the GLS and KMP amendment to
    DYNAMIC-EXTENT (which was passed out at the meeting last week and
    was unanimously adopted by X3J13 provides an unambiguous answer to
    each of your concerns.

Well, the difficulty centers on how one interprets the word "identical"
in Sandra's proposal.  I would invite you to make your interpretation,
and put it into unambiguous words, explicitly in this proposal.

By the bye, do you agree that a single declaration name -- DYNAMIC-EXTENT
--  is satisfactory for both contexts?   A reasonable alternative might 
simply be to amend the previously passed proposal to include the function 
context.



-- JonL --

∂05-Apr-89  2203	CL-Cleanup-mailer 	issue DYNAMIC-EXTENT-FUNCTION, version 1 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Apr 89  22:03:16 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00980g; Wed, 5 Apr 89 21:57:29 PDT
Received: by bhopal id AA05644g; Wed, 5 Apr 89 22:03:57 PDT
Date: Wed, 5 Apr 89 22:03:57 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904060503.AA05644@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Wed, 5 Apr 89 08:21:39 MDT <8904051421.AA19890@defun.utah.edu>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1

re: . . .all of the problems you mention also apply to the DYNAMIC-EXTENT
    declaration proposal that we have already accepted.  (The only
    difference between the two is that DYNAMIC-EXTENT declarations apply
    to variable bindings and DYNAMIC-EXTENT-FUNCTION declarations apply to
    function bindings.) 

This can't be true -- for example, there is no such thing as
"anonymous variables" in the way that lambda-forms are anonymous
functions.  And as Moon's recounting of the current Symbolics model
shows, downward lambdas can be very important.

However, I was mostly concerned about the possibility that two
readers might interpret your wording "identical" in somwhat
non-identical ways.


-- JonL --

∂06-Apr-89  1115	CL-Cleanup-mailer 	Condensed summary of CL Cleanup meeting results    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 6 Apr 89  11:15:35 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 572595; Thu 6-Apr-89 14:15:30 EDT
Date: Thu, 6 Apr 89 14:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Condensed summary of CL Cleanup meeting results
To: CL-Cleanup@SAIL.Stanford.EDU
cc: chapman%aitg.dec@decwrl.dec.com
Message-ID: <890406141456.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

Kathy Chapman asked for the information that was in my last burst of
messages in some sort of `summary' form. I had chosen to send out
individual messages because I assumed most people like myself who were
doing per-topic filing would find that simpler. But for those who are
just auditing this stuff and deleting it, here's my summary.
Just a reminder though -- these are just my notes and do not necessarily
represent the official story if it turns out there are discrepancies.
-----

ADJUST-ARRAY-NOT-ADJUSTABLE - Deferred
BREAK-ON-WARNINGS-OBSOLETE - Passed
CLOS-CONDITIONS - Passed
CLOS-MACRO-COMPILATION - Tabled
CLOSED-STREAM-OPERATIONS -
 Motion to replace v7 with v5 passed unamended
COERCE-INCOMPLETE - Withdrawn
COMMON-TYPE - Passed
COMPLEX-RATIONAL-RESULT - Passed
CONDITION-RESTARTS - Deferred
COPY-SYMBOL-COPY-PLIST - Passed
COPY-SYMBOL-COPY-PRINT-NAME - Passed
DECLARE-FUNCTION-AMBIGUITY - 
 An incredibly weird vote on the question ``How many favor saying it passed
 at the last meeting?'' passed N-0-M.
DEFINE-OPTIMIZER - Failed
 There is new information which leads me to believe this might come up
 again at the next meeting.
DEFMACRO-LAMBDA-LIST -
 There were hardcopy amendments distributed.
 My notes say that we approved amendments A & B (``permit all four'')
 and we added an amendment that said that &ENVIRONMENT would not be
 duplicated in a DEFMACRO lambda-list.
 The amended proposal was passed N-0-1.
DESCRIBE-UNDERSPECIFIED - 
 An amendment was made (I think by Barrett) to make DESCRIBE deal with 
 its second argument in the same way as PRINT does (that is, permitting
 arguments of NIL and T).
 The amended proposal passed 15-0.
DESTRUCTURING-BIND
 Discussion on this was broken over two days with quite a number of
 possible amendments discussed.  Pitman came up with a written set of
 amendments for Thursday which were discarded because Moon submitted a
 revised proposal (consistent with those amendments, and adding at least
 one other feature not covered in those separate amendments) on Thursday.
 The revised proposal was v3, already mailed.
 Moon's revised proposal was voted on, and passed 15-1.
DYNAMIC-EXTENT - 
 Steele and Pitman drafted a revised proposal over lunch Thursday
 which passed 17-0.
EQUALP-GENERIC - Withdrawn
ERROR-CHECKING-IN-NUMBERS-CHAPTER - Deferred
ERROR-NOT-HANDLED -
 Withdrawn in favor of providing Kathy with editorial advice to
 `minimize implicit requirements on debuggers' in the presentation of the
 debugger in the standard.
EVAL-WHEN-NON-TOP-LEVEL - Option GENERALIZE-EVAL-NEW-KEYWORDS passed
EXIT-EXTENT - 
 Moon offered some amendments the effect of which were to allow you to throw again
 to the same tag as you were already throwing to; specifically:
 In the first paragraph of the MINIMAL proposal, delete "or is itself the
 target exit" and change "events (c) and (d) at" to "event (c) occurs at".
 After the first paragraph add a new paragraph "The event (d) occurs at the
 end of the transfer of control."
 The proposal was amended, and the amended option MINIMAL passed 11-5.
FUNCTION-COERCE-TIME - 
 Withdrawn; editors were instructed to be explicitly vague 16-1.
FUNCTION-NAME - 
 The net effect is that option LARGE passed with amendments to strike 7,8,9.
GENSYM-NAME-STICKINESS - Passed
HASH-TABLE-ACCESS - 
 Passed 17-0 with hand-written amendments by Pitman (and agreement that the
 `obvious' write-o's would be corrected).
HASH-TABLE-SIZE - Deferred
IN-PACKAGE-FUNCTIONALITY - 
 The net effect is that NEW-MACRO passed with the name of SELECT-PACKAGE
 changed to IN-PACKAGE.
IN-SYNTAX -
 Version 2, which makes LOAD and *COMPILE-FILE* bind *READTABLE* (and
 which does -not- introduce the IN-SYNTAX macro mentioned in version 1)
 passed 12-0-3.  This version was distributed by KMP in handwritten form.
LISP-PACKAGE-NAME - 
 The net effect is that this passed with amendment to rename package USER to 
 COMMON-LISP-USER with nickname CL-USER.
LISP-SYMBOL-REDEFINITION - 
 GZ wanted an amendment to strike item 8 from this list.
 Sandra had some concern about the penultimate paragraph where she wanted a
 prohibition on the ability to trace local functions (in implementations that
 permit that).  Moon thinks the proposal was amended to explicitly allow
 tracing of such local function bindings.
 We went round in circles about item 8.  A straw poll to send this back for
 more work failed 6-10, so we kept on.
 A motion was made to terminate discussion. This passed by 2/3 vote.
 Moon's notes say item 8 may need further refinement, as for instance by GLS's
 amendment.  The goal is to separate properties into the ones the user can
 bash and the ones the user cannot bash.
 Ultimately, I have written in my notes that we voted on
   ``proposal replaced by RPG, item 8 struck, w/ Sandra's prohibition
     to trace local functions''
 and that it passed 14-3.
 Item 8 might be revisited at the next meeting.
LOAD-OBJECTS -
 Moon proposed friendly amendment to use the name MAKE-LOAD-FORM-SAVING-SLOTS.
 The amended proposal passed 18-0.
LOAD-TRUENAME - Deferred
LOCALLY-TOP-LEVEL - Passed
LOOP-AND-DISCREPANCY - Passed
MACRO-CACHING -
 Tabled Tuesday. Not re-raised Thursday.
 Might or might not come up at next meeting.
MACRO-ENVIRONMENT-EXTENT - option DYNAMIC passed 15-1.
MAKE-STRING-FILL-POINTER - Withdrawn
PACKAGE-FUNCTION-CONSISTENCY - 
 This was on the agenda but not discussed.
 I expect it will come up at the next meeting.
PATHNAME-CANONICAL-TYPE - Deferred
PATHNAME-COMPONENT-CASE - Deferred
PATHNAME-COMPONENT-VALUE - Deferred
PATHNAME-LOGICAL - Deferred (but not seriously expected to come up again)
PATHNAME-PRINT-READ - 
 This was deferred from Tuesday to Thursday but then didn't come
 around for discussion due to lack of time.
 It might come up at the next meeting.
PATHNAME-SUBDIRECTORY-LIST - Deferred
PATHNAME-SYNTAX-ERROR-TIME - Deferred
PATHNAME-WILD - Deferred
PEEK-CHAR-READ-CHAR-ECHO - 
 Kim Barrett mentioned again that he wants to reopen this, but nothing was done.
PRETTY-PRINT-INTERFACE - Deferred
PRINT-CASE-PRINT-ESCAPE-INTERACTION - 
 This was deferred from Tuesday to Thursday but then didn't come up
 for discussion. Being a clarification, I expect it to come up at the
 next meeting.
PRINT-CIRCLE-SHARED -
 This was deferred from Tuesday to Thursday but then didn't come up
 for discussion. Since some people consider this almost a clarification,
 this might come up at the next meeting.
PROCLAIM-LEXICAL - Failed
READ-CASE-SENSITIVITY - Deferred
READ-DELIMITED-LIST-EOF -
 This issue was mentioned but was not on my list of possible topics.
 No action was taken. It's probably a clarification and I guess it might
 still come up later.
REAL-NUMBER-TYPE - Passed (the `union' of the two proposals)
REMF-DESTRUCTION-UNSPECIFIED - Passed
REQUIRE-PATHNAME-DEFAULTS - 
 Reconsidered but no change made. Previous vote stands.
SETF-MULTIPLE-STORE-VARIABLES - 
 This was on the agenda but never gotten to.
 I think it might come up at the next meeting.
SYMBOL-MACROLET-SEMANTICS - Version 6 passed.
SYNTACTIC-ENVIRONMENT-ACCESS - Deferred
THE-AMBIGUITY -
 This didn't come up. Being a clarification, I assume it might come up next meeting.
TIME-ZONE-NON-INTEGER
 Moon proposed time zones be multiples of 1/3600 so that they were
 even numbers of seconds.  (Some people suspected this was a subtle
 marketing ploy for Symbolics.) This amendment was accepted 11-0.
 Pitman proposed that we limit time zone to the range [-24,24], inclusive.
 The inclusive was to allow countries to disagree on which end was open,
 since it was agreed that the correct value here is a largely political,
 rather than technical issue.  The amendment was accepted 8-5.
 The full proposal with both amendments passed 18-0.
TYPE-OF-UNDERCONSTRAINED - 
 Some people had some concerns about a previous version of this that passed.
 We wanted to reconsider this, but didn't have the right hardcopy.
 No action was taken. This will probably come up next meeting.
UNDEFINED-VARIABLES-AND-FUNCTIONS - Deferred
WITH-COMPILATION-UNIT -
 This passed 11-6 with an amendment to say it defers "warnings" rather than "actions"
 and with an amendment to say it does not apply to the COMPILE function (only to 
 COMPILE-FILE).

∂09-Apr-89  0921	CL-Cleanup-mailer 	Issue COMPLEX-RATIONAL-RESULT, version 2 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89  09:21:18 PDT
Return-Path: <gls@Think.COM>
Received: from brigit.think.com by Think.COM; Sun, 9 Apr 89 12:20:54 EDT
Received: by brigit.think.com; Sun, 9 Apr 89 01:37:19 EDT
Date: Sun, 9 Apr 89 01:37:19 EDT
From: gls@Think.COM
Message-Id: <8904090537.AA00468@brigit.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: Issue COMPLEX-RATIONAL-RESULT, version 2

This was a good thing for Moon to bring up, but I think a couple
of desirable details were left uncovered.  Here is a new version
to consider in June.

Detail 1 is that a mathematically rational or complex rational
value might result from arguments that are a mixture of rational
and complex rational; or a complex rational value might result
from arguments that are rational only.

Detail 2 is that the version 1 proposal mentions (complex float)
where I believe the more specific (complex single-float) is appropriate.

Detail 3 is that in some cases the option of an ordinary float
result is desirable or required rather than a (complex single-float);
consider the ABS function, for example.

Detail 4 is that if the true mathematical result is not rational
or complex rational, I think we want to specify that the returned
value is single-float or (complex single-float).

----------------------------------------------------------------
Issue:         COMPLEX-RATIONAL-RESULT

References:    CLtL p.203

Category:      CLARIFICATION

Edit history:  Version 1, 20-Mar-89, by Moon
               Version 2, 08-Apr-89, by Steele

Problem description:
  
  Referring to irrational and transcendental functions, CLtL says:
    
    When the arguments to a function in this section are all rational and
    the true mathematical result is also (mathematically) rational, then
    unless otherwise noted an implementation is free to return either an
    accurate result of type rational or a single-precision floating-point
    approximation.  If the arguments are all rational but the result cannot
    be expressed as a rational number, then a single-precision
    floating-point approximation is always returned.

  Referring to EXPT, CLtL says:

    If the base-number is of type RATIONAL and the power-number is an
    INTEGER, the calculation will be exact and the result will be of
    type RATIONAL; otherwise a floating-point approximation may result.

  What about arguments of type (complex rational)?

Proposal (COMPLEX-RATIONAL-RESULT:EXTEND):

  Extend the paragraph quoted above as follows to cover the components
  of complex numbers.  If the arguments to a function are all of type
  (OR RATIONAL (COMPLEX RATIONAL)) and the true mathematical result is
  (mathematically) a complex number with rational real and imaginary
  parts, then unless otherwise noted an implementation is free to return
  either an accurate result of type (OR RATIONAL (COMPLEX RATIONAL)) or
  a single-precision floating-point approximation of type SINGLE-FLOAT
  (permissible only if the imaginary part of the true mathematical
  result is zero) or \cd{(COMPLEX SINGLE-FLOAT). If the arguments are
  all of type (OR RATIONAL (COMPLEX RATIONAL)) but the result cannot be
  expressed as a rational or complex rational number, then the returned
  value will be of type SINGLE-FLOAT (permissible only if the imaginary
  part of the true mathematical result is zero) or (COMPLEX SINGLE-FLOAT).

  For EXPT of a (COMPLEX RATIONAL) to an integer power, the
  calculation must be exact and the result will be of type
  (OR RATIONAL (COMPLEX RATIONAL)).

Examples:

  (log #c(-16 16) #c(2 2)) => 3 or approximately #c(3.0 0.0)
			        or approximately 3.0 (unlikely)
  (abs #c(3/5 4/5)) => 1 or approximately 1.0
  (expt #c(2 2) 3) => #c(-16 16)
  (expt #c(2 2) 4) => -64 

Rationale:
  
  This seems most consistent with the treatment of real numbers.

Current practice:
  
  Symbolics Genera 7.4 returns a (complex float) for the first example
  and returns the specified answers for the second and third examples.
  Other implementations were not surveyed.

Cost to Implementors:

  Only EXPT would have to change, since the type of the other results
  is at the discretion of the implementation.

Cost to Users:

  Probably none, but it is hard to predict.

Cost of non-adoption:
  
  Slightly less self-consistent language.

Performance impact:

  None of any significance.

Benefits/Esthetics:

  More self-consistent language.

Discussion:

  None.

∂09-Apr-89  2155	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION, v.6
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89  21:55:03 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 89 21:55:03 PDT
Date: 9 Apr 89 21:54 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: LISP-SYMBOL-REDEFINITION, v.6
To: cl-cleanup@SAIL.Stanford.EDU
line-fold: NO
Message-ID: <890409-215503-3430@Xerox>

I've compared my notes against Mary's minutes, and they agree
that we struck 8 and added a phrase "and to trace that binding"
("Sandra's amendment".)

!
Status: Passed, Mar 89 X3J13, as amended

Forum:         Cleanup
Issue:         LISP-SYMBOL-REDEFINITION
 
References:    Cleanup issue PACKAGE-CLUTTER
               CLtL pp 67-69 Defining named functions
 
Category:      CLARIFICATION
 
Edit history:  Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
               Masinter, Version 2, 7-Oct-88
               Masinter, Version 3,  7-Oct-88, fix typos
               van Roggen, Version 4, 13-Oct-88, undefined, not unspecified
               Masinter, Version 5, 22-Nov-88, add more cases
		Masinter, Version 6,  9-Apr-89, make Mar 89 X3j13 amendments
 
Problem description:
 
Is it legal to redefine Common Lisp functions? There is no explicit
prohibition, and many implementations do allow redefinition of
functions in the Lisp package.
 
CLtL only says that special forms can not be redefined. But this doesn't 
solve the general problem of redefining system functions.
 
Proposal LISP-SYMBOL-REDEFINITION:MAR89-X3J13

Except where explicitly allowed, the consequences are undefined if any
of the following actions are performed on symbols in the COMMON-LISP
package:

1. Binding or altering its value (lexically or dynamically)
2. Defining or binding it as a function
3. Defining or binding it as a macro
4. Defining it as a type specifier (defstruct, defclass, deftype)
5. Defining it as a structure (defstruct)
6. Defining it as a declaration
7. Using it as a symbol macro
8. Altering its print name (this may already be prohibited)
9. Altering its package
10. Tracing it
11. Declaring or proclaiming it special or lexical
12. Declaring or proclaiming its type or ftype
13. Removing it from the package COMMON-LISP

If such a symbol is not globally defined as a variable or a constant,
it is allowed to lexically bind it and declare the type of that binding.

If such a symbol is not defined as a function, macro, or special form,
it is allowed to (lexically) bind it as a function and to declare the
ftype of that binding and to trace that binding.

If such a symbol is not defined as a function, macro, or special form,
it is allowed to (lexically) bind it as a macro.

Examples:
 
The behavior of the construct:
 
(FLET ((OPEN (filename &key direction) (format t "Open called....") 
			(OPEN filename :direction direction)))
    (with-open-file (x "frob" :direction ':output) 
		(format t "was Open called?")))
 
is undefined; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
 
(DEFUN CAR (X) (CDR X))
 
might signal an error.
 
Rationale:
 
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
 
Allowing arbitrary redefinition of symbols in the system would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
 
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
 
Current practice:
 
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
 
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
 
Cost to Implementors:
 
This proposal clarifies the status quo -- that the consequences are undefined. It
allows and encourages implementors to check for such redefinition, but does not
require it.
 
Cost to Users:
 
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
non-portable.
 
Benefits:
 
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp. 
 
Cost of non-adoption:
 
Continued questions.
 
Esthetics:
 
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble. 
 
Discussion:
 
At the March 89 X3j13 meeting, a proposed additional constraint 
("Altering its property list") was removed. Presumably this means
that conformal programs are allowed to alter the property list of
 symbols in the COMMON-LISP package.

∂09-Apr-89  2239	CL-Cleanup-mailer 	Re: Issue: PACKAGE-FUNCTION-CONSISTENCY  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89  22:39:02 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 89 22:38:45 PDT
Date: 9 Apr 89 22:38 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PACKAGE-FUNCTION-CONSISTENCY
In-reply-to: KMP%STONY-BROOK.SCRC.Symbolics:COM:Xerox's message of 4 Apr 89
 12:31 PDT
To: KMP@Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.edu
Message-ID: <890409-223845-3466@Xerox>

I believe the status is that David mailed a Version 4 which contained the
correct wording for what was passed at the Jan 89 X3J13. I don't think we
need to discuss it again. I had it on the agenda because I knew my Version
3 was incorrect or cloudy.

I'm marking it "Passed, as amended, Jan 89 X3j13". 

∂09-Apr-89  2248	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89  22:48:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 89 22:48:13 PDT
Date: 9 Apr 89 22:47 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Wed, 23 Nov 88 18:55 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <890409-224813-3470@Xerox>

You said: 

"I have some concerns about your alternate proposal but my mind is not
closed. I need more time to study this alternative and would like to
postpone dealing with this issue until after the letter ballot, instead
targeting a mailing in time for an in-person vote in January.
"

I still like my alternative proposal, which is just a smaller,
but useful, subset. 


∂09-Apr-89  2315	CL-Cleanup-mailer 	Re: PRETTY-PRINT-INTERFACE, version 4    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89  23:15:32 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 89 23:15:22 PDT
Date: 9 Apr 89 23:14 PDT
From: masinter.pa@Xerox.COM
Subject: Re: PRETTY-PRINT-INTERFACE, version 4
In-reply-to: dick@wheaties.ai.mit.edu's message of Wed, 22 Mar 89 13:54:34
 EST
To: dick@wheaties.ai.mit.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890409-231522-3487@Xerox>

As I relayed to you, what I recall is that there was some squawking about
adding new FORMAT directives. Maybe we should break it up for voting.

∂09-Apr-89  2332	CL-Cleanup-mailer 	Issue: READ-DELIMITED-LIST-EOF 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89  23:32:26 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 09 APR 89 23:32:26 PDT
Date: 9 Apr 89 23:31 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: READ-DELIMITED-LIST-EOF
To: KMP@symbolics.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890409-233226-3497@Xerox>

This is what I have filed under "READ-DELIMITED-LIST-EOF".

I think this could well be handled under ERROR-CHECKING-IN-IO-CHAPTERS or
some such.


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

Date: Mon, 28 Nov 88 17:17 EST
From: Barry Margolin <barmar@Think.COM>
Subject: EOF during READ-DELIMITED-LIST
To: cl-cleanup@sail.stanford.edu

According to CLtL p.378, "it is always an error to hit end-of-file
during the operation of READ-DELIMITED-LIST."  This makes
READ-DELIMITED-LIST almost useless, because it means that some user
input to an application can cause undefined effects.

I think that this particular "is an error" was not intended this way.
READ-DELIMITED-LIST should be the function that the standard "(" macro
character uses, and the latter is defined to signal an error if an EOF
occurs before the matching delimiter is read.  Also, the previous
sentence says that this is the reason that there is no EOF-ERROR-P
argument; the implication is that READ-DELIMITED-LIST has an implicit
EOF-ERROR-P argument that is always non-NIL.

Has this already been cleaned up?

                                                barmar



     ----- Next Message -----

Date: 29 Nov 88 14:45 PST
From: masinter.pa
Subject: Re: EOF during READ-DELIMITED-LIST
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Mon, 28 Nov 88
17:17 EST
To: Barry Margolin <barmar@Think.COM>
cc: masinter

As far as I know, there is no cleanup issue regarding READ-DELIMITED-LIST.
I think you might be proposing to change an "is an error" in CLtL into a
"signals an error"; if so, you might consider specifying the class of error
signalled.


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

∂10-Apr-89  0006	CL-Cleanup-mailer 	Re: Issue: TYPE-OF-UNDERCONSTRAINED 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89  00:06:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 10 APR 89 00:05:53 PDT
Date: 10 Apr 89 00:05 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TYPE-OF-UNDERCONSTRAINED
In-reply-to: KMP%STONY-BROOK.SCRC.Symbolics:COM:Xerox's message of 4 Apr 89
 13:32 PDT
To: KMP@Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890410-000553-3516@Xerox>

Actually, Mary's notes and my recollection is that there was a motion to
reconsider that was tabled. I'm not sure this is the same as "no action was
tabled", but I think it definitely will come up next meeting.

∂10-Apr-89  0028	CL-Cleanup-mailer 	Cleanup Issue status, 10-Apr-89
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89  00:28:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 APR 89 00:28:19 PDT
Date: 10 Apr 89 00:27 PDT
From: masinter.pa@Xerox.COM
Subject: Cleanup Issue status, 10-Apr-89
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Thu, 6 Apr 89 14:14 EDT
To: CL-Cleanup@SAIL.Stanford.EDU, chapman%aitg.dec@decwrl.dec.com
line-fold: NO
Message-ID: <890410-002819-3553@Xerox>

Well, I had a couple of discrepancies, that I already sent mail
about, with Kent's notes. I think Mary has good notes this time,
and I checked them fairly carefully against mine.

Here's my issue status. Except for time-zone-non-integer,
I think I have updated versions of all passed
issues stored on arisia.xerox.com under the
	clcleanup/passed

directory. The clcleanup/pending directory is unreliable.

Codes:

+ passed
* pending; to be considered later meeting
- withdrawn

released = "Mailed to X3J13@Sail.stanford.edu"

+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988

+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988

+-* ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments:  amendment had wording problem.
Version 9, 17-Mar-89, released 21-mar-89
Comments: still problems
Status: withdrawn Mar 89 X3J13, intend to revisit Jun 89 X3J13 

+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13

+ AREF-1D
synopsis: add ROW-MAJOR-AREF
Version 7, 14-NOV-87
Status: Passed, 1988?

+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13

+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13

+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?

+ BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Version 2,  8-Apr-89, (not mailed, on arisia)
Status: Passed, as amended, Mar 89 X3J13

+ CLOS-CONDITIONS
Version 4, 10-Mar-89, released 16-Mar-89
Comments: define metaclass of conditions? Not here.
Status: Passed, Mar 89 X3J13

+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13

+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at Jan 89 X3J13; amendment withdrawn Mar 89 X3J13;
	version 5 stands

- COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: motion died for lack of second; withdrawn

+ COLON-NUMBER
Synopsis:  :123 is an error
Version 1, 22-OCT-87
Status: Passed, 1988

+ COMMON-TYPE
Version 1, 20-Mar-89, released 21-Mar-89
Status: passed, Mar 89 X3J13

+ COMPLEX-RATIONAL-RESULT
Version 1, 20-Mar-89, released 21-Mar-89
Status: passed, Mar 89 X3J13

+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988

+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13

* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version

+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13

+ COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: passed, Mar 89 X3j13

+ COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: passed, Mar 89 X3j13

+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
Version 2, 4-SEP-88, released 4-Sep-88
Status: Passed, Aug 88 X3J13

+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13

+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89, released 3-Feb-89
Status: passed, Jan 89 X3J13

+ DECLARE-FUNCTION-AMBIGUITY
Version 4,  5-Dec-88, Released  5-Dec-88
Synopsis: (DECLARE (FUNCTION ...)) no longer synonym for FTYPE
Status: passed, Jan 89 X3J13

+ DECLARE-MACROS
Version 3, 5-FEB-88 
Status: Passed, 1988?

+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13

+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13

+ DEFMACRO-LAMBDA-LIST
Version 3, 9-Apr-89, released  9-Apr-89
Status: Passed, as amended, Mar 89 X3J13

+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988

+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 1, 7/26/88, released 8-Oct-88
Version 3, 6-Feb-89 (not released, on arisia)
Status: Passed (as amended) Jan 89 X3J13

+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988

+ DEFVAR-DOCUMENTATION
Version 2, 23-NOV-87
Status: Passed, 1988

+ DEFVAR-INIT-TIME
Version 2, 29-MAR-87
Status: Passed, 1988

+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988

+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13

+ DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
Version 2, 9-Apr-89 (not released, on arisia)
status: passed, as amended, Mar 89 X3J13

+* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Version 3, Mar 89, (Circulated at Mar 89 X3J13)
Status: passed, Mar 89 X3J13
*** NO VERSION ON ARISIA ***

* DIRECTORY-DOES-TO-MUCH
Version 1
Status: not on agenda, didn't get to; withdraw?

+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988

+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988

+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13

+ DRIBBLE-TECHNIQUE
Version 2, 14-FEB-88 
Status: Passed, 1988

+ DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Version 4, 5-Apr-89, as amended (not released to X3j13, on arisia)
Status: passed, as amended, Mar 89 X3J13

* DYNAMIC-EXTENT-FUNCTION
Comment: spin-off of DYNAMIC-EXTENT, to be considered Jun 89

+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Version 7, 15-Mar-89 (not released to X3j13, on arisia)
Status: Passed Jan 89 X3J13 as amended.

- EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Status: withdrawn, Mar 89 X3J13

* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: to be considered Jun 89

- ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: withdrawn; made editorial advice

+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?

+ EXIT-EXTENT
Version 6,  8-Jan-89, distributed Jan89 X3J13, Rereleased 16-Mar-89
Version 7, 4-Apr-89, as amended (not released to X3j13, on arisia)
Status: Passed, Mar 89 X3j13, as amended

+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13

+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended

+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988

+ FLET-IMPLICIT-BLOCK
Version 6, 5-JUN-87
Status: Passed, 1988

+ FORMAT-ATSIGN-COLON
Version 4, 5-JUN-87
Status: Passed, 1988

+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988

+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988

+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13

+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988

- FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: not submitted, will not be considered

+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13

+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988

- FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: withdrawn; request editor to rewrite as explicitly vague

+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89 (not released to X3j13; on arisia)
Status: Passed (as amended) Jan 89 X3J13
     maybe this was passed as amendment to TEST-NOT-IF-NOT instead

+ FUNCTION-DEFINITION
Version 3, 10-Feb-89 (not released to X3J13, on arisia)
Status: Passed (as amended) Jan 89 X3J13

+ FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
Version 1, 27-Jan-89, Released 16-Mar-89
Status: FUNCTION-NAME:LARGE with sections 7, 8, and 9 removed, passed
	Mar 89 X3J13

+ FUNCTION-TYPE
Version 12, 4-SEP-88, released 4-sep-88
Status: Passed, June 1988 X3J13, as amended

+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released  12-Dec-88
Status: Passed, Jan 89 X3J13

+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88 
Status: Passed, 1988

+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13

+ GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 3, 20-Mar-89, Released 23-Mar-89
Status: passed, Mar 89 X3J13 

+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89 (not released; on arisia)
Status: Passed (as amended) Jan 89 X3J13

+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988

+ HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 2, 13 Oct 88, released 16-Mar-89
Version 3, 5-Apr-89 (not released to X3j13; on arisia from KMP)
status: passed, as amended, Mar 89 X3J13 

+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
 from the generator in  the wrong order.
Status: passed, Jan 89 X3J13

- HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: didn't get to it; withdrawn

* HASH-TABLE-SIZE
Version 1, 20-Mar-89, released 21-Mar-89
Status: Postponed to Jun 89

+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 88
Status: passed Jan 89 X3J13

+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13

- IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
Status: didn't get to it by Mar 89; withdrawn

+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5, MAY-87
Status: Passed, 1988?

+ IN-PACKAGE-FUNCTIONALITY
Version 8, 15-Mar-89, Released 15-Mar-89
Version 9, 9-Apr-89, as amended Mar89 X3J13, (not released, on Arisia)
Status: passed, as amended, Mar 89 X3J13

+ IN-SYNTAX
Version 3,  9-Apr-89 (not released, on Arisia)
Status: Version 2 (without cost/benefit analysis, but same proposal)
	passed Mar 89 X3J13

+ KEYWORD-ARGUMENT-NAME-PACKAGE
Version 8, 8-NOV-87
Status: Passed, 1988?

+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?

+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13

+ LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Version 2,  9-Apr-89, as amended Mar 89 X3J13. Not released, on arisia
Status: passed, as amended, Mar 89 X3J13

+ LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Version 6,  9-Apr-89, as amended Mar 89 X3j13 (not released to X3j13, on arisia)
Status: passed, as amended, Mar 89 X3J13

+ LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Version 4, 4-Apr-89, (not released to X3J13, on arisia)
Status: passed, as amended, Mar 89 X3J13

* LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Version 2 mailed, withdrawn. KMP has amendments
Status: postponed to Jun 89

+ LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: passed, Mar 89 X3J13

+ LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: passed, Mar 89 X3J13

+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988

- MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: didn't get to Mar 89; withdraw? ???
(LMM: I'm uneasy about withdrawning.)

+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended 

- MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: withdrawn

+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13

+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89 (not released; on arisia)
Status: passed, as amended, Jan 89 X3J13

+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89 (not released; on arisia)
Status: Passed, Jan 89 X3J13, as amended

+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13

+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Version 4, 17-Mar-89, released 18-Mar-89
Status: passed, as amended, Jan 89 X3J13

* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME; add PATHNAME-CANONICAL-TYPE?
Version 1, 07-Jul-88
Status: postponed till Jun 89 X3J13

* PATHNAME-COMPONENT-CASE
Version 2, 22-Mar-89, released 22-Mar-89
Status: postponed till Jun 89 X3J13

* PATHNAME-COMPONENT-VALUE
Version 1, 20-Mar-89, released 21-Mar-89
Status: postponed till Jun 89 X3J13

* PATHNAME-EXTENSIONS
Version 1, 28-Dec-88
Status: ??? not discussed

* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet

* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88, released 23-Mar-89
Status: postponed? Mar 89 to Thursday but not to Jun?

+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988

* PATHNAME-SUBDIRECTORY-LIST
Version 4, 22-Mar-89, released 22-mar-89 (Moon's version)
Status: Postponed to Jun 89 X3J13

+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988

* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88, released 23-Mar-89
Comments: only want proposal PATHNAME-CREATION
Status: postponed to Jun 89 X3J13

+  PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89 (not released, on arisia)
Status: Passed, Jan 89 X3j13, as amended

* PATHNAME-WILD
Version 2
Status: postponed to Jun 89

*+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis:  PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
	Kim Barrett wants to reopen

* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: postponed to Jun 89 X3J13

+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?

* PRINT-CASE-PRINT-ESCAPE-INTERACTION
Version 1, 26-Jan-89
Status: postponed tues -> thur; didn't get to. Revisit, probably
	VERTICAL-BAR-RULE-NO-UPCASE

* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: didn't get to; withdraw? revisit?

+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89 (not released, on arisia)
Status: Passed, Jan 89 X3J13, as amended

- PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: amended, then failed, Mar 89 X3J13

+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988

+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13

+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Version 2, 23-Mar-89
Status: postponed to Jun 89; need one alternative

* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission

+ REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Version 4, 5-Apr-89, as amended (not released, on arisia)
Status: passed, as amended, Mar 89 X3j13

+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988

+ REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 7, 5-Apr-89 (not released, as amended, on arisia)
Status: passed, as amended, Mar 89 X3J13

+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
   (Motion to retract failed Mar 89 X3J13)

+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13

+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released  9-Dec-88
Status: passed, Jan 89 X3J13

+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13

* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 2, 22-Mar-89, released 22-Mar-89
Status: didn't get to Mar 89 X3J13.. withdraw?

+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...) 
Status: passed, Jan 89 X3J13

+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?

+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?

+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13

+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released  7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended

+ STREAM-ACCESS
Version 2, 30-Nov-88, Released  9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13

* STREAM-DEFINITION-BY-USER
Version 1, 22-Mar-89, Released hardcopy Mar 89 X3J13
Comments: Cleanup forum? For 'future directions'?

+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2 
Status: Passed, 1988?

- SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: missing writeup, didn't get to, withdraw

+ SUBTYPEP-TOO-VAGUE
Version 4,  7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

+ SYMBOL-MACROLET-DECLARE
Version 2,  9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13

+ SYMBOL-MACROLET-SEMANTICS
Status: Version 5, Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: Version 6 (reconsidered), passed, Mar 89 X3J13

+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13

+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec 
Version 4, 18-Mar-89
Status: Need new version as amended.

* THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: didn't come up Mar 89 X3J13; withdraw?

+ TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: passed with amendments; *** NEED VERSION AS AMENDED ****

* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: Moon's comments, only some responses. Fix
Status: ** NEED NEW VERSION ***

* UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: offline discussion about SLOT-UNBOUND
Status: vote on 1?

+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13

+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13

+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88 
Status: Passed, 1988

* WITH-OPEN-FILE-DOES-NOT-EXIST
Version 1, 17-Mar-89
Status: didn't get to; withdraw?

∂10-Apr-89  1025	CL-Cleanup-mailer 	Cleanup Issue status, 10-Apr-89     
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89  10:25:20 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 APR 89 09:56:10 PDT
Date: 10 Apr 89 09:52 PDT
From: masinter.pa@Xerox.COM
Subject: Cleanup Issue status, 10-Apr-89 
To: cl-cleanup@Sail.stanford.edu
Message-ID: <890410-095610-4389@Xerox>

Here's my revised issue status.

I think I have updated versions of all passed
issues stored on arisia.xerox.com under the
	clcleanup/passed

directory. The clcleanup/pending directory is unreliable.


Do you think we need to mail the 'unreleased' versions to 
X3J13?

!
Codes:

+ passed
* pending; to be considered later meeting
- withdrawn

released = "Mailed to X3J13@Sail.stanford.edu"


+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988

+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988

+-* ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments:  amendment had wording problem.
Version 9, 17-Mar-89, released 21-mar-89
Comments: still problems
Status: withdrawn Mar 89 X3J13, intend to revisit Jun 89 X3J13 

+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13

+ AREF-1D
synopsis: add ROW-MAJOR-AREF
Version 7, 14-NOV-87
Status: Passed, 1988

+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13

+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13

+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988

+ BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Version 2,  8-Apr-89, (not mailed, on arisia)
Status: Passed, as amended, Mar 89 X3J13

+ CLOS-CONDITIONS
Version 4, 10-Mar-89, released 16-Mar-89
Comments: define metaclass of conditions? Not here.
Status: Passed, Mar 89 X3J13

+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13

+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at Jan 89 X3J13; amendment withdrawn Mar 89 X3J13;
	version 5 stands

- COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: motion died for lack of second; withdrawn

+ COLON-NUMBER
Synopsis:  :123 is an error
Version 1, 22-OCT-87
Status: Passed, 1988

+ COMMON-TYPE
Version 1, 20-Mar-89, released 21-Mar-89
Status: passed, Mar 89 X3J13

+ COMPLEX-RATIONAL-RESULT
Version 1, 20-Mar-89, released 21-Mar-89
Status: passed, Mar 89 X3J13

+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988

+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13

* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version

+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13

+ COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: passed, Mar 89 X3j13

+ COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: passed, Mar 89 X3j13

+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
Version 2, 4-SEP-88, released 4-Sep-88
Status: Passed, Aug 88 X3J13

+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13

+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89, released 3-Feb-89
Status: passed, Jan 89 X3J13

+ DECLARE-FUNCTION-AMBIGUITY
Version 4,  5-Dec-88, Released  5-Dec-88
Synopsis: (DECLARE (FUNCTION ...)) no longer synonym for FTYPE
Status: passed, Jan 89 X3J13

+ DECLARE-MACROS
Version 3, 5-FEB-88 
Status: Passed, 1988?

+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13

+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13

+ DEFMACRO-LAMBDA-LIST
Version 3, 9-Apr-89, released  9-Apr-89 (as amended)
Version 4, 10-Apr-89 (left out an amendment; not released)
Status: Passed, as amended, Mar 89 X3J13

+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988

+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 1, 7/26/88, released 8-Oct-88
Version 3, 6-Feb-89 (not released, on arisia)
Status: Passed (as amended) Jan 89 X3J13

+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13

+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988

+ DEFVAR-DOCUMENTATION
Version 2, 23-NOV-87
Status: Passed, 1988

+ DEFVAR-INIT-TIME
Version 2, 29-MAR-87
Status: Passed, 1988

+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988

+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13

+ DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
Version 2, 9-Apr-89 (not released, on arisia)
status: passed, as amended, Mar 89 X3J13

+ DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Version 3, Mar 89, (circulated at Mar 89 X3J13, not released, on arisia)
Status: passed, Mar 89 X3J13

* DIRECTORY-DOES-TO-MUCH
Version 1
Status: not on agenda, didn't get to; withdraw?

+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988

+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988

+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13

+ DRIBBLE-TECHNIQUE
Version 2, 14-FEB-88 
Status: Passed, 1988

+ DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Version 4, 5-Apr-89, as amended (not released to X3j13, on arisia)
Status: passed, as amended, Mar 89 X3J13

* DYNAMIC-EXTENT-FUNCTION
Comment: spin-off of DYNAMIC-EXTENT, to be considered Jun 89
Version 1, 4-Apr-89

- ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
   value in consistent format across implementations. This makes
   them virtually useless. I would like to constrain the values
   enough so that implementors knew what to provide as return
   values, and provide some examples of intended uses."
Status: didn't get to; withdrawn

+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Version 7, 15-Mar-89 (not released to X3j13, on arisia)
Status: Passed Jan 89 X3J13 as amended.

- EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Status: withdrawn, Mar 89 X3J13

* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: to be considered Jun 89

- ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: withdrawn; made editorial advice

+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?

+ EXIT-EXTENT
Version 6,  8-Jan-89, distributed Jan89 X3J13, Rereleased 16-Mar-89
Version 7, 4-Apr-89, as amended (not released to X3j13, on arisia)
Status: Passed, Mar 89 X3j13, as amended

+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13

+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended

+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988

+ FLET-IMPLICIT-BLOCK
Version 6, 5-JUN-87
Status: Passed, 1988

+ FORMAT-ATSIGN-COLON
Version 4, 5-JUN-87
Status: Passed, 1988

+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988

+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988

+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13

+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988

- FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: not submitted, will not be considered

+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13

+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988

- FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: withdrawn; request editor to rewrite as explicitly vague

+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89 (not released to X3j13; on arisia)
Status: Passed (as amended) Jan 89 X3J13
     maybe this was passed as amendment to TEST-NOT-IF-NOT instead

+ FUNCTION-DEFINITION
Version 3, 10-Feb-89 (not released to X3J13, on arisia)
Status: Passed (as amended) Jan 89 X3J13

+ FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
Version 1, 27-Jan-89, Released 16-Mar-89
Status: FUNCTION-NAME:LARGE with sections 7, 8, and 9 removed, passed
	Mar 89 X3J13

+ FUNCTION-TYPE
Version 12, 4-SEP-88, released 4-sep-88
Status: Passed, June 1988 X3J13, as amended

+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released  12-Dec-88
Status: Passed, Jan 89 X3J13

+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88 
Status: Passed, 1988

+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13

+ GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 3, 20-Mar-89, Released 23-Mar-89
Status: passed, Mar 89 X3J13 

+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89 (not released; on arisia)
Status: Passed (as amended) Jan 89 X3J13

+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988

+ HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 2, 13 Oct 88, released 16-Mar-89
Version 3, 5-Apr-89 (not released to X3j13; on arisia from KMP)
status: passed, as amended, Mar 89 X3J13 

+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
 from the generator in  the wrong order.
Status: passed, Jan 89 X3J13

- HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: didn't get to it; withdrawn

* HASH-TABLE-SIZE
Version 1, 20-Mar-89, released 21-Mar-89
Status: Postponed to Jun 89

+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 88
Status: passed Jan 89 X3J13

+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13

- IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
Status: didn't get to it by Mar 89; withdrawn

+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5, MAY-87
Status: Passed, 1988?

+ IN-PACKAGE-FUNCTIONALITY
Version 8, 15-Mar-89, Released 15-Mar-89
Version 9, 9-Apr-89, as amended Mar89 X3J13, (not released, on Arisia)
Status: passed, as amended, Mar 89 X3J13

+ IN-SYNTAX
Version 3,  9-Apr-89 (not released, on Arisia)
Status: Version 2 (without cost/benefit analysis, but same proposal)
	passed Mar 89 X3J13

+ KEYWORD-ARGUMENT-NAME-PACKAGE
Version 8, 8-NOV-87
Status: Passed, 1988?

+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?

+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13

+ LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Version 2,  9-Apr-89, as amended Mar 89 X3J13. Not released, on arisia
Status: passed, as amended, Mar 89 X3J13

+ LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Version 6,  9-Apr-89, as amended Mar 89 X3j13 (not released to X3j13, on arisia)
Status: passed, as amended, Mar 89 X3J13

+ LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Version 4, 4-Apr-89, (not released to X3J13, on arisia)
Status: passed, as amended, Mar 89 X3J13

* LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Version 2 mailed, withdrawn. KMP has amendments
Status: postponed to Jun 89

+ LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: passed, Mar 89 X3J13

+ LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: passed, Mar 89 X3J13

+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988

- MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: didn't get to Mar 89; withdraw? ???
(LMM: I'm uneasy about withdrawning.)

+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended 

- MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: withdrawn

+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13

+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89 (not released; on arisia)
Status: passed, as amended, Jan 89 X3J13

+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89 (not released; on arisia)
Status: Passed, Jan 89 X3J13, as amended

+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13

+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Version 4, 17-Mar-89, released 18-Mar-89
Status: passed, as amended, Jan 89 X3J13

* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME; add PATHNAME-CANONICAL-TYPE?
Version 1, 07-Jul-88
Status: postponed till Jun 89 X3J13

* PATHNAME-COMPONENT-CASE
Version 2, 22-Mar-89, released 22-Mar-89
Status: postponed till Jun 89 X3J13

* PATHNAME-COMPONENT-VALUE
Version 1, 20-Mar-89, released 21-Mar-89
Status: postponed till Jun 89 X3J13

* PATHNAME-EXTENSIONS
Version 1, 28-Dec-88
Status: ??? not discussed

* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet

* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88, released 23-Mar-89
Status: postponed? Mar 89 to Thursday but not to Jun?

+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988

* PATHNAME-SUBDIRECTORY-LIST
Version 4, 22-Mar-89, released 22-mar-89 (Moon's version)
Status: Postponed to Jun 89 X3J13

+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988

* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88, released 23-Mar-89
Comments: only want proposal PATHNAME-CREATION
Status: postponed to Jun 89 X3J13

+  PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89 (not released, on arisia)
Status: Passed, Jan 89 X3j13, as amended

* PATHNAME-WILD
Version 2
Status: postponed to Jun 89

*+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis:  PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
	Kim Barrett wants to reopen

* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: postponed to Jun 89 X3J13

+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?

* PRINT-CASE-PRINT-ESCAPE-INTERACTION
Version 1, 26-Jan-89
Status: postponed tues -> thur; didn't get to. Revisit, probably
	VERTICAL-BAR-RULE-NO-UPCASE

* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: didn't get to; withdraw? revisit?

+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89 (not released, on arisia)
Status: Passed, Jan 89 X3J13, as amended

- PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: amended, then failed, Mar 89 X3J13

+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988

+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13

+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Version 2, 23-Mar-89
Status: postponed to Jun 89; need one alternative

* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission

+ REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Version 4, 5-Apr-89, as amended (not released, on arisia)
Status: passed, as amended, Mar 89 X3j13

+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988

+ REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 7, 5-Apr-89 (not released, as amended, on arisia)
Status: passed, as amended, Mar 89 X3J13

+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
   (Motion to retract failed Mar 89 X3J13)

+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13

+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released  9-Dec-88
Status: passed, Jan 89 X3J13

+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13

* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 2, 22-Mar-89, released 22-Mar-89
Status: didn't get to Mar 89 X3J13.. withdraw?

+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...) 
Status: passed, Jan 89 X3J13

+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?

+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?

+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13

+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released  7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended

+ STREAM-ACCESS
Version 2, 30-Nov-88, Released  9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13

* STREAM-DEFINITION-BY-USER
Version 1, 22-Mar-89, Released hardcopy Mar 89 X3J13
Comments: Cleanup forum? For 'future directions'?

+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2 
Status: Passed, 1988?

- SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: missing writeup, didn't get to, withdraw

+ SUBTYPEP-TOO-VAGUE
Version 4,  7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13

+ SYMBOL-MACROLET-DECLARE
Version 2,  9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13

+ SYMBOL-MACROLET-SEMANTICS
Status: Version 5, Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: Version 6 (reconsidered), passed, Mar 89 X3J13

- TAIL-RECURSION-OPTIMIZATION
Version 2, Oct 88?
Status: dropped somehow?

+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13

+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec 
Version 4, 18-Mar-89
Status: Need new version as amended.

* THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: didn't come up Mar 89 X3J13; withdraw?

+ TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Version 2, 10-Apr-89, as amended Mar 89 X3J13 (not released, on arisia)
Status: passed, as amended, Mar 89 X3J13 

* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: Moon's comments, only some responses. Fix
Status: need new version

* UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: offline discussion about SLOT-UNBOUND
Status: ? didn't get to; withdraw?

+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13

+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13

+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88 
Status: Passed, 1988

* WITH-OPEN-FILE-DOES-NOT-EXIST
Version 1, 17-Mar-89
Status: didn't get to; withdraw?

∂10-Apr-89  1303	CL-Cleanup-mailer 	Issue: LOAD-TRUENAME (Version 3)    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89  13:02:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 574569; Mon 10-Apr-89 16:02:52 EDT
Date: Mon, 10 Apr 89 16:02 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890410160211.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

This is not just a report on what happened at the meeting.
In this version, I did the following:

 - Merged my `proposed amendments.'
 - Ignored Moon's version 2 by his request. It was only very slightly
   different than my `proposed amendments,' which he liked better.
 - Changed the description of the ...-PATHNAME* variables to say they
   hold a pathname that has already been merged with the defaults by
   LOAD and COMPILE-FILE.

The Proposal and Rationale are the only sections which changed since v1.
 -kmp

-----
Issue:        LOAD-TRUENAME
Forum:	      Cleanup
References:   LOAD (p426), PROVIDE (p188), REQUIRE (p188),
	      Issue REQUIRE-PATHNAME-DEFAULTS
Category:     ADDITION
Edit history: 13-Mar-89, Version 1 by Pitman
	      29-Mar-89, Version 2 by Moon (add -PATHNAME vars)
	      10-Apr-89, Version 3 by Pitman (clarify v2)

Problem Description:

 It is difficult to construct sets of software modules which work
 together as a unit and which port between different implementations.

 REQUIRE and PROVIDE were intended to provide this level of support
 but have `failed' to be portable in practice.

 Typical user configurations involve a `system definition' file which
 loads the modules of a `system' (collection of software modules).

 Among the specific problems which arise are:

  - File system types may vary. Different file syntax must be used for
    each site.

  - Even with the same Lisp implementation and host file system type,
    the directory in which a software system resides may differ from
    delivery site to delivery site.

  - Multiple `copies' of the same system may reside in different
    directories on the same machine.

Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):

 Introduce new variables:

   *LOAD-TRUENAME*					[Variable]

   This special variable is initially NIL, but is bound by LOAD to
   hold the truename of the pathname of the file being loaded.

   *COMPILE-FILE-TRUENAME*				[Variable]

   This special variable is initially NIL, but is bound by 
   COMPILE-FILE to hold the truename of the pathname of the file
   being compiled.
   
   *LOAD-PATHNAME*					[Variable]
  
   This special variable is initially NIL but is bound by LOAD
   to hold a pathname which represents the filename given as the
   first argument to LOAD merged against the defaults.
   That is, (PATHNAME (MERGE-PATHNAMES arg1)).
  
   *COMPILE-FILE-PATHNAME*				[Variable]
  
   This special variable is initially NIL but is bound by COMPILE-FILE
   to hold a pathname which represents the filename given as the
   first argument to COMPILE-FILE merged against the defaults.
   That is, (PATHNAME (MERGE-PATHNAMES arg1)).

Example:

 ------ File SETUP ------
 (IN-PACKAGE 'MY-STUFF)
 (DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
 (DEFVAR *SOURCE-FILE* (COMPILE-TRUENAME) "Just for debugging.")
 (DEFVAR *LOADED-FILE* *LOAD-TRUENAME*)
 (DEFUN LOAD-MY-SYSTEM ()
   (DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
     (LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-TRUENAME*))))
 ------------------------

 (LOAD "SETUP")
 (LOAD-MY-SYSTEM)

Rationale:

 This satisfies the most common instances of the frequently reported
 problem in the Problem Description.

 The ...-TRUENAME* variables are useful to tell the real file being
 loaded.

 The ...-PATHNAME* variables are useful to find information about
 the original link names or logical device names mentioned in the
 pathname to be opened but no longer reflected in the truename.

 Note that it is not adequate to just have the -PATHNAME* variables
 since TRUENAME on these pathnames might not yield the value of the
 -TRUENAME* variables if the file has been deleted or protected
 since the open occurred (in some implementations).

Current Practice:

 Wide variation.

 In some implementations, calling LOAD binds or sets 
 *DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
 LOADed will default to being `nearby.'

 Some implementations provide special variables that are similar or
 identical to one or both of those proposed.

 Some implementations have a way to represent the pathname for the
 current working directory, and make the default pathname default
 to that, so that loading without specifying a default again tends to
 get `nearby' files.

 None of these techniques is portable, unfortunately, because there
 is no agreement.

Cost to Implementors:

 Very small.

Cost to Users:

 None. This change is upward compatible.

Cost of Non-Adoption:

 Continued difficulty for anyone trying to put a system of modules
 in a form where they can be conveniently delivered using portable code.

Benefits:

 The cost of non-adoption is avoided.

Aesthetics:

 Negligible.

Discussion:

 Touretzky raised the issue most recently on Common-Lisp. A number
 of people immediately jumped on the bandwagon, indicating it was
 important to them, too.

 Pitman made three suggestions in response, of which the above is
 the first. The others included:
  2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
     lists of the truenames of all files being loaded or compiled,
     respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
 
  3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
    ((LOAD truename) (COMPILE-FILE truename) ...)
    during the dynamic invocation of LOAD and COMPILE-FILE.
 
 Touretzky responded:
 ``I like KMP's proposals.  I like the second one best: have separate
   variables for files being loaded and files being compiled, and use
   them to maintain a stack so we can see the nesting of loads within
   files.''

 Pitman ultimately chose to present the first rather than the second
 because it seemed simpler, easier to explain, and more likely to
 pass at this late date.


∂10-Apr-89  1349	CL-Cleanup-mailer 	Issue: LOAD-TRUENAME (Version 3)    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89  13:49:07 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 574621; Mon 10-Apr-89 16:48:51 EDT
Date: Mon, 10 Apr 89 16:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890410160211.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890410204842.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

I approve this version.  I checked it against the amendment
I had proposed.

In the example section,

     (LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-TRUENAME*))))

should be

     (LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-PATHNAME*))))

That's the whole reason for the amendment to add *LOAD-PATHNAME*!

The discussion section ought to include someone's suggestion that all
these variables could be replaced by *LOAD-STREAM* and
*COMPILE-FILE-STREAM*, combined with the existing PATHNAME and TRUENAME
functions.  It should also include someone else's suggestion that those
two variables could be replaced by *STANDARD-INPUT*.  I think there was
some argument against allowing access to the stream that convinced me to
support this proposal instead, but that other suggestion ought to be
given fair representation.

∂10-Apr-89  1621	CL-Cleanup-mailer 	Issue: PATHNAME-CANONICAL-TYPE 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89  16:21:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 574802; Mon 10-Apr-89 19:21:01 EDT
Date: Mon, 10 Apr 89 19:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-CANONICAL-TYPE
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890410232048.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

Larry suggests a simpler proposal than Kent's.  Here is some background
on pathname canonical types in general:

There are three purposes served by pathname canonical types:

(1) Construction.  There is currently no portable way to construct a
pathname that follows local file naming conventions.  For example, given
a program named "foo", we'd like to construct the conventional names for
its source and compiled files.  These will be "foo.l" and "foo.b" on one
system, "FOO.LSP" and "FOO.BIN" on another system, and "foo.lisp" and
"foo.ibin" on a third system.

More generally, we would like to be able to access naming conventions
for many types of files, not just Lisp source and compiled Lisp.  A
simplifying assumption is that all naming conventions affect only the
type field.  Thus a facility to translate canonical types into actual
types is sufficient.  Another assumption is that a given file system
always uses the same actual type for a given class of file; Symbolics
pathname canonical types are more general than this, but that is not
being proposed here, as it was primarily useful only in connection with
a transition between different releases of Unix, an application too
specialized to be enshrined in Common Lisp.

We would also like users to be able to define new classes of files of
their own, with associated file-system-dependent naming conventions.
For example, if I write a portable `defsystem', I would use a unique
naming convention for the file in which it stores its configuration
database.  The naming convention might not use the same string on every
file system, so it should be a canonical type.

(2) Recognition.  There is currently no portable way to classify a file
from its pathname.  If I write a portable editor, I would like to be
able to recognize the syntax of a program source file from its pathname
type field (Lisp, C, Ada, etc.)  The same table of local file naming
conventions used in part 1 can be accessed in reverse to translate an
actual type to a canonical type.  The editor can then look up the
canonical type in a table of known languages.

There is a tension here between two goals when there are subclasses of
files.  Consider two systems that can cross-compile for each other.
This clearly involves two canonical types for compiled Lisp files.
Should the canonical type reflect the system for which the file was
compiled, so that the canonical type of a particular file has the same
value in both systems?  Or should both systems use the same canonical
type for files compiled to be loaded locally, so that the canonical type
of a particular usage of a file has the same value in both systems?

(3) Translation.  There is currently no portable way to translate a
pathname written in the file naming conventions of one file system into
a pathname written in the file naming conventions of a different file
system.  A trivial use for this is cross-host pathname defaulting and
merging in a heterogeneous network, e.g. so a portable copy file command
can default the output file name intelligently.  A much more important
use is in logical pathnames (logical pathnames are a universal file
system that is mapped into the locally available file system through
site-dependent translations; this is primarily useful in software
distribution), where it is necessary to translate accurately between
logical pathname file naming conventions and local file naming
conventions.  The table of file naming conventions used in part 1 can be
accessed in reverse to identify the canonical type of a logical
pathname, and then accessed forwards to translate to the actual type to
be used on the local file system.

Whether we want Common Lisp to support these three features in a
portable fashion is of course a matter of policy.  Omitting any or all
of the features does not make the language unusable, it just means two
things: Users writing programs not intended to be portable will build
the local conventions directly into their programs, causing problems
later if they change their minds about portability.  Every user writing
a portable program that needs such capabilities has to implement them
himself, or obtain them from some supplier other than the Common Lisp
language, which will produce a small non-portable appendage to the
program that has to be redone for each port.

Critique of the proposals:

Larry's proposal addresses only the first paragraph of part 1.  It
does not allow user definition of file naming conventions and does
not support recognition or translation at all.

Kent's proposal addresses part 2 and the first paragraph of part 1.
It probably extends trivially to address part 3 as well, by adding
a statement that MERGE-PATHNAMES uses canonical types to merge
the type field.

As noted in the discussion section of the proposal, I would prefer
a proposal that addressed all three parts, which would require a
way to name file system types.  We could follow the standard defined
by the Internet Domain Name system.

∂11-Apr-89  0714	CL-Cleanup-mailer 	Issue: LOAD-TRUENAME (Version 4)    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 11 Apr 89  07:14:20 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 575061; Tue 11-Apr-89 10:12:53 EDT
Date: Tue, 11 Apr 89 10:12 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890411101208.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

New version to accomodate Moon's comments.

I changed the Example a bit.
I added a paragraph to the Discussion.
Everything else is the same.

I'm hoping this is a final version.
 -kmp

-----
Issue:        LOAD-TRUENAME
Forum:	      Cleanup
References:   LOAD (p426), PROVIDE (p188), REQUIRE (p188),
	      Issue REQUIRE-PATHNAME-DEFAULTS
Category:     ADDITION
Edit history: 13-Mar-89, Version 1 by Pitman
	      29-Mar-89, Version 2 by Moon (add -PATHNAME vars)
	      10-Apr-89, Version 3 by Pitman (clarify v2)
	      11-Apr-89, Version 4 by Pitman (merge Moon's v3 comments)

Problem Description:

 It is difficult to construct sets of software modules which work
 together as a unit and which port between different implementations.

 REQUIRE and PROVIDE were intended to provide this level of support
 but have `failed' to be portable in practice.

 Typical user configurations involve a `system definition' file which
 loads the modules of a `system' (collection of software modules).

 Among the specific problems which arise are:

  - File system types may vary. Different file syntax must be used for
    each site.

  - Even with the same Lisp implementation and host file system type,
    the directory in which a software system resides may differ from
    delivery site to delivery site.

  - Multiple `copies' of the same system may reside in different
    directories on the same machine.

Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):

 Introduce new variables:

   *LOAD-TRUENAME*					[Variable]

   This special variable is initially NIL, but is bound by LOAD to
   hold the truename of the pathname of the file being loaded.

   *COMPILE-FILE-TRUENAME*				[Variable]

   This special variable is initially NIL, but is bound by 
   COMPILE-FILE to hold the truename of the pathname of the file
   being compiled.
   
   *LOAD-PATHNAME*					[Variable]
  
   This special variable is initially NIL but is bound by LOAD
   to hold a pathname which represents the filename given as the
   first argument to LOAD merged against the defaults.
   That is, (PATHNAME (MERGE-PATHNAMES arg1)).
  
   *COMPILE-FILE-PATHNAME*				[Variable]
  
   This special variable is initially NIL but is bound by COMPILE-FILE
   to hold a pathname which represents the filename given as the
   first argument to COMPILE-FILE merged against the defaults.
   That is, (PATHNAME (MERGE-PATHNAMES arg1)).

Example:

 ------ File SETUP ------
 (IN-PACKAGE "MY-STUFF")
 (DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
 (DEFVAR *MY-COMPILE-TRUENAME* (COMPILE-TRUENAME) "Just for debugging.")
 (DEFVAR *MY-LOAD-PATHNAME* *LOAD-PATHNAME*)
 (DEFUN LOAD-MY-SYSTEM ()
   (DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
     (LOAD (MERGE-PATHNAMES MODULE-NAME *MY-LOAD-PATHNAME*))))
 ------------------------

 (LOAD "SETUP")
 (LOAD-MY-SYSTEM)

Rationale:

 This satisfies the most common instances of the frequently reported
 problem in the Problem Description.

 The ...-TRUENAME* variables are useful to tell the real file being
 loaded.

 The ...-PATHNAME* variables are useful to find information about
 the original link names or logical device names mentioned in the
 pathname to be opened but no longer reflected in the truename.

 Note that it is not adequate to just have the -PATHNAME* variables
 since TRUENAME on these pathnames might not yield the value of the
 -TRUENAME* variables if the file has been deleted or protected
 since the open occurred (in some implementations).

Current Practice:

 Wide variation.

 In some implementations, calling LOAD binds or sets 
 *DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
 LOADed will default to being `nearby.'

 Some implementations provide special variables that are similar or
 identical to one or both of those proposed.

 Some implementations have a way to represent the pathname for the
 current working directory, and make the default pathname default
 to that, so that loading without specifying a default again tends to
 get `nearby' files.

 None of these techniques is portable, unfortunately, because there
 is no agreement.

Cost to Implementors:

 Very small.

Cost to Users:

 None. This change is upward compatible.

Cost of Non-Adoption:

 Continued difficulty for anyone trying to put a system of modules
 in a form where they can be conveniently delivered using portable code.

Benefits:

 The cost of non-adoption is avoided.

Aesthetics:

 Negligible.

Discussion:

 Touretzky raised the issue most recently on Common-Lisp. A number
 of people immediately jumped on the bandwagon, indicating it was
 important to them, too.

 Pitman made three suggestions in response, of which the above is
 the first. The others included:
  2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
     lists of the truenames of all files being loaded or compiled,
     respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
 
  3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
    ((LOAD truename) (COMPILE-FILE truename) ...)
    during the dynamic invocation of LOAD and COMPILE-FILE.
 
 Touretzky responded:
 ``I like KMP's proposals.  I like the second one best: have separate
   variables for files being loaded and files being compiled, and use
   them to maintain a stack so we can see the nesting of loads within
   files.''

 Pitman ultimately chose to present the first rather than the second
 because it seemed simpler, easier to explain, and more likely to
 pass at this late date.

 Other suggestions which were considered discarded were:
  a. Provide just variables *LOAD-STREAM* and *COMPILE-FILE-STREAM*.
     Then PATHNAME and TRUENAME could be used to yield the 
     information contained in the -PATHNAME* and -TRUENAME* variables
     of the proposal above.
  b. Like (a), but call both variables *STANDARD-INPUT*. That is,
     say that LOAD and COMPILE-FILE bind *STANDARD-INPUT* to the
     stream being loaded.
 There were a number of pitfalls with this approach which all center
 around the way it invites the user to do other operations besides
 PATHNAME and TRUENAME.  Not only would some people be confused by
 the difference between the characteristics of *LOAD-STREAM* for
 compiled and interpreted files, but also even with interpreted 
 streams, the actual position of the stream pointer at the time of
 execution of the forms contained in the file could vary between
 implementations in a way that became a lurking portability barrier.
 Since the observed user need which spawned this discussion was for
 a way to tell what file was being loaded and not for a way to 
 manipulate the stream, it seemed best to just go with the variables
 that addressed that specific need--fewer pitfalls and more perspicuous
 code are likely to result.

∂11-Apr-89  2155	CL-Cleanup-mailer 	Re: Issue: PATHNAME-CANONICAL-TYPE  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Apr 89  21:55:01 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 89 21:54:37 PDT
Date: 11 Apr 89 21:53 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Mon, 10 Apr 89 19:20 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@sail.stanford.edu
Message-ID: <890411-215437-9502@Xerox>

I like your analysis. My argument is that the first paragraph of (1) is the
"most important", and is the only one that I think can be solved. While we
can make some requirements on lisp system's naming conventions, e.g., that
the naming convention that distinguishes a Lisp source and compiled Lisp
must affect only the type field, we can't require that of other
applications. Since your "assumptions" are often false ("all naming
conventions affect only the type field", "a given file system always uses
the same actual type for a given class of file"), a design which presumes
they are true are not good canditates for the standard. 
Similarly, there are numerous file systems where there is no good canonical
mapping from pathname-type to actual knowledge of the kind of file, and so
the prerequesites are not satisifed for being able to do recognition and
translation based merely on pathname-type. (I'm thinking of the Macintosh,
where the actual file type is frequently encoded not in the pathname but
rather in the 'creator' and 'type' fields, and DOS, where the three
character limit means that the same pathname-type is frequently used for
different interpretations by different applications, and some Xerox
systems, where the actual file type is encoded by a 16-bit file attribute,
etc.)

I don't think it is merely a matter of policy whether Common Lisp should
support all three features; I think it is also a matter of feasibility. If
supporting the features is in fact impossible in many file systems, we
shouldn't require them to be supported. Since Lisp implementors have
control over the file types used by their compiler, we can require
canonical values for make-pathname, however.

∂12-Apr-89  1012	CL-Cleanup-mailer 	issue PRETTY-PRINT-INTERFACE   
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Apr 89  10:12:12 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA07535; Wed, 12 Apr 89 11:12:05 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA03186; Wed, 12 Apr 89 11:12:03 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904121712.AA03186@defun.utah.edu>
Date: Wed, 12 Apr 89 11:12:02 MDT
Subject: issue PRETTY-PRINT-INTERFACE
To: cl-cleanup@sail.stanford.edu

I've finally found time to look over the hardcopy of this issue that
was distributed at the March meeting, but I'm having an extremely
difficult time parsing it.  The description is spread out in too many
places (the proposal section, the list of amendments, and the attached
document), and there are some things mentioned in the discussion
section that appear to contradict what is actually in the proposal
(like whether the list form of the CONS type specifier is a real type
specifier or not).  Can somebody please revise this writeup so that it
is organized more coherently?  I realize this issue is long and
complicated, but improving the presentation would make it a lot more
understandable. 

-Sandra
-------

∂14-Apr-89  0700	CL-Cleanup-mailer 	Status of CL Condition Handling
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 14 Apr 89  07:00:00 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 577300; Fri 14-Apr-89 10:00:03 EDT
Date: Fri, 14 Apr 89 09:59 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Status of CL Condition Handling
To: CL-Cleanup@SAIL.Stanford.EDU, CL-Error-Handling@SAIL.Stanford.EDU
cc: Gateley@tilde.csc.ti.com
In-Reply-To: <2817520854-15094035@Casablanca>
Message-ID: <890414095910.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

Messages like the following are increasingly common these days.

    Date: Thu, 13 Apr 89  23:40:54 CDT
    From: John Gateley <Gateley@tilde.csc.ti.com>
    Subject: CLEH

    Could you send me a pointer to the latest description of CLEH? I have
    the 3/12/88 version of 'Condition System Revision 18'?
    I checked with David Bartley, our representative to X3J13 and he doesn't
    have anything more recent.

I really don't mind fielding this sort of question and have been doing so
for a long time, but since it has been asked a lot lately, I'm sending this
one-shot message just so there will be a recent message that people can
refer to when bringing others up to date.

----- Status of Condition Handling in Common Lisp, April 1989 -----

  The most current revision of the error handling document is
  Common Lisp Condition System, Version 18. This document was voted
  in to CL (in the same sense as CLOS and LOOP have been) and in my
  mind it occupies essentially the same status in the standard as 
  does CLtL. That is, it has been affected by and may be further
  affected by action of the Cleanup committee. The effect of its
  acceptance was not to cast it in concrete and prohibit change,
  but rather to establish that the default is that what it says will
  end up in the standard unless someone acts to change that default.
  Until the standard is finally voted in as a single unit, nothing is
  a certainty.

  Version 18 of the condition proposal document is available from
  AI.AI.MIT.EDU in the file named "COMMON;COND18 TEXT".

  A `sample implementation' is available from AI.AI.MIT.EDU in the
  file named "COMMON;COND18 LISP".  The sample implementation is not
  binding on the proposal text. It is merely `recommended reading'
  for anyone who is about to implement the proposal.

  With the advent of the proposal's adoption by X3J13 last fall, the
  the error handling subcommittee was effectively disbanded.  I seem
  to still be handling some of what would have been its business, but
  I no longer formally consider the group to be an active one or myself
  to be the moderator.  Changes since the proposal have been and are
  being handled by the Cleanup committee.

  The window is closed for most Cleanup changes which are feature
  additions. The effect of this is that CL-ERROR-HANDLING@SAIL.STANFORD.EDU
  is a dormant list.  As cleanup items are approved, no new central
  error handling document is being produced to minimize administrative
  overhead.  The approved items will be directly absorbed by the full
  standard document itself.

  At this point, the only changes being seriously considered by Cleanup
  are `essential functionality' that has slipped through the cracks,
  or `clarifications' and `bug fixes.'

  The cleanup items which are of most interest are:

    CLOS-CONDITIONS - Version 4, option INTEGRATE was adopted at the
      Mar-89 meeting.

    ERROR-CHECKING-IN-NUMBERS-CHAPTER - A proposal for what conditions
      should be signalled (and when) by the functions in the numbers
      chapter. This will be discussed at the next X3J13 meeting. Other
      proposals of similar kind may appear at that time as well.

    CONDITION-RESTARTS - A proposal for associating conditions with
      restarts. This has been a long-acknowledged weakness in the
      condition system.  This proposal will come up in some form at the
      next X3J13 meeting, but will probably change before it does.
      Some changes under consideration:
       - Eliminate the proposed COPY-CONDITION function
       - Eliminate SIGNAL-WITH-RESTARTS in favor of a change to
	 RESTART-CASE that makes it automatically create an association
	 when its first `argument' is a SIGNAL, WARN, ERROR, or CERROR
	 expression.
       - Change the syntax of WITH-CONDITION-RESTARTS to get 
	 condition-form and restarts-form as two arguments instead of
	 as one argument with funny syntax.

  These cleanup items are generally available via anonymous FTP from 
  ARISIA.XEROX.COM in the directories /clcleanup/pending/ and
  /clcleanup/passed/, depending on whether they are pending or passed.

  Cleanup items for which there is some interest but not yet any proposal
  are:

    CONDITIONS-PACKAGE - Some people think the LISP package (now the
      COMMON-LISP package, I guess, since a recent vote on issue
      LISP-PACKAGE-NAME) is too cluttered and that we should make a new
      package for some of the CONDITIONS stuff. (Many of the same people
      think the same about CLOS, by the way.)

    CONDITION-METACLASS - We've never specified the metaclass of
      conditions so right now you can really only safely mix together
      condition classes with other condition classes. People have
      expressed interest in doing other kinds of mixing, which would
      require knowing the metaclass of objects of class CONDITION.

  If this leaves unanswered questions about any of this and you are
  not an X3J13 representative, please direct them first to the X3J13
  rep from your organization. If you have no rep or if your rep can't
  answer your question (or if you are the rep and can't answer your own
  question :-), you can direct your queries directly to me if you don't
  consider them of broad interest and just want them handled privately.

∂17-Apr-89  1301	CL-Cleanup-mailer 	[Robert S. Boyer <boyer@CLI.COM>: Fast IO]    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Apr 89  13:01:31 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 17 APR 89 12:44:48 PDT
Date: 17 Apr 89 12:44 PDT
From: masinter.pa@Xerox.COM
Subject: [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
To: cl-cleanup@sail.stanford.edu
cc: wfs@CLI.COM, boyer@CLI.COM
reply-to: cl-cleanup@sail.stanford.edu, wfs@CLI.COM, boyer@CLI.COM
Message-ID: <890417-124448-22081@Xerox>

If two implementations need some declaration for 'simple' streams so that
READ-CHAR and friends can be fast, maybe this is a more generally felt
need? I thought I'd go ahead and forward to a wider forum....



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

Date: Mon, 17 Apr 89 14:31:51 CDT
From: Robert S. Boyer <boyer@CLI.COM>
To: masinter.pa
Cc: wfs@CLI.COM, jonl@lucid.com
Subject: Fast IO
Reply-To: boyer@cli.com

Sorry for not being informative about read-char, fast-read-char, and
:in-line.

In both Lucid and AKCL, it takes about 60 microseconds on a Sun-3/280
to do a read-char or read-byte in the usual case.  That is a lot of
time!  I am not really sure why it should take so long, but it does.
Something about doing necessary checking that the stream is not fancy,
bidirectional, etc., etc.  (I am not making exact timing remarks here
-- just ballpark.)

Of course, in Unix on a Sun-3/280, the C programmer can get a
character in a couple of microseconds (again, ballpark).  So both
Lucid and AKCL have non-CLTL extensions to make it possible to move
characters at microsecond speeds.  Lucid does this by defining 6
functions that have a "fast-" prefix, e.g. fast-read-char.  AKCL
(1.112) adds a new declaration (:in-line) whose semantics is something
like "I hereby assert that here is a really simple sort of stream and
I want the AKCL compiler to therefore lay down fast code for
read-char".

If these explanations don't suffice, I'm in over my head.  I am
speaking here just as a user, not an implementor; but I am a user who
sees the necessity of a fast way to read characters in any Common
Lisp.  I suspect that since both AKCL and Lucid have run into this
problem, other von Neumann machine Lisps will too.  (In fact, my
recollection is that read-char stood a lot of room for speeding up on
Lispms, too, perhaps for the same reasons.)

I personally like the AKCL idea of somehow adding a declaration that a
stream is "simple".  As it is, in our theorem-prover code we now do a
(proclaim '(declaration :in-file)), which, as I understand it, means
that :in-file declarations will be ignored by, say, the Lucid compiler
or any other compiler that doesn't know about :in-line.  read-char
will go fast in AKCL, but the code will also work in Lucid.  If we
were to use Lucid's fast-read-char, say, that would work for Lucid but
we would need dialect conditionals defining such a function to get
fast-read-char to work in other Lisps besides Lucid.  We abhor dialect
conditionals.

I would much prefer a CLTL uniform nomenclature, any nomenclature,
fast-read-char, :in-line, or anything else.

Thanks,

Bob

P.S.  If you have any serious questions about :in-line, I suspect that
Schelter (wfs@cli.com) will be happy to answer them.



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

∂19-Apr-89  0707	CL-Cleanup-mailer 	[Robert S. Boyer <boyer@CLI.COM>: Fast IO]    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89  07:07:32 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 580833; Tue 18-Apr-89 19:20:16 EDT
Date: Tue, 18 Apr 89 19:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
To: cl-cleanup@sail.stanford.edu, wfs@CLI.COM, boyer@CLI.COM
In-Reply-To: <890417-124448-22081@Xerox>
Message-ID: <19890418232014.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

Symbolics Genera is even slower at read-char.  But I don't think a
declaration is the answer.  I believe that if we wanted to make
read-char fast on streams where it can be fast (simple buffered
streams), a simple-stream declaration would not add any significant
additional speed.  It might save about 2 microseconds for an indirect
call.  This is assuming that compatibility with past implementations
of streams was not an issue (and I don't think it's reasonable in
designing a new language to assume that such would be an issue).

I know that Symbolics Genera read-char is slow because we haven't
made any effort to make it fast, not because non-simple streams make
it impossible to make it fast.  I can't speak for Lucid but I wouldn't
be surprised if the story is the same for them.  So I'd oppose adding
anything to the language in this area.  Instead, customers should signal
to implementors their discontent with the current quality of implementation
of read-char.  Implementors can then raise the priority of that and
possibly shift resources from other things.

∂19-Apr-89  1519	CL-Cleanup-mailer 	no :in-file
Received: from CLI.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89  15:18:54 PDT
Received: by CLI.COM (4.0/1); Wed, 19 Apr 89 17:15:32 CDT
Date: Wed, 19 Apr 89 17:15:32 CDT
From: Robert S. Boyer <boyer@CLI.COM>
Message-Id: <8904192215.AA03885@CLI.COM>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, wfs@CLI.COM
Subject: no :in-file
Reply-To: boyer@cli.com

I now concur with Moon's view that stream declarations are unnecessary
in principle, especially in view of the fact that Bill Schelter has
now implemented very fast (couple of microsecond)
read/write//char-byte in AKCL without the necessity of declarations or
specially named functions.

∂19-Apr-89  1528	CL-Cleanup-mailer 	[Robert S. Boyer <boyer@CLI.COM>: Fast IO]    
Received: from CLI.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89  15:28:36 PDT
Received: by CLI.COM (4.0/1); Wed, 19 Apr 89 17:24:42 CDT
Date: Wed, 19 Apr 89 17:24:42 CDT
From: Bill Schelter <wfs@CLI.COM>
Message-Id: <8904192224.AA03946@CLI.COM>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, boyer@CLI.COM
In-Reply-To: David A. Moon's message of Tue, 18 Apr 89 19:20 EDT <19890418232014.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
Reply-To: wfs@cli.com


I had originally felt it might be a good idea to have a specialized
type of stream for faster io in common lisp, but now am in accord with
Moon that this is simply not necessary.

Just before receiving his message I had finished reworking the
write-byte/write-char and read-byte/read-char WITHOUT declarations, so
they are now in the 2 to 3 microsecond range respectively, in
AKCL(version 1.116) on a sun3/280.  The difference between this and
what I could do with a specialized stream was practically not possible
to time, when reading or writing a million characters.  Of course
streams other than file streams and interprocess streams are still
substantially slower, but that is probably reasonable (for the
moment..).

Bill Schelter




∂19-Apr-89  1557	CL-Cleanup-mailer 	no :in-file
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Apr 89  15:54:32 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA11844g; Wed, 19 Apr 89 15:54:11 PDT
Received: by blacksox id AA01834g; Wed, 19 Apr 89 15:53:40 PDT
Date: Wed, 19 Apr 89 15:53:40 PDT
From: Eric Benson <eb@lucid.com>
Message-Id: <8904192253.AA01834@blacksox>
To: boyer@cli.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu,
        wfs@CLI.COM
In-Reply-To: Robert S. Boyer's message of Wed, 19 Apr 89 17:15:32 CDT <8904192215.AA03885@CLI.COM>
Subject: no :in-file

However, in order to be competitive with C in speed it would be useful
to be able to do the following:

For binary streams, declare the element-type of the stream, e.g. allow
the STREAM type specifier to take an optional element-type like ARRAY
and COMPLEX.

For binary streams, functions to read and write arrays in a single
chunk.  Lucid supplies READ-ARRAY and WRITE-ARRAY as extensions.

For character input, a destructive version of READ-LINE.

∂19-Apr-89  1621	CL-Cleanup-mailer 	no :in-file
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89  16:21:42 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 581565; Wed 19-Apr-89 19:21:33 EDT
Date: Wed, 19 Apr 89 19:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: no :in-file
To: Eric Benson <eb@lucid.com>
cc: boyer@cli.com, cl-cleanup@sail.stanford.edu, wfs@CLI.COM
In-Reply-To: <8904192253.AA01834@blacksox>
Message-ID: <19890419232148.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 19 Apr 89 15:53:40 PDT
    From: Eric Benson <eb@lucid.com>

    However, in order to be competitive with C in speed it would be useful
    to be able to do the following:

    For binary streams, declare the element-type of the stream, e.g. allow
    the STREAM type specifier to take an optional element-type like ARRAY
    and COMPLEX.

I see no harm in this, if someone wants to propose it.  I'm not sure
whether Symbolics would use it, but I think it's a reasonable thing
for imaginable implementations to want.

    For binary streams, functions to read and write arrays in a single
    chunk.  Lucid supplies READ-ARRAY and WRITE-ARRAY as extensions.

    For character input, a destructive version of READ-LINE.

Symbolics Genera has the equivalent of all of these under different
names.  The read-array and write-array (shouldn't they be called
read-vector and write-vector?) are generic and work for character
streams as well, given a string as the vector.  Someone should write
a proposal for these features.  It might or might not be too late
to add this to X3J13 Common Lisp, but at least everybody could use
compatible names for their extensions.

∂20-Apr-89  1454	CL-Cleanup-mailer 	Issue: THE-VALUES [was: intent of (THE <type> <expression>)] 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 20 Apr 89  14:54:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 582196; Thu 20-Apr-89 17:54:13 EDT
Date: Thu, 20 Apr 89 17:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: THE-VALUES [was: intent of (THE <type> <expression>)]
To: gls@Think.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8904202059.AA00383@joplin.think.com>
Message-ID: <890420175328.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

[Outside world removed.]

    Date: Thu, 20 Apr 89 16:59:15 EDT
    From: Guy Steele <gls@Think.COM>
       ...
       PROPOSAL:

       What it boils down to, is that THE should check only as many types
       as requested (and pass back only as many).

    No, this is not cool.  THE is supposed to act purely as a declaration,
    but you are changing it to require it to pass on only as many values
    as the type specifer indicates.  This could change the semantics of
    a suitably devious program.

    Better to say that it checks as many types as requsted, but passes on
    exactly the values it receives.
    --Guy

Even though I agree with your position, I think it's worth our writing up
a clarification issue to make sure we're all agreed and that it's 100% clear
in the ANSI spec.

∂20-Apr-89  2003	CL-Cleanup-mailer 	Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)    
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 20 Apr 89  20:03:37 PDT
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
	Thu, 20 Apr 89 22:04:03 CDT id AA13750 for cl-cleanup@sail.stanford.edu
Posted-Date: Thu, 20 Apr 89 22:02:30 CDT
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
	id AA08661; Thu, 20 Apr 89 22:02:30 CDT
Date: Thu, 20 Apr 89 22:02:30 CDT
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8904210302.AA08661@pavo.src.honeywell.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 18 Apr 89 13:19 <8904181723.AA03079@decwrl.dec.com>
Subject: Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)

>IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat the
>			situation in ANY ONE of the following ways: (1)
>			When the situation occurs, an error should be 
>			signalled at least in safe code, OR (2) When the 
>			situation occurs, the "consequences are undefined", 
>			OR (3) When the situation occurs, the consequences are

Item (1) should either be:

  When the situation occurs, an error "should be signalled",

Or simply deleted entirely since it is really a subset of (2)/(3)

>WARNING IS ISSUED	A warning is issued, as described in WARN, in
>			both safe and unsafe code when the situation
>			is detected. Conforming code may rely on the
>			fact that a warning will be issued in both
>			safe and unsafe code when the situation is
>			detected.  Every implementation is required to
>			detect this situation in both safe and unsafe
>			code when the situation is detected. The
>			presence of a warning will in no way alter the
>			value returned by the form which caused the
>			situation to occur. For example, "a warning is
>			issued if a declaration specifier is not one
>			of those defined in Chapter 9 of CLtL and has
>			not been declared in a DECLARATION
>			declaration."

"Every implementation is required to detect this situation in both safe and
unsafe code."  (i.e. delete the "when the situation is detected").

Also; "The presence of a warning will in no way alter the value
returned..." is a little strong.  I think some weasel words like "in the
absence of handlers for contitions of type warning, the presence of a
warning will ...".  Unless of course we intend to disallow users from
setting up handlers for warnings that throw out, which would of course
change the value returned since there wouldn't be any.

∂24-Apr-89  1249	CL-Cleanup-mailer 	Issue COMPLEX-RATIONAL-RESULT, version 2 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 24 Apr 89  12:49:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 583636; Mon 24-Apr-89 15:48:28 EDT
Date: Mon, 24 Apr 89 15:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue COMPLEX-RATIONAL-RESULT, version 2
To: gls@THINK.COM, Masinter.pa@XEROX.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8904090537.AA00468@brigit.think.com>
Message-ID: <19890424194840.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

The opinion at Symbolics is that your version 2 is good.  Let's
vote it in to replace the version 1 that X3J13 already voted in.
Should we take time in June to do this, or do it by letter?

Some TeX markup snuck into the proposal section, please remove it
before releasing.

The current practice section is out of date, since there are four
examples now.  I'd change it to:
  
  Symbolics Genera 7.4 returns a (complex single-float) for the first
  example, returns 1 for the second example, and returns the specified
  answers for the third and fourth examples.  Other implementations were
  not surveyed.

Guy if you'd like to survey some other implementations that could be
helpful.

∂28-Apr-89  0944	CL-Cleanup-mailer 	Issue COMPLEX-RATIONAL-RESULT, version 3 
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 28 Apr 89  09:44:06 PDT
Received: from fafnir.think.com by Think.COM; Fri, 28 Apr 89 12:44:13 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 28 Apr 89 12:43:29 EDT
Received: from joplin.think.com by verdi.think.com; Fri, 28 Apr 89 12:43:26 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Fri, 28 Apr 89 12:43:24 EDT
Date: Fri, 28 Apr 89 12:43:24 EDT
Message-Id: <8904281643.AA05966@joplin.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: Issue COMPLEX-RATIONAL-RESULT, version 3

Version 3 fixes typos and surveys a few implementations.
Prologue to version 2 follows.

This was a good thing for Moon to bring up, but I think a couple
of desirable details were left uncovered.  Here is a new version
to consider in June.

Detail 1 is that a mathematically rational or complex rational
value might result from arguments that are a mixture of rational
and complex rational; or a complex rational value might result
from arguments that are rational only.

Detail 2 is that the version 1 proposal mentions (complex float)
where I believe the more specific (complex single-float) is appropriate.

Detail 3 is that in some cases the option of an ordinary float
result is desirable or required rather than a (complex single-float);
consider the ABS function, for example.

Detail 4 is that if the true mathematical result is not rational
or complex rational, I think we want to specify that the returned
value is single-float or (complex single-float).

----------------------------------------------------------------
Issue:         COMPLEX-RATIONAL-RESULT

References:    CLtL p.203

Category:      CLARIFICATION

Edit history:  Version 1, 20-Mar-89, by Moon
               Version 2, 08-Apr-89, by Steele
               Version 2, 28-Apr-89, by Steele

Problem description:
  
  Referring to irrational and transcendental functions, CLtL says:
    
    When the arguments to a function in this section are all rational and
    the true mathematical result is also (mathematically) rational, then
    unless otherwise noted an implementation is free to return either an
    accurate result of type rational or a single-precision floating-point
    approximation.  If the arguments are all rational but the result cannot
    be expressed as a rational number, then a single-precision
    floating-point approximation is always returned.

  Referring to EXPT, CLtL says:

    If the base-number is of type RATIONAL and the power-number is an
    INTEGER, the calculation will be exact and the result will be of
    type RATIONAL; otherwise a floating-point approximation may result.

  What about arguments of type (complex rational)?

Proposal (COMPLEX-RATIONAL-RESULT:EXTEND):

  Extend the paragraph quoted above as follows to cover the components
  of complex numbers.  If the arguments to a function are all of type
  (OR RATIONAL (COMPLEX RATIONAL)) and the true mathematical result is
  (mathematically) a complex number with rational real and imaginary
  parts, then unless otherwise noted an implementation is free to return
  either an accurate result of type (OR RATIONAL (COMPLEX RATIONAL)) or
  a single-precision floating-point approximation of type SINGLE-FLOAT
  (permissible only if the imaginary part of the true mathematical
  result is zero) or (COMPLEX SINGLE-FLOAT). If the arguments are
  all of type (OR RATIONAL (COMPLEX RATIONAL)) but the result cannot be
  expressed as a rational or complex rational number, then the returned
  value will be of type SINGLE-FLOAT (permissible only if the imaginary
  part of the true mathematical result is zero) or (COMPLEX SINGLE-FLOAT).

  For EXPT of a (COMPLEX RATIONAL) to an integer power, the
  calculation must be exact and the result will be of type
  (OR RATIONAL (COMPLEX RATIONAL)).

Examples:

[a]  (log #c(-16 16) #c(2 2)) => 3 or approximately #c(3.0 0.0)
			           or approximately 3.0 (unlikely)
[b]  (abs #c(3/5 4/5)) => 1 or approximately 1.0
[c]  (expt #c(2 2) 3) => #c(-16 16)
[d]  (expt #c(2 2) 4) => -64 

Rationale:
  
  This seems most consistent with the treatment of real numbers.

Current practice:
  
			[a]			[b]	[c]		[d]
Symbolics Genera 7.4	#c(3.00... 1.40...e-7)	1	#c(-16 16)	-64
Sun Common Lisp 3.0.1	#c(3.0 2.61...e-16)	1.0	#c(-16 16)	-64
KCL of 9/16/86 on VAX	#c(3.0s0 -1.40...s-7)	1.0s0	#c(-16 16)	-64
Allegro CL (Mac II)	#c(3.0 2.05...e-16)	1.0	#c(-16 16)	-64

Cost to Implementors:

  Only EXPT would have to change, since the type of the other results
  is at the discretion of the implementation.

Cost to Users:

  Probably none, but it is hard to predict.

Cost of non-adoption:
  
  Slightly less self-consistent language.

Performance impact:

  None of any significance.

Benefits/Esthetics:

  More self-consistent language.

Discussion:

  None.

∂28-Apr-89  1426	CL-Cleanup-mailer 	ISSUE: GCD-LCM-ZERO-ARGS  
Received: from hub.ucsb.edu (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 28 Apr 89  14:26:38 PDT
Received: from csilvax.ucsb.edu
	by hub.ucsb.edu (5.59/UCSB-v2)
	id AA22234; Fri, 28 Apr 89 14:27:18 PDT
Message-Id: <8904282127.AA22234@hub.ucsb.edu>
Received: from  by csilvax.ucsb.CSNET (5.51) id AA14455; Fri, 28 Apr 89 14:25:34 PDT
Date: Fri, 28 Apr 89 14:25:34 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Fri, 28 Apr 89 14:25:34 PDT
To: CL-cleanup@SAIL.Stanford.edu
Subject: ISSUE: GCD-LCM-ZERO-ARGS
Cc: skona%csilvax@hub.ucsb.edu

Issue:         GCD-LCM-ZERO-ARGS
References:    CLtl pg.202 and Document 86-003 pg.3
Category:      CHANGE
Edit history:  Revision 1 by Skona Brittain 03/22/87
               Revision 2 by Skona Brittain 01/06/89
               Revision 3 by Skona Brittain 04/28/89 (removed references to
                                                     cases of no args to lcm)

Problem Description:

These functions are not well-defined for sets of arguments 
that include the number zero.


Proposal (GCD-LCM-ZERO-ARGS:NOT-ALLOWED):

The arguments to lcm and gcd must be positive integers.


Test Case:

(lcm 1 0) would be an error instead of having the value 0.


Rationale:

Having the least common multiple of a set of numbers be less than 
the least common multiple of a proper subset of that set 
violates monotonicity.  For example, monotonicity is violated by 
      (lcm 1 0) < (lcm 1)   and   (lcm 0) < (lcm).
Increasing the restrictions on the candidates for the lcm should 
only be able to increase the value of the least qualifying one.
What the first example is saying is that the the least multiple 
of 1 is 1 but the least number that is a multiple of both 1 and 0
is 0.  This is patently ridiculous.  Any reasoning that says that
0 is the lcm of 1 & 0 would also say that 0 is the lcm of 1 alone,
since 0 would be considered a multiple of 1 and is less than 1.  
Furthermore, it would say that 0 is the result of the lcm operation 
on any set of arguments at all.  Although this would be mathematically 
consistent, it would not make lcm a very useful operator.

The root of the problem is that it is unnatural to apply lcm or 
gcd to anything but natural numbers.  Negative numbers are not 
having much of an effect because they are just being treated as
if they were their absolute values, i.e. the negativity of negative 
arguments is ignored, but zero really screws things up.  If it is 
desired that zero be an allowed argument, it should also just be ignored, 
(i.e passed over, the way nil in an association list is passed over) 


Current Practice:

I know of no implementations that currently implement this change.


Cost to Users:

Very slight.


Cost to Implementors:

Very slight.  Should lead to a reduction in code, since most algorithms 
for computing gcd and lcm are for positive integers anyway.


Benefits:

see Esthetics.


Esthetics:

Mathematical correctness is much more aesthetic than its alternatives.


Discussion:
  

∂28-Apr-89  1606	CL-Cleanup-mailer 	Issue: MULTIPLICATION-ZERO-ARGS
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 28 Apr 89  16:06:30 PDT
Received: from fafnir.think.com by Think.COM; Fri, 28 Apr 89 18:17:10 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 28 Apr 89 18:16:27 EDT
Received: from joplin.think.com by verdi.think.com; Fri, 28 Apr 89 18:16:22 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Fri, 28 Apr 89 18:16:19 EDT
Date: Fri, 28 Apr 89 18:16:19 EDT
Message-Id: <8904282216.AA05993@joplin.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: Issue: MULTIPLICATION-ZERO-ARGS

Issue:         MULTIPLICATION-ZERO-ARGS
References:    CLtl p. 199
Category:      CHANGE
Edit history:  Version 1 by Guy Steele 04/28/89


Problem Description:

This function is not well-defined for sets of arguments 
that include the number zero.


Proposal (MULTIPLICATION-ZERO-ARGS:NOT-ALLOWED):

Integer arguments to * must be non-zero.


Test Case:

(* 1 0) would be an error instead of having the value 0.


Rationale:

Having the product of a set of integers be less than 
the product of a proper subset of that set 
violates monotonicity.  For example, monotonicity is violated by 
      (* 6 0) < (* 6)   and   (* 0) < (*).
The multiset of prime factors of a product is the union of the
multisets of prime factors of the numbers being multiplied.
Increasing the multiset of prime factors that contribute to the
result should only be able to increase the value of result.
What the first example is saying is that the multiset of factors
of 6 has two elements {2, 3} but the product of both 6 and 0
does not.  This is patently ridiculous.  Any reasoning that says that
0 is the product of 6 & 0 would also say that 0 is the product of 6 alone,
since 0 has all the prime factors that 6 does and is the smallest such number.
Furthermore, it would say that 0 is the result of the multiplication operation 
on any set of arguments at all.  Although this would be mathematically 
consistent, it would not make multiplication a very useful operator.

The root of the problem is that it is unnatural to apply multiplication to
anything but natural numbers.  Multiplication over the positive integers
forms a monoid, and over the rational numbers forms a group.  Negative
numbers do not have much of an effect because they can be treated as if
they were their absolute values, with signs handled separately, but zero
really screws things up.  If it is desired that zero be an allowed
argument, it should also just be ignored, (i.e passed over, the way nil in
an association list is passed over)


Current Practice:

I know of no implementations that currently implement this change.


Cost to Users:

Very slight.


Cost to Implementors:

Very slight.  Should lead to a reduction in code, since most algorithms 
for computing products are for positive integers anyway.  (Consider what
you learned in second grade.)


Benefits:

see Esthetics.


Esthetics:

Mathematical correctness is much more aesthetic than its alternatives.


Discussion:
  
This is not a satire.  Skona's arguments about LCM are correct, and my
arguments about multiplication are of exactly the same form.  Zero really
does screw up multiplication.  If it were not for addition, the value of
zero to addition, and the relationship of addition to multiplication
(especially through the distributive law), we would not put up with zero.
If you formulate multiplication in terms of unions of multisets of prime
factors (a natural and convenient representation for integers if you don't
have to do addition), then there isn't even any good representation for
zero.

But addition and zero ARE important, so we agree to extend the range of
multiplication to include zero, even though it has weird properties like
destroying the invertibility of multiplication (suddenly (/ (* A B) B)
is not always equal to A).

The same holds for GCD and LCM.  Yes, their behaviors for arguments that
are zero is weird and makes no sense.  But we adopt these definitions
anyway because they preserve useful identities.  For example, we have the
identity

	(* x (gcd y z)) = (gcd (* x y) (* x z))

If x is zero, then we had better have (gcd 0 0) = 0.
If y is zero, then we have

	(* x (gcd 0 z)) = (gcd 0 (* x z))

and letting (gcd 0 a) = a is the simplest way of preserving this.
Then consider

	(* u v) = (* (gcd u v) (lcm u v))

Let u be zero.  Then to preserve this identity at least one of
(gcd u v) and (lcm u v) must be zero.  But (gcd 0 v) = v, so if
v is not zero then (lcm 0 v) had better be zero.

See Knuth, volume 2, section 4.5.2.  There you will see that he finds it
convenient to use the prime-factor representation of integers to explain
gcd and lcm (and in fact during that part of the discussion he conveniently
ignores the fact that you cannot encode zero in that representation--and
for his expository purposes it doesn't matter).

So that is why gcd and lcm behave in such strange ways: they preserve
important identities in the boundary cases.  A cardinal rule of
mathematics is that consistency is more important than making sense.
(In fact, consistency is the *definition* of making sense.)

So I argue that, whatever we do, we should treat GCD/LCM and multiplication
on integers in exactly the same way.  Either all accept arguments that
are zero, or none do.

∂03-May-89  1653	CL-Cleanup-mailer 	[chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 May 89  16:53:46 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 03 MAY 89 16:51:25 PDT
Date: 3 May 89 16:51 PDT
From: masinter.pa@Xerox.COM
Subject: [chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890503-165125-11110@Xerox>

My record says that we passed version 4 at the January meeting, Guy
produced version 5 in March, but that we didn't discuss version 5, postpone
version 5, or otherwise deal with version 5 at the March meeting. I think
this one fell between the cracks... right?

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

From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 May 89 13:08
To: @masinter@decwrl.dec.com
Subject: question @ SUBTYPEP-TOO-VAGUE

LM,

The last version I got of SUBTYPEP-TOO-VAGUE reads like it is
Version 5, but doesn't have Version 5 in the header. That's no
big deal, but since it has some big changes from Version 4, I 
wondered if what I got was just a review copy or  a final draft?
The reason you're getting this question (vs. KMP) is that your
name appeared twice and last in the revision list.



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

∂04-May-89  0922	CL-Cleanup-mailer 	Issue: SETF-MULTIPLE-STORE-VARIABLE 
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 4 May 89  09:22:39 PDT
Received: from layla.parc.Xerox.COM by arisia.Xerox.COM with SMTP
	(5.61+/IDA-1.2.8/gandalf) id AA01288; Thu, 4 May 89 09:21:02 -0700
Reply-To: <rao@arisia.Xerox.COM>
Received: by layla. (4.0/SMI-4.0)
	id AA05410; Thu, 4 May 89 09:21:58 PDT
Date: Thu, 4 May 89 09:21:58 PDT
From: Ramana Rao <rao@arisia.Xerox.COM>
Message-Id: <8905041621.AA05410@layla.>
To: cl-cleanup@sail.stanford.edu
Cc: Rao@arisia.Xerox.COM, pavel.pa@Xerox.COM, gregor@arisia.Xerox.COM,
        masinter.pa@arisia.Xerox.COM
Subject: Issue: SETF-MULTIPLE-STORE-VARIABLE


This message is to encourage the cleanup committee to get to and accept this
proposal and to bring up a related issue having to do with setf generic
functions in CLOS.  

The case covered by the proposal is real (or at least exactly what I want to).
I have a rectangle object that has accessors for retrieving the corner points
and the extent that return two multiple values.  A motivation for doing it this
way versus with structured objects is to please users that are particularly
concerned about consing new structures.  So both types of methods are provided.
(I hacked a version of setf that allows setf of these accessors.)

Example:

(defmethod rectangle-min-point ((rect rectangle))
	...
	(make-point min-x min-y))

(defmethod rectangle-min-point* ((rect rectangle))
	...
	(values min-x min-y))

(defmethod (setf* rectangle-min-point*) (min-x min-y (rect rectangle))
	---
	)

The related issue has to do with CLOS.  How does the setf generic function know
how many store values to expect?  This may be a problem with having recombined
the store varables into a single argument list.

Example:

Alternatives Solutions in order of preferrence:

1) Change syntax of methods on setf generic function.

(defmethod (setf rectangle-min-point*) (min-x min-y) ((rect rectangle))
	---
	)

2) Extend defgeneric to allow indicating the number of store variables expected
by the setf generic function.

3) Require user to generate setf expander using some provided macro.

(def-generic-setf rectangle-min-point* 2) 

Or the following allows catching some errors at setf expansion.

(def-generic-setf rectangle-min-point* (rect) (min-x min-y))

(defmethod (setf rectangle-min-point*) (min-x min-y (rect rectangle))
	---
	)




∂04-May-89  1244	CL-Cleanup-mailer 	[chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 May 89  12:44:36 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 589809; 4 May 89 13:49:40 EDT
Date: Thu, 4 May 89 13:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890503-165125-11110@Xerox>
Message-ID: <19890504174937.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 3 May 89 16:51 PDT
    From: masinter.pa@Xerox.COM

    My record says that we passed version 4 at the January meeting, Guy
    produced version 5 in March, but that we didn't discuss version 5, postpone
    version 5, or otherwise deal with version 5 at the March meeting. I think
    this one fell between the cracks... right?

My records are consistent with that.  I never studied this issue really
carefully but version 5 was okay with me, more or less.  It's still a bit
bogus because an implementation could define all type specifiers as
expansions into SATISFIES, in which case SUBTYPEP could return NIL NIL
always.  I suspect the proposal was intended to rule that out, but the
actual words that it says fail to rule that out.

    From: chapman%aitg.DEC@decwrl.dec.com

    The last version I got of SUBTYPEP-TOO-VAGUE reads like it is
    Version 5, but doesn't have Version 5 in the header. That's no
    big deal, but since it has some big changes from Version 4, I 
    wondered if what I got was just a review copy or  a final draft?
    The reason you're getting this question (vs. KMP) is that your
    name appeared twice and last in the revision list.

Here is a better version of version 5 that I found in our archives:

Date: Wed, 15 Mar 89 17:44:14 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152244.AA03741@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: [gls: Issue SUBTYPEP-TOO-VAGUE, version 5]

[I forgot to update the edit history.  Here is corrected copy.]



Date: Wed, 15 Mar 89 17:41:16 EST
From: Guy Steele <gls>
To: cl-cleanup@sail.stanford.edu
Subject: Issue SUBTYPEP-TOO-VAGUE, version 5
Cc: gls


This is a proposed amendment to version 4 passed in January 1989 at Kauai.

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)
                Version 3,  6-Oct-88 (Masinter)
                Version 4,  7-Oct-88 (Masinter, per Moon's comments)
		Version 5, 15-Mar-89 Steele

Problem Description:

[From version 4]

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.

[Addition for version 5]

There are two problems with version 4.  First is that of the first three
bulleted points in the version 4 proposal:

    * Clarify that SUBTYPEP will return a second value of NIL
    only when either of the type specifiers involves the SATISFIES, NOT, 
    AND, OR, MEMBER. SUBTYPEP will not return a second
    value of NIL when both arguments involve only the words in Table 4-1, or
    names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes
    that expand into only those words and/or names.

    * SUBTYPEP should signal an error when handed (for either argument)
    a type specifier that involves VALUES or the list form of the FUNCTION
    type.

    * SUBTYPEP must always return values T T in the case where the two
    type specifiers (or their expansions) are EQUAL.

any two have significant overlap, and indeed all three can overlap;
version 4 contained no indication of how this conflict should be resolved.

Second is that version 4 calls for SUBTYPEP to signal an error (at least at
high safety)even when the arguments are valid type specifiers, but this can
make it harder to use SUBTYPEP.  These are cases that returning NIL NIL
was supposed to cover.

This version replaces the three bulleted points above with a single point
and some observations about its consequences.  This version eliminates
the requirement to signal an error.


Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY-MORE

A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a 
DEFTYPE  defined type specifier. 

* Clarify that SUBTYPEP is permitted to return NIL NIL only when
  at least one argument involves SATISFIES, AND, OR, NOT, MEMBER,
  VALUES, or the list form of FUNCTION.

  Note that one consequence of this is that if neither argument
  involves any of these type specifiers, then SUBTYPEP is obliged
  to determine the relationship accurately.  In particular, SUBTYPEP
  must return T T if the arguments are EQUAL and do not involve
  any of the above-stated type specifiers.

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

Specifying the behavior of SUBTYPEP makes it more useful. Otherwise,
programs cannot rely on any more than NIL NIL as return values.

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.   

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:

Its hard to imagine a portable program that depends heavily
on SUBTYPEP. This proposal does not require any implementation
to "handle" fewer cases of SUBTYPEP.

Benefits:

An area of confusion in the language is cleared up.  Usages of SUBTYPEP
will be more portable.

Discussion:

The handling of FLOAT and SINGLE-FLOAT  appeared to be the 
consensus from a discussion on the common-lisp mailing list some
 time ago.

It would not be too onerous to require implementations to handle
the cases where one but not the other type specifier involves
OR, AND, NOT or MEMBER, but the specification becomes 
cumbersome.

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?

The rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail.

∂04-May-89  1251	CL-Cleanup-mailer 	Issue: SETF-MULTIPLE-STORE-VARIABLE 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 May 89  12:51:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 589900; 4 May 89 15:52:19 EDT
Date: Thu, 4 May 89 15:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-MULTIPLE-STORE-VARIABLE
To: rao@arisia.Xerox.COM
cc: cl-cleanup@sail.stanford.edu, pavel.pa@Xerox.COM, gregor@arisia.Xerox.COM,
    masinter.pa@arisia.Xerox.COM
In-Reply-To: <8905041621.AA05410@layla.>
Message-ID: <19890504195216.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Thu, 4 May 89 09:21:58 PDT
    From: Ramana Rao <rao@arisia.Xerox.COM>

    This message is to encourage the cleanup committee to get to and accept this
    proposal

We'd better!  June?

    and to bring up a related issue having to do with setf generic functions in CLOS.  

setf generic functions, like the short form of defsetf, only work for storing single
values.  To store multiple values you need to use the long form of defsetf or
define-setf-method.  I don't think it's at all hard to make a macro that expands
into a defmethod and a defsetf.  It's probably not worth trying to change the
syntax of defmethod to be that macro (I think we already considered that a couple
years ago and uncovered some problems).

∂23-May-89  1013	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-CASE (version 4)    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89  10:13:09 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599388; 23 May 89 13:14:50 EDT
Date: Tue, 23 May 89 13:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-CASE (version 4)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523171914.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>

This issue is on the agenda for the June X3J13 meeting.  KMP and I
have prepared a revised writeup which we think is ready for release.
I'd like to distribute this to X3J13 as soon as discussion, if any,
in the cleanup subcommittee is completed.

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)
Related-issues: PATHNAME-WILD-TRANSLATE
Category:     CHANGE
Edit history: 1-Jul-88, Version 1 by Pitman
              22-Mar-89, Version 2 by Moon, update and rewrite
               9-May-89, Version 3 by Moon, remove alternate proposals
               9-May-89, Version 4 by Moon, respond to discussion with KMP

Problem Description:

  Issues of alphabetic case in pathnames are a major source of problems.
  In some file systems, the customary case is lowercase, in some uppercase,
  in some mixed.  In some file systems, case matters, in others it does
  not.

  There are two kinds of pathname case portability problems: moving
  programs from one Common Lisp to another, and moving pathname component
  values from one file system to another.  To solve the first problem, all
  Common Lisp implementations that support a particular file system must
  use compatible representations for pathname component values.  To solve
  the second problem, there must be a common representation for the least
  common denominator pathname component values that exist on all
  interesting file systems.

  This desire for a common representation directly conflicts with the
  desire among programmers who only use one file system to work with the
  local conventions and not think about issues of porting to other file
  systems.  The common representation cannot be the same as every local
  convention, since they vary.

  In the current anarchy of pathname component case conventions:
  
  (NAMESTRING (MAKE-PATHNAME :NAME "FOO" :TYPE "LISP"))
  will produce foo.lisp in some Unix Common Lisp implementations
  and will produce FOO.LISP in other Unix Common Lisp implementations.

  (NAMESTRING (MAKE-PATHNAME :NAME "foo" :TYPE "lisp"))
  will produce FOO.LISP in some Tops-20 Common Lisp implementations
  and will produce "↑Vf↑Vo↑Vo.↑Vl↑Vi↑Vs↑Vp"in other Tops-20 Common
  Lisp implementations.

  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:KEYWORD-ARGUMENT):

  Add a keyword argument :CASE to MAKE-PATHNAME, PATHNAME-HOST,
  PATHNAME-DEVICE, PATHNAME-DIRECTORY, PATHNAME-NAME, and PATHNAME-TYPE.
  The possible values for the argument are :COMMON and :LOCAL.
  :LOCAL means strings input to MAKE-PATHNAME or output by PATHNAME-xxx
  follow the local file system's conventions for alphabetic case.
  :COMMON means those strings follow this common convention:
    - all uppercase means to use a file system's customary case.
    - all lowercase means to use the opposite of the customary case.
    - mixed case represents itself.
  The second and third bullets exist so that translation from local to
  common and back to local is information-preserving.

  The default is :COMMON.

  Namestrings always use local file system case conventions.

  MERGE-PATHNAMES and TRANSLATE-WILD-PATHNAME map customary case in the
  input pathnames into customary case in the output pathname.

Implications of the proposal:

  Unix is case-sensitive and prefers lowercase, so it translates between
  common and local by inverting the case of non-mixed-case strings.
  
  Tops-20 is case-sensitive and prefers uppercase, so it uses identical
  representations for common and local.

  VAX/VMS is upper-case-only, so it translates common to local by upcasing,
  and translates local to common with no change.

  Macintosh is case-insensitive and prefers lowercase, so it translates
  between common and local by inverting the case of non-mixed-case strings,
  and ignores case in EQUAL of two pathnames.

Test Case/Examples:

  Under PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT:

  (PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")
                 :CASE :COMMON)                                 => "FOO"
  (PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")
                 :CASE :COMMON)                                 => "FOO"
  (PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")
                 :CASE :LOCAL)                                  => "foo"
  (PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")
                 :CASE :LOCAL)                                  => "FOO"
  (PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/TeX.lisp")
                 :CASE :COMMON)                                 => "TeX"
  (PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/TeX.lisp")
                 :CASE :LOCAL)                                  => "TeX"
  (NAMESTRING (MAKE-PATHNAME :HOST "MY-UNIX" :NAME "FOO"
                             :CASE :COMMON)                     => "MY-UNIX: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.
  Together with the other pathname proposals, the behavior of pathnames
  should be sufficiently consistent across Common Lisp implementations
  and across file systems to allow portability of pathname-manipulating
  programs.

  Upper case is chosen as the common case for no better reason than
  consistency with Lisp symbols.

  The :CASE keyword argument provides access to both common and local
  conventions without introducing any new functions.  The default
  convention is the common one, assuming that most programs are fully
  portable and therefore :COMMON will be more frequently used.

Current Practice:

  There are no known implementations of exactly what is proposed.
  Symbolics Genera uses common case normally, and provides a way to
  access the local case (called "raw") that in practice is rarely used.
  Symbolics Genera's own file system uses lower case as the customary
  case, but transparent network access is available to file systems
  using all known case conventions.

  Several Common Lisp implementations behave as if :CASE :LOCAL was
  specified (but accept no :CASE argument).

Cost to Implementors:

  The :CASE feature is easily added, but some implementations may have
  to change the default behavior when :CASE is not specified.  No
  implementation need change its internal representation, nor the way
  pathnames print, just the interface functions listed above.

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.

Performance Impact:

  None.

Benefits:

  One step closer to a usable pathname system.

Aesthetics:

  Anything that simplifies the user model of pathnames is an improvement.

Discussion:

  Some people would rather use lowercase as the common case.  The
  decision is essentially arbitrary.  Everywhere else in Common Lisp
  where case matters, uppercase was chosen.

  It has been proposed that the Common Lisp specification should include
  specifications of the exact behavior of pathnames for several popular
  operating systems, so that multiple implementations for those
  operating systems would be compatible with each other.  This proposal
  does that for alphabetic case.

  Some people want the default for :CASE to be :LOCAL instead of :COMMON.
  See Rationale.

  There should probably be a remark somewhere that says that portable
  programs shouldn't expect to be able to create and/or access distinct
  files whose pathname components differ only in case.

∂23-May-89  1014	CL-Cleanup-mailer 	Issue: PATHNAME-COMPONENT-VALUE (version 2)   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89  10:13:57 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599391; 23 May 89 13:15:46 EDT
Date: Tue, 23 May 89 13:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 2)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523172011.4.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>

This issue is on the agenda for the June X3J13 meeting.  KMP and I
have prepared a revised writeup which we think is ready for release.
I'd like to distribute this to X3J13 as soon as discussion, if any,
in the cleanup subcommittee is completed.

Issue:         PATHNAME-COMPONENT-VALUE

Related Issues:PATHNAME-CANONICAL-TYPE,
               PATHNAME-SUBDIRECTORY-LIST,
               PATHNAME-UNSPECIFIC-COMPONENT,
               PATHNAME-WILD

References:    CLtL pp.410-3

Category:      CLARIFICATION and CHANGE

Edit history:  Version 1, 20-Mar-89, by Moon
               Version 2,  9-May-89, by Moon (rewrite based on mail)

Problem description:
  
  CLtL is overly restrictive on the possible values for pathname components.
  These restrictions are described in a funny way that makes it unclear
  whether they are requirements, guidelines, or just an example.
  
  The restrictions are not all written down in one place, but they appear
  to be as follows:

  Host          nil, :wild, string, or list of strings
  Device        nil, :wild, string, or something else ("structured")
  Directory     nil, :wild, string, or something else ("structured")
  Name          nil, :wild, string, or something else ("structured")
  Type          nil, :wild, or string
  Version       nil, :wild, :newest, positive integer, implementation
                dependent symbol, or implementation-dependent integer
                less than or equal to zero.  Suggestions include :oldest,
                :previous, :installed, 0, and -1.

  PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN allowed implementations to
  allow any component to be :UNSPECIFIC.  This has been voted in.

  PATHNAME-SUBDIRECTORY-LIST proposes a list of strings and keyword
  symbols for the directory component.

  PATHNAME-CANONICAL-TYPE proposes some new operations but does not
  change the possible values of the type component.

  PATHNAME-WILD proposes a portable way to test for implementation
  dependent component values that indicate wildcard matching.  It
  does not change the possible values of any component.

Proposal (PATHNAME-COMPONENT-VALUE:SPECIFY):

  The points of the proposal have been numbered/lettered to facilitate
  discussion of individual points.

  0. Pathname component value strings never contain the punctuation
  characters that are used to separate pathname fields (e.g. slashes and
  dots in Unix).  Punctuation characters appear only in namestrings.
  Characters used as punctuation can appear in pathname component values
  with a non-punctuation meaning if the file system allows it (e.g. a Unix
  file name that begins with a dot).

  When examining pathname components, conforming programs must be prepared
  to encounter any of the following values:
  
    1. Any component can be NIL, which means the component has not
    been specified.
  
    2. Any component can be :UNSPECIFIC, which means the component has
    no meaning in this particular pathname.
  
    3. The device, directory, name, and type can be strings.
  
    4. The host can be any object, at the discretion of the implementation.
  
    5. The directory can be a list of strings and symbols as detailed in
    PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)
  
    6. The version can be any symbol or any integer.  The symbol :NEWEST
    refers to the largest version number that already exists in the file
    system when reading, overwriting, appending, superseding, or directory
    listing an existing file, and refers to the smallest version number
    greater than any existing version number when creating a new file.
    Other symbols and integers have implementation-defined meaning.
    It is suggested, but not required, that implementations use positive
    integers starting at 1 as version numbers, recognize the symbol :OLDEST
    to designate the smallest existing version number, and use keyword
    symbols for other special versions.

  Wildcard pathnames can be used with DIRECTORY but not with OPEN, and
  return true from WILD-PATHNAME-P (if issue PATHNAME-WILD passes).  When
  examining wildcard components of a wildcard pathname, conforming programs
  must be prepared to encounter any of the following additional values
  in any component or any element of a list that is the directory component:

    7. :WILD, which matches anything.

    8. A string containing implementation-dependent special wildcard
    characters.

    9. Any object, representing an implementation-dependent wildcard
    pattern.

  When constructing a pathname from components, conforming programs
  must follow these rules:
  
    a. Any component can be NIL.  NIL in the host may mean a default host
    rather than an actual NIL in some implementations.
    
    b. The host, device, directory, name, and type can be strings.  There
    are implementation-dependent limits on the number and type of
    characters in these strings.
  
    c. The directory can be a list of strings and symbols as detailed in
    PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)  There are
    implementation-dependent limits on the list's length and contents.
  
    d. The version can be :NEWEST.

    e. Any component can be taken from the corresponding component
    of another pathname.  When the two pathnames are for different
    file systems (in implementations that support multiple file
    systems), an appropriate translation occurs.  If no meaningful
    translation is possible, an error is signalled.  The definitions
    of "appropriate" and "meaningful" are implementation-dependent.
  
    f. When constructing a wildcard pathname, the name, type, or version
    can be :WILD, which matches anything.
  
    g. An implementation might support other values for some components,
    but a portable program cannot use those values.  A conforming program
    can use implementation-dependent values but this can make it
    non-portable, for example, it might work only with Unix file systems.

Consequences:

  The changes relative to CLtL plus PATHNAME-UNSPECIFIC-COMPONENT
  are as follows:

  The removal of punctuation characters during parsing is specified.

  "Structured" components are disallowed in non-wildcard pathnames,
  except for the specific structuring of directories specified
  in issue PATHNAME-SUBDIRECTORY-LIST.
  
  "Structured" hosts are allowed, a generalization of CLtL's list
  of strings.

  The type and version can be "structured" in wildcard pathnames.
  
  The difference between what component values a program can depend
  on being able to use, versus what component values a program must
  be prepared to encounter, is clarified.

  The implementation-dependent variations are identified explicitly.

Rationale:
  
  This should make it easier to write portable programs that deal with
  pathnames and make it easier for implementors by clarifying the
  framework into which they must fit.  Also it should make it easier
  to write the Common Lisp language specification by resolving some
  things that were unclear about the status quo.

  Adding "structured" hosts conforms to current practice.

  Substituting a default host for NIL conforms to current practice
  in implementations that require all pathnames to have a specific host.

  Confining "structured" devices and names to wildcard pathnames, and
  replacing "structured" directories with an explicit specification of
  the form of the directory value, should improve portability without causing
  any harm.

  :WILD is only required to be supported in the name, type, or version,
  which are the easiest to implement and the most useful in applications.

Current practice:
  
  All versions of Symbolics Genera violate CLtL in the matter of hosts,
  since it uses standard-objects as the host component.  Genera deviates
  slightly from PATHNAME-SUBDIRECTORY-LIST, but otherwise conforms to
  PATHNAME-COMPONENT-VALUE:SPECIFY.

  Other implementations were not surveyed.

  This proposal assumes that no current or planned implementation
  uses "structured" names except possibly for wildcards.

Cost to Implementors:

  Most implementations already conform, except for the changes required
  by PATHNAME-UNSPECIFIC-COMPONENT and PATHNAME-SUBDIRECTORY-LIST, so
  the cost of this proposal itself should be minimal.  It is conceivable
  that an implementation may exist that has to change its pathname
  representation, for example one that uses numbers as "structured" devices.
  Some implementations may have to change their treatment of punctuation
  characters.

Cost to Users:

  None.

Cost of non-adoption:
  
  Pathnames will continue to be a poorly specified part of the language.

Performance impact:

  None of any significance.

Benefits/Esthetics:

  The boundary between the specified behavior of pathnames and the
  implementation-dependent behavior of pathnames will be more clear.

Discussion:

  None.

∂23-May-89  1015	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL (version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89  10:15:38 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599393; 23 May 89 13:17:22 EDT
Date: Tue, 23 May 89 13:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-LOGICAL (version 2)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523172147.5.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>

This issue is on the agenda for the June X3J13 meeting.  This issue has
not been written up before.  With KMP's help I have prepared a writeup
which we think is ready for release.  I'd like to distribute this to
X3J13 as soon as discussion, if any, in the cleanup subcommittee is
completed.

Issue:          PATHNAME-LOGICAL
References:     Pathnames (pp410-413)
                OPEN (p.418), WITH-OPEN-FILE (p.422), RENAME-FILE (p.423),
                DELETE-FILE (p.424), PROBE-FILE (p.424),
                FILE-WRITE-DATE (p.424), FILE-AUTHOR (p.424), LOAD (p.426),
                COMPILE-FILE (p.439), DIRECTORY (p.427), PATHNAME (p.413),
                TRUENAME (p.413), MERGE-PATHNAMES (p.415), 
                MAKE-PATHNAME (p.416), and PARSE-NAMESTRING (p.414).
Related issues: PATHNAME-CANONICAL-TYPE, PATHNAME-COMPONENT-VALUES, 
                PATHNAME-SUBDIRECTORY-LIST, and PATHNAME-WILD
Category:       ADDITION
Edit history:   Version 1, 11-May-89, by Moon
                Version 2, 18-May-89, by Moon

Problem description:

  Pathname values are not portable, but they are sometimes part of a
  program, for example the names of files containing the program and the
  data used by the program.  Moving large programs between sites would
  be easier if pathname values did not have to be translated.

  Pathname values are nonportable because not all Common Lisp
  implementations use the same operating system and file name syntax varies
  widely among operating systems.  In addition, corresponding files at two
  different sites may have different names even when the operating system
  is the same; for example, they may be on different directories or
  different devices.

  The issue of portable pathname values is separate from the issues of
  portable pathname operations.  See the related issues listed above.
  For inter-issue interactions, see the discussion section below.

Proposal (PATHNAME-LOGICAL:ADD):

  Define a "logical" file system that looks the same at every site.  This
  file system is implemented by translating each logical pathname into a
  physical pathname on a real file system.  The logical pathnames are the
  same at all sites, but the translation rules are different at each site,
  thus the physical pathnames can be different at each site.

  The syntax of a logical pathname namestring is as follows:

     host ":" { directory ";" }* [ name ] [ "." type [ "." version ]]

  Terminology:
  A word consists of one to twelve uppercase letters, digits, and hyphens.
  Lowercase letters are translated to uppercase.  The consequences of using
  other characters, or more than twelve characters, are unspecified.  A
  wildcard word is "*" (:WILD), which matches anything, or a word with one
  or more asterisk characters inserted into it, with no two asterisks
  adjacent; each asterisk matches a sequence of zero or more characters.
  The maximum number of non-asterisk characters in a wildcard word is 12.

  The host is a word that has been defined as a logical pathname host by
  using DEFINE-LOGICAL-PATHNAME-TRANSLATIONS.

  There is no device, so the device component of a logical pathname is
  always :UNSPECIFIC.  No other component can be :UNSPECIFIC.

  Each directory is a word, a wildcard word, or "**" (:WILD-INFERIORS).
  There are no relative directories.

  The name is a word or a wildcard word.

  The type is a word or a wildcard word.

  The version is a positive decimal integer of one to six digits or
  "NEWEST" (:NEWEST) or "*" (:WILD).  The letters in "NEWEST" can be in
  either alphabetic case.  The consequences of using anything else as a
  version are unspecified.

  Some real file systems do not have versions.  Logical pathname
  translation to such a file system ignores the version.  This implies that
  a program cannot rely on being able to store more than one version of a
  file named by a logical pathname.

  The type of a logical pathname for a Common Lisp source file is "LISP".
  This should be translated into whatever type is appropriate in a physical
  pathname.

  The logical pathname host name "SYS" is reserved for the implementation.
  The existence and meaning of SYS: logical pathnames is
  implementation-defined.

  The functions OPEN (and WITH-OPEN-FILE), RENAME-FILE, DELETE-FILE,
  PROBE-FILE, FILE-WRITE-DATE, FILE-AUTHOR, LOAD, COMPILE-FILE, DIRECTORY,
  and TRUENAME accept logical pathnames and translate them into physical
  pathnames.  PATHNAME of a stream created by OPEN of a logical pathname is
  a logical pathname.  TRUENAME, PROBE-FILE, and DIRECTORY never return
  logical pathnames.  RENAME-FILE with a logical pathname as the second
  argument returns a logical pathname as the first value.  MERGE-PATHNAMES
  returns a logical pathname if and only if its first argument is a logical
  pathname or its first argument does not specify a host and the default
  host is logical.  MAKE-PATHNAME returns a logical pathname if and only if
  the host is logical.  PARSE-NAMESTRING returns a logical pathname if and
  only if the string begins with a logical pathname host name (defined by
  using DEFINE-LOGICAL-PATHNAME-TRANSLATIONS) and a colon, or the string
  does not specify a host and the default host is logical.

  Add these defined names to Common Lisp in support of logical pathnames:

  LOGICAL-PATHNAME                                              [Class]

    LOGICAL-PATHNAME is a subclass of PATHNAME.

  TRANSLATE-LOGICAL-PATHNAME pathname                           [Function]

    Translate a logical pathname to the corresponding physical pathname.
    The pathname argument is first coerced to a pathname.  If it is not a
    pathname, string, or file stream an error of type TYPE-ERROR is
    signalled.  If the coerced argument is a logical pathname, the first
    matching translation (according to PATHNAME-MATCH-P) of the logical
    pathname host is applied, using TRANSLATE-PATHNAME with the reversible
    argument true, and three values are returned:
      1. The physical pathname
      2. The from-wildcard of the translation
      3. The to-wildcard of the translation
    If no translation matches, an error of type FILE-ERROR is signalled.
    If the coerced argument is a physical pathname, it is returned as all
    three values.

  DEFINE-LOGICAL-PATHNAME-TRANSLATIONS host translations &key   [Function]

    Define a logical pathname host named <host> (a string or a symbol which
    is coerced to a string).  <translations> is a list of translations.
    Each translation is a list of from-wildcard and to-wildcard.
    From-wildcard must be a logical pathname or a string coercible to a
    logical pathname.  To-wildcard must be a physical pathname or a string
    coercible to a physical pathname.  Translations are searched in the
    order listed, so more specific from-wildcards must precede more general
    ones.

    The specified translations might be modified or augmented in an
    implementation-dependent fashion, typically to provide translation of
    file types to local naming conventions, to accomodate physical file
    systems with limited length names, or to deal with special character
    requirements such as translating hyphens to underscores or uppercase
    letters to lowercase.  These modifications are reflected in the second
    and third values returned by TRANSLATE-LOGICAL-PATHNAME in such a way
    that TRANSLATE-PATHNAME used with them produces the same translation.

    If a logical pathname host named <host> already exists, its existing
    translations are replaced.

    There are no keyword arguments specified by this standard, but any
    implementation extensions are provided as keyword arguments or as
    translations with more than two elements.

  LOAD-LOGICAL-PATHNAME-TRANSLATIONS host                       [Function]

    If a logical pathname host named <host> (a string or a symbol which is
    coerced to a string) is already defined, return NIL.  Otherwise, search
    for a logical pathname host definition in an implementation defined
    manner.  If none is found, signal an error.  If a definition is found,
    install it and return T.

    The search used by LOAD-LOGICAL-PATHNAME-TRANSLATIONS should be
    documented, as logical pathname definitions will be created by users,
    not only by Lisp implementors.

  COMPILE-FILE-PATHNAME pathname &key :output-file              [Function]

    Returns the pathname that COMPILE-FILE would write into, if given
    the same arguments.

Examples:

  ;A simple, and typical, example
  (define-logical-pathname-translations "FOO"
     '(("FOO:**;*.*.*"              "MY-LISPM:>library>foo>**>")))

  ;A more complex example
  (define-logical-pathname-translations "PROG"
     '(("PROG:RELEASED;*.*.*"       "MY-UNIX:/sys/bin/my-prog/")
       ("PROG:RELEASED;*;*.*.*"     "MY-UNIX:/sys/bin/my-prog/*/")
       ("PROG:EXPERIMENTAL;*.*.*"   "MY-UNIX:/usr/Joe/development/prog/")
       ("PROG:EXPERIMENTAL;DOCUMENTATION;*.*.*"
                                    "MY-VAX:SYS$DISK:[JOE.DOC]")
       ("PROG:EXPERIMENTAL;*;*.*.*" "MY-UNIX:/usr/Joe/development/prog/*/")
       ("PROG:MAIL;**;*.MAIL"       "MY-VAX:SYS$DISK:[JOE.MAIL.PROG...]*.MBX")))

  ;This function is like DIRECTORY, but if its argument is a logical
  ;pathname it returns logical pathnames in the results.  If its
  ;argument is a physical pathname, it is the same as DIRECTORY.
  (defun logical-directory (pathname)
    (multiple-value-bind (physical from-wildcard to-wildcard)
        (translate-logical-pathname pathname)
      (map 'list #'(lambda (truename)
                     (translate-pathname truename to-wildcard
                                         from-wildcard t))
           (directory physical))))

Rationale:

  Large programs can be moved between sites without changing any pathnames,
  provided all pathnames used are logical.  A portable system construction
  tool can be created that operates on programs defined as sets of files.

  Logical pathname syntax was chosen to be easily translated into most
  popular file systems, while still being powerful enough for storing large
  programs.  Logical pathnames have least-common-denominator capabilities.
  Although they have hierarchical directories, versions, and a medium sized
  maximum name length, they can be mapped onto a less capable real file
  file system by translating each directory that is used into a flat
  directory name, treating all versions as :newest, and/or using special
  implementation-dependent translation rules to shorten long names.
  More advanced capabilities such as relative pathnames and a name for the
  root directory were not felt to be necessary in logical pathnames.  They
  could be added later if a need emerges.

  It is not a goal of logical pathnames to be able to represent all
  possible file names.  Their goal is rather to represent just enough file
  names to be useful for storing software.  Real pathnames, in contrast,
  need to provide a uniform interface to all possible file names, including
  names and naming conventions that are not under the control of Common
  Lisp.

  The choice of logical pathname syntax was guided by the goal of being
  visually distinct from real file systems.

  The numbers twelve and six are arbitrary but chosen to accomodate
  both typical program file names and typical file system limitations.
  File systems that are more limited can still be accomodated through
  additional implementation-dependent translation as pointed out earlier.

  The LOGICAL-PATHNAME class exists so that methods can distinguish
  logical pathnames from regular pathnames.

  The two extra values returned by TRANSLATE-LOGICAL-PATHNAME allow
  for back-translation, as shown in the LOGICAL-DIRECTORY example.

  Loading of logical pathname translations from a site-dependent file
  allows software to be distributed using logical pathnames.  The software
  is supplied with logical pathnames and a sample set of translations.  The
  actual translations are defined by the user of the software, since the
  supplier does not know the user's local file system conventions.  Loading
  the software uses these translations via LOAD-LOGICAL-PATHNAME-TRANSLATIONS.

  The COMPILE-FILE-PATHNAME function and the specification of "LISP" as the
  type of a logical pathname for a Common Lisp source file together provide
  enough information about compilation for a portable system construction
  tool that uses logical pathnames to work.

Current practice:

  Symbolics Genera has had a similar facility for many years.  It is used
  extensively for software distribution by Symbolics and its customers.
  The Genera facility uses the same logical pathname syntax but different
  function names, and is somewhat more complicated.  The extra complexity
  is not necessary in the Common Lisp standard.

  Symbolics Genera offers a function for translating from a physical
  pathname back to a logical pathname.  There are a number of problems with
  this, and so it has not been proposed here.  Instead
  TRANSLATE-LOGICAL-PATHNAME returns enough information to allow the user
  program to perform the backtranslation itself.

  The Genera equivalent of LOAD-LOGICAL-PATHNAME-TRANSLATIONS looks for
  a file named SYS:SITE;hostname.TRANSLATIONS.

Cost to Implementors:

  This is a fairly complex facility, but its performance is unimportant
  so a straightforward implementation should suffice.  Most of the
  complexity comes in dealing with unusual file systems, such as ones
  that don't allow file names longer than eight characters.

Cost to Users:

  None.

Cost of non-adoption:

  Portable software construction and distribution will have to rely on
  implementation-dependent kludges.  Lisp software will continue to be
  difficult to install.

Performance impact:

  None.

Benefits:

  Avoid cost of non-adoption.

Esthetics:

  Improved portability of large programs.

Discussion:

  Issue PATHNAME-LOGICAL fundamentally depends on issue PATHNAME-WILD.

  If PATHNAME-CANONICAL-TYPE:NEW-CONCEPT passes, it will affect the
  behavior of the function TRANSLATE-PATHNAME and therefore the behavior of
  the function TRANSLATE-LOGICAL-PATHNAME.  When a logical pathname
  translation has from and to type fields that are * or omitted,
  translation of the type will be guided by canonical types.  If
  PATHNAME-CANONICAL-TYPE:NEW-CONCEPT fails to pass, it will either have to
  be done behind the scenes by TRANSLATE-PATHNAME or users will have to
  write more verbose translations that individually specify the handling of
  each file type.

∂23-May-89  1017	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (version 6) 
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89  10:16:36 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599395; 23 May 89 13:18:24 EDT
Date: Tue, 23 May 89 13:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (version 6)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523172251.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>

This issue is on the agenda for the June X3J13 meeting.  KMP and I
have prepared a revised writeup which we think is ready for release.
I'd like to distribute this to X3J13 as soon as discussion, if any,
in the cleanup subcommittee is completed.

Issue:          PATHNAME-SUBDIRECTORY-LIST
References:     Pathnames (pp410-413), MAKE-PATHNAME (p416),
                PATHNAME-DIRECTORY (p417)
Related-issues: PATHNAME-COMPONENT-CASE, PATHNAME-COMPONENT-VALUE
Category:       CHANGE
Edit history:   18-Jun-87, Version 1 by Ghenis.pasa@Xerox.COM
                05-Jul-88, Version 2 by Pitman (major revision)
                28-Dec-88, Version 3 by Pitman (merge discussion)
                22-Mar-89, Version 4 by Moon (fix based on discussion)
                19-May-89, Version 5 by Moon (improve based on mail)
                21-May-89, Version 6 by Moon (final cleanups)

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 the pathname abstraction.

  According to CLtL, only a string is a portable value for the directory
  component of a pathname.  Thus in order to denote a subdirectory, the use
  of punctuation characters (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 different subdirectory punctuation.

  Related problems:

  - In some implementations "FOO.BAR" might denote the "BAR" subdirectory
    of "FOO", while in other implementations it would denote a top-level
    directory, because "." is not treated as punctuation. To be safe,
    portable programs must avoid all potential punctuation characters.

  - Even in implementations where "." is used for subdirectories,
    "FOO.BAR" may be recognized by some to mean the "BAR" subdirectory of
    "FOO" and by others to mean `a seven character directory name with "."
    as the fourth character.'

  - In fact, CLtL does not even say whether punctuation characters are
    part of the string. eg, is "foo" or "/foo" the directory component for
    a unix pathname "/foo/bar.lisp". Similarly, is "[FOO]" or "FOO" the
    directory component for a VMS pathname "[FOO]ME.LSP"?
    PATHNAME-COMPONENT-VALUE:SPECIFY says punctuation characters are not
    part of the string.

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

  Remove the "structured" directory feature mentioned on CLtL p.412.
  
  Allow the value of a pathname's directory component to be a list.  The
  car of the list is one of the symbols :ABSOLUTE or :RELATIVE.
  Each remaining element of the list is a string or a symbol (see below).
  Each string names a single level of directory structure.  The strings
  should contain only the directory names themselves -- no punctuation
  characters.

  A list whose car is the symbol :ABSOLUTE represents a directory path
  starting from the root directory.  The list (:ABSOLUTE) represents
  the root directory.  The list (:ABSOLUTE "foo" "bar" "baz") represents
  the directory called "/foo/bar/baz" in Unix [except possibly for
  alphabetic case -- that is the subject of a separate issue].

  A list whose car is the symbol :RELATIVE represents a directory path
  starting from a default directory.  The list (:RELATIVE) has the same
  meaning as NIL and hence is not used.  The list (:RELATIVE "foo" "bar")
  represents the directory named "bar" in the directory named "foo" in the
  default directory.

  In place of a string, at any point in the list, symbols may occur to
  indicate special file notations. The following symbols have standard
  meanings.  Implementations are permitted to add additional objects of any
  non-string type if necessary to represent features of their file systems
  that cannot be represented with the standard strings and symbols.
  Supplying any non-string, including any of the symbols listed below, to a
  file system for which it does not make sense signals an error of type
  FILE-ERROR.  For example, Unix does not support :WILD-INFERIORS.

   :WILD           - Wildcard match of one level of directory structure.
   :WILD-INFERIORS - Wildcard match of any number of directory levels.
   :UP             - Go upward in directory structure (semantic).
   :BACK           - Go upward in directory structure (syntactic).

  "Syntactic" means that the action of :BACK depends only on the pathname
  and not on the contents of the file system.  "Semantic" means that the
  action of :UP depends on the contents of the file system; to resolve
  a pathname containing :UP to a pathname whose directory component
  contains only :ABSOLUTE and strings requires probing the file system.
  :UP differs from :BACK only in file systems that support multiple
  names for directories, perhaps via symbolic links.  For example,
  suppose that there is a directory
    (:ABSOLUTE "X" "Y" "Z")
  linked to 
    (:ABSOLUTE "A" "B" "C")
  and there also exist directories
    (:ABSOLUTE "A" "B" "Q")
    (:ABSOLUTE "X" "Y" "Q")
  then
    (:ABSOLUTE "X" "Y" "Z" :UP "Q")
  designates
    (:ABSOLUTE "A" "B" "Q")
  while
    (:ABSOLUTE "X" "Y" "Z" :BACK "Q")
  designates
    (:ABSOLUTE "X" "Y" "Q")

  If a string is used as the value of the :DIRECTORY argument to
  MAKE-PATHNAME, it should be the name of a toplevel directory and should
  not contain any punctuation characters.  Specifying a string, str, is
  equivalent to specifying the list (:ABSOLUTE str).  Specifying the symbol
  :WILD is equivalent to specifying the list (:ABSOLUTE :WILD-INFERIORS),
  or (:ABSOLUTE :WILD) in a file system that does not support :WILD-INFERIORS.

  The PATHNAME-DIRECTORY function always returns NIL, :UNSPECIFIC, or a
  list, never a string, never :WILD.

  In non-hierarchical file systems, the only valid list values for the
  directory component of a pathname are (:ABSOLUTE string) and
  (:ABSOLUTE :WILD).  :RELATIVE directories and the keywords
  :WILD-INFERIORS, :UP, and :BACK are not used in non-hierarchical file
  systems.

  Pathname merging treats a relative directory specially.  Let
  <pathname> and <defaults> be the first two arguments to
  MERGE-PATHNAMES.  If (PATHNAME-DIRECTORY <pathname>) is a list whose
  car is :RELATIVE, and (PATHNAME-DIRECTORY <defaults>) is a list, then
  the merged directory is the value of
    (APPEND (PATHNAME-DIRECTORY <defaults>)
            (CDR  ;remove :RELATIVE from the front
              (PATHNAME-DIRECTORY <pathname>)))
  except that if the resulting list contains a string or :WILD immediately
  followed by :BACK, both of them are removed.  This removal of redundant
  :BACKs is repeated as many times as possible.
  If (PATHNAME-DIRECTORY <defaults>) is not a list or
  (PATHNAME-DIRECTORY <pathname>) is not a list whose car is :RELATIVE, the
  merged directory is
    (OR (PATHNAME-DIRECTORY <pathname>) (PATHNAME-DIRECTORY <defaults>))

  A relative directory in the pathname argument to a function such as
  OPEN is merged with *DEFAULT-PATHNAME-DEFAULTS* before accessing the
  file system.

Test Cases/Examples:

  (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:KEYWORD-ARGUMENT passes with a default of
  :COMMON, the value is the second one shown.

  (PATHNAME-DIRECTORY (PARSE-NAMESTRING "../baz.lisp")) ;on Unix
  => (:RELATIVE :UP)

  (PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/../mum/baz")) ;on Unix
  => (:ABSOLUTE "foo" "bar" :UP "mum")

  (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.
  This would allow a system construction utility that organizes programs
  by subdirectories to be portable to all implementations that have
  hierarchical file systems.

  Discussion indicated that "Implementations are permitted to add
  additional objects of any non-string type if necessary to represent
  features of their file systems that cannot be represented with the
  standard strings and symbols" is a necessary escape hatch for things like
  home directories and fancy pattern matching.  Implementations should
  limit their use of this loophole and use the standard keyword symbols
  whenever that is possible.

Current Practice:

  Symbolics Genera implements something very similar to this. The main
  differences are:
   - 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.
   - Genera has no separate concepts of :UP and :BACK.  Genera
     represents Unix ".." as :UP, but deals with :UP syntactically, not
     semantically.

Cost to Implementors:

  In principle, nothing about the implementation needs to change except
  the treatment of the directory component by MAKE-PATHNAME and
  PATHNAME-DIRECTORY. The internal representation can otherwise be left
  as-is if necessary.

  Implementations such as Genera that already have hierarchical directory
  handling will have to make an incompatible change to switch to what
  is proposed here.

  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 for portable programs. This change is upward compatible with CLtL.
  Nonportable programs will have to be changed if they use implementation
  dependent hierarchical directory handling and the implementation
  removes support for that when it adds support for this proposal.

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 component 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 could have been some programs which thought the
  change was compatible and ended up ignoring important information (the
  :SUBDIRECTORIES component). 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.

  Moon doesn't like having both :UP and :BACK, but admits that some
  file systems do it one way and some do it the other.  He still thinks
  it would be simpler not to have both.

  To keep it simple, we chose not to add to this issue the functions
  DIRECTORY-PATHNAME-AS-FILE and PATHNAME-AS-DIRECTORY, which convert
  the name of a directory from or to the directory component of a file
  inferior to that directory.  This conversion is system-dependent, for
  example TOPS-20 appends a type field and Unix does not.  Also in some
  systems the root directory has a name and in others it doesn't.  Of
  course these functions signal an error in non-hierarchical file
  systems.  Examples (for Unix, assuming #P print syntax for pathnames):
   (directory-pathname-as-file #P"/usr/bin/sh") => #P"/usr/bin"
   (pathname-as-directory #P"/usr/bin") => #P"/usr/bin"/
  These functions have not been proposed because they are mainly useful
  in conjunction with additional functions for manipulating directories
  (creating, expunging, setting access control) that have not been made
  available in Common Lisp.

∂23-May-89  1018	CL-Cleanup-mailer 	Issue: PATHNAME-WILD (version 5)    
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89  10:18:45 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599400; 23 May 89 13:20:31 EDT
Date: Tue, 23 May 89 13:24 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (version 5)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523172456.7.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>

This issue is on the agenda for the June X3J13 meeting.  KMP and I
have prepared a revised writeup which we think is ready for release.
I'd like to distribute this to X3J13 as soon as discussion, if any,
in the cleanup subcommittee is completed.

Issue:        PATHNAME-WILD
References:   Pathnames (pp410-413)
Related issues: PATHNAME-LOGICAL
Category:     ADDITION
Edit history: 21-Jul-88, Version 1 by Pitman
              06-Oct-88, Version 2 by Pitman
               9-May-89, Version 3 by Moon (small fixes)
              10-May-89, Version 4 by Moon (add two more functions)
              13-May-89, Version 5 by Moon (minor cleanups, add clarification)

Problem Description:

  Some file systems provide more complex conventions for wildcards than
  simple component-wise wildcards (:WILD). 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

  Some file systems support even more complex wildcards, for example
  regular expressions.

  The CL pathname model does not specify a way to represent complex
  wildcards, which means, for example, that (MAKE-PATHNAME :NAME "F*O")
  cannot be recognized by portable code as containing a wildcard.

  Common Lisp provides only the first of these four common operations
  on wildcard pathnames:
  (1) Enumerate the set of existing files that match the pathname;
  this is provided by the DIRECTORY function.
  (2) Test whether a pathname contains wildcards.
  (3) Test whether a pathname matches a wildcard pathname.
  (4) Translate one pathname into another according to a mapping specified
  by a pair of wildcard pathnames.

Proposal (PATHNAME-WILD:NEW-FUNCTIONS):

  Introduce the following three functions:

    WILD-PATHNAME-P pathname &optional field-key
  
    Tests a pathname for the presence of wildcard components.  If the first
    argument is not a pathname, string, or file stream an error of type
    TYPE-ERROR is signalled.
  
    If no <field-key> is provided, or the <field-key> is NIL, the result is
    T if <pathname> has any wildcard components, NIL if <pathname> has none.
  
    If a non-null <field-key> is provided, it must be one of :HOST, :DEVICE,
    :DIRECTORY, :NAME, :TYPE, or :VERSION.  In this case, the result is T
    if the indicated component of <pathname> is a wildcard, NIL if the
    component is not a wildcard.


    PATHNAME-MATCH-P pathname wildcard

    T if <pathname> matches <wildcard>, otherwise NIL.  The matching rules
    are implementation-dependent but should be consistent with the
    DIRECTORY function.  Missing components of <wildcard> default to :WILD.

    If either argument is not a pathname, string, or file stream an error
    of type TYPE-ERROR is signalled.  It is valid for <pathname> to be a
    wild pathname.  It is valid for <wildcard> to be a non-wild pathname.


    TRANSLATE-PATHNAME source from-wildcard to-wildcard &optional reversible

    Translate the pathname <source> according to the correspondence between
    the two wildcard pathnames.  This translation is implementation
    dependent.  The result is <to-wildcard> with each missing or wildcard
    field replaced by the portion of <source> that matches the corresponding
    field (usually a wildcard) in <from-wildcard>.  Additional translations
    of alphabetic case or file naming conventions might also occur,
    especially when from-wildcard and to-wildcard are for different hosts.

    If <reversible> is false, the translation is determined by the user
    interface conventions of the file systems involved.  If <reversible> is
    true, the translation must instead be reversible, that is, the
    following identity must hold for all cases where no error is signalled:

      (equal (translate-pathname (translate-pathname pathname from to t)
                                 to from t)
             pathname)

    In some file systems the above identity is true only when
    (member (pathname-version pathname) '(:newest :unspecific)).
    This is considered valid, as Common Lisp cannot force all the
    file systems in the world to implement versions.

    In some file systems the <reversible> argument is ignored because the
    user interface conventions are reversible anyway.

    If any of the first three arguments is not a pathname, string, or file
    stream an error of type TYPE-ERROR is signalled.  It is valid for
    <source> to be a wild pathname; in general this will produce a wild
    result.  It is valid for <from-wildcard> and/or <to-wildcard> to be
    non-wild pathnames.  (PATHNAME-MATCH-P <source> <from-wildcard>) must
    be true or an error is signalled.
    
    Implementation guideline: one typical file system performs this
    operation by examining each field of the pathnames in turn, where a
    field is a component or an element of a structured component such as a
    hierarchical directory.  Hierarchical directory elements in
    <from-wildcard> and <to-wildcard> are matched by whether they are
    wildcards, not by depth in the directory hierarchy.  If the field in
    <from-wildcard> does not match the field in <source>, an error is
    signalled.  If the field in <to-wildcard> is present and not wild, it
    is copied into the result.   If the field in <to-wildcard> is :WILD or
    NIL, and either <reversible> is false or the field in <from-wildcard>
    is not a complex wildcard, the field in <source> is copied into the
    result.  Otherwise, the field in <to-wildcard> might be a complex
    wildcard such as "foo*bar" and the field in <from-wildcard> should be
    wild; the portion of the field in <source> that matches the wildcard
    portion of the field in <from-wildcard> fills in the wildcard portion
    of the field in <to-wildcard> and the field value produced is used in
    the result.

  Clarify that the functions OPEN (and WITH-OPEN-FILE), RENAME-FILE,
  DELETE-FILE, PROBE-FILE, FILE-WRITE-DATE, FILE-AUTHOR, LOAD,
  COMPILE-FILE, and TRUENAME only accept non-wildcard pathnames and signal
  an error if given a pathname for which WILD-PATHNAME-P returns true.

Examples:

  (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD)) => T
  (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :NAME) => T
  (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :TYPE) => NIL
  (WILD-PATHNAME-P (PATHNAME "S:>foo>**>")) => T   ;Lispm
  (WILD-PATHNAME-P (PATHNAME :NAME "F*O")) => T    ;Most places

  ;This example assumes one particular set of wildcard conventions
  ;Not all file systems will run this example exactly as written
  (DEFUN RENAME-FILES (FROM TO)
    (DOLIST (FILE (DIRECTORY FROM))
      (RENAME-FILE FILE (TRANSLATE-PATHNAME FILE FROM TO))))
  (RENAME-FILES "/usr/me/*.lisp" "/dev/her/*.l")
    ;Renames /usr/me/init.lisp to /dev/her/init.l
  (RENAME-FILES "/usr/me/pcl*/*" "/sys/pcl/*/")
    ;Renames /usr/me/pcl-5-may/low.lisp to /sys/pcl/pcl-5-may/low.lisp
    ;In some file systems the result might be /sys/pcl/5-may/low.lisp
  (RENAME-FILES "/usr/me/pcl*/*" "/sys/library/*/")
    ;Renames /usr/me/pcl-5-may/low.lisp to /sys/library/pcl-5-may/low.lisp
    ;In some file systems the result might be /sys/library/5-may/low.lisp
  (RENAME-FILES "/usr/me/foo.bar" "/usr/me2/")
    ;Renames /usr/me/foo.bar to /usr/me2/foo.bar

  ;This example assumes one particular set of wildcard conventions and
  ;illustrates how and why reversible translation uses different rules
  (PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*baz" NIL)) => "barbaz"
  (PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*baz" T))   => "barbaz"
  (PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*"    NIL)) => "foobar"
  (PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "foo*" "*"    T))   => "bar"
  (PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "*"    "foo*" NIL)) => "foofoobar"
  (PATHNAME-NAME (TRANSLATE-PATHNAME "foobar" "*"    "foo*" T))   => "foofoobar"
  (PATHNAME-NAME (TRANSLATE-PATHNAME "bar"    "*"    "foo*" NIL)) => "foobar"
  (PATHNAME-NAME (TRANSLATE-PATHNAME "bar"    "*"    "foo*" T))   => "foobar"

  ;This example presumes background information described in PATHNAME-LOGICAL
  (DEFUN TRANSLATE-LOGICAL-PATHNAME-1 (PATHNAME RULES)
    (LET ((RULE (ASSOC PATHNAME RULES :TEST #'PATHNAME-MATCH-P)))
      (UNLESS RULE (ERROR "No translation rule for ~A" PATHNAME))
      (TRANSLATE-PATHNAME PATHNAME (FIRST RULE) (SECOND RULE) T)))
  (TRANSLATE-LOGICAL-PATHNAME-1 "FOO:CODE;BASIC.LISP"
                        '(("FOO:DOCUMENTATION;" "MY-UNIX:/doc/foo/")
                          ("FOO:CODE;"          "MY-UNIX:/lib/foo/")
                          ("FOO:PATCHES;*;"     "MY-UNIX:/lib/foo/patch/*/")))
   => the pathname MY-UNIX:/lib/foo/basic.l

Rationale:

  These three functions provide a standardized interface to the
  idiosyncratic wildcard functionality of each host file system.

  WILD-PATHNAME-P makes it possible to detect wild pathnames reliably and
  do something useful (give up, merge out the bothersome components, call
  DIRECTORY for a list of matching pathnames, etc.)

  TRANSLATE-PATHNAME is needed by many application programs that deal with
  wildcard pathnames.  PATHNAME-MATCH-P and TRANSLATE-PATHNAME are needed
  by logical pathnames.  The reversible feature is needed by logical
  pathnames.

Current Practice:

  Presumably no implementation supports the proposal exactly as stated.
  Symbolics Genera has had similar features under different names for many
  years:

    (SEND pathname :WILD-P) returns a value such as NIL, :NAME, :TYPE,
    etc., indicating the first wild field.

    (SEND pathname :NAME-WILD-P), (SEND pathname :DIRECTORY-WILD-P),
    etc. test individual fields.

    The :TRANSLATE-WILD-PATHNAME, :TRANSLATE-WILD-PATHNAME-REVERSIBLE, and
    :PATHNAME-MATCH messages resemble TRANSLATE-PATHNAME and
    PATHNAME-MATCH-P.

  The clarification is current practice as far as the authors are aware.
  If some implementations are found that specify a meaning for wildcard
  pathnames as arguments to these functions, this proposal should be changed
  to say that the consequences are unspecified rather than signalling an error.

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 wildcards to write it.

  Since the detailed behavior is at the implementor's discretion, the cost
  is unlikely to be large.  Some file systems will do all the work and the
  implementor need only provide an interface to the file system or to a
  standard library routine.  For other file systems the implementor has to
  write the actual matching and translation algorithms.

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  Wild pathnames would continue to be mistaken for ordinary pathnames in
  many situations.  User programs that deal with wildcard pathnames would
  have to operate on implementation-dependent representations and hence
  would not be easily portable.

  The biggest cost is that any logical pathnames proposal would be stymied.

Performance Impact:

  None.

Benefits:

  A more complete set of wildcard pathname operations.  Portable user
  programs that deal with wildcard pathnames will be more consistent
  and reliable.  A portable system construction tool can be written
  and the foundations are laid for a `logical pathname' facility
  (proposed separately in PATHNAME-LOGICAL).

Aesthetics:

  This change would make some portable code less kludgey.

Discussion:

  There was some question about the name. The name PATHNAME-WILD-P
  suggests a ``slot'' of a pathname (like PATHNAME-HOST),
  while WILD-PATHNAME-P suggests a type (like INPUT-STREAM-P).
  The committee was split on what to call it. Since it is more
  like a type than a slot, the name WILD-PATHNAME-P was chosen.

∂23-May-89  1148	CL-Cleanup-mailer 	Issue: DATA-IO (version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89  11:47:55 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599434; 23 May 89 14:25:29 EDT
Date: Tue, 23 May 89 14:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DATA-IO (version 6)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523182956.9.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>

This is a new issue.  It arose from an investigation of features
that are plausibly needed but missing from draft ANSI Common Lisp.
This issue seems sufficiently simple and noncontroversial that
I would like to see it on the agenda for the June X3J13 meeting.
Let's use the cleanup subcommittee to test the assertion that this
is a simple and noncontroversial issue.  If it's controversial,
let's just drop it, otherwise let's give X3J13 a chance to vote
for or against it.

Issue:          DATA-IO
References:     CLtL pp.360, 370, 382
Related issues: none
Category:       ADDITION
Edit history:   Version 1,  9-May-89, by Moon
                Version 2, 10-May-89, by Moon
                        (clarify ambiguities, add PRINT-UNREADABLE-OBJECT)
                Version 3, 18-May-89, by Moon (respond to KMP's comments)
                Version 4, 21-May-89, by Moon (almost-final cleanup)
                Version 5, 22-May-89, by Pitman (``never say never'')
                Version 6, 23-May-89, by Moon (final cleanup)

Problem description:

  Storing data in textual form in files, as Lisp expressions, is common
  practice but has some pitfalls.  Files can be unreadable if #<...> syntax
  is written by the printer, or if the reader syntax or package varies
  between writing and reading.  Files of data intended to be carried from
  one Lisp implementation to another can fail to read correctly if
  implementation-dependent syntax extensions get used when not intended.

  CLtL p.370 recommends that unreadable objects be printed with #<...>
  syntax including implementation-dependent information.  Now that users
  can write their own PRINT-OBJECT methods, a way is needed for such
  methods to print this syntax without any implementation-dependent coding.

Proposal (DATA-IO:ADD-SUPPORT):

  Add a new variable *PRINT-READABLY*.  Add a corresponding keyword
  argument :READABLY to WRITE.  The default value of *PRINT-READABLY* is
  NIL.  If :READABLY (which defaults to *PRINT-READABLY*) is true, then
  printing any object produces a printed representation that the reader
  will accept.  If this is not possible, the printer signals an error of
  type PRINT-NOT-READABLE rather than using an unreadable syntax such as
  #<...>.  The printed representation produced when :READABLY is true might
  or might not be the same as the printed representation produced when
  :READABLY is false.

  All methods for PRINT-OBJECT must obey *PRINT-READABLY*.  This includes
  both user-defined methods and implementation-defined methods.

  Printed representations produced when *PRINT-READABLY* is true and
  *PRINT-ESCAPE* is false might or might not be readable.

  Setting *PRINT-ESCAPE* to false might or might not prevent errors of type
  PRINT-NOT-READABLE from being signalled.

  Add two new macros:

    WITH-STANDARD-IO-SYNTAX &body body                             [Macro]

    Within the dynamic extent of <body>, all reader/printer control
    variables, including any implementation-defined ones not specified by
    Common Lisp, are bound to values that produce standard read/print
    behavior.  The values for Common Lisp specified variables are:

      *PACKAGE*                            The USER package
      *PRINT-ARRAY*                        T
      *PRINT-BASE*                         10
      *PRINT-CASE*                         :UPCASE
      *PRINT-CIRCLE*                       NIL
      *PRINT-ESCAPE*                       T
      *PRINT-GENSYM*                       T
      *PRINT-LENGTH*                       NIL
      *PRINT-LEVEL*                        NIL
      *PRINT-PRETTY*                       NIL
      *PRINT-RADIX*                        NIL
      *PRINT-READABLY*                     T
      *READ-BASE*                          10
      *READ-DEFAULT-FLOAT-FORMAT*          SINGLE-FLOAT
      *READ-SUPPRESS*                      NIL
      *READTABLE*                          The standard readtable

    PRINT-UNREADABLE-OBJECT (object stream &key type identity)      [Macro]
                            &body body

    Output a printed representation of <object> on <stream>, beginning with
    "#<" and ending with ">".  Everything output to <stream> by the <body>
    forms is enclosed in the angle brackets.  If :type is true, the body
    output is preceded by a brief description of the object's type and a
    space character.  If :identity is true, the body output is followed by
    a space character and a representation of the object's identity,
    typically a storage address.

    If *PRINT-READABLY* is true, PRINT-UNREADABLE-OBJECT signals an error
    of type PRINT-NOT-READABLE without printing anything.

    The <object>, <stream>, :type, and :identity arguments are all evaluated
    normally.  :type and :identity default to false.  It is valid to omit
    the <body> forms.  If :type and :identity are both true and there are no
    <body> forms, only one space character separates the type and the identity.

  Add a new condition type:

    PRINT-NOT-READABLE                                             [Type]

    Errors which occur during output while *PRINT-READABLY* is true, as a
    result of attempting to output a printed representation that cannot be
    read back, should inherit from this type.  This is a subtype of ERROR.
    The init keyword :OBJECT is supported to initialize the slot containing
    the object being printed, which can be accessed using
    PRINT-NOT-READABLE-OBJECT.

Examples:

  ;; Example #1: Reliable Write-Read

  (WITH-OPEN-FILE (FILE pathname :DIRECTION :OUTPUT)
    (WITH-STANDARD-IO-SYNTAX
      (PRINT DATA FILE)))

  ; ... Later, in another Lisp:

  (WITH-OPEN-FILE (FILE pathname :DIRECTION :INPUT)
    (WITH-STANDARD-IO-SYNTAX
      (SETQ DATA (READ FILE))))

  ;; Example #2: Use of PRINT-UNREADABLE-OBJECT
  ;; Note that in this example, the precise form of the output
  ;; is really implementation-dependent.

  (DEFMETHOD PRINT-OBJECT ((OBJ AIRPLANE) STREAM)
    (PRINT-UNREADABLE-OBJECT (OBJ STREAM :TYPE T :IDENTITY T)
      (PRINC (TAIL-NUMBER OBJ) STREAM)))

  (PRINT MY-AIRPLANE)
  #<Airplane NW0773 36000123135>        ;in Implementation A
                                        ;or
  #<FAA:AIRPLANE NW0773 17>             ;in Implementation B

Rationale:

  *PRINT-READABLY* is important so that errors involving data with no
  readable printed representation are detected when writing the file, not
  later on when the file is read.

  *PRINT-READABLY* is different from *PRINT-ESCAPE* because output printed
  with escapes only has to be generally recognizable by humans, whereas
  output printed readably has to be reliably recognizable by computers.

  Providing the WITH-STANDARD-IO-SYNTAX macro to bind all the variables,
  instead of using LET and explicit bindings of the existing variables,
  ensures that nothing is overlooked and avoids problems with
  implementation-defined reader/printer control variables.

  If the user wishes to use a non-standard value for some variable, most
  commonly *PACKAGE*, it can be bound by LET inside the body of
  WITH-STANDARD-IO-SYNTAX.  Similarly, if the user dislikes the somewhat
  arbitrary choices of values for *PRINT-CIRCLE* and *PRINT-PRETTY*, they
  can be bound to the preferred values inside the body.

Current practice:

  Symbolics Genera has had these features for many years, except that
  WITH-STANDARD-IO-SYNTAX is named WITH-STANDARD-IO-ENVIRONMENT and binds
  *PACKAGE* to a non-standard package.  The new name both is more accurate
  and avoids compatibility problems for Genera.

  Genera's WITH-STANDARD-IO-ENVIRONMENT also disables #., to prevent trojan
  horses, since #. could evaluate an arbitrary form.  This is particularly
  important for network protocols.  This feature is not being proposed for
  Common Lisp at this time as it would prevent using #. in the printer for
  common datatypes, which is current practice in some implementations.  #.
  suppression could be a separate reader/printer control variable.

  In Genera, PRINT-UNREADABLE-OBJECT is called SYS:PRINTING-RANDOM-OBJECT
  and takes slightly different arguments. In PCL, PRINT-UNREADABLE-OBJECT
  is called PCL:PRINTING-RANDOM-THING.

Cost to Implementors:

  Very small.

Cost to Users:

  None if they don't use the feature.  Otherwise just the cost of
  supporting *PRINT-READABLY* or using PRINT-UNREADABLE-OBJECT in their
  PRINT-OBJECT methods.

Cost of non-adoption:

  There will be no reliable, standard way to write data into a file.

Performance impact:

  Negligible.  Entering WRITE may be slightly slower since there is
  one more keyword argument to parse and one more special variable
  to bind before calling PRINT-OBJECT.

Benefits:

  Data can be written into files reliably without resorting to
  implementation-specific programming.

Esthetics:

  Mildly improved.

Discussion:

  Pitman and Moon support this proposal.

∂23-May-89  1148	CL-Cleanup-mailer 	Issue: STRING-COERCION (version 2)  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89  11:48:21 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599438; 23 May 89 14:29:55 EDT
Date: Tue, 23 May 89 14:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STRING-COERCION (version 2)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523183420.0.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>

This is a new issue.  This issue seems sufficiently simple and
noncontroversial that I would like to see it on the agenda for the June
X3J13 meeting.  Let's use the cleanup subcommittee to test the assertion
that this is a simple and noncontroversial issue.  If it's
controversial, let's just drop it, otherwise let's give X3J13 a chance
to vote for or against it.

Issue:          STRING-COERCION
References:     Strings (pp299-304),
                STRING= (p300), STRING-EQUAL (p301), STRING< (p301),
                STRING> (p301), STRING<= (p301), STRING>= (p301),
                STRING/= (p301), STRING-LESSP (p302), STRING-GREATERP (p302),
                STRING-NOT-GREATERP (p302), STRING-NOT-LESSP (p302),
                STRING-NOT-EQUAL (p302), STRING-TRIM (p302), STRING-LEFT-TRIM (p302),
                STRING-RIGHT-TRIM (p302), STRING-UPCASE (p303), STRING-DOWNCASE (p303),
                and STRING-CAPITALIZE (p303).
Related issues: none
Category:       CLARIFICATION
Edit history:   Version 1, 9-May-89 by Moon
                Version 2, 9-May-89 by Pitman (editorial changes)

Problem description:

  CLtL is inconsistent about the argument coercion performed by the
  referenced functions. Page 299 says that the <string> argument can
  be either a symbol or a string.  Page 304 says that these functions
  effectively call the STRING function, thus accepting a symbol,
  a string, or a character.

  Neither page lists the set of affected functions explicitly.

  Page 304 says that if any other data type is used, an error is
  signalled.  But some implementations allow other types, such as
  pathnames, to be coerced to strings, which page 299 appears to allow
  but page 304 appears to forbid.  In some implementations these
  coercions are under user control via methods for a generic function.

Proposal (STRING-COERCION:MAKE-CONSISTENT):

  Specify that the referenced functions perform coercion identical to
  the action of the STRING function.

  Specify that the STRING function can perform additional implementation
  dependent coercions.  In all cases the returned value is of type STRING.
  Only in the case where no coercion is defined is the STRING function
  required to signal an error; in that case, the error is of type TYPE-ERROR.

Examples:

  (string-lessp #\a "B") => T

Rationale:

  Our choices are to make the coercion identical to the STRING function,
  identical to the COERCE function, or different from both of them.  The
  COERCE function won't coerce non-null symbols to strings, so it is out.
  Being consistent with the STRING function seems better than inventing
  yet another set of string coercion rules.  Removing the ability for the
  STRING function to coerce characters to strings would be an incompatible
  change, so instead we clarify that the other functions have that ability.

  Allowing additional coercions is harmless and consistent with current
  practice.

Current practice:

  Symbolics Genera follows page 304 except for allowing additional
  coercions.  Symbolics Cloe follows page 299 except for not allowing
  additional coercions.

Cost to Implementors:

  Small changes to eighteen functions.

Cost to Users:

  None, this is upward-compatible.

Cost of non-adoption:

  Inconsistency and confusion about what coercions are allowed.

Performance impact:

  None.  If these things have to accept symbols, accepting characters
  too can't make much difference.  The implementation of character
  arguments to string functions might cons a string, but this has no
  performance impact on programs that don't use the feature.

Benefits:

  Consistency.

Esthetics:

  Consistency.

Discussion:

  None.

∂23-May-89  1148	CL-Cleanup-mailer 	Issue: BIT-ARRAY-FUNCTIONS (version 5)   
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 23 May 89  11:48:21 PDT
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 599444; 23 May 89 14:38:13 EDT
Date: Tue, 23 May 89 14:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: BIT-ARRAY-FUNCTIONS (version 5)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890523184240.1.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>

This is a new issue.  It arose from an investigation of features
that are plausibly needed but missing from draft ANSI Common Lisp.
This issue seems sufficiently simple and noncontroversial that
I would like to see it on the agenda for the June X3J13 meeting.
Let's use the cleanup subcommittee to test the assertion that this
is a simple and noncontroversial issue.  If it's controversial,
let's just drop it, otherwise let's give X3J13 a chance to vote
for or against it.

Issue:         BIT-ARRAY-FUNCTIONS
References:    The binary bit-array functions BIT-AND, BIT-IOR, BIT-XOR,
               BIT-EQV, BIT-NAND, BIT-NOR, BIT-ANDC1, BIT-ANDC2, BIT-ORC1,
               and BIT-ORC2 (CLtL p.294).
               The unary bit-array function BIT-NOT (CLtL p.295).
               The mapping functions EVERY, MAP, NOTANY, NOTEVERY, and SOME
               (CLtL pp.249-250).
               The