perm filename CLCLEA.5[COM,LSP] blob sn#870941 filedate 1989-03-13 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00608 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00088 00002	
C00089 00003	∂11-Dec-88  1051	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)   
C00094 00004	∂11-Dec-88  1549	CL-Cleanup-mailer 	Issue PACKAGE-CLUTTER (Version 5)   
C00096 00005	∂12-Dec-88  0929	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3) 
C00100 00006	∂12-Dec-88  0930	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)   
C00103 00007	∂12-Dec-88  0929	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)   
C00106 00008	∂12-Dec-88  0929	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 2) 
C00109 00009	∂12-Dec-88  0949	CL-Cleanup-mailer 	Issue: DEFSTRUCT-REDEFINITION (version 1)
C00113 00010	∂12-Dec-88  1025	CL-Cleanup-mailer 	Re: discussion of Moon's comments re: ELIMINATE-FORCED-CONSING    
C00115 00011	∂12-Dec-88  1143	CL-Cleanup-mailer 	RE: Issue: HASH-TABLE-ACCESS (version 2) 
C00117 00012	∂12-Dec-88  1212	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-KEY-MODIFICATION (and HASH-TABLE-STABILITY) 
C00119 00013	∂12-Dec-88  1444	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 4)  
C00124 00014	∂12-Dec-88  1448	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 5)  
C00127 00015	∂12-Dec-88  1527	CL-Cleanup-mailer 	Re: Issue: SYMBOL-MACROFLET (Version 1)  
C00129 00016	∂12-Dec-88  1546	CL-Cleanup-mailer 	REST-LIST-ALLOCATION (Version 3)    
C00143 00017	∂12-Dec-88  1748	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)   
C00147 00018	∂12-Dec-88  1755	X3J13-mailer 	Issue: TAILP-NIL (Version 5)   
C00149 00019	∂12-Dec-88  2019	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 6) 
C00151 00020	∂13-Dec-88  0831	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 5)   
C00154 00021	∂13-Dec-88  0856	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 5)   
C00157 00022	∂13-Dec-88  1130	CL-Cleanup-mailer 	New issue: COMPLEX-ATAN-BRANCH-CUT  
C00162 00023	∂13-Dec-88  1131	CL-Cleanup-mailer 	New issue: IEEE-ATAN-BRANCH-CUT
C00170 00024	∂13-Dec-88  1446	CL-Cleanup-mailer 	Issues: SETF-PLACES, SETF-FUNCTION-VERSUS-MACRO    
C00175 00025	∂13-Dec-88  1509	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 5) 
C00178 00026	∂13-Dec-88  1606	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 5)   
C00186 00027	∂13-Dec-88  1645	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 9) 
C00191 00028	∂13-Dec-88  1800	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 5) 
C00223 00029	∂13-Dec-88  1816	CL-Cleanup-mailer 	Issue: REST-LIST-ALLOCATION (Version 3)  
C00228 00030	∂13-Dec-88  2111	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
C00243 00031	∂13-Dec-88  2201	CL-Cleanup-mailer 	Issue: CLOSE-CONSTRUCTED-STREAMS (not yet submitted)    
C00248 00032	∂13-Dec-88  2207	CL-Cleanup-mailer 	Re: Issue ALIST-NIL  
C00250 00033	∂13-Dec-88  2215	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)    
C00253 00034	∂13-Dec-88  2241	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)  
C00259 00035	∂14-Dec-88  0007	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 5)   
C00262 00036	∂14-Dec-88  0019	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE (Version 2)
C00264 00037	∂14-Dec-88  0143	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 7)  
C00267 00038	∂14-Dec-88  0208	CL-Cleanup-mailer 	Please add me to the cl-cleanup mailing list  
C00269 00039	∂14-Dec-88  1037	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 5)   
C00273 00040	∂14-Dec-88  1157	X3J13-mailer 	Issue: PACKAGE-CLUTTER (Version 6)  
C00275 00041	∂15-Dec-88  1315	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)     
C00278 00042	∂15-Dec-88  1358	CL-Cleanup-mailer 	Issue: HASH-TABLE-KEY-MODIFICATION (and HASH-TABLE-STABILITY)
C00283 00043	∂15-Dec-88  1444	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 5) 
C00285 00044	∂15-Dec-88  1515	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 5) 
C00288 00045	∂15-Dec-88  2136	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 5)   
C00291 00046	∂15-Dec-88  2203	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 5) 
C00294 00047	∂16-Dec-88  0108	CL-Cleanup-mailer 	Really about the ontology of EQ {Issue: TAILP-NIL (Version 5)}    
C00299 00048	∂16-Dec-88  0838	CL-Cleanup-mailer 	EQ    
C00302 00049	∂16-Dec-88  1101	CL-Cleanup-mailer 	Really about the ontology of EQ {Issue: TAILP-NIL (Version 5)}    
C00304 00050	∂17-Dec-88  0118	CL-Cleanup-mailer 	EQ    
C00309 00051	∂17-Dec-88  1338	CL-Cleanup-mailer 	Re: EQ
C00312 00052	∂20-Dec-88  1710	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 5) 
C00317 00053	∂22-Dec-88  1127	CL-Cleanup-mailer 	Issue: LISP-PACKAGE-NAME (Version 1)
C00330 00054	∂22-Dec-88  1350	CL-Cleanup-mailer 	Re: Issue: LISP-PACKAGE-NAME (Version 1) 
C00334 00055	∂22-Dec-88  1545	CL-Cleanup-mailer 	Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C00345 00056	∂22-Dec-88  1614	CL-Cleanup-mailer 	Re: Issue: LISP-PACKAGE-NAME (Version 1) 
C00353 00057	∂27-Dec-88  1209	CL-Cleanup-mailer 	Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C00358 00058	∂27-Dec-88  1716	CL-Cleanup-mailer 	Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)   
C00371 00059	∂27-Dec-88  1724	CL-Cleanup-mailer 	Issue: SETF-SUB-METHODS   
C00373 00060	∂28-Dec-88  1133	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3) 
C00386 00061	∂28-Dec-88  1259	CL-Cleanup-mailer 	Issue: PATHNAME-EXTENSIONS (Version 1)   
C00396 00062	∂29-Dec-88  0353	CL-Cleanup-mailer 	Issue: SETF-SUB-METHODS   
C00399 00063	∂29-Dec-88  1006	CL-Cleanup-mailer 	Issue: PATHNAME-EXTENSIONS (Version 1)   
C00401 00064	∂29-Dec-88  1031	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3) 
C00409 00065	∂29-Dec-88  1038	CL-Cleanup-mailer 	Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)   
C00411 00066	∂29-Dec-88  1040	CL-Cleanup-mailer 	Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)   
C00414 00067	∂29-Dec-88  1119	CL-Cleanup-mailer 	Issue: PATHNAME-EXTENSIONS (Version 1)   
C00419 00068	∂29-Dec-88  1132	CL-Cleanup-mailer 	Issue: PATHNAME-EXTENSIONS (Version 1)   
C00422 00069	∂29-Dec-88  1153	CL-Cleanup-mailer 	Issue: PATHNAME-EXTENSIONS (Version 1)   
C00426 00070	∂29-Dec-88  1157	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3) 
C00439 00071	∂29-Dec-88  1219	CL-Cleanup-mailer 	Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)   
C00441 00072	∂29-Dec-88  1228	CL-Cleanup-mailer 	Issue: PATHNAME-EXTENSIONS (Version 1)   
C00453 00073	∂29-Dec-88  1308	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3) 
C00462 00074	∂29-Dec-88  1451	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3) 
C00465 00075	∂29-Dec-88  1834	CL-Cleanup-mailer 	Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1) 
C00467 00076	∂30-Dec-88  0234	CL-Cleanup-mailer 	Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C00470 00077	∂30-Dec-88  1425	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)    
C00476 00078	∂30-Dec-88  1432	CL-Cleanup-mailer 	Issue SPECIAL-TYPE-SHADOWING (V1)   
C00478 00079	∂30-Dec-88  1446	CL-Cleanup-mailer 	Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES  
C00488 00080	∂30-Dec-88  1525	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 2) 
C00493 00081	∂30-Dec-88  1628	CL-Cleanup-mailer 	Issue GC-MESSAGES (Version 2)  
C00496 00082	∂30-Dec-88  1650	CL-Cleanup-mailer 	Issue GC-MESSAGES (Version 2)  
C00502 00083	∂31-Dec-88  1935	CL-Cleanup-mailer 	Issue SYNTACTIC-ENVIRONMENT-ACCESS  
C00504 00084	∂31-Dec-88  2001	CL-Cleanup-mailer 	Issue EXIT-EXTENT, v5
C00508 00085	∂01-Jan-89  0259	CL-Cleanup-mailer 	*** HELP ***    
C00510 00086	∂01-Jan-89  0302	CL-Cleanup-mailer 	Issue FIXNUM-NON-PORTABLE, v4  
C00513 00087	∂01-Jan-89  2142	CL-Cleanup-mailer 	Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES  
C00517 00088	∂01-Jan-89  2359	CL-Cleanup-mailer 	Issue SYNTACTIC-ENVIRONMENT-ACCESS  
C00520 00089	∂02-Jan-89  1037	CL-Cleanup-mailer 	Issue: REST-LIST-ALLOCATION (Version 3)  
C00527 00090	∂02-Jan-89  1044	CL-Cleanup-mailer 	Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES  
C00534 00091	∂02-Jan-89  1045	CL-Cleanup-mailer 	*** HELP ***    
C00536 00092	∂02-Jan-89  1202	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 2)   
C00551 00093	∂02-Jan-89  1233	CL-Cleanup-mailer 	Issue: REST-LIST-ALLOCATION (Version 3)  
C00560 00094	∂02-Jan-89  1328	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 1)
C00570 00095	∂02-Jan-89  1444	CL-Cleanup-mailer 	[Kim A. Barrett <IIM@ECLA.USC.EDU>: Ballot reply]  
C00598 00096	∂02-Jan-89  1455	CL-Cleanup-mailer 	re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2)
C00601 00097	∂02-Jan-89  1517	CL-Cleanup-mailer 	re: Issue: EQUAL-STRUCTURE (Version 5)   
C00605 00098	∂02-Jan-89  1517	CL-Cleanup-mailer 	re: Issue: EXIT-EXTENT (Version 5)  
C00607 00099	∂02-Jan-89  1521	CL-Cleanup-mailer 	re: Issue: EXIT-EXTENT (Version 5)  
C00609 00100	∂02-Jan-89  1521	CL-Cleanup-mailer 	re: Issue: FIXNUM-NON-PORTABLE (Version 4)    
C00612 00101	∂02-Jan-89  1524	CL-Cleanup-mailer 	re: Issue: PACKAGE-CLUTTER:REDUCE (Version 6) 
C00613 00102	∂02-Jan-89  1525	CL-Cleanup-mailer 	re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)    
C00615 00103	∂02-Jan-89  1524	CL-Cleanup-mailer 	re: Issue: HASH-TABLE-STABILITY (Version 1)   
C00617 00104	∂02-Jan-89  1528	CL-Cleanup-mailer 	re: Issue: REST-LIST-ALLOCATION (Version 3)   
C00619 00105	∂02-Jan-89  1529	CL-Cleanup-mailer 	re: Issue: STEP-ENVIRONMENT (Version 3)  
C00621 00106	∂02-Jan-89  1635	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 9)
C00639 00107	∂02-Jan-89  1737	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, Version 1   
C00651 00108	∂02-Jan-89  1811	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 9)
C00654 00109	∂02-Jan-89  1820	CL-Cleanup-mailer 	Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)    
C00656 00110	∂02-Jan-89  1821	CL-Cleanup-mailer 	Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)    
C00658 00111	∂02-Jan-89  1836	CL-Cleanup-mailer 	Issues: SINGLE-FLOAT-NON-PORTABLE,  
C00670 00112	∂02-Jan-89  1852	CL-Cleanup-mailer 	Re: Issue: TAILP-NIL (Version 5)    
C00673 00113	∂02-Jan-89  1916	CL-Cleanup-mailer 	Re: Issue: REST-LIST-ALLOCATION (Version 3)   
C00676 00114	∂02-Jan-89  2102	CL-Cleanup-mailer 	Re: Issue: PATHNAME-PRINT-READ (Version 1)    
C00678 00115	∂02-Jan-89  2109	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL ? 
C00680 00116	∂02-Jan-89  2118	CL-Cleanup-mailer 	Re: issue COMPILE-ARGUMENT-PROBLEMS 
C00684 00117	∂02-Jan-89  2118	CL-Cleanup-mailer 	Re: issue COMPILE-ARGUMENT-PROBLEMS 
C00686 00118	∂02-Jan-89  2127	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (Version 5) 
C00688 00119	∂02-Jan-89  2210	CL-Cleanup-mailer 	Re: issue COMPILE-ARGUMENT-PROBLEMS 
C00692 00120	∂02-Jan-89  2214	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
C00700 00121	∂02-Jan-89  2225	CL-Cleanup-mailer 	Re: Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1)  
C00702 00122	∂02-Jan-89  2236	CL-Cleanup-mailer 	Re: Issue: DELETE-FILE-NONEXISTENT (Version 1)
C00704 00123	∂02-Jan-89  2248	CL-Cleanup-mailer 	Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)   
C00706 00124	∂03-Jan-89  0027	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
C00711 00125	∂03-Jan-89  0542	CL-Cleanup-mailer 	Re: Issue: DYNAMIC-EXTENT (Version 2)    
C00716 00126	∂03-Jan-89  0758	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL ? 
C00719 00127	∂03-Jan-89  0800	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, Version 1   
C00721 00128	∂03-Jan-89  0812	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, Version 1   
C00725 00129	∂03-Jan-89  0834	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 2)   
C00727 00130	∂03-Jan-89  0902	CL-Cleanup-mailer 	Re:  Issue: REST-LIST-ALLOCATION (Version 3)  
C00730 00131	∂03-Jan-89  0916	CL-Cleanup-mailer 	Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES   
C00736 00132	∂03-Jan-89  0924	CL-Cleanup-mailer 	Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES   
C00741 00133	∂03-Jan-89  0938	CL-Cleanup-mailer 	Re:  Issue: REST-LIST-ALLOCATION (Version 3)  
C00745 00134	∂03-Jan-89  0946	CL-Cleanup-mailer 	Re: Issue GC-MESSAGES (Version 2)   
C00748 00135	∂03-Jan-89  0952	CL-Cleanup-mailer 	Re: Issue GC-MESSAGES (Version 2)   
C00752 00136	∂03-Jan-89  0955	CL-Cleanup-mailer 	Re: Issue COMPILER-DIAGNOSTICS, v7  
C00754 00137	∂03-Jan-89  1020	CL-Cleanup-mailer 	Re: Issue: PATHNAME-EXTENSIONS (Version 1)    
C00757 00138	∂03-Jan-89  1056	CL-Cleanup-mailer 	Re: Issue COMPILER-DIAGNOSTICS, v7  
C00762 00139	∂03-Jan-89  1056	CL-Cleanup-mailer 	Re: Issue GC-MESSAGES (Version 2)   
C00771 00140	∂03-Jan-89  1227	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
C00774 00141	∂03-Jan-89  1507	CL-Cleanup-mailer 	ballot
C00787 00142	∂03-Jan-89  1818	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
C00789 00143	∂03-Jan-89  1819	CL-Cleanup-mailer 	meeting in Hawaii    
C00790 00144	∂03-Jan-89  1820	CL-Cleanup-mailer 	Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1) 
C00792 00145	∂03-Jan-89  2230	CL-Cleanup-mailer 	Issue: REST-LIST-ALLOCATION (Version 3)  
C00797 00146	∂04-Jan-89  0103	CL-Cleanup-mailer 	Issue: HASH-TABLE-STABILITY (Version 1)  
C00799 00147	∂04-Jan-89  0140	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 9)
C00803 00148	∂04-Jan-89  0206	CL-Cleanup-mailer 	Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)   
C00806 00149	∂04-Jan-89  0210	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL ? 
C00808 00150	∂04-Jan-89  0224	CL-Cleanup-mailer 	Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES  
C00812 00151	∂04-Jan-89  0311	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE, v4   
C00814 00152	∂04-Jan-89  0623	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE, v4   
C00816 00153	∂04-Jan-89  1116	CL-Cleanup-mailer 	Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES   
C00823 00154	∂04-Jan-89  1137	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE, v4   
C00826 00155	∂04-Jan-89  1503	CL-Cleanup-mailer 	Issue PATHNAME-PRINT-READ, v1  
C00828 00156	∂04-Jan-89  1547	CL-Cleanup-mailer 	meeting in Hawaii    
C00830 00157	∂04-Jan-89  1549	CL-Cleanup-mailer 	Issue PATHNAME-PRINT-READ, v1  
C00837 00158	∂04-Jan-89  1633	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, v1
C00841 00159	∂04-Jan-89  1641	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, v1
C00843 00160	∂04-Jan-89  1900	CL-Cleanup-mailer 	meeting in Hawaii    
C00845 00161	∂05-Jan-89  1113	CL-Cleanup-mailer 	Symbolics response to mail ballot   
C00874 00162	∂05-Jan-89  1113	CL-Cleanup-mailer 	Issue PATHNAME-PRINT-READ, v1  
C00876 00163	∂05-Jan-89  1208	CL-Cleanup-mailer 	Issue PATHNAME-PRINT-READ, v1  
C00878 00164	∂05-Jan-89  1208	CL-Cleanup-mailer 	Symbolics response to mail ballot   
C00907 00165	∂05-Jan-89  1313	CL-Cleanup-mailer 	Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **     
C00920 00166	∂05-Jan-89  1539	CL-Cleanup-mailer 	Issue: REST-LIST-ALLOCATION (Version 3)  
C00922 00167	∂05-Jan-89  1806	CL-Cleanup-mailer 	Ballot
C00932 00168	∂05-Jan-89  2029	CL-Cleanup-mailer 	Issue PATHNAME-PRINT-READ, v1, and then some  
C00937 00169	∂06-Jan-89  0759	CL-Cleanup-mailer 	Re: Issue PATHNAME-PRINT-READ, v1, and then some   
C00940 00170	∂06-Jan-89  0919	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 1)
C00944 00171	∂06-Jan-89  1006	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 1) 
C00947 00172	∂06-Jan-89  1115	CL-Cleanup-mailer 	Issue FUNCTION-COMPOSITION
C00949 00173	∂06-Jan-89  1438	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 1) 
C00956 00174	∂06-Jan-89  1502	CL-Cleanup-mailer 	Re: Issue MACRO-FUNCTION-ENVIRONMENT, v1 
C00969 00175	∂06-Jan-89  1502	CL-Cleanup-mailer 	environment argument for SUBTYPEP   
C00971 00176	∂06-Jan-89  1503	CL-Cleanup-mailer 	Re: ballot 
C00973 00177	∂06-Jan-89  1504	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 6)  
C00976 00178	∂06-Jan-89  1506	CL-Cleanup-mailer 	Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **     
C00978 00179	∂06-Jan-89  1503	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
C00981 00180	∂06-Jan-89  1504	CL-Cleanup-mailer 	Issue APPLYHOOK-ENVIRONMENT (not submitted)   
C00983 00181	∂06-Jan-89  1504	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)   
C00987 00182	∂06-Jan-89  1504	CL-Cleanup-mailer 	Meeting in Hawaii    
C00988 00183	∂06-Jan-89  1526	CL-Cleanup-mailer 	Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **     
C00990 00184	∂06-Jan-89  1528	CL-Cleanup-mailer 	Re: Issue PATHNAME-PRINT-READ, v1   
C00992 00185	∂06-Jan-89  1557	CL-Cleanup-mailer 	Issue FUNCTION-COMPOSITION
C00994 00186	∂06-Jan-89  1618	CL-Cleanup-mailer 	Re:  Issue FUNCTION-COMPOSITION
C00996 00187	∂06-Jan-89  2117	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, Version 1   
C00999 00188	∂06-Jan-89  2125	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 1) 
C01002 00189	∂06-Jan-89  2127	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 1)
C01007 00190	∂06-Jan-89  2246	CL-Cleanup-mailer 	Re: Ballot 
C01009 00191	∂06-Jan-89  2247	CL-Cleanup-mailer 	Issue: COMPILE-AND-LOAD-VERBOSITY????    
C01010 00192	∂06-Jan-89  2248	CL-Cleanup-mailer 	*DRAFT* issue status 
C01055 00193	∂06-Jan-89  2246	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3) 
C01058 00194	∂06-Jan-89  2246	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (Version 5)   
C01060 00195	∂06-Jan-89  2247	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 1)  
C01062 00196	∂06-Jan-89  2247	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01065 00197	∂06-Jan-89  2247	CL-Cleanup-mailer 	Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1) 
C01067 00198	∂06-Jan-89  2247	CL-Cleanup-mailer 	Issue: APPLYHOOK-ENVIRONMENT (Version 1) 
C01070 00199	∂06-Jan-89  2247	CL-Cleanup-mailer 	Re: Issue: CLOSE-CONSTRUCTED-STREAMS (not yet submitted)
C01078 00200	∂06-Jan-89  2258	CL-Cleanup-mailer 	Issue FUNCTION-COMPOSITION
C01080 00201	∂06-Jan-89  2311	CL-Cleanup-mailer 	Ballots, please 
C01082 00202	∂06-Jan-89  2349	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (Version 7)   
C01086 00203	∂07-Jan-89  0007	CL-Cleanup-mailer 	Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE (Version 2)    
C01090 00204	∂07-Jan-89  0100	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 1) 
C01092 00205	∂07-Jan-89  0927	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, Version 1   
C01095 00206	∂07-Jan-89  2109	CL-Cleanup-mailer 	votes at Hawaii 
C01096 00207	∂07-Jan-89  2109	CL-Cleanup-mailer 	[alarson@src.honeywell.com (Aaron Larson): Ballots, please]  
C01117 00208	∂07-Jan-89  2153	CL-Cleanup-mailer 	Issue PATHNAME-PRINT-READ, v1  
C01123 00209	∂07-Jan-89  2212	CL-Cleanup-mailer 	Re: Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)    
C01125 00210	∂07-Jan-89  2223	CL-Cleanup-mailer 	Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C01127 00211	∂07-Jan-89  2235	CL-Cleanup-mailer 	Issue: DEFSTRUCT-REDEFINITION (Version 2)
C01136 00212	∂08-Jan-89  0035	CL-Cleanup-mailer 	Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1) 
C01140 00213	∂08-Jan-89  0113	CL-Cleanup-mailer 	Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 3)    
C01148 00214	∂08-Jan-89  0145	CL-Cleanup-mailer 	Re: Issue: DYNAMIC-EXTENT (Version 2)    
C01150 00215	∂08-Jan-89  0831	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 2) 
C01157 00216	∂08-Jan-89  1327	CL-Editorial-mailer 	conformance & extensions issues   
C01165 00217	∂08-Jan-89  1341	CL-Cleanup-mailer 	Issue: ELIMINATE-FORCED-CONSING (Version 3)   
C01168 00218	∂08-Jan-89  1400	CL-Cleanup-mailer 	Re: Ballot 
C01170 00219	∂08-Jan-89  1405	CL-Cleanup-mailer 	Re: Ballot 
C01172 00220	∂08-Jan-89  1416	CL-Cleanup-mailer 	Re:  Issue: LISP-SYMBOL-REDEFINITION (Version 5)   
C01175 00221	∂08-Jan-89  1735	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, Version 1   
C01178 00222	∂08-Jan-89  1833	CL-Cleanup-mailer 	Issue: APPLYHOOK-ENVIRONMENT (Version 1) 
C01180 00223	∂08-Jan-89  2251	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 6) 
C01205 00224	∂08-Jan-89  2334	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE, v4   
C01208 00225	∂08-Jan-89  2357	CL-Cleanup-mailer 	Re: Issue: FORMAT-ROUNDING (Version 1)   
C01210 00226	∂08-Jan-89  2359	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COERCE-TIME (Version 2)   
C01212 00227	∂09-Jan-89  0013	CL-Cleanup-mailer 	Re: Issue GC-MESSAGES (Version 2)   
C01215 00228	∂09-Jan-89  0644	CL-Cleanup-mailer 	Re: Issue FUNCTION-COMPOSITION 
C01216 00229	∂09-Jan-89  0644	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 1)  
C01218 00230	∂09-Jan-89  0933	CL-Cleanup-mailer 	Meeting in Hawaii    
C01220 00231	∂09-Jan-89  1020	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 1)  
C01221 00232	∂09-Jan-89  1059	CL-Cleanup-mailer 	Issues: REQUIRE-PATHNAME-DEFAULTS and LOAD-TRUENAME
C01238 00233	∂09-Jan-89  1119	CL-Cleanup-mailer 	Re: Issue: EXIT-EXTENT (Version 6)  
C01241 00234	∂09-Jan-89  1125	CL-Cleanup-mailer 	re: Issue: EQUAL-STRUCTURE (Version 5)   
C01248 00235	∂09-Jan-89  1142	CL-Cleanup-mailer 	Re: Ballots, please  
C01249 00236	∂09-Jan-89  1318	CL-Cleanup-mailer 	Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1    
C01251 00237	∂09-Jan-89  1320	CL-Cleanup-mailer 	Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1    
C01254 00238	∂09-Jan-89  1553	CL-Cleanup-mailer 	Re: Ballots, please  
C01256 00239	∂09-Jan-89  1609	CL-Cleanup-mailer 	Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1    
C01260 00240	∂09-Jan-89  1722	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 1)  
C01262 00241	∂09-Jan-89  1728	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 2)  
C01264 00242	∂09-Jan-89  1822	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 2) 
C01281 00243	∂09-Jan-89  1913	CL-Cleanup-mailer 	Re: Issue: OUTPUT-STREAM-P-EXAMPLE  
C01283 00244	∂09-Jan-89  1914	CL-Cleanup-mailer 	Issue: SETF-SUB-METHODS (Version 5) 
C01285 00245	∂09-Jan-89  1913	CL-Cleanup-mailer 	re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)    
C01288 00246	∂09-Jan-89  1913	CL-Cleanup-mailer 	Re: Issue: REST-LIST-ALLOCATION (Version 3)   
C01290 00247	∂09-Jan-89  1943	CL-Cleanup-mailer 	Re: Issue: TAGBODY-CONTENTS (Version 5)  
C01293 00248	∂09-Jan-89  1952	CL-Cleanup-mailer 	Re: Ballots, please  
C01294 00249	∂09-Jan-89  1956	CL-Cleanup-mailer 	Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C01300 00250	∂09-Jan-89  2142	CL-Cleanup-mailer 	Issue: FORMAT-ROUNDING (Version 1)  
C01302 00251	∂09-Jan-89  2203	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 5)  
C01304 00252	∂09-Jan-89  2230	CL-Cleanup-mailer 	ballot
C01321 00253	∂09-Jan-89  2233	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 5)   
C01323 00254	∂09-Jan-89  2238	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
C01325 00255	∂09-Jan-89  2335	CL-Cleanup-mailer 	[chapman%aitg.DEC@decwrl.dec.com: vote]  
C01336 00256	∂09-Jan-89  2341	CL-Cleanup-mailer 	Re: revised ISO discussion, revised DRAFT Gegenda and Subcommittee
C01338 00257	∂10-Jan-89  0022	CL-Cleanup-mailer 	Issue: STREAM-ACCESS (Version 2)    
C01340 00258	∂10-Jan-89  0024	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 6) 
C01344 00259	∂10-Jan-89  0039	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 1)  
C01346 00260	∂10-Jan-89  0039	CL-Cleanup-mailer 	Revised draft issue status
C01399 00261	∂10-Jan-89  0149	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 5)  
C01402 00262	∂10-Jan-89  0413	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)    
C01405 00263	∂10-Jan-89  0624	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 2) 
C01413 00264	∂10-Jan-89  0733	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 6) 
C01418 00265	∂10-Jan-89  0906	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
C01421 00266	∂10-Jan-89  0948	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 2)  
C01423 00267	∂10-Jan-89  1019	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-COPY-PLIST  
C01427 00268	∂10-Jan-89  1042	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 2) 
C01445 00269	∂10-Jan-89  1042	CL-Cleanup-mailer 	Re:  Issue: SETF-SUB-METHODS (Version 5) 
C01448 00270	∂10-Jan-89  1050	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 6) 
C01452 00271	∂10-Jan-89  1101	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 2) 
C01456 00272	∂10-Jan-89  1429	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 6) 
C01463 00273	∂10-Jan-89  1441	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-COPY-PLIST  
C01466 00274	∂10-Jan-89  1443	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01469 00275	∂10-Jan-89  1458	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01471 00276	∂10-Jan-89  1506	CL-Cleanup-mailer 	revised ISO discussion, revised DRAFT Gegenda and Subcommittee    
C01473 00277	∂10-Jan-89  1508	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
C01475 00278	∂10-Jan-89  1527	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 6)  
C01477 00279	∂10-Jan-89  1536	CL-Cleanup-mailer 	Re: New proposed issue APPEND-ATOM  
C01479 00280	∂10-Jan-89  1551	CL-Cleanup-mailer 	New proposed issue APPEND-ATOM 
C01488 00281	∂10-Jan-89  1551	CL-Cleanup-mailer 	Re: New proposed issue APPEND-ATOM  
C01491 00282	∂10-Jan-89  1552	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-COPY-PLIST  
C01499 00283	∂10-Jan-89  1556	CL-Cleanup-mailer 	Possible issue: GCD-NO-ARGUMENTS    
C01503 00284	∂10-Jan-89  1610	CL-Cleanup-mailer 	cleanup ballot  
C01514 00285	∂10-Jan-89  1610	CL-Cleanup-mailer 	cleanup ballot  
C01525 00286	∂10-Jan-89  2248	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 9)
C01528 00287	∂11-Jan-89  0004	CL-Cleanup-mailer 	Issue: SETF-SUB-METHODS (Version 5) 
C01533 00288	∂11-Jan-89  0126	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)    
C01536 00289	∂11-Jan-89  1217	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
C01539 00290	∂11-Jan-89  1429	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 6)  
C01549 00291	∂11-Jan-89  1430	CL-Cleanup-mailer 	Issue: APPLYHOOK-ENVIRONMENT (Version 2) 
C01552 00292	∂11-Jan-89  1431	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 9)
C01554 00293	∂11-Jan-89  1430	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 4) 
C01571 00294	∂11-Jan-89  1431	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
C01581 00295	∂11-Jan-89  1458	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 9)
C01584 00296	∂11-Jan-89  1513	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01588 00297	∂11-Jan-89  1514	CL-Cleanup-mailer 	Re: Issue: SETF-SUB-METHODS (Version 5)  
C01593 00298	∂11-Jan-89  1515	CL-Cleanup-mailer 	Re:  Issue: SETF-SUB-METHODS (Version 5) 
C01595 00299	∂11-Jan-89  1516	CL-Cleanup-mailer 	Re: New proposed issue APPEND-ATOM  
C01597 00300	∂11-Jan-89  1517	CL-Cleanup-mailer 	Re:  Issue: SETF-SUB-METHODS (Version 5) 
C01599 00301	∂11-Jan-89  1522	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
C01601 00302	∂11-Jan-89  1514	CL-Cleanup-mailer 	Ballot response 
C01628 00303	∂11-Jan-89  1522	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 3)   
C01647 00304	∂11-Jan-89  1522	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 2)   
C01666 00305	∂11-Jan-89  1534	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 6) 
C01668 00306	∂11-Jan-89  1558	CL-Cleanup-mailer 	Re: Issue: EXIT-EXTENT (Version 6)  
C01669 00307	∂11-Jan-89  1601	CL-Cleanup-mailer 	Re:  Issue: SETF-SUB-METHODS (Version 5) 
C01671 00308	∂11-Jan-89  1614	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
C01674 00309	∂11-Jan-89  1652	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 2)  
C01676 00310	∂11-Jan-89  1722	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 1)  
C01679 00311	∂11-Jan-89  1750	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)    
C01682 00312	∂11-Jan-89  1812	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01687 00313	∂11-Jan-89  1821	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (Version 7)   
C01692 00314	∂11-Jan-89  1928	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 7)  
C01698 00315	∂11-Jan-89  1957	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-COPY-PLIST  
C01700 00316	∂11-Jan-89  1957	CL-Cleanup-mailer 	Possible issue: GCD-NO-ARGUMENTS    
C01702 00317	∂11-Jan-89  2007	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 2)   
C01705 00318	∂11-Jan-89  2016	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)    
C01708 00319	∂11-Jan-89  2138	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01712 00320	∂11-Jan-89  2148	CL-Cleanup-mailer 	New versions vs amendments
C01714 00321	∂11-Jan-89  2222	CL-Cleanup-mailer 	Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)    
C01716 00322	∂12-Jan-89  0033	CL-Cleanup-mailer 	Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)   
C01718 00323	∂12-Jan-89  0037	CL-Cleanup-mailer 	Issue: PROCLAIM-SPECIAL (Version 9) 
C01722 00324	∂12-Jan-89  0048	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (Version 5) 
C01724 00325	∂12-Jan-89  0309	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 9)
C01727 00326	∂12-Jan-89  0420	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 7)  
C01730 00327	∂12-Jan-89  0520	CL-Cleanup-mailer 	** BALLOT ** BALLOT ** BALLOT ** BALLOT **    
C01746 00328	∂12-Jan-89  0924	CL-Cleanup-mailer 	Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)   
C01753 00329	∂12-Jan-89  0937	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 5)   
C01755 00330	∂12-Jan-89  0953	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 6)   
C01758 00331	∂12-Jan-89  1038	CL-Cleanup-mailer 	Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)    
C01762 00332	∂12-Jan-89  1054	CL-Cleanup-mailer 	Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)    
C01764 00333	∂12-Jan-89  1106	CL-Cleanup-mailer 	Re: Issue: PROCLAIM-SPECIAL (Version 9)  
C01766 00334	∂12-Jan-89  1106	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 10)    
C01784 00335	∂12-Jan-89  1124	CL-Cleanup-mailer 	Issue: NTH-VALUE (Version 4)   
C01789 00336	∂12-Jan-89  1143	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 5)
C01796 00337	∂12-Jan-89  1505	CL-Cleanup-mailer 	Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
C01798 00338	∂12-Jan-89  1518	CL-Cleanup-mailer 	Re: Issue: TAGBODY-CONTENTS (Version 5)  
C01800 00339	∂12-Jan-89  1524	CL-Cleanup-mailer 	Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)    
C01802 00340	∂12-Jan-89  1536	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME , Version 4
C01808 00341	∂12-Jan-89  1745	CL-Cleanup-mailer 	Issue Status    
C01870 00342	∂12-Jan-89  2036	CL-Cleanup-mailer 	Issue: APPEND-FIASCO (Version 2)    
C01888 00343	∂12-Jan-89  2112	CL-Cleanup-mailer 	Issue: REMF-MULTIPLE (Version 2)    
C01890 00344	∂12-Jan-89  2157	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01893 00345	∂12-Jan-89  2333	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)    
C01896 00346	∂13-Jan-89  0751	CL-Cleanup-mailer 	Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 2)
C01903 00347	∂13-Jan-89  0858	CL-Cleanup-mailer 	Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 2)
C01909 00348	∂13-Jan-89  0935	CL-Cleanup-mailer 	Re: Issue: NTH-VALUE (Version 4)    
C01913 00349	∂13-Jan-89  0958	CL-Cleanup-mailer 	Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE , Version 3 
C01918 00350	∂13-Jan-89  1022	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01920 00351	∂13-Jan-89  1022	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01922 00352	∂13-Jan-89  1039	CL-Cleanup-mailer 	Re: Issue: REMF-MULTIPLE (Version 2)
C01924 00353	∂13-Jan-89  1039	CL-Cleanup-mailer 	Re: Issue: APPEND-FIASCO (Version 2)
C01926 00354	∂13-Jan-89  1049	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 3)   
C01932 00355	∂13-Jan-89  1052	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 3) 
C01945 00356	∂13-Jan-89  1053	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
C01949 00357	∂13-Jan-89  1109	CL-Cleanup-mailer 	Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES (Version 3)     
C01957 00358	∂13-Jan-89  1126	CL-Cleanup-mailer 	Re: Issue: NTH-VALUE (Version 4)    
C01960 00359	∂13-Jan-89  1129	CL-Cleanup-mailer 	Re: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME , Version 4 
C01963 00360	∂13-Jan-89  1320	CL-Cleanup-mailer 	Re: Issue: NTH-VALUE (Version 4)    
C01966 00361	∂13-Jan-89  1448	CL-Cleanup-mailer 	Ballot
C01979 00362	∂13-Jan-89  1454	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 2)
C01999 00363	∂13-Jan-89  1602	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 2)
C02002 00364	∂13-Jan-89  1631	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 6)   
C02007 00365	∂13-Jan-89  1903	CL-Editorial-mailer 	Code as Spec: {Issue: THE-AMBIGUITY (Version 2)} 
C02012 00366	∂13-Jan-89  1913	CL-Cleanup-mailer 	Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)    
C02014 00367	∂13-Jan-89  2000	CL-Cleanup-mailer 	Issue: CLOSE-CONSTRUCTED-STREAM (Version 2)   
C02016 00368	∂13-Jan-89  2058	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 2)
C02024 00369	∂14-Jan-89  0336	CL-Cleanup-mailer 	Issue DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE, v3   
C02026 00370	∂15-Jan-89  0547	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)    
C02029 00371	∂15-Jan-89  0557	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 3)   
C02033 00372	∂15-Jan-89  0617	CL-Cleanup-mailer 	Issue: NTH-VALUE (Version 4)   
C02036 00373	∂18-Jan-89  1123	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS (Version 1)    
C02051 00374	∂20-Jan-89  1453	CL-Cleanup-mailer 	issue PROCLAIM-LEXICAL    
C02055 00375	∂20-Jan-89  1501	CL-Cleanup-mailer 	issue IN-PACKAGE-FUNCTIONALITY, version 5
C02069 00376	∂23-Jan-89  0238	CL-Cleanup-mailer 	issue IN-PACKAGE-FUNCTIONALITY, version 5
C02071 00377	∂23-Jan-89  0820	CL-Cleanup-mailer 	Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
C02074 00378	∂23-Jan-89  1032	CL-Cleanup-mailer 	issue PROCLAIM-LEXICAL    
C02080 00379	∂23-Jan-89  1532	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL
C02082 00380	∂23-Jan-89  1640	CL-Cleanup-mailer 	[Robert S. Boyer <boyer@CLI.COM>: Backquote Documentation    
C02086 00381	∂23-Jan-89  2027	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL
C02090 00382	∂23-Jan-89  2148	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL
C02094 00383	∂24-Jan-89  0327	CL-Cleanup-mailer 	issue IN-PACKAGE-FUNCTIONALITY, version 5
C02100 00384	∂24-Jan-89  1043	CL-Cleanup-mailer 	Re: issue IN-PACKAGE-FUNCTIONALITY, version 5 
C02107 00385	∂24-Jan-89  1433	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND (Version 1)    
C02116 00386	∂24-Jan-89  1527	CL-Cleanup-mailer 	Re: Issue: DESTRUCTURING-BIND (Version 1)
C02119 00387	∂24-Jan-89  1722	CL-Cleanup-mailer 	Re: Issue: DESTRUCTURING-BIND (Version 1)
C02122 00388	∂24-Jan-89  1917	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND (Version 1)    
C02124 00389	∂25-Jan-89  0251	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND (Version 1)    
C02127 00390	∂25-Jan-89  0523	CL-Cleanup-mailer 	issue IN-PACKAGE-FUNCTIONALITY, version 5
C02131 00391	∂25-Jan-89  0840	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND (Version 2)    
C02146 00392	∂25-Jan-89  1018	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND (Version 1)    
C02148 00393	∂25-Jan-89  1111	CL-Cleanup-mailer 	Re: Issue: DESTRUCTURING-BIND (Version 1)
C02151 00394	∂25-Jan-89  1111	CL-Cleanup-mailer 	Re: Issue: DESTRUCTURING-BIND (Version 1)
C02153 00395	∂25-Jan-89  1604	CL-Cleanup-mailer 	Issue status-- not 'till next week  
C02155 00396	∂25-Jan-89  1711	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL
C02159 00397	∂26-Jan-89  1215	CL-Cleanup-mailer 	Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION (Version 1)  
C02171 00398	∂27-Jan-89  0326	CL-Cleanup-mailer 	issue PROCLAIM-LEXICAL    
C02174 00399	∂27-Jan-89  1755	CL-Cleanup-mailer 	issue PROCLAIM-LEXICAL    
C02186 00400	∂27-Jan-89  1803	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND (Version 2)    
C02189 00401	∂27-Jan-89  1805	CL-Cleanup-mailer 	Issue: LISP-PACKAGE-NAME, (Version 1)    
C02192 00402	∂27-Jan-89  1824	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND (Version 2)    
C02194 00403	∂27-Jan-89  1844	CL-Cleanup-mailer 	issue IN-PACKAGE-FUNCTIONALITY, version 5
C02200 00404	∂27-Jan-89  1950	CL-Cleanup-mailer 	Issue: FUNCTION-NAME (Version 1)    
C02225 00405	∂28-Jan-89  1011	CL-Cleanup-mailer 	Re: issue IN-PACKAGE-FUNCTIONALITY, version 5 
C02230 00406	∂29-Jan-89  1325	Common-Lisp-Object-System-mailer 	Re: Issue: FUNCTION-NAME (Version 1)
C02233 00407	∂29-Jan-89  1428	CL-Cleanup-mailer 	Re: issue IN-PACKAGE-FUNCTIONALITY, version 5 
C02242 00408	∂30-Jan-89  0653	CL-Cleanup-mailer 	Issue: DEFMACRO-LAMBDA-LIST (Version 1)  
C02252 00409	∂30-Jan-89  0704	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND (Version 2)    
C02257 00410	∂30-Jan-89  0720	CL-Cleanup-mailer 	Issue: FUNCTION-NAME (Version 1)    
C02259 00411	∂30-Jan-89  0903	CL-Cleanup-mailer 	Issue: LISP-PACKAGE-NAME, (Version 1)    
C02269 00412	∂30-Jan-89  0910	CL-Cleanup-mailer 	issue IN-PACKAGE-FUNCTIONALITY, version 5
C02272 00413	∂30-Jan-89  0915	CL-Cleanup-mailer 	Re: issue IN-PACKAGE-FUNCTIONALITY, version 5 
C02274 00414	∂30-Jan-89  0917	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS (Version 1)    
C02276 00415	∂30-Jan-89  1003	Common-Lisp-Object-System-mailer 	Issue: FUNCTION-NAME (Version 1)    
C02278 00416	∂30-Jan-89  1458	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6) 
C02281 00417	∂30-Jan-89  1826	CL-Cleanup-mailer 	issue IN-PACKAGE-FUNCTIONALITY, version 6
C02295 00418	∂31-Jan-89  0233	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND (Version 2)    
C02300 00419	∂01-Feb-89  1140	CL-Cleanup-mailer 	Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)    
C02308 00420	∂01-Feb-89  1206	CL-Cleanup-mailer 	Re: Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
C02310 00421	∂01-Feb-89  1208	CL-Cleanup-mailer 	Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)    
C02312 00422	∂01-Feb-89  1224	CL-Cleanup-mailer 	Re: Issue: SETF-OPTIONAL-ARGUMENTS (Version 1)
C02316 00423	∂01-Feb-89  2123	CL-Cleanup-mailer 	New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN  
C02330 00424	∂02-Feb-89  0532	CL-Cleanup-mailer 	issue PROCLAIM-LEXICAL    
C02335 00425	∂02-Feb-89  0807	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL
C02341 00426	∂02-Feb-89  1239	CL-Cleanup-mailer 	Issue: FUNCTION-NAME (Version 1)    
C02353 00427	∂03-Feb-89  0820	CL-Compiler-mailer 	Re: Issue: FUNCTION-NAME (Version 1)    
C02357 00428	∂03-Feb-89  1513	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND (Version 2)    
C02363 00429	∂03-Feb-89  1537	CL-Cleanup-mailer 	New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN  
C02365 00430	∂03-Feb-89  1542	CL-Cleanup-mailer 	Issue: DEFMACRO-LAMBDA-LIST (Version 1)  
C02368 00431	∂03-Feb-89  1557	CL-Cleanup-mailer 	Issue: DEFMACRO-LAMBDA-LIST (Version 1)  
C02370 00432	∂03-Feb-89  1602	CL-Cleanup-mailer 	Re: New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN   
C02372 00433	∂03-Feb-89  2211	CL-Cleanup-mailer 	Issue: APPEND-DOTTED (Version 5)    
C02381 00434	∂03-Feb-89  2218	CL-Cleanup-mailer 	Re: Issue: APPEND-DOTTED (Version 5)
C02383 00435	∂03-Feb-89  2232	CL-Cleanup-mailer 	Issue: CLOS-CONDITIONS (Version 3)  
C02416 00436	∂03-Feb-89  2243	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (Version 6)   
C02426 00437	∂03-Feb-89  2257	CL-Cleanup-mailer 	Re: Issue: CLOSED-STREAM-OPERATIONS (Version 6)    
C02428 00438	∂05-Feb-89  1111	CL-Cleanup-mailer 	Issue: CLOS-CONDITIONS (Version 3)  
C02430 00439	∂05-Feb-89  1519	CL-Cleanup-mailer 	issue PROCLAIM-LEXICAL    
C02434 00440	∂05-Feb-89  1841	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS (Version 1)    
C02438 00441	∂06-Feb-89  0841	CL-Cleanup-mailer 	New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN  
C02441 00442	∂06-Feb-89  0845	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND (Version 2)    
C02444 00443	∂06-Feb-89  0851	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (Version 6)   
C02446 00444	∂06-Feb-89  0902	CL-Cleanup-mailer 	Re: Issue: CLOSED-STREAM-OPERATIONS (Version 6)    
C02449 00445	∂06-Feb-89  0937	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND (Version 2)    
C02452 00446	∂06-Feb-89  1017	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (Version 6)   
C02456 00447	∂06-Feb-89  1150	CL-Cleanup-mailer 	Re: Issue: DESTRUCTURING-BIND (Version 2)     
C02459 00448	∂06-Feb-89  1213	CL-Cleanup-mailer 	Re: Issue: DESTRUCTURING-BIND (Version 2)     
C02464 00449	∂06-Feb-89  1251	CL-Cleanup-mailer 	Issue: DESTRUCTURING-BIND (Version 2)    
C02467 00450	∂06-Feb-89  1302	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL
C02473 00451	∂06-Feb-89  1316	CL-Cleanup-mailer 	issue SYMBOL-MACROLET-SEMANTICS
C02475 00452	∂06-Feb-89  1307	Common-Lisp-Object-System-mailer 	issue SYMBOL-MACROLET-SEMANTICS
C02477 00453	∂06-Feb-89  1354	CL-Cleanup-mailer 	Issue: IGNORE-VARIABLE (Version 1)  
C02487 00454	∂06-Feb-89  1419	CL-Cleanup-mailer 	Re: Issue: DESTRUCTURING-BIND (Version 2)     
C02492 00455	∂06-Feb-89  1638	CL-Cleanup-mailer 	Re: Issue: DESTRUCTURING-BIND (Version 2)     
C02498 00456	∂07-Feb-89  0819	CL-Windows-mailer 	I/O generic functions     
C02512 00457	∂07-Feb-89  1016	Common-Lisp-Object-System-mailer 	Re: I/O generic functions 
C02514 00458	∂07-Feb-89  1033	Common-Lisp-Object-System-mailer 	Re: I/O generic functions 
C02518 00459	∂07-Feb-89  1241	CL-Cleanup-mailer 	New issue ADJUST-ARRAY-NOT-ADJUSTABLE-BROKEN, or Hokey-Pokey-ADJUST-ARRAY   
C02533 00460	∂07-Feb-89  1248	CL-Cleanup-mailer 	issue PROCLAIM-LEXICAL    
C02536 00461	∂07-Feb-89  1252	CL-Cleanup-mailer 	issue PROCLAIM-LEXICAL    
C02538 00462	∂07-Feb-89  1302	CL-Cleanup-mailer 	Issue: SUBTYPEP-EMPTY-NIL (Version 1)    
C02543 00463	∂07-Feb-89  1325	CL-Cleanup-mailer 	Issue: DEFSTRUCT-REDEFINITION (Version 3)
C02552 00464	∂07-Feb-89  2005	CL-Cleanup-mailer 	I/O generic functions     
C02556 00465	∂07-Feb-89  2252	CL-Cleanup-mailer 	Issue: SUBTYPEP-EMPTY-NIL (Version 1)    
C02558 00466	∂08-Feb-89  0639	CL-Cleanup-mailer 	Issue: SUBTYPEP-EMPTY-NIL (Version 1)    
C02562 00467	∂08-Feb-89  0907	CL-Cleanup-mailer 	Re: Issue: IGNORE-VARIABLE (Version 1)   
C02565 00468	∂08-Feb-89  0921	CL-Cleanup-mailer 	Re: Issue: SUBTYPEP-EMPTY-NIL (Version 1)
C02567 00469	∂08-Feb-89  1010	CL-Cleanup-mailer 	Re: Issue: SUBTYPEP-EMPTY-NIL (Version 1)     
C02570 00470	∂08-Feb-89  1107	CL-Cleanup-mailer 	Re: Issue: IGNORE-VARIABLE (Version 1)   
C02577 00471	∂08-Feb-89  1112	CL-Cleanup-mailer 	Issue: SUBTYPEP-EMPTY-NIL (Version 1)    
C02579 00472	∂08-Feb-89  1230	CL-Cleanup-mailer 	Issue: SUBTYPEP-EMPTY-NIL (Version 1)    
C02583 00473	∂08-Feb-89  1251	CL-Cleanup-mailer 	Re: Issue: IGNORE-VARIABLE (Version 1)   
C02587 00474	∂08-Feb-89  1428	CL-Cleanup-mailer 	Re: Issue: IGNORE-VARIABLE (Version 1)   
C02592 00475	∂08-Feb-89  1704	CL-Cleanup-mailer 	Re: I/O generic functions 
C02598 00476	∂08-Feb-89  2017	CL-Cleanup-mailer 	Issue: SUBTYPEP-EMPTY-NIL (Version 1)    
C02601 00477	∂09-Feb-89  0656	CL-Cleanup-mailer 	Issue: CLOS-CONDITIONS (Version 3)  
C02604 00478	∂10-Feb-89  1325	CL-Cleanup-mailer 	re: PATHNAME-PRINT-READ, v1    
C02608 00479	∂10-Feb-89  2353	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 5)  
C02613 00480	∂11-Feb-89  0023	CL-Cleanup-mailer 	Issue: FUNCTION-DEFINITION (Version 3)   
C02622 00481	∂13-Feb-89  1250	CL-Cleanup-mailer 	Re: issue PROCLAIM-LEXICAL
C02627 00482	∂14-Feb-89  1213	CL-Cleanup-mailer 	Issue: GENSYM-NAME-STICKINESS (Version 1)
C02633 00483	∂14-Feb-89  1328	CL-Cleanup-mailer 	Re: Issue: GENSYM-NAME-STICKINESS (Version 1) 
C02636 00484	∂14-Feb-89  1615	CL-Cleanup-mailer 	Re: Issue: CLOS-CONDITIONS (Version 3)   
C02638 00485	∂14-Feb-89  1615	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C02655 00486	∂14-Feb-89  1636	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (Version 7)   
C02666 00487	∂14-Feb-89  1658	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 2) 
C02668 00488	∂15-Feb-89  0646	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C02673 00489	∂15-Feb-89  0706	CL-Cleanup-mailer 	Issue: CLOSED-STREAM-OPERATIONS (Version 7)   
C02678 00490	∂15-Feb-89  0737	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 2) 
C02681 00491	∂15-Feb-89  0817	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C02683 00492	∂15-Feb-89  0835	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6) 
C02685 00493	∂15-Feb-89  1000	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6) 
C02689 00494	∂15-Feb-89  1124	CL-Cleanup-mailer 	[Moon@STONY-BROOK.SCRC.Symbolics.COM: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)] 
C02705 00495	∂15-Feb-89  1126	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6) 
C02708 00496	∂15-Feb-89  1206	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS (Version 1)    
C02714 00497	∂15-Feb-89  1244	CL-Cleanup-mailer 	Issue: READ-CASE-SENSITIVITY (Version 1) 
C02727 00498	∂15-Feb-89  1331	CL-Cleanup-mailer 	Issue: READ-CASE-SENSITIVITY (Version 1) 
C02740 00499	∂15-Feb-89  1435	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C02744 00500	∂15-Feb-89  1509	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C02750 00501	∂16-Feb-89  0758	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C02757 00502	∂16-Feb-89  0857	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C02767 00503	∂16-Feb-89  1104	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C02781 00504	∂16-Feb-89  1215	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C02788 00505	∂16-Feb-89  1241	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C02791 00506	∂17-Feb-89  0004	CL-Cleanup-mailer 	Cleanup Issue Status 
C02837 00507	∂17-Feb-89  1031	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C02844 00508	∂17-Feb-89  1049	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C02848 00509	∂20-Feb-89  0944	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C02852 00510	∂21-Feb-89  1501	CL-Cleanup-mailer 	Issue IGNORE-VARIABLE, v1 
C02854 00511	∂21-Feb-89  1501	Common-Lisp-Object-System-mailer 	Issue CONSTANT-COMPILABLE-TYPES
C02862 00512	∂22-Feb-89  1037	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C02866 00513	∂22-Feb-89  1117	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C02870 00514	∂23-Feb-89  1412	CL-Cleanup-mailer 	Potential issue: MACRO-SPECIAL-FORMS
C02876 00515	∂23-Feb-89  1446	CL-Compiler-mailer 	Potential issue: MACRO-SPECIAL-FORMS    
C02882 00516	∂23-Feb-89  1502	CL-Cleanup-mailer 	Re: Potential issue: MACRO-SPECIAL-FORMS 
C02886 00517	∂23-Feb-89  1525	CL-Compiler-mailer 	Re: Potential issue: MACRO-SPECIAL-FORMS
C02891 00518	∂24-Feb-89  0157	Common-Lisp-Object-System-mailer 	Issue CONSTANT-COMPILABLE-TYPES
C02895 00519	∂24-Feb-89  1446	CL-Cleanup-mailer 	PRETTY-PRINT-INTERFACE    
C02952 00520	∂27-Feb-89  0938	CL-Cleanup-mailer 	Re: Potential issue: MACRO-SPECIAL-FORMS 
C02959 00521	∂27-Feb-89  1337	CL-Cleanup-mailer 	[Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization:  two proposals]   
C02963 00522	∂27-Feb-89  1433	CL-Cleanup-mailer 	Re: PRETTY-PRINT-INTERFACE     
C02967 00523	∂27-Feb-89  1506	CL-Cleanup-mailer 	[Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization:  two proposals]   
C02969 00524	∂27-Feb-89  1639	CL-Cleanup-mailer 	Issue: EXPT-ZERO-ZERO (Version 1)   
C02975 00525	∂27-Feb-89  1658	CL-Cleanup-mailer 	Re: Issue: EXPT-ZERO-ZERO (Version 1)    
C02978 00526	∂28-Feb-89  0240	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C02986 00527	∂28-Feb-89  0949	CL-Cleanup-mailer 	Issue: EXPT-ZERO-ZERO (Version 1)   
C02989 00528	∂28-Feb-89  1148	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C03002 00529	∂28-Feb-89  1402	CL-Cleanup-mailer 	Issue EQUALP-GENERIC 
C03016 00530	∂28-Feb-89  1508	CL-Cleanup-mailer 	Issue EQUALP-GENERIC 
C03020 00531	∂28-Feb-89  1758	CL-Cleanup-mailer 	Issue PRETTY-PRINT-INTERFACE   
C03022 00532	∂01-Mar-89  2009	CL-Cleanup-mailer 	Re: Issue EQUALP-GENERIC  
C03026 00533	∂01-Mar-89  2029	CL-Cleanup-mailer 	Issue EQUAL-STRUCTURE
C03030 00534	∂01-Mar-89  2055	CL-Cleanup-mailer 	Issue EQUAL-STRUCTURE
C03033 00535	∂04-Mar-89  1123	CL-Cleanup-mailer 	MERGE-PATHNAMES-DIRECTORY:EXTEND    
C03045 00536	∂04-Mar-89  1740	CL-Cleanup-mailer 	Issue EQUALP-GENERIC 
C03048 00537	∂04-Mar-89  1741	CL-Cleanup-mailer 	Issue EQUAL-STRUCTURE
C03051 00538	∂06-Mar-89  1007	CL-Cleanup-mailer 	Re: Issue EQUAL-STRUCTURE 
C03055 00539	∂06-Mar-89  1445	CL-Cleanup-mailer 	Issue: OPTIMIZE-SAFETY (Version 1)  
C03061 00540	∂06-Mar-89  1717	CL-Cleanup-mailer 	[Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization:  two proposals]   
C03063 00541	∂06-Mar-89  1831	CL-Cleanup-mailer 	Re: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]     
C03068 00542	∂06-Mar-89  1911	CL-Cleanup-mailer 	Re: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]     
C03072 00543	∂06-Mar-89  1921	CL-Cleanup-mailer 	Re: [Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]     
C03076 00544	∂06-Mar-89  2031	CL-Cleanup-mailer 	Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER (Version 1)    
C03108 00545	∂06-Mar-89  2053	CL-Cleanup-mailer 	Issue: FORMAT-PLURALS [was "pluralization:  two proposals"]  
C03110 00546	∂07-Mar-89  1047	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C03116 00547	∂07-Mar-89  1054	CL-Cleanup-mailer 	[Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization:  two proposals]   
C03120 00548	∂07-Mar-89  1135	CL-Cleanup-mailer 	[Dave.Touretzky@B.GP.CS.CMU.EDU: pluralization: two proposals]    
C03124 00549	∂07-Mar-89  1443	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE (Version 3)
C03135 00550	∂07-Mar-89  1504	CL-Cleanup-mailer 	MERGE-PATHNAMES-DIRECTORY:EXTEND    
C03137 00551	∂07-Mar-89  1637	CL-Cleanup-mailer 	Issue: OPTIMIZE-SAFETY (Version 1)  
C03145 00552	∂07-Mar-89  1643	CL-Cleanup-mailer 	Issue: BREAK-ON-WARNINGS-OBSOLETE   
C03149 00553	∂07-Mar-89  1722	CL-Cleanup-mailer 	Issue EQUALP-GENERIC 
C03166 00554	∂07-Mar-89  1825	CL-Compiler-mailer 	Re: Potential issue: MACRO-SPECIAL-FORMS
C03171 00555	∂07-Mar-89  2346	CL-Cleanup-mailer 	MERGE-PATHNAMES-DIRECTORY:EXTEND    
C03174 00556	∂08-Mar-89  0524	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-PRINT-NAME  
C03177 00557	∂08-Mar-89  0806	CL-Cleanup-mailer 	Re: Potential issue: MACRO-SPECIAL-FORMS 
C03179 00558	∂08-Mar-89  0820	CL-Cleanup-mailer 	Re: Issue: COPY-SYMBOL-PRINT-NAME   
C03181 00559	∂08-Mar-89  0930	CL-Cleanup-mailer 	Issue: MERGE-PATHNAMES-DIRECTORY    
C03183 00560	∂08-Mar-89  0939	CL-Cleanup-mailer 	Re: Issue: COPY-SYMBOL-PRINT-NAME   
C03185 00561	∂08-Mar-89  0948	CL-Cleanup-mailer 	Re: Issue: COPY-SYMBOL-PRINT-NAME   
C03188 00562	∂08-Mar-89  0951	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-PRINT-NAME  
C03190 00563	∂08-Mar-89  0952	CL-Cleanup-mailer 	Re: Issue: COPY-SYMBOL-PRINT-NAME   
C03193 00564	∂08-Mar-89  1117	CL-Cleanup-mailer 	Issue: PLUS-ABNORMAL 
C03199 00565	∂08-Mar-89  1437	CL-Cleanup-mailer 	case sensitive readers    
C03205 00566	∂08-Mar-89  1628	CL-Cleanup-mailer 	Re: Issue: COPY-SYMBOL-PRINT-NAME   
C03207 00567	∂09-Mar-89  1109	CL-Cleanup-mailer 	Issue: CLOS-CONDITIONS (Version 3)  
C03209 00568	∂09-Mar-89  1120	CL-Cleanup-mailer 	Re: case sensitive readers
C03213 00569	∂09-Mar-89  1128	CL-Cleanup-mailer 	Re: Issue: CLOS-CONDITIONS (Version 3)   
C03217 00570	∂09-Mar-89  1128	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS (Version 1)    
C03225 00571	∂09-Mar-89  1135	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE (Version 3)
C03227 00572	∂09-Mar-89  1228	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7)
C03234 00573	∂09-Mar-89  1313	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7)
C03236 00574	∂09-Mar-89  1325	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 2)
C03240 00575	∂09-Mar-89  1329	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 3)
C03263 00576	∂09-Mar-89  1334	CL-Cleanup-mailer 	issue IN-PACKAGE-FUNCTIONALITY, version 6
C03265 00577	∂09-Mar-89  1522	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS (Version 1)    
C03269 00578	∂09-Mar-89  1527	CL-Cleanup-mailer 	Issue: CLOS-CONDITIONS (Version 3)  
C03273 00579	∂09-Mar-89  1541	CL-Cleanup-mailer 	issue IN-PACKAGE-FUNCTIONALITY, version 6
C03275 00580	∂09-Mar-89  1539	CL-Compiler-mailer 	Issue: LOCALLY-TOP-LEVEL (Version 1)    
C03283 00581	∂09-Mar-89  1635	CL-Cleanup-mailer 	Re: Issue: READ-CASE-SENSITIVITY (Version 1)  
C03286 00582	∂09-Mar-89  1920	CL-Cleanup-mailer 	Re: Potential issue: MACRO-SPECIAL-FORMS 
C03288 00583	∂09-Mar-89  2244	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE (Version 3)
C03290 00584	∂09-Mar-89  2314	CL-Cleanup-mailer 	Issue EQUALP-GENERIC 
C03303 00585	∂10-Mar-89  0916	CL-Cleanup-mailer 	issue IN-PACKAGE-FUNCTIONALITY, version 7
C03313 00586	∂10-Mar-89  1000	CL-Cleanup-mailer 	issue IN-PACKAGE-FUNCTIONALITY, version 7
C03315 00587	∂10-Mar-89  1109	CL-Cleanup-mailer 	Issue: CLOS-CONDITIONS (Version 4)  
C03327 00588	∂10-Mar-89  1211	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 7)
C03329 00589	∂10-Mar-89  1443	CL-Cleanup-mailer 	Issue PEEK-CHAR-READ-CHAR-ECHO 
C03333 00590	∂10-Mar-89  1444	CL-Cleanup-mailer 	Issue STREAM-ACCESS  
C03335 00591	∂10-Mar-89  1445	CL-Cleanup-mailer 	Issue SUBTYPEP-TOO-VAGUE  
C03337 00592	∂10-Mar-89  1446	CL-Cleanup-mailer 	Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER, v1   
C03341 00593	∂10-Mar-89  1452	CL-Cleanup-mailer 	(new) Issue DESCRIBE-UNDERSPECIFIED 
C03352 00594	∂10-Mar-89  1511	CL-Cleanup-mailer 	Issue PEEK-CHAR-READ-CHAR-ECHO 
C03357 00595	∂10-Mar-89  1527	CL-Cleanup-mailer   
C03363 00596	∂10-Mar-89  1529	CL-Cleanup-mailer 	Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER, v1   
C03369 00597	∂10-Mar-89  1553	CL-Cleanup-mailer 	(reply to message)   
C03370 00598	∂10-Mar-89  1553	CL-Cleanup-mailer 	Re: issue IN-PACKAGE-FUNCTIONALITY, version 7 
C03372 00599	∂10-Mar-89  1723	CL-Cleanup-mailer 	Re: Issue: CLOS-CONDITIONS (Version 4)   
C03374 00600	∂11-Mar-89  0125	CL-Cleanup-mailer 	Re: Issue SUBTYPEP-TOO-VAGUE   
C03377 00601	∂11-Mar-89  1452	CL-Cleanup-mailer 	amendments to already passed issues 
C03382 00602	∂11-Mar-89  1658	Common-Lisp-Object-System-mailer 	Issue: LOAD-OBJECTS (Version 3)
C03390 00603	∂11-Mar-89  1745	Common-Lisp-Object-System-mailer 	Re: Issue: LOAD-OBJECTS (Version 3) 
C03393 00604	∂11-Mar-89  1938	CL-Cleanup-mailer 	Issue: CONDITION-RESTARTS (Version 1)    
C03399 00605	∂12-Mar-89  1032	Common-Lisp-Object-System-mailer 	Issue: LOAD-OBJECTS (Version 3)
C03401 00606	∂13-Mar-89  0940	CL-Cleanup-mailer 	Issue: CLOS-CONDITIONS (Version 4)  
C03406 00607	∂13-Mar-89  0946	CL-Cleanup-mailer 	Issue: TIME-ZONE-NON-INTEGER   
C03409 00608	∂13-Mar-89  1009	CL-Cleanup-mailer 	Issue: CLOS-CONDITIONS (Version 4)  
C03413 ENDMK
C⊗;
∂11-Dec-88  1051	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Dec 88  10:51:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 DEC 88 10:45:21 PST
Date: Sun, 11 Dec 88 10:45 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5) 
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, pierson@mist.encore.com, Gray@DSG.csc.ti.com,
 cl-cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <8812100131.AA07286@bhopal>
Message-ID: <19881211184511.8.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

    Date: Fri, 9 Dec 88 17:31:12 PST
    From: Jon L White <jonl@lucid.com>

    Larry, I would very much like to see a second alternative in this
    proposal.  I think the idea of a "safety-net" version of REQUIRE is
    fully portable, and backwards compatible with those implementations 
    that hook into their own "defsystem".  All the arguments against it, 
    that have been sent out in discussion so far, are simply confusing the 
    issue of REQUIRE portability with that of DEFSYSTEM portability.  If 
    someone uses implementation A's DEFSYSTEM, his code won't be portable 
    to implementation B (unless B has cloned A's DEFSYSTEM).  There is just 
    no reason to indict REQUIRE of cuplability here.

    My "compromise" proposal, that Gray seemed to agree to, was to insist
    that implementations which "hook" their REQUIRE into some  kind of 
    DEFSYSTEM -- as an implementation- specific extension -- must also 
    provide a special variable flag that disengages any such "hook-up".  
    While it is true that many people will persist in writing non-portable 
    code, the portable use of REQUIRE to ensure that required package 
    definitions are "already loaded in" is of paramount importance.  There is 
    no other portable feature to help ensure that.

I don't buy this.  You can do it portably with find-package and intern.
You might claim that is gross, but I don't believe it.  The point is
that REQUIRE "suggests" more than it can possibly do.  It need to know
that the sub-system I depend on really is completely loaded, up and
running.  Any program that is "portably" going to require the existence
of other programs takes work,  it takes some sort of defsystem facility.
REQUIRE can't possibly provide that, all it can do is confuse people
into thinking that they might be getting it.

    If you and Dan are amenable, I'd write the additional part -- from 
    previous mails, it should only take 10 or 20 minutes at most.  Either
    of you could probably write it too.


    -- JonL --


-------

∂11-Dec-88  1549	CL-Cleanup-mailer 	Issue PACKAGE-CLUTTER (Version 5)   
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 11 Dec 88  15:49:17 PST
Date: Sun 11 Dec 88 14:56:27-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue PACKAGE-CLUTTER (Version 5)
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12453663438.21.IIM@ECLA.USC.EDU>

Paragraph 2 of the Proposal section says:

    " ... FBOUNDP will be false for all external symbols of the LISP package
    except those documented to be functions or macros; ... "

What about special-forms?  From CLtL, page 90-91, the definition of FBOUNDP
says: 

    "Note that FBOUNDP is true when the symbol names a special form or macro."

kab
-------

∂12-Dec-88  0929	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3) 
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 12 Dec 88  09:29:22 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA00368; Mon, 12 Dec 88 12:28:03 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA10750; Mon, 12 Dec 88 11:34:43 EST
Message-Id: <8812121634.AA10750@mist.>
To: Jon L White <jonl@lucid.com>
Cc: IIM@ECLA.USC.EDU, cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3) 
In-Reply-To: Your message of Fri, 09 Dec 88 23:37:12 -0800.
             <8812100737.AA07690@bhopal> 
Date: Mon, 12 Dec 88 11:34:39 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    I thought I made my opposition clear enough -- that the Symbolics "status 
    quo" is not the status quo for the community at large; their "extension" 
    is not one that is fully compatible with (the obvious reading of) CLtL.
    In particular, the part that of the proposal that suggests that 
            (make-arry n :adjustable nil)
    can legitimately return an adjustable array flies in the face of the
    very reason reason why the type SIMPLE-ARRAY was introduced into Common
    Lisp in the first place!  Listen very carefully to those implementing
    Lisp on stock hardware -- ask if they think it is perfectly fine to
    **** have no way whatsoever *** to guarantee getting a
    non-adjustable array. 
    
While I agree with you here, I would like to point out that the
position you are taking here strikes me as being the opposite of your
position on REQUIRE-PATHNAME-DEFAULTS.  In both cases, the status quo
allows careful programmers to write portable code as in:

    - Never adjust a "non-adjustable" array
    - Never use REQUIRE in a context that would cause file loading

The, quite legitimate, objection to the status quo is that it makes it
_very_ likely that programmers, being human and fallible, will
accidently wind up producing non-portable code because the current
versions of these features lack adaquate (read any) portable error
checking. 

∂12-Dec-88  0930	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 12 Dec 88  09:29:50 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA00392; Mon, 12 Dec 88 12:28:35 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA10740; Mon, 12 Dec 88 11:25:39 EST
Message-Id: <8812121625.AA10740@mist.>
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5) 
In-Reply-To: Your message of Fri, 09 Dec 88 17:34:40 -0800.
             <8812100134.AA07293@bhopal> 
Date: Mon, 12 Dec 88 11:25:37 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    You meant DEFSYS, of course.  Proof in point that it is DEFSYSTEM, not
    REQUIRE, that is currently not in a portable state.
    
Of course.

I disagree in that I think both are currently not in a portable state.

In case any of this argument has given people the wrong impression, I
would strongly support almost any reasonable proposal for adding a
portable DEFSYSTEM to the standard.  (I haven't put one forward
because it seems that it would have no chance).  The history of Unix
for the last decade or so is a perfect demonstration of the tremendous
advantages of such a facility even if the facility itself is far short
of perfection.  

While simple, standard DEFSYSTEM would be a great aid to portable CL
software distribution, it needn't compete with implementors superior
proprietary system definition packages at all.  Since the prime goals
of a standard DEFSYSTEM would be portability, simplicity, and minimum
necessary functionality, it should be simple to enhance any of the
proprietary packages to cons up a portable DEFSYSTEM file when the
time came to distribute the software.


∂12-Dec-88  0929	CL-Cleanup-mailer 	Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 12 Dec 88  09:29:31 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA00380; Mon, 12 Dec 88 12:28:24 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA10731; Mon, 12 Dec 88 11:17:09 EST
Message-Id: <8812121617.AA10731@mist.>
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5) 
In-Reply-To: Your message of Fri, 09 Dec 88 17:31:12 -0800.
             <8812100131.AA07286@bhopal> 
Date: Mon, 12 Dec 88 11:17:06 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    If you and Dan are amenable, I'd write the additional part -- from 
    previous mails, it should only take 10 or 20 minutes at most.  Either
    of you could probably write it too.
    
Well, I still disagree with the substance and will almost certainly
vote against such an alternative (see Gregor's reply to your message
for my reasoning).  The only thing that might change my vote would be:

    1. Standardizing the control variable, and
    2. Making its default value be no loading or DEFSYS interaction.

This would force all of Grey, etc.'s users to explictly enable the
non-portable feature if they wanted it.  I suspect that Coral, at
least, would oppose this because they evidently document REQUIRE as
the way to enable (load) proprietary extensions such as Macintosh
graphics support.

One the other hand, I'm getting the feeling that a substatial part of
cleanup disagrees with me.  Given that, and the amount of time we've
spent discussing this, I think that it is quite approptiate for you to
add a second alternative to the proposal, give it a couple of days for
cleanup comments, and send the combination to x3j13 for voting.

∂12-Dec-88  0929	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 2) 
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 12 Dec 88  09:29:26 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA00376; Mon, 12 Dec 88 12:28:20 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA10721; Mon, 12 Dec 88 11:08:16 EST
Message-Id: <8812121608.AA10721@mist.>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: COERCE-INCOMPLETE (Version 2) 
In-Reply-To: Your message of 09 Dec 88 16:47:00 -0800.
             <881209-164733-1437@Xerox> 
Date: Mon, 12 Dec 88 11:08:13 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    I see we have some choices:
    
    a) remove COERCE
    b) leave COERCE alone
    c) extend COERCE slightly
    d) extend COERCE a lot
    
    I think (b) or (c) are the best. I'll try to say why:
    
    ...

    So why don't we just define:
    (coerce x 'string) == (string x)
    (coerce x 'character) == (character x)
    (coerce x 'pathname) = (pathname x)
    (coerce x 'float) = (float x),
    
I agree.

In addition I think that COERCE is a dandy candidate for a generic
function, but it's my understanding that nominations for that status
haven't been opened yet.

∂12-Dec-88  0949	CL-Cleanup-mailer 	Issue: DEFSTRUCT-REDEFINITION (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88  09:49:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 09:45:21 PST
Date: 12 Dec 88 09:44 PST
From: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-REDEFINITION (version 1)
To: cl-cleanup@sail.stanford.edu
Message-ID: <881212-094521-4222@Xerox>

Perhaps we can bring a new version of this issue with us for distribution
at the January meeting.

I think the problem is that defstruct accessors are often compiled with
"knowledge" of the structure, in a way that defclass accessors are not. I
think of "defstruct" as "the most efficient defclass", i.e., I'd like to
leave maximum room for optimization. However, error-if-redefined seems a
bit too strong, e.g., if all I do is change the initial value, it doesn't
old compiled accessors or even old instances.

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

Date: Wed, 7 Dec 88 19:56 PST
From: Gregor.pa
Subject: Re: [masinter.pa: [cl-cleanup@sail.stanford.edu: DRAFT Issue:
DEFSTRUCT-REDEFINITION (Version 1)]]
To: masinter.pa
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: The message of 7 Dec 88 15:40 PST from masinter.pa
Message-ID: <19881208035629.7.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no

Sorry, but I just don't have the time to write this up just now.  I am
barely managing to do what I have to do.  Chapter 3 can support either
of the proposals.  As I have written it now, I believe it specifies
error-if-redefined.

The only point about the relation to chapter 3 is that chapter 3 gives a
technical language for defining it.  There are really three options:

error-if-redefined

error-iff-instances-exist

error-iff-used

In CLOS terminology these are:

(defmethod reinitialize-instance ((c structure-class) &rest ignore)
  (error "..."))

or

(defmethod reinitialize-instance ((c structure-class) &rest ignore)
  (when (class-finalized-p c)
    (error "...")))

or

"The results are undefined if an instance with metaclass structure-class
is accessed after the generic function make-instances-obsolete has been
called with that class as an argument."
-------


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

∂12-Dec-88  1025	CL-Cleanup-mailer 	Re: discussion of Moon's comments re: ELIMINATE-FORCED-CONSING    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88  10:25:20 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 10:10:42 PST
Date: 12 Dec 88 10:08 PST
From: masinter.pa@Xerox.COM
Subject: Re: discussion of Moon's comments re: ELIMINATE-FORCED-CONSING
In-reply-to: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU's message of Tue, 6 Sep
 88 15:38:22 PDT
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881212-101042-4317@Xerox>

Joe:

On 6 Sept 88 you said, in response to a critique from Moon. "I'll submit a
modified proposal for discussion."

There were some subsequent comments on the cl-cleanup mailing list, and
we've not heard back from you. The January 1989 meeting is fast
approaching; we don't have a new writeup on this issue to mail out in
advance; if we don't hear from you, we will not have a new version to bring
there either.

Please reply if you get this note (to cl-cleanup@sail.stanford.edu), about
your plans with respect to this issue.


∂12-Dec-88  1143	CL-Cleanup-mailer 	RE: Issue: HASH-TABLE-ACCESS (version 2) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88  11:43:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 11:31:45 PST
Date: 12 Dec 88 11:31 PST
From: masinter.pa@Xerox.COM
Subject: RE: Issue: HASH-TABLE-ACCESS (version 2)
In-reply-to: masinter.pa's message of 14 Nov 88 14:57 PST
To: vanroggen%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
Message-ID: <881212-113145-4632@Xerox>

I've not heard from Walter in weeks; I presume he is somehow unavailable.
I don't have a new version of this issue and I'm reluctant to mail out
Version 2 given comments from Sandra, GZ and JonL.

I hope we can have a new version to bring with us.


∂12-Dec-88  1212	CL-Cleanup-mailer 	Re: Issue: HASH-TABLE-KEY-MODIFICATION (and HASH-TABLE-STABILITY) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88  12:12:08 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 DEC 88 11:51:07 PST
Date: 12 Dec 88 11:50 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-KEY-MODIFICATION (and HASH-TABLE-STABILITY)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Sat, 10 Dec 88
 05:36:37 PST
To: cl-cleanup@sail.stanford.edu
Message-ID: <881212-115107-4697@Xerox>

If it is true that this issue "has already received extensive positive
review within Lucid; and has received some very positive review outside", I
have not seen those reviews. 

I did see a piece of a message from Jeff Dalton included in your response
to him, but I'm missing his original message. I presume that they were not
mailed to cl-cleanup.

The only review I have is Moon's, which is fairly critical.

Against my judgement, I will release this version.



∂12-Dec-88  1444	CL-Cleanup-mailer 	Issue: FUNCTION-COMPOSITION (Version 4)  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88  14:34:17 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Mon, 12 Dec 88 16:45:18 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Mon, 12 Dec 88 17:30:37 EST
Date: Mon, 12 Dec 88 17:30 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: FUNCTION-COMPOSITION (Version 4)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881212-111746-4560@Xerox>
Message-Id: <19881212223051.0.BARMAR@OCCAM.THINK.COM>

    Date: 12 Dec 88 11:04 PST
    From: cl-cleanup@sail.stanford.edu


    !
    Forum:          Cleanup
    Issue:          FUNCTION-COMPOSITION
    References:     None
    Category:       ADDITION
    Edit history:   21-Jun-88, Version 1 by Pitman
		    05-Oct-88, Version 2 by Pitman
		     7-Dec-88, Version 3 by Masinter
		    12-Dec-88, Version 4 by Masinter (additional comments)
    Related-Issues: TEST-NOT-IF-NOT

    Problem Description:

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

    Proposal (FUNCTION-COMPOSITION:NEW-FUNCTIONS):

      Add the following functions:

       COMPOSE &REST functions				[Function]

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

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

This example implementation is not consistent with the description.  The
description doesn't say that at least one function is required.  I think
that (COMPOSE) should return #'IDENTITY, which is the identity of the
COMPOSE function.

Stylistic note: Both instances of "NOT" in the above function definition
should be "NULL", since they are testing for a list being empty, not a
boolean being false.

                                                barmar

∂12-Dec-88  1448	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 5)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Dec 88  14:48:25 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 507438; Mon 12-Dec-88 17:47:27 EST
Date: Mon, 12 Dec 88 17:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 5)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <881208-182529-5127@Xerox>
Message-ID: <881212174714.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

    ....
      A valid implimentation may have or put additional properties
      on symbols (even user created symbols) as long as the
      property indicators are not in the LISP, KEYWORD or USER
      package.
    ....

The wording should be stronger. I think it should say that it will not
use any property names which are on any user-created packages (except by
inheritance). In other words, it should say that the only permissible
packages of symbols which may be used by the system for properties are
those which are initially allocated by the system for its own use (or
allocated later under some known contract between the system and user if
any implementations ever do this).

Also, SETF of GET, GETF(?), and SYMBOL-PLIST need to be explicitly excepted
for the obvious reason that they are requests by the user for the system
to violate the rules we're describing above.

∂12-Dec-88  1527	CL-Cleanup-mailer 	Re: Issue: SYMBOL-MACROFLET (Version 1)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Dec 88  15:27:43 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 DEC 88 15:10:04 PST
Date: 12 Dec 88 15:09 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SYMBOL-MACROFLET (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Fri, 30 Sep 88 18:47 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881212-151004-5356@Xerox>

Somehow I missed this issue on my first two passes. I think it needs a new
version to reflect the comments (from EB, Moon).

I hope I don't have *too* many copies to cart to Hawaii.


∂12-Dec-88  1546	CL-Cleanup-mailer 	REST-LIST-ALLOCATION (Version 3)    
Received: from mist.math.uoregon.edu by SAIL.Stanford.EDU with TCP; 12 Dec 88  15:45:17 PST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Mon, 12 Dec 88 15:43:08 PDT
Received: by fog.cs.uoregon.edu; Mon, 12 Dec 88 15:42:59 PDT
Date: Mon, 12 Dec 88 15:42:59 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8812122342.AA05921@fog.cs.uoregon.edu>
To: cl-cleanup@sail.stanford.edu
Subject: REST-LIST-ALLOCATION (Version 3)

I didn't send Version 2 to this mailing list, but sent it to
Masinter instead.  He requested that I make some small changes
and send the result to CL-Cleanup.  Here it is.

!
Forum:         Cleanup
Issue:         REST-LIST-ALLOCATION

References:    CLtL pp 107-108 (APPLY)

Related issues: DYNAMIC-EXTENT

Category:      CLARIFICATION

Edit history:  8-Dec-88, Version 1 by Masinter
               9-Dec-88, Version 2 by Clinger (add rationale, more discussion)
               12-Dec-88, Version 3 by Clinger (delete bogus examples)

Problem description:

In the special case of calling a function with an &REST list via APPLY,
Common Lisp fails to specify whether a new copy of the list is freshly
allocated.  For example, given

 (DEFVAR *MY-LIST* '(A B C))

 (DEFUN FOO (&REST X) (EQ X *MY-LIST*))

does 
(APPLY #'FOO *MY-LIST*)
return T?

This issue is different from the question of the extent of "rest lists" in
the case when they *are* newly allocated which is indefinite; the issue
DYNAMIC-EXTENT also contains some proposals about extent.


Proposal (REST-LIST-ALLOCATION:NEWLY-ALLOCATED): 

Specify that &REST lists are newly allocated in the case when the function
is called via APPLY.

Proposal (REST-LIST-ALLOCATION:MAY-SHARE): 

Specify that the value of an &REST parameter is permitted, but not required,
to share (top-level) structure with the last argument to APPLY.

Proposal (REST-LIST-ALLOCATION:MUST-SHARE)

Specify that the value of an &REST parameter is required
to share (top-level) structure with the last argument to APPLY.

>> this needs better spec about how the args match << 

Examples:

 (DEFVAR *MY-LIST* '(A B C))

 (DEFUN FOO (&REST X) (EQ X *MY-LIST*))

 (APPLY #'FOO *MY-LIST*) => T ;on Symbolics systems and probably
			      ; many stock hardware implementations

This implies that

 (DEFUN BAR (&REST X) (RPLACA X 'D))

 (APPLY #'BAR *MY-LIST*)

 *MY-LIST* => (D B C) ;on Symbolics systems and probably many stock
		      ; hardware implementations

Another example: which of the following have the same semantics?

    (setq x '(1 2 3))

    [1] (apply #'foo 1 2 3 NIL)
    [2] (apply #'foo 1 2 (cddr x))
    [3] (apply #'foo 1 (cdr x))
    [4] (apply #'foo x)
    [5] (funcall #'foo 1 2 3)

Under REST-LIST-ALLOCATION:NEWLY-ALLOCATED:
  [1]-[5] are equivalent.
Under REST-LIST-ALLOCATION:MAY-SHARE:
  Any answer to the question is correct for some conceivable implementation.
  Abstracting over implementations, this means that [1]-[5] are pairwise
  non-equivalent.
Under REST-LIST-ALLOCATION:MUST-SHARE:
  [1]-[4] are pairwise non-equivalent in all implementations.  This proposal
  leaves open the question of whether [1] is equivalent to [5].

And finally:

Should     (defun foo (&rest x) ...)
    
     behave (aside from efficiency) as if it were defined:
    
(defun foo (&rest G0047)     ;Gensym really
      (let ((x (copy-list G0047)))
         ...))
    

Rationale:

The semantics of APPLY is unclear.  In consequence it is impossible
to write portable code that relies on &REST arguments sharing structure
with the last argument to APPLY.  Portable code can rely on &REST arguments
*not* sharing structure with the last argument to APPLY, but only by
performing an explicit COPY-LIST on all &REST arguments; this is redundant
and inefficient in implementations where &REST arguments are newly
allocated anyway.

Current practice:

Some implementations always share. Some implementations never share.
A few may share interpreted and not share compiled, or vice versa.

Cost to Implementors:

None for MAY-SHARE, since that is the status quo.  Both of the other
proposals entail a significant cost for some implementations.
If MUST-SHARE is adopted, then implementations that don't share structure
may be nearly impossible to convert.  If NEWLY-ALLOCATED is adopted, then
implementations that do share will have to insert a call to COPY-LIST
inside either APPLY or &REST list handling, which will slow things down
and may be difficult as well.

Cost to Users:

No matter what, somebody gets hurt.  MAY-SHARE means you have to
write awkward and inefficient code if you care.  (This is already
the case for portable code.)  MUST-SHARE means you have to add
explicit calls to COPY-LIST to code that assumes the contrary.
NEWLY-ALLOCATED means you have to rewrite code that assumes sharing.

Cost of non-adoption:

Great confusion over the issue.  A certain amount of awkwardness and
inefficiency would remain inevitable if you want to write portable code.

Performance impact:

MUST-SHARE costs least in consing, but might slow down function call 
for some implementations.  MAY-SHARE lets implementations pick, has
least impact.  NEWLY-ALLOCATED requires consing in cases where it
didn't before.

Benefits:

Less confusion.  Improved portability.

Esthetics:

Differing, strongly held opinions.

Discussion:

The Revised3 Report on Scheme specifies that the equivalent of a
&REST argument must be a newly allocated list, to avoid precisely this
problem.

The argument for MUST-SHARE is that copying is inefficient, so
&REST should never cause copying of a list passed to it from APPLY.
Functions that desire a new copy can just call COPY-LIST.

Two arguments for MAY-SHARE are:

1. In no other place does Common Lisp automatically unshare structure,
except when the user is explicitly modifying the structure (as in REMOVE).
Making APPLY automatically unshare would be a semantic wart.

2. If APPLY copies its last argument, recursive programs that receive an
&REST argument and pass it to APPLY become inefficient.  A linear time
algorithm can change to a quadratic time algorithm.  While the efficiency
could be regained through compiler flow analysis in many cases, it's
better not to put the inefficiency into the language in the first place.

The DYNAMIC-EXTENT proposal would allow &REST lists
that were "newly allocated" to have dynamic extent if they were
to be passed down via APPLY.  This puts the burden in the
right place.

Two (closely related) arguments for NEWLY-ALLOCATED:

1. The programmer's model of function calling is simpler: functions
take arguments, and any two calls that pass the same arguments to the
same function are equivalent.  The MAY-SHARE and MUST-SHARE proposals
require a model in which functions generally take their arguments in
the form of a list, and the extent to which that list shares structure
with other lists in the system becomes an important part of the
semantics of a function call.

2.  It's not only smashing a &rest argument that's a problem, it's
smashing any list that has been given as the last argument to APPLY as
well.  Consider the following in an implementation that doesn't copy
the last argument to APPLY when it is passed as a &rest argument:

> (defvar *message*)
*MESSAGE*
> (defun set-message (&rest mess)
    (setq *message* mess))
SET-MESSAGE
> (let ((winner (list 'a 'winner)))
    (apply #'set-message winner)
    (setf (cdr winner) (list 'loser))
    winner)
(A LOSER)

Is *message* (A WINNER) or (A LOSER)?  (It might be
(#<DTP-LOCATIVE 76123756> #<DTP-ODD-PC 12313453> ...)
but that's a different problem.)  This suggests that once a list has
been given as the last argument to APPLY it is no longer OK to modify
it.

Gail Zacharias talked about the common idiom of simply doing a COPY-LIST
on every &rest argument, to insure some normalcy.  Her reasoning seems
to bolster the case for those who claim that the current CL semantics
(MAY-SHARE) are deficient:

    Subject: &REST Lists
    Date: 24 Mar 88 12:23:15 EST (Thu)
    From: gz@spt.entity.com (Gail Zacharias)
    . . . 
    If Common Lisp doesn't require unshared &rest lists, then I think
    it must provide a declarative version of this idiom so the COPY-LIST can
    be portably avoided when it's redundant.  Seems to me that the fact that
    this is a common case where users find a need for conditionalization
    indicates a real deficiency in Common Lisp's specification.
    . . . 

So we have a responsibility to resolve the very thorny issue
of REST-LIST-ALLOCATION.

∂12-Dec-88  1748	CL-Cleanup-mailer 	Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Dec 88  17:48:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 507596; Mon 12-Dec-88 20:48:08 EST
Date: Mon, 12 Dec 88 20:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881212-160109-5511@Xerox>
Message-ID: <19881213014819.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

[X3J13 removed]

I approve this, but there are some obvious mistakes:

Why is RANDOM-STATE missing from the list of built-in types?  Probably others
are missing as well, I did not check the list carefully.

(SUBTYPEP (TYPE-OF x) (CLASS-OF x)) => T T for all x, seems to
have been intended but is not actually said.  I think this should
be added to the proposal section.

The first three points in the proposal section are identified with
letters, but the last three points are not.

Re the discussion section:

The comment about the relation of CLASS-OF and TYPE-OF, while it may be
true, only indicates confusion in an earlier CLOS spec and detracts from
understanding the point of this proposal.

If you want "to eliminate the possibility that TYPE-OF might return a
non-portable implementation-specific value" you will have to define
the concept of portable objects versus implementation-dependent objects,
since obviously an implementation that has an entirely new kind of
object cannot return a portable type-specifier for that object.  Also what
about implementations that have implementation-dependent subtypes of
built-in types, especially if those subtypes are defined with DEFSTRUCT
or DEFCLASS -- the spec simultaneously requires TYPE-OF to return the
class name or structure name, and to return a portable value distinct
from the class or structure name.  For a concrete example, Genera has an
implementation-dependent subtype of PATHNAME for each type of file
system supported, and TYPE-OF returns the class name.  I think the
proposed implementation recommendation cannot be portably specified
and hence should be discarded.

∂12-Dec-88  1755	X3J13-mailer 	Issue: TAILP-NIL (Version 5)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Dec 88  17:55:38 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 507602; Mon 12-Dec-88 20:55:04 EST
Date: Mon, 12 Dec 88 20:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)
To: x3j13@sail.stanford.edu
cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: <881212-151820-5387@Xerox>
Message-ID: <19881213015522.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

Correction: Contrary to what the current practice section says,
the proposal TAILP-NIL:T is not what Symbolics Genera does.  In
fact I know of no implementation that does what the proposal says.

However, I support the proposal anyway, because I think it's the
most consistent with the rest of Common Lisp.

∂12-Dec-88  2019	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 6) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Dec 88  20:19:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 507662; Mon 12-Dec-88 23:18:59 EST
Date: Mon, 12 Dec 88 23:19 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 6)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881209-100319-6354@Xerox>
Message-ID: <19881213041909.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

[X3J13 removed]

Approved only if the name-changing amendment mentioned in the mail passes.

The writeup incorrectly states that Newline is not a standard character; I
suspect someone has confused "standard" with "graphic".  If for some reason
the proposal is edited again, this should be fixed.

∂13-Dec-88  0831	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 5)   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88  08:31:02 PST
Return-Path: <barmar@fafnir.think.com>
Received: from sauron.think.com by Think.COM; Tue, 13 Dec 88 10:38:42 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 13 Dec 88 11:25:07 EST
Date: Tue, 13 Dec 88 11:25 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: TAILP-NIL (Version 5)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: <19881213015522.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19881213162522.6.BARMAR@OCCAM.THINK.COM>

    Date: Mon, 12 Dec 88 20:55 EST
    From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>

    Correction: Contrary to what the current practice section says,
    the proposal TAILP-NIL:T is not what Symbolics Genera does.  In
    fact I know of no implementation that does what the proposal says.

    However, I support the proposal anyway, because I think it's the
    most consistent with the rest of Common Lisp.

I just tried all the examples in the mailing, and they all had the
results that they were supposed to.  How does Genera differ from
TAILP-NIL:T?

                                                barmar

∂13-Dec-88  0856	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 5)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88  08:56:24 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 507776; Tue 13-Dec-88 11:52:01 EST
Date: Tue, 13 Dec 88 11:52 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)
To: Barry Margolin <barmar@Think.COM>
cc: cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: <19881213162522.6.BARMAR@OCCAM.THINK.COM>
Message-ID: <19881213165206.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Tue, 13 Dec 88 11:25 EST
    From: Barry Margolin <barmar@Think.COM>

    How does Genera differ from TAILP-NIL:T?

Genera uses EQ, the proposal uses EQL (maybe you didn't notice that).
Since I don't believe EQ belongs in Common Lisp in the first place, I
agree that any system function that uses EQ as a test is wrong and
should be using EQL, which is why I support the proposal.  (EQ is only
in Common Lisp as a concession to implementors who haven't figured out
how to implement EQL efficiently (it isn't hard), or hadn't figured it
out yet in 1984).

∂13-Dec-88  1130	CL-Cleanup-mailer 	New issue: COMPLEX-ATAN-BRANCH-CUT  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88  11:30:21 PST
Received: from fafnir.think.com by Think.COM; Tue, 13 Dec 88 13:42:15 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 13 Dec 88 14:28:45 EST
Received: by verdi.think.com; Tue, 13 Dec 88 14:27:20 EST
Date: Tue, 13 Dec 88 14:27:20 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8812131927.AA25890@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: New issue: COMPLEX-ATAN-BRANCH-CUT

Forum:         Cleanup
Issue:         COMPLEX-ATAN-BRANCH-CUT
References:    CLtL p.208, 212
Related issues: IEEE-ATAN-BRANCH-CUT
Category:      CHANGE

Edit history:  Version 1, 13-Dec-88, Steele

Problem description:

The formula that defines ATAN results in a branch cut that is at
variance with the recommendations of Prof. W. Kahan and with the
implementations of that function in many computing systems and
calculators.

Proposal (COMPLEX-ATAN-BRANCH-CUT:TWEAK):
  
Replace the formula

	arctan z = - i log ((1+iz) sqrt (1/(1+z↑2)))

with the formula

	arctan z = (log (1+iz) - log (1-iz)) / (2i)

This leaves the branch cuts pretty much in place; the only change is
that the upper branch cut (on the positive imaginary axis above i)
is continuous with quadrant I, where the old formula has it continuous
with quadrant II.

Examples:

(atan #c(0 2)) => #c(-1.57... 0.549...)	;Current
(atan #c(0 2)) => #c(1.57... -0.549...)	;Proposed

Note: 1.57... = pi/2, and 0.549... = (log 3)/2.

Rationale:

Compatibility with what seems to be becoming standard practice.

  
Current practice:

(atan #c(0 2)) => #c(-1.57... 0.549...)	;Symbolics CL
(atan #c(0 2)) => #c(-1.57... 0.549...)	;Allegro CL 1.1 (Macintosh)
(atan #c(0 2)) => #c(-1.57... 0.549...)	;Sun-4 CL 2.1.3 of 10-Nov-88
(atan #c(0 2)) => #c(1.57... -0.549...)	;Sun CL 2.0.3 of 30-Jun-87
(atan #c(0 2)) => #c(1.57... 0.549...)	;KCL of 3-Jun-87

Note that in KCL the upper branch cut is thus continuous with
quadrant I, but its lower branch cut is continuous with quadrant III!

Cost to Implementors:

ATAN must be rewritten.  It is not a very difficult fix.

Cost to Users:

It is barely conceivable that some user code could depend on this.
Note that the proposed change invalidates the identities
	arctan i z = i arctanh z
and	arctanh i z = i arctan z
on the upper branch cut.

The compatibility note on p. 210 of CLtL gave users fair warning that
a change of this kind might be adopted.

Cost of non-adoption:

Incompatibility with HP calculators.

Benefits:

Numerical analystsmay find the new definition easier to use.

Esthetics:

A toss-up, except to those who care.

Discussion:

Steele has sent a letter to W. Kahan at Berkeley to get any last
comments he may have on the matter.

Paul Penfield of MIT, after whose article the Common Lisp branch
cuts were originally patterned, endorses this change.

∂13-Dec-88  1131	CL-Cleanup-mailer 	New issue: IEEE-ATAN-BRANCH-CUT
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88  11:31:13 PST
Received: from fafnir.think.com by Think.COM; Tue, 13 Dec 88 13:43:05 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 13 Dec 88 14:29:36 EST
Received: by verdi.think.com; Tue, 13 Dec 88 14:28:10 EST
Date: Tue, 13 Dec 88 14:28:10 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8812131928.AA25893@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: New issue: IEEE-ATAN-BRANCH-CUT

Forum:         Cleanup
Issue:         IEEE-ATAN-BRANCH-CUT
References:    CLtL p.203-214
Related issues: COMPLEX-ATAN-BRANCH-CUT
Category:      CHANGE

Edit history:  Version 1, 13-Dec-88, Steele

Problem description:

If an implementation provides a floating-point minus zero as well as a
floating-point plus zero, most notably as in IEEE 754 floating-point
arithmetic, then slight adjustments in the branch cuts of transcendental
functions are appropriate.

If there is a minus zero and a plus zero, then *no* complex number
is actually "on the axis" whether real or imaginary.  Instead,
numbers of the form x+0i and x-0i straddle the real axis, and those
of the form 0+xi and -0+xi straddle the imginary axis.  Branch cuts
that lie on the axes therefore run between such numbers, and directions
of continuity are not an issue.

Proposal (IEEE-ATAN-BRANCH-CUT:SPLIT):

We propose to redefine the branch cut for two-argument ATAN, covering
the cases where there is or is not a minus zero, and then redefine *all*
other functions that have branch cuts in terms of two-argument ATAN.
Specifically, we first define PHASE in terms of two-argument ATAN,
and complex ABS in terms of real SQRT (which has no branch cut problems);
then define complex LOG in terms of PHASE, ABS, and real LOG; then define
complex SQRT in terms of LOG; and then define all others in terms of these.

When I write Lisp expressions, I mean them to be taken as mathematical
formulas that could be implemented in other ways for improved accuracy.

(1) If there is no minus zero, two-argument ATAN behaves as in CLtL.
    If there is a minus zero, then some cases are modified:
	Condition			result
	y=+0  x>0			   +0
	y=-0  x>0			   -0
	y=+0  x<0			   +pi
	y=-0  x<0			   -pi
	y=+0  x=+0			   +0
	y=-0  x=+0			   -0
	y=+0  x=-0			   +pi
	y=-0  x=-0			   -pi
    The range of two-argument atan therefore includes -pi in this case.

    Note that the case y=0 x=0 is an error in the absence of minus zero,
    but is defined in the presence of minus zero.

(2) (PHASE X) = (ATAN (IMAGPART X) (REALPART X)), as before, but now
    the range of PHASE may include -PI if there is a minus zero.

(3) (ABS X) = (SQRT (+ (* (REALPART X) (REALPART X))
		       (* (IMAGPART X) (IMAGPART X)))), as before

(4) (LOG X) = (COMPLEX (LOG (ABS X)) (PHASE X))

(5) (SQRT X) = (EXP (/ (LOG X) 2))

(6) For EXPT, ASIN, ACOS, ATAN, ASINH, ACOSH, ATANH use the formulas
    in CLtL pp. 211-213, but use the formulas (1-5) above as the
    definitions of LOG and SQRT in order to determine the branch cuts
    properly.

Examples:

(LOG #c(-1.0 +0.0)) => #c(0.0 3.14159...)	;Current
(LOG #c(-1.0 -0.0)) => #c(0.0 3.14159...)	;Current

(LOG #c(-1.0 +0.0)) => #c(0.0 3.14159...)	;Proposed (= current)
(LOG #c(-1.0 -0.0)) => #c(0.0 -3.14159...)	;Proposed (conjugate)

Rationale:

The current specification ignores some natural consequences of IEEE
floating-point arithmetic.  The proposed specification produces results
more natural to that arithmetic.

  
Current practice:

Of implementations that support a minus zero that I have checked,
such as Sun-4 CL 2.1.3 of 10-Nov-88 and Symbolics CL, all follow
the current CLtL specification.

The IEEE trig library atan2 routine written by K.C. Ng (with the advice
or supervision of W. Kahan, I believe), and distributed with BSD UNIX
(it is file /usr/src/usr.lib/libm/IEEE/atan2.c on my machine) follows
this proposal for treatment of minus zero.


Cost to Implementors:

Some of the trig routines will require some rewriting.  Probably certain
tests that are now written using ZEROP need to be rewritten to use
FLOAT-SIGN instead.


Cost to Users:

It is barely conceivable that some user code could depend on this.
Probably there is no cost.

The compatibility note on p. 210 of CLtL gave users fair warning that
a change of this kind might be adopted.

Cost of non-adoption:

Unnatural treatment of some functions on machines supporting IEEE
floating-point arithmetic.

Benefits:

Natural treatment, etc.

Esthetics:

A toss-up, except to those who care.

Discussion:

Steele has sent a letter to W. Kahan at Berkeley to get any last
comments he may have on the matter.

∂13-Dec-88  1446	CL-Cleanup-mailer 	Issues: SETF-PLACES, SETF-FUNCTION-VERSUS-MACRO    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88  14:46:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508073; Tue 13-Dec-88 17:46:21 EST
Date: Tue, 13 Dec 88 17:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issues: SETF-PLACES, SETF-FUNCTION-VERSUS-MACRO
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <8812091618.AA01151@defun.utah.edu>,
             <881209-011330-5598@Xerox>,
             <881209-005847-5576@Xerox>,
             <881209-005650-5575@Xerox>,
             <881130-185833-3618@Xerox>,
             <19881201011953.3.GREGOR@PORTNOY.parc.xerox.com>,
             <8811301926.AA01386@mist.>,
             <881130-103422-2216@Xerox>,
             <8811300836.AA03401@bhopal>,
             <8811300333.AA02997@bhopal>,
             <2805815733-10120696@Kelvin>,
             <8811290708.AA00511@bhopal>,
             <8811290702.AA00498@bhopal>,
             <8811290644.AA00476@bhopal>,
             <8811281729.AA10535@rainbow-warrior>,
             <881128-102707-1360@Xerox>,
             <19881123004923.5.MOON@EUPHRATES.SCRC.Symbolics.COM>,
             <2805237539-1438981@Kelvin>
Message-ID: <19881213224631.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

I have re-read all of the referenced messages on SETF-PLACES and
SETF-FUNCTION-VERSUS-MACRO.  My opinion has not changed.  I don't
consider that any of my comments on SETF-PLACES have been adequately
addressed; that is, the version of SETF-PLACES that was mailed to X3J13
was the same as the original version, and the mail response to my
comments did not convince me that no changes to the proposal were
appropriate.

I agree with Gray that if the problem is with making SYMBOL-FUNCTION
accept arguments that are not symbols, a better approach than
UNDERLYING-NAME is to add FDEFINITION and its related primitives,
leaving SYMBOL-FUNCTION alone.  This provides a clear layering of
primitives, instead of this strange (to me anyway) concept of a
translation that may or may not actually translate.  I wasn't at the
October X3J13 meeting, but from the description of the amendment at that
meeting, what Gray said seems to be more like what X3J13 was asking for.

We have been discussing this stupid issue for almost a year and a half.
I certainly hope the January X3J13 meeting can come to a decision.

∂13-Dec-88  1509	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 5) 
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 13 Dec 88  15:08:58 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)
	id AA24500; Tue, 13 Dec 88 17:07:45 CST
Posted-Date: Tue, 13 Dec 88 17:06:12 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
	id AA11821; Tue, 13 Dec 88 17:06:12 CST
Date: Tue, 13 Dec 88 17:06:12 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8812132306.AA11821@pavo.src.honeywell.com>
To: cl-cleanup@sail.stanford.edu
Cc: masinter.pa@Xerox.COM
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 8 Dec 88 20:40 PST <881208-204059-5304@Xerox>
Subject: Issue: PACKAGE-DELETION (Version 5)

....
      If the designated package is used by other packages, a correctable
      error is signalled. ...

"continuable error"

      After this operation completes, the contents of the symbol-package  
      slot of any symbol homed in the deleted package is unspecified; ...

symbol S homed in pkg P == (eq P (symbol-package S)) ?

Perhaps;
  If package P was the value of (symbol-package S) then P is killed, it is
  unspecified what the value of (symbol-package S) is.

∂13-Dec-88  1606	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 5)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88  16:06:23 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508117; Tue 13-Dec-88 19:05:23 EST
Date: Tue, 13 Dec 88 19:05 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)
To: Masinter.PA@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881212-151820-5387@Xerox>
Message-ID: <881213190509.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 12 Dec 88 15:17 PST
    From: cl-cleanup@sail.stanford.edu
    Sender: masinter.pa@Xerox.COM

    Issue:        TAILP-NIL
    ...
    Discussion:
    ...
      It was suggested more than once by more than one cleanup 
      committee member that we remove TAILP from the language
      "since almost nobody uses it". 

For the record, at least one member of the cleanup committee thinks
this sentence is

 Irrelevant.  Removing the operator would be gratuitous.

 Inflammatory.  It seems to raise the possibility of removing TAILP,
   when in fact since such a move would be quickly labeled gratuitous,
   only provides fodder for those who wish to muddy the water and avoid
   the real issues under discussion.

 Unfounded.  No evidence is presented to support the claim that almost
   nobody uses it. Indeed, it has been repeatedly shown that if an
   operator is used at all, we have no way of evaluating what it
   means for the operator to be "used a lot" (lines of code, number
   of executed funcalls, dollars behind products using, ...). It happens
   that this claim's probably true, but as a point of style we oughtn't
   be in the habit of making anonymous, unsubstantiated claims about usage
   patterns, or especially of encouraging that decisions be made based on
   such claims.

 Shooting in the Dark.  Even if an operator were not often used by some
   metric(s), the suggestion that the only or best way to deal with it
   is to remove it is random. There are equally good reasons to believe
   that the operator would be both useful and more heavily used if its
   definition were ammended to accomodate serious uses.

   I, for one, have found that nearly every time I think LDIFF would
   suffice, the EQL test (rather than EQUAL), and its failure to take
   a test argument, has screwed me -- causing me to do what I have always
   felt is needless rewrite. I have only rarely needed TAILP and I can't
   remember if I ended up actually using it or not -- I'd suspect that
   the constraints on it make it next to useless.

   The point I want to stress is that the fact that LDIFF and TAILP have
   not been what I've needed does not mean that I've not needed to find
   the difference of two lists or to find if something was a subtail of
   something else. The problem for me has not been that these -operations-
   are useless (or nearly so) -- but rather that these -operators- are.
   The cure is not necessarily to flush the operators -- it might well be
   to fix them. I certainly think fixing them is the correct solution.

Only in writing this message did I become cognizant of the significance of
my problems with LDIFF and its relation to TAILP.

Btw, I just looked up LDIFF and its description suffers from a similar
non-clarity about dotted lists to that which TAILP suffers from. It
clearly admits NIL as a possible sublist, but it doesn't really treat
atoms. So, the status quo is that the relationship between LDIFF and TAILP
is not clear, the proposal TAILP-NIL:NIL would have definitely made them
incompatible, TAILP-NIL:T makes them more conceptually compatible, but
without further clarification, they will not really be compatible.

Based on this, I'm strongly tempted to suggest that we should ...

 - Expand this proposal to deal with LDIFF.

 - Elaborate this proposal to add a :TEST argument to both
   operators. [Clearly a :TEST argument of EQUAL may be dramatically
   slower, but if the alternative is to write a LOOP calling EQUAL,
   the net effect is the same and the only question is how much coding
   I have to do and how much the system will do for me.]


So there! That should teach you to add "harmless" little additions to the
discussion at the last minute. :-)

∂13-Dec-88  1645	CL-Cleanup-mailer 	Issue: PROCLAIM-LEXICAL (Version 9) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88  16:45:17 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508133; Tue 13-Dec-88 19:44:31 EST
Date: Tue, 13 Dec 88 19:44 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 9)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881208-215519-5376@Xerox>
Message-ID: <881213194417.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 8 Dec 88 21:54 PST
    From: masinter.pa@Xerox.COM

    I've attempted to make the edits that JonL suggested in
    his message of 18-Oct-88. 

To my great relief, these changes look generally quite fine.
Thanks, Larry.

    I wish this were shorter, e.g., that we could say what we have
    to say with less Discussion. I'm sorry I haven't the courage
    to tackle it.

Well, My training in writing for newspapers says this is not really much
of an issue as you might think. As long as the presentation is in
"inverse pyramid style" (order of diminishing importance), people can
stop reading when they've gotten the important stuff if they think the
writeup is too long. Of course, the poor guy we trick into Xeroxing copies
of all these issues and carry them halfway around the world to the meeting
(possibly in the other order) may not agree...

I have one substantive comment, by the way:

    Issue:        PROCLAIM-LEXICAL
    Edit history:
    ...
		  Version 9 by Masinter  8-Dec-88 (make JonL's changes)
    ...
    Proposal (PROCLAIM-LEXICAL:LG):
    ...
      Clarify that a dynamic binding of a variable creates a new binding
      in the dynamic environment (D) leaving the global environment (G)
      unaffected.
    ...

In the previous version, I used the verb "Define" for this, not "Clarify"
here. "Clarify" is technically ok but only if you understand how the formal
global environment (G) described here potentially differs from the global
environment actually implemented in the running Lisp (i.e., if you
understand why this description does not preclude shallow binding).
I had preferred the word "Define" because it makes people read more closely,
and because some people may not see this as a simple clarification.

I don't think it's worth re-issuing the proposal, but I do think it's
something we should be aware of in case it leads to confusion in the
open discussion -- so we can head it off quickly.

Overall, I'm extremely pleased with this how this writeup ended up.
I'm crossing my fingers that it will be well-received.

∂13-Dec-88  1800	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 5) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88  18:00:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508169; Tue 13-Dec-88 20:59:28 EST
Date: Tue, 13 Dec 88 20:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT (Version 5)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881212-103904-4431@Xerox>
Message-ID: <19881214015936.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

I'm sorry I got behind reading the mail on this topic.  There are enough
mistakes in this released-to-X3J13 version (even though it is
considerably improved over my last version) that a line by line
commentary seems necessary.  Sorry about the length.  I've avoided
commenting on typos that don't affect the meaning, except to put -> in
the margin, to save space.

I'd volunteer to fix the writeup except that, as noted below, I can't
think of any implementation-independent way to say what I think the
MEDIUM proposal was intended to say, but does not actually say.

    Issue:         EXIT-EXTENT

    References:    CATCH, THROW,
		   BLOCK, RETURN, RETURN-FROM,
		   TAGBODY, GO, UNWIND-PROTECT,
		   Dynamic extent (CLtL p.37),
		   Nested dynamic extents (CLtL p.38),
		   Blocks can only be exited once (CLtL p.120),
		   Catch is disestablished just before the values 
		   are returned (CLtL p.139).
    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

    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?

    (Terminology: In this issue writeup, the noun "exit" is
->  refera to the thing that can be exited from, rather than the
    act of exiting. 

That would be a good idea, but in fact the writeup still uses the word
"exit" to refer both to the door and to the act of walking out the door.
I guess the sentence is technically true, since the latter use is a verb
rather than a noun.  It would be better to use only "transfer of control"
to refer to the act of walking out the door.

		    When the extent of an exit has ended, it is
    no longer legal to exit from it. This is different from
    the scope of the exit. For example, a BLOCK has lexical
->  scope but dynamic extent; a the scope of a CATCH--the 
    visibility of the CATCH tag to corresponding THROWs--
    could differ from the extent of the CATCH.)

    The problem arises when there are nonlocal exits from the 
    "cleanup" clauses of an UNWIND-PROTECT.

    There are three cases of interest:

    (1) Normal exit from a CATCH, BLOCK, or TAGBODY, or equivalent such as
    PROG.  A normal exit occurs when the last form in the body of one of
    these constructs completes its evaluation without performing a transfer
    of control.

    (2) Nonlocal exit from the target of a THROW or RETURN.  A nonlocal exit
    occurs when control is transferred by THROW, RETURN, or RETURN-FROM.
    The CATCH or BLOCK named in the THROW, RETURN, or RETURN-FROM is
    referred to as the target.  The TAGBODY containing the tag named by a
    GO is also referred to as the target, but GO differs from the other
    nonlocal control transfer operators because GO does not exit its target.
->  For example,

    (3) Abandonment of an exit passed over by THROW, RETURN, or GO.  A
    CATCH, BLOCK, or TAGBODY that is dynamically nested inside the target of
    a nonlocal transfer of control is said to be passed over when control is
    transferred to the target.  The target itself is not said to be passed
    over.

    For example, in
       (block testem
	  (when (zilched) (return-from testem nil))
	  (when (zorked) (throw 'uh-oh))
	  (format t "Neither zilched nor zorked."))

    if (zilched) returns true, the block testem is exited via a 
    'nonlocal exit'. If (zorked) returns true, the block testem
    is 'passed over'. Otherwise, the block is exited normally.

    The terms "normal exit", "target", and "passed over" will be used with
    these meanings for the remainder of the discussion.

    CLtL is unambiguous about case 1.  In case 2, the extent could end
    anywhere from the time the THROW or RETURN commences, until the time the
    transfer of control is completed.  In case 3, the extent could end
    anywhere from the time the THROW, RETURN, or GO commences, until the
    time the transfer of control is completed.  In case 2, it is clear that
    the extent of the target ends before the transfer of control completes,
    since a block cannot be exited twice, but it is not made clear whether
    the extent ends before or after execution of UNWIND-PROTECT cleanup
    forms.  CLtL says nothing about case 3, although a note on p.38 implies
    that the extent of a passed-over exit should end no later than the end
    of the extent of the target exit.  It would make sense for the extent
    of an exit passed-over by GO to end no later than when the transfer of
    control is completed, but CLtL says nothing about this.

    !
    Proposal (EXIT-EXTENT:MINIMAL):

    The dynamic extent of an exit, whether target or passed-over, ends as
    soon as the THROW, RETURN, or GO commences.  In the language of the
    implementation note on p.142, the extent ends at the beginning of the
    second pass.  It is an error for an UNWIND-PROTECT cleanup form executed
    during a nonlocal transfer of control to attempt to use an exit whose
    dynamic extent ended when the nonlocal transfer of control commenced.

Actually this should just say "It is an error to attempt a transfer of
control to an exit whose dynamic extent has ended."  It doesn't really
matter when it ended nor exactly who attempts the transfer of control.

    Note that this does not affect the extent of the binding of CATCH
    tags; that is, under this proposal, a THROW to a CATCH which was
    already in the process of being exited would be an error.

I think the word "extent" in the first line of this paragraph should
have been "scope", but I can see how reasonable people might disagree.
A couple of places later in the writeup use "scope" in that way in
connection with CATCH, though.

    This proposal is called "minimal" because it gives exits the smallest
    extent consistent with CLtL. 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 dynamic extent of an exit, whether target or passed-over, ends
    only after the exit is complete. 

I doubt that that is what you intended to say.  For example,
  (block one
     (let ((f nil))
       (unwind-protect
           (block two
	     (flet ((g () (return-from two 2)))
	       (setq f #'g)
	       (return-from one 1)))
	 (funcall f))))
Under MINIMAL, this is an error because the block named two is passed
over by the return-from one before the return-from two is executed.
Under MEDIUM, this is not an error because at the time of the funcall f,
the exit is not complete and so the dynamic extent of the block named
two has not yet ended.  It either returns 2 or goes into an infinite
loop, depending on what it means to exit twice out of an UNWIND-PROTECT.

Probably this intended to say something about how the dynamic extent of
a passed-over exit ends when control reaches a frame that was
established before the exit was established.  I don't know how to say
that in an implementation-independent way.  This difficulty in defining
a clear semantics for passed-over exits is exactly why I have always
favored MINIMAL, which constrains portable programs maximally and
constrains implementations minimally (which allows us to say as little
as possible about the implementation).

I think we must only vote on what proposals actually say, not on what we
guess they might have been intended to say.  We can of course amend them
to say something different and then vote on them.

    A transfer of control from within an UNWIND-PROTECT cleanup form
    to a point outside of the UNWIND-PROTECT causes the original control
    transfer which initiated the execution of the cleanup forms to be
->  abandonded.

    During the execution of the cleanup forms of an UNWIND-PROTECT a
    non-local exit to a point outside of the scope of the UNWIND-PROTECT,
->  but still within the dynamic scope of of the target of the original
    non-local exit succeeds, and the original pending exit is discarded.

    Where an UNWIND-PROTECT cleanup form attempts a non-local exit to a
    point outside the original non-local exit, control is passed to the
    outer exit (and the pending original non-local exit is discarded.) 

    In no case will UNWIND-PROTECT cleanup forms ever be attempted more
    than once.

This can't be true, since everyone agrees that

  (unwind-protect nil
    (loop (print 1)))

prints 1 more than once.  Also if the UNWIND-PROTECT is entered more
than once, it cleanup forms can of course be called more than once.

I think I know what you intended to say, but that isn't what you
actually said.  I'm not sure why this needs to be in the proposal at all
once the problem I pointed out above is fixed, so maybe it would be
simpler just to remove it.

    !
    Examples:

->  Each of the following programs are an error under either
    proposal:

    ;; Error: BLOCK has normal exit before RETURN
    (funcall (block nil #'(lambda () (return))))

    ;; Error: normal exit before GO
    (let ((a nil)) 
      (tagbody t (setq a #'(lambda () (go t))))
      (funcall a))

    ;; Error: TAGBODY is passed over, before GO
    (funcall (block nil
	       (tagbody a (return #'(lambda () (go a))))))


->  Each of these programs are an error under MINIMAL, but
    not under MEDIUM:

    ;;returns 2 under MEDIUM, is error under MINIMAL
    (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, is error under MINIMAL
    (catch nil 
      (unwind-protect (throw nil 1)
	(throw nil 2)))

    ;; returns 2 under MEDIUM, is error under MINIMAL
    (catch 'a
      (catch 'b
	(unwind-protect (throw 'a 1)
	  (throw 'b 2))))
    ;; An 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 catch is not yet disestablished and therefore it
    ;; is the target of the second throw.

    ;; the following is an error under MINIMAL; 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, 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))


    The following program is not an error.  It returns 10.  The inner
    catch of a is passed over, but this is not case 3 because that catch
    is disestablished before the throw to a is executed.

    (catch 'a
      (catch 'b
	(unwind-protect (1+ (catch 'a (throw 'b 1)))
	  (throw 'a 10))))

The way MEDIUM is actually written, this seems to return 11 under
MEDIUM, because the throw to a goes to the inner catch.  But I think you
intended for it to return 10.

    The following cases are errors under MINIMAL, and have
    the following interpretation under MEDIUM:

The second case is not an error under MINIMAL.  It behaves
identically in MINIMAL and MEDIUM.

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

    the pending exit to tag FOO is discarded by the second THROW 
    to BAR and the value 4 is transfered to (CATCH 'BAR ...),
    which returns 4. The (CATCH 'FOO ...) then returns the 4
    because its first argument has returned normally.
    XXX is not printed.

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

    the value 4 is returned from the (CATCH 'BAR ...); XXX is not printed.
	. 3 evaluates to itself and is saved by THROW which begins
	  searching for tag FOO. 
	. 4 evaluates to iself and is saved by THROW which begins
	  searching for tag BAR.
	. It is not an error, even though the
	  BAR tag is not found within the local dynamic scope of

I don't know what a "local dynamic scope" is.

	  the UNWIND-PROTECT cleanup form containing (THROW 'BAR 4)
	  but is found outside the scope of the target of the 
	  pending THROW to FOO.

    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.

->  For MEDIUM: Giving exits a longer exent 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, the extent of a target exit lasts until the
    exit has been completed; in those implementations, it is possible for a
    throw or non-local exit to be effectively "stopped" by an UNWIND-PROTECT
    cleanup clause that performs a nonlocal 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 exent.

    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 nonlocal 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 interchangably,
    calling this an error would be inappropriate. 

This is no argument against the MINIMAL proposal.  Suppose FOO and BAR
are to be treated interchangeably.  Then the above example should be
equivalent to

      (block foo
	(unwind-protect
	    (return-from foo 'foo)
	  (return-from foo 'bar)))

In fact these two examples are equivalent under both proposals.  Under
MEDIUM they both return BAR.  Under MINIMAL they are both errors.

    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 nonlocal exit
    that caused the cleanup clause to be invoked. 

    CLtL never says in what dynamic environment cleanup forms of
    UNWIND-PROTECT are executed.  The implementation note on p.142 may have
    been intended to cover this, but since it doesn't define the term
    "frame" that it uses, it doesn't actually say anything.  The extent of
    dynamic-extent entities other than exits should be the
    subject of a separate proposal. It was argued that the likely
    resolution of those issues would be more consistent with the
    MEDIUM proposal than MINIMAL.

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

"exited" in the preceding line should be "ended" or "passed over".

This is true, but interchanging the first two lines of the example would fix it.
It is quite intentional that the MINIMAL proposal says this style of coding
is non-portable.  In current practice it is non-portable.

∂13-Dec-88  1816	CL-Cleanup-mailer 	Issue: REST-LIST-ALLOCATION (Version 3)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88  18:16:25 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508176; Tue 13-Dec-88 21:15:56 EST
Date: Tue, 13 Dec 88 21:15 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REST-LIST-ALLOCATION (Version 3)
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
In-Reply-To: <881212-161110-5531@Xerox>
Message-ID: <881213211541.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

This is a tough issue.

NEWLY-ALLOCATED and MUST-SHARE have the virtue of involving the fewest
hassles for portable code. Latent surprises of this kind are invariably
terribly hard to track down, and it's a definite feature to avoid the
problem.

On the other hand, MAY-SHARE is the clearly efficient thing for what is
probably the most common case, so we should be careful not to pick a
semantics that forces undue expense in that case.

This problem may be related to the DYNAMIC-EXTENT issue. Just as we want
the option of new structures being stack-allocated, we seem to want the
option of new structures being shared or unshared. I could imagine,
as GZ suggests, a declaration to accomodate this. For example:
 (DEFUN FOO (&REST X)
   (DECLARE (UNSHARED-STRUCTURE X))
   ...)
We might someday figure a way to generalize to other cases, such as uses
of backquote. Consider:
 (LET ((X `(A ,B C)))
   (DECLARE (UNSHARED-STRUCTURE X))
   ...)
For now, though, I think it best to consider restricting the variable to
only &REST variables (by not allowing the variable to be specified!).
This kind of declaration may sound bizarre, but I think GZ is right in
asserting that it's an important thing that portable programs must 
constantly reckon with and need a serious solution for.

On the basis of the reasoning presented above, my position is that we
should do the following two things:

 - Drop the NEWLY-ALLOCATED and MUST-SHARE variants as practically
   infeasible and ramp up MAY-SHARE.

 - Extend MAY-SHARE to include a mechanism that seriously addresses
   the fact that sometimes we need to get a particular kind of
   functionality. Perhaps declarations like
     (REST-LIST-SHARING :NEVER)
     (REST-LIST-SHARING :SOMETIMES)     
     (REST-LIST-SHARING :ALWAYS)
   or
     (REST-LIST-ALLOCATION :NEW)
     (REST-LIST-ALLOCATION :UNSPECIFIC)
     (REST-LIST-ALLOCATION :SHARE)
   The only issue then would be whether there were implementations where
   the always-share functionality would be impossible to implement (since
   the never-share functionality could at least be simulated in 
   implementations where it couldn't be reliably detected), and whether we
   were willing to allow such implementations to just signal an error in
   that case. (If we were to permit implementations to not implement :SHARE,
   we might be better off not offering the feature in the first place.)

∂13-Dec-88  2111	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88  21:11:04 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508226; Wed 14-Dec-88 00:10:13 EST
Date: Wed, 14 Dec 88 00:09 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
To: jonl@lucid.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8812070640.AA11552@bhopal>
Message-ID: <881214000958.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

Disclaimer: The contents of this note are my personal opinion and not
	    necessarily the opinion of Symbolics.

Summary: I'm quite upset by this message of JonL's, not because of its
	 technical position, but because of the lack of personal respect
	 JonL has shown for my technical position. This message has some
	 technical content, and therefore I want it in the CL-Cleanup
	 archives, but its primary content is political, emotional, and
	 personal. As such, recipients other than JonL shouldn't treat it
	 as high priority reading.

-----
    Date: Tue, 6 Dec 88 22:40:23 PST
    From: Jon L White <jonl@lucid.com>

    ... 
    This may be the Symbolics 3600 status quo (and TI Explorer); but no other
    implementation I'm aware of takes this variant view of CLtL.  Considering
    the strong, though not unanimous,  opposition  to making all arrays 
    adjustable, I don't see how you can expect to resolve the debate simply
    making such a statement.

Status quo has, to the best of my knowledge, always been taken in our
discussions to mean "what is implemented", not "what is understood by an
elite group of people who designed CLtL in the first place". We have usually
reserved the phrase "what was intended" to refer to what people might have
had in mind, and we might debate what was intended, but as far as I'm
concerned there is never any debate on the status quo.

I discount from the status quo only obvious violations (eg, an implementation
fails to support bignums) where no defensible reading of the manual will cover.
I count for the status quo -any- implementation for which there is a passage
in CLtL which the implementors claim to have faithfully interpreted and which
they have made a financial investment in.

I did not question the validity of someone's claim that Choral had implemented
NCONC as APPEND. They claim this was a mere bug, but if they hadn't, I would
have been willing to accept it as the "status quo" (even if not "what was
intended") because they can probably find text to back it up.

If you take a different view of the status quo, you should go back to Mathis or
that nice lady who on the first day of X3J13 gave us a lesson on the legalities
of X3J13 and the dangers of claiming to be able to "interpret" CLtL. You'd
better be -very- careful not to make any public statements of the form
"Implementation X is not conforming because of ..." unless you're prepared to
cite written text (not popular myth) to back yourself up or you may find yourself
in court backing up such slanderous claims. Such, at least, was their contention,
and I'm inclined to believe they were right to warn us thus.

It is not the business of this committee to retroactively invalidate good faith
implementations of CLtL. If we want to make tougher standards, we can do so only
by making a new standard which is more rigorously defined.

    Why not just admit that the intent of simple arrays was to accommodate 
    the needs of "stock" hardware implementations?

I admitted this already.

    Thus remembered, no one could mistake the intent for SIMPLE-ARRAYs -- that
    they be non-adjustable. 

Not so. Our collective recollection is that you were -permitted- (not -required-)
to make them be non-adjustable.

    Indeed, why create such an arbitrary type subset if it were only of 
    theoretical interest?  [Remember also the "RPG Memorial Array" proposal.]  

It isn't only of theoretical interest. It's clearly a bug that ADJUSTABLE-ARRAY-P
doesn't predicate whether ADJUST-ARRAY will work. That should just be fixed.

It's not clear that it's a bug that the effect of doing :ADJUSTABLE NIL
was not specified. There are plenty of useful applications that derive
from the interpretation we support.

    Then this whole disingenuous 

Excuse me, but this kind of thing really pisses me off. This adjective has no
place in any discussion of this sort and if I see it again I will disinvolve
myself with this and perhaps any further discussion.

We could not be more up front and sincere: We have said some people here believe
the wording is as it is for a reason. The reason, while not popular -- I don't
even like it personally -- is completely defensible from a technical standpoint
and not subject to any kind of common sense arguments that there was "only one
possible interpretation". There may have been only one "obvious interpretation"
but on inspection you should be willing (as am I) to agree, at least reluctantly,
that this is a valid point of view -- if for no other reason because people
whom you hopefully respect have asserted that it is a valid point of view.

In general, my rule of thumb for what is ambiguous is anything for which all
parties cannot be convinced, through discussion, is not ambiguous. This is,
if one party thinks something is ambiguous and one party thinks it is not, then
by (my) definition, it is ambiguous. The only exceptions are extreme cases where
where the individual claiming ambiguity can be demonstrated to have insufficient
command of the issue (eg, hairy floating point stuff) or insufficient command
of the English language; I assert that on this issue, I have neither of these
deficiencies, and that my claim of ambiguity is generous.

    re-reading of the history of adjustable 
    arrays and "loopholes" in CLtL could be dropped; and Symbolics could 
    simply say something like:
	"Symbolics extends Common Lisp ARRAY functionality in an improved,
	 but technically incompatible, way." 

It is your burden to demonstrate that it is incompatible. I have cited
specific passages with which you might quibble about "original intent" but
you cannot quibble about "technically compatible". In point of fact, we are
within the letter of the stated rules, and we have cited reasons 

I've said over and over that I don't happen to personally like the Symbolics 
[Genera] interpretation (Cloe's interpretation is different :-), but I think
they/we are within their/our rights to claim it.

    That simple, frank statement would make everybody much more comfortable
    (especially 3600 user's who wonder why their code doesn't port), and 
    would finally close the debate so that we don't have to waste yet more 
    and more time on it.

Don't hold your breath. It's just not as simple as that. There are really major 
issues of compatibility and QA that we have to deal with, and the expense for
us would probably not be small.

Besides, the Cloe development environment (which is what I and many others
here recommend for people porting code out to other environments) does offer
the interpretation you suggest.

    [Yes, I'm aware that Symbolics would have to face 
    persistent demands from some of their users to "come into compliance"; 
    but it's much more likely that you can make satisfactory explanations to 
    these customers than that you can convince the "stock hardware" types to 
    swallow universal adjustability.]

I don't see why either of these extremes is necessary. I'm not advocating
that stock hardware swallow universal adjustability and I'm asking them not
to force this change on us.

Virtually every other vendor has at one time or another indicated that some
proposed change would be prohibitively expensive. We have generally treated
such claims with respect. Rarely has anyone had the gall to suggest that they
should just bite the bullet and accept an enormous incompatible change or
"just declare themselves to be incompatible" (a dangerous trend). In general,
such proposals have stopped dead in their tracks until/unless someone could
propose a serious way around the difficulty -- and "just declare yourself to
be incompatible" has never been an avenue open to us before. I am awestruck
that you could suggest this.

If you want to disagree with our proposal on technical grounds, that's fine.
But keep in mind that compatibility with existing code, transition cost, etc.
are legitimate concerns applied in every other proposal writeup and we're
fully entitled to assert that this is a proposal of major cost to us. 

I think, too, we're within our rights to ask for a little respect from the
other members of CL-Cleanup when we assert such a position.

I personally would like to see the tighter definition you'd like to see,
but given the potential expenses involved, I see nothing disingenuous
about my having described the status quo as I did, and nothing
unreasonable about my having suggested that this is our only viable
alternative.

∂13-Dec-88  2201	CL-Cleanup-mailer 	Issue: CLOSE-CONSTRUCTED-STREAMS (not yet submitted)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88  22:01:18 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508246; Wed 14-Dec-88 01:00:33 EST
Date: Wed, 14 Dec 88 01:00 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOSE-CONSTRUCTED-STREAMS (not yet submitted)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <881205-121523-3921@Xerox>
Message-ID: <881214010015.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 5 Dec 88 12:14 PST
    From: masinter.pa@Xerox.COM
    ...

	What does it mean to CLOSE a composite stream ( broadcast two-way
    synonym
	concatenated) ? The choices I can think of are:
	a) no effect
	b) implementation dependent (ugh)
	c) closes constituent streams
	d) the composite stream is "closed" (no I/O operations allowed) but
		the constituents are not.

    I prefer c.

There is another possibility:
 e) signals an error
I can't think of any reason why a Common Lisp program ever needs to call
CLOSE on a composite stream. Can someone suggest a legitimate case where
you wouldn't instead close the underlying stream?

My preferences are, in order of diminishing preference:

(e) is my preference unless someone cites a screw case.

(c) seems certainly justifiable. it -could- be an incompatible change for
    some implementations, i suppose. it makes more sense for things like
    broadcast streams (which are usually non-interactive) than it does
    for echo streams (which are sometimes interactive). Anything which
    might accidentally get mixed up with the terminal makes me nervous.
    I agree one shouldn't close terminal streams on purpose -- what I'm
    worried about is someone accidentally closing a terminal stream because
    of some indirection through a composite stream.

(d) is weird. i can't figure out what i think of it. it seems 
    counterintuitive and yet it probably wouldn't be harmful if it were
    well-defined that this was what it did.

(b) is the status quo, and technically requires no action though a 
    clarification wouldn't bother me. making things explicit is often
    a good idea.

(a) is neither the status quo nor does it sound very desirable to me.
    if there were any place where this was desirable in some non-trivial
    application, i'd be curious to hear about it.

	What does it mean to close a constructed stream (e.g., STRING)? 
	a) no effect
	b) implementation dependent (ugh)
	c) the constructed stream is "closed" (no I/O operations allowed).

    I prefer a or c.

I don't care which of (a) or (c) as long as it's clearly documented.
(c) would be more consistent with good programming hygeine, though might
have some [probably trivial] storage and/or execution efficiency impact
in some implementations.

(b) is the status quo, and technically requires no action though a 
    clarification wouldn't bother me. making things explicit is often 
    a good idea.

∂13-Dec-88  2207	CL-Cleanup-mailer 	Re: Issue ALIST-NIL  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Dec 88  22:07:44 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508251; Wed 14-Dec-88 01:07:03 EST
Date: Wed, 14 Dec 88 01:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue ALIST-NIL
To: masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, IIM@ECLA.USC.EDU
In-Reply-To: <881202-163852-131@Xerox>
Message-ID: <881214010647.0.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 2 Dec 88 16:36 PST
    From: masinter.pa@Xerox.COM

    ... Unless I hear otherwise (and I'll leave this open for Kent, who is on
    vacation until December 10 and may not read this until much later), I will
    mark this as Withdrawn. 

Agreed: withdrawn in favor of the suggested editorial advice.

∂13-Dec-88  2215	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Dec 88  22:15:52 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA06918g; Tue, 13 Dec 88 22:13:07 PST
Received: by bhopal id AA11940g; Tue, 13 Dec 88 22:15:07 PST
Date: Tue, 13 Dec 88 22:15:07 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812140615.AA11940@bhopal>
To: masinter.pa@Xerox.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 8 Dec 88 23:21 PST <881208-232139-5495@Xerox>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)

re: I'll add that I still prefer the proposal I outlined (awkwardly) in
    November 1987, which was neither explicitly-vague or explicitly-defined.
    The "sequence" functions:
      NREVERSE DELETE DELETE-IF DELETE-IF-NOT DELETE-DUPLICATES NSUBSTITUTE
      NSUBSTITUTE-IF NSUBSTITUTE-IF-NOT
    and the destructive set manipulation functions:
      NUNION NINTERSECTION NSET-EXCLUSIVE-OR
    should be explicitly-vague, but the others 
      SETF of GETF, REMF, SETF of GET, REMPROP, NCONC, NRECONC, NBUTLAST,
      NSUBST, NSUBST-IF, NSUBST-IF-NOT
    should be specified.

I think I prefer your version too, for essentially the reasons you
elucidated further in your msg.

-- JonL --

∂13-Dec-88  2241	CL-Cleanup-mailer 	Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Dec 88  22:41:23 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA06973g; Tue, 13 Dec 88 22:37:36 PST
Received: by bhopal id AA11971g; Tue, 13 Dec 88 22:39:35 PST
Date: Tue, 13 Dec 88 22:39:35 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812140639.AA11971@bhopal>
To: Gregor.pa@Xerox.COM
Cc: masinter.pa@Xerox.COM, pierson@mist.encore.com, Gray@DSG.csc.ti.com,
        cl-cleanup@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM's message of Sun, 11 Dec 88 10:45 PST <19881211184511.8.GREGOR@PORTNOY.parc.xerox.com>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 5) 

re: 
	My "compromise" proposal, that Gray seemed to agree to, was to insist
	that implementations which "hook" their REQUIRE into some  kind of 
	DEFSYSTEM -- as an implementation- specific extension -- must also 
	provide a special variable flag that disengages any such "hook-up".  
	While it is true that many people will persist in writing non-portable 
	code, the portable use of REQUIRE to ensure that required package 
	definitions are "already loaded in" is of paramount importance.  There
        is no other portable feature to help ensure that.

    I don't buy this.  You can do it portably with find-package and intern.
    You might claim that is gross, but I don't believe it.  . . . 

The point underlying this claim has been re-iterated several times during
the discussion of this issue, but let me try again.

  -- a REQUIRE used in an implementation that can hook into a defsystem
     will trigger that loading.  There is no portable way to do so now
     [doesn't matter that the hook merely errors out for implementations
     that don't have a defsystem, or for which the user failed to supply
     the appropriate database].  REQUIREs which supply explicit filenames
     are not portable -- that's precisely how this proposal got started.

  -- any REQUIRE is expression of intent on the part of the programmer.
     REQUIREs are in common usage around the community, and they are 
     especially useful in package "requirements".  All such expressions
     are portable.  

But I have no idea what you mean by suggesting that these usages of
REQUIRE can be replaced by some idiosyncratic usage of FIND-PACKAGE etc.

Incidentally, the point about "expression of intent" was said much
better by Larry last October:

    Date: 18 Oct 88 14:13 PDT
    From: masinter.pa@Xerox.COM
    Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (Version 3) 

    The thing that distinguishes PROVIDE and REQUIRE from their obvious
    implementations is that they have declarative rather than operative
    semantics. Program walkers, DEFSYSTEM constructors as well as compilers
    might be expected to pay special heed to PROVIDE and REQUIRE, but not pay
    any special heed to direct manipulation of *MODULES*.

    We should be careful in the standard to distinguish between what things
    mean and how they may be implemented, but doubly so in the case of macros
    and special forms that may get processed at times other than EVAL-time.


-- JonL --

∂14-Dec-88  0007	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 5)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Dec 88  00:06:56 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA07168g; Wed, 14 Dec 88 00:03:21 PST
Received: by bhopal id AA12044g; Wed, 14 Dec 88 00:05:20 PST
Date: Wed, 14 Dec 88 00:05:20 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812140805.AA12044@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: barmar@Think.COM, cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: David A. Moon's message of Tue, 13 Dec 88 11:52 EST <19881213165206.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)

re: . . . (EQ is only
    in Common Lisp as a concession to implementors who haven't figured out
    how to implement EQL efficiently (it isn't hard), or hadn't figured it
    out yet in 1984).

Hmmm, I may remember something similar said in the late 1960's or very
early 1970's about why EQ was still in the language -- but back then,
the contender was EQUAL rather than EQL.  Plus ca change . . . maybe
there is a more fundamental reason than incompotent implementors.  Like,
maybe some folks implement their memory management systems in Lisp, and
are reluctant to give up all user-accessibility to this historic, object
identity function?

But that's just a conjecture.  I really don't know why (and don't
particularly care why) EQ persists.


-- JonL --



∂14-Dec-88  0019	CL-Cleanup-mailer 	Issue: COERCE-INCOMPLETE (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Dec 88  00:19:33 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA07199g; Wed, 14 Dec 88 00:16:48 PST
Received: by bhopal id AA12063g; Wed, 14 Dec 88 00:18:48 PST
Date: Wed, 14 Dec 88 00:18:48 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812140818.AA12063@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 9 Dec 88 16:47 PST <881209-164733-1437@Xerox>
Subject: Issue: COERCE-INCOMPLETE (Version 2)

Wasn't there some hairy issue with ...-FUNCTION-... in it's name that
we discussed verbally at the June meeting?  and didn't we take a vote
there to ammend that issue by saying that 
    (COERCE '(LAMBDA ...) 'FUNCTION)
would be the way to go from list structure to a "real" function?

That didn't seem to be in your list of obvious candidates for COERCE
extension.

-- JonL --

∂14-Dec-88  0143	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 7)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Dec 88  01:43:09 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA07351g; Wed, 14 Dec 88 01:40:25 PST
Received: by bhopal id AA12144g; Wed, 14 Dec 88 01:42:24 PST
Date: Wed, 14 Dec 88 01:42:24 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812140942.AA12144@bhopal>
To: barmar@Think.COM
Cc: CL-CLEANUP@sail.stanford.edu
In-Reply-To: barmar@Think.COM's message of Sat, 10 Dec 88 15:57:29 EST <8812102057.AA18056@kulla.think.com>
Subject: Issue: DEFPACKAGE (Version 7)

re: . . .  How about this as an
    alternative to "at most the original package will be updated":
    "however, no objects other than the original package will be
    modified as a result."

Doesn't work -- by performing the newer definition, you may require links
to be modified in other packages' used-by lists.  

If this really is an insoluable problem for you, and if other people
also feel so uncomfortable with it, then maybe we should just flush
the whole phrase; after all, the primary things we want to say are that:
  (1) you don't change the name-to-package mapping, and
  (2) you *might* alter the existing package [then again, you might not].



re: . . . Kathy's proposal for
    the new classification system of error situations includes a
    description of this case.  As I said, I don't remember the actual
    terminology she used for this case (I suggested "undefined but
    benign", but she rejected it), but the description was like what you
    described.

Hmmm, well I'm not familiar with this yet newer error terminology proposal.


-- JonL --

∂14-Dec-88  0208	CL-Cleanup-mailer 	Please add me to the cl-cleanup mailing list  
Received: from RELAY.CS.NET (GW1.CS.NET) by SAIL.Stanford.EDU with TCP; 14 Dec 88  02:08:14 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac00167; 14 Dec 88 4:55 EST
Received: from etl.jp by RELAY.CS.NET id ac03458; 14 Dec 88 4:49 EST
Received: by etlcom.etl.junet (3.2/6.3Junet-1.0)
	id AA02955; Wed, 14 Dec 88 13:25:06 JST
Date: Wed, 14 Dec 88 13:25:06 JST
From: Haruyuki Kawabe <kawabe@etl.jp>
To: cl-cleanup@SAIL.STANFORD.EDU
Subject: Please add me to the cl-cleanup mailing list

 Please add mlist%unisys.junet@uunet.uu.net to the cl-cleanup mailing list.
 Thanks in advance.

	Haruyuki Kawabe
	Knowledge Systems
	Nihon Unisys, Ltd.
	2-17-51 Akasaka, Minato-ku, 
	Tokyo 107, JAPAN  
	e-mail: kawabe%etl.jp@relay.cs.net

∂14-Dec-88  1037	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 5)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Dec 88  10:37:26 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 508548; Wed 14-Dec-88 13:35:49 EST
Date: Wed, 14 Dec 88 13:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)
To: Jon L White <jonl@lucid.com>
cc: barmar@Think.COM, cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: <8812140805.AA12044@bhopal>
Message-ID: <19881214183553.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: Wed, 14 Dec 88 00:05:20 PST
    From: Jon L White <jonl@lucid.com>

    re: . . . (EQ is only
	in Common Lisp as a concession to implementors who haven't figured out
	how to implement EQL efficiently (it isn't hard), or hadn't figured it
	out yet in 1984).

    Hmmm, I may remember something similar said in the late 1960's or very
    early 1970's about why EQ was still in the language -- but back then,
    the contender was EQUAL rather than EQL.  Plus ca change . . . maybe
    there is a more fundamental reason than incompotent implementors.  

Just to clarify what I meant, since as usual I didn't express myself
very clearly in the initial message: I think of EQL as the
implementation-independent version of EQ.  The behavior of EQ is
different from EQL only in implementation-dependent situations that
portable programs are not supposed to depend on.  This is very different
from EQUAL, which is a semantically different operation in a way that
is meaningful across all implementations.

								       Like,
    maybe some folks implement their memory management systems in Lisp, and
    are reluctant to give up all user-accessibility to this historic, object
    identity function?

Could be.  But I claim that EQ has no portable meaning distinct from EQL,
only an implementation-dependent meaning, so that indeed we should be speaking
in terms of "reluctance" rather than "semantics".

Anyway, that's more than enough time on that side-issue.

∂14-Dec-88  1157	X3J13-mailer 	Issue: PACKAGE-CLUTTER (Version 6)  
Received: from goldhill.com ([128.168.1.211]) by SAIL.Stanford.EDU with TCP; 14 Dec 88  11:56:23 PST
Received: by goldhill.com; Wed, 14 Dec 88 14:55:55 EST
Date: Wed, 14 Dec 88 14:55:55 EST
From: rpk@goldhill.com (Robert Krajewski)
Message-Id: <8812141955.AA16807@goldhill.com>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: cl-cleanup@sail.stanford.edu's message of 12 Dec 88 13:44 PST <881212-134536-5049@Xerox>
Subject: Issue: PACKAGE-CLUTTER (Version 6)

I just noticed two problems in this paragraph:

  A valid implimentation may have or put additional properties
  on symbols (even user created symbols) as long as the
  property indicators are not in the LISP, KEYWORD or USER
  package.

1. The spelling of the third word.

2. It should be OK for an implementation to use property list indicators
that are *internal* symbols in the LISP package.  (Of course, the ``internal''
concept doesn't make sense, really, for keywords, and internal USER symbols
are the most common kind.)

∂15-Dec-88  1315	CL-Cleanup-mailer 	Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)     
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88  13:15:16 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00434g; Thu, 15 Dec 88 13:11:36 PST
Received: by bhopal id AA19775g; Thu, 15 Dec 88 13:13:34 PST
Date: Thu, 15 Dec 88 13:13:34 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812152113.AA19775@bhopal>
To: pierson@mist.encore.com
Cc: IIM@ECLA.USC.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Dan L. Pierson's message of Mon, 12 Dec 88 11:34:39 EST <8812121634.AA10750@mist.>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3) 

re: In both cases, the status quo
    allows careful programmers to write portable code as in:

	- Never adjust a "non-adjustable" array
	- Never use REQUIRE in a context that would cause file loading

    The, quite legitimate, objection to the status quo is that it makes it
    _very_ likely that programmers, being human and fallible, will
    accidently wind up producing non-portable code because the current
    versions of these features lack adaquate (read any) portable error
    checking. 

The problem with the Symbolics implementation (as conveyed to us by
those inside symbolics) is that there is *** no place available ***
in an array to remember the :adjustable option.  Hence it is not a
trivial option for them to accommodate to the "Lucid status quo".

However, the "compromise" proposal for REQUIRE would expose a global 
variable to make inhibition of vendor-specific extensions possible.
This would be trivial in anybody's implementation.


-- JonL --

∂15-Dec-88  1358	CL-Cleanup-mailer 	Issue: HASH-TABLE-KEY-MODIFICATION (and HASH-TABLE-STABILITY)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88  13:58:42 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00508g; Thu, 15 Dec 88 13:55:44 PST
Received: by bhopal id AA19863g; Thu, 15 Dec 88 13:57:41 PST
Date: Thu, 15 Dec 88 13:57:41 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812152157.AA19863@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 12 Dec 88 11:50 PST <881212-115107-4697@Xerox>
Subject: Issue: HASH-TABLE-KEY-MODIFICATION (and HASH-TABLE-STABILITY)

re: I did see a piece of a message from Jeff Dalton included in your response
    to him, but I'm missing his original message. I presume that they were not
    mailed to cl-cleanup.

Both of Jeff's comments were CC'd to cl-cleanup.  Since you included Moon's
negative comments in the mailing to x3j13, shouldn't Jeff's comments be
included too?


  Date: Thu, 17 Nov 88 17:17:09 GMT
  From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
  Subject: Re: Issue: HASH-TABLE-STABILITY (version 1)
  To: Jon L White <@sail.stanford.edu:jonl@lucid.com>,
	  cl-cleanup@sail.stanford.edu
  In-Reply-To: Jon L White's message of Mon, 14 Nov 88 23:14:43 PST

  Well said.  I can think of one "problem": you have specified the
  constraints relating the :test and the key transformation so well
  that it no longer seems reasonable that users are not able to provide
  their own :test and key transformation.

  -- Jeff

  Date: Sat, 19 Nov 88 21:35:47 GMT
  From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
  Subject: Re: Issue: HASH-TABLE-STABILITY (version 1)
  To: jonl <@sail.stanford.edu:jonl@lucid.com>, cl-cleanup@sail.stanford.edu
  In-Reply-To: Jon L White's message of Fri, 18 Nov 88 15:19:52 PST

  > re: Well said.  I can think of one "problem": you have specified the
  >     constraints relating the :test and the key transformation so well
  >     that it no longer seems reasonable that users are not able to provide
  >     their own :test and key transformation.
  > 
  > That would be superb, if Joe Random User were able to understand this
  > "clarification".  I agree that that may be the only thing lacking for 
  > fully extensible hash-tables.

  There are many things in Lisp that users may not understand initially
  and so may get wrong.  I don't think that's necessarily a good reason
  to keep something out of the language.  (And if it were, there are
  parts of CLOS, SETF, and packages that we would want clean out.)

  BTW, Pop11 allows user-specified test and hash (key transform)
  functions.

  -- Jeff

∂15-Dec-88  1444	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 5) 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88  14:40:09 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00550g; Thu, 15 Dec 88 14:37:16 PST
Received: by bhopal id AA19979g; Thu, 15 Dec 88 14:39:13 PST
Date: Thu, 15 Dec 88 14:39:13 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812152239.AA19979@bhopal>
To: alarson@src.honeywell.com
Cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: Aaron Larson's message of Tue, 13 Dec 88 17:06:12 CST <8812132306.AA11821@pavo.src.honeywell.com>
Subject: Issue: PACKAGE-DELETION (Version 5)

re: ....
	  If the designated package is used by other packages, a correctable
	  error is signalled. ...

    "continuable error"

Yes, "continuable".  If there is to be another version, it can be changed.


re:	  After this operation completes, the contents of the symbol-package  
	  slot of any symbol homed in the deleted package is unspecified; ...

    symbol S homed in pkg P == (eq P (symbol-package S)) ?

A symbol's "home" package is defined to be the contents of its
symbol-package cell.  See CLtL p.175 (about middle of page).

-- JonL --

∂15-Dec-88  1515	CL-Cleanup-mailer 	Issue: PACKAGE-DELETION (Version 5) 
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 15 Dec 88  15:15:17 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)
	id AA25319; Thu, 15 Dec 88 17:14:00 CST
Posted-Date: Thu, 15 Dec 88 17:12:20 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
	id AA16934; Thu, 15 Dec 88 17:12:20 CST
Date: Thu, 15 Dec 88 17:12:20 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8812152312.AA16934@pavo.src.honeywell.com>
To: jonl@lucid.com
Cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: Jon L White's message of Thu, 15 Dec 88 14:39:13 PST <8812152239.AA19979@bhopal>
Subject: Issue: PACKAGE-DELETION (Version 5)

   Posted-Date: Thu, 15 Dec 88 14:39:13 PST
   Date: Thu, 15 Dec 88 14:39:13 PST
   From: Jon L White <jonl@lucid.com>
   re:	  After this operation completes, the contents of the symbol-package  
	     slot of any symbol homed in the deleted package is unspecified; ...

       symbol S homed in pkg P == (eq P (symbol-package S)) ?

   A symbol's "home" package is defined to be the contents of its
   symbol-package cell.  See CLtL p.175 (about middle of page).

I guess I should have been more carefull in my statement.  The problem I
was raising is that being "homed" is a satement about the symbol-package of
a symbol (and the fact that "homed" is slang), and stating that
(symbol-package x) being the deleted package and being undefined is
contradictory.  The fact that you are stating something about the (previous)
state of the symbol-packge, and that kill-package may (or may not) change
the symbol-package was being muddled.  In retrospect it was undoubtedly
obvious to everybody what the statement meant.

∂15-Dec-88  2136	CL-Cleanup-mailer 	Issue: TAILP-NIL (Version 5)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88  21:36:13 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00886g; Thu, 15 Dec 88 21:33:11 PST
Received: by bhopal id AA20798g; Thu, 15 Dec 88 21:35:11 PST
Date: Thu, 15 Dec 88 21:35:11 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812160535.AA20798@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Tue, 13 Dec 88 19:05 EST <881213190509.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 5)

re:    I, for one, have found that nearly every time I think LDIFF would
       suffice, the EQL test (rather than EQUAL), and its failure to take
       a test argument, has screwed me -- causing me to do what I have always
       felt is needless rewrite. I have only rarely needed TAILP and I can't
       remember if I ended up actually using it or not -- I'd suspect that
       the constraints on it make it next to useless.

This paragraph provides proof in substance of one of the reasons for
wanting to toss out TAILP, namely

   (1) the "test" questions is at least as complex as for defining
       EQUAL -- and we never did come to agreement about that;

It would only be sheer conjecture that the currently unused TAILP
would become generally useful if it were extended to take a :test
argument.   By the reasoning in your note, you don't believe we have
any way to evaluate this kind of question; you say:
    ``. . . we have no way of evaluating what it
       means for the operator to be "used a lot"''


-- JonL --

∂15-Dec-88  2203	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 5) 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 15 Dec 88  22:03:41 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00902g; Thu, 15 Dec 88 22:00:41 PST
Received: by bhopal id AA20824g; Thu, 15 Dec 88 22:02:42 PST
Date: Thu, 15 Dec 88 22:02:42 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812160602.AA20824@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 13 Dec 88 20:59 EST <19881214015936.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT (Version 5)

I wanted to recommend against accepting this proposal in its current
format; it looked like to me that a lot more work was needed to make
it both accurate and comprehensible.  Since I don't have the time to
work one it before the January meeting, I won't be able to explain
my objections in much better detail (without, in fact, going to the
trouble to prepare the necessary revised proposal, which I don't
have time to do!)

What would you like to see happen?  If you think you can do it in time 
before the January meeting, could you _please_ make the revision, and
mail that out?  to X3J13 as well?


-- JonL --

∂16-Dec-88  0108	CL-Cleanup-mailer 	Really about the ontology of EQ {Issue: TAILP-NIL (Version 5)}    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Dec 88  01:07:55 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00962g; Fri, 16 Dec 88 01:04:33 PST
Received: by bhopal id AA20981g; Fri, 16 Dec 88 01:06:32 PST
Date: Fri, 16 Dec 88 01:06:32 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812160906.AA20981@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: barmar@Think.COM, cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: David A. Moon's message of Wed, 14 Dec 88 13:35 EST <19881214183553.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Really about the ontology of EQ {Issue: TAILP-NIL (Version 5)}

re: Just to clarify what I meant, since as usual I didn't express myself ...

Well me too (i.e. I wasn't as clear as possible).   [Incidentally,
although this topic is only remotely connected to TAILP-NIL, it
seems to be central the to abortive attempt to "clean up" the
EQUAL predicate.  Hence, I drone on some more. ...]

The issue "way back when" wasn't whether EQUAL would be portable and EQ
not portable (since "pdlnums" hadn't even been thought of then), but 
rather whether or not a programmer should be allowed to find out if two
"equivalent" pieces of data are stored in the same location.  The Lisp 
1.5 definition of EQ was "EQUAL, on atoms (meaning, symbols)".  I suppose 
the explanations about "update semantics" forced the hand of those who 
wanted to flush EQ back then.  That is, an EQUAL but non-EQ copy of a cons 
cell wouldn't show the results of updates applied to the original cell.
This kind of analysis is probably more interesting to a pure functional 
programming type, or to a data-flow type person.

Now, as the the EQ/EQL purpose: Interlisp used to have a function called
SETN, which would actually modify the contents of a number "box" --
thus it made sense for Interlisp to have both EQ and EQL (it was called
EQP in Interlisp), to be able to choose whether such updates are to be
considered important.  Of course, Common Lisp has no updators for numbers
or characters -- only new constructors (which is why SETF of LDB is so
complicated) -- so the only conceivable use now for distinguishing EQ
and EQL is explicit storage management.

   (setq pi 3.14159265) ==> 3.14159265
   pi                   ==> 3.14159265
   (setq saved-pi pi)   ==> 3.14159265
   ;; the "Tennessee Patch", in Interlisp-10 code
   (setn pi 3.0)        ==> 3.0
   pi                   ==> 3.0
   (eq pi saved-pi)     ==> T


-- JonL --

∂16-Dec-88  0838	CL-Cleanup-mailer 	EQ    
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 16 Dec 88  08:37:45 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa19006; 16 Dec 88 10:56 EST
Received: from draper.com by RELAY.CS.NET id ad00211; 16 Dec 88 10:49 EST
Date: Fri, 16 Dec 88 07:59 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: EQ
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525

re: The only purpose for retaining EQ as opposed to EQL is storage management,
    or words to that effect...
 
The basic reason for the existence of EQ, as I see it, is to compare interned
symbols.  LISP is a symbol processing language primarily because the comparison
of non-arithmetic quantities is optimized by insuring that the expensive part
is done at symbol creation time (i.e. interning) and all subsequent tests are
very fast (address comparisons).  Now, it is true that EQL on symbols is the
same as EQ, so EQ per se is unnecessary.  But isn't it preferable to retain EQ
so that the compiler can generate the very fast inline operation for EQ instead
of (possibly, depending on the implementation) having to invoke an out-of-line
routine or a longer sequence of inline code to compare two things using EQL?
If neither operand is a constant or a type-declared variable or function call,
it is not known whether the EQL call may be optimized into an EQ call.  (This
is probably not a problem for your implementation, JonL, or for many others',
but it may be for others - it is for mine.)  

∂16-Dec-88  1101	CL-Cleanup-mailer 	Really about the ontology of EQ {Issue: TAILP-NIL (Version 5)}    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Dec 88  11:01:45 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01270g; Fri, 16 Dec 88 10:55:17 PST
Received: by bhopal id AA21626g; Fri, 16 Dec 88 10:57:15 PST
Date: Fri, 16 Dec 88 10:57:15 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8812161857.AA21626@bhopal>
To: jonl@lucid.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, barmar@Think.COM,
        cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: Jon L White's message of Fri, 16 Dec 88 01:06:32 PST <8812160906.AA20981@bhopal>
Subject: Really about the ontology of EQ {Issue: TAILP-NIL (Version 5)}

   ;; the "Tennessee Patch", in Interlisp-10 code
   (setn pi 3.0)        ==> 3.0

I thought it was Indiana that passed that law.

  jlm

∂17-Dec-88  0118	CL-Cleanup-mailer 	EQ    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Dec 88  01:18:15 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01901g; Sat, 17 Dec 88 01:15:22 PST
Received: by bhopal id AA23281g; Sat, 17 Dec 88 01:17:22 PST
Date: Sat, 17 Dec 88 01:17:22 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812170917.AA23281@bhopal>
To: SEB1525@draper.com
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: "Steve Bacher (Batchman)"'s message of Fri, 16 Dec 88 07:59 EST <8812161638.AA01151@lucid.com>
Subject: EQ

re: If neither operand is a constant or a type-declared variable or function 
    call, it is not known whether the EQL call may be optimized into an EQ 
    call.  (This is probably not a problem for your implementation, JonL, or 
    for many others', but it may be for others - it is for mine.)  

I think that's a universal problem, but not a particularly serious one.
Of course, Lucid's Production-Quality compiler makes all the obvious type 
optimizations; but for EQL, it also does an in-line check for EQ success 
before calling EQL out-of-line.  (Vax/NIL used to do a bit more on EQUAL, 
based on monitoring some MACSYMA code; but that was before EQL came about).

I have often referred to these kinds of tricks as "beating out the function 
call" -- namely, a fast, in-line, fail-safe, but not complete test which is 
performed just before taking the time to go out-of-line.  I think Richard 
Fateman of UCB independently discovered "beating out the function call" on 
EQUAL -- for exactly the same reason (tuning the performance of Vaxima).

Internally, Lucid code ocasionally makes use of (optimizable) functions
named EQ-FOR-EQL-P and EQ-FOR-EQUAL-P; typically they are used to select
one of two alternative methods;  e.g., ASSOC can dynamically turn into
ASSQ.  These checks "open compile".  So the time to make the determination
pays off immensely in the one case by reducing out-of-line calls, and in
the other case, the out-of-line calls are so costly that the check time
is negligible.  It wouldn't matter whether or not EQ were part of the 
portable standard -- these tricks would still be applicable to the way in 
which the system internals and compiler output work.

A good point to make for retention of EQ is that even though portable
code may not be able to utilize the difference between EQ and EQL, it
will still be the case that every implementation will have *some*
function that does address/pointer identity comparison; so we might as 
well all call it the same thing, so as to minimize the culture shock when
moving from one implementation to another.


-- JonL --

∂17-Dec-88  1338	CL-Cleanup-mailer 	Re: EQ
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 17 Dec 88  13:37:59 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa04738; 17 Dec 88 19:10 GMT
Date: Sat, 17 Dec 88 19:23:01 GMT
Message-Id: <9194.8812171923@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: EQ
To: Jon L White <@sail.stanford.edu:jonl@lucid.com>, 
    SEB1525%draper.com@NSS.Cs.Ucl.AC.UK
In-Reply-To: Jon L White's message of Sat, 17 Dec 88 01:17:22 PST
Cc: cl-cleanup@sail.stanford.edu

> A good point to make for retention of EQ is that even though portable
> code may not be able to utilize the difference between EQ and EQL, it
> will still be the case that every implementation will have *some*
> function that does address/pointer identity comparison; so we might as 
> well all call it the same thing, so as to minimize the culture shock when
> moving from one implementation to another.

Just so.  While portable code is more important, I don't think we should
discount non-protable code completely.  And I don't think we should force
people to write only portable code.  Besides, using EQ in a portable way
is generally easier than using declarations.

I realize that CL has gone a different way with the generic arithmetic
functions, but the two cases are not identical.  If necessary, I suppose
a more elaborate justification for EQ could be attempted, but is there any
great harm to keeping EQ?

∂20-Dec-88  1710	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 5) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Dec 88  17:09:53 PST
Received: from KENNETH-WILLIAMS.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 510806; 20 Dec 88 20:08:36 EST
Date: Tue, 20 Dec 88 20:14 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT (Version 5)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8812160602.AA20824@bhopal>
Message-ID: <19881221011406.6.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>

    Date: Thu, 15 Dec 88 22:02:42 PST
    From: Jon L White <jonl@lucid.com>

    I wanted to recommend against accepting this proposal in its current
    format; it looked like to me that a lot more work was needed to make
    it both accurate and comprehensible.  

I agree with that for version 5.  I'm not sure whether I agree with that
for the earlier versions, I would have to go back and re-read them.

					  Since I don't have the time to
    work on it before the January meeting, I won't be able to explain
    my objections in much better detail (without, in fact, going to the
    trouble to prepare the necessary revised proposal, which I don't
    have time to do!)

    What would you like to see happen?  If you think you can do it in time 
    before the January meeting, could you _please_ make the revision, and
    mail that out?  to X3J13 as well?

I'd help if I could, but I cannot revise the proposal in its current
two-proposal form, because I cannot think of any coherent, unambiguous,
implementation-independent way to say what I think the second proposal is
trying to say.  At this point it wouldn't surprise me if it turns out to be
impossible to specify it in any acceptable way.  If someone else can come
up with it, fine, I'd love to be proved wrong.

If that doesn't happen, I'd like to see either the first proposal (the one
that ends the dynamic extent of an exit sooner) accepted or retain the
status quo.  I think the status quo, which is vague, ambiguous, and
incoherent, would still be better than adopting a new proposal that (I
feel) is still ambiguous and incoherent, and at the same time is
incompatible with current practice.  As I commented earlier, I think
version 5 of the second proposal (the one that ends the dynamic extent of
an exit later) is in fact incompatible with all current implementations,
and may not be implementable at all.  I don't think that was what was
intended, but even what was probably intended is incompatible with some
current implementations (Genera is the one I know about).

∂22-Dec-88  1127	CL-Cleanup-mailer 	Issue: LISP-PACKAGE-NAME (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Dec 88  11:27:34 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 511418; Thu 22-Dec-88 14:03:31 EST
Date: Thu, 22 Dec 88 14:03 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-PACKAGE-NAME (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881222140316.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

Issue:        LISP-PACKAGE-NAME
References:   11.6 Built-in Packages (pp181-182)
Category:     CHANGE
Edit history: 22-Dec-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  Since ANSI Common Lisp will differ from the Common Lisp described by CLtL,
  it will not be possible to have support for both in the same Lisp image
  if ANSI Common Lisp insists on placing its functionality in the package
  named LISP.

  Further, use of the name unqualified name LISP by the ANSI Common Lisp
  community is inconsistent with ANSI's expressed position to ISO that 
  the term "LISP" names a language family rather than a specific dialect
  within that family.

Proposal (LISP-PACKAGE-NAME:COMMON-LISP):

  Define that ANSI Common Lisp uses the package name COMMON-LISP, not LISP.
  Define that the COMMON-LISP package has nickname CL.

  Since some symbols (e.g., T, NIL, and LAMBDA) might have to be shared
  between COMMON-LISP and LISP in implementations simultaneously supporting
  both, clarify that the initial symbols specified by ANSI Common Lisp as
  belonging in the COMMON-LISP package need not have a home package of 
  Common-Lisp.

Test Case:

  In an implementation supporting CLtL's LISP package and 
  the ANSI Common Lisp CL package proposed here:

  (EQ 'LISP:T 'CL:T)
  => not specified, due to this proposal, but probably T

  (EQ 'LISP:CAR 'CL:CAR)
  => not specified, due to this proposal, but probably T

  (EQ 'LISP:FUNCTIONP 'CL:FUNCTIONP)
  => not specified, due to this proposal, but since FUNCTIONP is
     changed incompatibly between CLtL (LISP) and CL (ANSI), there
     are good reasons why this might return NIL.

  (SYMBOL-PACKAGE 'CL:T)
  => not specified, due to this proposal. Perhaps #<Package CL>, 
     perhaps #<Package LISP>, or perhaps something implementation-specific.

  (SYMBOL-PACKAGE 'LISP:T)
  => not specified, not due to this proposal, but because CLtL didn't
     specify this explicitly.

Rationale:

  In practice, some implementations will have very legitimate reasons for 
  wanting to Lisp dialects to be coresident. As it stands, they will have
  little other choice than to make the two use different packages, and so
  will be forced to be incompatible with one or the other dialect unless
  we choose a different package name for the one dialect for which there
  is currently no existing code.

  Not only is this important the CLtL and ANSI Common Lisp communities, but
  also, if we continue to use the name LISP, it sends a signal to the ISO
  Lisp community that the "latest and greatest" Lisp should use the generic
  name LISP, and they may try to use it as well. If ISO Lisp turns out to
  be very different than ANSI Common Lisp, there may be motivation down the
  line for having ISO Lisp and ANSI Common Lisp co-resident, and conflicts
  will inevitably arise if both want to use the name LISP. This will almost
  certainly lead to a confrontation where one Lisp dialect tries to force
  the other out by the artificial means of asserting its right to this
  generic name. Choosing a name which compatibly admits the option of
  introducing other dialects into the environment at a later date without
  conflict is a good way to avoid a class of potential problems.

  Although there are a few problems which could come up due to the symbol
  package of initial symbols being unspecified, experience with 
  implementations that do this suggests that they are very few.
  Problems occur only in the rare circumstance that all of the following
  conditions are met:

   - A symbol S on the LISP package but with home package H (that is not "LISP")
     is shadowed in some package P of implementation A.

   - A program F in package P uses the shadowed symbol H:S by an explicit
     LISP: or H: package qualification. (Only the case of using "LISP:" is
     interesting, of course, since if H were named explicitly, we would be
     outside the bounds of portable code).

   - The program F, referring to H:S, is printed out in implementation A 
     while using package P (or some other package that shadows S, so that
     the H package qualifier appears explicitly) and an attempt is made to
     re-read it in implementation B.

   - Implementation B has no package named H, has a package named H but no
     external symbol named S, or has a package named H with external symbol
     S but the symbol H:S has different semantics in implementation B than
     it did in implementation A.

  In practice, this hardly ever happens. It would happen even less if 
  programmers were explicitly alerted that it was a potential problem they
  needed to guard against.

Current Practice:

  Symbolics Genera already has a package named COMMON-LISP with nicknames
  CL and LISP. As such, this would be an incompatible change for Genera.

Cost to Implementors:

  Small.

  In some cases, this may even have `negative cost' because it will provide
  implementors a way of avoiding incompatible changes to released operators.

Cost to Users:

  Small.

  In some cases, this may even have `negative cost' because existing code
  would be able to continue to run in implementations which chose to support
  both CLtL's LISP and ANSI Common Lisp's CL packages, thereby allowing
  developers to put off a massover changeover, perhaps doing the transition
  more incrementally.

Cost of Non-Adoption:

  Implementations trying to support multiple dialects in the same environment
  would be forced to violate one or the other spec.

  Worse, different implementations faced with the same set of hard choices
  about which spec to violate in order to concurrently support two dialects
  might not make the same choices, leading to even more gratuitous 
  incompatibility.

  ANSI's position in ISO that we are not trying to legislate the meaning of
  -the- LISP dialect would be weakened.

Benefits:

  Needless incompatibility would be avoided in a variety of situations.

Aesthetics:

  Failing to specify the home package of symbols in the LISP and CL packages
  seems unaesthetic because it appears to diminish print/read invertability,
  but as observed above, that case is rare.

  Failiing to specify a way in which lisp dialects can be co-resident is also
  unaesthetic because in practice implementors with a need to do this will do
  so whether the standard allows them or not, and it will be a source of 
  severe divergence among implementations.

Discussion:

  Symbolics Genera offers two co-resident dialects of Lisp: Zetalisp and
  Symbolics Common Lisp. The Symbolics Cloe development environment adds
  a third co-resident dialect, making an environment in which two differing
  Common Lisp dialects (Symbolics Common Lisp and Cloe) must cooperate.
  Already in Cloe it is not possible for the home package to contain 
  package "LISP" since Cloe's concept of what the "LISP" package is differs
  from Genera's concept of what the "LISP" package is, yet they are forced
  by efficiency constraints to share the same symbol. It is Pitman's belief,
  based on extensive experience with Cloe, that failure to pass this proposal
  (or something very like it) will lead to all sorts of trouble for Common
  Lisp users and implementors down the road.

  Pitman strongly supports this proposal.

∂22-Dec-88  1350	CL-Cleanup-mailer 	Re: Issue: LISP-PACKAGE-NAME (Version 1) 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 22 Dec 88  13:49:53 PST
Received: by ti.com id AA09673; Thu, 22 Dec 88 15:48:59 CST
Received: from Kelvin by tilde id AA24814; Thu, 22 Dec 88 15:35:10 CST
Message-Id: <2807818509-4565574@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 22 Dec 88  15:35:09 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU, X3J13@DSG.csc.ti.com
Subject: Re: Issue: LISP-PACKAGE-NAME (Version 1)
In-Reply-To: Msg of Thu, 22 Dec 88 14:03 EST from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

> Proposal (LISP-PACKAGE-NAME:COMMON-LISP):
> 
>   Define that ANSI Common Lisp uses the package name COMMON-LISP, not LISP.
>   Define that the COMMON-LISP package has nickname CL.
> 
>   Since some symbols (e.g., T, NIL, and LAMBDA) might have to be shared
>   between COMMON-LISP and LISP in implementations simultaneously supporting
>   both, clarify that the initial symbols specified by ANSI Common Lisp as
>   belonging in the COMMON-LISP package need not have a home package of 
>   Common-Lisp.

I like this.  I wonder, though, if you might want to add that it would be
permissible for implementations to define "LISP" as a nickname for this
package, for the sake of backwards compatibility in new implementations
that wouldn't otherwise have a "LISP" package?

> Cost to Implementors:
> 
>   Small.
> 
>   In some cases, this may even have `negative cost' because it will provide
>   implementors a way of avoiding incompatible changes to released operators.

I agree; this approach will make it much easier for us to support the
standard with minimal incompatibility for existing programs.  Trying to
support Zetalisp and Common Lisp sharing the same LISP package has been
enough of a headache without having to try to support two dialects of
Common Lisp that way.

Now we just need something in the *FEATURES* list to enable easy
distinction between standard-conforming and pre-standard implementations.

∂22-Dec-88  1545	CL-Cleanup-mailer 	Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Dec 88  15:45:39 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 511675; 22 Dec 88 18:44:30 EST
Date: Thu, 22 Dec 88 18:44 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881222184414.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

Michael Greenwald at Symbolics raised this issue on the Common-Lisp
mailing list. I ran this proposal draft by him. He agrees the writeup
expresses the issue he was trying to raise, and he says he has no
preference for which of the two proposals is adopted.  He just wants
us to take some definitive position so he'll know what to implement
for Genera. He asked not to be cc'd in the mail from this point out.
 -kmp

-----
Issue:        BACKQUOTE-COMMA-ATSIGN-DOT-COMMA
Forum:	      Cleanup
References:   Back quote (pp349-351)
Category:     CLARIFICATION/CHANGE
Edit history: 22-Dec-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  The consistent description of backquote has been disrupted by 
  recent changes in the semantics of APPEND.

  The description at the bottom of p350 suggests that
  `(foo ,@bar) can be legitimately interpreted as any of
  #1: (list* 'foo bar)
  #2: (append (list 'foo) bar)
  #3: (append (list 'foo) bar '())
  Unfortunately, issue APPEND-DOTTED has disrupted the equivalences
  here because if BAR holds a dotted list, #1 and #2 are the same (they
  preserve the `dotted cdr'), but #3 is different (it replaces the
  `dotted cdr' with NIL). Under CLtL, a dotted list given to APPEND was
  an error, so this case did not come up. But since ANSI CL will not make
  this an error, this ambiguity must be resolved.  

Proposal (BACKQUOTE-COMMA-ATSIGN-DOT-COMMA:DIVERGENT):

  Define that `(x1 ... xM . ,xN) is equivalent to (LIST* x1 ... xN).
  The actual (EQL) object xN will be used without copying in the result.
  The result itself might not be a proper list (e.g., if xN is an
  atom or dotted list).

  Define that `(x1 ... xM ,@xN) is equivalent to 
  (APPEND (LIST 'x1) ... (list 'xM) xN '()).
  Any top-level list structure of the object xN will be copied in the
  result, replacing (CDR (LAST xN)) with NIL (or replacing xN itself
  with NIL if xN is an atom and issue APPEND-ATOM passes).

Proposal (BACKQUOTE-COMMA-ATSIGN-DOT-COMMA:INTERCHANGEABLE):

  Define that `(x1 ... xM . ,xN) is equivalent to (LIST* x1 ... xN).
  The actual (EQL) object xN will be used without copying in the result.
  The result itself might not be a proper list (e.g., if xN is an
  atom or dotted list).

  Define that `(x1 ... xM ,@xN) is equivalent to 
  (APPEND (LIST 'x1) ... (list 'xM) xN).
  The actual (EQL) object xN will be used without copying in the result.
  The result itself might not be a proper list (e.g., if xN is an
  atom or dotted list).

Notes:

  Note well that this has implications which go beyond dotted lists.
  Currently, `(FOO ,@X) may be implemented by either
     (LIST* 'FOO X)
  or (APPEND (LIST 'FOO) X '())
  or (APPEND (LIST 'FOO) X)
  A consequence of the proposals above is to distinguish between
  the two APPEND cases, forcing changes in the side-effect behavior
  of backquoted structures currently exhibited by some implementations.

Test Cases:

  ;; Issue #1: Non-side-effect treatment of dotted lists.
  (LET ((DOTTED (LIST* 'A 'B 'C)))
    (VALUES `(FOO ,@DOTTED)
	    `(FOO . ,DOTTED)))
  
  => (FOO A B),      (FOO A B . C)		;under proposal DIVERGENT
  => (FOO A B . C),  (FOO A B . C)		;under proposal INTERCHANGEABLE

  ;; Issue #2a: Side-effects
  ;; Sometimes called the ``Standard Backquote Screw''
  ;; Structure is unintentionally shared.
  (LET ((TAIL1 (LIST 'A 'B 'C))
	(TAIL2 (LIST 'A 'B 'C)))
    (FLET ((GET-XABC-COMMA-ATSIGN () `(X ,@TAIL1))
	   (GET-XABC-DOT-COMMA    () `(X . ,TAIL2)))
      (LET ((TEMP1 (GET-XABC-COMMA-ATSIGN))
	    (TEMP2 (GET-XABC-DOT-COMMA)))
	(SETF (CADDR TEMP1) 'Z)
	(SETF (CADDR TEMP2) 'Z)
	(VALUES TEMP1 (GET-XABC-COMMA-ATSIGN)
		TEMP2 (GET-XABC-DOT-COMMA)))))
  => (X A Z C), (X A B C), (X A Z C), (X A Z C) ;under proposal DIVERGENT
  => (X A Z C), (X A Z C), (X A Z C), (X A Z C) ;under proposal INTERCHANGEABLE

  ;; Issue #2b: Side-effects
  ;; Sometimes called ``Inverse Backquote Screw''
  ;; Structure is unintentionally copied.
  (LET ((VAR 'X)
	(VAL '7)
	(THE-SETQ-TAIL (LIST NIL NIL)))
    (LET ((COMMA-ATSIGN `(SETQ ,@THE-SETQ-TAIL))
	  (DOT-COMMA    `(SETQ . ,THE-SETQ-TAIL)))
      (SETF (CAR  SETQ-TAIL) VAR)
      (SETF (CADR SETQ-TAIL) VAL)
      (VALUES COMMA-ATSIGN DOT-COMMA)
  => (SETQ NIL NIL), (SETQ X 7)			; under proposal DIVERGENT
  => (SETQ X 7),     (SETQ X 7)			; under proposal INTERCHANGEABLE

Rationale:

  This clarifies an ambiguity in the description of the language which was caused
  by issue APPEND-DOTTED and APPEND-ATOM.

  Although CLtL tries not to specify the sharing and side-effect implications
  of backquote, there is no really principled reason for its failure to do so.
  In practice, the failure to do so leads to gratuitous portability barriers.
  
Current Practice:

  Currently, the definition of APPEND is such that it would be an error
  to pass it a dotted list, so there is no possibility of discrepancy
  because the interesting case is an "is an error" case.

Cost to Implementors:

  Very small. Some implementations would need to change how they implement
  backquote. Presumably this is a very isolated change.

Cost to Users:

  Technically, none. Existing code is not supposed to rely on the distinctions
  discussed here. The distinction will only be meaningful when ANSI CL goes into
  effect.

  In practice, since some implementations will have to change incompatibly,
  some code which accidentally relies on the current behavior will break.
  However, once such code is fixed, it will be more portable because 
  implementations will not gratuitously diverge.

Cost of Non-Adoption:

  An ambiguity would exist in the language, confusing both users and
  implementors.

Benefits:

  An ambiguity would be removed.
  Some gratuitous barriers to portability would be removed.

Aesthetics:

  Proposal DIVERGENT makes things slightly harder to learn.

  Both proposals make things more predictably portable, which presumably
  has some aesthetic appeal.

Discussion:

  Pitman thinks that either of these choices will be better than the status quo.

  Given that some people already think of ., and ,@ as interchangeable and merely
  a matter of personal style, it would be better to go with option INTERCHANGEABLE.

∂22-Dec-88  1614	CL-Cleanup-mailer 	Re: Issue: LISP-PACKAGE-NAME (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Dec 88  16:14:46 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 511685; 22 Dec 88 19:13:34 EST
Date: Thu, 22 Dec 88 19:13 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LISP-PACKAGE-NAME (Version 1)
To: Gray@DSG.csc.ti.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU,
    X3J13@DSG.csc.ti.com
In-Reply-To: <2807818509-4565574@Kelvin>
Message-ID: <881222191318.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Thu, 22 Dec 88  15:35:09 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    > Proposal (LISP-PACKAGE-NAME:COMMON-LISP):
    > 
    >   Define that ANSI Common Lisp uses the package name COMMON-LISP, not LISP.
    >   Define that the COMMON-LISP package has nickname CL.
    > 
    >   Since some symbols (e.g., T, NIL, and LAMBDA) might have to be shared
    >   between COMMON-LISP and LISP in implementations simultaneously supporting
    >   both, clarify that the initial symbols specified by ANSI Common Lisp as
    >   belonging in the COMMON-LISP package need not have a home package of 
    >   Common-Lisp.

    I like this.  I wonder, though, if you might want to add that it would be
    permissible for implementations to define "LISP" as a nickname for this
    package, for the sake of backwards compatibility in new implementations
    that wouldn't otherwise have a "LISP" package?

Anyone wanting to make LISP a nickname could just as well create a LISP
package which simply imported the appropriate symbols from the CL package.

With only modest additional effort, they could try to make new symbols where
feasable (especially for most functions) and put borrowed functions plopped
in their function cells. The amount of additional storage is small (compared
to implementing a whole new lisp), but it would leave open the possibility for
users upgrading the level of compatibility without hurting the core
system. eg, if I wanted APPEND to signal an error on dotted lists, I
would not consider redefining the system's APPEND for fear of breaking
the world, but if they told me that nothing depended on LISP other than
compatibility code, I might feel ok about redefining (or doing
SHADOWING-IMPORT of LISP:APPEND on a per-implementation basis (with
appropriate sharp conditionals)) in order to up the level of
compatibility.

In fact, though, my guess is that implementations which are not going to
do a serious compatibility effort are better off leaving the package
missing. My experience has been that customers are often happier growing
their own compatibility [or getting it from a public library] than being
stuck with something which really doesn't do what they want but which
seals off the place in the namespace which they needed in order to do
their own thing.

For this reason, I think we should discourage or prohibit the placement
of a LISP nickname on the CL package.

Besides, ANSI CL supersedes CLtL, but ISO Lisp may not. Depending on how
it turns out, I could see people considering them siblings rather than
mother/daughter. I really believe the bit about not wanting to lock down
the name LISP for a dialect that may not be the unique favorite.

    > Cost to Implementors:
    > 
    >   Small.
    > 
    >   In some cases, this may even have `negative cost' because it will provide
    >   implementors a way of avoiding incompatible changes to released operators.

    I agree; this approach will make it much easier for us to support the
    standard with minimal incompatibility for existing programs.  Trying to
    support Zetalisp and Common Lisp sharing the same LISP package has been
    enough of a headache without having to try to support two dialects of
    Common Lisp that way.

    Now we just need something in the *FEATURES* list to enable easy
    distinction between standard-conforming and pre-standard implementations.

In Cloe, we use a separate readtable for the different dialects, and each dialect
has its own *FEATURES* list. Although this seems like it would be confusing, it
works out pretty well in practice once you've made all the system tools understand
it. If we specified that CLtL and ANSI CL could have similar readtables but that
they must not be EQ (for the sake of #+ and #-), and if we defined that 
(NOT (EQ 'CL:*FEATURES* 'LISP:*FEATURES*)), then we could indeed have such a feature.

If I get a little time (worn out joke), I'll see about see about spinning off an
issue to deal with that and see if it flies. I know it's last minute, but I agree
with you that it would really grease the wheels of transition, so hopefully people
will find it palatable.

∂27-Dec-88  1209	CL-Cleanup-mailer 	Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Dec 88  12:08:57 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00336g; Mon, 26 Dec 88 22:12:24 PST
Received: by bhopal id AA01403g; Mon, 26 Dec 88 22:13:04 PST
Date: Mon, 26 Dec 88 22:13:04 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812270613.AA01403@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Thu, 22 Dec 88 18:44 EST <881222184414.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)

re    Cost to Users:
      Technically, none. Existing code is not supposed to rely on ...

Not so!  The language of the last line on P.350 of CLtL make it clear 
that implementations are currently free to take either choice mentioned
in the two proposals.  Since not everyone restricts himself to writing
only portable-by-the-book CLtL code, then many users will in fact take 
advantage of the particular choices made by the implementation they use.
[Witness the number of Symbolics users who unknowingly adjust arrays that 
were made without the :adjustable option].

Selecting only one the two alternatives of P.350 will invalidate those
implementations that have taken the other choice; so either proposal
will shaft some community of users (i.e., those who have never ported 
their code between vendors that took different paths on the P.350
question).  I know, because we just went through such an exercise here
at Lucid not too long ago.  Far too many places depended on the
equivalence of ., and ,. -- that the last form *not* be NCONC'd with
with NIL -- and at least a couple places actually depended upon a final 
,@ giving shared structure (for updates to be communally visible).

Incidentally, Lucid adopted a view towards non-standard lists long, long 
ago that forced it to resolve the APPEND-DOTTED issue for itself; thus it 
is not true of "Current Practice:" that there is "no possibility of 
discrepancy".  I'm not necessarily defending that view of dotted-lists -- 
merely pointing out that Lucid's decision back in October 1984 makes the 
INTERCHANGEABLE proposable infeasible without backing out of infinitely-many 
more dotted-list type decisions.  ["infinitely-many more" means that we 
worried about just this issue sometime in late 1986, and decided we didn't 
have the manpower to resolve it, since it turns up pervasively throughout 
the system.]  In defence of the 1984 decision, someone who was here at the 
time claimed that they personally asked Guy Steele about that interpretation,
and that "he approved".  Perhaps no one was concerned back then with the
examples on ClTL P.351.


I actually think the DIVERGENT proposal is simpler to understand:
   (1) ,@ always copies -- not to worry about being "at the end"
   (2) ,. always NCONC's and ., never NCONC's -- not to worry about
       situations that would switch meanings.


-- JonL --





∂27-Dec-88  1716	CL-Cleanup-mailer 	Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)   
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 27 Dec 88  17:16:34 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 414776; Tue 27-Dec-88 11:27:49 EST
Date: Tue, 27 Dec 88 11:26 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881227112629.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

To my knowledge, this was discussed (well, ok, one message was sent on
the subject) but never formally written up.

Actually, I took the writeup of PATHNAME-TYPE-UNSPECIFIC and expanded 
it slightly to accomodate other fields. I wrote it up and included the
issue PATHNAME-TYPE-UNSPECIFIC with it. If people seem happy with this
writeup, Larry can consider PATHNAME-TYPE-UNSPECIFIC withdrawn.
If this one runs into some hidden snag, I'll reactivate 
PATHNAME-TYPE-UNSPECIFIC.

Note that Larry's original message on PATHNAME-UNSPECIFIC-COMPONENT
deals with some things unrelated to the issue of unspecific components.
I haven't lost that information; it will appear in a different proposal,
soon to follow.
 -kmp

-----
Issue:        PATHNAME-UNSPECIFIC-COMPONENT
Forum:        Cleanup
References:   File System Interface (pp409-427)
Category:     CHANGE
Edit history: 27-Dec-88, Version 1 by Pitman
Status:       For Internal Discussion
Subsumes:     Issue PATHNAME-TYPE-UNSPECIFIC

Problem Description:

  In some file systems, it is inappropriate to represent particular
  pathname components, either all the time or in some specialized 
  circumstance.

   - Unix pathnames never have a version field.

   - In some file systems, specifying a device and a directory means
     something very different than specifying the device alone, 
     particularly when the device is a "logical device" that may
     already imply a directory.

   - Some Unix pathnames have types and others do not. For example,
     it is possible to make files named "foo." and "foo" which are
     distinct. CLtL (p412) specifies that the type is ``always a
     string, NIL, or :WILD.'' This description is too restrictive
     to be practical in this case. One of these (usually the former)
     can get a type of "" but it is not clear how to represent the
     other. If NIL is used, merging primitives cannot detect that the
     field is filled and should not be merged against. 

   - ITS pathnames have either a version or a type, but never both.
     "JOE;FILE 32" has a directory, a name, and a version.
     "JOE;FILE TEXT" has a directory, a name, and a type.
     "JOE;FILE TEXT 32" is not a possible ITS filename.

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

  Permit :UNSPECIFIC as a value of the DEVICE, DIRECTORY, TYPE, or
  VERSION field of a pathname for file systems in which it makes sense.

  When a pathname is converted to a namestring, NIL and :UNSPECIFIC
  are treated as if the field were empty. That is, they both cause the
  component not to appear in the string.

  When merging, however, only a NIL value for a component will be
  replaced with the default for that component, while :UNSPECIFIC
  will be left alone as if the field were filled.

  Portable programs should expect to find :UNSPECIFIC in the device,
  directory, type, or version field in some implementations.

  Portable programs should not explicitly place :UNSPECIFIC in any
  field, since that it might not be permitted in some situations,
  but portable programs may sometimes do so implicitly.

Test Case:

  ;; #1: Non-portable code. This may signal an error in some
  ;;     implementations where an unspecific type makes no sense.

  (MAKE-PATHNAME :TYPE :UNSPECIFIC)	;not portable

  ;; #2: In this example, assume a Unix file system.

  (PATHNAME-TYPE (PARSE-NAMESTRING "foo."))
  => ""

  (PATHNAME-TYPE (PARSE-NAMESTRING "foo"))
  => :UNSPECIFIC

  (PATHNAME-TYPE (MERGE-PATHNAMES (PARSE-NAMESTRING "foo")
				  (MAKE-PATHNAME :TYPE "BAR")))
  => :UNSPECIFIC

  ;; #3: In this example, assume an ITS file system.

  (LET ((P (PARSE-NAMESTRING "FOO 32")))
    (LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
  => (:UNSPECIFIC 32)

  (LET ((P (PARSE-NAMESTRING "FOO TEXT")))
    (LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
  => ("TEXT" :UNSPECIFIC)

  (LET ((P (MERGE-PATHNAMES (PARSE-NAMESTRING "FOO 32")
			    (PARSE-NAMESTRING "FOO TEXT"))))
    (LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
  => (:UNSPECIFIC 32)

  ;; Note: It is not the intent of this proposal to actually legislate
  ;; the canonical representation of Unix pathnames "foo." and "foo",
  ;; nor of ITS pathnames "FOO 32" and "FOO TEXT". That should probably
  ;; be done, but under separate cover. The above examples are intended
  ;; only to demonstrate how this proposal will permit the representation
  ;; of pathnames not usefully representable under CLtL.

Rationale:

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

Current Practice:

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

Cost to Implementors:

  None. No change to any implementation is forced.

  Some implementations which already do this are legitimized.

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

Cost to Users:

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

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

Cost of Non-Adoption:

  Some implementations would be unable to both represent all possible 
  pathnames in a rational way and at the same time to conform to the
  standard. Such an inability would seriously jeopardize the usefulness
  of Common Lisp in the design of serious programs.

Benefits:

  Some programs involving pathnames would be more portable.

Aesthetics:

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

Discussion:

  Pitman and Moon support PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.

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

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

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

∂27-Dec-88  1724	CL-Cleanup-mailer 	Issue: SETF-SUB-METHODS   
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 27 Dec 88  17:24:10 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 27 Dec 88 20:16:59 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 27 Dec 88 20:22:08 EST
Date: Tue, 27 Dec 88 20:22 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: SETF-SUB-METHODS
To: cl-cleanup@sail.stanford.edu
Message-Id: <19881228012217.3.BARMAR@OCCAM.THINK.COM>

I have a question about the SETF-SUB-METHODS issue, which clarifies the
order of "evaluation" of access forms that are generalized variable
references.

The Cost to Users section only mentions the incompatibilities caused by
implementations changing to the required behavior.  What about users who
have implemented their own complex DEFINE-SETF-METHODs?  Will they need
to change these if they wish their generalized variables to be
consistent with the language-defined ones?  Or does this not affect the
return values from a SETF method?

                                                barmar

∂28-Dec-88  1133	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Dec 88  11:33:42 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 512753; Wed 28-Dec-88 14:32:32 EST
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
Message-ID: <881228143206.5.KMP@BOBOLINK.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.

∂28-Dec-88  1259	CL-Cleanup-mailer 	Issue: PATHNAME-EXTENSIONS (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Dec 88  12:58:49 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 512793; Wed 28-Dec-88 15:57:35 EST
Date: Wed, 28 Dec 88 15:57 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-EXTENSIONS (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <881228155709.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

Issue:        PATHNAME-EXTENSIONS
Forum:	      Cleanup
References:   Pathnames (pp410-413)
Category:     ADDITION
Edit history: 28-Dec-88, Version 1 by Pitman
Status:	      For Internal Discussion

Problem Description:

  CLtL is quite strict about what may and may not be in any kind of
  pathname, leaving implementors up against a brick wall when an
  idiosyncratic extension is necessary to uniquely and usefully 
  represent all files in a particular file system which may not have
  been completely anticipated by the Common Lisp designers.

Proposal (PATHNAME-EXTENSIONS:NEW-PREDICATE):

  Introduce a function COMMON-PATHNAME-P, described as follows:

	COMMON-PATHNAME-P pathname			[Function]

	Returns true if its argument satisfies the Common Lisp
	pathname model, and false otherwise. If the argument is
	not a pathname, an error of type TYPE-ERROR is signalled.

  Clarify that COMMON-PATHNAME-P considers a pathname's host field
  to fit the Common Lisp pathname model if the filler of the host
  field is a string (naming a host), and not otherwise.

  Clarify that COMMON-PATHNAME-P considers a pathname's device to fit
  the Common Lisp pathname model if it is a string naming a device,
  or NIL, or :WILD[, or, if issue PATHNAME-COMPONENT-UNSPECIFIC 
  passes, is :UNSPECIFIC], and not otherwise.

  Clarify that COMMON-PATHNAME-P considers a pathname's directory
  field to fit the Common Lisp pathname model if the filler of the
  directory field is NIL, or :WILD, or a string[, or, if issue
  PATHNAME-SUBDIRECTORY-LIST passes, is a list described as valid
  by that proposal][, or, if issue PATHNAME-COMPONENT-UNSPECIFIC 
  passes, is :UNSPECIFIC], and not otherwise.

  Clarify that COMMON-PATHNAME-P considers a pathname's name to 
  fit the Common Lisp pathname model if it is a string, or NIL,
  or :WILD, and not otherwise.
  
  Clarify that COMMON-PATHNAME-P considers a pathname's type to
  fit the Common Lisp pathname model if it is a string, or :WILD,
  or NIL[, or, if issue PATHNAME-COMPONENT-UNSPECIFIC passes, is
  :UNSPECIFIC], and not otherwise.

  Clarify that COMMON-PATHNAME-P considers a pathname's version to
  fit the Common Lisp pathname model if it is a positive integer,
  :WILD, or NIL, or :NEWEST[, or, if issue PATHNAME-COMPONENT-UNSPECIFIC
  passes, is :UNSPECIFIC], and not otherwise.

  Clarify that COMMON-PATHNAME-P considers a pathname to be outside
  the Common Lisp model if it contains special syntax or purpose 
  which is not readily apparent to Common Lisp programs. For example,
  if a character like "*" or "~" has special meaning to the file 
  system, then strings like "F*X" or "~FOO" which exploit that syntax
  are not considered to "fit the model". [Note that if issue
  PATHNAME-WILD passes, WILD-PATHNAME-P might still be true of
  some pathnames that were not COMMON-PATHNAME-P.]

Test Case:

  ;; On Unix...

  (common-pathname-p (make-pathname :name "f*x"))
  => nil

  ;; On Tops-20...

  (common-pathname-p (make-pathname :name "FOO" :version -1))

  ;; On VMS...

  (common-pathname-p (parse-namestring "x::y::z::w::[joe]a.b"))
  => nil

  ;; Normally

  (common-pathname-p (make-pathname :name "FOO" :version :wild))
  => t

  (common-pathname-p (make-pathname :name "FOO" :version 17))
  => t

Rationale:

  The purpose of COMMON-PATHNAME-P is not to detect pathnames which
  are not valid. Indeed, no Common Lisp function requires that its 
  argument satisfy this test; it is assumed that functions such as
  OPEN and MERGE-PATHNAMES will recognize and deal appropriately with
  whatever special pathname syntax is appropriate to the host operating
  system. Rather, the purpose of COMMON-PATHNAME-P is to help Common 
  Lisp programs which try to pick apart a pathname and perform some
  sort of simulated merging on the basis of the simple pathname model
  put forth by Common Lisp, so that such programs can detect situations
  which are beyond their capabilities.

Current Practice:

  Probably nobody implements this.

Cost to Implementors:

  Small. The program is fairly straightforward. It could almost be
  written as a portable library if it weren't for detecting special
  characters that have some special syntax.

Cost to Users:

  None. This change is upward compatible.

Cost of Non-Adoption:

  Some idiosyncratic system syntax would be hard to detect.

  Making extensions to the pathname system in a way that Common Lisp
  users would not be forced to trip over would be more difficult.

Benefits:

  Some ad-hoc user code which tries to do the same thing could be
  eliminated. Portable programs which must prompt for native pathname
  syntax, and deal with the result of having parsed it could be more
  robust.

  Making idiosyncratic extensions to the pathname system would be much
  less prone to cause problem for portable programs which used this 
  facility.

  The presence of this operator could someday ease the transition
  into a future, incompatible pathname system.

Aesthetics:

  Probably improves aesthetics slightly by giving people who want to
  reject extended pathnames a more reliable way of weeding them out.

Discussion:

  The COMMON data type was probably intended to have this same purpose.
  Unfortunately, since no one ever really said specifically enough what
  was in COMMON or not, and why, it never really caught on. Hopefully
  this proposal is definite enough on such issues to not be useless.

  Pitman thinks this is probably a good idea.

∂29-Dec-88  0353	CL-Cleanup-mailer 	Issue: SETF-SUB-METHODS   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Dec 88  03:53:21 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00898g; Thu, 29 Dec 88 03:49:55 PST
Received: by bhopal id AA09984g; Thu, 29 Dec 88 03:52:05 PST
Date: Thu, 29 Dec 88 03:52:05 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812291152.AA09984@bhopal>
To: barmar@Think.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 27 Dec 88 20:22 EST <19881228012217.3.BARMAR@OCCAM.THINK.COM>
Subject: Issue: SETF-SUB-METHODS

re:  What about users who
    have implemented their own complex DEFINE-SETF-METHODs?  Will they need
    to change these if they wish their generalized variables to be
    consistent with the language-defined ones?  Or does this not affect the
    return values from a SETF method?

Well, I won't say that a programmer who uses DEFINE-SETF-METHOD can't
shaft himself this way [by definition, DEFINE-SETF-METHOD is for the
"not easy" case].  However, this proposal seems more directed towards
stopping the premature optimization where "evaluating a subform" and 
"doing the access" are falsly combined into one step.  [The original
temptation to do so was when the sub-form was a symbol(?)]  I rather
hope, as you suggest, that this proposal affects the return value
of a SETF method only to the degree that the related accessing and 
storing forms don't make the premature optimization.


-- JonL --

∂29-Dec-88  1006	CL-Cleanup-mailer 	Issue: PATHNAME-EXTENSIONS (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88  10:06:22 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513117; Thu 29-Dec-88 13:05:13 EST
Date: Thu, 29 Dec 88 13:04 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-EXTENSIONS (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881228155709.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881229180459.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

This sounds reasonable at first, but I was unable to think of any
way that a correct portable program could use it.  If there was a
use for it, I couldn't convince myself that a single yes/no distinction
was sufficient; some extensions to Common Lisp pathname semantics
might be handled by a CL function that the user program was going to
call, thus they wouldn't interfere with use of an "extended" pathname.
Indeed, why isn't this true of all such extensions?

I think you need to supply a real example.

∂29-Dec-88  1031	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88  10:30:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513134; Thu 29-Dec-88 13:29:18 EST
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>
Message-ID: <19881229182903.0.MOON@EUPHRATES.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.

∂29-Dec-88  1038	CL-Cleanup-mailer 	Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88  10:38:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513138; Thu 29-Dec-88 13:37:15 EST
Date: Thu, 29 Dec 88 13:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881227112629.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881229183701.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

I approve PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN (of course).

Where you note that Unix pathnames don't have versions, you
could also note that they don't have devices either.

The stuff about generic pathnames in the discussion section
was brain damage and may have lead to the confusion that caused
:unspecific to be dropped from Common Lisp.  Only the stuff about
components not supported by a file system makes sense.

∂29-Dec-88  1040	CL-Cleanup-mailer 	Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88  10:39:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513139; Thu 29-Dec-88 13:38:15 EST
Date: Thu, 29 Dec 88 13:38 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881227112629.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Supersedes: <19881229183701.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Added comment about misspelled proposal name
Message-ID: <19881229183800.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

I approve PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN (of course).
Uh, the proposal name is really spelled that way in the body
of the writeup.  It should be PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN.

Where you note that Unix pathnames don't have versions, you
could also note that they don't have devices either.

The stuff about generic pathnames in the discussion section
was brain damage and may have lead to the confusion that caused
:unspecific to be dropped from Common Lisp.  Only the stuff about
components not supported by a file system makes sense.

∂29-Dec-88  1119	CL-Cleanup-mailer 	Issue: PATHNAME-EXTENSIONS (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88  11:18:41 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513169; Thu 29-Dec-88 14:17:20 EST
Date: Thu, 29 Dec 88 14:16 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-EXTENSIONS (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19881229180459.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <881229141653.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

Here's a made-up example of the kind I was imagining:

(DEFUN TRANSLATE-LOGICAL-PATHNAME (LPATHNAME)
  (MULTIPLE-VALUE-BIND (LHOST LDEVICE LDIR LNAME LTYPE LVERSION)
      (PARSE-LOGICAL-PATHNAME LPATHNAME)
    (MULTIPLE-VALUE-BIND (PHOST PDEVICE PDIR PNAME PTYPE PVERSION)
        (TRANSLATE-PATHNAME-COMPONENTS LHOST LDEVICE LDIR LNAME LTYPE LVERSION)
      (LET ((PHYSICAL-PATHNAME (MAKE-PATHNAME :HOST PHOST ...)))
        (UNLESS (COMMON-PATHNAME-P PHYSICAL-PATHNAME)
          (CERROR "Use ~*~A anyway."
		  "The result of translating pathname ~A to a physical pathname~
		 ~%resulted in a valid physical pathname, ~A,~
                 ~%but that pathname has special meaning to host ~A which may~
		 ~%not have been what was intended."
	          LPATHNAME PHYSICAL-PATHNAME PHOST))))))

I don't think I have a specific example around, but I remember I used to worry
about this a lot in Macsyma, because LispM Macsyma does cross-host file searches
by mixing and matching file syntaxes gotten from here and there. I used to worry
it would construct pathnames that were magic in some way and do something weird.
If I could have put in an error check here and there, I'd have felt a bit more 
comfortable.

Also, CLtL's spec gives so much leeway allowing "implementation-dependent" things
all over the place in pathnames, that I just figured that it would be easier for
users who want to assume the "nice" values are present to just guard simple-minded
code with

 (COND ((COMMON-PATHNAME-P PATHNAME)
        ... code that assumes pathnames don't contain hairy junk ...)
       (T
        (ERROR "Pathname ~S was more complex than I expected." PATHNAME)))

As clumsy as this error seems, it's probably more informative than the
LENGTH got bad argument or whatever that you'd get instead if you wrote the
same code unguarded. Seems like that would provide at least the opportunity
for fault-tolerant code without giving up the ability to do fast prototyping.

∂29-Dec-88  1132	CL-Cleanup-mailer 	Issue: PATHNAME-EXTENSIONS (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88  11:32:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513176; Thu 29-Dec-88 14:31:07 EST
Date: Thu, 29 Dec 88 14:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-EXTENSIONS (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881229141653.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881229193043.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

The examples only shed negative illumination for me.  That is,
I'm not sure what precisely "special meaning", "something weird",
not "nice values", and "hairy junk" really mean.  I suspect part of
what you're worried about is wildcard pathnames; wasn't there already
proposed a PATHNAME-WILD-P (or was it WILD-PATHNAME-P?) function for
that?

In one of your examples COMMON-PATHNAME-P seems to mean "this pathname
is acceptable to the host" and in the other example COMMON-PATHNAME-P
seems to mean "this pathname is acceptable to a particular user-written
algorithm".  To me those don't seem to be the same test.  I think the
former test makes sense to codify as a function (although when I try
to articulate precisely what "acceptable" means, I have trouble; can it
be dynamically varying depending on what files and directories currently
exist?), but I don't see that your proposed function does this test.
The latter test seems hard to specify without saying anything about
the user-written algorithm.

I'm not really opposed to this, but I don't think it's defined
specifically enough yet.  I begin to fear that it is inherently
impossible to define it specifically enough.

∂29-Dec-88  1153	CL-Cleanup-mailer 	Issue: PATHNAME-EXTENSIONS (Version 1)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Dec 88  11:53:36 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01031g; Thu, 29 Dec 88 11:49:58 PST
Received: by bhopal id AA11022g; Thu, 29 Dec 88 11:52:09 PST
Date: Thu, 29 Dec 88 11:52:09 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8812291952.AA11022@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: Kent M Pitman's message of Wed, 28 Dec 88 15:57 EST <881228155709.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-EXTENSIONS (Version 1)

Does this really need to be a part of the standard?  Why can't it
just be privately distributed (or re-invented) by the few sites that
want it?  As far as I can see, it is merely a syntax checker which
sits entirely on top of the current language, and anyone who cares
can implement it quickly after reading the standard.

If one is to persue portability in this fashion, I think it would be
more elegant to seriously implement the COMMON data type and have a
pair of predicates that tested any given lisp form and said whether it
was data (or code) that adhered to the common lisp standard.  (The
data predicate might itself be written portably.  The code predicate
would need to be ported to each vendor to detect supported but
non-standard features, since (TRICKY X) would be standard if TRICKY
were user-defined, but would not be if it implemented some
vendor-specific magic.)  Given such predicates you could safely
descend through any lisp structure, using the predicates to warn you
of pitfalls ahead.   

Doing bits and pieces of syntax checking seems somewhat ad hoc, unless
the claim is that pathnames are and will be the only "standard" data
which have unpredictable format.

  jlm

∂29-Dec-88  1157	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88  11:56:58 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513196; Thu 29-Dec-88 14:54:41 EST
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>
Message-ID: <881229145413.6.KMP@BOBOLINK.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?

∂29-Dec-88  1219	CL-Cleanup-mailer 	Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88  12:18:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513216; Thu 29-Dec-88 15:17:18 EST
Date: Thu, 29 Dec 88 15:16 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
To: CL-Cleanup@SAIL.Stanford.Edu, Pavel.pa@Xerox.COM
In-Reply-To: <881205-182309-4829@Xerox>
Message-ID: <19881229201656.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

I support this proposal, especially as modified by GSB's comments.

I'd like to point out that this proposal corresponds exactly to current
practice in Symbolics Genera (all versions from 6.0 on), except that
SHIFTF, ROTATEF, ASSERT, CTYPECASE, and CCASE only allow single values.
You should update the current practice section accordingly.

I think SHIFTF and ROTATEF should allow any number of values, but the
other three (yes, including ASSERT) properly only allow single values.

Do you plan to bring an updated version of this proposal to the
next X3J13 meeting?

∂29-Dec-88  1228	CL-Cleanup-mailer 	Issue: PATHNAME-EXTENSIONS (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88  12:28:43 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513219; Thu 29-Dec-88 15:24:16 EST
Date: Thu, 29 Dec 88 15:23 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-EXTENSIONS (Version 1)
To: jlm@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8812291952.AA11022@bhopal>
Message-ID: <881229152348.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Thu, 29 Dec 88 11:52:09 PST
    From: Jim McDonald <jlm@lucid.com>

    Does this really need to be a part of the standard?  Why can't it
    just be privately distributed (or re-invented) by the few sites that
    want it?  As far as I can see, it is merely a syntax checker which
    sits entirely on top of the current language, and anyone who cares
    can implement it quickly after reading the standard.

The answer to this is in the proposal (Cost to Implementors):

  Small. The program is fairly straightforward. It could almost be
  written as a portable library if it weren't for detecting special
  characters that have some special syntax.

A truly portable program cannot know that "*" or "~" or whatever
is special to some file systems and not to others.

    If one is to persue portability in this fashion, I think it would be
    more elegant to seriously implement the COMMON data type 

I'd be really surprised if you could come up with a meaning for this
as a type. I could imagine you almost coming up with a meaning for COMMON
which was representable as a predicate, but I don't think you could do
it as a type. It's clear that some non-COMMON data types have to be 
subtypes of COMMON. For example, arrays with array leaders on the 3600.
You might write a COMMON-P predicate which detected this, but you'd be
misled by subtypep relations if you really pursued this as part of the
type system.

    and have a
    pair of predicates that tested any given lisp form and said whether it
    was data (or code) that adhered to the common lisp standard.

If you want to write a description of such a predicate, I think we should
have it. But I don't think you could describe it adequately, so I was biting
off a particular part of the problem that has some real world application.
Pathnames are interestingly different from other CL data because they involve
a syntax (namestrings) which are specified by an external agency (the file
system) and which correspond to data structures (directories, links, files,...)
which are also really beyond the scope of CL to legislate. As such, they are
more prone to legitimately deviate than other aspects of CL data. At least
in the case of other data, you can argue that the implementors could have
opted to not provide the extensions (eg, array leaders). You can't argue
that CL implementors should fail to support some kinds of files just because
the CL model doesn't suppor them. They must support all files, or CL programmers
will be laughed at by their friends that use -real- programming languages.
If they do support all files, then either we must have amazing foresight in
choosing just the right pathname model, or we must guard ourselves by providing
ways for CL implementors to legitimately deviate without screwing up normal
programs.

    (The data predicate might itself be written portably.

It cannot be written portably. Examples:
 - From Scheme: Scheme does not define a way to adjust the length of
   a STRING. Unfortunately, some implementations do. The Scheme spec
   did not define (EQL "" ""), but did define that operationally
   equivalent data was EQL. Since the only side-effecting string 
   operations in Scheme set a string element (and don't change its
   size), then "" can't be side-effected, and so by implication
   (EQL "" "") should return T. However, some implementations extended
   Scheme to provide operations to change a string's length. Those
   operations (rightly, I think) interpreted the spec to say that
   (EQL "" "") could return NIL. No portable predicate on "" can
   detect that someone has added an operation that makes "" not fit
   the model that Scheme had for strings. The issue here is that
   sometimes it's the operators which cause the confusion, not the
   data layout, so making a function just on data is not necessarily
   helpful.
 - From Genera: What portable operation can detect that an array has
   a leader (given that EQUAL ignores leaders). Answer: None. You have
   to use implementation-dependent means to detect 
   implementation-dependent features!
 - From Star Trek: Spock: "Captain, I'm registering a kind of energy
   never before encountered." Man, the guys who designed his scanner
   were geniuses...


    The code predicate would need to be ported to each vendor to 
    detect supported but non-standard features, 

Then what's the point of claiming it's portable?

    since (TRICKY X) would be standard if TRICKY
    were user-defined, but would not be if it implemented some
    vendor-specific magic.)

What is "it" in this sentence?

    Given such predicates you could safely descend through any lisp
    structure, using the predicates to warn you of pitfalls ahead.   

Given the above, I think this is naive.

    Doing bits and pieces of syntax checking seems somewhat ad hoc, unless
    the claim is that pathnames are and will be the only "standard" data
    which have unpredictable format.

Well, as I mentioned above, there's a real empirical reason to believe
that if not the only one in that `class,' they are at least part of an
elite group. Streams might be another candidate, but I don't happen to
be interested in that.

In any case, I have grown very weary of arguments of the form
 "Gosh, you thought up an interesting thing there, but before
  I'll agree with it, I think you should generalize it a lot more
  for no apparent reason."  Lots of things we've proposed as cleanups
are incidences of larger problems, but I think we ought to just consider
what's proposed. If it's important to someone to solve the more general
case, let them write the proposal and I (at least) will consider it for
what it's worth. But in the absence of such a general proposal, I don't
agree that it's best to just admit defeat and do nothing. There is a lot
to be gained by solving subsets of problems and gaining experience for
the next round. Maybe ten years from now we'll know if a primitive like
this had unforseen problems, we'll know if it got any (or a lot of) use,
etc.  The COMMON type was an example. It was a noble experiment and
probably should be put to death now that it's been demonstrated to be a
loser.  But it didn't cost users at all, and it didn't cost implementors
much (an evening each of lost sleep for a few implementors here and there)
to have it there -- and we learned something in the process.

∂29-Dec-88  1308	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Dec 88  13:07:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513261; Thu 29-Dec-88 16:05:23 EST
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>
Message-ID: <19881229210501.0.MOON@EUPHRATES.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.

∂29-Dec-88  1451	CL-Cleanup-mailer 	Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3) 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Dec 88  14:51:48 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01199g; Thu, 29 Dec 88 14:46:14 PST
Received: by bhopal id AA11773g; Thu, 29 Dec 88 14:48:23 PST
Date: Thu, 29 Dec 88 14:48:23 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8812292248.AA11773@bhopal>
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

∂29-Dec-88  1834	CL-Cleanup-mailer 	Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1) 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 29 Dec 88  18:33:53 PST
Received: by ti.com id AA06901; Thu, 29 Dec 88 20:33:36 CST
Received: from dsg by tilde id AA24175; Thu, 29 Dec 88 20:22:52 CST
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 29 Dec 88  20:20:40 CST
Message-Id: <2808440631-7583328@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 29 Dec 88  20:23:51 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
In-Reply-To: Msg of Thu, 22 Dec 88 18:44 EST from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

I ran all of the test cases on an Explorer and found that the results were
all consistent with proposal
BACKQUOTE-COMMA-ATSIGN-DOT-COMMA:INTERCHANGEABLE, so I would have to
prefer that alternative, although I don't know who might be depending on
that behavior.

The INTERCHANGEABLE alternative also has a performance advantage by doing
less copying of lists.

∂30-Dec-88  0234	CL-Cleanup-mailer 	Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Dec 88  02:34:03 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01499g; Fri, 30 Dec 88 02:29:35 PST
Received: by bhopal id AA13596g; Fri, 30 Dec 88 02:31:41 PST
Date: Fri, 30 Dec 88 02:31:41 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812301031.AA13596@bhopal>
To: Gray@DSG.csc.ti.com
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: David N Gray's message of Thu, 29 Dec 88  20:23:51 CST <2808440631-7583328@Kelvin>
Subject: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)

re: I ran all of the test cases on an Explorer and found that the results were
    all consistent with proposal
    BACKQUOTE-COMMA-ATSIGN-DOT-COMMA:INTERCHANGEABLE . . .

It's highly probably that all "spiritual descendents" of MacLisp have
this behaviour, because they all probably copied the optimization that
treats ",."  ",@" and ".," the same when found at the penultimate 
position of a list.  ["backquote" evolved during the mid-1970's at
MIT in the AI and LCS labs].

Steele's book was the first to formalize the meaning of backquote, with
his meta-language on p.350.  From this discussion, it is clear that
the step
   (APPEND ... (APPEND X NIL))  ==>  (APPEND ... X)
is arbitrary, rather than being an inevitable part of the intended
meaning.  Steele implies that either doing this optimization or not
doing it is fine.  But the Issue APPEND-DOTTED now seems to make
this an invalid optimization.  

My feeling is that we either have to go for the discriminatory version
of BACKQUOTE-COMMA-ATSIGN-DOT-COMMA -- the one that says that ".," and
",@" really don't produce the same code -- or else we have to go back
to the prior state for APPEND.


-- JonL --

∂30-Dec-88  1425	CL-Cleanup-mailer 	Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Dec 88  14:25:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513668; Fri 30-Dec-88 17:24:15 EST
Date: Fri, 30 Dec 88 17:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881129165233.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881230222336.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

I agree with REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE as I think it
would be modified by ensuing discussion (be more careful in the
discussion of whether new objects are consed or not, and putting in the
missing functions SORT, STABLE-SORT, MERGE, and NSUBLIS; will there be a
version 5?), except that there is one additional change you need to
make:

Where you say
 (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.
you also need to say that it is an error after this operation to
reference any CONS that was formerly part of the top-level list
structure and is no longer part of it.  Of course this applies not
just to REMF, but also to SETF of GETF, NREVERSE, DELETE,
DELETE-DUPLICATES, NCONC, NUNION, NINTERSECTION, NSET-EXCLUSIVE-OR,
SORT, STABLE-SORT, and MERGE and to the ones that are defined to be
equivalent to these; these are all the ones that might change
list structure rather than just replacing CAR elements.

You see, not only are these destructive functions allowed to change
the components of the conses that make up the top-level list structure
of the argument, they are also allowed to reuse the storage of those
conses for something else that isn't a cons at all.  You may recall
that this was DLA's original motivation for bringing up the issue.

I strongly disagree with Larry's contention that SETF of GETF, REMF,
SETF of GET, and REMPROP are not reasonable to include in this proposal.
If anything, the property list operators have less justification for the
user to depend on the representation than (for example) DELETE, not more
justification.

I disagree with JonL's and Larry's contention that NBUTLAST is not
reasonable to include in this proposal.  I think it would be reasonable
to implement NBUTLAST by sliding all the list elements to the right n
positions and then returning NTHCDR n of the original list.  However,
CLtL p.271 could be interpreted as -requiring- NBUTLAST to be
implemented in terms of RPLACD of a specific cons, rather than just
mentioning that as an example; if so, I would change my mind and
agree that NBUTLAST should be excluded from this proposal.

I also believe that NCONC (and hence by implication NRECONC) is
reasonable to optimize, but on that point I could easily be swayed to
change my mind since I can't think of any really plausible
optimizations.  However, CLtL doesn't offer much evidence that a
specific implementation of NCONC is required.

For the others Larry listed (NSUBST, NSUBST-IF, and NSUBST-IF-NOT), what
the proposal actually says ("is permitted to SETF any part of the TREE
of conses which must be replaced by NEW-OBJECT.") is not proposing to
allow an implementation to modify any portion of a cons other than what
CLtL requires it to modify.  Perhaps that means there is no reason to
include these in the proposal because the proposal says exactly the same
thing about these that CLtL says.  BTW CLtL appears to -require- a
side-effect for these rather than merely -allowing- a side-effect.

∂30-Dec-88  1432	CL-Cleanup-mailer 	Issue SPECIAL-TYPE-SHADOWING (V1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Dec 88  14:32:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513671; Fri 30-Dec-88 17:31:08 EST
Date: Fri, 30 Dec 88 17:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue SPECIAL-TYPE-SHADOWING (V1)
To: David N Gray <Gray@DSG.csc.ti.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <2803680321-5692691@Kelvin>
Message-ID: <19881230223036.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

SPECIAL-TYPE-SHADOWING:CLARIFY seems right (i.e. the most consistent
with the rest of Common Lisp as it is emerging).

∂30-Dec-88  1446	CL-Cleanup-mailer 	Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Dec 88  14:45:54 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513680; Fri 30-Dec-88 17:43:47 EST
Date: Fri, 30 Dec 88 17:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
To: Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810072119.AA03303@mist.UUCP>
Message-ID: <19881230224313.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

I don't have any record of this issue being discussed.  If I'm
coming in late, please ignore and forgive me.

    Date: Fri, 07 Oct 88 17:19:22 EDT
    From: Dan L. Pierson <pierson%mist@multimax.ARPA>

    Issue:         DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES

    References:    Array type specifiers, pp. 45-46

    Related issues: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, DECLARE-TYPE-FREE

I don't think this has any actual interactions with the issue
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, since
DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES is about ARRAY type specifiers for
declaration, while ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS is about ARRAY type
specifiers for discrimination.

    Category:      CLARIFICATION

    Edit history:  Version 1,  7-Oct-88, Pierson

    Problem description:

    Array type specifiers appear to be useful both for declaring the
    storage format of the array and for declaring the types of legal
    operations on array elements.  Unfortunately, the current definition
    of the meaning of array type specifiers does not require an
    implementation to support the second use.

    Proposal (DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE):

    Within the scope of an array type declaration, all references to array
    elements are assumed to satisfy the exact declared element type.  

That's reasonable.  However, this is not a CLARIFICATION but a CHANGE,
since CLtL p.46 seems to be quite clear that the current meaning of such
a TYPE declaration is that the array elements satisfy the implementation
element type (what JonL calls the upgraded type), not the exact declared
element type.  Since your proposed new definition is more restrictive,
some portable programs that used to be correct may now be in error, hence
this is an incompatible CHANGE.  I think I'd vote for it anyway unless
someone argues that there is a significant impact on users.

								      An
    implementation should signal an error if this is ever violated.  

That's not reasonable.  The status quo for type declarations is that
a violation "is an error".  Changing it to "signals an error" is likely to
meet enormous resistance especially from stock hardware implementations,
and I think even changing it to "signals an error at the highest SAFETY
setting" would meet significant resistance.

								     A
    compiler may treat the code within the scope of the array type
    declaration as if each access of an array element was surrounded by an
    appropriate THE form.

That's a good way to define it (except you shouldn't assume that letting
everyone work out for themselves what the "appropriate THE form" is means
they will all come up with the same answer!).

    Examples:

    (DEFVAR *ONE-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 5)))
    (DEFVAR *ANOTHER-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 8)))

    (DEFUN FROB (AN-ARRAY)
      (DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
      (SETF (AREF AN-ARRAY 1) 31)		; OK
      (SETF (AREF AN-ARRAY 2) 127)		; Should signal an error
      (SETF (AREF AN-ARRAY 3) (* 2 (AREF AN-ARRAY 3))) ; Run-time decision needed
      (LET ((FOO 0))
	(DECLARE (TYPE (SIGNED-BYTE 5) FOO))
	(SETF FOO (AREF AN-ARRAY 0))))	; Declared to be safe

    (FROB *ONE-ARRAY*)			; Legal call, should signal an error
    (FROM *ANOTHER-ARRAY*)			; Is probably an undetectable error

    Note that the above definition of FROB is equivalent to:

    (DEFUN FROB (AN-ARRAY)
      (DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
      (SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 1) 31))
      (SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 2) 127))
      (SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))
	    (* 2 (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))))
      (LET ((FOO 0))
	(DECLARE (TYPE (SIGNED-BYTE 5) FOO))
	(SETF FOO (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 0)))))

    Test Cases:

    TBS

    Rationale:

    This mandates a useful and commonly expected behavior.  It complements
    proposal ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, which deals with array
    type specifiers as they refer to arrays as a whole.  The "should
    signal an error" requirement permits compiler optimization while
    requiring interpreters and low compiler optimization levels to perform
    useful error checking.

    Current practice:

    ???

    Cost to Implementors:

    Most implementations will have to extend the type checking in the
    interpreter and low optimization levels of the compiler.

    Cost to Users:

    Some users might find that errors in existing code become visible for
    the first time.

    Cost of non-adoption:

    Users will continue to expect declaration syntax to be more useful
    than it really is.

    It will be harder to debug code that uses arrays containing
    specialized types.

    Performance impact:

    Highly optimized code should be unaffected.  Interpreted and
    unoptimized code will run slower because of the additional error
    checking. 

    Benefits:

    It will be easier to use the Common Lisp type system to catch
    programming errors.

    Aesthetics:

    Improved because the meaning of type declarations will coincide more
    clearly with their appearance.

    Discussion:

    Pierson supports this proposal.

    JonL expressed support for the idea behind this proposal during the
    discussion of ARRAY-TYPE-ELEMENT-TYPE-SEMANITICS but said that it was
    a compiler committee problem.  This was submitted as a cleanup issue
    anyway because it imposes requirements on the interpreter as well as
    the compiler.

∂30-Dec-88  1525	CL-Cleanup-mailer 	Re: Issue: COERCE-INCOMPLETE (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Dec 88  15:25:51 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513694; Fri 30-Dec-88 18:24:45 EST
Date: Fri, 30 Dec 88 18:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: COERCE-INCOMPLETE (Version 2)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881209-164733-1437@Xerox>
Message-ID: <19881230232406.2.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 9 Dec 88 16:47 PST
    From: masinter.pa@Xerox.COM

    So why don't we just define:
    (coerce x 'string) == (string x)

This is the whole problem.  Leaving aside the cases that are
currently required to signal an error, (string nil) => "nil"
and (coerce nil 'string) => "" are currently required by CLtL.
So one way or another this would be an incompatible change.
Maybe it would be worth the incompatible change for the
increased consistency, who knows?  I don't like incompatible
changes.

    (coerce x 'character) == (character x)

Already true by definition (CLtL p.241).

    (coerce x 'pathname) = (pathname x)

Good idea.

    (coerce x 'float) = (float x),

Already true; not by definition, but deducible from CLtL.

Also (coerce x 'rational) = (rational x) would be a good idea,
don't you think?  CLtL p.52 indicates this was left out because
the user should have to decide explicitly whether to use rational
or rationalize.

The other functions that are also names of types that can be used
as type-specifiers without arguments are:

ATOM 
BIT 
BREAK -- condition system type
COMPLEX 
CONS 
ERROR -- condition system type
FUNCTION 
LIST 
NULL 
VECTOR 

except for FUNCTION, none of these is a coercer.  Should
(coerce x 'function) = (eval `(function ,x))?  Actually that
may have already been added to the language by the function-type
proposal, I forget.

    I might think that
    (coerce nil 'string) might well return a different value than
    (coerce nil '(vector character)).

I think that would be a really bad idea!  It's hard to be sure, but
I think CLtL's definition of COERCE very carefully skates around
any problems like this.  Making (coerce x 'string) = (string x)
might introduce this problem if we're not careful.

I think I've just been led back to the same place I always end up
when thinking about COERCE, even though that's not what I expected
at all when I started this message.  We should either leave COERCE
essentially the way it is or get rid of it.  I appreciate Larry's
argument that it's good to have because you know a lot about what
it will do even without knowing the specific coercions for the
target type.

∂30-Dec-88  1628	CL-Cleanup-mailer 	Issue GC-MESSAGES (Version 2)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Dec 88  16:28:05 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513710; Fri 30-Dec-88 19:26:54 EST
Date: Fri, 30 Dec 88 19:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881114101307.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881231002621.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

I still think that focussing on GC messages is wrong, and instead there
should be a form that disables unsolicited typeout in general,
regardless of its source.  Of course in some operating systems it might
be impossible to disable some forms of unsolicited typeout, and in other
operating systems unsolicited typeout might not exist (that is,
asynchronous messages might always come out in a separate window).
Thus this facility would just do the best effort appropriate for
the particular implementation.

I think there should be a stream argument, since there might be more
than one possible place for unsolicited typeout.  In other words, 
(WITHOUT-UNSOLICITED-OUTPUT (<stream>) <body>...) means that the output
send by <body> to <stream> should appear as a unit, without other
unsolicited output interspersed with it.

I don't think your :VERBOSE T option to encourage unsolicited typeout
is needed.

∂30-Dec-88  1650	CL-Cleanup-mailer 	Issue GC-MESSAGES (Version 2)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Dec 88  16:50:51 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513719; Fri 30-Dec-88 19:49:42 EST
Date: Fri, 30 Dec 88 19:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue GC-MESSAGES (Version 2)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19881231002621.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <881230194912.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Fri, 30 Dec 88 19:26 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    I still think that focussing on GC messages is wrong, and instead there
    should be a form that disables unsolicited typeout in general,
    regardless of its source.  Of course in some operating systems it might
    be impossible to disable some forms of unsolicited typeout, and in other
    operating systems unsolicited typeout might not exist (that is,
    asynchronous messages might always come out in a separate window).
    Thus this facility would just do the best effort appropriate for
    the particular implementation.

    I think there should be a stream argument, since there might be more
    than one possible place for unsolicited typeout.  In other words, 
    (WITHOUT-UNSOLICITED-OUTPUT (<stream>) <body>...) means that the output
    send by <body> to <stream> should appear as a unit, without other
    unsolicited output interspersed with it.

What if the typeout isn't going to a stream? Eg, some implementations might
cheat and do native non-stream-based I/O raw to the terminal during a GC to
avoid the risk of consing. I'm pretty sure I've seen some implementation
do this but I can't remember which.

Also, what if I do
 (WITHOUT-UNSOLICITED-OUTPUT (*TERMINAL-IO*) <body>)
? Does this affect unsolicited output to *STANDARD-OUTPUT*?

Also, what if I do
 (WITHOUT-UNSOLICITED-OUTPUT (*STANDARD-OUTPUT*) <body>)
? Does this affect unsolicited output to *TERMINAL-IO*?

Maybe we'd specify the stream to which unsolicited typeout is supposed to
go to help avoid problems like this. But then why would anyone bother to
use this macro on any other stream.

Without a way to test this property of a stream, no user-created stream
is going to ever respect this form anyway because unsolicited typeout
can't be distinguished from solicited typeout by the low-level printer
routines.

To my way of thinking, the root of this problem is that the system thinks
it is permissible to type on the virtual CL console. Personally, I think
this is a violation of the whole purpose of having stream-based I/O, which
is to keep the output of one program separate from the output of another.
Creating a stream-based abstraction to solve the problem of somebody 
violating the heart of the stream concept does not (without further
justification) seem to me the necessarily best way to proceed.

    I don't think your :VERBOSE T option to encourage unsolicited typeout
    is needed.

∂31-Dec-88  1935	CL-Cleanup-mailer 	Issue SYNTACTIC-ENVIRONMENT-ACCESS  
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 31 Dec 88  19:35:07 PST
Date: Sat 31 Dec 88 19:33:20-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue SYNTACTIC-ENVIRONMENT-ACCESS
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12458956724.23.IIM@ECLA.USC.EDU>

The issue SYNTACTIC-ENVIRONMENT-ACCESS mentions a proposal before cleanup to
add optional environment arguments to MACRO-FUNCTION and GET-SETF-METHOD.  Does
anyone happen to know the status of that proposal, and did it mention any other
functions that needed environment arguments?  BTW, I'd like to try to avoid
letting SYNTACTIC-ENVIRONMENT-ACCESS die of neglect.  I think something like
what it proposes is pretty important.  I believe Sandra said (in one of her
status messages) that Eric Benson was going to do a new writeup.  Sandra, have
you heard anything from him?  Do you have an address for him so I can poke
him?  Is he an X3J13 member?

kab
-------

∂31-Dec-88  2001	CL-Cleanup-mailer 	Issue EXIT-EXTENT, v5
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 31 Dec 88  20:01:14 PST
Date: Sat 31 Dec 88 19:48:58-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue EXIT-EXTENT, v5
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12458959570.23.IIM@ECLA.USC.EDU>

MINIMAL: I don't agree with this, for reasons I have already discussed
somewhat.  Basically, I feel this seriously damages the semantics of the
language, playing havoc with both UNWIND-PROTECT and the definition of
dynamic-scope. 

MEDIUM: Even though the intent of this proposal is what I want, I don't believe
it is really ready for voting yet because the current proposal is poorly
written.  I agree with Moon's comment that this may be hard to write in a
reasonably implementation-independent way.  My intuition is based on the
nesting of forms, but I'm not sure how constraining a writup based on that
would be (though obviously somewhat, since the technique Symbolic's uses would
seem to be invalidated by acceptence of something like this proposal).

This is a hard issue.  Some people feel that MINIMAL is essential because
MEDIUM is too expensive/restrictive for implementors, while other people feel
that (a cleaned up) MEDIUM is essential because MINIMAL is too
expensive/restrictive for users.  Since I favor MEDIUM I would hate to see
this issue die with nothing at all being said, since that can be interpreted as
defacto MINIMAL.  I don't know if I'm going to be able to find the time to
write up anything more coherent though.  Part of the problem I've encountered
when I've tried to do so, is that I think this whole issue is sort of
misdirected.  The problem that needs clarification isn't the extent of exits,
its the dynamic environment in which cleanup forms are executed (in spite of
the fact that the proposal says the extent of other dynamic-extent entities
should be the subject of seperate proposal(s), a claim which I totally disagree
with).  UNWIND-PROTECT cleanup forms are the only place where these proposals
make a difference (to the user).

kab
-------

∂01-Jan-89  0259	CL-Cleanup-mailer 	*** HELP ***    
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 1 Jan 89  02:59:22 PST
Date: Sat 31 Dec 88 19:35:53-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: *** HELP ***
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12458957189.23.IIM@ECLA.USC.EDU>

I don't have copies of the latest versions of some of the issues in Larry's
ballot.  Would some kind person who already has them easily accessable let me
know, and I'll send a list of which issues I need.

And yes, I know they are supposed to be available via anonymous FTP from
Arisia.  Repeated attempts to get them that way have failed.  I keep getting
timeout and failed to synchronize transmission errors.  So far, I haven't even
been able to do a dir on the directory.

Thanks in advance,
kab
-------

∂01-Jan-89  0302	CL-Cleanup-mailer 	Issue FIXNUM-NON-PORTABLE, v4  
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 1 Jan 89  03:02:30 PST
Date: Sat 31 Dec 88 19:47:14-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue FIXNUM-NON-PORTABLE, v4
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12458959255.23.IIM@ECLA.USC.EDU>

Basically, I don't think either proposal really addresses the problem
adequately.  I'm looking at this from the point of view of someone who has
dealt with porting C programs between machines with different native word
sizes, and therefor different definitions of the 'int' type.  I see many of the
same kinds of problems here, and the approach being taken by these proposals
really doesn't do anything about them.

Actually, I think a case could be made in favor of a third proposal,
TOSS-FIXNUM-TOSS-BIGNUM, making it explicit that neither is portable.  I'm not
planning to put this forward as a serious proposal though, since I expect it
would go over like a lead balloon for historical reasons if nothing else.
There are relatively few legitimate uses of FIXNUM in portable code, and
legislating the definition of FIXNUM in a fairly ad hoc way is not going to
improve the situation.  About the only place the FIXNUM type specifier should
appear in portable code is as part of the definition of a type used by the
portable code, with the definition parameterized according to the
implementation being ported to.  Even there it is probably better to use ranged
integer type specifiers.

kab
-------

∂01-Jan-89  2142	CL-Cleanup-mailer 	Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Jan 89  21:42:26 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02548g; Sun, 1 Jan 89 21:38:03 PST
Received: by bhopal id AA21474g; Sun, 1 Jan 89 21:40:16 PST
Date: Sun, 1 Jan 89 21:40:16 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901020540.AA21474@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: pierson%mist@MULTIMAX.ARPA, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 30 Dec 88 17:43 EST <19881230224313.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES

I seem to have no record of past mail on this issue, but I remember at
one time arguing against it since it tended to contradict the agreement
in ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS -- namely (1) that we wouldn't
distinguish between "for declaration" and "for discrimination", and
(2) that the original source-code element-type specifier may be "upgraded"
so that for all intents an purposes you can't recover the "exact declared 
element type".  But if all that Dan wanted to say was that the array
references were assumed to satisfy the *upgrade* of the declared type,
then there would be no problem (with that part).

My name probably got put reference in this proposal because I have
generally given support for the following notion: that there be at least
one mode of operation (interpretation or compilation) in which all type
information is rigidly checked.  I don't think Lucid would be that averse
to some form of required error signaling in this case; but likely it
wouldn't be in interpreted code --  rather, it most easily could be in
code compiled under highest safety [because the interpreter currently 
doesn't pay attention to type declarations].  Contrary to your suggestion, 
I would have thought that Symbolics would offer more resistance to this 
idea than would "stock hardware" implementatons, since many of the latter
have already invested in a compiler cognizant of type declartions.


-- JonL --

∂01-Jan-89  2359	CL-Cleanup-mailer 	Issue SYNTACTIC-ENVIRONMENT-ACCESS  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Jan 89  23:59:42 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02603g; Sun, 1 Jan 89 23:56:03 PST
Received: by bhopal id AA21788g; Sun, 1 Jan 89 23:58:15 PST
Date: Sun, 1 Jan 89 23:58:15 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901020758.AA21788@bhopal>
To: IIM@ECLA.USC.EDU
Cc: cl-cleanup@SAIL.STANFORD.EDU, cl-compikelr@SAIL.STANFORD.EDU
In-Reply-To: Kim A. Barrett's message of Sat 31 Dec 88 19:33:20-PST <12458956724.23.IIM@ECLA.USC.EDU>
Subject: Issue SYNTACTIC-ENVIRONMENT-ACCESS

Eric Benson reads the CL-Cleanup mails, and ocasionally participates
in its discussions.  His address is eb@lucid.com, but he's on vacation 
right now.

I think one can assume that MACRO-FUNCTION and GET-SETF-METHOD will
neeed &environment arguments.  The issue for GET-SETF-METHOD was
"passed" in June 1987.  

I fear that we have let MACRO-FUNCTION drop on the floor.  Larry's
"Issue Status" for the Ft. Collins meeting (Nov 1987) says that
it "need[s a] volunteer" to write it up.  I don't recall seeing a 
subsequent proposal.  It ought to be trivial.

For the record, Lucid's implementation of MACRO-FUNCTION has an
optional second argument for the &environment.


-- JonL --


∂02-Jan-89  1037	CL-Cleanup-mailer 	Issue: REST-LIST-ALLOCATION (Version 3)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89  10:36:26 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513971; Mon 2-Jan-89 13:25:47 EST
Date: Mon, 2 Jan 89 13:25 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REST-LIST-ALLOCATION (Version 3)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881213211541.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890102182514.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 13 Dec 88 21:15 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    This is a tough issue.
    .... discussion elided for brevity ....
    On the basis of the reasoning presented above, my position is that we
    should do the following two things:

     - Drop the NEWLY-ALLOCATED and MUST-SHARE variants as practically
       infeasible and ramp up MAY-SHARE.

I strongly agree with this.

     - Extend MAY-SHARE to include a mechanism that seriously addresses
       the fact that sometimes we need to get a particular kind of
       functionality. Perhaps declarations like
	 (REST-LIST-SHARING :NEVER)
	 (REST-LIST-SHARING :SOMETIMES)     
	 (REST-LIST-SHARING :ALWAYS)
       or
	 (REST-LIST-ALLOCATION :NEW)
	 (REST-LIST-ALLOCATION :UNSPECIFIC)
	 (REST-LIST-ALLOCATION :SHARE)

Upin reflection, I don't support this part.  I can't understand why a
portable program would ever depend on (REST-LIST-SHARING :ALWAYS),
unless it's going to perform side-effects on the &rest list as a way of
passing information back to the caller.  But I strongly believe that
side-effecting such a list is a really bad idea.  Any program that needs
to create and modify a list should use an explicitly created list that
is passed as a normal argument, not the implicitly created list received
as an &rest argument, in my opinion.  Also, as Kent pointed out there
might be implementations in which (REST-LIST-SHARING :ALWAYS) is
impossible to implement.

The other reason for using (REST-LIST-SHARING :ALWAYS) might be a belief
that it enhances efficiency.  But it seems to me that if sharing was
more efficient than not sharing, the implementation would be doing it
already, and in general the implementor knows better than the PORTABLE
programmer what implementation technique for rest arguments is most
efficient.

This leaves (REST-LIST-SHARING :NEVER).  The only justification for this
I can see that is that the program is going to perform side-effects on
the &rest list and wants them insulated from the caller, and furthermore
doesn't want the overhead of calling COPY-LIST in implementations that
don't share.  This is certainly not as unreasonable as
(REST-LIST-SHARING :ALWAYS), but it's still pretty specialized.  I have
two objections to doing this with a declaration rather than with
imperative code.  First: why should

  (defun foo (&rest x)
     (declare (rest-list-sharing :never))
     (remf x :frob)
     ...)

compile into different instructions than

  (defun foo (&rest x)
     (setq x (copy-list x))
     (remf x :frob)
     ...)

An implementation that never shares can easily notice the redundant
call to COPY-LIST and remove it.  All we need is a hint to programmers
and implementors that this is an expected optimization.

Second: declarations other than SPECIAL declarations are supposed to be
"completely optional and correct declarations do not affect the meaning
of a correct program."  A declaration about rest-list-sharing that
makes it valid to perform side-effects on a rest-list clearly does not
fit this dictum of CLtL.  On the other hand, if even with the declaration
it is still not correct to perform side-effects on a rest-list, then
I don't see any use for (REST-LIST-SHARING :NEVER); it can only make a
program slower.

In conclusion, REST-LIST-ALLOCATION:MAY-SHARE without additional
declarations is the only proposal that I find viable and consistent
with the rest of Common Lisp.

∂02-Jan-89  1044	CL-Cleanup-mailer 	Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89  10:44:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513967; Mon 2-Jan-89 12:37:48 EST
Date: Mon, 2 Jan 89 12:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
To: Jon L White <jonl@lucid.com>
cc: pierson%mist@MULTIMAX.ARPA, cl-cleanup@sail.stanford.edu
In-Reply-To: <8901020540.AA21474@bhopal>
Message-ID: <19890102173715.1.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sun, 1 Jan 89 21:40:16 PST
    From: Jon L White <jonl@lucid.com>

    I seem to have no record of past mail on this issue, but I remember at
    one time arguing against it since it tended to contradict the agreement
    in ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS -- namely (1) that we wouldn't
    distinguish between "for declaration" and "for discrimination", and
    (2) that the original source-code element-type specifier may be "upgraded"
    so that for all intents an purposes you can't recover the "exact declared 
    element type".  But if all that Dan wanted to say was that the array
    references were assumed to satisfy the *upgrade* of the declared type,
    then there would be no problem (with that part).

I basically agree with you, but would like to point out one thing that I
hadn't thought of until I read your mail just now.  Since a portable
program cannot know what the upgraded element type is, it must not
assume that all implementations have some objects that are members of
the upgraded element type but not members of the exact declared type.
This means that if it "is an error" for an array element not to be of
the upgraded type, it also "is an error" for an array element not to be
of the exact declared type; either way, a program that does that is not
portable.  So the only real problem with Pierson's proposal is its
proposed change of enforcement of type declarations from "is an error"
to "signals an error".

Now, if we make it "signals an error in the highest safety mode" then
we're back with the same problem: does it signal an error when you
violate the declared type, or only when you violate the upgraded type?
The former provides a more portable definition of when errors are
signalled, but violates the consistency of declaration with
discrimination.  The latter keeps declaration and descrimination
consistent, but means that there are some cases that "are an error" (or
at least are not portable) in lower safety settings, but fail to "signal
an error" in the highest safety setting.

    My name probably got put reference in this proposal because I have
    generally given support for the following notion: that there be at least
    one mode of operation (interpretation or compilation) in which all type
    information is rigidly checked.  I don't think Lucid would be that averse
    to some form of required error signaling in this case; but likely it
    wouldn't be in interpreted code --  rather, it most easily could be in
    code compiled under highest safety [because the interpreter currently 
    doesn't pay attention to type declarations].  Contrary to your suggestion, 
    I would have thought that Symbolics would offer more resistance to this 
    idea than would "stock hardware" implementatons, since many of the latter
    have already invested in a compiler cognizant of type declartions.

I was referring to the suggestion that type information be rigidly checked
in all modes, not just in the highest safety mode.  In fact it would not be
terribly difficult for Symbolics to check all type requirements, including
declarations, rather than just most implicit type requirements, in the
highest safety mode.  What priority this would have for implementation
relative to other things I can't say, but I do know that keeping track of
type declarations in the compiler would not be a major part of the work.
I believe it is a one-line change, actually.

It would be interesting to see the impact of a Lucid implementation where
debugging was easier in compiled code than in interpreted code.

∂02-Jan-89  1045	CL-Cleanup-mailer 	*** HELP ***    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89  10:45:29 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 513972; Mon 2-Jan-89 13:26:59 EST
Date: Mon, 2 Jan 89 13:26 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: *** HELP ***
To: IIM@ECLA.USC.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <12458957189.23.IIM@ECLA.USC.EDU>
Message-ID: <890102132618.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Sat 31 Dec 88 19:35:53-PST
    From: Kim A. Barrett <IIM@ECLA.USC.EDU>

    I don't have copies of the latest versions of some of the issues in Larry's
    ballot.  Would some kind person who already has them easily accessable let me
    know, and I'll send a list of which issues I need. ...

send me your list, and i'll try to get you up to date...

∂02-Jan-89  1202	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 2)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89  12:02:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514009; Mon 2-Jan-89 15:00:49 EST
Date: Mon, 2 Jan 89 15:00 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881115161453.5.KMP@BOBOLINK.SCRC.Symbolics.COM>,
             <881207-180731-2393@Xerox>
Message-ID: <19890102200018.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

I favor DYNAMIC-EXTENT:NEW-DECLARATION over STACK-LET, because
a declaration does seem more appropriate than a new special form.
I favor it over WITH-DYNAMIC-EXTENT, because (as BarMar pointed
out) saying that -all- objects consed during execution of a form
have dynamic extent is too dangerous.

However I cannot support the current version of the DYNAMIC-EXTENT
proposal, basically for the reason that Masinter gave.  See below.
While I'm here I'll also comment on typos.

    Date: Tue, 15 Nov 88 16:14 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    Issue:          DYNAMIC-EXTENT

    Problem Description:

->    Sometimes a programmers knows that a particular data structure
programmer[s]

    Proposal (DYNAMIC-EXTENT:NEW-DECLARATION):

      Other interesting cases are:

            (PROCLAIM '(INLINE G))
            (DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
->          (DEFUN F () (F (LIST 1 2 3)))
The second F should be G.

      What data types (if any) can be stack-allocated will vary from
      implementation to implementation. In some implementations, it might be
      possible to allocate arrays, structures, or instances, for example.

Masinter seems not to have noticed this paragraph, since he complained
that the proposal addressed only lists, so perhaps it should be moved
earlier in the proposal.  I suggest coupling this with the second
paragraph in the proposal section, which makes it clear that the
declaration -allows- the declared object to be stack-allocated
regardless of its type, but does not -require- anything to be
stack-allocated.

The following is where I disagree strongly with the proposal:

      It is very important to note that it is the actual constructor operation
      and not the resulting data type which determines the level of the object
      referred to in the dynamic extent declaration. For example, in

            (LET ((X (LIST 'A1 'B1 'C1))
                  (Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
              (DECLARE (DYNAMIC-EXTENT X Y))
              ...)

      The list (A1 B1 C1) which is the initial value of X will have three cons
      cells, all of which have dynamic extent. The cons (A2 . (B2 C2)) which is
      the initial value of Y will have dynamic extent, but its cdr (B2 C2) will
      have indefinite extent.

I think this is the wrong way to look at it in general, and furthermore
this means that backquote can't be used correctly with the
DYNAMIC-EXTENT declaration, since there is no promise what backquote
expands into.  Also this way of looking at it requires saying silly (in
my opinion) things like:

      If an implementation does not recognize the constructor, it calls
      MACROEXPAND-1 in hopes of seeing a constructor which it does recognize.

A particular implementation might well be implemented this way, but this
should not be the definition of the language!

I propose the following instead.  I admit that this is somewhat stilted,
but I think that is necessary in order to be precise and unambiguous.

The meaning of a dynamic extent declaration is that execution of the
forms in the scope of the declaration will not "save" any "proper part"
of the initial value of the declared variable.  To "save" an object
means to cause a reference to that object to be accessible outside the
dynamic extent of the form at the beginning of whose body the
declaration appears.  An object can be "saved" by storing it with a
side-effecting operation and not replacing it with a different value
before the end of the dynamic extent, by using it as a component of a
freshly-allocated object that is itself "saved," by capturing it in a
function closure that is itself "saved," by returning it as a value, or
by transmitting it outside the dynamic extent with THROW.  A "proper
part" of an object A is any object that is accessible at the beginning
of the scope of the declaration -only- by applying a function to A or to
a "proper part" of A.  This means that any objects freshly allocated
during the construction of the initial value of the declared variable,
and not "saved" during the construction of that value, are "proper
parts" and can be allocated on a stack.

Returning to the example
            (LET ((X (LIST 'A1 'B1 'C1))
                  (Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
              (DECLARE (DYNAMIC-EXTENT X Y))
              ...)

The "proper parts" of X are three conses, and the "proper parts" of Y
are three other conses.  None of the symbols A1, B1, C1, A2, B2, C2, or
NIL is a "proper part" of X or Y.  However, if a freshly allocated
uninterned symbol had been used, it would have been a "proper part."

    Test Case:

          (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 "proper parts" 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 a "proper part" 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 a "proper part", 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.

I hope no one misreads the above as an argument that my proposal is too
complicated, since it does not derive at all from my proposal, but only
from the way Common Lisp works.

    Discussion:

      Actually, a blurry issue is whether
       (LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
       => 1
      is well-defined. I refer to these stack-allocated things as being invalid
      return values, but in fact we might want to say that they're ok to return
      but that you just can't do any serious operations on them (ie, you can't
      expect them to still be lists, etc.) Can anyone imagine a pointer into
      unallocated stack causing problems for their GC? If so, we could be more
      clear on this point.

In some if not all implementations, the part of the stack above the
current stack pointer can have its contents changed at any time by an
interrupt, possibly to something that will cause LIST to blow out when
it stores it into the CAR of the CONS it creates.  That's an
implementational point of view.  From a language point of view, I do not
believe you can make a coherent definition of "serious operations."  I
don't think this is a blurry issue at all, I think it's quite clear that
returning an object as a value is "saving" it regardless of what the
caller actually does with the value.  I would say that even

  (PROGN (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)
         NIL)

is an error.

    Date: 7 Dec 88 18:05 PST
    From: masinter.pa@Xerox.COM

    Version 2 of this writeup didn't mention one of the criticisms I sent on 1
    July, namely:

    "a) it is disturbing to introduce a construct within which a casual change
    of (CONS X (LIST Y Z)) to  (LIST X Y Z) could introduce a serious bug
    (e.g., if the tail were stashed away
    somewhere.)"

I quite agree with this.  My proposed alternative definition doesn't have any
problems like this, since it is defined in terms of the actual object, not in
terms of how it was constructed.

    I wonder if it might be useful to think about what the semantics of
    declaring something to be "dynamic extent" really means. 

    For example, I think of a type declaration as a promise from the programmer
    to the compiler that a TYPEP assertion will at certain points (exactly what
    points being subject to some debate).

    When you declare something as DYNAMIC-EXTENT, what is it you are promising
    to the compiler? That the value of the variable or any part of it will not
    be newly stored in any other permanent structure? It or any subpart of it
    will not be referenced outside of the dynamic extent of the enclosing form?

My proposed alternative definition addresses this, I believe.  I'd be interested
to hear if anyone can find any imprecisenesses in it.

∂02-Jan-89  1233	CL-Cleanup-mailer 	Issue: REST-LIST-ALLOCATION (Version 3)  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89  12:33:16 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514015; Mon 2-Jan-89 15:32:02 EST
Date: Mon, 2 Jan 89 15:31 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REST-LIST-ALLOCATION (Version 3)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881213211541.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Supersedes: <19890102182514.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: In the previous transmission I left out part of what I had intended to say.
Message-ID: <19890102203124.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 13 Dec 88 21:15 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    This is a tough issue.
    .... discussion elided for brevity ....
    On the basis of the reasoning presented above, my position is that we
    should do the following two things:

     - Drop the NEWLY-ALLOCATED and MUST-SHARE variants as practically
       infeasible and ramp up MAY-SHARE.

I strongly agree with this.  MUST-SHARE is out because some implementations
cannot implement it.  NEWLY-ALLOCATED is not as bad, but I want to rebut an
argument that was given in favor of it:

  (defvar *message*)
  (defun set-message (&rest mess)
    (setq *message* mess))
  (let ((winner (list 'a 'winner)))
    (apply #'set-message winner)
    (setf (cdr winner) (list 'loser))
    winner)
  Is *message* (A WINNER) or (A LOSER)?  With MAY-SHARE, the answer is
  implementation-dependent, with NEWLY-ALLOCATED the answer is (A WINNER).

Consider this similar program:

  (defvar *message*)
  (defun set-message (mess)
    (setq *message* mess))
  (let ((winner (list 'a 'winner)))
    (funcall #'set-message winner)
    (setf (cdr winner) (list 'loser))
    winner)
  The answer is (A LOSER).

All I did was change APPLY to FUNCALL, and remove the corresponding
&REST.  I find it inconsistent if calling with APPLY is guaranteed to
copy one of the arguments, but calling with FUNCALL is not.  I think
all the example shows is that programs with side-effects are generally
more difficult to understand than programs without side-effects, and
we certainly won't fix that by tweaking the definition of APPLY.

     - Extend MAY-SHARE to include a mechanism that seriously addresses
       the fact that sometimes we need to get a particular kind of
       functionality. Perhaps declarations like
	 (REST-LIST-SHARING :NEVER)
	 (REST-LIST-SHARING :SOMETIMES)     
	 (REST-LIST-SHARING :ALWAYS)
       or
	 (REST-LIST-ALLOCATION :NEW)
	 (REST-LIST-ALLOCATION :UNSPECIFIC)
	 (REST-LIST-ALLOCATION :SHARE)

Upin reflection, I don't support this part.  I can't understand why a
portable program would ever depend on (REST-LIST-SHARING :ALWAYS),
unless it's going to perform side-effects on the &rest list as a way of
passing information back to the caller.  But I strongly believe that
side-effecting such a list is a really bad idea.  Any program that needs
to create and modify a list should use an explicitly created list that
is passed as a normal argument, not the implicitly created list received
as an &rest argument, in my opinion.  Also, as Kent pointed out there
might be implementations in which (REST-LIST-SHARING :ALWAYS) is
impossible to implement.

The other reason for using (REST-LIST-SHARING :ALWAYS) might be a belief
that it enhances efficiency.  But it seems to me that if sharing was
more efficient than not sharing, the implementation would be doing it
already, and in general the implementor knows better than the PORTABLE
programmer what implementation technique for rest arguments is most
efficient.

This leaves (REST-LIST-SHARING :NEVER).  The only justification for this
I can see that is that the program is going to perform side-effects on
the &rest list and wants them insulated from the caller, and furthermore
doesn't want the overhead of calling COPY-LIST in implementations that
don't share.  This is certainly not as unreasonable as
(REST-LIST-SHARING :ALWAYS), but it's still pretty specialized.  I have
two objections to doing this with a declaration rather than with
imperative code.  First: why should

  (defun foo (&rest x)
     (declare (rest-list-sharing :never))
     (remf x :frob)
     ...)

compile into different instructions than

  (defun foo (&rest x)
     (setq x (copy-list x))
     (remf x :frob)
     ...)

An implementation that never shares can easily notice the redundant
call to COPY-LIST and remove it.  All we need is a hint to programmers
and implementors that this is an expected optimization.

Second: declarations other than SPECIAL declarations are supposed to be
"completely optional and correct declarations do not affect the meaning
of a correct program."  A declaration about rest-list-sharing that
makes it valid to perform side-effects on a rest-list clearly does not
fit this dictum of CLtL.  On the other hand, if even with the declaration
it is still not correct to perform side-effects on a rest-list, then
I don't see any use for (REST-LIST-SHARING :NEVER); it can only make a
program slower.

In conclusion, REST-LIST-ALLOCATION:MAY-SHARE without additional
declarations is the only proposal that I find viable and consistent
with the rest of Common Lisp.

∂02-Jan-89  1328	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89  13:28:15 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 514035; 2 Jan 89 16:26:46 EST
Date: Mon, 2 Jan 89 16:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 1)
To: CL-Cleanup@sail.stanford.edu
cc: Common-Lisp-Object-System@Sail.Stanford.edu, CL-Compiler@Sail.Stanford.edu
In-Reply-To: <19881229175913.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890102212611.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

This was discussed on the clos and compiler lists.  I thought it would
be a good idea to write it up for discussion and give the cleanup group
a look at it.  I think it's something that fell in the cracks between
these three subcommittees.

Issue:         LOAD-OBJECTS

References:    none

Related issues: none

Category:      ADDITION

Edit history:  Version 1, 2-Jan-89, by Moon (for discussion)

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 one value.  The value is a form which, when
  evaluated at some later 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.

  Define that COMPILE-FILE calls MAKE-LOAD-FORM on any object that
  appears in a constant and has STANDARD-CLASS or STRUCTURE-CLASS as a
  metaclass.  Define that COMPILE-FILE will only call MAKE-LOAD-FORM
  once for any given object (compared with EQ) within a single file.

  It is unspecified whether LOAD calls EVAL on the form or does some
  other operation that has an equivalent effect.

  Define that an instance of a class defined with DEFCLASS without any
  direct superclasses, or defined with DEFSTRUCT without the :TYPE or
  :INCLUDE options, does not inherit any method for MAKE-LOAD-FORM other
  than possibly a method that only signals an error.

Example:

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

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

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.

  A default method, such as one that makes an object whose class has the
  same name and whose slots have equivalent contents, is not supplied
  because this is inappropriate for many objects and because it is easy
  to write for those objects where it is appropriate.

  MAKE-LOAD-FORM has a natural resemblance to PRINT-OBJECT.

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.

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.

∂02-Jan-89  1444	CL-Cleanup-mailer 	[Kim A. Barrett <IIM@ECLA.USC.EDU>: Ballot reply]  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  14:44:02 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 14:42:54 PST
Date: 2 Jan 89 14:42 PST
From: masinter.pa@Xerox.COM
Subject: [Kim A. Barrett <IIM@ECLA.USC.EDU>: Ballot reply]
To: cl-cleanup@sail.stanford.edu
Message-ID: <890102-144254-1696@Xerox>

Hi -- I'm reading answering the volumes of mail I have in a fairly random
order, so things will come out of sync.

Some ballots came in only to me, so I'm forwarding them to the entire
committee, and will prepare a summary/status report.


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

Return-Path: <IIM@ECLA.USC.EDU>
Received: from ECLA.USC.EDU ([26.21.0.65]) by Xerox.COM ; 01 JAN 89
05:11:50 PST
Date: Sat, 31 Dec 88 19:53:52 PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Ballot reply
To: masinter.pa
cc: iim@ECLA.USC.EDU
Message-ID: <12458960461.23.IIM@ECLA.USC.EDU>

Larry,

Here is my response to the cleanup ballot.  This can be considered the
'official' position of IIM.  I've included extensive comments on a few
issues.
I consider some of these issues controversial, and not appropriate to a
block
vote.  I've commented on some of them as to why I think they have problems.
I'm going to send these comments out for general distribution so that
people
can respond, but I'm also including them here to help you tell which ones
I'm
just voting yes/no on and which ones I think need further work or should be
voted separately. 

I have not voted on the following issues because I don't have a copy of the
current proposal to read.  If I can obtain copies of them in time I'll send
a
seperate response for just them. Yes, I know about /clcleanup/pending on
arisia, but repeated FTP attempts haven't gotten me anywhere.

kab


===============================================================================
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
DECLARE-TYPE-FREE:ALLOW
FUNCTION-DEFINITION:FUNCTION-SOURCE
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
HASH-TABLE-TESTS:ADD-EQUALP
LAMBDA-FORM:NEW-MACRO
LCM-NO-ARGUMENTS:1
LISP-SYMBOL-REDEFINITION:DISALLOW
NTH-VALUE:ADD
PACKAGE-DELETION:NEW-FUNCTION
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
RETURN-VALUES-UNSPECIFIED:SPECIFY
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
SETF-PLACES:ADD-SETF-FUNCTIONS
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
SYMBOL-MACROLET-DECLARE:ALLOW
TAGBODY-CONTENTS:FORBID-EXTENSION
TEST-NOT-IF-NOT:FLUSH-ALL
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE

===============================================================================

And now for the voting ...


===============================================================================
ARGUMENTS-UNDERSPECIFIED:SPECIFY
	Version 4, 21-Sep-88, Mailed 4 Dec 88

YES

===============================================================================
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
	Version 1, 14-Sep-88, Mailed 6 Oct 88

YES

===============================================================================
DECLARATION-SCOPE:NO-HOISTING
DECLARATION-SCOPE:LIMITED-HOISTING
	Version 4, 15-Nov-88, Mailed 9-Dec-88

NO on both proposals.

I really don't like NO-HOISTING because it is too imcompatible.  I think I
could live with LIMITED-HOISTING, but I'm unconvinced of the need for such
an
incompatible change.  All of the problem examples are easily solved by
simply
changing some of the variable names.


===============================================================================
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
	Version 2, 30-Sep-88, Mailed 6 Oct 88

YES

===============================================================================
DEFPACKAGE:ADDITION
	Version 7, 2-Nov-88, Mailed 5 Dec 88

YES

===============================================================================
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
	Version 2, 21-Sep-88, Mailed 6 Oct 88

While I support the concept, the wording needs cleanup.  If these problems
are
fixed, then I'll vote YES.

1. The proposal explicitely says to allow &OPTIONAL, &KEY, and &AUX
keywords,
but fails to mention &REST and &ALLOW-OTHER-KEYS.

2. The proposal does not say how defaulting is to be done when the
programmer
doesn't supply a default value for a keyword argument.  I assume that the
intent is that it will do defaulting in the same way &OPTIONAL arguments
are
specified to default in CLtL, ie. if no default is supplied in the
lambda-list
then use the slot initform, else undefined.

3. The proposal does not say which of key/var gets matched to the slot name
in
keyword parameter specifiers of the form ((key var) [default [svar]]).  I
assume that it should be var that gets matched, since that gives the
programmer
the most options, but this needs to be stated explicitely.

Note for Current Practice:  The latest version of IIM Common Lisp
implements
this.

===============================================================================
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
	Version 3, 7 Dec 88, Mailed 12-Dec-88

YES

===============================================================================
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
	Version 4, 31-Oct-88, Mailed 12-Dec-88

YES

===============================================================================
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
DESCRIBE-INTERACTIVE:NO
	Version 4, 15-Nov-88	, Mailed 7-Dec-88

EXPLICITLY-VAGUE: ABSTAIN
NO: YES

I sort of agree with the arguments for disallowing interaction, but I won't
be
too upset if the NO proposal gets shot down and we have to go to
EXPLICTLY-VAGUE. 

===============================================================================
DOTTED-MACRO-FORMS:ALLOW
	Version 3, 15-Nov-88, Mailed 7-Dec-88

YES

===============================================================================
EQUAL-STRUCTURE:STATUS-QUO
	Version 5, 1-Oct-88, Mailed 8 Oct 88

I thought this had been pretty well hashed out, so I was surprised to find
some
serious problems with the proposal.  While I support the general idea of
the
proposal, I can't vote in favor of it in its current form.  If these things
get
cleaned up, then I'll vote YES.  Note that all of my problems with the
current
proposal have to do with EQUALP; I agree with the proposal for EQUAL, and
would
vote YES for it as a seperate issue if the EQUALP stuff can't be resolved
in
time. 

1. The description of EQUALP's behavior does not match CLtL, since it
references EQUAL more than it ought.  Specifically, characters should be
compared with CHAR-EQUAL, and numbers should be compared with =, while the
proposal says EQL for numbers (by defaulting to EQUAL) and is ambiguous
about
characters (could be EQL (by defaulting to EQUAL) or CHAR-EQUAL (since
string
comparisons are case insensitive)).

2. The proposal says EQUALP descends arrays, structures, and instances, but
uses EQ on other types, and gives hash-tables as an example of a data type
which is not descended.  What if, in a given implementation, hash-tables
are
implemented using structures or instances.  Does this mean that such an
implementation must include code in EQUALP to explicitely prevent
descending
into hash-tables (and presumably any other COMMON types which are
implemented
using structures or instances)?  This question has to be answered if the
use of
EQUALP is to have any chance of being portable when applied to such
objects.

===============================================================================
EXIT-EXTENT:MINIMAL
EXIT-EXTENT:MEDIUM
	Version 5, 12-Dec-88, Mailed 12-Dec-88

MINIMAL:  NO, for reasons I have discussed on the mailing list.  Basically,
I
feel this seriously damages the semantics of the language, playing havoc
with
both UNWIND-PROTECT and the definition of dynamic-scope.

MEDIUM:  Currently NO, even though the intent of this proposal is what I
want,
because the current proposal is poorly written.  I don't believe it is
really
ready for voting yet.  I agree with Moon's comment that this may be hard to
write in a reasonably implementation-independent way.  My intuition is
based on
the nesting of forms, but I'm not sure how constraining a writup based on
that
would be (though obviously somewhat, since the technique Symbolic's uses is
invalidated by acceptence of something like this proposal).

===============================================================================
EXPT-RATIO:P.211
	Version 3, 31-Oct-88, Mailed 7 Dec 88

YES

===============================================================================
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
	Version 4, 7-Dec-88, Mailed 12-Dec-88

NO on both.

Basically, I don't think either proposal really addresses the problem
adequately.  I'm looking at this from the point of view of someone who has
dealt with porting C programs between machines with different native word
sizes, and therefor different definitions of the 'int' type.  I see many of
the
same kinds of problems here, and the approach being taken by these
proposals
really doesn't do anything about them.

Actually, I think a case could be made in favor of a third proposal,
TOSS-FIXNUM-TOSS-BIGNUM, making it explicit that neither is portable.  I'm
not
planning to put this forward as a serious proposal though, since I expect
it
would go over like a lead balloon for historical reasons if nothing else.
There are relatively few legitimate uses of FIXNUM in portable code, and
legislating the definition of FIXNUM in a fairly ad hoc way is not going to
improve the situation.  About the only place the FIXNUM type specifier
should
appear in portable code is as part of the definition of a type used by the
portable code, with the definition parameterized according to the
implementation being ported to.  Even there it is probably better to use
ranged
integer type specifiers.

===============================================================================
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
	Version 2, 2 Oct 88, Mailed 6 Oct 88

YES

===============================================================================
FORMAT-PRETTY-PRINT:YES
	Version 7, 15 Dec 88, Mailed 7 Dec 88

YES

===============================================================================
FUNCTION-COMPOSITION:NEW-FUNCTIONS
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
	Version 4, 12 Dec 88, Mailed 12 Dec 88

NEW-FUNCTIONS: NO.  I agree with some of the discussion that this is an
inadequate set of operators, it is untested by the community, and serves no
visible need.  Encourage people to add extensions like this, and we'll see
what
results when we do CL9x (or CL2001).

COMPLEMENT-AND-ALWAYS: YES.  I can see COMPLEMENT being a useful standard
shorthand that makes the removal of the :test-not and -if-not stuff more
palatable.

===============================================================================
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
	Version 3, 7-Dec-88, Mailed  12-Dec-88

YES

===============================================================================
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
	Version 5, 14-Nov-88	, Mailed 8-Dec-88

NO

===============================================================================
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
	Version 1, 11-Nov-88	, Mailed 12 Dec 88

YES.

There is a minor glitch in an aside that needs to be fixed.  Paragraph 3 of
item 3 says that the following code would be acceptable as the <sxh>
function
for EQL tables:

  (if (numberp x) (sxhash x) (%unique-no x))

In general, the NUMBERP test really should be (OR (NUMBERP X) (CHARACTERP
X)),
to correspond properly to the definition of EQL.

===============================================================================
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
	Version 4, 12-Dec-88, Mailed 12-Dec-88

YES

===============================================================================
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
	Version 2, 8 Oct 88, Mailed 12-Dec-88

NO

===============================================================================
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
	Version 2, 09-Jun-88, Mailed 8 Oct 88

YES

===============================================================================
PACKAGE-CLUTTER:REDUCE
	Version 6, 12-Dec-88, Mailed 12-Dec-881

YES, but note such that symbols which are documented special-forms are also
FBOUNDP.

===============================================================================
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
	Version 3, 8-Oct-88, Mailed 8 Oct 88

YES

However, I think it should be mentioned that this implies that PEEK-CHAR is
really no longer equivelent to read-char followed by unread-char, and can't
be
implemented that way for any kind of metastream.  All metastreams must now
support PEEK-CHAR directly, and pass it along to the indirect streams, in
case
some of those streams are echo streams.  This mostly increases the cost to
implementors, though it is also a cost to users in systems where the set of
metastreams is user-extensible. 

===============================================================================
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
	Version 3, 20 Sep 88, Mailed 8 Oct 88

YES

===============================================================================
PROCLAIM-LEXICAL:LG
	Version 9, 8-Dec-88, Mailed 12-Dec-88


===============================================================================
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
	Version 1, 14-Sep-88, Mailed 7 Oct 88

YES

===============================================================================
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
	Version 6, 9 Dec 88, mailed 09 Dec 88

YES

===============================================================================
REST-LIST-ALLOCATION:NEWLY-ALLOCATED
REST-LIST-ALLOCATION:MAY-SHARE
REST-LIST-ALLOCATION:MUST-SHARE
	Version 3, 12-Dec-88, mailed 12-Dec-88

NEWLY-ALLOCATED: NO
MUST-SHARE: NO

I feel that both of these take away too much implementation freedom.  Which
leaves us with ...

MAY-SHARE: YES.

But I'd like to see something added that allows the programmer to force
copying
when she cares, without requiring an explicit call to COPY-LIST (possibly
featurized).  Note that most cases of COPY-LIST on &REST parameters that
I've
seen had nothing to do with the question of whether apply => &rest could
share;
they were put in to deal with implementations which always stack-cons &rest
lists.

===============================================================================
ROOM-DEFAULT-ARGUMENT:NEW-VALUE
	Version 1 12-Sep-88 mailed 8 Oct 88

YES

I liked KMP's suggestion of defining additional synonyms:
  :short    ==  nil
  :medium   ==  :default
  :long     ==  t
This could be done as a seperate proposal, but hardly seems worth the
effort.

===============================================================================
SETF-SUB-METHODS:DELAYED-ACCESS-STORES
	Version 5, 12-Feb-88 mailed 8 Oct 88

YES

===============================================================================
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
	Version 8, 8 Jul 88, Mailed 7 Oct 88

YES

===============================================================================
STEP-ENVIRONMENT:CURRENT
	Version 3, 20-Jun-88, mailed  7 Oct 88

I have no problem with TIME behaving as proposed.  I have serious problems
with
STEP though, as far as compiled behavior.  I don't agree that it is easy to
get
the environment right in this case, because it would require the
interpreter to
handle compiler data structures, which might not even be possible.  Maybe
I'm
misunderstanding what is wanted for compiled STEP.  If what is wanted is
that
execution of interpreted code which occurs within the context of the STEP
macro
should be stepped, then that's ok, and I'll vote YES.

===============================================================================
SUBTYPEP-TOO-VAGUE:CLARIFY
	Version 4,  7-Oct-88, mailed 7 Oct 88 

YES

===============================================================================
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
	Version 5, 30-Nov-88, mailed 9 Dec 88

YES

===============================================================================
TAILP-NIL:T
	Version 5, 9-Dec-88, mailed 12-Dec-88

YES

===============================================================================
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
	Version 3, 12-Dec-88, mailed 12 Dec 88
	(some "bugs" in the proposal)

YES, assuming bugs are fixed.  Include Moon's phrasing of the constraint I
brought up: (SUBTYPEP (TYPE-OF X) (CLASS-OF X)) => T T, for all X.

===============================================================================
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
	Version 2, 2-Dec-88, mailed 12-Dec-88

YES
-------


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

∂02-Jan-89  1455	CL-Cleanup-mailer 	re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  14:54:57 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 14:53:09 PST
Date: 2 Jan 89 14:52 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-145309-1706@Xerox>

DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
	Version 2, 21-Sep-88, Mailed 6 Oct 88

While I support the concept, the wording needs cleanup.  If these problems are
fixed, then I'll vote YES.

1. The proposal explicitely says to allow &OPTIONAL, &KEY, and &AUX keywords,
but fails to mention &REST and &ALLOW-OTHER-KEYS.

2. The proposal does not say how defaulting is to be done when the programmer
doesn't supply a default value for a keyword argument.  I assume that the
intent is that it will do defaulting in the same way &OPTIONAL arguments are
specified to default in CLtL, ie. if no default is supplied in the lambda-list
then use the slot initform, else undefined.

3. The proposal does not say which of key/var gets matched to the slot name in
keyword parameter specifiers of the form ((key var) [default [svar]]).  I
assume that it should be var that gets matched, since that gives the programmer
the most options, but this needs to be stated explicitely.

Note for Current Practice:  The latest version of IIM Common Lisp implements
this.

∂02-Jan-89  1517	CL-Cleanup-mailer 	re: Issue: EQUAL-STRUCTURE (Version 5)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  15:17:11 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:16:05 PST
Date: 2 Jan 89 15:15 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: EQUAL-STRUCTURE (Version 5)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-151605-1724@Xerox>

I thought this had been pretty well hashed out, so I was surprised to find some
serious problems with the proposal.  While I support the general idea of the
proposal, I can't vote in favor of it in its current form.  If these things get
cleaned up, then I'll vote YES.  Note that all of my problems with the current
proposal have to do with EQUALP; I agree with the proposal for EQUAL, and would
vote YES for it as a seperate issue if the EQUALP stuff can't be resolved in
time. 

1. The description of EQUALP's behavior does not match CLtL, since it
references EQUAL more than it ought.  Specifically, characters should be
compared with CHAR-EQUAL, and numbers should be compared with =, while the
proposal says EQL for numbers (by defaulting to EQUAL) and is ambiguous about
characters (could be EQL (by defaulting to EQUAL) or CHAR-EQUAL (since string
comparisons are case insensitive)).

2. The proposal says EQUALP descends arrays, structures, and instances, but
uses EQ on other types, and gives hash-tables as an example of a data type
which is not descended.  What if, in a given implementation, hash-tables are
implemented using structures or instances.  Does this mean that such an
implementation must include code in EQUALP to explicitely prevent descending
into hash-tables (and presumably any other COMMON types which are implemented
using structures or instances)?  This question has to be answered if the use of
EQUALP is to have any chance of being portable when applied to such objects.

∂02-Jan-89  1517	CL-Cleanup-mailer 	re: Issue: EXIT-EXTENT (Version 5)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  15:17:47 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:16:42 PST
Date: 2 Jan 89 15:16 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: EXIT-EXTENT (Version 5)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-151642-1725@Xerox>

MINIMAL:  NO, for reasons I have discussed on the mailing list.  Basically, I
feel this seriously damages the semantics of the language, playing havoc with
both UNWIND-PROTECT and the definition of dynamic-scope.

MEDIUM:  Currently NO, even though the intent of this proposal is what I want,
because the current proposal is poorly written.  I don't believe it is really
ready for voting yet.  I agree with Moon's comment that this may be hard to
write in a reasonably implementation-independent way.  My intuition is based on
the nesting of forms, but I'm not sure how constraining a writup based on that
would be (though obviously somewhat, since the technique Symbolic's uses is
invalidated by acceptence of something like this proposal).

∂02-Jan-89  1521	CL-Cleanup-mailer 	re: Issue: EXIT-EXTENT (Version 5)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  15:21:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:17:30 PST
Date: 2 Jan 89 15:16 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: EXIT-EXTENT (Version 5)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-151730-1728@Xerox>

MINIMAL:  NO, for reasons I have discussed on the mailing list.  Basically, I
feel this seriously damages the semantics of the language, playing havoc with
both UNWIND-PROTECT and the definition of dynamic-scope.

MEDIUM:  Currently NO, even though the intent of this proposal is what I want,
because the current proposal is poorly written.  I don't believe it is really
ready for voting yet.  I agree with Moon's comment that this may be hard to
write in a reasonably implementation-independent way.  My intuition is based on
the nesting of forms, but I'm not sure how constraining a writup based on that
would be (though obviously somewhat, since the technique Symbolic's uses is
invalidated by acceptence of something like this proposal).

∂02-Jan-89  1521	CL-Cleanup-mailer 	re: Issue: FIXNUM-NON-PORTABLE (Version 4)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  15:21:42 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:18:16 PST
Date: 2 Jan 89 15:17 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: FIXNUM-NON-PORTABLE (Version 4)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-151816-1730@Xerox>

NO on both.

Basically, I don't think either proposal really addresses the problem
adequately.  I'm looking at this from the point of view of someone who has
dealt with porting C programs between machines with different native word
sizes, and therefor different definitions of the 'int' type.  I see many of the
same kinds of problems here, and the approach being taken by these proposals
really doesn't do anything about them.

Actually, I think a case could be made in favor of a third proposal,
TOSS-FIXNUM-TOSS-BIGNUM, making it explicit that neither is portable.  I'm not
planning to put this forward as a serious proposal though, since I expect it
would go over like a lead balloon for historical reasons if nothing else.
There are relatively few legitimate uses of FIXNUM in portable code, and
legislating the definition of FIXNUM in a fairly ad hoc way is not going to
improve the situation.  About the only place the FIXNUM type specifier should
appear in portable code is as part of the definition of a type used by the
portable code, with the definition parameterized according to the
implementation being ported to.  Even there it is probably better to use ranged
integer type specifiers.

∂02-Jan-89  1524	CL-Cleanup-mailer 	re: Issue: PACKAGE-CLUTTER:REDUCE (Version 6) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  15:24:32 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:22:33 PST
Date: 2 Jan 89 15:22 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: PACKAGE-CLUTTER:REDUCE (Version 6)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-152233-1735@Xerox>

YES, but note such that symbols which are documented special-forms are also
FBOUNDP.

∂02-Jan-89  1525	CL-Cleanup-mailer 	re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  15:24:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:23:48 PST
Date: 2 Jan 89 15:23 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-152348-1739@Xerox>

However, I think it should be mentioned that this implies that PEEK-CHAR is
really no longer equivelent to read-char followed by unread-char, and can't be
implemented that way for any kind of metastream.  All metastreams must now
support PEEK-CHAR directly, and pass it along to the indirect streams, in case
some of those streams are echo streams.  This mostly increases the cost to
implementors, though it is also a cost to users in systems where the set of
metastreams is user-extensible. 

∂02-Jan-89  1524	CL-Cleanup-mailer 	re: Issue: HASH-TABLE-STABILITY (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  15:24:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:21:01 PST
Date: 2 Jan 89 15:20 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: HASH-TABLE-STABILITY (Version 1)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-152101-1732@Xerox>

There is a minor glitch in an aside that needs to be fixed.  Paragraph 3 of
item 3 says that the following code would be acceptable as the <sxh> function
for EQL tables:

  (if (numberp x) (sxhash x) (%unique-no x))

In general, the NUMBERP test really should be (OR (NUMBERP X) (CHARACTERP X)),
to correspond properly to the definition of EQL.

∂02-Jan-89  1528	CL-Cleanup-mailer 	re: Issue: REST-LIST-ALLOCATION (Version 3)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  15:27:50 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:26:43 PST
Date: 2 Jan 89 15:25 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: REST-LIST-ALLOCATION (Version 3)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-152643-1745@Xerox>

NEWLY-ALLOCATED: NO
MUST-SHARE: NO

I feel that both of these take away too much implementation freedom.  Which
leaves us with ...

MAY-SHARE: YES.

But I'd like to see something added that allows the programmer to force copying
when she cares, without requiring an explicit call to COPY-LIST (possibly
featurized).  Note that most cases of COPY-LIST on &REST parameters that I've
seen had nothing to do with the question of whether apply => &rest could share;
they were put in to deal with implementations which always stack-cons &rest
lists.

∂02-Jan-89  1529	CL-Cleanup-mailer 	re: Issue: STEP-ENVIRONMENT (Version 3)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  15:29:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 15:28:10 PST
Date: 2 Jan 89 15:27 PST
Sender: masinter.pa@Xerox.COM
Subject: re: Issue: STEP-ENVIRONMENT (Version 3)
To: cl-cleanup@sail.stanford.edu
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Message-ID: <890102-152810-1747@Xerox>

I have no problem with TIME behaving as proposed.  I have serious problems with
STEP though, as far as compiled behavior.  I don't agree that it is easy to get
the environment right in this case, because it would require the interpreter to
handle compiler data structures, which might not even be possible.  Maybe I'm
misunderstanding what is wanted for compiled STEP.  If what is wanted is that
execution of interpreted code which occurs within the context of the STEP macro
should be stepped, then that's ok, and I'll vote YES.

∂02-Jan-89  1635	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89  16:34:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514100; Mon 2-Jan-89 19:33:29 EST
Date: Mon, 2 Jan 89 19:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 9)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890103003245.0.MOON@EUPHRATES.SCRC.Symbolics.COM>

There was considerable discussion about the released version 8 not
reflecting the concensus of the committee.  I don't feel strongly about
this either way, but as an aid in discussion I have prepared this
version, which contains two proposals.

The argument is about whether a type declaration affects only variable
references within its scope, or also affects variable references that
are outside the scope of the declaration but dynamically inside the
execution of a form that is itself inside the scope of the declaration.
This really has nothing to do with the original goal of the proposal,
since exactly the same issue arises for a type declaration attached
to a binding of a special variable.


Forum:         Cleanup
Issue:         DECLARE-TYPE-FREE
References:    CLtL p.158
               DECLARATION-SCOPE
Related issues: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
               DECLARATION-SCOPE
Category:      CLARIFICATION/ADDITION

Edit history:  Version 1, 18-Sep-88, Moon
               Version 2, 22-Sep-88, Moon
                (small edits to reflect mail discussion)
               Version 3, 22-Sep-88, Masinter
               Version 4, 27-Sep-88, JonL 
               Version 5, 30-Sep-88, Masinter (cost to implementors)
               Version 6, 06-Oct-88, Pitman (minor edits in Discussion)
               Version 7,  5-Dec-88, Masinter (scope->extent)
               Version 8,  7-Dec-88, Masinter (back to scope)
               Version 9,  2-Jan-89, Moon (2 proposals, to clarify discussion)


Problem description:

  Section 9.2 of CLtL, p158, says that a declaration specifier like
  (TYPE type var1 var2 ...) "... affects only variable bindings".  
  Since declarations can occur in contexts other than establishing 
  "variable bindings", most people interpret this statement to mean 
  that type declarations not in such context are either (1) completely 
  to be ignored, or (2) invalid CL  syntax.  Thus both of the following 
  forms would be suspect in that the type declarations could not have 
  any effect:

    (if (and (typep x 'fixnum) (typep y 'fixnum))
        (locally (declare (fixnum x y))             ;LOCALLY does not bind
          ...algorithm using x and y...)            ; any variables.
        ...similar algorithm using x and y...)

    (let ((y 'foo))
      (setq y 10)
      (let ((x 5))                                  ;'y' is not being bound in
        (declare (fixnum y))                        ; this particular context.
        (incf y)
         ...random algorithm...))


Proposal (DECLARE-TYPE-FREE:ALLOW):
  
  Specify that a type declaration does not only "affect variable bindings";
  rather, type declarations are legal in all declarations. The interpretation
  of a type declaration is that, during the execution of any expression 
  within the scope of the declaration,  it is an error for the value of
  the declared variable not to be of the declared type. For declarations
  that are associated with variable bindings, the type declaration also
  applies to the initial binding of the variable. In the special case
  of a declaration for which there are no executable expressions
  within the scope of the declaration (e.g., (locally (declare (integer x)))),
  the result is as if there were executable expressions.

  In this proposal, a type declaration affects not only variable
  references within its scope, but also affects variable references that
  are outside the scope of the declaration but dynamically inside the
  execution of a form that is itself inside the scope of the
  declaration.  Such references can exist when the variable is SPECIAL
  or when the declaration is not attached to the variable's binding, so
  that the scope of the declaration does not include the entire scope
  of the variable.


Proposal (DECLARE-TYPE-FREE:LEXICAL):

  Specify that a type declaration does not only "affect variable bindings";
  rather, type declarations are legal in all declarations. The interpretation
  of a type declaration is that, during the execution of any reference to the
  declared variable within the scope of the declaration, it is an error for
  the value of the declared variable not to be of the declared type; and
  during the execution of any SETQ of the declared variable within the scope
  of the declaration, it is an error for the newly assigned value of the
  declared variable not to be of the declared type; and at the moment the
  scope of the declaration is entered, it is an error for the value of the
  declared variable not to be of the declared type.

  In this proposal, a type declaration affects only variable references within
  its scope, and the meaning of "free" and "variable-binding-associated" type
  declarations can be described identically.

  This proposal is equivalent to saying that the meaning of a type declaration
  is equivalent to changing each reference to <var> within the scope of the
  declaration to (THE <type> <var>), changing each expression assigned to the
  variable within the scope of the declaration to (THE <type> <new-value>),
  and executing (THE <type> <var>) at the moment the scope of the declaration
  is entered.


Examples:

;; this is an error under DECLARE-TYPE-FREE:ALLOW:
;; the assertion that x is a fixnum is violated between the two 
;; calls to (zap)
;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL

        (let ((x 12) (y 'foo))
          (flet ((zap () (rotatef x y)))
            (locally (declare (fixnum x))
              (zap)
              (zap)
              x)))

;; this is an error under both proposals

        (let ((x 12) (y 'foo))
          (flet ((zap () (rotatef x y)))
            (locally (declare (fixnum x))
              (zap)
              (print x)
	      (zap)
              x)))

;; this is an error under DECLARE-TYPE-FREE:ALLOW, because
;; the assertion that x is a fixnum
;; is violated during the call to zap, even though few 
;; implementations will be able to check:
;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL

        (let ((x 12) (y 'foo))
          (flet ((zap ()
                   (rotatef x y)
                   (rotatef x y)))
            (locally (declare (fixnum x))
              (zap)
              x)))

;; this is an error under both proposals, even though the
;; violation of the type constraint happens after the form
;; with the declaration is exited.

   (let ((f (let ((x 3))
              (declare (fixnum x))
              #'(lambda (z) (incf x z)))))
     (funcall f 4.3))


Rationale:

  This proposal enables optimizing compilers to make use of the otherwise
  ignored type information.  Many people have often asked for it, and
  there is no strong reason to forbid it.
  
  DECLARE-TYPE-FREE:ALLOW is more restrictive on programs and hence allows
  more freedom for optimizing compilers.  DECLARE-TYPE-FREE:LEXICAL is easier
  to understand but allows a specialized representation only where the scope
  of the variable is the same as the scope of the declaration or the compiler
  can prove that there are no relevant other references to the variable.

Current practice:

  Lucid Common Lisp allows "free" type declarations;  under some 
  circumstances the compiler issues a warning message that such usage 
  is an extension to Common Lisp.

Cost to Implementors:

  Implementations that might currently warn about such declarations
  would have to remove the warning; otherwise, it is valid to ignore 
  type declarations.

Cost to Users:

  None, this is a compatible addition.

Cost of non-adoption:

  Common Lisp will be less self-consistent.

Benefits:

  Programmers will be able to use type declaration to express their
  intent, rather than having to manually insert THE wrappers around 
  every reference.


Esthetics:

  It is a simpler interpretation for type declaration specifiers, with
  fewer special cases; hence reduces the number of exceptions in the
  language.

Discussion:

  Another cleanup issue, DECLARATION-SCOPE, addresses the scope of 
  declarations. This proposal carefully uses the phrase "within the 
  scope of the declaration" to avoid confounding the two issues. 

  This issue has been discussed at the Fort Collins X3J13 meeting in
  November 1987, and at length on the various electronic mailing lists.

  At least one current implementation is able to generate more efficient
  code when declarations are associated with a particular binding, since
  it then has the option to choose type-specific specialized storage for 
  the runtime value of the variable.  So, for example, 

      (let ((x v)) (declare (type float x)) (+ x x))

  is sometimes more efficient than

      (let ((x v)) (locally (declare (type float x)) (+ x x)))

  However, the local type declarations allowed by this proposal do
  provide some useful information, even if it is not the *most* useful.
  It is possible for a sufficiently "smart" compiler to infer the 
  equivalent of a "binding declaration" when it can ascertain that the 
  type of the binding value -- 'v' above -- is commensurate with the 
  type locally declared over the scope of usage of the variable.

  It may be useful for a compiler to issue a warning whenever it finds
  nested type declarations referring to the same variable and the
  intersection of the declared types is null.

  Documentation might want to discuss the style implications of
  nested declarations intersecting. The interesting cases are:
   - An inner declaration could be a subtype of an outer one.
     This is the most useful case and probably the only one to
     be encouraged in code written by humans. e.g.,
       (locally (declare (type number x))
         (locally (declare (type integer x))
           ...use X as integer...))
   - An outer declaration could be a subtype of an inner one.
     This is useless but harmless. It might happen as the result
     of certain macro situations. e.g.,
       (locally (declare (type integer x))
         (locally (declare (type number x))
           ...use X as integer...))
   - Two types may only partially overlap. This would presumably
     happen only as the result of a macro expansion.
       (locally (declare (type fixnum x))
         (locally (declare (type (or bit package) x))
           ...use X as BIT...))

∂02-Jan-89  1737	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, Version 1   
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 2 Jan 89  17:36:40 PST
Date: Mon 2 Jan 89 17:31:11-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12459458774.4.IIM@ECLA.USC.EDU>

Ok, since a volunteer was needed, here goes.  I've also included a proposal for
SUBTYPEP, since it has similar problems.  There may be other functions that
need this same treatment.  CONSTANTP comes to mind, though I've decided to wait
on that until some of the issues regarding DEFCONSTANT settle down.  A
VARIABLE-SPECIAL-P predicate would also need this, though that could be handled
right from the start, and can be written portably using the functional
interface defined in SYNTACTIC-ENVIRONMENT-ACCESS (assuming it makes some
progress). 

kab

-----
Issue: 		MACRO-FUNCTION-ENVIRONMENT
References:	Macros, CLtL p.143
		CLOS Ch. 1 & 2
		-- tbd --
Category:	CHANGE
Edit history:	02-Jan-89, Version 1, by kab
Related issues: COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
		SYNTACTIC-ENVIRONMENT-ACCESS
Status:		For Internal Discussion

Problem Description:

 CLtL is often read to imply that COMPILE-FILE should avoid modifying the
 behavior of the running system by changing definitions to correspond to those
 in the file being compiled.  Issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS
 makes this an explicit requirement, and specifies the kind of side-effects
 each of the standard defining forms is required to perform.

 Implementing this distinction between the compile-time and run-time
 environments requires some mechanism for distinguishing which environment is
 being dealt with.  MACRO-FUNCTION needs to be able to make this distinction in
 order to correctly determine what value to return.

 Because CLOS specifies that FIND-CLASS uses an &environment argument to make
 this distinction, integration of the type system and the class system requires
 that SUBTYPEP also accept an &environment argument, if for no other reason
 than to be able to pass it to FIND-CLASS.

 Some implementations may have already implemented some parts of these
 proposals, but user code which makes use of these changes is currently not
 portable. 

Proposal (MACRO-FUNCTION-ENVIRONMENT:NEW-ARGUMENT)

 Extend MACRO-FUNCTION to accept an optional second argument.  This argument
 should be either NIL, the &environment argument received by a macro expander
 function, or the environment argument received by an *evalhook* or *applyhook*
 function.  This argument is used to distinguish between compile-time and
 run-time environments. 

 This proposal explicitly does not modify MACRO-FUNCTION to examine the
 environment argument for local definitions.  MACRO-FUNCTION only returns
 a symbol's global macro definition (if present).

 SETF of MACRO-FUNCTION is changed such that it only sets the global macro
 definition in the specified environment.  Thus, if a compiler environment is
 specified then the macro definition of the running system is not modified.

Proposal (SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT)

 Extend SUBTYPEP to accept an optional third argument.  This argument should be
 either NIL, the &environment argument received by a macro expander function,
 or the environment argument received by an *evalhook* or *applyhook* function.
 This argument is used to distinguish between compile-time and run-time
 environments. 

Rationale:

 CLOS already specifies the use of &environment arguments for the purpose used
 here.  These proposals make use of that existing facility to fix some other
 functions which need the same capabilities.

Test Case:

 -- tbd --

Current Practice:

 Lucid's implementation of MACRO-FUNCTION has an optional second argument for
 the &environment.  Whether it only returns global expanders or also returns
 local (macrolet) is unknown to this author.

 IIM Common Lisp generally uses the &environment argument for distinguishing
 between compile-time and run-time environments, but for these two functions
 (whose arguments were already specified by CLtL) they implement the
 discrimination through the use of a special variable.

Cost to Implementors:

 These proposals require the compiler environment be distinguishable, but that
 seems to already be required by CLOS.  Modifying the definitions of
 MACRO-FUNCTION and its SETF is probably trivial in most implementations.
 Probably the modifications for SUBTYPEP are also trivial.  The hard part may
 be ensuring that all calls are passing the environment argument, which in most
 cases will be a simple word-processing exercise, but in some cases might be
 more difficult because the environment has not been passed along to the point
 where it is needed. 

Cost to Users:

 Users must ensure that all calls are passing the proper environment argument,
 which entails the same difficulties as for implementors.

Benefits:

 -- tbd --  ;I didn't want to write just "Fixes the stated problem."

Aesthetics:

 -- tbd --  ;I didn't want to write just "Removes a problem from the language."

Discussion:

 This is yet another case of a fairly widespread problem relating to the
 interaction between the compiler and the running system.  There seems to be
 general agreement that using a special variable to solve this class of
 problems is wrong, though several implementations currently use this
 technique.  The designers of CLOS apparently believe so, and have specified
 several of the functions in the CLOS interface as accepting an optional
 &environment argument in order to solve the problem of distinguishing between
 compile-time and run-time environments.  Some members of the compiler
 subcommittee also seem to be adopting the use of &environment arguments into
 their thinking about how top-level defining forms perform their special
 compile-time magic, though with some misgivings.

 The decision to not have MACRO-FUNCTION examine the environment argument for
 local definitions is based in part on the assumption that the issue
 SYNTACTIC-ENVIRONMENT-ACCESS (SEA) will make some progress.  MACRO-FUNCTION is
 generally used as a predicate or as a place for SETF (the return value is
 probably almost never used outside of the implementation of MACROEXPAND), and
 SEA proposes a mechanism for determining the presence of a local definition
 and for adding local macro definitions to an environment. 

 SUBTYPEP really needs this change regardless of CLOS, for the same reasons
 that MACRO-FUNCTION does.  The demands of CLOS simply make it more immediately
 obvious.

 The extension of allowing an environment argument from *evalhook* or
 *applyhook* functions seems reasonable, though it might be inferable from the
 acceptence of &environment arguments.  However, since CLtL specifically states
 that the &environment argument need not be a complete lexical environment,
 this could be arguable.  Rather than leaving such a question open for debate,
 this proposal makes explicit allowance for such values.  If it is agreed that
 this explicitness is necessary, then CLOS should ammended appropriately too.
-------

∂02-Jan-89  1811	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 9)
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89  18:11:20 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 415645; Mon 2-Jan-89 21:10:49 EST
Date: Mon, 2 Jan 89 21:09 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 9)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19890103003245.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890102210923.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

My strong preference is for LEXICAL. The ALLOW proposal (which is the
only option offered in v8, which is on the ballot) doesn't sit well
with me, and I wouldn't have been inclined vote yes on it.

Btw, both versions 8 and 9 have the non-preemptive problem that the
only examples they provide illustrate what happens in the screw
cases. This might lead some people to think that this whole issue
is kind of random. I think there should be a few examples of the
"normal use" (such as the un-filled-out examples in the problem
description). It's probably worth fixing this before the meeting
so that people doing last-minute aren't bogged down trying to decipher
the proposal by working backward from the strange examples currently
in the proposal.

∂02-Jan-89  1820	CL-Cleanup-mailer 	Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  18:20:11 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 JAN 89 18:19:06 PST
Date: Mon, 02 Jan 89 18:18:58 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
In-reply-to: <19881229201656.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
To: CL-Cleanup@SAIL.Stanford.Edu
Cc: Pavel.pa@Xerox.COM
Message-ID: <890102-181906-1853@Xerox>

David says,  ``ASSERT ... properly only allow[s] single values.''

Why do you think so?  I assume that you disagree with my reasoning in
response to GSB:

``In the case of ASSERT it is NOT a list of individual values, but of
individual PLACES.  Sure they can be individually changed by the user.  But
doesn't that user specify an expression whose value will be stored?  Can't
that expression return multiple values?''

Where do we disagree?

	Pavel

∂02-Jan-89  1821	CL-Cleanup-mailer 	Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  18:21:49 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 02 JAN 89 18:20:45 PST
Date: Mon, 02 Jan 89 18:20:37 PST
From: Pavel.pa@Xerox.COM
Subject: Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
In-reply-to: <19881229201656.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
To: CL-Cleanup@SAIL.Stanford.Edu
Cc: Pavel.pa@Xerox.COM
Message-ID: <890102-182045-1856@Xerox>

Oops, I forgot to answer David's other question:

	``Do you plan to bring an updated version of this proposal
	  to the next X3J13 meeting?''

I won't be at that meeting, so I'll just send another copy to this mailing list.

	Pavel

∂02-Jan-89  1836	CL-Cleanup-mailer 	Issues: SINGLE-FLOAT-NON-PORTABLE,  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  18:36:08 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 18:33:56 PST
Date: 2 Jan 89 18:33 PST
From: masinter.pa@Xerox.COM
Subject: Issues: SINGLE-FLOAT-NON-PORTABLE,
 LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION
to: cl-cleanup@sail.stanford.edu
Message-ID: <890102-183356-1861@Xerox>

Do any of you have any desire to tangle with these?

In cleaning out my files, I came across this bit of discussion, which
raises at least two issues: SINGLE-FLOAT-NON-PORTABLE

should single-float and double-float be removed from the standard?

LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION 
should LEAST-POSITIVE- and MOST-POSITIVE- numbers include denormalized ones
in those implementations that admit them?
	

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

Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 08 APR 88 22:44:38 PDT
Received: from labrea.Stanford.EDU by SAIL.Stanford.EDU with TCP; 8 Apr 88
22:42:47 PDT
Received: by labrea.Stanford.EDU; Fri, 8 Apr 88 21:42:13 PST
Received: from bhopal.lucid.com by edsel id AA10628g; Fri, 8 Apr 88
22:35:20 PDT
Received: by bhopal id AA08201g; Fri, 8 Apr 88 22:36:11 PDT
Date: Fri, 8 Apr 88 22:36:11 PDT
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Message-Id: <8804090536.AA08201@bhopal.lucid.com>
To: chapman%lisp.DEC@decwrl.dec.com
Cc: edsel!jonl@labrea.Stanford.EDU, cl-cleanup@sail.stanford.edu
In-Reply-To: chapman%lisp.DEC@decwrl.dec.com's message of Fri, 8 Apr 88
07:23:21 PDT <8804081423.AA17359@decwrl.dec.com>
Subject: floating point questions

re: Dick reviewed my snapshot draft of the standard and suggested I talk to
you
    about floating point number representation. . . .  Do you have other 
    thoughts on how floating point data types should be
specified/implemented?
    I don't see any clean-up proposals that have to do with this topic,
just 
    the LEAST-POSITIVE-<mumble>-FLOAT communication.

There are three problems of concern that I know about:


First, for purposes of CLOS, it is very inconvenient to have sub-range 
types for any numerical type.  In one sense, the short-float, single-float,
double-float, and long-float types are sub-ranges of float; and the thorny 
issue is that that there are three possible variations one how they are 
merged.  I don't know how to solve this one, except by ignoring the 
existence of differing float types [and there is probably at least one or 
two manufactures who will fight that to the hilt, since they have optimized
one extreme end or the other and perhaps see this distinction as a 
"competitive edge"].  I *could* make a case for having only FLOAT as a
Common Lisp type, leaving to the vendors the issue of foisting distinctions
off on to the user [since in many cases, the distinctions will be
irrelevant].
Very briefly, the three main points of this case are 
    (1) As a standard, CLtL p16-17 guarantees virtually nothing about what 
	single-float, double-float etc. mean; in one implementation, single
	could mean a 23-bit mantissa, and in another it could mean a 96-bit
	mantissa.  Hence there is no guarantee of portability, so why bother?
    (2) A recent survey of some numerical analysts, in a company dedicated
	to selling Fortran engines, discovered the all-too-obvious fact that
	many many algorithms are numerically unstable when run under the IEEE 
	32-bit format, but are quite well-behaved under the 64-bit format; 
	but interestingly, it turned up *no* cases of ill behaviour in the
	64-bit mode that were correctible by going to a 128 bit format.
	[Now, this is not the same as an "ill conditioned" problem].  In short,
	there is a "good enough" size -- larger isn't needed, and smaller
	could be justified only ocasionally by savings in space and/or time.
    (3) On most machines, there seems to be a "preferred" format.  In fact,
	I'm aware of some hardware where single-float operations are a tad
	slower than double-float ones; the driving motivation is that the
	numerical analysts wanted the fastest possible floating point of
	"good enough" size, and the other sizes were supported only for
	"compatibility".  Also, compact representations inside arrays
	provide the only intesting space savings; this is quite analogous
	to packed arrays of integers [e.g., an array element-type of
	(signed-byte 8)]
[Since a larger group is being cc'd, I'd like to appeal to that group *not*
to flood the mailing list with lots of trivial counterexamples to each of
the above generalizations.  I'm sure they've all been thought of before;
and since the status quo will remain until an actual proposal is made,
there is no need to argue against a non-proposal.  If anyone would like
to contact me privately about pursuing such a proposal, I will respond;
but so far, I haven't seen much interest].



Second, some implementations permit "extremals" to be representable
numbers, 
and others don't;  e.g., the IEEE standard allows for "denormalized" and 
"infinity" numbers, while VAX and IBM/370 don't.  So the question arises 
as to just what "least-positive-<mumble>-float" means;  is it the smallest 
possible representation, or is it the smallest "normal" representation?  
Paul Hilfinger (at Berkeley) feels rather strongly that is should be
the smallest possible representation; but now that raises the issue that
on some implementatons, "least-positive-<mumble>-float" is a perfectly
normal number causing no exceptions whatsoever, while on others it will
cause an "underflow" type trap whenever it is produced (unless you turn
off trapping,  and yes, "gradual underflow" really is "underflow").  About 
the best consensus I could get was to follow Symbolics lead and add the 
names "least-positive-normalized-<mumble>-float", so that there would be a 
portable way of dealing with the smallest reasonable number.   Also:
  (eql least-positive-<mumble>-float
least-positive-normalized-<mumble>-float)
could be used as a test to determine whether or not the implementation 
supports denormalized numbers.


A possible third trouble is with "most-positive-<mumble>-float" -- should
this be the largest reasonable number, or the largest possible
representation?
If the latter, then in the IEEE format, the positive infinity should be
"most-positive-<mumble>-float" since it certainly is larger than any other
float.  By analogy with the difference between "least-positive-..." and
"least-positive-normalized-...", I would have liked to see
"most-positive-..."
and "most-positive-normalized-..."; that way, the test
  (= most-positive-<mumble>-float most-positive-normalized-<mumble>-float)
could be used to determine whether or not the implementation supports
infinities.  But alas, I couldn't convince QUUX (Guy Steele) about this
one,
so I'm not sure it's worth wasting any more time over.


-- JonL --




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


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

∂02-Jan-89  1852	CL-Cleanup-mailer 	Re: Issue: TAILP-NIL (Version 5)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  18:51:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 18:50:54 PST
Date: 2 Jan 89 18:50 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TAILP-NIL (Version 5)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Tue, 13 Dec 88 19:05 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890102-185054-1879@Xerox>

For the record, re: whether the following sentence is Irrelevant,
Inflammatory, Unfounded, Shooting in the Dark

<< It was suggested more than once by more than one cleanup 
committee member that we remove TAILP from the language
"since almost nobody uses it". >>

It is relevant, since it is an alternate solution to the proposal.
It is inflammatory, evidenced by your flame.
It is not unfounded; I have two messages, one from Moon and one from JonL,
that mention removing TAILP from the language as a serious possibility,
although only one of them used the phrase "since almost nobody uses it".
Perhaps you could search through your local sources for calls to TAILP?
As for "shooting in the dark", that's likely.


However, we did not go so far as to present the proposal of removing TAILP
as a serious contender, because we realized the cost of incompatible
changes. I think if I were designing a good lisp from scratch I might put
TAILP low in the list of priorities of things to add, but taking it out has
high cost and almost no benefit. 

Your two suggestions (expand the proposal to deal with LDIFF, possibly add
a :TEST argument) may have gotten lost.

∂02-Jan-89  1916	CL-Cleanup-mailer 	Re: Issue: REST-LIST-ALLOCATION (Version 3)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  19:16:23 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 19:15:18 PST
Date: 2 Jan 89 19:14 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: REST-LIST-ALLOCATION (Version 3)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Tue, 13 Dec 88 21:15 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
Message-ID: <890102-191518-1893@Xerox>

re: "The only issue then would be whether there were implementations where
the always-share functionality would be impossible to implement" 

In the Medley implementation of Common Lisp (and in all the Interlisp
implementations I'm familiar with), APPLY always "spreads" its arguments on
the stack, independent of the internal argument structure of the recipient
function; an &REST argument is always "consed" from the stack structure. In
this implementation, always-share would require APPLY to "look ahead"
somehow, and invoke some kind of alternate version of the function which
could take the rest list "shared". 

Re "Perhaps declarations like...."

I am opposed to adding declarations that change the behavior of correct
programs. Except for SPECIAL, declarations change only the "checking" for
incorrect programs and not the behavior of correct programs.

∂02-Jan-89  2102	CL-Cleanup-mailer 	Re: Issue: PATHNAME-PRINT-READ (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  21:02:16 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 21:00:45 PST
Date: 2 Jan 89 21:00 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-PRINT-READ (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Fri, 21 Oct 88 17:00 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890102-210045-1930@Xerox>

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

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




∂02-Jan-89  2109	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL ? 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  21:09:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 21:08:14 PST
Date: 2 Jan 89 21:07 PST
From: masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-LOGICAL ?
In-reply-to: Eric Benson <eb@lucid.com>'s message of Fri, 21 Oct 88
 14:13:50 pdt
To: Eric Benson <eb@lucid.com>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890102-210814-1939@Xerox>

Re: "I wish someone would make a proposal
for generic pathnames.  I don't think they ever got the consideration
they deserved."

There are several issues waiting a "pathname" committee to study them
further. They include: 

PATHNAME-COMPONENT-CASE, PATHNAME-LOGICAL, PATHNAME-SUBDIRECTORY-LIST,
PATHNAME-SYNTAX-ERROR-TIME, PATHNAME-WILD, STREAM-CAPABILITIES,
TRUENAME-SYNTAX-ONLY

Frankly, I don't know what  "generic" pathnames are, so I don't know how I
could have considered them. Are they the same thing as "logical" pathnames?



∂02-Jan-89  2118	CL-Cleanup-mailer 	Re: issue COMPILE-ARGUMENT-PROBLEMS 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89  21:17:47 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514161; Tue 3-Jan-89 00:15:34 EST
Date: Tue, 3 Jan 89 00:14 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue COMPILE-ARGUMENT-PROBLEMS
To: sandra%defun@cs.utah.edu
cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8901030502.AA05326@defun.utah.edu>
Message-ID: <890103001457.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

I had forgotten the issue was voted on.

I do, however, think there are substantial benefits to be gained from my
new proposal over the other one. I think any definition of COMPILE which
permits it to err at random (which is pretty much how I feel about all
these "is an error" situations) severely cripples the usefulness of COMPILE
in really portable code. Signalling an error rather than quietly returning
seems useless. The only  reason I can think of to signal an error in general
is if there was some danger to be avoided or more than one way you could
go and you want to allow user intervention. In this case, I think people
always do just one thing: say to themselves "oh, i guess I won't compile
this". We might as well let the system do it for them.

So my inclination is to say yes, that we should reopen the issue.
My understanding was that the primary justification of the previous proposal
over this one is that it was what you thought was the "best that could be
hoped for". My inclination is to believe that this raises the least common
denominator without crossing that line where we get bogged down in
capabilities of particular implementations, etc.

Does you (or does anyone) have reason to believe that the new proposal
I've just circulated would cause any kind of problem?

∂02-Jan-89  2118	CL-Cleanup-mailer 	Re: issue COMPILE-ARGUMENT-PROBLEMS 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89  21:18:36 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 514163; 3 Jan 89 00:17:18 EST
Date: Tue, 3 Jan 89 00:16 EST
From: KMP@STONY-BROOK.SCRC.Symbolics.COM
To: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: issue COMPILE-ARGUMENT-PROBLEMS
References: <890103001457.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890103001640.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

[The referenced message has been redirected:
  Sorry. I sent that message to the wrong list.
    CL-Cleanup@SAIL.Stanford.EDU has been removed;
    CL-Compiler@SAIL.Stanford.EDU has been added.]

∂02-Jan-89  2127	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (Version 5) 
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89  21:27:05 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 305264; Tue 3-Jan-89 00:25:14 EST
Date: Tue, 3 Jan 89 00:25 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAGBODY-CONTENTS (Version 5)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <890103002508.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

Typo (extra word in "the given a tag") in para 1 of Proposal.

The term "data element" is too vague in para 2 of Proposal.

These should be fixed before final vote; the latter could lead to
serious confusion.

∂02-Jan-89  2210	CL-Cleanup-mailer 	Re: issue COMPILE-ARGUMENT-PROBLEMS 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 2 Jan 89  22:07:33 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA06581; Mon, 2 Jan 89 23:04:23 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA05373; Mon, 2 Jan 89 23:03:11 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901030603.AA05373@defun.utah.edu>
Date: Mon, 2 Jan 89 23:03:10 MST
Subject: Re: issue COMPILE-ARGUMENT-PROBLEMS
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: sandra%defun@cs.utah.edu, CL-Cleanup@SAIL.Stanford.EDU,
        KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 3 Jan 89 00:14 EST

It looks to me like the main difference between the two proposals is
in the treatment of functions defined in a non-null lexical
environment.  The proposal that was voted on was amended in accordance
with your earlier suggestions to make the other situations harmless --
doing nothing is an acceptable alternative if the function is already
compiled, but signalling errors or blowing fuses is not -- so I think
the other issues you touch upon in your new proposal could probably be
handled as editorial changes.  I would much rather do that than re-open
the issue (I think our time would be better spent trying to deal with
the many other unresolved issues we still have pending), but if you 
feel strongly about this then of course we can go ahead and ask for
another vote.

A problem I have with your proposal is that I believe that
COMPILED-FUNCTION-P must be true of any function returned from
COMPILE, and that COMPILE must also at least ensure that all macro
calls in the function have been expanded.  I don't think that allowing
COMPILE to do nothing when passed an interpreted function is a
legitimate option. 

I've actually been trying to draft a short document for Kathy Chapman
to describe the minimum functionality required for implementations of
COMPILE and COMPILE-FILE (incorporating Steve's famous "compiler
model" from last March), but if what's obvious to me isn't obvious to
other people, I should probably turn at least this one part of the
writeup into a new issue so we can vote on it formally. 

-Sandra
-------

∂02-Jan-89  2214	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  22:14:21 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 22:13:15 PST
Date: 2 Jan 89 22:12 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Mon, 2 Jan 89 19:32 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@sail.stanford.edu
Message-ID: <890102-221315-1967@Xerox>

Thanks for doing this, I think it does help clarify the discussion.

I had thought -- apparently incorrectly -- that the only objection to
making type declarations have the strongest possible meaning was the
difficulty in specifying what that meaning might be. I think the ALLOW
proposal does so consistently. 

If I say (DECLARE (TYPE (SIGNED-BYTE 12) X)), I'd think I'd like it to mean
that X never even momentarily holds a value that isn't of the declared
type.

I'd suggest adding to Current Practice that some Common Lisp
implementations ignore type declarations completely.

I'd like to see the writeup make it clear that the following is subsumed;
note that this issue never was released or appeared on a Status list, so it
should probably just be included

Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 04 NOV 88
16:21:08 PST
Received: from ti.com by SAIL.Stanford.EDU with TCP; 4 Nov 88  16:19:26 PST
Received: by ti.com id AA07547; Fri, 4 Nov 88 18:19:48 CST
Received: from Kelvin by tilde id AA15412; Fri, 4 Nov 88 18:03:33 CST
Message-Id: <2803680321-5692691@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 4 Nov 88 18:05:21 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue SPECIAL-TYPE-SHADOWING (V1)
In-Reply-To: Msg of 28 Sep 88 20:44 PDT from masinter.pa@Xerox.COM


Issue:         SPECIAL-TYPE-SHADOWING

References:    CLtL pages 156, 158

Related issues: DECLARE-TYPE-FREE

Category:      CLARIFICATION

Edit history:  Version 1, 04-Nov-88 by David Gray

Problem description:

  A Common Lisp user raised the question of whether something like the
  following is legal:

    (PROCLAIM '(TYPE NUMBER *X*))
    (DEFVAR *X*)
    (DEFUN FOO ()
      (LET ((*X* T))
        (DECLARE (TYPE SYMBOL *X*))
        (BAR)))

  Page 156 of CLtL says that a proclamation is "always in force unless
  locally shadowed" and page 158 says type declarations "only affect
  variable bindings", which might be interpreted to mean that the DECLARE
  locally shadows the PROCLAIM.  However, that interpretation would make
  the global type proclamation useless because it could not be relied on
  when compiling a function such as BAR. 

Proposal SPECIAL-TYPE-SHADOWING:CLARIFY
  
  Clarify that if there is a local type declaration for a special
  variable, and there is also a global type proclamation for that same
  variable, then the value of the variable within the scope of the local
  declaration must be a member of the intersection of the two declared
  types.

Rationale:

  Some restriction on local type declarations for special variables is
  needed in order for type proclamations to be meaningful.  The wording
  used here was chosen for consistency with proposal DECLARE-TYPE-FREE.

Current practice:

  The TI, Symbolics, and Lucid implementations do not report any error
  on the example above, but it isn't clear that they really do anything
  with type declarations for special variables anyway.

Cost to Implementors:

  This is unlikely to require a change in any current implementation.

Cost to Users:

  Anyone who has written code like the example above would have to
  modify it if compilers started enforcing this restriction.

Cost of non-adoption:

  A minor ambiguity in the language specification that could confuse
  users.

Performance impact:

  None.

Benefits:

  A clearer definition of the meaning of type declarations for special
  variables.

Discussion:

  This is obviously very closely related to issue DECLARE-TYPE-FREE, but
  this is an ambiguity in the existing language that should be resolved
  even if the language extension of proposal DECLARE-TYPE-FREE is not
  accepted.  Note also that DECLARE-TYPE-FREE makes no mention of type
  proclamations.

  Other possible resolutions of the ambiguity would be to either rule
  out use of local type declarations for special variables, or to say
  that the local type must be a subtype of the global type.

∂02-Jan-89  2225	CL-Cleanup-mailer 	Re: Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  22:25:12 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 22:24:08 PST
Date: 2 Jan 89 22:23 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFSTRUCT-ACCESS-FUNCTIONS (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Thu, 10 Nov 88 13:33 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890102-222408-1971@Xerox>

I think this is fine, too. If I were being picky I'd want some minor
cosmetic changes, but I don't think we have time.

∂02-Jan-89  2236	CL-Cleanup-mailer 	Re: Issue: DELETE-FILE-NONEXISTENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Jan 89  22:36:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 02 JAN 89 22:32:31 PST
Date: 2 Jan 89 22:31 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DELETE-FILE-NONEXISTENT (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Sun, 13 Nov 88 18:32 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890102-223231-1974@Xerox>

I renamed this from DELETE-NONEXISTENT-FILE.

I agree that I don't like the proposal. I'd like DELETE-FILE to spell out
what the classes of errors it would get when the file didn't exist vs when
the file couldn't be deleted.

Did you have those on your list of error signals?


∂02-Jan-89  2248	CL-Cleanup-mailer 	Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89  22:48:03 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514178; Tue 3-Jan-89 01:46:49 EST
Date: Tue, 3 Jan 89 01:46 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881208-111031-3954@Xerox>
Message-ID: <890103014612.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

I have a problem with version 2 because I don't think anything requires
get-dispatch-macro-character to return the same function on successive
calls even with the same readtable (provided the functions returned are
equivalent). As such, the example is inappropriate where it uses ASSERT
and EQ.

∂03-Jan-89  0027	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
Received: from VALLECITO.SCRC.Symbolics.COM (SCRC-VALLECITO.ARPA) by SAIL.Stanford.EDU with TCP; 3 Jan 89  00:26:59 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by VALLECITO.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 267616; Tue 3-Jan-89 01:32:47 EST
Date: Tue, 3 Jan 89 01:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
To: masinter.pa@Xerox.COM
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <890102-221315-1967@Xerox>
Message-ID: <890103013157.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 2 Jan 89 22:12 PST
    From: masinter.pa@Xerox.COM

    ...
    If I say (DECLARE (TYPE (SIGNED-BYTE 12) X)), I'd think I'd like it to mean
    that X never even momentarily holds a value that isn't of the declared
    type.
    ...

The problems I have with this are the following:

 - It isn't enforceable.

 - In exactly those cases where it is enforceable, it's useful to enforce.
   In those case where it is not enforceable (the odd middle-ground cases
   in the Examples), it doesn't help you any to enforce the restriction, and
   it might get in your way. 

   Put another way: If you grant that a language could be internally 
   consistent, well-formed, and all that sort of thing with the LEXICAL
   proposal, then why not attach a useful meaning to the middle ground case?
   There are potentially useful things (mostly "patches") that you could
   write that way, and even if you permit it, you don't hinder the compiler's
   ability to make useful inferences.

 - My general rule of thumb is that if someone says they need a feature
   and someone else says they don't, that the person claiming they do need
   the feature has an a priori more interesting case. As such, LEXICAL is
   more interesting partly because the fact that some people don't need all
   its features is not a compelling thing to me. If you could make a case for
   why LEXICAL caused some actual -problem-, that would make the other case
   more interesting. After all, nothing about LEXICAL prevents you personally
   from meaning that "X never momentarily holds..." since that's compatible
   with the meaning proposed in LEXICAL -- just as nothing about the way 
   false and the empty-list are treated in Lisp keeps you from meaning
   that () always means the empty list (even if Lisp doesn't care).
   Similarly here, LEXICAL admits both views of the universe while ALLOW
   admits only one. To me, this seems unfair, since ALLOW restricts things
   to lock out a view of the world, without providing any hint of a reason
   for why that view of the world is an unreasonable one.

∂03-Jan-89  0542	CL-Cleanup-mailer 	Re: Issue: DYNAMIC-EXTENT (Version 2)    
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 3 Jan 89  05:42:40 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa19261; 3 Jan 89 8:32 EST
Received: from draper.com by RELAY.CS.NET id aa29726; 3 Jan 89 8:20 EST
Date: Tue, 3 Jan 89 08:11 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: DYNAMIC-EXTENT (Version 2)
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525

> From: "David A. Moon" <Moon@scrc-stony-brook.ARPA>
> Subject: Issue: DYNAMIC-EXTENT (Version 2)

> The following is where I disagree strongly with the proposal:
>
>      It is very important to note that it is the actual constructor operation
>      and not the resulting data type which determines the level of the object
>      referred to in the dynamic extent declaration. For example, in
>
>            (LET ((X (LIST 'A1 'B1 'C1))
>                  (Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
>              (DECLARE (DYNAMIC-EXTENT X Y))
>              ...)
>
>      The list (A1 B1 C1) which is the initial value of X will have three cons
>      cells, all of which have dynamic extent. The cons (A2 . (B2 C2)) which is
>      the initial value of Y will have dynamic extent, but its cdr (B2 C2) will
>      have indefinite extent.
>
> I think this is the wrong way to look at it in general, and furthermore
> this means that backquote can't be used correctly with the
> DYNAMIC-EXTENT declaration, since there is no promise what backquote
> expands into. 
>
> ...
>
>            (LET ((X (LIST 'A1 'B1 'C1))
>                  (Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
>              (DECLARE (DYNAMIC-EXTENT X Y))
>              ...)
>
> The "proper parts" of X are three conses, and the "proper parts" of Y
> are three other conses.  None of the symbols A1, B1, C1, A2, B2, C2, or
> NIL is a "proper part" of X or Y.  However, if a freshly allocated
> uninterned symbol had been used, it would have been a "proper part."
>
>    Date: 7 Dec 88 18:05 PST
>    From: masinter.pa@Xerox.COM
>
>    Version 2 of this writeup didn't mention one of the criticisms I sent on 1
>    July, namely:
>
>    "a) it is disturbing to introduce a construct within which a casual change
>    of (CONS X (LIST Y Z)) to  (LIST X Y Z) could introduce a serious bug
>    (e.g., if the tail were stashed away
>    somewhere.)"
>
> I quite agree with this.  My proposed alternative definition doesn't have any
> problems like this, since it is defined in terms of the actual object, not in
> terms of how it was constructed.
>

I agree strongly with the comments of Moon and Masinter.  For example, in our
implementation, the compiler source-transforms calls to LIST into nested
calls to CONS.  Under these circumstances, it is impossible to distinguish
between the cases in the various examples above for the purpose of determining 
which conses are subject to the DYNAMIC-EXTENT constraint.

∂03-Jan-89  0758	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL ? 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  07:58:16 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA03074g; Tue, 3 Jan 89 07:52:30 PST
Received: by blacksox id AA00248g; Tue, 3 Jan 89 07:54:37 pst
Date: Tue, 3 Jan 89 07:54:37 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901031554.AA00248@blacksox>
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 2 Jan 89 21:07 PST <890102-210814-1939@Xerox>
Subject: Issue: PATHNAME-LOGICAL ?

   Date: 2 Jan 89 21:07 PST
   From: masinter.pa@Xerox.COM

   Re: "I wish someone would make a proposal
   for generic pathnames.  I don't think they ever got the consideration
   they deserved."

   There are several issues waiting a "pathname" committee to study them
   further. They include: 

   PATHNAME-COMPONENT-CASE, PATHNAME-LOGICAL, PATHNAME-SUBDIRECTORY-LIST,
   PATHNAME-SYNTAX-ERROR-TIME, PATHNAME-WILD, STREAM-CAPABILITIES,
   TRUENAME-SYNTAX-ONLY

   Frankly, I don't know what  "generic" pathnames are, so I don't know how I
   could have considered them. Are they the same thing as "logical" pathnames?

Yes, I meant to say logical pathnames.

∂03-Jan-89  0800	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, Version 1   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  08:00:39 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA03077g; Tue, 3 Jan 89 07:56:54 PST
Received: by blacksox id AA00251g; Tue, 3 Jan 89 07:59:11 pst
Date: Tue, 3 Jan 89 07:59:11 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901031559.AA00251@blacksox>
To: IIM@ECLA.USC.EDU
Cc: cl-cleanup@SAIL.STANFORD.EDU, iim@ECLA.USC.EDU
In-Reply-To: Kim A. Barrett's message of Mon 2 Jan 89 17:31:11-PST <12459458774.4.IIM@ECLA.USC.EDU>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, Version 1

   Date: Mon 2 Jan 89 17:31:11-PST
   From: Kim A. Barrett <IIM@ECLA.USC.EDU>

   Current Practice:

    Lucid's implementation of MACRO-FUNCTION has an optional second argument for
    the &environment.  Whether it only returns global expanders or also returns
    local (macrolet) is unknown to this author.

Yes, MACRO-FUNCTION in Lucid CL will return a MACROLET expander as
well as a DEFMACRO expander.  It also correctly handles the case of an
FLET or LABELS overriding a DEFMACRO (by returning NIL).

∂03-Jan-89  0812	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, Version 1   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  08:12:08 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA03092g; Tue, 3 Jan 89 08:08:25 PST
Received: by blacksox id AA00254g; Tue, 3 Jan 89 08:10:38 pst
Date: Tue, 3 Jan 89 08:10:38 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901031610.AA00254@blacksox>
To: IIM@ECLA.USC.EDU
Cc: cl-cleanup@SAIL.STANFORD.EDU, iim@ECLA.USC.EDU
In-Reply-To: Kim A. Barrett's message of Mon 2 Jan 89 17:31:11-PST <12459458774.4.IIM@ECLA.USC.EDU>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, Version 1

   Date: Mon 2 Jan 89 17:31:11-PST
   From: Kim A. Barrett <IIM@ECLA.USC.EDU>

   Proposal (MACRO-FUNCTION-ENVIRONMENT:NEW-ARGUMENT)

    Extend MACRO-FUNCTION to accept an optional second argument.  This argument
    should be either NIL, the &environment argument received by a macro expander
    function, or the environment argument received by an *evalhook* or *applyhook*
    function.  This argument is used to distinguish between compile-time and
    run-time environments. 

MACRO-FUNCTION should not accept the environment argument received by
an *EVALHOOK* or *APPLYHOOK* function.  (*APPLYHOOK* should not even
receive an environment argument, was there ever a cleanup issue
addressing this?)  MACRO-FUNCTION is only concerned with what I have
referred to as "syntactic" environments.  *EVALHOOK* environments are
a different beast entirely, they don't belong in the same category.
In fact, the status of EVALHOOK is tenuous at best.  How is it
done in a compiled-only implementation?

    This proposal explicitly does not modify MACRO-FUNCTION to examine the
    environment argument for local definitions.  MACRO-FUNCTION only returns
    a symbol's global macro definition (if present).

In that case, what does MACRO-FUNCTION return when there is a MACROLET
definition visible?  It must return some non-NIL value.  It should be
the expansion function, to be consistent with the global case.

∂03-Jan-89  0834	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 2)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  08:33:55 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA03107g; Tue, 3 Jan 89 08:29:18 PST
Received: by blacksox id AA00259g; Tue, 3 Jan 89 08:31:34 pst
Date: Tue, 3 Jan 89 08:31:34 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901031631.AA00259@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: David A. Moon's message of Mon, 2 Jan 89 15:00 EST <19890102200018.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 2)

This is very good.  The definitions of "saved" and "proper part" seem
quite precise to me.  It is essential to have a definition independent
of the implementation.  Still, it would be useful to give at least a
sketch of how this might be implemented, since it still involves
looking for functions like CONS and LIST (and whatever backquote turns
into) about which the compiler has information.

∂03-Jan-89  0902	CL-Cleanup-mailer 	Re:  Issue: REST-LIST-ALLOCATION (Version 3)  
Received: from mist.math.uoregon.edu ([128.223.4.3]) by SAIL.Stanford.EDU with TCP; 3 Jan 89  09:02:25 PST
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Tue, 3 Jan 89 09:00:06 PDT
Received: by fog.cs.uoregon.edu; Tue, 3 Jan 89 08:59:44 PDT
Date: Tue, 3 Jan 89 08:59:44 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8901031659.AA06887@fog.cs.uoregon.edu>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
Subject: Re:  Issue: REST-LIST-ALLOCATION (Version 3)

Moon writes of his example that:

  All I did was change APPLY to FUNCALL, and remove the corresponding
  &REST.  I find it inconsistent if calling with APPLY is guaranteed to
  copy one of the arguments, but calling with FUNCALL is not.

To my way of thinking, APPLY never copies any arguments so APPLY is
perfectly consistent with FUNCALL even if &REST lists are always
freshly consed.  You see, my understanding of APPLY is that it calls
its first argument on the elements of the list that is its second
argument (or the analagous thing if you give it more than two arguments).
The arguments, therefore, are the elements of the list, not the list
itself, and so the arguments are not copied.

It is true that the list created by &REST list processing may happen to
be a copy of some existing list, possibly even a list that was once
passed to APPLY, but I don't see why APPLY should be given credit for
having made the copy.

Peace, Will

∂03-Jan-89  0916	CL-Cleanup-mailer 	Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  09:16:19 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA25011; Tue, 3 Jan 89 12:15:08 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA12970; Tue, 3 Jan 89 12:15:09 EST
Message-Id: <8901031715.AA12970@mist.>
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES 
In-Reply-To: Your message of Sun, 01 Jan 89 21:40:16 -0800.
             <8901020540.AA21474@bhopal> 
Date: Tue, 03 Jan 89 12:15:07 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    I seem to have no record of past mail on this issue, but I remember at
    one time arguing against it since it tended to contradict the agreement
    in ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS -- namely (1) that we wouldn't
    distinguish between "for declaration" and "for discrimination", and
    (2) that the original source-code element-type specifier may be "upgraded"
    so that for all intents an purposes you can't recover the "exact declared 
    element type".  But if all that Dan wanted to say was that the array
    references were assumed to satisfy the *upgrade* of the declared type,
    then there would be no problem (with that part).
    
Sorry, but that's exactly the opposite of what I meant.  If I declare
an array, FOO, to be (SIGNED-BYTE 5), within the scope of that
definition I'm saying that expect references to that array to be
equivalent to:
    (THE (SIGNED-BYTE 5) (AREF FOO X))
No matter what the array was upgraded to.  Upgrading should  refer to the
array's physical layout and overall type, but it should not license
the FOO below to be a different type from (AREF BAR X) in FROB.

    (DEFUN FROB (FOO BAR)
       (DECLARE (TYPE (SIGNED-BYTE 5) FOO)
		(TYPE (ARRAY (SIGNED-BYTE 5)) BAR))
       ...
    )

    My name probably got put reference in this proposal because I have
    generally given support for the following notion: that there be at least
    one mode of operation (interpretation or compilation) in which all type
    information is rigidly checked.  I don't think Lucid would be that averse
    to some form of required error signaling in this case; but likely it
    wouldn't be in interpreted code --  rather, it most easily could be in
    code compiled under highest safety [because the interpreter currently 
    doesn't pay attention to type declarations].  Contrary to your suggestion, 
    I would have thought that Symbolics would offer more resistance to this 
    idea than would "stock hardware" implementatons, since many of the latter
    have already invested in a compiler cognizant of type declartions.
    
Actually, your name got put in support because of an early message of
yours (which I finally found) in the ARRAY-ELEMENT-TYPE-SEMANTICS
discussion.  I'll be happy to remove your name if we now disagree.

As I've said before, I support a strict type checking mode for all
Common Lisp compilers.  However I now suspect that it's too late (and
maybe too experimental) to get in this version of the standard.  I
said I'd write up a proposal for it at the cleanup meeting last
October, but was later talked out of doing so.

    

∂03-Jan-89  0924	CL-Cleanup-mailer 	Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  09:24:41 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA25203; Tue, 3 Jan 89 12:23:23 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA12979; Tue, 3 Jan 89 12:23:24 EST
Message-Id: <8901031723.AA12979@mist.>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES 
In-Reply-To: Your message of Mon, 02 Jan 89 12:37:00 -0500.
             <19890102173715.1.MOON@EUPHRATES.SCRC.Symbolics.COM> 
Date: Tue, 03 Jan 89 12:23:23 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    I basically agree with you, but would like to point out one thing that I
    hadn't thought of until I read your mail just now.  Since a portable
    program cannot know what the upgraded element type is, it must not
    assume that all implementations have some objects that are members of
    the upgraded element type but not members of the exact declared type.
    This means that if it "is an error" for an array element not to be of
    the upgraded type, it also "is an error" for an array element not to be
    of the exact declared type; either way, a program that does that is not
    portable.  So the only real problem with Pierson's proposal is its
    proposed change of enforcement of type declarations from "is an error"
    to "signals an error".
    
    Now, if we make it "signals an error in the highest safety mode" then
    we're back with the same problem: does it signal an error when you
    violate the declared type, or only when you violate the upgraded type?
    The former provides a more portable definition of when errors are
    signalled, but violates the consistency of declaration with
    discrimination.  The latter keeps declaration and descrimination
    consistent, but means that there are some cases that "are an error" (or
    at least are not portable) in lower safety settings, but fail to "signal
    an error" in the highest safety setting.
    
The problem is that there are logically three types of declaration in
these cases: for discrimination, for declaration, and for reference.
For declaration refers to the array as a whole.  For reference refers
to references to array elements.  I claim that upgrading for reference
introduces a confusing and unnecessary incompatibility between array
elements and normal variables.  I also claim that there are people
writing and distributing code today who neither understand nor desire
this incompatibility.

This whole upgrading thing is a necessary hack to try an adopt an
abstract type system to a varying set of efficient implementations.
There is no reason why this hack needs to be propagated to references
to individual elements, which should follow the rules for "normal"
variables as much as possible.

∂03-Jan-89  0938	CL-Cleanup-mailer 	Re:  Issue: REST-LIST-ALLOCATION (Version 3)  
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 3 Jan 89  09:38:25 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 255261; Tue 3-Jan-89 12:37:06 EST
Date: Tue, 3 Jan 89 12:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re:  Issue: REST-LIST-ALLOCATION (Version 3)
To: William Clinger <will@fog.cs.uoregon.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8901031659.AA06887@fog.cs.uoregon.edu>
Message-ID: <19890103173617.5.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 3 Jan 89 08:59:44 PDT
    From: William Clinger <will@fog.cs.uoregon.edu>

    Moon writes of his example that:

      All I did was change APPLY to FUNCALL, and remove the corresponding
      &REST.  I find it inconsistent if calling with APPLY is guaranteed to
      copy one of the arguments, but calling with FUNCALL is not.

    To my way of thinking, APPLY never copies any arguments so APPLY is
    perfectly consistent with FUNCALL even if &REST lists are always
    freshly consed.  You see, my understanding of APPLY is that it calls
    its first argument on the elements of the list that is its second
    argument (or the analagous thing if you give it more than two arguments).
    The arguments, therefore, are the elements of the list, not the list
    itself, and so the arguments are not copied.

    It is true that the list created by &REST list processing may happen to
    be a copy of some existing list, possibly even a list that was once
    passed to APPLY, but I don't see why APPLY should be given credit for
    having made the copy.

Something happens in between the APPLY and the &REST.  You think of it as
connected with the &REST, I think of it as connected with the APPLY, and
someone else might think of it as an independent thing not really connected
with either of them.  Okay.

Peace yourself.

∂03-Jan-89  0946	CL-Cleanup-mailer 	Re: Issue GC-MESSAGES (Version 2)   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  09:46:24 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA25413; Tue, 3 Jan 89 12:45:16 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA13066; Tue, 3 Jan 89 12:45:16 EST
Message-Id: <8901031745.AA13066@mist.>
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue GC-MESSAGES (Version 2) 
Date: Tue, 03 Jan 89 12:45:14 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    I still think that focussing on GC messages is wrong, and instead there
    should be a form that disables unsolicited typeout in general,
    regardless of its source.  Of course in some operating systems it might
    be impossible to disable some forms of unsolicited typeout, and in other
    operating systems unsolicited typeout might not exist (that is,
    asynchronous messages might always come out in a separate window).
    Thus this facility would just do the best effort appropriate for
    the particular implementation.
    
I agree in general.  I further think that the cleanest way to handle
the problem is by having all such output be signalled.  There is then
a well-defined, portable way for a user to intercept any desired
messages and deal with them in any way.  Now that we have a condition
system, this approach seems much cleaner than another set of ad-hoc
keywords, wrapper forms, functions, etc.

This is the approach I'm pushing for compiler messages in the compiler
committee, but it doesn't seem to be getting very far.

∂03-Jan-89  0952	CL-Cleanup-mailer 	Re: Issue GC-MESSAGES (Version 2)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Jan 89  09:52:25 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514389; Tue 3-Jan-89 12:51:17 EST
Date: Tue, 3 Jan 89 12:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue GC-MESSAGES (Version 2) 
To: Dan L. Pierson <pierson@mist.encore.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8901031738.AA13041@mist.>
Message-ID: <19890103175039.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 03 Jan 89 12:38:44 EST
    From: Dan L. Pierson <pierson@mist.encore.com>

	I still think that focussing on GC messages is wrong, and instead there
	should be a form that disables unsolicited typeout in general,
	regardless of its source.  Of course in some operating systems it might
	be impossible to disable some forms of unsolicited typeout, and in other
	operating systems unsolicited typeout might not exist (that is,
	asynchronous messages might always come out in a separate window).
	Thus this facility would just do the best effort appropriate for
	the particular implementation.
    
    I agree in general.  I further think that the cleanest way to handle
    the problem is by having all such output be signalled.

This can't work for asynchronous, unsolicited typeout.  In a multiprocess
system, the cause of the condition leading to message output may not be
in a "user" process, so signalling in the originating process won't give
the user any control.  Also there may be multiple "user" processes and it
may not be obvious which one should receive the signal.  I shouldn't
have to tell this to someone from Encore, you must have faced all these
issues already!  Also a special form that disables unsolicited typeout
during the dynamic extent of its body could interact with the operating
system to disable or defer operating-system-generated typeout, but in
most operating systems it would be much more difficult to arrange for
the operating system to signal a Lisp condition when it wants to type
something out.

It's too bad it can't work, because it certainly would be cleaner.

∂03-Jan-89  0955	CL-Cleanup-mailer 	Re: Issue COMPILER-DIAGNOSTICS, v7  
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  09:55:07 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA25447; Tue, 3 Jan 89 12:53:56 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA13100; Tue, 3 Jan 89 12:53:57 EST
Message-Id: <8901031753.AA13100@mist.>
To: "Kim A. Barrett" <IIM@ECLA.USC.EDU>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue COMPILER-DIAGNOSTICS, v7 
In-Reply-To: Your message of Sat, 31 Dec 88 19:39:52 -0800.
             <12458957912.23.IIM@ECLA.USC.EDU> 
Date: Tue, 03 Jan 89 12:53:55 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    > I agree.  I lumped ALERT and NOTICE together to keep them from causing
    > BREAKs. 
    
    This doesn't seem necessary, with the depreciation of
    *break-on-warnings* in the current condition system, being
    replaced by *break-on-signals*
    
That may actually make things worse, depending on whether you believe
that a MEMBER type specifier is a valid portable value for
*BREAK-ON-SIGNALS*.   If it isn't, you need to be able to collect all
the things you'd like to turn off as subtypes of the same type.


∂03-Jan-89  1020	CL-Cleanup-mailer 	Re: Issue: PATHNAME-EXTENSIONS (Version 1)    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  10:20:28 PST
Received: by ti.com id AA18762; Tue, 3 Jan 89 12:19:51 CST
Received: from dsg by tilde id AA14868; Tue, 3 Jan 89 12:15:51 CST
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 3 Jan 89  12:16:29 CST
Message-Id: <2808843406-15267619@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 3 Jan 89  12:16:46 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-EXTENSIONS (Version 1)
In-Reply-To: Msg of Wed, 28 Dec 88 15:57 EST from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

>   Clarify that COMMON-PATHNAME-P considers a pathname's host field
>   to fit the Common Lisp pathname model if the filler of the host
>   field is a string (naming a host), and not otherwise.
... etc.

Rather than talk about the "fields" of a pathname, I think it would be
better to talk about the value returned by the standard accessor
functions.  For example, in proposal PATHNAME-SUBDIRECTORY-LIST, you
suggested that an implementation could use a non-standard representation
internally so long as the function PATHNAME-DIRECTORY returned the
standard representation.  Thus, we could say:

  Clarify that COMMON-PATHNAME-P returns true if PATHNAME-HOST will
  return a string, and NIL if PATHNAME-HOST will return something else.

etc.

∂03-Jan-89  1056	CL-Cleanup-mailer 	Re: Issue COMPILER-DIAGNOSTICS, v7  
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  10:56:10 PST
Received: from [73.0.0.15] by multimax.encore.com (5.59/25-eef)
	id AA25868; Tue, 3 Jan 89 13:54:55 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA13187; Tue, 3 Jan 89 13:54:49 EST
Message-Id: <8901031854.AA13187@mist.>
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue COMPILER-DIAGNOSTICS, v7 
Date: Tue, 03 Jan 89 13:54:47 EST
From: Dan L. Pierson <pierson@mist.encore.com>

[[Meta-note to cl-cleanup.  One of the proposals for handling compiler
  messages is based on signalling all messages as conditions with the
  standard signalling function "printing" the message iff the
  condition isn't handled.  I think that this approach can, and
  should, be applied to messages in the cleanup domain as well so I'm
  forwarding just this message to cleanup to get a sense of the
  sentiment there.]]

    Part of my objection is that the name NOTICE is too vanilla.
    There are other possible meanings and I can see people being bummed
    if we use it up.
    
    The Lisp Machine has a thing called a notification. I might be
    susceptible to calling the type a NOTIFICATION and making a function
    called NOTIFY. Then, at least, there would be current practice behind
    the idea.
    
I have no objection to these name changes.

    In another message, you suggested things like
     Compiling FOO.
    could be controlled by this, but there's already a competing proposal
    for a :PRINT keyword to COMPILE-FILE which would cause that kind of
    thing to go to STANDARD-OUTPUT (presumably unconditionally). I don't
    want -too- many ways to do the same thing, so we should be careful about
    our motivation.
    
That's true.  I am mildly opposed to the competing proposal because
it's redundant with mine.  I am strongly in favor of one general
condition-based mechanism for all of these messages.

    If we made a notification facility, I think it should be done by Cleanup,
    not compiler. Then perhaps GC messages could be done using it, and 
    the GC-MESSAGES issue (which deals with suppressing such messages) could
    be handled as part of the same thing, too.
    
No object, since it also came up in connection with Moon's comments on
GC-MESSAGES, if forwarding this to cl-cleanup as well.

    I don't have time to pursue this further and I can't say for sure that
    if someone fleshed this out that I would necessarily support it ... but
    I am not unalterably opposed to it if it's done in a way that motivates
    its use (and doesn't just go in randomly with not even an initial purpose),
    doesn't lock down too many short highly generic names, etc.
    
I can try to come up with something, if a condition-based approach to
this whole problem looks acceptable.

∂03-Jan-89  1056	CL-Cleanup-mailer 	Re: Issue GC-MESSAGES (Version 2)   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  10:56:16 PST
Received: from [73.0.0.15] by multimax.encore.com (5.59/25-eef)
	id AA25865; Tue, 3 Jan 89 13:54:43 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA13178; Tue, 3 Jan 89 13:53:43 EST
Message-Id: <8901031853.AA13178@mist.>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue GC-MESSAGES (Version 2) 
In-Reply-To: Your message of Tue, 03 Jan 89 12:50:00 -0500.
Date: Tue, 03 Jan 89 13:53:40 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    Date: Tue, 3 Jan 89 12:50 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
    
        Date: Tue, 03 Jan 89 12:38:44 EST
        From: Dan L. Pierson <pierson@mist.encore.com>
    
    	I still think that focussing on GC messages is wrong, and
    	instead there should be a form that disables unsolicited
    	typeout in general, regardless of its source.  Of course in
    	some operating systems it might be impossible to disable some
    	forms of unsolicited typeout, and in other operating systems
    	unsolicited typeout might not exist (that is, asynchronous
    	messages might always come out in a separate window).  Thus
    	this facility would just do the best effort appropriate for
    	the particular implementation.
        
        I agree in general.  I further think that the cleanest way to handle
        the problem is by having all such output be signalled.
    
    This can't work for asynchronous, unsolicited typeout.

Maybe I did tack this on to the wrong message.  GC-MESSAGES may well
have to be a special case, both because they're almost the only truly
asyncronous events that don't invoke a debugger, and because they have
special consing problems as Kent reminded us.  I think that all (or
almost all) other messages can still be treated in one uniform way.

                                                            In a multiprocess
    system, the cause of the condition leading to message output may not be
    in a "user" process, so signalling in the originating process won't give
    the user any control.

Well, the condition system spec doesn't talk about how handlers are or
aren't inherited across processes.  Since handlers are dynamically
scoped, it might be assumed that a process "inherits" all the handers
in existence when it is created.  While this is probably not true in
most (if not all) existing Lisp multiprocessing systems, it's absence
does make it much harder to bullet proof a delivered application.  

In addition, if handlers are inherited, it would be nice for any lisp
system to allow a user to define handlers that will be inherited by
all processes; I realize that this may not be possible for system
processes in a Lisp Machine.

                           Also there may be multiple "user" processes and it
    may not be obvious which one should receive the signal. I shouldn't
    have to tell this to someone from Encore, you must have faced all these
    issues already!

We have, but not in a Lisp context!  In general you can either have a
special signal handling process or let each process do it's best.  It
depends on what the signal and application are trying to do.  A single
signal handing process doesn't scale well, so I wouldn't want to use
it for something like divide by zero execptions (if my code was
prepared to handle those efficiently and I could get them delivered to
the originating process(or)), but that probably doesn't matter for
user interfaces.  On the other hand, scaling doesn't really matter
unless you have several multiple processors.  A Mach approach is to
have one thread with receive rights to a port that gets all errors.

While I'm very concerned about language changes that might make a
parallel lisp harder to create or define, I've been less worried about
user interface issues like this.  All of your hard objections apply
just as much to any error handling (or even invoking the debugger) as
they do to printing a message.  We've adopted a condition system that
doesn't deal with any of these issues because the language standard
doesn't deal with multitasking (e.g. stack groups) at all, let alone
true parallel processing.  If the condition system is going to be
useful to users (and customers), multitasking implementations are
going to have to find answers to many of these problems.  It won't be
easy, but that does that mean that we'd be better off without a
condition system?

                     Also a special form that disables unsolicited typeout
    during the dynamic extent of its body could interact with the operating
    system to disable or defer operating-system-generated typeout, but in
    most operating systems it would be much more difficult to arrange for
    the operating system to signal a Lisp condition when it wants to type
    something out.
    
True, but the stock hardware operating systems I've worked with don't
tend to type things out.  They just signal errors, return a bad status
code, or abort your program.  Of course, linked-in foreign language
code may do such a thing, but that's only a problem for
implementations that use such code themselves.  Any typeout proposal
that we come up with isn't going to control what the user can do to
himself.

    It's too bad it can't work, because it certainly would be cleaner.
    
It can't work for GC-MESSAGES, but does that mean it can't work for
the loader, compiler, etc?  I'm not convinced yet.

∂03-Jan-89  1227	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Jan 89  12:27:03 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514582; Tue 3-Jan-89 15:25:04 EST
Date: Tue, 3 Jan 89 15:24 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890103-113603-1600@Xerox>
Message-ID: <890103152425.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 3 Jan 89 11:35 PST
    From: masinter.pa@Xerox.COM

    Well, I think it is enforcable, if you have specialized storage.

Can you give me a concrete example? I'm basically saying that since it's you
that wants to introduce a restriction, the burden of proof is on you to show
a single example where the restriction buys you somthing. If you think it
does buy you something, I'm not calling you a liar -- I'm just saying I'm not
able to see the example you're hinting at.

So far, the only concrete example we have is one which has a perfectly
legitimate interpretation or an "is an error" interpretation. You're saying
you want to opt for the "is an error" interpretation, but you're not saying
what I buy for giving up the flexibility.

As soon as we start talking about concrete examples, I think we'll be making
headway.

∂03-Jan-89  1507	CL-Cleanup-mailer 	ballot
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Jan 89  15:07:20 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA01829; Tue, 3 Jan 89 16:06:06 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA06115; Tue, 3 Jan 89 16:06:00 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8901032306.AA06115@defun.utah.edu>
Date: Tue, 3 Jan 89 16:05:56 MST
Subject: ballot
To: cl-cleanup@sail.stanford.edu

Here's my ballot.  I represent (officially) the University of Utah CS
department.

ARGUMENTS-UNDERSPECIFIED:SPECIFY				Y
	Version 4, 21-Sep-88, Mailed 4 Dec 88

ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING		Y
	Version 9, 31-Oct-88, Mailed 5 Dec 88

CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY				Y
	Version 5,  5-Dec-88, Mailed 5 Dec 88

CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE			Y
	Version 1, 14-Sep-88, Mailed 6 Oct 88

DECLARATION-SCOPE:NO-HOISTING					Y
DECLARATION-SCOPE:LIMITED-HOISTING				N
	Version 4, 15-Nov-88, Mailed 9-Dec-88

DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION		Y
	Version 4,  5-Dec-88, Mailed  5-Dec-88

DECLARE-TYPE-FREE:ALLOW						Y
	Version 8, 7-Dec-88, Mailed 9-Dec-88

DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE			A
	Version 2, 30-Sep-88, Mailed 6 Oct 88

DEFPACKAGE:ADDITION						Y
	Version 7, 2-Nov-88, Mailed 5 Dec 88

DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY			Y
	Version 2, 21-Sep-88, Mailed 6 Oct 88

DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES			Y
	Version 3, 7 Dec 88, Mailed 12-Dec-88

DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR		Y
	Version 4, 31-Oct-88, Mailed 12-Dec-88

DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE				N
DESCRIBE-INTERACTIVE:NO						Y
	Version 4, 15-Nov-88	, Mailed 7-Dec-88

DOTTED-MACRO-FORMS:ALLOW					Y
	Version 3, 15-Nov-88, Mailed 7-Dec-88

EQUAL-STRUCTURE:STATUS-QUO					A
	Version 5, 1-Oct-88, Mailed 8 Oct 88

EXIT-EXTENT:MINIMAL						N
EXIT-EXTENT:MEDIUM						Y
	Version 5, 12-Dec-88, Mailed 12-Dec-88

EXPT-RATIO:P.211						Y
	Version 3, 31-Oct-88, Mailed 7 Dec 88

FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION				I*
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM			Y
	Version 4, 7-Dec-88, Mailed 12-Dec-88
  * I will vote for TIGHTEN-DEFINITION if TIGHTEN-FIXNUM-TOSS-BIGNUM
    is voted down.

FORMAT-E-EXPONENT-SIGN:FORCE-SIGN				A
	Version 2, 2 Oct 88, Mailed 6 Oct 88

FORMAT-PRETTY-PRINT:YES						Y
	Version 7, 15 Dec 88, Mailed 7 Dec 88

FUNCTION-COMPOSITION:NEW-FUNCTIONS				N
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS			Y
	Version 4, 12 Dec 88, Mailed 12 Dec 88

FUNCTION-DEFINITION:FUNCTION-SOURCE				Y
	Version 2, 09-Dec-88	, Mailed 9 Dec 88

FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE		Y
	Version 3, 7-Dec-88, Mailed  12-Dec-88

FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE	A
	Version 5, 14-Nov-88	, Mailed 8-Dec-88

GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD			Y
	Version 2, 8 Dec 88, Mailed 8 Dec 88

HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER			N
	Version 7, 8-Dec-88, Mailed 9-Dec-88

HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS			C*
	Version 1, 11-Nov-88	, Mailed 12 Dec 88
  * I agree with the sentiments expressed in the "additional comment"
    at the end.  I'd rather see a shorter proposal that deals only
    with destructive operations on keys.

HASH-TABLE-TESTS:ADD-EQUALP					N
	Version 2, 8-Dec-88, Mailed 8 Dec 88

IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY				N
	Version 4, 12-Dec-88, Mailed 12-Dec-88

LAMBDA-FORM:NEW-MACRO						N
	Version 4, 22-Nov-88, Mailed 8-Dec-88

LCM-NO-ARGUMENTS:1						Y
	Version 1, 17 Oct 88, Mailed 8 Dec 88

LISP-SYMBOL-REDEFINITION:DISALLOW				Y
	Version 5, 22-Nov-88, Mailed 8 Dec 88

MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT		N
	Version 2, 8 Oct 88, Mailed 12-Dec-88

MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE		Y
	Version 2, 09-Jun-88, Mailed 8 Oct 88

NTH-VALUE:ADD							N
	Version 4, 8-Dec-88, Mailed 8 Dec 88

PACKAGE-CLUTTER:REDUCE						I*
	Version 6, 12-Dec-88, Mailed 12-Dec-881
  * I don't see any need to restrict the use of internal symbols in
    the LISP package as property indicators.  Otherwise I support the
    proposal.

PACKAGE-DELETION:NEW-FUNCTION					A
	Version 5, 21 nov 88, Mailed 8 Dec 88

PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN				I*
	Version 1 27-Jun-88, Mailed 7 Oct 88
  * :UNSPECIFIC should be legal in all pathname fields, not just in the
    type field.

PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR			N, C*
	Version 3, 8-Oct-88, Mailed 8 Oct 88
  * This proposal seems to be in conflict with the rationale for
    issue UNREAD-CHAR-AFTER-PEEK-CHAR, which is to legitimize
    implementing PEEK-CHAR as READ-CHAR/UNREAD-CHAR.
   
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK			I*
	Version 3, 20 Sep 88, Mailed 8 Oct 88
  * This proposal would be OK if it specified that circularity only
    had to be detected for objects that are contained in slots of the
    structure, not random objects that are printed out by the structure
    print function.  Rationale:  an obvious way to handle circular
    printing is to traverse the structure to detect circularities before
    printing anything.

PROCLAIM-LEXICAL:LG						N*
	Version 9, 8-Dec-88, Mailed 12-Dec-88
  * I don't have any fundamental complaint with this issue, but I believe 
    we need more experience with this feature before it should be 
    standardized.

RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER				Y
	Version 3, 9-Oct-88, Mailed 14-Oct-88

RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL	Y
	Version 1, 14-Sep-88, Mailed 7 Oct 88

REQUIRE-PATHNAME-DEFAULTS:ELIMINATE				Y
	Version 6, 9 Dec 88, mailed 09 Dec 88

REST-LIST-ALLOCATION:NEWLY-ALLOCATED				N
REST-LIST-ALLOCATION:MAY-SHARE					Y
REST-LIST-ALLOCATION:MUST-SHARE					N
	Version 3, 12-Dec-88, mailed 12-Dec-88

RETURN-VALUES-UNSPECIFIED:SPECIFY				Y
	Version 6,  9 Dec 88 mailed  9-Dec-88

ROOM-DEFAULT-ARGUMENT:NEW-VALUE					A
	Version 1 12-Sep-88 mailed 8 Oct 88

[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS				N
	Version 3, 4-Nov-87, mailed Nov 87
SETF-PLACES:ADD-SETF-FUNCTIONS					I*
	Version 1, 11-Nov-88, mailed 9-Dec-88
  * I already commented separately on this issue.

SETF-SUB-METHODS:DELAYED-ACCESS-STORES				Y
	Version 5, 12-Feb-88 mailed 8 Oct 88

STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS		Y
	Version 8, 8 Jul 88, Mailed 7 Oct 88

STEP-ENVIRONMENT:CURRENT					Y
	Version 3, 20-Jun-88, mailed  7 Oct 88

STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS			I*
	version 2, 30-Nov-88 mailed  9 Dec 88
	(expect amendment T => "true")
  * If the amendment is accepted.

STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS				Y
	Version 6, 30-Nov-88, mailed 9 dec 88
	expect amendment:
		LINE-WIDTH   ==> STREAM-LINE-WIDTH
		LINE-POSITION ==> STREAM-LINE-POSITION
		PRINTED-WIDTH ==> STREAM-STRING-WIDTH


SUBTYPEP-TOO-VAGUE:CLARIFY					Y
	Version 4,  7-Oct-88, mailed 7 Oct 88 

SYMBOL-MACROLET-DECLARE:ALLOW					I*
	Version 2,  9-Dec-88, mailed 9 Dec 88
  * Only if SYMBOL-MACROLET-SEMANTICS passes.

SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM				A
	Version 5, 30-Nov-88, mailed 9 Dec 88

TAGBODY-CONTENTS:FORBID-EXTENSION				Y
	Version 5, 9-Dec-88 mailed 9 Dec 88

TAILP-NIL:T							Y
	Version 5, 9-Dec-88, mailed 12-Dec-88

TEST-NOT-IF-NOT:FLUSH-ALL					Y
TEST-NOT-IF-NOT:FLUSH-TEST-NOT					I*
	Version 3, 1 Dec 88 mailed 9 dec 
  * Flushing some is better than not flushing all.

TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS			Y
	Version 3, 12-Dec-88, mailed 12 Dec 88
	(some "bugs" in the proposal)

UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW				Y
	Version 2, 2-Dec-88, mailed 12-Dec-88

VARIABLE-LIST-ASYMMETRY:SYMMETRIZE				Y
	Version 3, 08-Oct-88, mailed 9 Dec 88


-------

∂03-Jan-89  1818	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89  18:18:13 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 JAN 89 11:36:03 PST
Date: 3 Jan 89 11:35 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Tue, 3 Jan 89 01:31 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM,
 CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <890103-113603-160@Xerox>

Well, I think it is enforcable, if you have specialized storage.

I think the direction of your inference is backward. ALLOW is more powerful
than LEXICAL.  A program that is correct using ALLOW semantics remains
correct using LEXICAL semantics. Thus, an implementation that can only
enforce LEXICAL will still accept programs that are correct under ALLOW.
The converse is not true. 

Thus, ALLOW is more restrictive, and it allows implementations more
freedom, while not putting any unreasonable constraints on programs that
want to use declarations.


∂03-Jan-89  1819	CL-Cleanup-mailer 	meeting in Hawaii    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89  18:19:29 PST
Received: from Semillon.ms by ArpaGateway.ms ; 03 JAN 89 13:20:07 PST
Date: 3 Jan 89 13:09 PST
From: masinter.pa@Xerox.COM
Subject: meeting in Hawaii
To: cl-cleanup@sail.stanford.edu
Message-ID: <890103-132007-189@Xerox>

How many of you would be available for a meeting on Sunday? Thursday? 


∂03-Jan-89  1820	CL-Cleanup-mailer 	Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89  18:20:05 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 03 JAN 89 18:17:29 PST
Date: 3 Jan 89 17:03 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Thu, 22 Dec 88 18:44 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890103-181729-1162@Xerox>

I like INTERCHANGABLE too.

I thought we might actually do more to backquote than just this.


∂03-Jan-89  2230	CL-Cleanup-mailer 	Issue: REST-LIST-ALLOCATION (Version 3)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 3 Jan 89  22:30:35 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03970g; Tue, 3 Jan 89 22:25:13 PST
Received: by bhopal id AA01102g; Tue, 3 Jan 89 22:27:25 PST
Date: Tue, 3 Jan 89 22:27:25 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901040627.AA01102@bhopal>
To: will@fog.cs.uoregon.edu
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: William Clinger's message of Tue, 3 Jan 89 08:59:44 PDT <8901031659.AA06887@fog.cs.uoregon.edu>
Subject:  Issue: REST-LIST-ALLOCATION (Version 3)

re: To my way of thinking, APPLY never copies any arguments so APPLY is
    perfectly consistent with FUNCALL even if &REST lists are always
    freshly consed.  You see, my understanding of APPLY is that it calls
    its first argument on the elements of the list that is its second
    argument (or the analagous thing if you give it more than two arguments).
    The arguments, therefore, are the elements of the list, not the list
    itself, and so the arguments are not copied.

There was much debate on the Common-Lisp mailing list some months back,
and I vaguely remember the upshot being that "users" definitely did not
want the _default_ state of &rests to be anything optimized -- it leads
to far too much confusion when debugging.  On the other side, numerous
implementors (especially those with roots in MIT) argued at length for
the freedom to make one or other time-saving or space-sharing hack.

In acknowledgement of the trade-off between efficiency and "clean, 
simple" semantics, people seemed willing to allow a declaration which
permited one or more of these hacks.  For example, DYNAMIC-EXTENT could
be applied to the variable holding the &rest argument, meaning that
it is OK to stack-cons it.  Gail Zacharias stated this position most
succinctly -- the demand for simple semantics by default, with "hair"
to be added at the users discretion -- although it would take me a
while to resurrect the old mail.  [Frankly, however, I don't remember
anyone proposing a declaration/proclamation that permitted the
APPLY-->&rest hack.]

Many of  the arguments against "sharing" were similar to what I've quoted 
from your msg above.  I agree with your explanation of APPLY, even
though I'm an implementor with "roots in MIT" (actually, so is GZ!).

Lucid's implementation works similar to Xerox/Envos' Medley in regard
to &rest treatment; however it does have a stack-consing capability
enabled by declarations.  Either way, as Larry Masinter points out,
it would be a tremendous re-vamp of the implemntation to even permit
the smallest amount of sharing when called via APPLY.


-- JonL --


∂04-Jan-89  0103	CL-Cleanup-mailer 	Issue: HASH-TABLE-STABILITY (Version 1)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  01:03:11 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04034g; Wed, 4 Jan 89 00:59:24 PST
Received: by bhopal id AA01426g; Wed, 4 Jan 89 01:01:36 PST
Date: Wed, 4 Jan 89 01:01:36 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901040901.AA01426@bhopal>
To: IIM@ECLA.USC.EDU
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kim A. Barrett's message of 2 Jan 89 15:20 PST <890102-152101-1732@Xerox>
Subject: Issue: HASH-TABLE-STABILITY (Version 1)

re:   (if (numberp x) (sxhash x) (%unique-no x))

    the NUMBERP test really should be (OR (NUMBERP X) (CHARACTERP X)), ...


Ooops, right.  Thanks for noticing it.

I've also noticed a bit of inconsistency in the use of the term
"key transformation".  The "terminology" section mentions two
variant meanings for the term, but I'd prefer now to see it made
more rigorous; perhaps "hash function" could be used for the 
variant which is typically dependent on the table size.


-- JonL --

∂04-Jan-89  0140	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 9)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  01:40:51 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04040g; Wed, 4 Jan 89 01:37:07 PST
Received: by bhopal id AA01494g; Wed, 4 Jan 89 01:39:19 PST
Date: Wed, 4 Jan 89 01:39:19 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901040939.AA01494@bhopal>
To: masinter.pa@Xerox.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 2 Jan 89 22:12 PST <890102-221315-1967@Xerox>
Subject: Issue: DECLARE-TYPE-FREE (Version 9)

re: If I say (DECLARE (TYPE (SIGNED-BYTE 12) X)), I'd think I'd like it to mean
    that X never even momentarily holds a value that isn't of the declared
    type.

For "bound" type declarations, it does mean this -- because the lexical 
scope includes all the code that can ever be executed during the dynamic
extent of that (binding) contour.  But for "free" type declarations,
we have a choice; we can say that it applies to the lexical scope,
or that it applies to the dynamic extent.  Clearly, the former is
simpler, and more in line with our other views on declaration
scoping; see for example this issue DECLARATION-SCOPE, especially
the parallelism between the scoping rules for variables (lexical)
and those for declarations.


re: I'd like to see the writeup make it clear that the following is subsumed;
    note that this issue never was released or appeared on a Status list, so 
    it should probably just be included:
      Date: Fri, 4 Nov 88 18:05:21 CST
      From: David N Gray <Gray@DSG.csc.ti.com>
      To: cl-cleanup@sail.stanford.edu
      Subject: Issue SPECIAL-TYPE-SHADOWING (V1)
      . . . 
      Proposal SPECIAL-TYPE-SHADOWING:CLARIFY

	Clarify that if there is a local type declaration for a special
	variable, and there is also a global type proclamation for that same
	variable, then the value of the variable within the scope of the local
	declaration must be a member of the intersection of the two declared
	types.


I don't think it is subsumed.  The various versions of DECLARE-TYPE-FREE
permitted an inner nested declaration to be merely overlapping with
an outer declaration; but Gray's proposal requires local (read: "inner")
declarations to be subtypes of the global proclamations (read: "outter")


-- JonL --

∂04-Jan-89  0206	CL-Cleanup-mailer 	Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)   
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  02:06:35 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04049g; Wed, 4 Jan 89 02:02:39 PST
Received: by bhopal id AA01559g; Wed, 4 Jan 89 02:04:51 PST
Date: Wed, 4 Jan 89 02:04:51 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901041004.AA01559@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: masinter.pa@Xerox.COM, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Kent M Pitman's message of Tue, 3 Jan 89 01:46 EST <890103014612.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: GET-MACRO-CHARACTER-READTABLE (Version 2)

re: I have a problem with version 2 because I don't think anything requires
    get-dispatch-macro-character to return the same function on successive
    calls even with the same readtable (provided the functions returned are
    equivalent). As such, the example is inappropriate where it uses ASSERT
    and EQ.

There is no "Examples" section in this proposal -- perhaps you meant
"Test Case"?  As such, it's clear that the test case can only be
applied to implementations where GET-MACRO-CHARACTER returns the same 
thing between two successive calls which don't modify the table.  

It would be hard to imagine writing a test case where you had to solve 
the Turing Machine Halting problem first.  Determining whether two 
function objects (i.e. functions as returned by GET-MACRO-CHARACTER) 
define the same mathematical function is equivalent to the Halting 
problem.


-- JonL --




∂04-Jan-89  0210	CL-Cleanup-mailer 	Issue: PATHNAME-LOGICAL ? 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  02:10:44 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04052g; Wed, 4 Jan 89 02:06:12 PST
Received: by bhopal id AA01565g; Wed, 4 Jan 89 02:08:19 PST
Date: Wed, 4 Jan 89 02:08:19 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901041008.AA01565@bhopal>
To: eb@lucid.com
Cc: masinter.pa@Xerox.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
        CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Eric Benson's message of Tue, 3 Jan 89 07:54:37 pst <8901031554.AA00248@blacksox>
Subject: Issue: PATHNAME-LOGICAL ?

re: Yes, I meant to say logical pathnames.

Or, did you say, PATH-LOGICAL NAMES?


-- JonL --

∂04-Jan-89  0224	CL-Cleanup-mailer 	Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  02:24:33 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04062g; Wed, 4 Jan 89 02:20:45 PST
Received: by bhopal id AA01609g; Wed, 4 Jan 89 02:22:57 PST
Date: Wed, 4 Jan 89 02:22:57 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901041022.AA01609@bhopal>
To: pierson@mist.encore.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dan L. Pierson's message of Tue, 03 Jan 89 12:15:07 EST <8901031715.AA12970@mist.>
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES 

re:     But if all that Dan wanted to say was that the array
        references were assumed to satisfy the *upgrade* of the declared type,
        then there would be no problem (with that part).
    
    Sorry, but that's exactly the opposite of what I meant.  If I declare
    an array, FOO, to be (SIGNED-BYTE 5), within the scope of that
    definition I'm saying that expect references to that array to be
    equivalent to:
        (THE (SIGNED-BYTE 5) (AREF FOO X))
    No matter what the array was upgraded to.  

Yea, that's what I thought you meant, and that's what I think is
inconsistent with the "unification" in issue ARRAY-ELEMENT-TYPE-SEMANTICS.

re: Actually, your name got put in support because of an early message of
    yours (which I finally found) in the ARRAY-ELEMENT-TYPE-SEMANTICS
    discussion.  I'll be happy to remove your name if we now disagree.

I fear that my very first reading of DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
was too hasty, and I incorrectly thought it was subsumed by
ARRAY-ELEMENT-TYPE-SEMANTICS.  I'm sure I recanted that apostasy in
later mail.


re: As I've said before, I support a strict type checking mode for all
    Common Lisp compilers.  However I now suspect that it's too late (and
    maybe too experimental) to get in this version of the standard.  I
    said I'd write up a proposal for it at the cleanup meeting last
    October, but was later talked out of doing so.

Why?  [i.e., Why did you get "talked out of doing so"?]  I remember 
discussing this with you at length during the Palo Alto meeting in
March 1988 and likeing it very much.  However -- I hasten to point
out -- it would help not to confuse this issue with the very limited
scope of DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES, which has it's own
peculiar problems related to "upgrading".


-- JonL --

∂04-Jan-89  0311	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE, v4   
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 4 Jan 89  03:11:07 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa03629; 4 Jan 89 10:47 GMT
Date: Tue, 3 Jan 89 17:26:31 GMT
Message-Id: <29459.8901031726@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue FIXNUM-NON-PORTABLE, v4
To: "Kim A. Barrett" <IIM@ecla.usc.edu>, cl-cleanup@sail.stanford.edu
In-Reply-To: Kim A. Barrett's message of Sat 31 Dec 88 19:47:14-PST
Cc: iim@ecla.usc.edu

> There are relatively few legitimate uses of FIXNUM in portable code,

While I sometimes use such arguments myself, I do not think it is
true in general that only portable code matters.  I want fixnums
because they let me do something is the same way in all implementations
that do it.  Also, in most implementations fixnums are big enough to
contain the address part of a pointer to a data object.  Therefore,
they are always big enough to count objects.

∂04-Jan-89  0623	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE, v4   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  06:23:11 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA01227; Wed, 4 Jan 89 09:21:59 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA13950; Wed, 4 Jan 89 09:22:00 EST
Message-Id: <8901041422.AA13950@mist.>
To: Jeff Dalton <"jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK"@multimax.encore.com>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue FIXNUM-NON-PORTABLE, v4 
In-Reply-To: Your message of Tue, 03 Jan 89 17:26:31 +0000.
             <29459.8901031726@subnode.aiai.ed.ac.uk> 
Date: Wed, 04 Jan 89 09:21:57 EST
From: Dan L. Pierson <pierson@mist.encore.com>

                 Also, in most implementations fixnums are big enough to
    contain the address part of a pointer to a data object.  Therefore,
    they are always big enough to count objects.
    
Note that this proposal does not guarantee that fixnums will be large
enough for your purposes; all Common Lisp systems will need more than
16 address bits...

∂04-Jan-89  1116	CL-Cleanup-mailer 	Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  11:15:55 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA02902; Wed, 4 Jan 89 13:53:40 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA14296; Wed, 4 Jan 89 13:53:41 EST
Message-Id: <8901041853.AA14296@mist.>
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES 
In-Reply-To: Your message of Wed, 04 Jan 89 02:22:57 -0800.
             <8901041022.AA01609@bhopal> 
Date: Wed, 04 Jan 89 13:53:39 EST
From: Dan L. Pierson <pierson@mist.encore.com>

        Sorry, but that's exactly the opposite of what I meant.  If I declare
        an array, FOO, to be (SIGNED-BYTE 5), within the scope of that
        definition I'm saying that expect references to that array to be
        equivalent to:
            (THE (SIGNED-BYTE 5) (AREF FOO X))
        No matter what the array was upgraded to.  
    
    Yea, that's what I thought you meant, and that's what I think is
    inconsistent with the "unification" in issue ARRAY-ELEMENT-TYPE-SEMANTICS.
    
It seems that we disagree here.  I'll remove your endorsement from the
next version of the proposal.

    re: As I've said before, I support a strict type checking mode for all
        Common Lisp compilers.  However I now suspect that it's too late (and
        maybe too experimental) to get in this version of the standard.  I
        said I'd write up a proposal for it at the cleanup meeting last
        October, but was later talked out of doing so.
    
    Why?  [i.e., Why did you get "talked out of doing so"?]  I remember 
    discussing this with you at length during the Palo Alto meeting in
    March 1988 and likeing it very much.  However -- I hasten to point
    out -- it would help not to confuse this issue with the very limited
    scope of DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES, which has it's own
    peculiar problems related to "upgrading".
    
Well, it was a combination of factors: the issue looked to be
extremely controversial; several well respected people were arguing
against much milder proposals on the grounds that no one had
implemented them (FUNCTION-COMPOSITION comes to mind); and Larry made
a strong pitch that time was running out and we should concentrate our
efforts on the important issues that still might be resolved in time.

I clearly don't have time to do a full writeup by Hawaii, but am still
willing to consider doing one later; I've also considered a Lisp
Pointers article as an alternative or addition.  It seems that a very
relevant question is whether any vendors would consider making such a
feature part of their product if it wasn't required.  If the answer to
that is no, then I would have to reluctantly admit that the
standardization case is -very- weak.  

Right now, I'm more likely to devote time to a foreign function
interface standard, since almost everyone implements the feature and
many of the differences are clearly unnecessary, if not plain
gratuitous.  The same arguments might apply to multiprocessing ala
stack groups (though emphatically not to parallel lisp).

Just to remove any doubt, I personally think that such a "string
typing" feature is very, very valuable and have felt and argued that
way since the early VAX Lisp days.  For one thing, the lack of this
feature makes it extremely difficult to move a non-trivial application
from low SPEED, high SAFETY to the reverse.  You currently have to go
straight from generic operations that "always" work to no-holds-barred
inline code where errors can do anything; a mode that checked your
declarations and signalled precise errors would make debugging and QA
of such an application vastly easier.  If we want people to produce
serious applications and products with Common Lisp, we have to give
them the tools to produce efficient and safe code without sacrificing
the traditional development advantages of Lisp.  This feature helps do
exactly that.


∂04-Jan-89  1137	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE, v4   
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 4 Jan 89  11:37:25 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa06991; 4 Jan 89 19:11 GMT
Date: Wed, 4 Jan 89 19:16:04 GMT
Message-Id: <1732.8901041916@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue FIXNUM-NON-PORTABLE, v4 
To: Jeff Dalton <"jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK"@multimax.encore.com>, 
    pierson <@multimax.encore.com:pierson@mist.encore.com>
Cc: cl-cleanup@sail.stanford.edu

>                  Also, in most implementations fixnums are big enough to
>     contain the address part of a pointer to a data object.  Therefore,
>     they are always big enough to count objects.
>     
> Note that this proposal does not guarantee that fixnums will be large
> enough for your purposes; all Common Lisp systems will need more than
> 16 address bits...

That's one of the problems with saying 16 bits: it might increase the
likelihood that implementations will do something that losing.  It would
be nice if there were some way to test whether fixmuns were big enough
(if we can't actually guarantee it), but it's worth noting that right
now fixnums work better for this purpose that any particular number of
bits I might pick.

∂04-Jan-89  1503	CL-Cleanup-mailer 	Issue PATHNAME-PRINT-READ, v1  
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 4 Jan 89  15:02:57 PST
Date: Wed 4 Jan 89 13:57:23-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue PATHNAME-PRINT-READ, v1
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12459944142.14.IIM@ECLA.USC.EDU>

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.

kab
-------

∂04-Jan-89  1547	CL-Cleanup-mailer 	meeting in Hawaii    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Jan 89  15:46:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 515446; Wed 4-Jan-89 18:45:15 EST
Date: Wed, 4 Jan 89 18:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: meeting in Hawaii
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890103-132007-189@Xerox>
Message-ID: <19890104234443.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 3 Jan 89 13:09 PST
    From: masinter.pa@Xerox.COM

    How many of you would be available for a meeting on Sunday? Thursday? 

I will be there Sunday but not Thursday.

∂04-Jan-89  1549	CL-Cleanup-mailer 	Issue PATHNAME-PRINT-READ, v1  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Jan 89  15:49:13 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 515448; Wed 4-Jan-89 18:48:01 EST
Date: Wed, 4 Jan 89 18:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue PATHNAME-PRINT-READ, v1
To: IIM@ECLA.USC.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <12459944142.14.IIM@ECLA.USC.EDU>
Message-ID: <890104184739.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

Yes, hosting is an issue that I deliberately glossed in the proposal.
Let me say a few words about that and other issues that have been raised.

 - I think #P is better than #. for the same reasons that Touretzky
   proposed #H instead of relying on #. . That is, because most Lisp
   data can be understood by engines considerably less complex than
   Lisp itself. Lists, numbers, etc. are parseable and manipulable
   [are those really words? I say them a lot but they look funny 
   written down..] by simpler programs which do not contain EVAL.
   Using #. makes a large barrier to such programs in manipulating
   any data involving pathnames, which a priori should not be an
   opaque concept to non-Lisp programs.

 - The issue of hosts is more severe in a multi-file-system 
   environment than many CL implementors working in single-file-system
   environments may realize. At Symbolics, the decision was made a
   long time ago to use what's called the `host colon' convention.
   Basically, it says that the first `:' in a filename is -always-
   the separator of the host from other host-specific syntax. To
   avoid ambiguity, we simply define that you cannot have a 
   namestring with a device specifier (or whatever other host-specific
   thing a `:' may mean) without having a host specifier. So, if my
   default host is a Tops-20 named Hydrogen, I can write "<FOO>" or
   "H:<FOO>" to mean "<FOO>" on Hydrogen, but if there is a device
   "H" on Hydrogen, I must write either "H:H:<FOO>" 
   (to be context-independent) or ":H:<FOO>" (if I know that H is
   the default and I want to get past the `host colon'. Our
   NAMESTRING and PARSE-NAMESTRING obey these same conventions.
   So Symbolics pathnames print as #P"host:asdf" (to use your example
   above) without ambiguity. But I agree that without such a convention,
   there are still some rough edges. To make things work for external
   interfaces, though, pathnames support a :string-for-host message
   which gives you the string the file system wants to see.

   I have not proposed the Symbolics solution (which was a major
   changeover at the time it was introduced) even though I think it's
   the right thing (and has solved a lot of major problems) mostly 
   because I've seen serious resistance [eg, in issue PATHNAME-COMPONENT-CASE]
   to solving issues of multiple file systems. My impression is that
   enough people either believe that there is only one file system in
   the world or only one that they'll ever have to deal with or
   or at least only one that they'll have to deal with in any given
   running Lisp that they feel comfortable just sweeping these issues
   under the rug. I think that's very sad, and I think they're making
   a big mistake, but there's only so much I can do. Either someone
   else with multiple-file-system experience needs to stand up and
   help with this problem, or someone from the single-file-system
   world needs to our community a vote of confidence that we're not
   pushing these things on people gratuitously, or else people should
   just hang it up and expect to get screwed by cross-host problems
   such as the very real one you allude to.

∂04-Jan-89  1633	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, v1
Received: from ECLA.USC.EDU by SAIL.Stanford.EDU with TCP; 4 Jan 89  16:32:59 PST
Date: Wed 4 Jan 89 13:59:03-PST
From: Kim A. Barrett <IIM@ECLA.USC.EDU>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, v1
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim@ECLA.USC.EDU
Message-ID: <12459944447.14.IIM@ECLA.USC.EDU>

> Date: Tue, 3 Jan 89 08:10:38 pst
> From: Eric Benson <eb@lucid.com>
>
> MACRO-FUNCTION should not accept the environment argument received by
> an *EVALHOOK* or *APPLYHOOK* function.  (*APPLYHOOK* should not even
> receive an environment argument, was there ever a cleanup issue
> addressing this?)

I want MACRO-FUNCTION to accept these so that MACROEXPAND (which does) can
simply pass such objects along to MACRO-FUNCTION.  My expectation is that
MACRO-FUNCTION (or the underlying mechanism it is based on) will look at this
thing and say "nope, not a compiler environment, lets go look in the current
function cell (or wherever the implementation puts macro expander functions)".

Yes, if APPLYHOOK has been "cleaned up" then references to it should be removed
from this proposal.

> In that case, what does MACRO-FUNCTION return when there is a MACROLET
> definition visible?  It must return some non-NIL value.  It should be
> the expansion function, to be consistent with the global case.

Right, it should be an expander function.  I don't have any really strong
preference for whether it actually "looks inside" the environment object to see
if there are any local definitions (macro or function).  I mostly proposed it
work that way so that it stayed compatible with CLtL's description, which only
talks about global definitions.  Of course, CLtL doesn't have it taking an
environment argument, so maybe I goofed here.  However, as I mentioned in the
discussion, MACRO-FUNCTION is primarily used as a predicate and a place for
SETF.  Does anybody outside of MACROEXPAND actually use the returned expander
function? 

kab
-------

∂04-Jan-89  1641	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, v1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  16:41:25 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA04915g; Wed, 4 Jan 89 16:37:33 PST
Received: by blacksox id AA00536g; Wed, 4 Jan 89 16:39:53 pst
Date: Wed, 4 Jan 89 16:39:53 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901050039.AA00536@blacksox>
To: IIM@ECLA.USC.EDU
Cc: cl-cleanup@SAIL.STANFORD.EDU, iim@ECLA.USC.EDU
In-Reply-To: Kim A. Barrett's message of Wed 4 Jan 89 13:59:03-PST <12459944447.14.IIM@ECLA.USC.EDU>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, v1

I don't think MACROEXPAND should be required to accept EVALHOOK-type
environments either.

∂04-Jan-89  1900	CL-Cleanup-mailer 	meeting in Hawaii    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  19:00:32 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA05101g; Wed, 4 Jan 89 18:56:44 PST
Received: by bhopal id AA03464g; Wed, 4 Jan 89 18:58:56 PST
Date: Wed, 4 Jan 89 18:58:56 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901050258.AA03464@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 3 Jan 89 13:09 PST <890103-132007-189@Xerox>
Subject: meeting in Hawaii

I'll be available after about 4PM Sunday, and up until about 10AM Thursday.

-- JonL --

∂05-Jan-89  1113	CL-Cleanup-mailer 	Symbolics response to mail ballot   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Jan 89  11:12:39 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 515914; Thu 5-Jan-89 14:11:27 EST
Date: Thu, 5 Jan 89 14:10 EST
From: Moon@STONY-BROOK.SCRC.Symbolics.COM,
      KMP@STONY-BROOK.SCRC.Symbolics.COM
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Symbolics response to mail ballot
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890105141057.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

These votes represent the official position of Symbolics.

Because of the volatility of some issues from version to version,
readers are reminded that our votes apply only to the indicated
versions of the writeup.

In the notes column, "comment" means we have comments which do
not necessarily affect our vote, but which we felt important
to mention. On the other hand, "provisional" means that
we have placed conditions on the indicated vote, and the vote does
not apply unless the conditions are met. Comments and provisions
follow at the end of this message.

Blank lines in the summary are just for readability. They don't
indicate any kind of grouping.

---Summary---

Issue:Proposal(Version)                                      Vote  Notes

ARGUMENTS-UNDERSPECIFIED:SPECIFY(4)                          Yes   ---
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING(9)         Yes   comment
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY(5)                    Yes   ---
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE(1)             Yes   ---
DECLARATION-SCOPE:LIMITED-HOISTING(4)                        Yes   ---

DECLARATION-SCOPE:NO-HOISTING(4)                             No    ---
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION (4)     Yes   comment
DECLARE-TYPE-FREE:ALLOW(8)                                   No    comment
DECLARE-TYPE-FREE:LEXICAL(9, unreleased)                     Yes   comment
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE(2)                Yes   ---

DEFPACKAGE:ADDITION(7)					     Yes   comment
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY(2)               Yes   comment
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES(3)                  Yes   ---
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR(4)         Yes   ---
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE(4)                     Yes   ---

DESCRIBE-INTERACTIVE:NO(4)                                   No    comment
DOTTED-MACRO-FORMS:ALLOW(3)				     Yes   ---
EQUAL-STRUCTURE:STATUS-QUO(5)				     No    comment
EXIT-EXTENT:MINIMAL(5)					     No    comment
EXIT-EXTENT:MEDIUM(5)					     No    comment

EXPT-RATIO:P.211(3)					     Yes   ---
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION(4)		     Yes   ---
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM(4)	     No    ---
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN(2)			     Yes   ---
FORMAT-PRETTY-PRINT:YES(7)				     Yes   comment

FUNCTION-COMPOSITION:NEW-FUNCTIONS(4)			     Yes   comment
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS(4)		     No    comment
FUNCTION-DEFINITION:FUNCTION-SOURCE(2)			     Yes   ---
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE(3)	     Yes   ---
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE(5)  Yes   comment

GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD(2)		     Yes   comment
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER(7)	     Yes   comment
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS(1)	     No    comment
HASH-TABLE-TESTS:ADD-EQUALP(2)				     Yes   comment
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY(4)			     Yes   provisional

LAMBDA-FORM:NEW-MACRO(4)				     Yes   ---
LCM-NO-ARGUMENTS:1(1)					     Yes   ---
LISP-SYMBOL-REDEFINITION:DISALLOW(5)			     Yes   provisional
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT(2)	     No    comment
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE(2)	     Yes   ---

NTH-VALUE:ADD(4)					     Yes   comment
PACKAGE-CLUTTER:REDUCE(6)				     Yes   comment
PACKAGE-DELETION:NEW-FUNCTION(5)			     Yes   ---
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN(1)			     Yes   ---
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR(3)		     Yes   comment

PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK(3)		     Yes   ---
PROCLAIM-LEXICAL:LG(9)					     Yes   comment
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER(3)		     Yes   ---
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL(1) Yes   ---
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE(6)			     Yes   ---

REST-LIST-ALLOCATION:MAY-SHARE(3)			     Yes   ---
REST-LIST-ALLOCATION:NEWLY-ALLOCATED(3)			     No    ---
REST-LIST-ALLOCATION:MUST-SHARE(3)			     No    ---
RETURN-VALUES-UNSPECIFIED:SPECIFY(6)			     Yes   ---
ROOM-DEFAULT-ARGUMENT:NEW-VALUE(1)			     Yes   ---

SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS(3)		     No    comment
SETF-PLACES:ADD-SETF-FUNCTIONS(1)			     No    comment
SETF-SUB-METHODS:DELAYED-ACCESS-STORES(5)		     Yes   ---
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS(8)	     Yes   ---
STEP-ENVIRONMENT:CURRENT(3)				     Yes   provisional

STREAM-ACCESS:ADD-TYPES-ACCESSORS(2)			     Yes   comment
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS(2)		     No    comment
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS(2)		     No    comment
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS			     Yes   provisional
SUBTYPEP-TOO-VAGUE:CLARIFY(4)				     Yes   comment

SYMBOL-MACROLET-DECLARE:ALLOW(2)			     Yes   ---
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM(5)		     Yes   ---
TAGBODY-CONTENTS:FORBID-EXTENSION(5)			     Yes   provisional
TAILP-NIL:T(5)						     Yes   comment
TEST-NOT-IF-NOT:FLUSH-ALL(3)				     Yes   provisional

TEST-NOT-IF-NOT:FLUSH-TEST-NOT(3)			     Yes   provisional
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS(3)		     Yes   provisional
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW(2)		     Yes   ---
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE(3)			     Yes   ---

---Detail---

Comment on ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9, 31-Oct-88)
  
 We don't think the functions UPGRADED-ARRAY-ELEMENT-TYPE and
 UPGRADED-COMPLEX-PART-TYPE are really necessary, but neither of us
 cares enough to pursue that issue. Otherwise it looks ok.

Comment on DECLARE-FUNCTION-AMBIGUITY (Version 4, 05-Dec-88)

 Moon is mildly opposed to this proposal, DELETE-FTYPE-ABBREVIATION,
 because he sees it as gratuitously incompatible. Pitman favors the
 proposal because he thinks the benefit of making things regular will
 outweigh the costs.

Comment on DECLARE-TYPE-FREE (Version 8, 07-Dec-88)

 Moon approved of an earlier version of this proposal, and wrote 
 a new option, LEXICAL, as part of a version 9 which has not been
 released to X3J13. Both Moon and Pitman support the LEXICAL proposal,
 version 9.

Comment on DEFPACKAGE (Version 7, 02-Nov-88)

 The semantics should be defined in terms of the existing package
 functions rather than being redundantly described, in order to minimize
 the risk that DEFPACKAGE and the package functions will accidentally
 differ in some unintended way.

Comment on DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2, 21-Sep-88)

 The proposal should accomodate comments by IIM about some keywords
 that were (presumably accidentally) not addressed 

Comment on DESCRIBE-INTERACTIVE (Version 4, 15-Nov-88)

 We prefer option EXPLICITLY-VAGUE.
 We would vote "Yes" for the NO option iff EXPLICITLY-VAGUE fails.

Comment on EQUAL-STRUCTURE (Version 5, 01-Oct-88)

 There are important technical comments about EQUALP which have not
 been addressed, and which we feel must be addressed before this is
 brought to a serious vote. Ultimately, when those pending technical
 comments have been addressed, we expect to buy into this proposal.

Comment on EXIT-EXTENT (Version 5, 12-Dec-88)

 Sadly, we feel it is still premature to vote on this issue at this time.
 There are too many errors and inconsistencies in the writeup.

Comment on FORMAT-PRETTY-PRINT (Version 7, 15-Dec-88)

 Although some fixes were made to accomodate ~R, some minor lingering
 questions remain, which should be addressed under separate cover:
   - Is PRINT-OBJECT used to print things of type FLOAT in any cases
     where ~$, ~E, ~F, or ~G is used?
   - Can users write any methods (including :AROUND, :BEFORE, etc) for
     PRINT-OBJECT on type FLOAT?
 If the answers to both of these questions end up being "Yes", then it
 matters whether any of those format ops bind *PRINT-BASE* in order to
 achieve the effect prescribed by CLtL of always printing floats in 
 base 10. If the answer to either of those questions is "No", then
 it doesn't matter.

Comment on FUNCTION-COMPOSITION (Version 4, 12-Dec-88)

 Barry Margolin's complaint about the degenerate case of COMPOSE should be
 fixed in both proposals.

 We prefer option NEW-FUNCTIONS.
 We would vote "Yes" for COMPLEMENT-AND-ALWAYS iff NEW-FUNCTIONS fails.

Comment on FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5, 14-Nov-88)
 
 It turns out the list type specifier being contemplated wouldn't have
 helped the case of alternating keyword value pairs because `repetitions'
 were not among the issues being addressed by those working on that topic.

Comment on GET-MACRO-CHARACTER-READTABLE (Version 2, 8-Dec-88)

 The proposal is ok, but the test case is wrong and should definitely be
 fixed before a vote is called. EQness of successive results from 
 GET-MACRO-CHARACTER when given the same arguments is not guaranteed
 currently, and the new proposal does not suggest causing such a thing.

Comment on HASH-TABLE-PACKAGE-GENERATORS (Version 7, 08-Dec-88)

 The test-package-iterator example has the values from the generator in
 the wrong order. This should be fixed before the actual vote.

Comment on HASH-TABLE-STABILITY (Version 1, 11-Nov-88)

 We believe that it is not appropriate to vote on this issue at this
 time. Neither of us had the patience to figure out in enough detail
 what it was saying to have any confidence in our opinions on the issue.
 If there is really something important going on here, it should be
 possible to say briefly and in plain English what the problem being 
 addressed is and what the nature of the solution is. If, after a brief,
 intelligible, high level discussion of the issue, details must be
 presented to back up the high level goals, that would be fine.

Comment on HASH-TABLE-TESTS (Version 2, 08-Dec-88)

 We would really like to see = hash tables, too.

Provision on IN-PACKAGE-FUNCTIONALITY (Version 4, 12-Dec-88)

 Our "Yes" vote is contingent on the DEFPACKAGE passing.

Provision on LISP-SYMBOL-REDEFINITION (Version 5, 22-Nov-88)

 We're reluctant to include the paragraph about permitting (DEFVAR CAR ...).
 Our vote is "Yes" only if the paragraph suggesting this is permissible
 is removed.

Comment on MAKE-PACKAGE-USE-DEFAULT (Version 2, 08-Oct-88)

 We oppose this issue because:
   - It is not clearly in the best interest of programmers in a supposedly
     portable language to give up the most convenient package creation
     syntax to a non-portable purpose.
   - The justifications given in the proposal are not strong enough to
     support an incompatible change like this.
   - This is a special-case hack that does not generalize. There is
     no way to create a package based on the implementation-dependent
     default -and- other packages.
   - It would be just as easy for someone to say 
       :USE (PACKAGE-USE-LIST (FIND-PACKAGE "USER"))
     At least this technique generalizes.
   - The Rationale uses incorrect suppositions to arrive at a false
     generalization. Cloe doesn't have the asymmetry referred to.
   - The current practice is not correct.
     No mention of what Cloe does is attempted.
   - Even allowing the default to be controlled by a variable does
     not help because it encourages programs to be developed depending
     on defaults which are not part of those programs, and therefore
     works against portability.
   - The Discussion section does not correctly reflect discussion.
     For example, Pitman has repeatedly voiced strong opposition.
     The Discussion mentions neither the fact that he objected nor the
     reasons for his objection.

Comment on NTH-VALUE (Version 4, 08-Dec-88)

 The proposal should clarify the treatment of n when it is out of range.
 Any non-negative integer index values should be permitted.
 NIL should result if the index argument is too large.

Comment on PACKAGE-CLUTTER (Version 6, 12-Dec-88)

 This leaves implementations freedom to hack any properties other than
 those in the LISP, KEYWORD, and USER packages.  In fact, though, the
 user should probably also have rights over the system in packages he
 creates.

 This will be an incompatible change -- possibly a major one -- for
 Genera, which uses properties named by keywords and by symbols in the
 LISP package. However, we think the change is worthwhile.

 In general, Genera tries not to distinguish "the system" from "the user".
 Anything the system is permitted to do, the user is permitted to do.
 As such, we feel a little odd about placing restrictions on the system
 which are not likewise placed on the user. In fact, if the system can
 cause problems in this way, the user can, too. This proposal is only 
 heuristic. We're voting "Yes" because it's probably a change for the
 better. But we won't be surprised if ultimately it is not seen to be
 the right way to achieve the high-level goal.

 LEXICAL, TYPE, INLINE, NOTINLINE, and FTYPE proclamations should be
 explicitly ruled out (just as SPECIAL is) except that TYPE is allowed
 if it's a CL variable, and FTYPE, INLINE, and NOTINLINE are allowed
 if it's a CL function.

 The DECLARATION proclamation probably be explicitly allowed (because 
 we see no reason not to permit it).

Comment on PEEK-CHAR-READ-CHAR-ECHO (Version 3, 08-Oct-88)

 There are some typos in this proposal that need to be corrected.
 Also, IIM asked for a clarification which seemed reasonable to us.

Comment on PROCLAIM-LEXICAL (Version 9, 08-Dec-88)

 The proposal might want to define the status of unproclaimed free variables.
 Presumably, we should say that they are an error, and we should encourage
 compilers to issue a warning.

Comment on SETF-FUNCTION-VS-MACRO (Version 3, 04-Nov-87)

 We think it's premature to vote on this issue at this time.
 We suggest that a better proposal, unifying this issue with SETF-PLACES,
 should be produced either before or during the upcoming meeting.

Comment on SETF-PLACES (Version 1, 11-Nov-88)

 We think it's premature to vote on this issue at this time.
 We suggest that a better proposal, unifying this issue with 
 SETF-FUNCTION-VS-MACRO, should be produced either before or during
 the upcoming meeting.
 
Provision on STEP-ENVIRONMENT (Version 3, 20-Jun-88)

 We don't understand
    "it is acceptable for an implementation to interactively step
     through only those parts of the evaluation that are interpreted."
 There are a variety of ways to clarify this that would satisfy us.
 Still, this must be clarified so we can know for sure what we're voting
 on and have some confidence that other implementors will interpret it
 in the same way as we have before we can vote "Yes".

Comment on STREAM-ACCESS (Version 2, 30-Nov-88)

 Although requiring types instead of predicates forces the implementation
 of these streams as separate types, there is no obvious serious problem
 which can result from that, and it leaves open the possibility of writing
 methods on particular types -- if they are also classes -- are they? The
 proposal should spell this out.

 Having both the types and the predicates is unnecessary clutter.
 Omitting the predicates makes for less overhead with no lost functionality.

Provision on STREAM-INFO (Version 6, 30-Nov-88)

 We vote "Yes" only if the name-changing amendment mentioned in the mail passes.
	
 Also, the writeup incorrectly states that Newline is not a standard character;
 Perhaps someone has confused "standard" with "graphic".

Comment on SUBTYPEP-TOO-VAGUE (Version 4, 07-Oct-88)

 Some minor worry about DECLARE-FUNCTION-AMBIGUITY here since the proposal
 mentions the list form of the FUNCTION declaration.

 This is a complicated issue and we have not had time to think it through
 as fully as we might like to have. Still, insofar as we have studied it,
 it looks ok.

Provision on TAGBODY-CONTENTS (Version 5, 09-Dec-88)

 The term "data element" is too vague in paragraph 2 of the proposal.
 Our "Yes" vote is contingent on correcting this.

 Moon doesn't really like allowing ignored frobs other than expressions
 and tags, but is willing to live with the current proposal.

 There several typos which should be fixed.

Comment on TAILP-NIL (Version 5, 09-Dec-88)

 The EQ -> EQL change at the last minute means this is not Genera current
 practice, contrary to the current practice section.

Provision on TEST-NOT-IF-NOT (Version 2, 05-Oct-88)

 We are mostly happy with either of these proposals, with slight 
 preference to FLUSH-ALL. However, our "Yes" vote is contingent on:

   - changing "remove" to "deprecate", and coming up with a
     suitable policy for deprecation which allows a comfortable
     transition from current practice.

   - either of the FUNCTION-COMPOSITION proposals passing.

Provision on TYPE-OF-UNDERCONSTRAINED (Version 3, 12-Dec-88)

 Our "Yes" vote is contingent on the following issues being addressed:

  - RANDOM-STATE should be added to the list of built-in types.

  - (subtypep (type-of x) (class-of x)) => T T for all x, seems to have
    been intended but is not actually said. It should be added.

  - The implementation recommendation in the discussion about returning
    only portable type specifiers should be discarded.

  - Shouldn't this refer to classes with proper names rather than just
    ones with names?

∂05-Jan-89  1113	CL-Cleanup-mailer 	Issue PATHNAME-PRINT-READ, v1  
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Jan 89  11:13:45 PST
Received: from JACKIE-O.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 159294; Thu 5-Jan-89 14:02:55 EST
Date: Thu, 5 Jan 89 14:03 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue PATHNAME-PRINT-READ, v1
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890104184739.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890105190305.1.MLY@JACKIE-O.AI.MIT.EDU>

I still don't understand why this needs to be standardised upon,
particularly since Common Lisp pathnames in general are so
subfunctional.  (Just what can portable programs do with the damn things
after they have successfully read them?)

Even if others do feel an urgent need to allow such portablability, I
don't understand why #S(PATHNAME ...) syntax isn't acceptable. (Perhaps
because Pitman hadn't `invented' it yet.)

One could go with #S(PATHNAME "host:namestring")
or #S(PATHNAME "host" "namestring"), which is perhaps the best choice,
or #S(PATHNAME :host "host" :directory '("foo" "bar") :name "baz")
or whatever.

Usurping #P makes it harder for users to find an unused reader macro
character.

∂05-Jan-89  1208	CL-Cleanup-mailer 	Issue PATHNAME-PRINT-READ, v1  
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Jan 89  11:13:45 PST
Received: from JACKIE-O.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 159294; Thu 5-Jan-89 14:02:55 EST
Date: Thu, 5 Jan 89 14:03 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue PATHNAME-PRINT-READ, v1
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890104184739.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890105190305.1.MLY@JACKIE-O.AI.MIT.EDU>

I still don't understand why this needs to be standardised upon,
particularly since Common Lisp pathnames in general are so
subfunctional.  (Just what can portable programs do with the damn things
after they have successfully read them?)

Even if others do feel an urgent need to allow such portablability, I
don't understand why #S(PATHNAME ...) syntax isn't acceptable. (Perhaps
because Pitman hadn't `invented' it yet.)

One could go with #S(PATHNAME "host:namestring")
or #S(PATHNAME "host" "namestring"), which is perhaps the best choice,
or #S(PATHNAME :host "host" :directory '("foo" "bar") :name "baz")
or whatever.

Usurping #P makes it harder for users to find an unused reader macro
character.

∂05-Jan-89  1208	CL-Cleanup-mailer 	Symbolics response to mail ballot   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Jan 89  11:12:39 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 515914; Thu 5-Jan-89 14:11:27 EST
Date: Thu, 5 Jan 89 14:10 EST
From: Moon@STONY-BROOK.SCRC.Symbolics.COM,
      KMP@STONY-BROOK.SCRC.Symbolics.COM
Sender: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Symbolics response to mail ballot
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890105141057.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

These votes represent the official position of Symbolics.

Because of the volatility of some issues from version to version,
readers are reminded that our votes apply only to the indicated
versions of the writeup.

In the notes column, "comment" means we have comments which do
not necessarily affect our vote, but which we felt important
to mention. On the other hand, "provisional" means that
we have placed conditions on the indicated vote, and the vote does
not apply unless the conditions are met. Comments and provisions
follow at the end of this message.

Blank lines in the summary are just for readability. They don't
indicate any kind of grouping.

---Summary---

Issue:Proposal(Version)                                      Vote  Notes

ARGUMENTS-UNDERSPECIFIED:SPECIFY(4)                          Yes   ---
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING(9)         Yes   comment
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY(5)                    Yes   ---
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE(1)             Yes   ---
DECLARATION-SCOPE:LIMITED-HOISTING(4)                        Yes   ---

DECLARATION-SCOPE:NO-HOISTING(4)                             No    ---
DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION (4)     Yes   comment
DECLARE-TYPE-FREE:ALLOW(8)                                   No    comment
DECLARE-TYPE-FREE:LEXICAL(9, unreleased)                     Yes   comment
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE(2)                Yes   ---

DEFPACKAGE:ADDITION(7)					     Yes   comment
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY(2)               Yes   comment
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES(3)                  Yes   ---
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR(4)         Yes   ---
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE(4)                     Yes   ---

DESCRIBE-INTERACTIVE:NO(4)                                   No    comment
DOTTED-MACRO-FORMS:ALLOW(3)				     Yes   ---
EQUAL-STRUCTURE:STATUS-QUO(5)				     No    comment
EXIT-EXTENT:MINIMAL(5)					     No    comment
EXIT-EXTENT:MEDIUM(5)					     No    comment

EXPT-RATIO:P.211(3)					     Yes   ---
FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION(4)		     Yes   ---
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM(4)	     No    ---
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN(2)			     Yes   ---
FORMAT-PRETTY-PRINT:YES(7)				     Yes   comment

FUNCTION-COMPOSITION:NEW-FUNCTIONS(4)			     Yes   comment
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS(4)		     No    comment
FUNCTION-DEFINITION:FUNCTION-SOURCE(2)			     Yes   ---
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE(3)	     Yes   ---
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE(5)  Yes   comment

GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD(2)		     Yes   comment
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER(7)	     Yes   comment
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS(1)	     No    comment
HASH-TABLE-TESTS:ADD-EQUALP(2)				     Yes   comment
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY(4)			     Yes   provisional

LAMBDA-FORM:NEW-MACRO(4)				     Yes   ---
LCM-NO-ARGUMENTS:1(1)					     Yes   ---
LISP-SYMBOL-REDEFINITION:DISALLOW(5)			     Yes   provisional
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT(2)	     No    comment
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE(2)	     Yes   ---

NTH-VALUE:ADD(4)					     Yes   comment
PACKAGE-CLUTTER:REDUCE(6)				     Yes   comment
PACKAGE-DELETION:NEW-FUNCTION(5)			     Yes   ---
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN(1)			     Yes   ---
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR(3)		     Yes   comment

PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK(3)		     Yes   ---
PROCLAIM-LEXICAL:LG(9)					     Yes   comment
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER(3)		     Yes   ---
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL(1) Yes   ---
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE(6)			     Yes   ---

REST-LIST-ALLOCATION:MAY-SHARE(3)			     Yes   ---
REST-LIST-ALLOCATION:NEWLY-ALLOCATED(3)			     No    ---
REST-LIST-ALLOCATION:MUST-SHARE(3)			     No    ---
RETURN-VALUES-UNSPECIFIED:SPECIFY(6)			     Yes   ---
ROOM-DEFAULT-ARGUMENT:NEW-VALUE(1)			     Yes   ---

SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS(3)		     No    comment
SETF-PLACES:ADD-SETF-FUNCTIONS(1)			     No    comment
SETF-SUB-METHODS:DELAYED-ACCESS-STORES(5)		     Yes   ---
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS(8)	     Yes   ---
STEP-ENVIRONMENT:CURRENT(3)				     Yes   provisional

STREAM-ACCESS:ADD-TYPES-ACCESSORS(2)			     Yes   comment
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS(2)		     No    comment
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS(2)		     No    comment
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS			     Yes   provisional
SUBTYPEP-TOO-VAGUE:CLARIFY(4)				     Yes   comment

SYMBOL-MACROLET-DECLARE:ALLOW(2)			     Yes   ---
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM(5)		     Yes   ---
TAGBODY-CONTENTS:FORBID-EXTENSION(5)			     Yes   provisional
TAILP-NIL:T(5)						     Yes   comment
TEST-NOT-IF-NOT:FLUSH-ALL(3)				     Yes   provisional

TEST-NOT-IF-NOT:FLUSH-TEST-NOT(3)			     Yes   provisional
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS(3)		     Yes   provisional
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW(2)		     Yes   ---
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE(3)			     Yes   ---

---Detail---

Comment on ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9, 31-Oct-88)
  
 We don't think the functions UPGRADED-ARRAY-ELEMENT-TYPE and
 UPGRADED-COMPLEX-PART-TYPE are really necessary, but neither of us
 cares enough to pursue that issue. Otherwise it looks ok.

Comment on DECLARE-FUNCTION-AMBIGUITY (Version 4, 05-Dec-88)

 Moon is mildly opposed to this proposal, DELETE-FTYPE-ABBREVIATION,
 because he sees it as gratuitously incompatible. Pitman favors the
 proposal because he thinks the benefit of making things regular will
 outweigh the costs.

Comment on DECLARE-TYPE-FREE (Version 8, 07-Dec-88)

 Moon approved of an earlier version of this proposal, and wrote 
 a new option, LEXICAL, as part of a version 9 which has not been
 released to X3J13. Both Moon and Pitman support the LEXICAL proposal,
 version 9.

Comment on DEFPACKAGE (Version 7, 02-Nov-88)

 The semantics should be defined in terms of the existing package
 functions rather than being redundantly described, in order to minimize
 the risk that DEFPACKAGE and the package functions will accidentally
 differ in some unintended way.

Comment on DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2, 21-Sep-88)

 The proposal should accomodate comments by IIM about some keywords
 that were (presumably accidentally) not addressed 

Comment on DESCRIBE-INTERACTIVE (Version 4, 15-Nov-88)

 We prefer option EXPLICITLY-VAGUE.
 We would vote "Yes" for the NO option iff EXPLICITLY-VAGUE fails.

Comment on EQUAL-STRUCTURE (Version 5, 01-Oct-88)

 There are important technical comments about EQUALP which have not
 been addressed, and which we feel must be addressed before this is
 brought to a serious vote. Ultimately, when those pending technical
 comments have been addressed, we expect to buy into this proposal.

Comment on EXIT-EXTENT (Version 5, 12-Dec-88)

 Sadly, we feel it is still premature to vote on this issue at this time.
 There are too many errors and inconsistencies in the writeup.

Comment on FORMAT-PRETTY-PRINT (Version 7, 15-Dec-88)

 Although some fixes were made to accomodate ~R, some minor lingering
 questions remain, which should be addressed under separate cover:
   - Is PRINT-OBJECT used to print things of type FLOAT in any cases
     where ~$, ~E, ~F, or ~G is used?
   - Can users write any methods (including :AROUND, :BEFORE, etc) for
     PRINT-OBJECT on type FLOAT?
 If the answers to both of these questions end up being "Yes", then it
 matters whether any of those format ops bind *PRINT-BASE* in order to
 achieve the effect prescribed by CLtL of always printing floats in 
 base 10. If the answer to either of those questions is "No", then
 it doesn't matter.

Comment on FUNCTION-COMPOSITION (Version 4, 12-Dec-88)

 Barry Margolin's complaint about the degenerate case of COMPOSE should be
 fixed in both proposals.

 We prefer option NEW-FUNCTIONS.
 We would vote "Yes" for COMPLEMENT-AND-ALWAYS iff NEW-FUNCTIONS fails.

Comment on FUNCTION-TYPE-REST-LIST-ELEMENT (Version 5, 14-Nov-88)
 
 It turns out the list type specifier being contemplated wouldn't have
 helped the case of alternating keyword value pairs because `repetitions'
 were not among the issues being addressed by those working on that topic.

Comment on GET-MACRO-CHARACTER-READTABLE (Version 2, 8-Dec-88)

 The proposal is ok, but the test case is wrong and should definitely be
 fixed before a vote is called. EQness of successive results from 
 GET-MACRO-CHARACTER when given the same arguments is not guaranteed
 currently, and the new proposal does not suggest causing such a thing.

Comment on HASH-TABLE-PACKAGE-GENERATORS (Version 7, 08-Dec-88)

 The test-package-iterator example has the values from the generator in
 the wrong order. This should be fixed before the actual vote.

Comment on HASH-TABLE-STABILITY (Version 1, 11-Nov-88)

 We believe that it is not appropriate to vote on this issue at this
 time. Neither of us had the patience to figure out in enough detail
 what it was saying to have any confidence in our opinions on the issue.
 If there is really something important going on here, it should be
 possible to say briefly and in plain English what the problem being 
 addressed is and what the nature of the solution is. If, after a brief,
 intelligible, high level discussion of the issue, details must be
 presented to back up the high level goals, that would be fine.

Comment on HASH-TABLE-TESTS (Version 2, 08-Dec-88)

 We would really like to see = hash tables, too.

Provision on IN-PACKAGE-FUNCTIONALITY (Version 4, 12-Dec-88)

 Our "Yes" vote is contingent on the DEFPACKAGE passing.

Provision on LISP-SYMBOL-REDEFINITION (Version 5, 22-Nov-88)

 We're reluctant to include the paragraph about permitting (DEFVAR CAR ...).
 Our vote is "Yes" only if the paragraph suggesting this is permissible
 is removed.

Comment on MAKE-PACKAGE-USE-DEFAULT (Version 2, 08-Oct-88)

 We oppose this issue because:
   - It is not clearly in the best interest of programmers in a supposedly
     portable language to give up the most convenient package creation
     syntax to a non-portable purpose.
   - The justifications given in the proposal are not strong enough to
     support an incompatible change like this.
   - This is a special-case hack that does not generalize. There is
     no way to create a package based on the implementation-dependent
     default -and- other packages.
   - It would be just as easy for someone to say 
       :USE (PACKAGE-USE-LIST (FIND-PACKAGE "USER"))
     At least this technique generalizes.
   - The Rationale uses incorrect suppositions to arrive at a false
     generalization. Cloe doesn't have the asymmetry referred to.
   - The current practice is not correct.
     No mention of what Cloe does is attempted.
   - Even allowing the default to be controlled by a variable does
     not help because it encourages programs to be developed depending
     on defaults which are not part of those programs, and therefore
     works against portability.
   - The Discussion section does not correctly reflect discussion.
     For example, Pitman has repeatedly voiced strong opposition.
     The Discussion mentions neither the fact that he objected nor the
     reasons for his objection.

Comment on NTH-VALUE (Version 4, 08-Dec-88)

 The proposal should clarify the treatment of n when it is out of range.
 Any non-negative integer index values should be permitted.
 NIL should result if the index argument is too large.

Comment on PACKAGE-CLUTTER (Version 6, 12-Dec-88)

 This leaves implementations freedom to hack any properties other than
 those in the LISP, KEYWORD, and USER packages.  In fact, though, the
 user should probably also have rights over the system in packages he
 creates.

 This will be an incompatible change -- possibly a major one -- for
 Genera, which uses properties named by keywords and by symbols in the
 LISP package. However, we think the change is worthwhile.

 In general, Genera tries not to distinguish "the system" from "the user".
 Anything the system is permitted to do, the user is permitted to do.
 As such, we feel a little odd about placing restrictions on the system
 which are not likewise placed on the user. In fact, if the system can
 cause problems in this way, the user can, too. This proposal is only 
 heuristic. We're voting "Yes" because it's probably a change for the
 better. But we won't be surprised if ultimately it is not seen to be
 the right way to achieve the high-level goal.

 LEXICAL, TYPE, INLINE, NOTINLINE, and FTYPE proclamations should be
 explicitly ruled out (just as SPECIAL is) except that TYPE is allowed
 if it's a CL variable, and FTYPE, INLINE, and NOTINLINE are allowed
 if it's a CL function.

 The DECLARATION proclamation probably be explicitly allowed (because 
 we see no reason not to permit it).

Comment on PEEK-CHAR-READ-CHAR-ECHO (Version 3, 08-Oct-88)

 There are some typos in this proposal that need to be corrected.
 Also, IIM asked for a clarification which seemed reasonable to us.

Comment on PROCLAIM-LEXICAL (Version 9, 08-Dec-88)

 The proposal might want to define the status of unproclaimed free variables.
 Presumably, we should say that they are an error, and we should encourage
 compilers to issue a warning.

Comment on SETF-FUNCTION-VS-MACRO (Version 3, 04-Nov-87)

 We think it's premature to vote on this issue at this time.
 We suggest that a better proposal, unifying this issue with SETF-PLACES,
 should be produced either before or during the upcoming meeting.

Comment on SETF-PLACES (Version 1, 11-Nov-88)

 We think it's premature to vote on this issue at this time.
 We suggest that a better proposal, unifying this issue with 
 SETF-FUNCTION-VS-MACRO, should be produced either before or during
 the upcoming meeting.
 
Provision on STEP-ENVIRONMENT (Version 3, 20-Jun-88)

 We don't understand
    "it is acceptable for an implementation to interactively step
     through only those parts of the evaluation that are interpreted."
 There are a variety of ways to clarify this that would satisfy us.
 Still, this must be clarified so we can know for sure what we're voting
 on and have some confidence that other implementors will interpret it
 in the same way as we have before we can vote "Yes".

Comment on STREAM-ACCESS (Version 2, 30-Nov-88)

 Although requiring types instead of predicates forces the implementation
 of these streams as separate types, there is no obvious serious problem
 which can result from that, and it leaves open the possibility of writing
 methods on particular types -- if they are also classes -- are they? The
 proposal should spell this out.

 Having both the types and the predicates is unnecessary clutter.
 Omitting the predicates makes for less overhead with no lost functionality.

Provision on STREAM-INFO (Version 6, 30-Nov-88)

 We vote "Yes" only if the name-changing amendment mentioned in the mail passes.
	
 Also, the writeup incorrectly states that Newline is not a standard character;
 Perhaps someone has confused "standard" with "graphic".

Comment on SUBTYPEP-TOO-VAGUE (Version 4, 07-Oct-88)

 Some minor worry about DECLARE-FUNCTION-AMBIGUITY here since the proposal
 mentions the list form of the FUNCTION declaration.

 This is a complicated issue and we have not had time to think it through
 as fully as we might like to have. Still, insofar as we have studied it,
 it looks ok.

Provision on TAGBODY-CONTENTS (Version 5, 09-Dec-88)

 The term "data element" is too vague in paragraph 2 of the proposal.
 Our "Yes" vote is contingent on correcting this.

 Moon doesn't really like allowing ignored frobs other than expressions
 and tags, but is willing to live with the current proposal.

 There several typos which should be fixed.

Comment on TAILP-NIL (Version 5, 09-Dec-88)

 The EQ -> EQL change at the last minute means this is not Genera current
 practice, contrary to the current practice section.

Provision on TEST-NOT-IF-NOT (Version 2, 05-Oct-88)

 We are mostly happy with either of these proposals, with slight 
 preference to FLUSH-ALL. However, our "Yes" vote is contingent on:

   - changing "remove" to "deprecate", and coming up with a
     suitable policy for deprecation which allows a comfortable
     transition from current practice.

   - either of the FUNCTION-COMPOSITION proposals passing.

Provision on TYPE-OF-UNDERCONSTRAINED (Version 3, 12-Dec-88)

 Our "Yes" vote is contingent on the following issues being addressed:

  - RANDOM-STATE should be added to the list of built-in types.

  - (subtypep (type-of x) (class-of x)) => T T for all x, seems to have
    been intended but is not actually said. It should be added.

  - The implementation recommendation in the discussion about returning
    only portable type specifiers should be discarded.

  - Shouldn't this refer to classes with proper names rather than just
    ones with names?

∂05-Jan-89  1313	CL-Cleanup-mailer 	Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **     
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 5 Jan 89  13:12:53 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA10957; Thu, 5 Jan 89 16:10:05 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA15055; Thu, 5 Jan 89 16:10:06 EST
Message-Id: <8901052110.AA15055@mist.>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT ** 
In-Reply-To: Your message of 12 Dec 88 18:16:00 -0800.
             <881212-181649-5908@Xerox> 
Date: Thu, 05 Jan 89 16:10:03 EST
From: Dan L. Pierson <pierson@mist.encore.com>

This is the official position of Encore Computer Corporation.

Y   ARGUMENTS-UNDERSPECIFIED:SPECIFY
    	Version 4, 21-Sep-88, Mailed 4 Dec 88
    
Y   ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
    	Version 9, 31-Oct-88, Mailed 5 Dec 88
    
Y   CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
    	Version 5,  5-Dec-88, Mailed 5 Dec 88
    
Y   CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
    	Version 1, 14-Sep-88, Mailed 6 Oct 88
    
Y   DECLARATION-SCOPE:NO-HOISTING
I   DECLARATION-SCOPE:LIMITED-HOISTING
    	Version 4, 15-Nov-88, Mailed 9-Dec-88
I support LIMITED-HOISTING if NO-HOISTING fails.  Either is better than
nothing.

Y   DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
    	Version 4,  5-Dec-88, Mailed  5-Dec-88
    
    DECLARE-TYPE-FREE:ALLOW
N   	Version 8, 7-Dec-88, Mailed 9-Dec-88
Y       Version 9, DECLARE-TYPE-FREE:ALLOW
N       Version 9, DECLARE-TYPE-FREE:LEXICAL
    
Y   DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
    	Version 2, 30-Sep-88, Mailed 6 Oct 88
    
Y   DEFPACKAGE:ADDITION
    	Version 7, 2-Nov-88, Mailed 5 Dec 88
    
Y   DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
    	Version 2, 21-Sep-88, Mailed 6 Oct 88
    
Y   DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
    	Version 3, 7 Dec 88, Mailed 12-Dec-88
    
Y   DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
    	Version 4, 31-Oct-88, Mailed 12-Dec-88
    
N   DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
Y   DESCRIBE-INTERACTIVE:NO
    	Version 4, 15-Nov-88	, Mailed 7-Dec-88
    
Y   DOTTED-MACRO-FORMS:ALLOW
    	Version 3, 15-Nov-88, Mailed 7-Dec-88
    
Y   EQUAL-STRUCTURE:STATUS-QUO
    	Version 5, 1-Oct-88, Mailed 8 Oct 88
    
    
C   EXIT-EXTENT:MINIMAL
C   EXIT-EXTENT:MEDIUM
    	Version 5, 12-Dec-88, Mailed 12-Dec-88
There seems to be serious disagreement whether MEDIUM is implementable
as well as some serious dissatisfaction with MINIMAL.  I oppose a vote
on this issue until it has either been reduced to a single proposal or
it has been reformed as two proposals that both sides agree are realistic
and implementable.
    
Y   EXPT-RATIO:P.211
    	Version 3, 31-Oct-88, Mailed 7 Dec 88
    
Y   FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
A   FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
    	Version 4, 7-Dec-88, Mailed 12-Dec-88
I think that tightening the definition of FIXNUM is a good thing, but don't
really care whether or not BIGNUM is tossed.
    
Y   FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
    	Version 2, 2 Oct 88, Mailed 6 Oct 88
    
Y   FORMAT-PRETTY-PRINT:YES
    	Version 7, 15 Dec 88, Mailed 7 Dec 88
    
A   FUNCTION-COMPOSITION:NEW-FUNCTIONS
Y   FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
    	Version 4, 12 Dec 88, Mailed 12 Dec 88
    
Y   FUNCTION-DEFINITION:FUNCTION-SOURCE
    	Version 2, 09-Dec-88	, Mailed 9 Dec 88
    
Y   FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
    	Version 3, 7-Dec-88, Mailed  12-Dec-88
    
Y   FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
    	Version 5, 14-Nov-88	, Mailed 8-Dec-88
    
Y   GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
    	Version 2, 8 Dec 88, Mailed 8 Dec 88
    
Y   HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
    	Version 7, 8-Dec-88, Mailed 9-Dec-88
    
A   HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
    	Version 1, 11-Nov-88	, Mailed 12 Dec 88
The explanation seems reasonable and useful, but I'm agnostic about whether
it belongs in the standard.
    
Y   HASH-TABLE-TESTS:ADD-EQUALP
    	Version 2, 8-Dec-88, Mailed 8 Dec 88
    
Y   IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
    	Version 4, 12-Dec-88, Mailed 12-Dec-88
    
A   LAMBDA-FORM:NEW-MACRO
    	Version 4, 22-Nov-88, Mailed 8-Dec-88
Undecided would be better than abstain here, but that's not an option.
    
Y   LCM-NO-ARGUMENTS:1
    	Version 1, 17 Oct 88, Mailed 8 Dec 88
    
Y   LISP-SYMBOL-REDEFINITION:DISALLOW
    	Version 5, 22-Nov-88, Mailed 8 Dec 88
    
Y   MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
    	Version 2, 8 Oct 88, Mailed 12-Dec-88
    
Y   MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
    	Version 2, 09-Jun-88, Mailed 8 Oct 88
    
Y   NTH-VALUE:ADD
    	Version 4, 8-Dec-88, Mailed 8 Dec 88
    
Y   PACKAGE-CLUTTER:REDUCE
    	Version 6, 12-Dec-88, Mailed 12-Dec-881
    
Y   PACKAGE-DELETION:NEW-FUNCTION
    	Version 5, 21 nov 88, Mailed 8 Dec 88
    
Y   PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
    	Version 1 27-Jun-88, Mailed 7 Oct 88
    
Y   PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
    	Version 3, 8-Oct-88, Mailed 8 Oct 88
    
Y   PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
    	Version 3, 20 Sep 88, Mailed 8 Oct 88
    
Y   PROCLAIM-LEXICAL:LG
    	Version 9, 8-Dec-88, Mailed 12-Dec-88
    
Y   RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
    	Version 3, 9-Oct-88, Mailed 14-Oct-88
    
Y   RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
    	Version 1, 14-Sep-88, Mailed 7 Oct 88
    
Y   REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
    	Version 6, 9 Dec 88, mailed 09 Dec 88
    
N   REST-LIST-ALLOCATION:NEWLY-ALLOCATED
Y   REST-LIST-ALLOCATION:MAY-SHARE
N   REST-LIST-ALLOCATION:MUST-SHARE
    	Version 3, 12-Dec-88, mailed 12-Dec-88
    
Y   RETURN-VALUES-UNSPECIFIED:SPECIFY
    	Version 6,  9 Dec 88 mailed  9-Dec-88
    
Y   ROOM-DEFAULT-ARGUMENT:NEW-VALUE
    	Version 1 12-Sep-88 mailed 8 Oct 88
    
    [The following are mutually exclusive]
Y   SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
    	Version 3, 4-Nov-87, mailed Nov 87
I   SETF-PLACES:ADD-SETF-FUNCTIONS
    	Version 1, 11-Nov-88, mailed 9-Dec-88
I support SETF-PLACES:ADD-SETF-FUNCTIONS if the first proposal
doesn't pass; it's ugly, but CLOS needs some resolution of this.
    
Y   SETF-SUB-METHODS:DELAYED-ACCESS-STORES
    	Version 5, 12-Feb-88 mailed 8 Oct 88
    
Y   STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
    	Version 8, 8 Jul 88, Mailed 7 Oct 88
    
Y   STEP-ENVIRONMENT:CURRENT
    	Version 3, 20-Jun-88, mailed  7 Oct 88
    
Y   STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
    	version 2, 30-Nov-88 mailed  9 Dec 88
    	(expect amendment T => "true")
    
Y   STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
    	Version 6, 30-Nov-88, mailed 9 dec 88
    	expect amendment:
    		LINE-WIDTH   ==> STREAM-LINE-WIDTH
    		LINE-POSITION ==> STREAM-LINE-POSITION
    		PRINTED-WIDTH ==> STREAM-STRING-WIDTH
    
    
Y   SUBTYPEP-TOO-VAGUE:CLARIFY
    	Version 4,  7-Oct-88, mailed 7 Oct 88 
    
Y   SYMBOL-MACROLET-DECLARE:ALLOW
    	Version 2,  9-Dec-88, mailed 9 Dec 88
    
Y   SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
    	Version 5, 30-Nov-88, mailed 9 Dec 88
    
Y   TAGBODY-CONTENTS:FORBID-EXTENSION
    	Version 5, 9-Dec-88 mailed 9 Dec 88
    
Y   TAILP-NIL:T
    	Version 5, 9-Dec-88, mailed 12-Dec-88
    
A   TEST-NOT-IF-NOT:FLUSH-ALL
A   TEST-NOT-IF-NOT:FLUSH-TEST-NOT
    	Version 3, 1 Dec 88 mailed 9 dec 
Cleaning up the sequence functions just isn't important enough to
justify incompatible changes at this time.  With any luck new portable
series/iteration constructs will obsolete most of them instead.  On
the other hand, I'd like to see them gone enough that I can't bring
myself to oppose the proposals either.
    
Y   TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
    	Version 3, 12-Dec-88, mailed 12 Dec 88
    	(some "bugs" in the proposal)
    
Y   UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
    	Version 2, 2-Dec-88, mailed 12-Dec-88
    
Y   VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
    	Version 3, 08-Oct-88, mailed 9 Dec 88

∂05-Jan-89  1539	CL-Cleanup-mailer 	Issue: REST-LIST-ALLOCATION (Version 3)  
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Jan 89  15:39:31 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA12186@EDDIE.MIT.EDU>; Thu, 5 Jan 89 18:38:12 EST
Received: by spt.entity.com (smail2.5); 5 Jan 89 18:06:05 EST (Thu)
To: cl-cleanup@sail.stanford.edu
Subject: Issue: REST-LIST-ALLOCATION (Version 3)
Message-Id: <8901051806.AA14403@spt.entity.com>
Date: 5 Jan 89 18:06:05 EST (Thu)
From: gz@spt.entity.com (Gail Zacharias)

I would be (a little) more comfortable with MAY-SHARE if it explicitly stated
that the &rest argument is guaranteed to be a proper list.  I know this is not
directly related to rest list sharing, but in practical terms I'm
concerned about the following situation:

	(defun debugged-function (&rest args)
	   (declare (optimize (safety 0)))
	   ... (cadr args) ...)

	(apply #'debugged-function '(a . 17))

The error should be detected before debugged-function is called (or
put another way, whether this error is detected or not should be determined
by optimize settings in effect around apply, not in debugged-function).

∂05-Jan-89  1806	CL-Cleanup-mailer 	Ballot
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 5 Jan 89  18:05:54 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA10715; Thu, 5 Jan 89 18:07:44 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA08627; Thu, 5 Jan 89 18:04:25 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA08229; Thu, 5 Jan 89 18:05:29 PST
Date: Thu, 5 Jan 89 18:05:29 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901060205.AA08229@clam.sun.com>
To: cl-cleanup@sail.stanford.edu
Subject: Ballot

This is the official ballot for Sun Microsystems.  I very much hope
that issues receiving significant opposition will be split out
from the block vote even if there is not a majority against.

Vote    | Proposal
--------------------------------------------------------------------
Y	| ARGUMENTS-UNDERSPECIFIED:SPECIFY
	| 
Y	| ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
	| 
Y	| CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
	| 
Y	| CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
	| 
	| DECLARATION-SCOPE:NO-HOISTING
If cases hoisted by 2nd alternatives are treated as errors and
limited-hoisting fails.
Y	| DECLARATION-SCOPE:LIMITED-HOISTING
	| 
Y	| DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
	| 
Y	| DECLARE-TYPE-FREE:ALLOW
	| 
Y	| DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
	| 
	| DEFPACKAGE:ADDITION
If we allow time for more experimental usage of this before adopting it.

	| DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
If the proposal is fixed as suggested by Kim Barrett.

Y	| DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
	| 
Y	| DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
	| 
N	| DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
Y	| DESCRIBE-INTERACTIVE:NO
	| 
Y	| DOTTED-MACRO-FORMS:ALLOW
	| 
Y	| EQUAL-STRUCTURE:STATUS-QUO
	| 
N	| EXIT-EXTENT:MINIMAL
Y	| EXIT-EXTENT:MEDIUM
	| 
Y	| EXPT-RATIO:P.211
	| 
N	| FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
This doesn't really do much for anyone and I believe it will break
some implementations.  For portability use subranges of integer rather
than FIXNUM in declarations.
N	| FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
	| 
Y	| FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
	| 
Y	| FORMAT-PRETTY-PRINT:YES
	| 
N	| FUNCTION-COMPOSITION:NEW-FUNCTIONS
	| FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
If a name better than "ALWAYS" can be found, or if only COMPLEMENT
were in the proposal.

Y	| FUNCTION-DEFINITION:FUNCTION-SOURCE
	| 
Y	| FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
	| 
Y	| FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
	| 
Y	| GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
	| 
Y	| HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
	| 
N	| HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
The problem statement hasn't yet compelled me to favor this.

Y	| HASH-TABLE-TESTS:ADD-EQUALP
	| 
	| IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
If we allow time for more experimental use of DEFPACKAGE before
adopting this.

N	| LAMBDA-FORM:NEW-MACRO
Confusing to users.

Y	| LCM-NO-ARGUMENTS:1
	| 
N	| LISP-SYMBOL-REDEFINITION:DISALLOW
This appears to disallow too much.

N	| MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
	| 
Y	| MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
	|
Y	| NTH-VALUE:ADD
	| 
Y	| PACKAGE-CLUTTER:REDUCE
	| 
A	| PACKAGE-DELETION:NEW-FUNCTION
	| 
N	| PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
No Unix convention I know of requires this new concept.  Perhaps a
couple of good examples would convince me.

Y	| PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
	| 
Y	| PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
	| 
N	| PROCLAIM-LEXICAL:LG
I don't believe in the reality of a separate "dynamic" environment,
don't believe it makes sense to support rapid access to
Globals on stock hardware, and don't understand what Scheme practices
don't work in Common Lisp.  Perhaps I can be dissuaded about some or
all of these opinions.

Y	| RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
	| 
Y	| RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
	| 
N	| REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Deprecate instead.  Do not remove from the Lisp package.

N	| REST-LIST-ALLOCATION:NEWLY-ALLOCATED
Y	| REST-LIST-ALLOCATION:MAY-SHARE
N	| REST-LIST-ALLOCATION:MUST-SHARE
	| 
Y	| RETURN-VALUES-UNSPECIFIED:SPECIFY
	| 
N	| ROOM-DEFAULT-ARGUMENT:NEW-VALUE
	| 
	| SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
If SETF-PLACES:ADD-SETF-FUNCTIONS is deemed unsatisfactory by X3J13.
Y	| SETF-PLACES:ADD-SETF-FUNCTIONS
	| 
N	| SETF-SUB-METHODS:DELAYED-ACCESS-STORES
This does not seem to be the "right" choice of semantics, and I
believe that the presentation of the proposal needs substantial work
even if it is "right".

Y	| STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
	| 
Y	| STEP-ENVIRONMENT:CURRENT
	| 
Y	| STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
	| 
Y	| STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
but the language needs some way of controlling whether this
information is to be collected or not, for the benefit of
implementations that support this.

Y	| SUBTYPEP-TOO-VAGUE:CLARIFY
	| 
Y	| SYMBOL-MACROLET-DECLARE:ALLOW
	| 
Y	| SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
	| 
Y	| TAGBODY-CONTENTS:FORBID-EXTENSION
	| 
A	| TAILP-NIL:T
	| 
N	| TEST-NOT-IF-NOT:FLUSH-ALL
Perhaps deprecate these instead.  They need to remain in the LISP
package.  The functionality of REMOVE-IF-NOT is needed, perhaps use
the name KEEP-IF.
Y	| TEST-NOT-IF-NOT:FLUSH-TEST-NOT
	| 
	| TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
If the language in paragraph (a) is made clear.  I can't tell which
"quantifiers" are intended or over what scope in the presentation.

Y	| UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
	| 
Y	| VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
	| 

∂05-Jan-89  2029	CL-Cleanup-mailer 	Issue PATHNAME-PRINT-READ, v1, and then some  
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 5 Jan 89  20:29:41 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 256497; Thu 5-Jan-89 23:26:48 EST
Date: Thu, 5 Jan 89 23:26 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue PATHNAME-PRINT-READ, v1, and then some
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, IIM@ECLA.USC.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890104184739.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890106042619.9.GSB@GANG-GANG.SCRC.Symbolics.COM>

    Date: Wed, 4 Jan 89 18:47 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    Yes, hosting is an issue that I deliberately glossed in the proposal.
    Let me say a few words about that and other issues that have been raised.

     - I think #P is better than #. for the same reasons that Touretzky
       proposed #H instead of relying on #. . That is, because most Lisp
       data can be understood by engines considerably less complex than
       Lisp itself. Lists, numbers, etc. are parseable and manipulable
       [are those really words? I say them a lot but they look funny 
       written down..] by simpler programs which do not contain EVAL.
       Using #. makes a large barrier to such programs in manipulating
       any data involving pathnames, which a priori should not be an
       opaque concept to non-Lisp programs.

    . . .

I would strongly prefer that a more generic approach be taken to
allocating reader syntax.

Previously #S has been suggested as the obvious place for extensions
such as this to occur.  In retrospect, I think that a slightly different
syntax should be reserved for extension by Common Lisp, in order that
any existing #S usage by particular implementations not conflict with
extensions dictated by CL.

e.g., if #T(typename ...) is reserved as the area of extension, then if
CL says that pathnames are read as #T(PATHNAME "namestring") there would
be no conflict for an implementation which happened to implement the
readableness of pathnames through the #S syntax already.  Such an
implementation should print a pathname using #T(PATHNAME "namestring")
and read both its older #S(PATHNAME :name whatever ...) and the #T
syntax.

No implementation would be permitted to extend this syntax, therefore
there would never be any conflict when it is extended by CL.

Doing this does not preclude eventual expansion of a user's ability to
define #S syntax (something I think should be done).  It DOES give CL a
place to expand read syntax into without using up all of the dispatch
characters, something which is beginning to look pretty likely.

∂06-Jan-89  0759	CL-Cleanup-mailer 	Re: Issue PATHNAME-PRINT-READ, v1, and then some   
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 6 Jan 89  07:58:59 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA16559; Fri, 6 Jan 89 10:55:42 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA15499; Fri, 6 Jan 89 10:55:44 EST
Message-Id: <8901061555.AA15499@mist.>
To: "Glenn S. Burke" <gsb@ALDERAAN.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue PATHNAME-PRINT-READ, v1, and then some 
In-Reply-To: Your message of Thu, 05 Jan 89 23:26:00 -0500.
             <19890106042619.9.GSB@GANG-GANG.SCRC.Symbolics.COM> 
Date: Fri, 06 Jan 89 10:55:41 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    I would strongly prefer that a more generic approach be taken to
    allocating reader syntax.
    
I agree.  We really need to split the possible read macro characters
not given a meaning in CLtL into three groups:

    1. Potential Common Lisp extensions.  Your idea of #T as the only
       hook here makes some sense.

    2. Potential implementation extensions.  I favor a small set of
       of characters here as well.

    3. Reserved for user extensions. 

This isn't as easy as it may seem.  One problem is what happens when a
popular user extension is incorporated in an implementation or even
standardized?  The read-macro issues in Dick Waters' new pretty
printer are a good example; he uses #" as a read macro in a
particularly elegant way -and- this in conflict with currect practice
in KCL, which uses #" for pathnames.

At the least we need to officially recognize this problem and set some
guidelines for oursevles.

∂06-Jan-89  0919	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 1)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Jan 89  09:19:22 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA28373@EDDIE.MIT.EDU>; Fri, 6 Jan 89 12:17:54 EST
Received: by spt.entity.com (smail2.5); 6 Jan 89 11:44:25 EST (Fri)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Mon, 2 Jan 89 16:26 EST <19890102212611.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 1)
Message-Id: <8901061144.AA16434@spt.entity.com>
Date: 6 Jan 89 11:44:25 EST (Fri)
From: gz@spt.entity.com (Gail Zacharias)

Defstruct needs a :LOAD-FUNCTION (or whatever) option, and a rule for how
you get the simple slot-recreation function.  I still think that it's going to
be awkward and confusing for this to default differently from :PRINT-FUNCTION
or :CONSTRUCTOR (both of which give you a default function if not specified),
but I guess nobody else does, so I won't press it...

I take it the form returned by MAKE-LOAD-FORM is walked again by the
file compiler, and it's the user's responsibility to avoid circularity
(as in (defmethod make-load-form ((x y)) `',x) or equivalent multi-level
examples).  If so, this should be stated.

It would be useful to make the simple slot-recreation function available as
part of the language.  Something like
   (slot-reconstruct-form x) -> (make-instance '<class-name> :a <a> ...)
so they can do
   (defmethod make-load-form ((x my-class)) (slot-reconstruct-form x))
The reason for this, aside from making things simpler for users doing
simple things, is that the obvious MAKE-LOAD-FORM doesn't work well with
inheritance.  That is, if a user writes
  (defclass person ()
     ((name :reader person-name)
      (age :reader person-age)))
  (defmethod make-load-form ((jrandom person))
     `(make-instance ',(class-name (class-of jrandom))
	            :name ',(person-name jrandom)
                    :age ',(person-age jrandom)))
as recommended by the examples, and then does
   (defclass astronaut (person)
      ((helmet-size :initarg 17)))
without specifing a make-load-form, then he's going to quietly lose dumping
astronauts in a very difficult to detect way.

∂06-Jan-89  1006	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 1) 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Jan 89  10:06:01 PST
Received: by ti.com id AA02485; Fri, 6 Jan 89 12:03:52 CST
Received: from Kelvin by tilde id AA01454; Fri, 6 Jan 89 11:52:41 CST
Message-Id: <2809101212-8623747@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 6 Jan 89  11:53:32 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: gz@spt.entity.com (Gail Zacharias)
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: LOAD-OBJECTS (Version 1)
In-Reply-To: Msg of 6 Jan 89 11:44:25 EST (Fri) from gz@spt.entity.com (Gail Zacharias)

> Defstruct needs a :LOAD-FUNCTION (or whatever) option, and a rule for how
> you get the simple slot-recreation function. 

Rather than adding more options to DEFSTRUCT, I'm more inclined to think
that the :PRINT-FUNCTION option is obsolete now that you can do
  (DEFMETHOD PRINT-OBJECT ...)

>   I still think that it's going to
> be awkward and confusing for this to default differently from :PRINT-FUNCTION
> or :CONSTRUCTOR (both of which give you a default function if not specified),

Maybe; on the Explorer, structures are already dumpable by treating them
like arrays, and I haven't noticed any problems caused by this.

∂06-Jan-89  1115	CL-Cleanup-mailer 	Issue FUNCTION-COMPOSITION
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  11:13:52 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA21890; Fri, 6 Jan 89 11:15:45 PST
Received: from clam.sun.com ([129.144.42.62]) by snail.Sun.COM (4.1/SMI-4.0)
	id AA25862; Fri, 6 Jan 89 11:01:49 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA08876; Fri, 6 Jan 89 11:01:14 PST
Date: Fri, 6 Jan 89 11:01:14 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901061901.AA08876@clam.sun.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue FUNCTION-COMPOSITION

In the letter ballot I objected to the name "ALWAYS".  I suggest
the name "CONSTANT-FN" as an alternative.

∂06-Jan-89  1438	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 1) 
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 6 Jan 89  14:38:35 PST
Received: from GROUSE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 256772; Fri 6-Jan-89 17:37:12 EST
Date: Fri, 6 Jan 89 17:36 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 1)
To: CL-Cleanup@Sail.Stanford.EDU
cc: DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM,
    Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <19890106223654.4.CASSELS@GROUSE.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
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):

  Add a standard type specifier
   (REAL low high)
  which means
   (OR (RATIONAL low high) (FLOAT low high))

  As with other such type specifiers, define that if the low and high
  are omitted, the atomic specifier REAL may be used.

  Clarify that NUMBER is equivalent to (OR REAL COMPLEX).

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:

  Occassional inconvenience and/or inefficiency.

Benefits:

  Mathematical clarity.

  Ability to define CLOS class by the same name for the purpose of
  method dispatch.

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.

∂06-Jan-89  1502	CL-Cleanup-mailer 	Re: Issue MACRO-FUNCTION-ENVIRONMENT, v1 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  15:00:19 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JAN 89 19:56:54 PST
Date: 5 Jan 89 19:56 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue MACRO-FUNCTION-ENVIRONMENT, v1
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Wed, 4 Jan 89
 13:59:03 PST
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890105-195654-180@Xerox>

I'm sorry, I should have caught this sooner. The following two issues were
passed at previous meetings (GET-SETF-METHOD-ENVIRONMENT and
MACRO-FUNCTION-ENVIRONMENT.)

Issue:          GET-SETF-METHOD-ENVIRONMENT
References:     GET-SETF-METHOD (CLtL p 187)
Category:       Change
Edit History:   Version 1 9-Jan-87, Version 1 by Masinter 
                (no version) 7-Apr-87, merged with ENVIRONMENT-ARGUMENTS
                Version 2 29-May-87, extracted again 
                Version 3  5-Jun-87, by Masinter
                Version 4  11-Jun-87, for release
                Version 5  13-Jul-87, by Masinter
                
Problem Description:

If a macro that performs similar processing to SETF uses GET-SETF-METHOD,
and that macro occurs within a MACROLET, the expansion will not see the
MACROLET definition, e.g.,

 (defmacro special-incf ... (get-setf-method ...) ...)

then  

 (macrolet ((test (x) `(car ,x)))
         (special-incf (test z)))

would not "see" the test definition.

Proposal (GET-SETF-METHOD-ENVIRONMENT:ADD-ARG):

Add an optional environment argument to GET-SETF-METHOD and
GET-SETF-METHOD-MULTIPLE-VALUE. If the argument is not supplied, it
defaults to the null lexical environment. NIL can also be passed explicitly
to denote the null lexical environment.

Allow &ENVIRONMENT variable to appear in the lambda-list subform of a
DEFINE-SETF-METHOD form, as with a DEFMACRO.

Note that macros defined with DEFINE-MODIFY-MACRO correctly pass the
environment to GET-SETF-METHOD.

Clarify that, within the scope of a MACROLET, FLET and LABELS, global SETF
definitions of the name defined by the MACROLET, FLET or LABELS do not
apply.  A SETF method applies only when the global function binding of the
name is lexically visible.  All of the built in macros of Common Lisp
(SETF, INCF, DECF, POP, ROTATEF, etc.) which modify location specifications
obey this convention.

Test Case:

;;; This macro is like POP 

(defmacro xpop (place &environment env)
  (multiple-value-bind (dummies vals new setter getter)
                       (get-setf-method place env)
     `(let* (,@(mapcar #'list dummies vals) (,(car new) ,getter))
        (prog1 (car ,(car new))
               (setq ,(car new) (cdr ,(car new)))
               ,setter)))))

(defsetf frob (x) (value) 
    `(setf (car ,x) ,value))

;;; The following will modify (cdr z) and not (car z)
(macrolet ((frob (x) `(cdr ,x)))
     (xpop (frob z)))

;;; The following is an error; an error may be signaled at macro expansion
time

(flet ((frob (x) (cdr x))
     (xpop (frob z)))


Rationale:

This was an omission in the original definition of CLtL.

Current Practice:

Many Common Lisp implementations already have this extension, although some
do not. One implementation has extended GET-SETF-METHOD to take an optional
argument which is incompatible with this use.

Cost to implementors:

Some implementations will have to add this feature, although it is not a
major change.

Cost to users:

This is generally an upward compatible change. In implementations which did
not already take into account the lexical environment for SETF'd forms
might start working differently if the internal implementation of SETF is
changed. The likelihood of this affecting a user's program is very small.

Benefits:

This change improves portability and the ability to use MACROLET, FLET and
LABELS in portable code which might also have SETF forms.

Aesthetics:

SETF methods cannot work correctly within lexically defined function
symbols without this change. This change makes the language more consistent
and correct. 

Discussion:

The cleanup committee generally supports this change.

A number of additional changes for rationally dealing with lexical
environments as first class objects, including a more general set of
accessors and constructors for lexical environments is required for many
language extensions (e.g., a portable version of the proposed Common Lisp
Object System) and should be addressed by a future proposal. For a while,
the cleanup committee attempted to deal with these issues together, but
decided to separate them out into their component parts. This issue is the
simplest.


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

Issue:         MACRO-FUNCTION-ENVIRONMENT

References:    MACRO-FUNCTION, p. 144
               MACROLET, pp. 113-4
               &ENVIRONMENT, pp. 145-6
               MACROEXPAND and MACROEXPAND-1, pp. 151-2

Category:      ADDITION

Edit history:  Version 1, Pavel, March 21, 1988
		   Version 2, Masinter,  8-Jun-88, (as per cleanup discussion)

Problem description:

The &ENVIRONMENT argument to a macro-expansion function may only be used as
the
second argument to the functions MACROEXPAND and MACROEXPAND-1.  It is
sometimes
more convenient, however, to be able to work directly with the more
primitive
function MACRO-FUNCTION, on which MACROEXPAND and MACROEXPAND-1 are
presumably
based.  However, since MACRO-FUNCTION does not take an environment
argument, it
cannot be used in situations in which that environment must be taken into
account.

Proposal (MACRO-FUNCTION-ENVIRONMENT:YES):

Add an optional second argument to MACRO-FUNCTION, that argument being an
environment that was passed as the &ENVIRONMENT argument to some macro
expansion
function.  If the argument is not given, or the argument is NIL, the null
environment is used.  MACRO-FUNCTION will now consider macro definitions
from
that environment in preference to ones in the global environment.  It is an
error
to supply the environment argument in a use of MACRO-FUNCTION as a SETF
location
specifier.

Examples:

(macrolet ((foo (&environment env)
              (if (macro-function 'bar env)
                 ''yes
                 ''no)))
   (list (foo)
         (macrolet ((bar () :beep))
            (foo))))

=> (no yes)

(setf (macro-function 'bar env) ...) is an error.

Rationale:

Intuitively, the more primitive operation in macro expansion is
MACRO-FUNCTION,
not MACROEXPAND or MACROEXPAND-1, yet the environment argument can only be
supplied to the latter functions and not to the former one.  By changing
this
state of affairs, the model of macro expansion becomes somewhat simpler.
Also,
more flexible use of the facility is enabled.

Current practice:

Xerox Common Lisp already implements this proposal.  Symbolics Common Lisp,
and Kyoto Common Lisp do not. Lucid Common Lisp did not, but version 3.0
does.

Cost to Implementors:

This is presumably a simple change to make, a small matter of moving the
environment-searching code from MACROEXPAND-1 to MACRO-FUNCTION.

Cost to Users:

The change is upward-compatible and so poses no cost to users.

Cost of non-adoption:

One more (small) semantic wart on the language.

Benefits:

The function that users think of as being more primitive really is.

Aesthetics:

This slightly cleans up the language.

Discussion:

This issue was discussed starting in January 1987, but got tangled in
a web of other related proposals. In its current form, the only objections
have been that some other proposal or committee might otherwise change
macro handling, or that this proposal doesn't fix enough of the problems.

  

∂06-Jan-89  1502	CL-Cleanup-mailer 	environment argument for SUBTYPEP   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  15:02:30 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 JAN 89 20:28:15 PST
Date: 5 Jan 89 20:27 PST
From: masinter.pa@Xerox.COM
Subject: environment argument for SUBTYPEP
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Mon, 2 Jan 89
 17:31:11 PST
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890105-202815-181@Xerox>

I'm temporarily blanking -- I can think of no way of making a local
declaration in such a way that SUBTYPEP might differ between local & global
context. So I can't think of a case where SUBTYPEP's results could
legitimately depend on an environment argument.


∂06-Jan-89  1503	CL-Cleanup-mailer 	Re: ballot 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  15:03:06 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 JAN 89 21:58:05 PST
Date: 5 Jan 89 21:57 PST
From: masinter.pa@Xerox.COM
Subject: Re: ballot
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
 Tue, 3 Jan 89 16:05:56 MST
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890105-215805-189@Xerox>

STREAM-ACCESS had three proposals, but I left all but the first off the ballot.

You marked Y on ADD-TYPES-PREDICATES-ACCESSORS. Is your vote N on the other two proposals?


STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
STREAM-ACCESS:ADD-TYPES-ACCESSORS
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
version 2, 30-Nov-88 mailed  9 Dec 88
Status: expect amendment T => "true"

∂06-Jan-89  1504	CL-Cleanup-mailer 	Issue: PACKAGE-CLUTTER (Version 6)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  15:04:25 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 JAN 89 23:58:51 PST
Date: 5 Jan 89 23:57 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: PACKAGE-CLUTTER (Version 6)
To: cl-cleanup@sail.stanford.edu
From: Moon@STONY-BROOK.SCRC.Symbolics.COM,
 KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890105-235851-193@Xerox>

[lmm: I've been folding short comments into my Issue status file, but this
one is too long.]

 This leaves implementations freedom to hack any properties other than
 those in the LISP, KEYWORD, and USER packages.  In fact, though, the
 user should probably also have rights over the system in packages he
 creates.

 This will be an incompatible change -- possibly a major one -- for
 Genera, which uses properties named by keywords and by symbols in the
 LISP package. However, we think the change is worthwhile.

 In general, Genera tries not to distinguish "the system" from "the user".
 Anything the system is permitted to do, the user is permitted to do.
 As such, we feel a little odd about placing restrictions on the system
 which are not likewise placed on the user. In fact, if the system can
 cause problems in this way, the user can, too. This proposal is only 
 heuristic. We're voting "Yes" because it's probably a change for the
 better. But we won't be surprised if ultimately it is not seen to be
 the right way to achieve the high-level goal.

 LEXICAL, TYPE, INLINE, NOTINLINE, and FTYPE proclamations should be
 explicitly ruled out (just as SPECIAL is) except that TYPE is allowed
 if it's a CL variable, and FTYPE, INLINE, and NOTINLINE are allowed
 if it's a CL function.

 The DECLARATION proclamation probably be explicitly allowed (because 
 we see no reason not to permit it).

∂06-Jan-89  1506	CL-Cleanup-mailer 	Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **     
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  15:04:45 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 10:50:22 PST
Date: 6 Jan 89 10:48 PST
From: masinter.pa@Xerox.COM
Subject: Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT ** 
In-reply-to: Dan L. Pierson <pierson@mist.encore.com>'s message of Thu, 05
 Jan 89 16:10:03 EST
To: Dan L. Pierson <pierson@mist.encore.com>
cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <890106-105022-239@Xerox>

The ballot incorrectly only listed one alternative of the three:

STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
STREAM-ACCESS:ADD-TYPES-ACCESSORS
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS


Do you prefer 

Y   STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS

?


∂06-Jan-89  1503	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  15:03:41 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 JAN 89 22:14:46 PST
Date: 5 Jan 89 22:14 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Tue, 3 Jan 89 15:24 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890105-221446-191@Xerox>

The example I keep coming back to is one where it isn't so much that the
local declaration is easy to enforce as it is where it is difficult *not*
to enforce it.

Suppose I have
(defun frob (delta)
 (flet ((more (x) (+ x delta)))
	;; if you like, put (declare (inline more)) here
   (typecase delta
	(float (locally (declare (type float delta))
		... (more rho ) ... )

       ((signed-byte 8)
		(locally (declare (type (signed-byte 8) delta))
		... (more zz) ... )

   ...)


Even without the inline, it is a common & legal transformation to do inline
substitution on "small" fletted functions. Even though the reference
"delta" in the definition of more isn't  within the lexical scope of the
local declaration, it *is* the same delta. While its not impossible to
maintain a separate contour in order to segregate the type declarations, it
seems like unnecessary work, and in fact, the declaration is quite useful
if "more" is inlined.



∂06-Jan-89  1504	CL-Cleanup-mailer 	Issue APPLYHOOK-ENVIRONMENT (not submitted)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  15:03:58 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 JAN 89 23:11:08 PST
Date: 5 Jan 89 23:10 PST
From: masinter.pa@Xerox.COM
Subject:  Issue APPLYHOOK-ENVIRONMENT (not submitted)
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Wed, 4 Jan 89
 13:59:03 PST
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890105-231108-192@Xerox>

I can't find any issue to remove the ENV argument from APPLYHOOK, although
I remember the discussion of it (I think on the common lisp mailing list.).

I'm reserving issue name APPLYHOOK-ENVIRONMENT.

∂06-Jan-89  1504	CL-Cleanup-mailer 	Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  15:04:14 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 05 JAN 89 23:55:12 PST
Date: 5 Jan 89 23:54 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (Version 2)
To: cl-cleanup@sail.stanford.edu
From: Moon@STONY-BROOK.SCRC.Symbolics.COM,
 KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890105-235512-193@Xerox>

[lmm: I've been folding short comments into my Issue status file, but this
one is too long.]

 We oppose this issue because:
   - It is not clearly in the best interest of programmers in a supposedly
     portable language to give up the most convenient package creation
     syntax to a non-portable purpose.
   - The justifications given in the proposal are not strong enough to
     support an incompatible change like this.
   - This is a special-case hack that does not generalize. There is
     no way to create a package based on the implementation-dependent
     default -and- other packages.
   - It would be just as easy for someone to say 
       :USE (PACKAGE-USE-LIST (FIND-PACKAGE "USER"))
     At least this technique generalizes.
   - The Rationale uses incorrect suppositions to arrive at a false
     generalization. Cloe doesn't have the asymmetry referred to.
   - The current practice is not correct.
     No mention of what Cloe does is attempted.
   - Even allowing the default to be controlled by a variable does
     not help because it encourages programs to be developed depending
     on defaults which are not part of those programs, and therefore
     works against portability.
   - The Discussion section does not correctly reflect discussion.
     For example, Pitman has repeatedly voiced strong opposition.
     The Discussion mentions neither the fact that he objected nor the
     reasons for his objection.



∂06-Jan-89  1504	CL-Cleanup-mailer 	Meeting in Hawaii    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  15:04:07 PST
Received: from Semillon.ms by ArpaGateway.ms ; 05 JAN 89 23:20:40 PST
Date: 5 Jan 89 23:20 PST
From: masinter.pa@Xerox.COM
Subject: Meeting in Hawaii
To: cl-cleanup@sail.stanford.edu
Message-ID: <890105-232040-193@Xerox>

OK:

Enough people can come Sunday that we'll meet Sunday afternoon to
decide/confirm what issues we will bring before the main X3J13 committee
for voting in plenary.


∂06-Jan-89  1526	CL-Cleanup-mailer 	Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **     
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 6 Jan 89  15:26:39 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA23600; Fri, 6 Jan 89 18:24:11 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA01261; Fri, 6 Jan 89 18:23:34 EST
Message-Id: <8901062323.AA01261@mist.>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT ** 
In-Reply-To: Your message of 06 Jan 89 10:48:00 -0800.
             <890106-105022-239@Xerox> 
Date: Fri, 06 Jan 89 18:23:32 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    The ballot incorrectly only listed one alternative of the three:
    
Oops, I noticed it, but forgot to put a note in my ballot.  This is
the correct Encore vote:

Y  STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
N  STREAM-ACCESS:ADD-TYPES-ACCESSORS
N  STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
    
I will consider voting for one of the alternatives if the combined one
looses, but haven't thought about which one I prefer.

∂06-Jan-89  1528	CL-Cleanup-mailer 	Re: Issue PATHNAME-PRINT-READ, v1   
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 6 Jan 89  15:28:21 PST
Received: from relay2.cs.net by RELAY.CS.NET id af06590; 6 Jan 89 9:05 EST
Received: from draper.com by RELAY.CS.NET id aa27590; 6 Jan 89 8:38 EST
Date: Fri, 6 Jan 89 07:56 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue PATHNAME-PRINT-READ, v1
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525

re: Richard Mlynarik's message about #S(PATHNAME ...)
 
Would this be legal?  Does it imply that PATHNAME is implemented as a
DEFSTRUCT?  Does the #S(PATHNAME "string" "another-string") syntax conflict
with #S(defstruct-structure :key value ...) syntax, or can it be analogous
to BOA-constructor structures?  Whatever the case, I think it's far less
good idea to compromise #S this way than to "use up" #P, which Lucid is
already using anyhow.

∂06-Jan-89  1557	CL-Cleanup-mailer 	Issue FUNCTION-COMPOSITION
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89  15:57:30 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516766; Fri 6-Jan-89 18:55:49 EST
Date: Fri, 6 Jan 89 18:55 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue FUNCTION-COMPOSITION
To: cperdue@Sun.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8901061901.AA08876@clam.sun.com>
Message-ID: <890106185519.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

I can't support any abbreviated name, and CONSTANT-FUNCTION is too long.
ALWAYS is at least current practice in an existing dialect.
However, if you really can't deal, how about CONSTANTLY.
 (MAPCAR (CONSTANTLY 7) '(A B C)) => (7 7 7)

∂06-Jan-89  1618	CL-Cleanup-mailer 	Re:  Issue FUNCTION-COMPOSITION
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  16:18:50 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA28487; Fri, 6 Jan 89 16:20:38 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA10478; Fri, 6 Jan 89 16:17:12 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA09453; Fri, 6 Jan 89 16:18:14 PST
Date: Fri, 6 Jan 89 16:18:14 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901070018.AA09453@clam.sun.com>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, cperdue@Sun.COM
Subject: Re:  Issue FUNCTION-COMPOSITION
Cc: CL-Cleanup@SAIL.Stanford.EDU

CONSTANTLY?  It's kind of catchy.  I dunno.  I just thought that
ALWAYS was confusing and we ought to be able to do better.

Sure, CONSTANTLY is OK with me.
				-Cris

∂06-Jan-89  2117	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, Version 1   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89  21:17:04 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516885; Sat 7-Jan-89 00:15:53 EST
Date: Sat, 7 Jan 89 00:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <12459458774.4.IIM@ECLA.USC.EDU>
Message-ID: <19890107051524.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon 2 Jan 89 17:31:11-PST
    From: Kim A. Barrett <IIM@ECLA.USC.EDU>

    Proposal (SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT)

     Extend SUBTYPEP to accept an optional third argument.  This argument should be
     either NIL, the &environment argument received by a macro expander function,
     or the environment argument received by an *evalhook* or *applyhook* function.
     This argument is used to distinguish between compile-time and run-time
     environments. 

I can't imagine why you would add an environment argument to SUBTYPEP,
but not to TYPEP.  In any case, the CLOS plan for this was that anyone who
needed to use a non-null environment would call FIND-CLASS explicitly,
instead of relying on the implicit class inside TYPEP and SUBTYPEP.
Since use of the compile-time environment for types should be quite rare,
this was seen as much less of a burden than modifying existing functions
to take new optional arguments.

∂06-Jan-89  2125	CL-Cleanup-mailer 	Re: Issue: LOAD-OBJECTS (Version 1) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89  21:25:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516898; Sat 7-Jan-89 00:23:23 EST
Date: Sat, 7 Jan 89 00:22 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 1)
To: David N Gray <Gray@DSG.csc.ti.com>, Gail Zacharias <gz@spt.entity.com>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <2809101212-8623747@Kelvin>
Message-ID: <19890107052254.8.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Fri, 6 Jan 89  11:53:32 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    > Defstruct needs a :LOAD-FUNCTION (or whatever) option, and a rule for how
    > you get the simple slot-recreation function. 

    Rather than adding more options to DEFSTRUCT, I'm more inclined to think
    that the :PRINT-FUNCTION option is obsolete now that you can do
      (DEFMETHOD PRINT-OBJECT ...)

I agree.  The old way using DEFSTRUCT options is so irregular and kludgy.

    >   I still think that it's going to
    > be awkward and confusing for this to default differently from :PRINT-FUNCTION
    > or :CONSTRUCTOR (both of which give you a default function if not specified),

    Maybe; on the Explorer, structures are already dumpable by treating them
    like arrays, and I haven't noticed any problems caused by this.

Since that's true in Symbolics Genera also, by reasoning from current practice
I could easily be convinced that the default method for STRUCTURE-OBJECT should
just save the structure name and slot values, rather than signalling an error.
That's fine for compatibility.  What I really care about is that the default
method for STANDARD-OBJECT must signal an error.

∂06-Jan-89  2127	CL-Cleanup-mailer 	Issue: LOAD-OBJECTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89  21:27:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 516901; Sat 7-Jan-89 00:26:41 EST
Date: Sat, 7 Jan 89 00:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 1)
To: Gail Zacharias <gz@spt.entity.com>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8901061144.AA16434@spt.entity.com>
Message-ID: <19890107052613.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: 6 Jan 89 11:44:25 EST (Fri)
    From: gz@spt.entity.com (Gail Zacharias)

    I take it the form returned by MAKE-LOAD-FORM is walked again by the
    file compiler, and it's the user's responsibility to avoid circularity
    (as in (defmethod make-load-form ((x y)) `',x) or equivalent multi-level
    examples).  If so, this should be stated.

I'm not sure what "walked" means, but it wouldn't be useful if the form
returned by MAKE-LOAD-FORM wasn't allowed to contain objects for which
MAKE-LOAD-FORM must be called.  Also you're right that if the user causes
infinite recursion the process won't terminate.  We shouldn't assume the
reader can figure these things out on his own, so I'll say something when
I edit the writeup.

    It would be useful to make the simple slot-recreation function available as
    part of the language.  Something like
       (slot-reconstruct-form x) -> (make-instance '<class-name> :a <a> ...)
    so they can do
       (defmethod make-load-form ((x my-class)) (slot-reconstruct-form x))
    The reason for this, aside from making things simpler for users doing
    simple things, is that the obvious MAKE-LOAD-FORM doesn't work well with
    inheritance.  That is, if a user writes
      (defclass person ()
	 ((name :reader person-name)
	  (age :reader person-age)))
      (defmethod make-load-form ((jrandom person))
	 `(make-instance ',(class-name (class-of jrandom))
			:name ',(person-name jrandom)
			:age ',(person-age jrandom)))
    as recommended by the examples, and then does
       (defclass astronaut (person)
	  ((helmet-size :initarg 17)))
    without specifing a make-load-form, then he's going to quietly lose dumping
    astronauts in a very difficult to detect way.

I was thinking that CLOS metaobjects made slot-reconstruct-form so easy
to write on one's own that there was no reason to build it in.  But perhaps
Gray's example shows that I was underestimating the complexity.

∂06-Jan-89  2246	CL-Cleanup-mailer 	Re: Ballot 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  22:45:27 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 11:32:34 PST
Date: 6 Jan 89 11:11 PST
From: masinter.pa@Xerox.COM
Subject: Re: Ballot
In-reply-to: cperdue@Sun.COM (Cris Perdue)'s message of Thu, 5 Jan 89
 18:05:29 PST
To: cperdue@Sun.COM (Cris Perdue)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890106-113234-250@Xerox>

The ballot incorrectly listed only one of three alternatives:

STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
STREAM-ACCESS:ADD-TYPES-ACCESSORS
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS

Do you prefer the marked 

Y	| STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS

?

∂06-Jan-89  2247	CL-Cleanup-mailer 	Issue: COMPILE-AND-LOAD-VERBOSITY????    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  22:46:14 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 16:33:37 PST
Date: 6 Jan 89 16:33 PST
From: masinter.pa@Xerox.COM
Subject: Issue: COMPILE-AND-LOAD-VERBOSITY????
To: cl-cleanup@sail.stanford.edu
Message-ID: <890106-163337-1447@Xerox>

I have this issue name down but no record of the discussion. 
Synopsis: Need to clarify how much typeout is done when :VERBOSE is
specified to :COMPILE and :LOAD


Did I lose it? Is this really necessary?


∂06-Jan-89  2248	CL-Cleanup-mailer 	*DRAFT* issue status 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  22:46:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 16:39:22 PST
Date: 6 Jan 89 16:38 PST
From: masinter.pa@Xerox.COM
Subject: *DRAFT* issue status
To: cl-cleanup@sail.stanford.edu
Message-ID: <890106-163922-1463@Xerox>

I sorted out the 7 ballots we've gotten so far, and tried to put together a
merged "status" list. I'm going thru my issue files once more
alphabetically, trying to get final or draft versions of things we want to
take with us -- not too much, I hope!

I haven't checked this, and I hope I didn't make too many mistakes.

Voters:
1 David N Gray (TI)
2 Kim A. Barrett (IIM)
3 David Bartley (TI)
4 Sandra J Loosemore (Utah)
5 David Moon (Symbolics)
6 Dan Pierson (Encore)
7 Chris Perdue (Sun)

In some cases I have changed a vote from Y to "I" (conditional) if the
comments said "Only if...." In a couple of cases I changed an "Abstain" to
"Conditional" where the associated comment warrented it.

ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 3, 2-Dec-88
Status: rewording to avoid "Status Quo" debate?

ALIST-NIL
Version 4, 1-Oct-88
Status: Withdrawn, recommend editorial

APPEND-ATOM
Version 1, 6-Dec-88
Synopsis: atom case of APPEND (left out of APPEND-DOTTED)
Status: Ready for release?

APPLYHOOK-ENVIRONMENT
Version 1, 6-Jan-89
Synopsis: remove (useless) env argument to applyhook
Status: Ready for release?

ARGUMENTS-UNDERSPECIFIED:SPECIFY
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Mailed 4 Dec 88
Vote: 1y2y3y4y5y6y6y
Status: part of "block" vote

ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Mailed 5 Dec 88
Vote: 1y3y4y5y*6y6y
Comment: remove UPGRADED-ARRAY-ELEMENT-TYPE and UPGRADED-COMPLEX-PART-TYPE?

BACKQUOTE-COMMA-ATSIGN-DOT
Version 1, 22-Dec-88
Synopsis:  `(... ,@x) vs `(... . ,x). Same, or different?
Status: Two proposals. Connection w/APPEND-DOTTED? Needs edits.

CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, Mailed 5 Dec 88
Vote: 1y3y4y5y6y7y
α∂
CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 1, 6-Jan-89
Status: Too many proposals, not all there.

COERCE-INCOMPLETE (Version 2, 21-Nov-88)
Synopsis: Extend COERCE to handle default coercions? take an optional
FROM-TYPE?
Status: Not Ready

COMPILE-AND-LOAD-VERBOSITY
Synopsis: Need to clarify how much typeout is done when :VERBOSE is
specified to :COMPILE and :LOAD
Status: is there an issue?

COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula

CONSTANT-SIDE-EFFECT (not submitted,???)
Synopsis: It is an error to do destructive operations on constants in code,
defconstant.
Status: In compiler?

CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
Version 1, 14-Sep-88, Mailed 6 Oct 88
Vote: 1n2y3n4y5y6y7y

DECLARATION-SCOPE:NO-HOISTING
Vote: 1n2n3n4y5n6y7i
DECLARATION-SCOPE:LIMITED-HOISTING
Vote: 1y2n3y4n5y6i7y
Version 4, 15-Nov-88, Mailed 9-Dec-88
Comment: "I really don't like NO-HOISTING because it is too imcompatible.
I think I
could live with LIMITED-HOISTING, but I'm unconvinced of the need for such
an
incompatible change.  All of the problem examples are easily solved by
simply
changing some of the variable names."
	6: "I support LIMITED-HOISTING if NO-HOISTING fails.  Either is better
than
nothing."
	7: "NO-HOISTING
If cases hoisted by 2nd alternatives are treated as errors and
limited-hoisting fails."

DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
Vote: 1n3y4y5y*6y7y
Version 4,  5-Dec-88, Mailed  5-Dec-88
Comment: 5: "Moon is mildly opposed to this proposal,
DELETE-FTYPE-ABBREVIATION,
 because he sees it as gratuitously incompatible. Pitman favors the
 proposal because he thinks the benefit of making things regular will
 outweigh the costs."

DECLARE-TYPE-FREE:ALLOW
Vote: 1a3y4y5n*6n7y
Version 8, 7-Dec-88, Mailed 9-Dec-88
Comment: 5: DECLARE-TYPE-FREE:LEXICAL(9, unreleased) Yes.
	6: Y       Version 9, DECLARE-TYPE-FREE:ALLOW
	   N       Version 9, DECLARE-TYPE-FREE:LEXICAL

DECLARE-TYPE-USER-DEFINED
Synopsis: allow (declare (type x y z)) for all valid type specifies type

DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
Vote: 1y3y4a5y6y7y
Version 2, 30-Sep-88, Mailed 6 Oct 88

DEFINITION-DELETE
Status: not submitted

DEFMACRO-BODY-LEXICAL-ENVIRONMENT
Synopsis: Allow DEFMACRO at non-top-level to capture environment. Not
submitted because "top level" wasn't defined.
Status: not submitted to cleanup; in compiler committee

DEFPACKAGE:ADDITION
Version 7, 2-Nov-88, Mailed 5 Dec 88
Vote: 1y3y4y5y*6y7i
Comment: 5: The semantics should be defined in terms of the existing
package
 functions rather than being redundantly described, in order to minimize
 the risk that DEFPACKAGE and the package functions will accidentally
 differ in some unintended way.
	7: "If we allow time for more experimental usage of this before adopting
it."

DEFSTRUCT-ACCESS-FUNCTIONS
Synopsis: defstruct accessors are proclaimed inline
Version 1, 5-Oct-88

DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Version 2, 21-Sep-88, Mailed 6 Oct 88
Vote: 1y2i3y4y5y6y7i
Comment: "The proposal should accomodate comments by IIM about some
keywords
 that were (presumably accidentally) not addressed "
	7: "If the proposal is fixed as suggested by Kim Barrett"

DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Version 3, 7 Dec 88, Mailed 12-Dec-88
Vote: 1Y2y3y4y5y6y7y

DEFSTRUCT-REDEFINITION (Version 1)
Status: Not released; need more options.

DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
Version 4, 31-Oct-88, Mailed 12-Dec-88
Vote: 1Y2y3y4y5y6y7y

DELETE-FILE-NONEXISTENT 
Version 1, 5-Oct-88
Status: Needs work

DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
Vote: 1n2a3n4n5y6n7n
DESCRIBE-INTERACTIVE:NO
Vote: 1y2y3y4y5n*6y7y
Version 4, 15-Nov-88, Mailed 7-Dec-88
Comment: "We prefer option EXPLICITLY-VAGUE.
 We would vote "Yes" for the NO option iff EXPLICITLY-VAGUE fails."

DOTTED-MACRO-FORMS:ALLOW
Vote: 1y2y3y4y5y6y7y
Version 3, 15-Nov-88, Mailed 7-Dec-88

DYNAMIC-EXTENT (Version 2, 15-Nov-88)
	Not Ready (?)

ELIMINATE-FORCED-CONSING
Version 3, 31-Aug-88
Status: Not Ready (?)

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.

ERROR-NOT-HANDLED
Version 1, 25-Sep-88

EQUAL-STRUCTURE:STATUS-QUO
Vote: 1y2i3y4a5i*6y7y
Version 5, 1-Oct-88, Mailed 8 Oct 88
Comment: "There are important technical comments about EQUALP which have
not
 been addressed, and which we feel must be addressed before this is
 brought to a serious vote. Ultimately, when those pending technical
 comments have been addressed, we expect to buy into this proposal."


EXIT-EXTENT:MINIMAL
Summary: What happens with non-local exits out of UNWIND-PROTECT cleanup
clauses?
Vote: 1a2n3a4n5n*6c7n
EXIT-EXTENT:MEDIUM
Vote: 1a2i3y4y5n*6c7y
Version 5, 12-Dec-88, Mailed 12-Dec-88
Status: serious mistakes as per moon, JonL says "not at this time"
	Sadly, we feel it is still premature to vote on this issue at this time.
 There are too many errors and inconsistencies in the writeup.


EXPT-RATIO:P.211
Vote: 1y2y4y5y6y7y
Version 3, 31-Oct-88, Mailed 7 Dec 88

FILE-LENGTH-PATHNAME 
Status: not submitted "Some people didn't seem to think this was
appropriate. No one seemed very interested in writing it up."

FILE-WRITE-DATE-IF-NOT-EXISTS
Synopsis: What does FILE-WRITE-DATE do if no such file?
Version: no proposal
Status:  "error signalling" committee

FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
Vote: 1n2n3n4i5y6y7n
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
Vote: 1y2n3y4y5n6a7n
Version 4, 7-Dec-88, Mailed 12-Dec-88
Comment: "TOSS-FIXNUM-TOSS-BIGNUM?"
	4: "TIGHTEN-DEFINITION if TIGHTEN-FIXNUM-TOSS-BIGNUM is voted down"

FOLLOW-SYNONYM-STREAM
Status: Not Submitted; lost in STREAM-ACCESS

FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
Vote: 1y2y3y4a5y6y7y
Version 2, 2 Oct 88, Mailed 6 Oct 88

FORMAT-NEGATIVE-PARAMETERS
Version: No proposal
Status: "KMP will incorporate in the list-of-signals part of the signal
proposal"

FORMAT-PRETTY-PRINT:YES
Vote: 1y2y3y4y5y6y7y
Version 7, 15 Dec 88, Mailed 7 Dec 88
Comments: "Although some fixes were made to accomodate ~R, some minor
lingering
 questions remain, which should be addressed under separate cover:
   - Is PRINT-OBJECT used to print things of type FLOAT in any cases
     where ~$, ~E, ~F, or ~G is used?
   - Can users write any methods (including :AROUND, :BEFORE, etc) for
     PRINT-OBJECT on type FLOAT?
 If the answers to both of these questions end up being "Yes", then it
 matters whether any of those format ops bind *PRINT-BASE* in order to
 achieve the effect prescribed by CLtL of always printing floats in 
 base 10. If the answer to either of those questions is "No", then
 it doesn't matter."


FORMAT-ROUNDING
Version 1, 5-Oct-88

FUNCTION-ARGUMENT-LIST
Synopsis: want way to get argument list

FUNCTION-COERCE-TIME (Version 2, 16-sep-88)
Not ready

FUNCTION-COMPOSITION:NEW-FUNCTIONS
Vote: 1n2n3n4n5y*6a7n
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
Vote: 1n2y3n4y5i*6y
Version 4, 12 Dec 88, Mailed 12 Dec 88
Comments: "Barry Margolin's complaint about the degenerate case of COMPOSE
should be
 fixed in both proposals."
	6: "We would vote "Yes" for COMPLEMENT-AND-ALWAYS iff NEW-FUNCTIONS
fails."

FUNCTION-DEFINITION:FUNCTION-SOURCE
Vote: 1y3y4y5y6y7y
Version 2, 09-Dec-88	, Mailed 9 Dec 88

FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Mailed  12-Dec-88
Vote: 1y2y3y4y5y6y7y

FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
Vote: 1y2n3y4a5y*6y7y
Version 5, 14-Nov-88, Mailed 8-Dec-88
Comments: "It turns out the list type specifier being contemplated wouldn't
have
 helped the case of alternating keyword value pairs because `repetitions'
 were not among the issues being addressed by those working on that topic."

GC-MESSAGES
Version 2, 14-Nov-88

GET-MACRO-CHARACTER-DISPATCHING
What does GET-MACRO-CHARACTER return for dispatching macros?

GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
Vote: 1y3y4y5y*6y7y
Version 2, 8 Dec 88, Mailed 8 Dec 88
Comments: "The proposal is ok, but the test case is wrong and should
definitely be
 fixed before a vote is called. EQness of successive results from 
 GET-MACRO-CHARACTER when given the same arguments is not guaranteed
 currently, and the new proposal does not suggest causing such a thing."

HASH-TABLE-ACCESS (Version 2, 13 Oct 88)
PROVIDE
Not ready

HASH-TABLE-GC (no proposal)
Will not be

HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
Vote: 1a3a4n5y*6y7y
Version 7, 8-Dec-88, Mailed 9-Dec-88
Comments: "The test-package-iterator example has the values from the
generator in
 the wrong order. This should be fixed before the actual vote."

HASH-TABLE-PRINTED-REPRESENTATION (Version 2)
Not ready (new proposal from KMP?)

HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
Vote: 1a2y3y4c5n*6a7n
Version 1, 11-Nov-88	, Mailed 12 Dec 88
Discussion: "It isn't clear that this is necessary, but I won't oppose
	it if other people think it is important."
	"I agree with the sentiments expressed in the "additional comment"
    at the end.  I'd rather see a shorter proposal that deals only
    with destructive operations on keys."
	"We believe that it is not appropriate to vote on this issue at this
 time. Neither of us had the patience to figure out in enough detail
 what it was saying to have any confidence in our opinions on the issue.
 If there is really something important going on here, it should be
 possible to say briefly and in plain English what the problem being 
 addressed is and what the nature of the solution is. If, after a brief,
 intelligible, high level discussion of the issue, details must be
 presented to back up the high level goals, that would be fine."


HASH-TABLE-TESTS:ADD-EQUALP
Vote: 1y3y4n5y*6y7y
Version 2, 8-Dec-88, Mailed 8 Dec 88
Comment: "We would really like to see = hash tables, too."

IEEE-ATAN-BRANCH-CUT

IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
Vote: 1y2y3y4n5y6y7i
Version 4, 12-Dec-88, Mailed 12-Dec-88
Discussion: "Our "Yes" vote is contingent on the DEFPACKAGE passing."
	"If we allow time for more experimental use of DEFPACKAGE before
adopting this."

IN-SYNTAX
Synopsis: IN-PACKAGE for readtables
Version 1, 21-Oct-88

INPUT-STREAM-P-CLOSED
Version: not submitted
Synopsis: What do INPUT-STREAM-P and OUTPUT-STREAM-P do on closed streams?

INPUT-STREAM-P-EXAMPLE
Version 1, 26-Oct-88

LAMBDA-FORM:NEW-MACRO
Vote: 1y3y4n5y6a7n
Version 4, 22-Nov-88, Mailed 8-Dec-88

LAMBDA-LIST-DUPLICATES
withdrawn

LCM-NO-ARGUMENTS:1
Vote: 1y3y4y5y6y7y
Version 1, 17 Oct 88, Mailed 8 Dec 88

LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION 
Status: Not yet submitted
Synopsis: should LEAST-POSITIVE- and MOST-POSITIVE-XXX-FLOAT numbers
include denormalized ones in those implementations that admit them?

LET-TOP-LEVEL
Synopsis: What's top level?
Status:  => clcompiler

LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88

LISP-SYMBOL-REDEFINITION:DISALLOW
Vote: 1y3y4y5i6y7n
Version 5, 22-Nov-88, Mailed 8 Dec 88
Comment: "We're reluctant to include the paragraph about permitting (DEFVAR
CAR ...).
 Our vote is "Yes" only if the paragraph suggesting this is permissible
 is removed."

LIST-TYPE-SPECIFIER (Version 1)
	no new version?

LOAD-OBJECTS
Version 1, 2-Jan-89
Synopsis: "Provide a way to allow defstruct/defclass objects in compiled
files"
LOAD-TIME-EVAL 
Synopsis: #, semantics not in read macro
Status: => clcompiler

LOAD-TRUENAME

MAKE-CONCATENATED-STREAM-EXAMPLE
Version 1, 26-Oct-88

MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Vote: 1y2n3y4n5n*6y7n
Version 2, 8 Oct 88, Mailed 12-Dec-88
Comment: lengthy

MAKE-STRING-FILL-POINTER
Version 1, 20-Oct-88

MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Vote: 1y2y3y4y5y6y7y
Version 2, 09-Jun-88, Mailed 8 Oct 88

NTH-VALUE:ADD
Vote: 1a3n4n5y*6y7y
Version 4, 8-Dec-88, Mailed 8 Dec 88
Discussion: "OK, but of marginal value."
	The proposal should clarify the treatment of n when it is out of range.
 Any non-negative integer index values should be permitted.
 NIL should result if the index argument is too large.

OUTPUT-STREAM-P-EXAMPLE
Version 1, 26-Oct-88

PACKAGE-CLUTTER:REDUCE
Vote: 1y2y3y4i5y6y7y
Version 6, 12-Dec-88, Mailed 12-Dec-881
Discussion: stronger on properties; bugs
	"I don't see any need to restrict the use of internal symbols in
    the LISP package as property indicators.  Otherwise I support the
    proposal."

PACKAGE-DELETION:NEW-FUNCTION
Vote: 1y3y4a5y6y7a
Version 5, 21 nov 88, Mailed 8 Dec 88
minor glitches

PACKAGE-FUNCTION-CONSISTENCY
Version 1, 21-Oct-88

PATHNAME-CANONICAL-TYPE
Status: => "pathname" committee

PATHNAME-COMPONENT-CASE
Status: => "pathname" committee

PATHNAME-LOGICAL
Status: => "pathname" committee

PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Status: expand current practice?

PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Status: => "pathname" committee

PATHNAME-SYNTAX-ERROR-TIME
Status: => "pathname" committee

PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
Vote: 1y3y4i5y6y7n
Version 1 27-Jun-88, Mailed 7 Oct 88
Comment: ":UNSPECIFIC should be legal in all pathname fields, not just in
the
    type field."
	"No Unix convention I know of requires this new concept.  Perhaps a
couple of good examples would convince me."

PATHNAME-WILD
Status: => "pathname" committee

PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: How to deal with logical devices, :unspecific components, etc in
pathname functions
Status: PATHNAME-TYPE-UNSPECIFIC handled part, rest not yet submitted =>
"pathname"

PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
Synopsis: interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM
Vote: 1y2y3y4n5y*6y7y
Version 3, 8-Oct-88, Mailed 8 Oct 88
Comment: "All metastreams must now support PEEK-CHAR directly..."
	"This proposal seems to be in conflict with the rationale for
    issue UNREAD-CHAR-AFTER-PEEK-CHAR, which is to legitimize
    implementing PEEK-CHAR as READ-CHAR/UNREAD-CHAR."
	"There are some typos in this proposal that need to be corrected.
 Also, IIM asked for a clarification which seemed reasonable to us."

PRINT-CIRCLE-SHARED
Status: Not submitted
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?

PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
Vote: 1y3y4i5y6y7y
Version 3, 20 Sep 88, Mailed 8 Oct 88
Comment: This proposal would be OK if it specified that circularity only
    had to be detected for objects that are contained in slots of the
    structure, not random objects that are printed out by the structure
    print function.  Rationale:  an obvious way to handle circular
    printing is to traverse the structure to detect circularities before
    printing anything."

PROCLAIM-LEXICAL:LG
Synopsis: add LEXICAL proclaimation
Vote: 1n3c4n5y*6y7n
Version 9, 8-Dec-88, Mailed 12-Dec-88
Discussion: change "Clarify" => "Define"
	"This sounds like basically a good idea, but there appears
	to be insufficient experience with actually implementing
	and using it for it to be ready for standardization."
	"I favor this in principle, but I want some discussion to
	ensure that we're all talking about the same thing."
	"I don't have any fundamental complaint with this issue, but I believe 
    we need more experience with this feature before it should be 
    standardized."
	"The proposal might want to define the status of unproclaimed free
variables.
 Presumably, we should say that they are an error, and we should encourage
 compilers to issue a warning."
	"I don't believe in the reality of a separate "dynamic" environment,
don't believe it makes sense to support rapid access to
Globals on stock hardware, and don't understand what Scheme practices
don't work in Common Lisp.  Perhaps I can be dissuaded about some or
all of these opinions."

PROCLAIM-SCOPE
Status: => clcompiler

PROMPT-FOR
Status: awaiting resubmission

RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
Vote: 1y3y4y5y6y7y
Version 3, 9-Oct-88, Mailed 14-Oct-88

RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
Vote: 1y2y3y4y5y6y7y
Version 1, 14-Sep-88, Mailed 7 Oct 88

READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Status: Not submitted

READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error

REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL

REMF-MULTIPLE 
Synopsis: What does REMF do if it sees more than one INDICATOR?
Status: Not ready

REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
Vote: 1y2y3y4y5y6y7n
Version 6, 9 Dec 88, mailed 09 Dec 88
Comment: "Deprecate instead.  Do not remove from the Lisp package."

REST-LIST-ALLOCATION:NEWLY-ALLOCATED
Vote: 1n2n3n4n5n6n7n
REST-LIST-ALLOCATION:MAY-SHARE
Vote: 1y2y3y4y5y6y7y
REST-LIST-ALLOCATION:MUST-SHARE
Vote: 1n2n3n4n5n6n7n
Version 3, 12-Dec-88, mailed 12-Dec-88
Discussion: Add a new kind of declaration


REST-LIST-EXTENT
Status: incorporated in issue DYNAMIC-EXTENT

RETURN-VALUES-UNSPECIFIED:SPECIFY
Vote: 1y3y4y5y6y
Version 6,  9 Dec 88 mailed  9-Dec-88

ROOM-DEFAULT-ARGUMENT:NEW-VALUE
Vote: 1y2y3y4a5y6y
Version 1 12-Sep-88 mailed 8 Oct 88
Comment: "I liked KMP's suggestion of defining additional synonyms"


[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
Vote: 1y3y4n5n*6y7i
Version 3, 4-Nov-87, mailed Nov 87
Comment: "We think it's premature to vote on this issue at this time.
 We suggest that a better proposal, unifying this issue with SETF-PLACES,
 should be produced either before or during the upcoming meeting."
	7: "If SETF-PLACES:ADD-SETF-FUNCTIONS is deemed unsatisfactory by X3J13"

SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 1, 5-Dec-88

SETF-PLACES:ADD-SETF-FUNCTIONS
Vote: 1n3n4i5n*6i7y
Version 1, 11-Nov-88, mailed 9-Dec-88
Discussion: other options? (Comments)
"We think it's premature to vote on this issue at this time.
 We suggest that a better proposal, unifying this issue with 
 SETF-FUNCTION-VS-MACRO, should be produced either before or during
 the upcoming meeting."

SETF-SUB-METHODS:DELAYED-ACCESS-STORES
Synopsis: more careful definition of order of evaluation inside (SETF (GETF
...) ...) 
Vote: 1a2y4y5y6y7n
Version 5, 12-Feb-88 mailed 8 Oct 88
	7: "This does not seem to be the "right" choice of semantics, and I
believe that the presentation of the proposal needs substantial work
even if it is "right".


SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Version 6, 06-Oct-88
Status: New version scales down rejected version

SINGLE-FLOAT-NON-PORTABLE
Status: Not yet submitted
Synopsis: should single-float and double-float be removed from the
standard?

SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Status: superceded by DECLARE-TYPE-FREE?

SPECIAL-VARIABLE-TEST
Status: "On hold pending SYNTACTIC-ENVIRONMENT-ACCESS"

STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
Vote: 2y3y4y5y6y7y
Version 8, 8 Jul 88, Mailed 7 Oct 88

STANDARD-VALUE
Synopsis: specify way to communicate from user programs to REP loops when
binding is "temporary"
Version 1, 21-Oct-88

STEP-ENVIRONMENT:CURRENT
Vote: 1y2c3y4y5i6y7y
Version 3, 20-Jun-88, mailed  7 Oct 88
Comment: "We don't understand
    "it is acceptable for an implementation to interactively step
     through only those parts of the evaluation that are interpreted."
 There are a variety of ways to clarify this that would satisfy us.
 Still, this must be clarified so we can know for sure what we're voting
 on and have some confidence that other implementors will interpret it
 in the same way as we have before we can vote "Yes".


STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
Vote: 1n3n4i5n*6y
STREAM-ACCESS:ADD-TYPES-ACCESSORS
Vote: 1n3n4?5y*6?
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
Vote: 1y3y4?5n*6?
version 2, 30-Nov-88 mailed  9 Dec 88
Status: expect amendment T => "true"
Comment: "Although requiring types instead of predicates forces the
implementation
 of these streams as separate types, there is no obvious serious problem
 which can result from that, and it leaves open the possibility of writing
 methods on particular types -- if they are also classes -- are they? The
 proposal should spell this out.
 Having both the types and the predicates is unnecessary clutter.
 Omitting the predicates makes for less overhead with no lost
functionality.

STREAM-CAPABILITIES
Status: => "pathname" committee

STREAM-DEFINITION-BY-USER
Synopsis: Need a way to define user-defined streams.

STREAM-ELEMENT-TYPE-EXAMPLES
Status: ?? missing proposal

STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
Vote: 1y3y4y5i*6y7y
Version 6, 30-Nov-88, mailed 9 dec 88
Status: expect amendment:
		LINE-WIDTH   ==> STREAM-LINE-WIDTH
		LINE-POSITION ==> STREAM-LINE-POSITION
		PRINTED-WIDTH ==> STREAM-STRING-WIDTH
Comment: 5: We vote "Yes" only if the name-changing amendment mentioned in
the mail passes.
 Also, the writeup incorrectly states that Newline is not a standard
character;
 Perhaps someone has confused "standard" with "graphic".


SUBTYPEP-TOO-VAGUE:CLARIFY
Vote: 1y2y3y5y*6y7y
Version 4,  7-Oct-88, mailed 7 Oct 88
Comment: "Some minor worry about DECLARE-FUNCTION-AMBIGUITY here since the
proposal
 mentions the list form of the FUNCTION declaration. This is a complicated
issue and we have not had time to think it through  as fully as we might
like to have. Still, insofar as we have studied it,  it looks ok."

SYMBOL-MACROFLET
Version 1
???

SYMBOL-MACROLET-DECLARE:ALLOW
Vote: 1y3y4i5y6y7y
Version 2,  9-Dec-88, mailed 9 Dec 88
Comment: 4: "Only if SYMBOL-MACROLET-SEMANTICS passes"

SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
Vote: 1y2y3y4a5y6y7y
Version 5, 30-Nov-88, mailed 9 Dec 88

SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
=> clcompiler

TAGBODY-CONTENTS:FORBID-EXTENSION
Vote: 1y3y4y5i6y7y
Version 5, 9-Dec-88 mailed 9 Dec 88
Comment: "The term "data element" is too vague in paragraph 2 of the
proposal.
 Our "Yes" vote is contingent on correcting this.  Moon doesn't really like
allowing ignored frobs other than expressions  and tags, but is willing to
live with the current proposal."

TAIL-RECURSION-OPTIMIZATION (Version 2)
Status: Not Ready

TAILP-NIL:T
Synopsis: Operation of TAILP given NIL
Vote: 1y2y3y4y5y*6y7a
Version 5, 9-Dec-88, mailed 12-Dec-88
Discussion: Current practice is wrong. Expand to LDIFF? Add :TEST?
	"The EQ -> EQL change at the last minute means this is not Genera current
 practice, contrary to the current practice section."

TEST-NOT-IF-NOT:FLUSH-ALL
Vote: 1n3n4y5y*6a7n*
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
Vote: 1n3n4i5y*6a7y
Version 3, 1 Dec 88 mailed 9 dec 
Comment: "Unnecessary incompatible change."
	4: "Flushing some is better than not flushing all"
	5: "We are mostly happy with either of these proposals, with slight 
 preference to FLUSH-ALL. However, our "Yes" vote is contingent on:
   - changing "remove" to "deprecate", and coming up with a
     suitable policy for deprecation which allows a comfortable
     transition from current practice.
   - either of the FUNCTION-COMPOSITION proposals passing.
	7: Perhaps deprecate these instead.  They need to remain in the LISP
package.  The functionality of REMOVE-IF-NOT is needed, perhaps use
the name KEEP-IF."
"

THE-AMBIGUITY
Version 1, 21-Oct-88
Status: typo

TRACE-ERROR
Version 1
Status: withdrawn?

TRACE-FUNCTION-ONLY (withdrwan)

TRUENAME-SYNTAX-ONLY
Status: => "pathname" committee

TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
Vote: 1y2c3y4y5i6y7i
Version 3, 12-Dec-88, mailed 12 Dec 88
Discussion: some "bugs" in the proposal
 5: "Our "Yes" vote is contingent on the following issues being addressed:
  - RANDOM-STATE should be added to the list of built-in types.
  - (subtypep (type-of x) (class-of x)) => T T for all x, seems to have
    been intended but is not actually said. It should be added.
  - The implementation recommendation in the discussion about returning
    only portable type specifiers should be discarded.
  - Shouldn't this refer to classes with proper names rather than just
    ones with names?
7: If the language in paragraph (a) is made clear.  I can't tell which
"quantifiers" are intended or over what scope in the presentation.



TYPE-SPECIFIER-PREDICATE
Status: Not yet submitted
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."

UNDEFINED-VARIABLES-AND-FUNCTIONS
Version 1, 29-Nov-88

UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
Vote: 1y2y3y4y5y6y7y
Version 2, 2-Dec-88, mailed 12-Dec-88

UNWIND-PROTECT-NON-LOCAL-EXIT
Status: renamed to EXIT-EXTENT

VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
Vote: 1y3y4y5y6y7y
Version 3, 08-Oct-88, mailed 9 Dec 88

WRITE-NEWLINE
Status: Not submitted

∂06-Jan-89  2246	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  22:45:31 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 89 11:48:01 PST
Date: 6 Jan 89 11:37 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 3)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Fri, 2 Dec 88 05:23 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.edu
Message-ID: <890106-114801-253@Xerox>

I'd like to see the following changes to the proposal:

a) I don't like saying that the effect of adjusting an array which "is not
adjustable" is not defined. I don't see any reason not to say that it
signals an error. 

b) I like defining clearly that "is not adjustable" means
"ADJUSTABLE-ARRAY-P returns false", and clarifying that MAKE-ARRAY may
return an adjustable array even if the :ADJUSTABLE array is given NIL.

c) I would like to say that either all arrays are adjustable, or else only
those that are specified with :ADJUSTABLE true, and that a conformal
implementation will document which behavior it uses.

d) Rename the proposal name from "STATUS-QUO" to "MAY-BE-ADJUSTABLE" and
change  "Document clearly" to "Specify". 

Is this OK?


∂06-Jan-89  2246	CL-Cleanup-mailer 	Issue: LISP-SYMBOL-REDEFINITION (Version 5)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  22:45:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 89 11:16:35 PST
Date: 6 Jan 89 11:06 PST
From: masinter.pa@Xerox.COM
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 5)
In-reply-to: cperdue@Sun.COM (Cris Perdue)'s message of Thu, 5 Jan 89
 18:05:29 PST
To: cperdue@Sun.COM (Cris Perdue)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890106-111635-248@Xerox>

On your ballot, Sun commented "This appears to disallow too much." 

What things would you allow that are disallowed by this proposal?

∂06-Jan-89  2247	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 1)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  22:45:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 14:54:13 PST
Date: 6 Jan 89 14:51 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: REAL-NUMBER-TYPE (version 1)
In-reply-to: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>'s
 message of Fri, 6 Jan 89 17:36 EST
To: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
cc: 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
Message-ID: <890106-145413-1224@Xerox>

The proposal should make REAL a CLOS class too, I think, rather than just
allowing that to be done.


∂06-Jan-89  2247	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  22:45:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 89 11:58:01 PST
Date: 6 Jan 89 11:57 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
In-reply-to: CL-Cleanup@Sail.Stanford.edu's message of 5 Dec 88 11:45 PST
To: cl-cleanup@Sail.Stanford.Edu
cc: masinter.pa@Xerox.COM
Message-ID: <890106-115801-255@Xerox>

The proposal contains the sentence

 'Eliminate the distinction between types "for declaration" and "for 
    discrimination".'

However, the distinction remains for the list form of the FUNCTION type
specifier, which is only valid "for declaration".

I don't think the proposal removes the list form of the FUNCTION type
specifier, or (alternatively, magically) allows the list form of the
FUNCTION type specifier to be used for discrimination. I think the sentence
needs to be qualified that it applies to COMPLEX and ARRAY and VECTOR type
specifiers.

I concur with the sentiment that would like to see the proposal amended to
remove UPGRADED-COMPLEX-PART-TYPE and UPGRADED-ARRAY-ELEMENT-TYPE, as they
are of so extremely limited utility and can be written trivially if really
necessary.

Stylisticly, this can be accomplished quickly if a bit awkwardly, by saying
"The proposal is written using the following two functions, although these
functions are not added to the standard."



∂06-Jan-89  2247	CL-Cleanup-mailer 	Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  22:45:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 89 14:04:22 PST
Date: 6 Jan 89 14:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Fri, 30 Dec 88
 02:31:41 PST
To: Jon L White <jonl@lucid.com>
cc: Gray@DSG.csc.ti.com, KMP@STONY-BROOK.SCRC.Symbolics.COM,
 CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890106-140422-1103@Xerox>

I fail to see the necessity of correlating the behavior of backquote with
the behavior of APPEND, since we've not ever specified that backquote
actually has to use APPEND. If your backquote currently uses APPEND, make
it use BACKQUOTE-APPEND instead which has some other semantics than APPEND.


∂06-Jan-89  2247	CL-Cleanup-mailer 	Issue: APPLYHOOK-ENVIRONMENT (Version 1) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  22:45:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 JAN 89 11:50:58 PST
Date: 6 Jan 89 11:49 PST
From: masinter.pa@Xerox.COM
Subject: Issue: APPLYHOOK-ENVIRONMENT (Version 1)
To: cl-cleanup@sail.stanford.edu
Message-ID: <890106-115058-253@Xerox>

!
Forum:	Cleanup
Issue:         APPLYHOOK-ENVIRONMENT

References:    APPLYHOOK (CLtL p. 323)

Category:      CHANGE

Edit history:  Masinter,  6-Jan-89, Version 1

Problem description:

The function APPLYHOOK is documented to take an optional environment
argument. CLtL says "Furthermore, the env argument is used as the lexical
environment for the operation; env defaults to the null environment." 

However, there is no way that the lexical environment can effect the way in
which APPLYHOOK processes its arguments; it merely calls the specified
function, and function call is not affected by lexical environments. (The
"function" argument to APPLYHOOK is a function object.)

This has been regularly a source of confusion for programmers encountering
APPLYHOOK.

Proposal (APPLYHOOK-ENVIRONMENT:REMOVE-ENV): Remove the optional "ENV"
argument to applyhook. 

Rationale:

Removes a very minor wart.

Current practice:

Most implementations accept an extra argument and then ignore it.

Cost to Implementors:

Remove optional ENV argument from APPLYHOOK and any code that passes one to
APPLYHOOK.

Cost to Users:

Remove any ENV argument passed to APPLYHOOK.

Cost of non-adoption:

Continued confusion.

Performance impact:

None

Benefits:

Removes a wart.

Esthetics:

Minor improvement.

Discussion:

This was discussed  on the Common Lisp mailing list several years ago, but
slipped thru the cracks.


∂06-Jan-89  2247	CL-Cleanup-mailer 	Re: Issue: CLOSE-CONSTRUCTED-STREAMS (not yet submitted)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  22:46:01 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 89 15:40:59 PST
Date: 6 Jan 89 15:40 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CLOSE-CONSTRUCTED-STREAMS (not yet submitted)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Wed, 14 Dec 88 01:00 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <890106-154059-1328@Xerox>

!
Forum:	Cleanup
Issue:         CLOSE-CONSTRUCTED-STREAM

References:    Close (CLtL p. 332), WITH-OPEN-STREAM 
	(CLtL p 330), make-synonym-stream, make-broadcast-stream,
	make-concatenated-stream, make-two-way-stream,
	make-echo-stream, make-string-input-stream,
	make-string-output-stream, with-input-from-string,
	with-output-from-string

Related issues: CLOSED-STREAM-OPERATIONS

Category:      Clarification/Change

Edit history:  Masinter,  6-Jan-89, Version 1

Problem description:

First some terminology:

A "composite" stream is one created with make-synonym-stream,
make-broadcast-stream, make-concatenated-stream, make-two-way-stream,
make-echo-stream. 

A "constructed" stream is either a composite stream or one created with
make-string-input-stream, make-string-output-stream,
with-input-from-string, with-output-from-string.

The function "CLOSE" is currently described in 21.3, which starts "This
section contains discussion of only those operations that are common to all
streams."  This would seem to imply that they apply to constructed streams.

The definition of CLOSE "The argument must be a stream. No further
input/output operations may be performed on it. ... "  It further states
"... and it is permissible to close an already closed stream."

However, the behavior on the constructed streams is not well defined, and
implementations (apparently) differ.

Proposal (CLOSE-CONSTRUCTED-STREAM:IS-ERROR): 

It "is an error" to call CLOSE on a constructed stream. CLOSE might signal
an error, or the result of CLOSE could cause the constituent streams to be
closed, etc, but the effect is implementation-dependent.

Proposal: (CLOSE-CONSTRUCTED-STREAM:SIGNALS-ERROR)

Calling CLOSE on a constructed stream signals an error.

Proposal (CLOSE-CONSTRUCTED-STREAM:ARGUMENT-STREAM-ONLY):

The effect of CLOSE on a constructed stream is to close the "argument"
stream only, but none of the constituents; that is, 

a) no i/o operations are permitted after the call to CLOSE on the stream
given to CLOSE. In addition, for streams created with
make-string-output-stream, the result of get-output-stream-string is
unspecified. For other composite streams, the "links" 

b) the call to CLOSE has no effect on other streams:
	for broadcast, two-way,  synonym or echo streams, none of
	the constituent streams are closed (the "links"
	to the constituents may be broken; if the proposal
	in STREAM-ACCESS passes, the results of
	the accessor functions there are unspecified after
	the call to CLOSE.)

Examples:

tbd

Rationale:

Signalling an error is reasonable if no Common Lisp program ever needs to
call CLOSE on a composite stream. We could not come up with a legitimate
case where you wouldn't instead close the underlying stream if that's what
you wanted.

Allowing the result to be implementation dependent is the "status quo". 

ARGUMENT-STREAM-ONLY is probably the "safest" in that it makes it harder to
accidentally close a stream that wasn't intended. 

Current practice:

Envos Medley seems to implement ARGUMENT-STREAM-ONLY.

Cost to Implementors:

Varying, depending on the current level of conformance. Making the changes
themselves is probably trivial (to the "close" method for each kind of
constructed stream type)

Cost to Users:

Likely small; we've not found any good uses for CLOSE on composite streams.

Cost of non-adoption:

Continued minor ambiguity

Performance impact:

near zero

Benefits:

The language would be more well specified.

Esthetics:

Well-specified languages are usually easier to deal with.

Discussion:


We discussed, and there was some sentiment, for another alternative: CLOSE
closes the constituent streams as well.  It could be an incompatible change
for some implementations. it makes more sense for things like broadcast
streams (which are usually non-interactive) than it does for echo streams
(which are sometimes interactive).

ARGUMENT-STREAM-ONLY is weird. i can't figure out what i think of it. it
seems counterintuitive and yet it probably wouldn't be harmful if it were
well-defined that this was what it did.

∂06-Jan-89  2258	CL-Cleanup-mailer 	Issue FUNCTION-COMPOSITION
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 6 Jan 89  22:58:14 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via INTERNET with SMTP id 256965; 7 Jan 89 01:56:21 EST
Date: Sat, 7 Jan 89 01:55 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue FUNCTION-COMPOSITION
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, cperdue@Sun.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890106185519.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890107065549.9.GSB@GANG-GANG.SCRC.Symbolics.COM>

    Date: Fri, 6 Jan 89 18:55 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    I can't support any abbreviated name, and CONSTANT-FUNCTION is too long.
    ALWAYS is at least current practice in an existing dialect.
    However, if you really can't deal, how about CONSTANTLY.
     (MAPCAR (CONSTANTLY 7) '(A B C)) => (7 7 7)

yes to CONSTANTLY.  ALWAYS is a bad choice.

∂06-Jan-89  2311	CL-Cleanup-mailer 	Ballots, please 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Jan 89  23:11:00 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate id AA08288g; Fri, 6 Jan 89 23:07:09 PST
Received: by bhopal id AA02680g; Fri, 6 Jan 89 23:09:24 PST
Date: Fri, 6 Jan 89 23:09:24 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901070709.AA02680@bhopal>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 6 Jan 89 00:23 PST <890106-002339-193@Xerox>
Subject: Ballots, please

Some of the senior staff at Lucid will meet early next week to discuss
what response to make to the ballot.  We will continue, however, to
make our interests known on individual issues as the needs arise.

-- JonL --

∂06-Jan-89  2349	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (Version 7)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jan 89  23:48:53 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JAN 89 23:47:46 PST
Date: 6 Jan 89 23:47 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFPACKAGE (Version 7)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Wed, 14 Dec 88
 01:42:24 PST
To: Jon L White <jonl@lucid.com>
cc: barmar@Think.COM, CL-CLEANUP@sail.stanford.edu
Message-ID: <890106-234746-2045@Xerox>

After re-reading the discussion, I think the only issue is to define
explicitly what "at variance with the current state of that package" means.
I think a subjunctive definition might be OK, here's a try:

Add to the Proposal: 

A DEFPACKAGE is "at variance with the current state of a pre-existing
package" if the result of executing the DEFPACKAGE with a different name
would create a package with a different set of exported symbols, a
different set of USEd packages, with any *more* shadowing symbols, or a
different set of nicknames.

A DEFPACKAGE is not at variance with the current state of a pre-existing
package even if the size of the pre-existing package differs from the :SIZE
of the DEFPACKAGE form, or if it the pre-existing package has more internal
symbols.

If there is a new proposal (rather than an amendment), it might be useful
to add to the discussion:

"One of the most common recipes for disaster is to have differing EXPORTs
in two package definitions, and then to load a file which was compiled in
one of these two enviroments into a "runtime" image that has the other
environment.  The file being loaded may expect to inherit some symbols
(due to their being EXPORT'd from a "used" package at compile time); but 
failing to inherit at "run time", it will create a Doppelganger in the 
current package

Virtually any difference *can* be made to be critical, due to the fact
that the package system is a global database in a flat namespace (there
is no "context" for FIND-PACKAGE).  Leaving it undefined as to how to 
handle varying package re-definitions allows the implementations to
experiment with helpful warnings, recovery stratagies, etc."

How this will get into the standard in the Rationale section is not clear,
but hopefully KC can find a way to cope with it.

∂07-Jan-89  0007	CL-Cleanup-mailer 	Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE (Version 2)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jan 89  00:07:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 JAN 89 00:03:16 PST
Date: 7 Jan 89 00:02 PST
From: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE (Version 2)
To: cl-cleanup@sail.stanford.edu
reply-to: cl-cleanup@sail.stanford.edu
Message-ID: <890107-000316-2049@Xerox>

I couldn't resist changing the name of the issue lest we have another
future issue also dealing with DEFSTRUCT-ACCESS-FUNCTIONS.


!
Issue:        DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
References:   DEFSTRUCT (p. 308)
Category:     CHANGE
Edit history: 5-Oct-88, Version 1 by Chapman
               6-Jan-89, Version 2 by Masinter

Problem Description:

 It is left up to the implementation whether or not the DEFSTRUCT access
 function is declared inline. Thus, some programmers write:

 (PROCLAIM '(INLINE FOO-A FOO-B FOO-C))
 (DEFSTRUCT FOO A B C)

 in portable code in case the code is run in an implementation where
 the INLINE proclaimation is meaningful but not the default for
 DEFSTRUCT accessors.

Proposal (DEFSTRUCT-ACCESS-FUNCTIONS-INLINE:YES)

 Make it mandatory that implementations declare access functions inline.
 Of course the declaration may or may not mean anything within the 
 particular implementation.

Rationale:

 This requirement resolves user ambiguity.

Current Practice:

  We've not surveyed many implementations, but apparently they
 differ as to whether INLINE for defstruct accessors is the default.

Cost to implementors:

 Minimal.

Cost to users:

 Minimal.

Benefits:

 This clarification will give users insurance that the inline declaration
 has been made for the access function.

Aesthetics:

 Specified is simpler than not-specified.

Performance Impact:
 
  Small. Some programs might have different size/space characteristics.

Discussion:

 We know of no implementation where such automatic inlining would
 be inappropriate, even in cases where INLINE is recognized. Certainly
 implementations are free to ignore INLINE proclaimations even
 selectively, i.e., ignore INLINE proclaimations only for DEFSTRUCT
 accessors.    The major impact of this proposal is just to make it clear
 that a separate (PROCLAIM '(INLINE ...)) is not necessary.

  

∂07-Jan-89  0100	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 1) 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Jan 89  01:00:38 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate id AA08362g; Sat, 7 Jan 89 00:56:37 PST
Received: by bhopal id AA02979g; Sat, 7 Jan 89 00:58:52 PST
Date: Sat, 7 Jan 89 00:58:52 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901070858.AA02979@bhopal>
To: Cassels@STONY-BROOK.SCRC.Symbolics.COM
Cc: 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: Robert A. Cassels's message of Fri, 6 Jan 89 17:36 EST <19890106223654.4.CASSELS@GROUSE.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 1)

I like this.  It's about time [but probably too late for an X3J13
vote in January?].


-- JonL --

∂07-Jan-89  0927	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, Version 1   
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Jan 89  09:27:16 PST
Received: from JACKIE-O.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 159618; Sat 7-Jan-89 12:24:35 EST
Date: Sat, 7 Jan 89 12:24 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
To: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19890107051524.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890107172420.3.MLY@JACKIE-O.AI.MIT.EDU>

    Date: Sat, 7 Jan 89 00:15 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

    [...]

    Since use of the compile-time environment for types should be quite rare,
    this was seen as much less of a burden than modifying existing functions
    to take new optional arguments.

Not so.  Consider compiler optimisations of (MAKE-ARRAY # :ELEMENT-TYPE #)
When I last wrote a CL type system I needed a mess of parallel
COMPILER-SUBTYPEP and COMPILER-UPGRADE-ARRAY-ELEMEN-TYPE (and so forth)
functions.  Using compilation-environment technology would have been far
preferable.

I give MAKE-ARRAY optimisation merely as an example -- I feel `user'
code has the same sorts of needs.

∂07-Jan-89  2109	CL-Cleanup-mailer 	votes at Hawaii 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jan 89  21:09:19 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 JAN 89 20:51:56 PST
Date: 7 Jan 89 20:50 PST
From: masinter.pa@Xerox.COM
Subject: votes at Hawaii
In-reply-to: Jon L White <jonl@lucid.com>'s message of Sat, 7 Jan 89
 00:58:52 PST
To: Jon L White <jonl@lucid.com>
cc: CL-Cleanup@Sail.Stanford.EDU
Message-ID: <890107-205156-2877@Xerox>

If we bring enough copies and no-one invokes the "two-week" rule, we can
get issues passed at the Hawaii meeting. 

∂07-Jan-89  2109	CL-Cleanup-mailer 	[alarson@src.honeywell.com (Aaron Larson): Ballots, please]  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jan 89  21:09:33 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 07 JAN 89 21:06:55 PST
Date: 7 Jan 89 21:04 PST
From: masinter.pa@Xerox.COM
Subject: [alarson@src.honeywell.com (Aaron Larson): Ballots, please]
To: cl-cleanup@sail.stanford.edu
Message-ID: <890107-210655-2892@Xerox>


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

Return-Path: <alarson@src.honeywell.com>
Received: from moon.src.honeywell.com ([129.30.1.10]) by Xerox.COM ; 07 JAN
89 19:26:09 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)
	id AA17213; Sat, 7 Jan 89 21:25:49 CST
Posted-Date: Sat, 7 Jan 89 21:24:16 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
	id AA13383; Sat, 7 Jan 89 21:24:16 CST
Date: Sat, 7 Jan 89 21:24:16 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8901080324.AA13383@pavo.src.honeywell.com>
To: masinter.pa
In-Reply-To: masinter.pa@Xerox.COM's message of 6 Jan 89 00:23 PST
<890106-002339-193@Xerox>
Subject: Ballots, please

This bounced the first time so...

To: masinter.pa@xerox.COM
Subject: Re: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **

The following is my ballot.  There are a couple of baked comments, mostly
notes to myself that I've not had time to check out throughly.  If they are
not clear or usefull, simply ignore them.  All my comments appear on a
single line at the side of the issue name, if this is a mess on your
system, let me know and I'll reformat.  Also, note that I did not copy
cl-cleanup. 

!
ARGUMENTS-UNDERSPECIFIED:SPECIFY                                Yes.
        Version 4, 21-Sep-88, Mailed 4 Dec 88           

ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING               Yes.
        Version 9, 31-Oct-88, Mailed 5 Dec 88

CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY                          Yes
        Version 5,  5-Dec-88, Mailed 5 Dec 88

CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE                   Yes
        Version 1, 14-Sep-88, Mailed 6 Oct 88

DECLARATION-SCOPE:NO-HOISTING                                   Yes.
DECLARATION-SCOPE:LIMITED-HOISTING                              Prefer
no-hoisting, but if there was serious objection, would accept this one
also.
        Version 4, 15-Nov-88, Mailed 9-Dec-88

DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION            Yes. (I
thought this already passed?)
        Version 4,  5-Dec-88, Mailed  5-Dec-88

DECLARE-TYPE-FREE:ALLOW                                         Yes.
        Version 8, 7-Dec-88, Mailed 9-Dec-88

DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE                      Abstain
        Version 2, 30-Sep-88, Mailed 6 Oct 88

DEFPACKAGE:ADDITION                                             Yes.  I
believe that "should signal an error" should be "will signal an error".
        Version 7, 2-Nov-88, Mailed 5 Dec 88

DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY                     Yes
        Version 2, 21-Sep-88, Mailed 6 Oct 88

DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES                        Yes
        Version 3, 7 Dec 88, Mailed 12-Dec-88

DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR               Confused,
why string= on the names.  Does that mean that foo:a and bar:a cannot both
be slots in the same structure?  (check where accessors are interned).
        Version 4, 31-Oct-88, Mailed 12-Dec-88

DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE                           Abstain
DESCRIBE-INTERACTIVE:NO                                         Yes
        Version 4, 15-Nov-88    , Mailed 7-Dec-88

DOTTED-MACRO-FORMS:ALLOW                                        Yes
        Version 3, 15-Nov-88, Mailed 7-Dec-88

EQUAL-STRUCTURE:STATUS-QUO                                      Yes
        Version 5, 1-Oct-88, Mailed 8 Oct 88


EXIT-EXTENT:MINIMAL                                             No,
semantics are bad.
EXIT-EXTENT:MEDIUM                                              Yes
        Version 5, 12-Dec-88, Mailed 12-Dec-88

EXPT-RATIO:P.211                                                Yes
        Version 3, 31-Oct-88, Mailed 7 Dec 88

FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION                          No.  fixnum
is defined to be non portable, if portable code needs to be written, then
(integer low up) is the way to specify it.
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM                  I agree
bignum is not usefull, but there are other non usefull aspects of the
language, and changing them now requires better justification.
        Version 4, 7-Dec-88, Mailed 12-Dec-88                   I don't
feel strongly about either of the above statements.

FORMAT-E-EXPONENT-SIGN:FORCE-SIGN                               Yes
        Version 2, 2 Oct 88, Mailed 6 Oct 88

FORMAT-PRETTY-PRINT:YES                                         Yes
        Version 7, 15 Dec 88, Mailed 7 Dec 88

FUNCTION-COMPOSITION:NEW-FUNCTIONS                              No.  Also,
there is an error in the proposal, the example for find-if specifies AND
and DISJOIN to be equivalent.  Not very "perspicuous".
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS                      No
        Version 4, 12 Dec 88, Mailed 12 Dec 88

FUNCTION-DEFINITION:FUNCTION-SOURCE                             Abstain
        Version 2, 09-Dec-88    , Mailed 9 Dec 88

FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE               Yes.
        Version 3, 7-Dec-88, Mailed  12-Dec-88

FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE        No/Abstain
        Version 5, 14-Nov-88    , Mailed 8-Dec-88

GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD                      Yes
        Version 2, 8 Dec 88, Mailed 8 Dec 88

HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER                  Abstain
        Version 7, 8-Dec-88, Mailed 9-Dec-88

HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS                 ??, very
long.  Check SXHASH, I thought it was supposed to work accross different
invocations of lisp.  This appears to not be the case according to the
proposal.  Since the proposal really i


sn't changing the language (I hope), then it is really only a clarification
of existing status, but I'm not sure I understand the issue any more now
than before I read it.
        Version 1, 11-Nov-88    , Mailed 12 Dec 88

HASH-TABLE-TESTS:ADD-EQUALP                                     Yes
        Version 2, 8-Dec-88, Mailed 8 Dec 88

IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY                            Yes,
conditionally on defpackage passing.
        Version 4, 12-Dec-88, Mailed 12-Dec-88

LAMBDA-FORM:NEW-MACRO                                           Abstain
        Version 4, 22-Nov-88, Mailed 8-Dec-88

LCM-NO-ARGUMENTS:1                                              Yes
        Version 1, 17 Oct 88, Mailed 8 Dec 88

LISP-SYMBOL-REDEFINITION:DISALLOW                               Yes
        Version 5, 22-Nov-88, Mailed 8 Dec 88

MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT               yea sure.
People writing portable code have more subtle problems to worry about than
the default :USE list anyhow. 
        Version 2, 8 Oct 88, Mailed 12-Dec-88

MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE                Yes
        Version 2, 09-Jun-88, Mailed 8 Oct 88

NTH-VALUE:ADD                                                   Abstain/No
        Version 4, 8-Dec-88, Mailed 8 Dec 88

PACKAGE-CLUTTER:REDUCE                                          yes.
        Version 6, 12-Dec-88, Mailed 12-Dec-881

PACKAGE-DELETION:NEW-FUNCTION                                   YES, (minor
editorial comment sent to cleanup (sorry bout that).
        Version 5, 21 nov 88, Mailed 8 Dec 88

PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN                              Yes
        Version 1 27-Jun-88, Mailed 7 Oct 88

PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR                        Yes
        Version 3, 8-Oct-88, Mailed 8 Oct 88

PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK                      Yes
        Version 3, 20 Sep 88, Mailed 8 Oct 88

PROCLAIM-LEXICAL:LG                                             If it can
be implemented easily then I'm for it.  (I thought symbol-value got the
global value, not the dynamic one??)
        Version 9, 8-Dec-88, Mailed 12-Dec-88

RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER                           Yes
        Version 3, 9-Oct-88, Mailed 14-Oct-88

RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL       Yes
        Version 1, 14-Sep-88, Mailed 7 Oct 88

REQUIRE-PATHNAME-DEFAULTS:ELIMINATE                             Yes.
        Version 6, 9 Dec 88, mailed 09 Dec 88

REST-LIST-ALLOCATION:NEWLY-ALLOCATED
REST-LIST-ALLOCATION:MAY-SHARE                                  All three
stink.  No idea what to do.
REST-LIST-ALLOCATION:MUST-SHARE
        Version 3, 12-Dec-88, mailed 12-Dec-88

RETURN-VALUES-UNSPECIFIED:SPECIFY                               Yes
        Version 6,  9 Dec 88 mailed  9-Dec-88

ROOM-DEFAULT-ARGUMENT:NEW-VALUE                                 Abstain
        Version 1 12-Sep-88 mailed 8 Oct 88

[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS                           Much better
than before.  Inroducing (setf name) as names for functions is still ugly.
Questions such as what about macros??  Generalized function specs? etc.  I
would vote for it if nothing


 better comes along.
        Version 3, 4-Nov-87, mailed Nov 87
SETF-PLACES:ADD-SETF-FUNCTIONS                                  No, it
would require most code to have things like (flet
((#.(underlying-spec-to-name ..))) (defsetf...)) which is very gross.  It
would also be a very big portability issue, because implemen


tations with function specs would probably work without the defsetf, which
is fairly subtle.
        Version 1, 11-Nov-88, mailed 9-Dec-88

SETF-SUB-METHODS:DELAYED-ACCESS-STORES                          Yes
        Version 5, 12-Feb-88 mailed 8 Oct 88

STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS                Yes
        Version 8, 8 Jul 88, Mailed 7 Oct 88

STEP-ENVIRONMENT:CURRENT                                        Yes
        Version 3, 20-Jun-88, mailed  7 Oct 88

STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS                    Yes, order
of perferense stream-access:add-types-accessors, then
add-types-predicates-accessors, I'm not fond of add-predicates-accessors,
but not stronly opposed.
        version 2, 30-Nov-88 mailed  9 Dec 88
        (expect amendment T => "true")

STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS                           Yes, Prefer
ammendment.  Also, I believe that the specification of the "basic
properties" makes no mention of the fact that NIL can be returned by any of
the functions.  This somewhat implies


 that they are required to return non nil values, although I believe the
proposal permits them too.
        Version 6, 30-Nov-88, mailed 9 dec 88
        expect amendment:
                LINE-WIDTH   ==> STREAM-LINE-WIDTH
                LINE-POSITION ==> STREAM-LINE-POSITION
                PRINTED-WIDTH ==> STREAM-STRING-WIDTH

SUBTYPEP-TOO-VAGUE:CLARIFY                                      Yes
        Version 4,  7-Oct-88, mailed 7 Oct 88 

SYMBOL-MACROLET-DECLARE:ALLOW                                   Yes (check
-SEMANTICS)
        Version 2,  9-Dec-88, mailed 9 Dec 88

SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM                          Yes (need
to think about it more, complex issue)
        Version 5, 30-Nov-88, mailed 9 Dec 88

TAGBODY-CONTENTS:FORBID-EXTENSION                               Yes
        Version 5, 9-Dec-88 mailed 9 Dec 88

TAILP-NIL:T                                                     Yes
        Version 5, 9-Dec-88, mailed 12-Dec-88

TEST-NOT-IF-NOT:FLUSH-ALL                                       No/Abstain
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
        Version 3, 1 Dec 88 mailed 9 dec 

TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS                        Yes
        Version 3, 12-Dec-88, mailed 12 Dec 88
        (some "bugs" in the proposal)

UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW                          Yes
        Version 2, 2-Dec-88, mailed 12-Dec-88

VARIABLE-LIST-ASYMMETRY:SYMMETRIZE                              No/Abstain.
Error checking gained by disallowing (var) is more important to me than
symmetry.  If anything (var) should be disallowed in all forms.
        Version 3, 08-Oct-88, mailed 9 Dec 88



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

∂07-Jan-89  2153	CL-Cleanup-mailer 	Issue PATHNAME-PRINT-READ, v1  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Jan 89  21:53:40 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate id AA08743g; Sat, 7 Jan 89 21:49:30 PST
Received: by bhopal id AA05537g; Sat, 7 Jan 89 21:51:44 PST
Date: Sat, 7 Jan 89 21:51:44 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901080551.AA05537@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: IIM@ECLA.USC.EDU, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Wed, 4 Jan 89 18:47 EST <890104184739.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue PATHNAME-PRINT-READ, v1

re:  - I think #P is better than #. for the same reasons that Touretzky
     proposed #H instead of relying on #. . That is, because most Lisp
     data can be understood by engines considerably less complex than
     Lisp itself.  . . .

I don't think Touretzky was thinking along those lines when he made
the #H proposal.  Perhaps  you are remember pieces of the following
message, which was part of a lengthy discussion that took place on 
the Common-Lisp mailing list last summer.

-- JonL --



  Date: Fri, 24 Jun 88 16:56:00 PDT
  From: Jon L White <edsel!jonl@labrea.stanford.edu>
  To: cperdue@sun.com
  Cc: ELIOT@cs.umass.edu, Moon@stony-brook.scrc.symbolics.com,
	  common-lisp@sail.stanford.edu
  In-Reply-To: Cris Perdue's message of Fri, 17 Jun 88 10:16:38 PDT <8806171716.AA01554@clam.sun.com>
  Subject:  #.

  re: > 	(I don't count #.(make-hash-table...) because it's so gross.)
      . . .
      I would like to add my agreement to David Moon's statement.  With the
      #. readmacro you don't have to learn extra syntax to understand the
      printed representation, and it is nothing if not adequately general.

  Let's just say that it is "nothing".  The problem with #. is precisely that 
  it is not syntax; rather, it is an "out" where the designers of the language 
  failed to come up with a syntax.  To see this more clearly, consider writing 
  a trivial C program to read in "simple" Lisp expressions into equivalent data
  structures of the C world.  Parsing is no real problem [maybe could even 
  be yacc'd away], INTERNing of symbols is just a table lookup, numbers is 
  numbers [hey, even C can do fixnums and floats!], defstructs can be structs,
  strings are strings, and so on; cons cells etc. can be cut out of mallocated 
  space, and pointer-type variables make it easly to link things together.

  But there is no reasonable equivalent for the #. requirements -- no matter 
  how trivial the data-type returned, it implies the existence of a Lisp 
  EVALuator just to parse-&-build the representation.  That's a LOT to require 
  for merely constructing up some simple data structures.

  Thus while #. could be viewed as an adequate escape mechanism, it certainly
  couldn't be part of a general interchange language.

  And yet the hard problems are not limited to the "interchange" cases.  
  Consider file-processors other than LOAD or COMPILE-FILE (such as the 
  cross-reference program described by Tom Gruber in the first issue of
  Lisp Pointers).  Such a processor will want to READ a file of Lisp code, 
  but not necessarily evaluate anything in it.  How will it react to the 
  file [named, say "/u/loser/trojan-horse.lisp"]:

     (defun gift-horse (x)
	#.(progn (punch-paper-tape)
		 (delete-all-user-files)
		 (logout)
		 'x))


  -- JonL --

∂07-Jan-89  2212	CL-Cleanup-mailer 	Re: Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jan 89  22:12:23 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 07 JAN 89 22:04:43 PST
Date: 7 Jan 89 22:04 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TYPE-OF-UNDERCONSTRAINED (Version 3)
In-reply-to: your message of 12 Dec 88 16:00 PST
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890107-220443-2934@Xerox>

On p. 317, CLtL gives an example

(defstruct (binop (:type list))
	(operator '? :type symbol)
	operand-1
	operand-2)

and says in the running text ...


"... and TYPE-OF will return LIST when given a BINOP structure."

I guess if the example survives in the standard it should be fixed.... I
don't see a compelling reason why

(TYPE-OF '(A B C)) should be LIST instead of CONS, do you?



∂07-Jan-89  2223	CL-Cleanup-mailer 	Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Jan 89  22:23:24 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate id AA08764g; Sat, 7 Jan 89 22:18:57 PST
Received: by bhopal id AA05601g; Sat, 7 Jan 89 22:21:13 PST
Date: Sat, 7 Jan 89 22:21:13 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901080621.AA05601@bhopal>
To: masinter.pa@Xerox.COM
Cc: Gray@DSG.csc.ti.com, KMP@STONY-BROOK.SCRC.Symbolics.COM,
        CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 6 Jan 89 14:02 PST <890106-140422-1103@Xerox>
Subject: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)

re: I fail to see the necessity of correlating the behavior of backquote with
    the behavior of APPEND, since we've not ever specified that backquote ...

See CLtL, pages 350-51.

-- JonL --

∂07-Jan-89  2235	CL-Cleanup-mailer 	Issue: DEFSTRUCT-REDEFINITION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Jan 89  22:34:58 PST
Received: from Semillon.ms by ArpaGateway.ms ; 07 JAN 89 22:30:18 PST
Date: 7 Jan 89 22:29 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFSTRUCT-REDEFINITION (Version 2)
Message-ID: <890107-223018-2952@Xerox>

I've not known exactly what to do with this issue even though I said I
would tackle it. This proposal a fairly arbitrary choice of the options we
could consider, but it is most consistent with my experience of trying to
make DEFSTRUCT efficient. 

!
Status; **DRAFT**
Issue:          DEFSTRUCT-REDEFINITION
References:     DEFSTRUCT (CLtL pp 305-320)
Related-issues: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
Category:       CLARIFICATION
Edit history:   Version 1 by Skona Brittain 07/26/88
		Version 2 by Larry Masinter  7-Jan-89

Problem Description:

The case of a structure type being redefined is not discussed in CLtL. Is
it legal to redefine a DEFSTRUCT? What happens to DEFSTRUCTS that :INCLUDE
the one defined. What things might be "wired in" in compiled code that
refered to the previous DEFSTRUCT?

Proposal: (DEFSTRUCT-REDEFINITION:ERROR):

Redefining a DEFSTRUCT structure is not portable. The results of doing so
are not specified in the standard. 

Rationale:

DEFSTRUCT is intended as "the most efficient" structure class. DEFCLASS
allows much more flexible structures to be defined. Thus, implementations
should be free to "wire in" much of the behavior of a DEFSTRUCT into
compiled code.

The issue of redefinition should be addressed since there are always
consequences that affect use of the structures.

Current Practice:

None of KCL, Lucid, & Symbolics detect a redefinition.

Envos Medley goes to some effort to detect if a new structure is
"compatible" with the old -- e.g., slots might change names, initial
values, but, since the space allocated in an instance is determined by the
:TYPE, an incompatible set of :TYPE forms would cause old instances to be
marked "obsolete". (The TYPE-OF an old instance changes to **OBSOLETE**,
for example.)

Cost to Implementors:

This proposal attempts to be consistent with current practice.

Cost to Users:

It is doubtful that any current programs actually define structures more
than once. Thus, constraints on DEFSTRUCT redefinition primarily affect the
debugging environment.

Cost of Non-Adoption:

Confusion.

Benefits:

Clarity.

Aethetics:

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

Discussion: 

Common implementation techniques may cause the following behavior if a
DEFSTRUCT is redefined:

If the new DEFSTRUCT is identical to the old DEFSTRUCT except for the
initialization forms for slots,  previous structure objects probably can
continue to be accessed with previously compiled slot accessors. DEFSTRUCT
constructor, test functions are proclaimed INLINE, and if these have
changed, previously compiled occurrences of them may behave unpredictably.

If any change is made to the definiton of the slots (either in number,
name, or :TYPE), attempting to execute a slot accessor of the old
definition may behave unpredictably: if a slot name of the old definition
also names a slot of the new definition, any "compiled" code might use the
old definition instead. 
 
DEFSTRUCT constructor, test functions may also be proclaimed INLINE, and
may behave unpredictably if previously compiled. In particular, a compiled
occurance of a constructor might have the previously slot initial values
"wired in".

If the new DEFSTRUCT differs from the old in any aspect other than the
initialization forms for slots, the results of attempting to access any old
instance might result in unspecified behavior. For example, if the size of
the structure became considerably shorter, an old accessor might "access
off the end" of an instance of a new object; it might signal an error or
have other unpredictable results.

Masinter supports this proposal.  If users want more flexibility than
DEFSTRUCT allows, they should use DEFCLASS.

Some felt strongly that  just saying it's an error to redefine a structure
but not requiring the error to be signalled will cause users to be confused
by the differing seemingly erratic behavior and code. 

Programming environments are allowed, encouraged, etc. to allow such
redefinition, perhaps with warning messages. It is beyond the scope of the
language standard to define those interactions, except to note that they
are not portable. 

Here's an example where reexecuting an EQUAL DEFSTRUCT might result in
different behavior:

(defvar *token-counter* 0)
(defstruct token (cookie '("unique-string")) (counter (incf
*token-counter*)))

(defvar *first-token* (make-token))

(eql (token-cookie *first-token*) (token-cookie (make-token))) => true

(defstruct token (cookie '("unique-string")) (counter (incf
*token-counter*)))
 
(eql (token-cookie *first-token*) (token-cookie (make-token))) => false

I.e., even though the second DEFSTRUCT is EQUAL to the first, the
structures are not EQL.

This is related to the compiler issue QUOTE-MAY-COPY, but is not the same
issue, since that proposal isn't proposing that QUOTE might copy its value
*every time* it is executed.

∂08-Jan-89  0035	CL-Cleanup-mailer 	Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89  00:35:24 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 00:31:43 PST
Date: 8 Jan 89 00:31 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Sat, 7 Jan 89
 22:21:13 PST
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, Gray@DSG.csc.ti.com,
 KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890108-003143-3022@Xerox>

I must have missed a tense there somewhere. 

Let me try to say it a different way:

The meta-rules for backquote were derived "after the fact" as a way to
explain what backquote did; the use of APPEND and the equivalences there
were based on the old semantics of APPEND. Now that we've extended APPEND,
we have to change the meta-rules of backquote, but not the way that
backquote really works in most implementations.

I think the simplest way to "fix" the proposal is to change the second
meta-rule about nil to be

`(x1 x2 x3 ... xn . nil) may be interpreted to mean

(append [x1] [x2] [x3] ... [xn])

-- rather than reducing it to a previous case.

This implies that `(x1 x2 ... . ,form) as in the third meta-rule has the
same interpretation as `(x1 x2 ... ,@form).

This requires fixing the example, so that 

`((,a b) ,c ,@d)

will be interpreted as

(append (list (append (list a) (list 'b))) (list c) d)

As far as I can tell, this is consistent with the way that Lucid Common
Lisp's backquote works anyway.

To: '((,a b) ,c ,@d)

Lucid 3.0 says:
(bq-list* (bq-cons a '(b)) c d)

ibuki 01/01 says
(list* (list a 'b) c d)

Franz says:
(list* (cons a '(b)) c d)

Medley says:
(il:bquote (((il:\\\, a) b) (il:\\\, c) (il:\\\,@d)))

which macroexpand to 
(LIST* (CONS A (QUOTE (B))) C D)

Somebody borrowed my Mac so I can't try Coral or Procyon, and none of the
local Symbolics machines will let me remote login; but it looks like
*nobody* really tries to APPEND the last structure ever, anyway.





∂08-Jan-89  0113	CL-Cleanup-mailer 	Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 3)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89  01:13:41 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 01:07:13 PST
Date: 8 Jan 89 01:06 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
line-fold: NO
cc: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 3)
Message-ID: <890108-010713-3036@Xerox>

I shouldn't work on these things late at night....

The discussion from Kim Barrett mentioned "supplied-p" arguments.
I tried to think of uses of supplied-p arguments, and I thought
they were most useful in helping with some of the other
initialization variables. So must supplied-p arguments name
slots? If not, are arguments allowed which don't name slots
but are only used in the computation of &AUX or other 
&OPTIONAL or &KEY defaults? I'm guessing so and propose
this amendment which enhances the proposal.

Let me know if you think this is a bad idea.

!
Forum:         Cleanup
Issue:         DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
References:    CLtL page 316
Category:      CHANGE
Edit history:  20-Sep-88, Version 1, Peck
               21-Sep-88, Version 2, Masinter, minor revisions
                8-Jan-89, Version 3, Masinter


Problem description:

Currently, DEFSTRUCT constructor functions can be either the default
constructor function, with *only* keyword arguments, or it can be a 
so-called "By Order of Arguments" constructor function with explicitly
*no* keyword arguments.  Other functions in Common Lisp allow a free
mix of required, optional, and keyword arguments. 

With the current restriction, it is necessary to hand code a function that
will accept optional and keyword arguments and parse the supplied-p
variables explicitly.  Even so, it is not obvious to the casual programmer
how to provide the same semantics as defstruct does with respect to default
values and the defstruct init-forms.

Proposal: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY

Allow &KEY keyword arguments in constructor forms of DEFSTRUCTs
and the &ALLOW-OTHER-KEYS token in addition to the &OPTIONAL,
&REST and &AUX arguments already allowed. Keyword arguments default
in a manner similar to that of &OPTIONAL arguments: if no default
is supplied in the lambda-list then the slot initform is used;
otherwise the slot is not initialized -- its initial value is
undefined.

If keyword arguments of the form ((key var) [default [svar]])
are specified, the "slot name" is matched with VAR (and not KEY).

Additional arguments that do not correspond to slot names but
are merely present to supply values used in subsequent initialization 
computations are allowed.


Examples:

It should be possible to write forms like this:

(defstruct (foo (:constructor CREATE-FOO (a &optional b (c 'sea)
					    &key (d 2)
					    &aux e (f 'eff))))
  (a 1) (b 2) (c 3) (d 4) (e 5) (f 6))

(create-foo 10) => #S(foo a 10 b 2 c sea d 2 e nil f eff)
(create-foo 10 'bee 'see :d 'dee) => #S(foo a 10 b bee c see d dee e nil f eff)

In the definition:
(defstruct (frob (:constructor create-frob
		(a &key (b 3 have-b) (c-token 'c) 
		        (c (list c-token (if have-b 7 2))))))
	a b c)

the c-token argument is used merely to supply a value used in the 
initialization of the c slot. The "supplied-p" arguments of
keyword arguments might be of this form.

Rationale:

This is a logical extension of the specification which makes some
programming easier.

Current practice:

Many implementations signal an error if given &KEY arguments or
arguments that are not slot names. The latest version of IIM Common 
Lisp allows &KEY arguments in this manner. Envos Medley
(Xerox Common Lisp) implements the proposal. 

Cost to Implementors:

The modifications to allow intermixed keywords and optionals in implementations
that don't already are likely simple. 

Cost to Users:

No cost, this is upward compatible.

Cost of non-adoption:

The current situation is non-intuitive and needless restrictive.

Benefits:

Much easier for users to write the constructor function they want.
Probably implementation code would be reduced, since this would no 
longer be an error.

Esthetics:

Minor improvement since it removes a needless restriction.

Discussion:

Possibly  references to "By-position", "positional", and "By Order of
Arguments" constructor function might need to be changed to something else in
the standard.  (They can still be called BOA-constructors, though, right?  :-)

Version 2 of this proposal was on the January 1989 ballot.

∂08-Jan-89  0145	CL-Cleanup-mailer 	Re: Issue: DYNAMIC-EXTENT (Version 2)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89  01:45:38 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 01:37:33 PST
Date: 8 Jan 89 01:36 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DYNAMIC-EXTENT (Version 2)
In-reply-to: Eric Benson <eb@lucid.com>'s message of Tue, 3 Jan 89 08:31:34
 pst
To: Eric Benson <eb@lucid.com>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890108-013733-3047@Xerox>

I like this too.

If we can have a new version of this, I think it will subsume
REST-ARGUMENT-EXTENT, WITH-DYNAMIC-EXTENT and STACK-LET.

I think all that's necessary is to insert David's words in a proposal. I'd
do it now but I'm falling asleep.  

∂08-Jan-89  0831	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jan 89  08:31:18 PST
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 517299; Sun 8-Jan-89 11:30:01 EST
Date: Sun, 8 Jan 89 11:29 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 2)
To: CL-Cleanup@Sail.Stanford.EDU
cc: DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM,
    Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
Supersedes: <19890106223654.4.CASSELS@GROUSE.SCRC.Symbolics.COM>
Message-ID: <19890108162936.5.CASSELS@GROUSE.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
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):

  Add a standard type specifier
   (REAL low high)
  which means
   (OR (RATIONAL low high) (FLOAT low high))

  As with other such type specifiers, define that if the low and high
  are omitted, the atomic specifier REAL may be used.

  Clarify that NUMBER is equivalent to (OR REAL COMPLEX).

  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.

∂08-Jan-89  1327	CL-Editorial-mailer 	conformance & extensions issues   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89  13:27:32 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 13:26:07 PST
Date: 8 Jan 89 13:25 PST
From: masinter.pa@Xerox.COM
Subject: conformance & extensions issues
To: cl-editorial@sail.stanford.edu, cl-cleanup@sail.stanford.edu 
reply-to: cl-editorial@sail.stanford.edu
Message-ID: <890108-132607-3283@Xerox>

These was in discussion on the common lisp mailing list, but it is relevant
to the conformance discussion, and probably should be split up into
separate issues. I've not the time to do so myself. There's some overlap
with a couple of cleanup issues but not much. I think these are not so much
"cleanup" issues since they have to deal with the broad policies of
conformance and extension rather than individual functions/variables, so
I'd think they should be discussed in the "editorial" forum rather than
cleanup -- unless there is strong objection.


Issue: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS
Problem:

Is it OK to define Common Lisp functions with extra optional or  keyword
parameters, with system dependent meanings?  

Proposal: EXTRA-OPTIONAL-KEYWORD-ARGUMENTS:NO-EXCEPT-AS-ALLOWED

No, except as explicitly allowed in the standard. Functions that may be
extended to take implementation-specific optional arguments are indicated
by an &REST IGNORE in their argument list. Functions that may be extended
to take additional keyword parameters are indicated by &ALLOW-OTHER-KEYS. 

It isn't required that implementations signal errors at all safety/speed
setting, but this is not legitimate/conformal behavior.

Rationale:
The goal is not to outlaw any current extensions currently offered by
implementors, but to make the range of extensions to functions defined in
the standard well documented in the standard.  Implementations that want to
extend functions that aren't explicitly allowed to be extended can instead
shadow them.

Issue: EXTRA-SYNTAX
Problem: is it OK to extend Common Lisp macros and special forms to take
additional syntax not specified?

Proposal:  EXTRA-SYNTAX:NO

It isn't allowed.

Issue: EXTRA-RETURN-VALUES
Problem: Is it OK to return extra values from Common Lisp functions?

Proposal: No, except where explicitly allowed. The reason is that
additional arguments are visible to otherwise portable programs. "For
instance, (multiple-value-call #'cons (floor x y)) looks portable, but it
will try to pass the wrong number of arguments to CONS if FLOOR returns an
extra value."

Issue: UNPSECIFIED-DATATYPES
Problem: Is it OK to define the behavior of functions on datatypes not
explicitly permitted in CLtL?  

Proposal: UNPSECIFIED-DATATYPES:NO-EXCEPT-AS-EXPLICITLY-ALLOWED

Example: It is currently not allowed for an implementation to define + as
operating on vectors.
 
Rationale: While the original intent of CL designers ws that
implementations be permitted to do these things, they get in the way of
portability when they're done, since it is nearly impossible to detect when
a program has used one of these features. It is simple to define a new
function 
acme-common-lisp:+ which has the behavior of the "portable" + plus all the
new whizzy features, too.


Issue: UNSOLICITED-MESSAGES
Problem: Is it legal for an implementation to produce unsolicited output,
e.g., GC notifications, autoload heralds, and progress messages from
COMPILE-FILE or LOAD?

Proposal: UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS

Unsolicited messages, such as GC notifications and autoload heralds, if
they are produced by an implementation, should not be directed to
*standard-output*, *error-output*. If an implementation produces them, they
may be produced on a stream that is not "shared" with any of the streams
that a user might redefine or redirect. (This really means that it is OK to
direct such notifications to *terminal-io* since a user may not redirect
*terminal-io*.)

Messages such as progress reports from LOAD and COMPILE are "solicited",
and are not covered by this issue. See issue COMPILE-AND-LOAD-VERBOSE.


Issue: MACRO-AS-FUNCTION
Problem: May implementations implement things documented as "macros" or
special forms be implemented as a function instead? PROG1 is the main
example, but there might be others.

Proposal: MACRO-AS-FUNCTION:YES

Things that are defined in CL as "macros" may have function definitions
instead if the semantics can be preserved. This is rare, perhaps only
restricted to

(defun prog1 (value &rest ignore) value)
(defun prog2 (value1 value2 &rest ignore) value2)

Rationale: 
There are few cases, and there doesn't seem to be a good reason to disallow
it. It doesn't seem to interfere with portability.


∂08-Jan-89  1341	CL-Cleanup-mailer 	Issue: ELIMINATE-FORCED-CONSING (Version 3)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89  13:41:09 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 13:37:33 PST
Date: 8 Jan 89 13:36 PST
From: masinter.pa@Xerox.COM
Subject: Issue: ELIMINATE-FORCED-CONSING (Version 3)
To: cl-cleanup@sail.stanford.edu
Message-ID: <890108-133733-3295@Xerox>

I have not heard back from Joe Ginder on this issue. Does anyone else want
to pursue this? Otherwise it will be dropped. (I personally would just as
well see it dropped at this time.)


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

Date: 12 Dec 88 10:08 PST
From: masinter.pa
Subject: Re: discussion of Moon's comments re: ELIMINATE-FORCED-CONSING
In-reply-to: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU's message of Tue, 6 Sep
 88 15:38:22 PDT
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.edu

Joe:

On 6 Sept 88 you said, in response to a critique from Moon. "I'll submit a
modified proposal for discussion."

There were some subsequent comments on the cl-cleanup mailing list, and
we've not heard back from you. The January 1989 meeting is fast
approaching; we don't have a new writeup on this issue to mail out in
advance; if we don't hear from you, we will not have a new version to bring
there either.

Please reply if you get this note (to cl-cleanup@sail.stanford.edu), about
your plans with respect to this issue.




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

∂08-Jan-89  1400	CL-Cleanup-mailer 	Re: Ballot 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89  13:59:53 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA28981; Sun, 8 Jan 89 14:01:41 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA05226; Sun, 8 Jan 89 13:58:21 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA11196; Sun, 8 Jan 89 13:59:27 PST
Date: Sun, 8 Jan 89 13:59:27 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901082159.AA11196@clam.sun.com>
To: masinter.pa@Xerox.COM
Subject: Re: Ballot
Cc: cl-cleanup@sail.stanford.edu

> The ballot incorrectly listed only one of three alternatives:
> 
> STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
> STREAM-ACCESS:ADD-TYPES-ACCESSORS
> STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
> 
> Do you prefer the marked 
> 
> Y	| STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS

After reading the proposal again, I favor all of the proposals.
I will guess that the types are not useful for performance purposes,
and based on this, I prefer STREAM-ACCESS:ADD-PREDICATES-ACCESSORS,
but do not really oppose any of the proposals.  I somewhat favor
having predicates even when the types exist, because the predicates
are usable with FUNCALL, APPLY, etc..

∂08-Jan-89  1405	CL-Cleanup-mailer 	Re: Ballot 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89  14:05:22 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA29037; Sun, 8 Jan 89 14:07:13 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA05255; Sun, 8 Jan 89 14:03:54 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA11210; Sun, 8 Jan 89 14:04:58 PST
Date: Sun, 8 Jan 89 14:04:58 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901082204.AA11210@clam.sun.com>
To: cl-cleanup@sail.stanford.edu
Subject: Re: Ballot

I voted conditionally in favor of STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS.

I wish to add another comment to my vote in favor.  This is a relatively
complex proposal, and I expect that some changes in details will
turn out to be desirable after there is experience with implementations.
X3J13 should expect to revisit this issue later to perfect the specification.

∂08-Jan-89  1416	CL-Cleanup-mailer 	Re:  Issue: LISP-SYMBOL-REDEFINITION (Version 5)   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89  14:16:09 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA29125; Sun, 8 Jan 89 14:17:57 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA05290; Sun, 8 Jan 89 14:14:36 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA11223; Sun, 8 Jan 89 14:15:42 PST
Date: Sun, 8 Jan 89 14:15:42 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901082215.AA11223@clam.sun.com>
To: masinter.pa@Xerox.COM
Subject: Re:  Issue: LISP-SYMBOL-REDEFINITION (Version 5)
Cc: cl-cleanup@sail.stanford.edu

> On your ballot, Sun commented "This appears to disallow too much." 
> 
> What things would you allow that are disallowed by this proposal?

Well, that *is* a fair question.

At minimum, it seems excessive to disallow application of TRACE
to functions in the LISP package.  I have worked on implementations
of TRACE, and I believe it can work on functions in the Lisp package.
If we don't wish to support TRACE on all functions in the Lisp package,
we could require TRACE to either work or to not establish tracing
of the function.

I'd prefer to permit redefinition of macros and functions in the
LISP package, though I know there are difficulties.  One would have
to admit that the compiler may treat any or all of these as inline,
assuming the built-in definitions, regardless of any user's redefinition.
Implementations must also be permitted to call any function in the LISP
package from any code whatsoever in the implementation.  Perhaps this
makes redefinition unsupportable.

∂08-Jan-89  1735	CL-Cleanup-mailer 	Issue MACRO-FUNCTION-ENVIRONMENT, Version 1   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jan 89  17:35:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 517316; Sun 8-Jan-89 15:28:30 EST
Date: Sun, 8 Jan 89 15:28 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue MACRO-FUNCTION-ENVIRONMENT, Version 1
To: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19890107172420.3.MLY@JACKIE-O.AI.MIT.EDU>
Message-ID: <19890108202804.7.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Sat, 7 Jan 89 12:24 EST
    From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>

	Date: Sat, 7 Jan 89 00:15 EST
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	[...]

	Since use of the compile-time environment for types should be quite rare,
	this was seen as much less of a burden than modifying existing functions
	to take new optional arguments.

    Not so.  Consider compiler optimisations of (MAKE-ARRAY # :ELEMENT-TYPE #)
    When I last wrote a CL type system I needed a mess of parallel
    COMPILER-SUBTYPEP and COMPILER-UPGRADE-ARRAY-ELEMEN-TYPE (and so forth)
    functions.  Using compilation-environment technology would have been far
    preferable.

    I give MAKE-ARRAY optimisation merely as an example -- I feel `user'
    code has the same sorts of needs.

Hmm, you're probably right.

∂08-Jan-89  1833	CL-Cleanup-mailer 	Issue: APPLYHOOK-ENVIRONMENT (Version 1) 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 8 Jan 89  18:33:44 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00178g; Sun, 8 Jan 89 18:29:43 PST
Received: by blacksox id AA00920g; Sun, 8 Jan 89 18:31:55 pst
Date: Sun, 8 Jan 89 18:31:55 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901090231.AA00920@blacksox>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 6 Jan 89 11:49 PST <890106-115058-253@Xerox>
Subject: Issue: APPLYHOOK-ENVIRONMENT (Version 1)

This applies also to functions bound to *APPLYHOOK*, i.e., under the
description of *APPLYHOOK* on p.322, the following

"The non-NIL value of *APPLYHOOK* should be a function that takes
three arguments, a function, a list of arguments and an
environment..."

should be changed to say

"The non-NIL value of *APPLYHOOK* should be a function that takes
two arguments, a function and a list of arguments..."

∂08-Jan-89  2251	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 6) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89  22:51:15 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 22:48:45 PST
Date: 8 Jan 89 22:47 PST
From: masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, jonl@lucid.com, IIM@ECLA.USC.EDU
line-fold: NO
Subject: Issue: EXIT-EXTENT (Version 6)
cc: masinter.pa@Xerox.COM
Message-ID: <890108-224845-3526@Xerox>

I'm hoping we can get this one voted on, at least to the 
intent. It is probably true that an exact definition of 
what we mean will be difficult to express without a formal 
semantics, but I think it is clear that -- by now -- we 
actually know what the proposals are trying to say, even
when more precision would be welcome. 

I've tried to shorten the issue writeup by removing some 
of the discussion of cases for which the semantics was not 
ambiguous while still defining terms. 

I am sick of this issue, even with only 331K bytes of
mail on it.

!
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

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--whether it is being "abandoned" because it is 
being passed over, or it is itself the target exit--ends as soon as 
the transfer of control is initiated. That is, the events (c) and (d) 
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.

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. 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, is error under MINIMAL
(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, is error under MINIMAL
(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 is an error under MINIMAL; 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, 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 'FOO ...) 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.

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

∂08-Jan-89  2334	CL-Cleanup-mailer 	Re: Issue FIXNUM-NON-PORTABLE, v4   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89  23:34:11 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 JAN 89 23:33:01 PST
Date: 8 Jan 89 23:31 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue FIXNUM-NON-PORTABLE, v4
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Sat, 31 Dec 88
 19:47:14 PST
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890108-233301-3546@Xerox>

The portable use of FIXNUMs that convinced me came from applications that
wanted to use, say, a list of fixnums instead of a bit vector or a bignum
as an efficient representation of an arbitrary length sequence of bits.
For such an application, the FIXNUM type is ideal: it is the largest
"efficient" set of integers, and any explicit ranged integer type specifier
would not have the right properties. 

I thought it was a legitimate portable use of the FIXNUM tpe. It is really
only a portable use of FIXNUM if FIXNUM is constrained to be a "reasonable"
size, however; e.g., it doesn't work if MOST-POSITIVE-FIXNUM is negative!

Constraining FIXNUM to be a reasonable size also makes other uses of FIXNUM
more legitimate. Perhaps we could make FIXNUM more useful if we required
MOST-POSITIVE-FIXNUM to be at least as big as ARRAY-DIMENSION-LIMIT or
CHAR-CODE-LIMIT or could be guaranteed to hold the largest "count" of
objects, e.g., that LENGTH always returns a FIXNUM. An alternative would be
to invent new types, e.g., 

(deftype array-dimension () `(integer 0 ,array-dimension-limit))

What should the name of "an integer big enough to count objects" be?

∂08-Jan-89  2357	CL-Cleanup-mailer 	Re: Issue: FORMAT-ROUNDING (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89  23:57:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 JAN 89 23:54:26 PST
Date: 8 Jan 89 23:53 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FORMAT-ROUNDING (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Mon, 14 Nov 88 15:12 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890108-235426-3563@Xerox>


My belief is that we've decided we don't like this issue as stated. Would
it be appropriate to require that IEEE-FLOATING-POINT on *features* implies
the round-to-nearest algorithm? 


∂08-Jan-89  2359	CL-Cleanup-mailer 	Re: Issue: FUNCTION-COERCE-TIME (Version 2)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Jan 89  23:59:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 08 JAN 89 23:58:44 PST
Date: 8 Jan 89 23:58 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-COERCE-TIME (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Thu, 13 Oct 88 17:03 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890108-235844-3572@Xerox>

Kent:

This one looks good for you to work on, if you're looking for priorities.
We released a draft at the last meeting, but couldn't get said what we
wanted. 

I'll try not to send too many "priorities" your way...


∂09-Jan-89  0013	CL-Cleanup-mailer 	Re: Issue GC-MESSAGES (Version 2)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  00:13:22 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 00:08:21 PST
Date: 9 Jan 89 00:07 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue GC-MESSAGES (Version 2) 
In-reply-to: Dan L. Pierson <pierson@mist.encore.com>'s message of Tue, 03
 Jan 89 13:53:40 EST
To: cl-cleanup@sail.stanford.edu
Message-ID: <890109-000821-3579@Xerox>

I sent a note to cl-editorial. I had a proposal for "unsolicited messages"
which is handles only those things like auto-load heralds and GC messages.
I think that LOAD and COMPILE progress notices are "solicited", at least by
LOAD. 

Maybe this just subsumes GC-MESSAGES or should be handled under this name?


Issue: UNSOLICITED-MESSAGES
Problem: Is it legal for an implementation to produce unsolicited output,
e.g., GC notifications, autoload heralds, and progress messages from
COMPILE-FILE or LOAD?

Proposal: UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS

Unsolicited messages, such as GC notifications and autoload heralds, if
they are produced by an implementation, should not be directed to
*standard-output*, *error-output*. If an implementation produces them, they
may be produced on a stream that is not "shared" with any of the streams
that a user might redefine or redirect. (This really means that it is OK to
direct such notifications to *terminal-io* since a user may not redirect
*terminal-io*.)

Messages such as progress reports from LOAD and COMPILE are "solicited",
and are not covered by this issue. See issue COMPILE-AND-LOAD-VERBOSE.

∂09-Jan-89  0644	CL-Cleanup-mailer 	Re: Issue FUNCTION-COMPOSITION 
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 9 Jan 89  06:44:18 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac16627; 9 Jan 89 8:57 EST
Received: from draper.com by RELAY.CS.NET id ae22894; 9 Jan 89 8:41 EST
Date: Mon, 9 Jan 89 08:02 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue FUNCTION-COMPOSITION
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525

I like KMP's suggestion of CONSTANTLY.

∂09-Jan-89  0644	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 1)  
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 9 Jan 89  06:44:30 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa16646; 9 Jan 89 8:57 EST
Received: from draper.com by RELAY.CS.NET id af22894; 9 Jan 89 8:41 EST
Date: Mon, 9 Jan 89 08:38 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: REAL-NUMBER-TYPE (version 1)
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525

Hold on.  How should the following be handled:
 (declare (type (real 3.1415926 71/7) x))
...or (typep x '(real 3.1415926 71/7))?
When the type determination is made, how is the coercion of x to be done?
Must x be coerced from rational to float, or from float to rational, in 
order to do the type check?  Should RATIONAL or RATIONALIZE be used?  ETc.,
etc., etc.

∂09-Jan-89  0933	CL-Cleanup-mailer 	Meeting in Hawaii    
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  09:33:25 PST
Received: from fafnir.think.com by Think.COM; Mon, 9 Jan 89 12:26:04 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 9 Jan 89 12:30:33 EST
Received: by verdi.think.com; Mon, 9 Jan 89 12:29:16 EST
Date: Mon, 9 Jan 89 12:29:16 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8901091729.AA21924@verdi.think.com>
To: masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 5 Jan 89 23:20 PST <890105-232040-193@Xerox>
Subject: Meeting in Hawaii

   Date: 5 Jan 89 23:20 PST
   From: masinter.pa@xerox.com

   OK:

   Enough people can come Sunday that we'll meet Sunday afternoon to
   decide/confirm what issues we will bring before the main X3J13 committee
   for voting in plenary.



I'll be there late Sunday afternoon.  I'll hunt up the room as
soon as I arrive from the airport.
--Guy

∂09-Jan-89  1020	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 1)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  10:19:56 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 10:15:58 PST
Date: 9 Jan 89 10:15 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: REAL-NUMBER-TYPE (version 1)
In-reply-to: "Steve Bacher (Batchman)" <SEB1525@draper.com>'s message of
 Mon, 9 Jan 89 08:38 EST
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890109-101558-4153@Xerox>

Surely it must use the same mechanism that <= and < do...

∂09-Jan-89  1059	CL-Cleanup-mailer 	Issues: REQUIRE-PATHNAME-DEFAULTS and LOAD-TRUENAME
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  10:59:38 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 10:54:31 PST
Date: 9 Jan 89 10:43 PST
From: masinter.pa@Xerox.COM
Subject: Issues: REQUIRE-PATHNAME-DEFAULTS and LOAD-TRUENAME
To: cl-cleanup@sail.stanford.edu
Message-ID: <890109-105431-4260@Xerox>

I had this stuff filed under the name LOAD-TRUENAME. But do they really
want to modify the default pathname for LOAD, or is it really REQUIRE? If
REQUIRE did have a default pathname, should it be the same as LOADs? 

Somehow I don't think we will get away from the issue of "default loading
behavior" merely by outlawing REQUIRE.


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

Date: Tue, 13 Dec 88 20:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Possible issue: LOAD-TRUENAME
To: Dave.Touretzky@cs.cmu.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Masinter.PA
In-Reply-To: <2131.598064664@DST.BOLTZ.CS.CMU.EDU>

I agree that the issue is one that comes up a lot. 

I think Genera offers a variable that lets you know what file is being
loaded.  It might hold the name of the source file in a binary file load,
I forget.

For CL, maybe a variable (or function) to give the truename of the file
being LOADed or a list of the truenames of all files being loaded (most
recent first). A variation on this facility for use in COMPILE-FILE would
be useful as well.

Would that level of functionality suffice?

[I'm leary about your suggestion of LOAD binding variables that people
 already assume LOAD doesn't bind. As to adding weird special-purpose
 keywords to LOAD, knowing the name of the file being loaded may be
 useful to other things besides LOAD, so I'd rather provide a more 
 general facility for getting at this information that would suffice for
 other uses.]

Masinter may tell me it's too late to consider this kind of change,
but especially since there's a recognition that REQUIRE and PROVIDE are
bankrupt, and since CLtL's pathname stuff doesn't address all the file
problems which commonly come up in portable programs, maybe I can sneak
this in under the umbrella of a number of other file- (ok, pathname-) 
related proposals we're about to hit X3J13 with if we come up with
something
sufficiently concrete and non-controversial in a hurry.

Some straw men:

 - Variables *LOAD-TRUENAME* and *COMPILE-FILE-TRUENAME* which hold the
   truename of the innermost file being loaded or compiled, respectively,
   during the dynamic invocation of LOAD and COMPILE-FILE.

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

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

Better names solicited, of course.


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

Sender: Common-Lisp-mailer%SAIL.Stanford:EDU:Xerox
Date: 14 Dec 88 08:45
From: MURRAY%cs.umass:EDU:Xerox
Subject: RE: load defaults
To: common-lisp%sail.stanford:EDU:Xerox

Return-Path: <Common-Lisp-mailer@SAIL.Stanford.EDU>
Redistributed: Xerox-Common-Lisp↑.x
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 14 DEC 88
08:45:49 PST
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU
with TCP; 14 Dec 88  08:13:15 PST
Received: from vax2.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
id AA02232; Wed, 14 Dec 88 11:14:26 est
Message-Id: <8812141614.AA02232@crash.cs.umass.edu>
Original-Date: Wed, 14 Dec 88 11:11 EST
X-Vms-To: IN%"common-lisp@sail.stanford.EDU"


> From: Dave.Touretzky@B.GP.CS.CMU.EDU
>I have a problem with the way Common Lisp says pathname defaults should be
> handled during load...

My initial reaction is that you should be using some sort of defsystem,
which gives you much more control over sets of files.
But maybe you're trying to run bare-bones.  

>1. Anybody know a *portable* trick I can use to get embedded calls to LOAD
>to use the parent file's pathname as a default?

There is no portable way to find out what pathname is currently being
loaded.  The portable way to get your desired behavior is simply to define
your own
load function that will bind *DEFAULT-PATHNAME-DEFAULTS* to the file it
is loading before it calls the real load.
   (defun default-load (input &rest args)
     (let ((*default-pathname-defaults* (merge-pathnames input)))
       (apply 'load *default-pathname-defaults* args)))

>2. How terrible would it be for LOAD to rebind *DEFAULT-PATHNAME-DEFAULTS*
?

Probably not too terrible, but it does create another instance of
a problem that some people have complained about.  By having LOAD bind
a special variable, it make it impossible to have the contents of a
file side-effect that variable after the load.  This is a current problem
with *package*.

>3. Alternatively, what would people think of adding a :PARENT-PATH keyword
>to LOAD.  With a value of T this keyword would mean "if this is an
embedded
>load, get default pathname information from the pathname of the parent
>file" ?

Surely you jest!


Kelly Murray




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

Sender: Common-Lisp-mailer%SAIL.Stanford:EDU:Xerox
Date: 14 Dec 88 10:21
From: cperdue%Sun:COM:Xerox
Subject: RE: load defaults
To: Dave.Touretzky%B.GP.CS.CMU:EDU:Xerox, MURRAY%cs.umass:EDU:Xerox,
common-lisp%sail.stanford:EDU:Xerox

GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
From: cperdue@Sun.COM (Cris Perdue)
To: Dave.Touretzky@B.GP.CS.CMU.EDU, MURRAY@cs.umass.EDU,
common-lisp@sail.stanford.EDU
Subject: RE: load defaults
Return-Path: <Common-Lisp-mailer@SAIL.Stanford.EDU>
Redistributed: Xerox-Common-Lisp↑.x
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 14 DEC 88
10:21:42 PST
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Dec 88  09:59:23
PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)	id AA28669; Wed, 14
Dec 88 09:59:57 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)	id AA27264; Wed,
14 Dec 88 09:56:35 PST
Received: by clam.sun.com (3.2/SMI-3.2)	id AA14360; Wed, 14 Dec 88 09:57:31
PST
Original-Date: Wed, 14 Dec 88 09:57:31 PST
Message-Id: <8812141757.AA14360@clam.sun.com>
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV

Some implementations of Common Lisp include a special variable
with a name like *source-pathname*, which is bound appropriately
by LOAD.  This supports what is commonly known as "source code
recording" and if added to Common Lisp would meet needs such
as Touretzky's.  We have found need for this at Sun and would
be happy to see such a thing in the language at some time.

				-Cris




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

Sender: Common-Lisp-mailer%SAIL.Stanford:EDU:Xerox
Date: 14 Dec 88 16:49
Reply-to: Dave.Touretzky%cs.cmu:EDU:Xerox
Subject: Re: load defaults
In-Reply-to: Your message of Wed, 14 Dec 88 11:11:00 -0500.
<8812141614.AA02232@crash.cs.umass.edu>
From: Dave.Touretzky%B.GP.CS.CMU:EDU:Xerox
To: common-lisp%sail.stanford:EDU:Xerox

Return-Path: <Common-Lisp-mailer@SAIL.Stanford.EDU>
Redistributed: Xerox-Common-Lisp↑.x
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 14 DEC 88
16:43:13 PST
Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Dec
88  16:19:18 PST
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 14 Dec 88
19:17:08 EST
Original-Date: Wed, 14 Dec 88 19:16:51 EST
Message-ID: <3154.598148211@DST.BOLTZ.CS.CMU.EDU>

> Date: Wed, 14 Dec 88 11:11 EST 
> From: MURRAY@cs.umass.EDU
>
>  There is no portable way to find out what pathname is currently being
>  loaded.  The portable way to get your desired behavior is simply to
>  define your own load function that will bind *DEFAULT-PATHNAME-DEFAULTS*
>  to the file it is loading before it calls the real load.
>     (defun default-load (input &rest args)
>       (let ((*default-pathname-defaults* (merge-pathnames input)))
>         (apply 'load *default-pathname-defaults* args)))

This is a nice idea, but it doesn't solve my problem.  The user would have
to type in the whole definition before he could use it to load the header
file I referred to.  I want to avoid inconveniencing the user; he should be
able to just start up a fresh Lisp, LOAD a single header file, and have
everything else happen automatically.

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.

-- Dave




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

Sender: Common-Lisp-mailer%SAIL.Stanford:EDU:Xerox
Date: 16 Dec 88 01:41
From: jonl%lucid:COM:Xerox
In-Reply-to: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Tue, 13 Dec 88
20:04:24 EST <2131.598064664@DST.BOLTZ.CS
Subject: file loading query
To: Dave.Touretzky%cs.cmu:EDU:Xerox
cc: common-lisp%sail.stanford:EDU:Xerox

GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV
From: Jon L White <jonl@lucid.com>
To: Dave.Touretzky@cs.cmu.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Tue, 13 Dec 88
20:04:24 EST <2131.598064664@DST.BOLTZ.CS.CMU.EDU>
Subject: file loading query
Return-Path: <Common-Lisp-mailer@SAIL.Stanford.EDU>
Redistributed: Xerox-Common-Lisp↑.x
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 16 DEC 88
01:41:40 PST
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Dec 88  01:22:59
PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id
AA00971g; Fri, 16 Dec 88 01:20:08 PST
Received: by bhopal id AA20998g; Fri, 16 Dec 88 01:22:08 PST
Original-Date: Fri, 16 Dec 88 01:22:08 PST
Message-Id: <8812160922.AA20998@bhopal>
GVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGVGV

re: 1. Anybody know a *portable* trick I can use to get embedded calls to
LOAD
    to use the parent file's pathname as a default?

I doubt that there's a portable trick.  Lucid Common Lisp supports an
extension as follows:
    (defvar *load-pathname* nil
      "During a load, this is bound to the pathname of the file being
loaded.")
and ocasionally it is used to find out what directory the currently
loading file is on, so that a related file can be loaded from the same
directory.


-- JonL --




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

∂09-Jan-89  1119	CL-Cleanup-mailer 	Re: Issue: EXIT-EXTENT (Version 6)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  11:18:53 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 11:06:54 PST
Date: 9 Jan 89 11:01 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXIT-EXTENT (Version 6)
In-reply-to: masinter.pa's message of 8 Jan 89 22:47 PST
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890109-110654-4306@Xerox>

I guess I want to add my personal feeling on this issue:

I'm willing to vote for MINIMAL on the grounds that, although it isn't the
cleanest semantics, it is consistent with the goal of allowing
high-performance implementations, and we have ample documentation that some
implementations benefit considerably by this; secondarily on the grounds
that MEDIUM would be a serious incompatibility for some implementations. I
wasn't willing to vote for MINIMAL on the grounds that MEDIUM couldn't be
described or understood, which is why I put effort into describing MEDIUM
even though I'm willing to vote for MINIMAL.

Maybe I wasted my time as far as the outcome is concerned, but I think
we'll have to defend the positions we take well into the future, that they
were well-considered and that decisions were made on technical grounds.




∂09-Jan-89  1125	CL-Cleanup-mailer 	re: Issue: EQUAL-STRUCTURE (Version 5)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  11:25:08 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JAN 89 11:20:39 PST
Date: 9 Jan 89 11:19 PST
From: masinter.pa@Xerox.COM
Subject: re: Issue: EQUAL-STRUCTURE (Version 5)
In-reply-to: your message of Sun, 8 Jan 89 15:48:41 PST
To: IIM%ECLA@ECLC.USC.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890109-112039-4344@Xerox>

You've uncovered an ambiguity in the spec for EQUALP that I
hadn't thought of before. I think your analysis points out that
EQUALP's description should mention HASH-TABLEs as a
 special case. There are three possibilities: (1) EQUALP uses EQ
on hash tables, (2) EQUALP descends hash tables, (3) it isn't
specified. If EQUALP were to descend hash tables, we'd have
to say how: I'd guess that you'd have to compare the set of
keys using the hash table test function, and then the values
corresponding to the keys using EQUALP. I like specified better
than unspecified, and EQ better than descending.

(For the rest of cl-cleanup, the relevant part of Kim's message
is...


Date: Sun, 8 Jan 89 15:48:41 PST
From: IIM%ECLA@ECLC.USC.EDU
Subject: re: Issue: EQUAL-STRUCTURE (Version 5)
To: masinter.pa
cc: IIM%ECLA@ECLC.USC.EDU
In-Reply-To: <890108-134500-3303@Xerox>


> Date: 8 Jan 89 13:44 PST
> From: masinter.pa@Xerox.COM
> 
> You're right. Can I talk you into helping draft a version that says what we
> mean? Kent and I are burned out on this issue, apparently. 
> 
> Preferably so we can have a version for voting on...
> Let me know one way or another asap.

Well, I'd like to help, but I have two serious problems.

First, I expect to have very little time to devote to X3J13 issues for the next
few weeks, other than attending the meeting and discussing things there, since
starting tomorrow I'm going to be embarking on a fairly major low-level change
in our implementation, the completion of which is on the critical path for the
completion of several other projects here.  I'm going to try to address as many
things as I can before I go home today (even if it means not leaving until
tomorrow) but after that I'm likely to be pretty unresponsive for a while.

Second, I'm really not certain myself what it is "we mean", much less what the
"right thing" is, so it's hard for me write it up.  The example problem I keep
having trouble with is hash-tables.  I can't think of any good reason why
EQUALP should specifically recognize them, yet I also think it has to.

Consider the following:
1. Given 2 EQ hash-tables H1 and H2
2. For some set of keys and associated values, install them in both H1 and H2,
   in the same order.
3. Invoke the garbage collector.  (I'm assuming that this will "invalidate" the
   hashing in the tables, requiring a rehash to occur on at least some
   operations.) 
4. Perform some operation on H1 which does not change the key mapping, but
   causes a rehash to occur due to the recent gc.

It is very likely that under a simple component-wise comparison, H1 and H2 are
now no longer equivelent.  Worse yet, I can readily construct situations in
multi-processing or interruptable environments in which a simple component-wise
comparison implementation of EQUALP will return false for (equalp x x), where x
is an eq hash-table.

So we have an existance proof of an ill-defined case.  I think you'll have a
hard time convincing me either that this is the only such case or that these
problems don't arise in "user code".  And it seems to me quite likely that the
set of problem cases will vary between implementations.  What do we do with
such things?  I'm afraid I don't have what I consider to be a good answer.  I
suppose we could punt by saying that EQUALP does component-wise comparisons
always, and add a caveat that this isn't necessarily useful or even "correct"
for some datatypes in some implementations.  I don't think we can say anything
about signaling errors in the bad cases, since if user-defined objects can have
these problems then there really isn't a way to detect when to signal.
Besides, I sort of dislike the idea of an equality predicate which signals
errors. 

kab
-------

∂09-Jan-89  1142	CL-Cleanup-mailer 	Re: Ballots, please  
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89  11:42:01 PST
Date: 9 Jan 1989 14:42-EST
Sender: ROSENKING@A.ISI.EDU
Subject: Re: Ballots, please
From: ROSENKING@A.ISI.EDU
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 9-Jan-89 14:42:06.ROSENKING>
In-Reply-To: <890106-002339-193@Xerox>


I expect to get my ballot in by late Tuesday (10 January).

∂09-Jan-89  1318	CL-Cleanup-mailer 	Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Jan 89  13:18:45 PST
Received: by ti.com id AA00427; Mon, 9 Jan 89 12:35:39 CST
Received: from Kelvin by tilde id AA05460; Mon, 9 Jan 89 12:26:31 CST
Message-Id: <2809362537-10236580@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 9 Jan 89  12:28:57 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Kim A. Barrett" <IIM@ECLA.USC.EDU>
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
In-Reply-To: Msg of Mon 2 Jan 89 17:31:11-PST from Kim A. Barrett <IIM@ECLA.USC.EDU>

> Proposal (SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT)
> 
>  Extend SUBTYPEP to accept an optional third argument.  This argument should be
>  either NIL, the &environment argument received by a macro expander function,
>  or the environment argument received by an *evalhook* or *applyhook* function.
>  This argument is used to distinguish between compile-time and run-time
>  environments. 

I don't see any point in mentioning *EVALHOOK* environments here since
there isn't any facility for local type declarations comparable to
MACROLET for local macros.

∂09-Jan-89  1320	CL-Cleanup-mailer 	Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1    
Received: from ti.com by SAIL.Stanford.EDU with TCP; 9 Jan 89  13:20:21 PST
Received: by ti.com id AA00423; Mon, 9 Jan 89 12:35:34 CST
Received: from Kelvin by tilde id AA05368; Mon, 9 Jan 89 12:20:25 CST
Message-Id: <2809362147-10213162@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 9 Jan 89  12:22:27 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Cc: "Kim A. Barrett" <IIM@ECLA.USC.EDU>, cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
In-Reply-To: Msg of Sat, 7 Jan 89 12:24 EST from Richard Mlynarik <Mly@AI.AI.MIT.EDU>

> Not so.  Consider compiler optimisations of (MAKE-ARRAY # :ELEMENT-TYPE #)
> When I last wrote a CL type system I needed a mess of parallel
> COMPILER-SUBTYPEP and COMPILER-UPGRADE-ARRAY-ELEMEN-TYPE (and so forth)
> functions.  Using compilation-environment technology would have been far
> preferable.
> 
> I give MAKE-ARRAY optimisation merely as an example -- I feel `user'
> code has the same sorts of needs.

On the Explorer, both TYPEP and SUBTYPEP already implicitly use the
compile-time environment when they are called from within COMPILE-FILE.
Consequently, uses of these in macro expanders will see type definitions
earlier in the same file without the macro writer needing to do anything
special, so this capability could be used a lot without anyone realizing
it.  I think it would be cleaner if these functions accepted optional
environment arguments, which default to the compilation environment when
within COMPILE-FILE.

∂09-Jan-89  1553	CL-Cleanup-mailer 	Re: Ballots, please  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jan 89  15:52:48 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa08549; 9 Jan 89 23:40 GMT
Date: Mon, 9 Jan 89 23:42:09 GMT
Message-Id: <12148.8901092342@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Ballots, please
To: cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com
In-Reply-To: masinter.pa@com.xerox's message of 6 Jan 89 00:23 PST

> 
> We've gotten very few ballots back. Please let us know soon if you plan to
> vote even if you can't get your ballot in right away; we'll need some time
> to respond to some of the comments and prepare new versions for the
> meeting!

I will try very hard to send mine tomorrow (but I mean after some
hours of sleep rather than after 20 minutes).

Cheers,
Jeff

∂09-Jan-89  1609	CL-Cleanup-mailer 	Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1    
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 9 Jan 89  16:09:00 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 257602; Mon 9-Jan-89 19:06:33 EST
Date: Mon, 9 Jan 89 19:06 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Re: Proposal SUBTYPEP-ENVIRONMENT:NEW-ARGUMENT, Version 1
To: Gray@DSG.csc.ti.com, Mly@AI.AI.MIT.EDU
cc: IIM@ECLA.USC.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <2809362147-10213162@Kelvin>
Message-ID: <19890110000602.8.GSB@GANG-GANG.SCRC.Symbolics.COM>

    Date: Mon, 9 Jan 89  12:22:27 CST
    From: David N Gray <Gray@DSG.csc.ti.com>

    > Not so.  Consider compiler optimisations of (MAKE-ARRAY # :ELEMENT-TYPE #)
    > When I last wrote a CL type system I needed a mess of parallel
    > COMPILER-SUBTYPEP and COMPILER-UPGRADE-ARRAY-ELEMEN-TYPE (and so forth)
    > functions.  Using compilation-environment technology would have been far
    > preferable.
    > 
    > I give MAKE-ARRAY optimisation merely as an example -- I feel `user'
    > code has the same sorts of needs.

    On the Explorer, both TYPEP and SUBTYPEP already implicitly use the
    compile-time environment when they are called from within COMPILE-FILE.
    Consequently, uses of these in macro expanders will see type definitions
    earlier in the same file without the macro writer needing to do anything
    special, so this capability could be used a lot without anyone realizing
    it.  I think it would be cleaner if these functions accepted optional
    environment arguments, which default to the compilation environment when
    within COMPILE-FILE.

The problem is defining "within" compile-file.  This is what the environment
argument determines.  A runtime call to make-array inside the guts of the
compiler (or other miscellaneous system code) which happens to be
unoptimized and calls subtypep should not be using type information from
the user's file.

∂09-Jan-89  1722	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 1)  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jan 89  17:21:30 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa00553; 10 Jan 89 1:14 GMT
Date: Tue, 10 Jan 89 01:16:52 GMT
Message-Id: <12503.8901100116@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: REAL-NUMBER-TYPE (version 1)
To: CL-Cleanup@sail.stanford.edu

I support this proposal.

One of the advantages of Scheme over Common Lisp is that it 
distinguishes between abstract numbers (real, complex, rational,
etc.) and representations (fixnum, ratio (well, that might be
both), etc.)  I think Common Lisp should try to do the same.

∂09-Jan-89  1728	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 2)  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 9 Jan 89  17:27:47 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa00610; 10 Jan 89 1:21 GMT
Date: Tue, 10 Jan 89 01:23:40 GMT
Message-Id: <12536.8901100123@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: REAL-NUMBER-TYPE (version 2)
To: CL-Cleanup@sail.stanford.edu

> 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.  [More about F and P.]

Scheme uses REAL to mean more or less what's being proposed for CL.

∂09-Jan-89  1822	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 2) 
Received: from WHITE.SWW.Symbolics.COM ([128.81.57.24]) by SAIL.Stanford.EDU with TCP; 9 Jan 89  18:21:47 PST
Received: from METAL-FLAKE.SWW.Symbolics.COM by WHITE.SWW.Symbolics.COM via CHAOS with CHAOS-MAIL id 229025; Mon 9-Jan-89 17:55:40 PST
Date: Mon, 9 Jan 89 17:57 PST
From: Marc Le Brun <MLB@WHITE.SWW.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 2)
To: Cassels@STONY-BROOK.SCRC.Symbolics.COM
cc: 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, rwg@WHITE.SWW.Symbolics.COM
In-Reply-To: <19890108162936.5.CASSELS@GROUSE.SCRC.Symbolics.COM>
Message-ID: <19890110015752.6.MLB@METAL-FLAKE.SWW.Symbolics.COM>

    Date: Sun, 8 Jan 89 11:29 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
    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):

I apologize for the size of this response, but since this is sort of a "dissenting opinion" I
felt it would be good to document the arguments as carefully as I could.

There are dangers in introducing the term REAL.  It encourages the widespread confusion
between a computer type, REAL, which of necessity denotes a countable class of symbols, with
the mathematical object (which I'll call R), which is non-denumerable.  This identification of
incommensurables has many unfortunate consequences, including ambiguous and inconsistent use
of "intuitive" models.  Further, members of these sets which are commonly identified with
eachother (ie real numbers and their computer images) often have incompatible semantics.

The original Common Lisp specification did the world a service by eliminating this source of
potential confusion.  If the term is to be reintroduced for pragmatic reasons, then it should
at least done very carefully, so as not to result in further propagation, even amplification,
of these problems.  It doesn't seem either responsible or forward-looking to gloss over these
difficult issues.

      Add a standard type specifier
       (REAL low high)
      which means
       (OR (RATIONAL low high) (FLOAT low high))

The Discussion section below implies that future extensions should be considered here.

Suppose an implementation introduces new types which model members of R but which do not
satisfy this predicate.  (For example, quadratic fields, or symbols denoting rational
multiples of (mathematical) pi, say).  Is the implementation allowed to extend the type REAL
or not?  I'd vote to allow extension, but in any case this should be stated.  (Further, must
it so extend it?)

      As with other such type specifiers, define that if the low and high
      are omitted, the atomic specifier REAL may be used.

      Clarify that NUMBER is equivalent to (OR REAL COMPLEX).

Suppose an implementation introduces new types which could considered numeric but which do not
satisfy this predicate.  (For example, quaternions, as mentioned in the Discussion).  Is the
implementation allowed to extend the type NUMBER or not?  I'd vote to allow extension, but in
any case this should be stated.  (Further, must it so extend it?)

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

No.  

1. As noted above R contains many "useful" elements (eg surds, mathematical pi or e) which can
have discrete symbolic representations but whose behavior is not accurately modeled by any
REAL element.

2. Under many circumstances the semantics of "typical" elements of REAL are quite distinct
from the elements of R with which they are commonly identified, leading to a variety of
situational interpretations as "intervals", "fuzzy numbers", etc which clearly do not belong
to the theory of R.

3. Conversely operations on elements of R conform to a semantics of "infinite precision"
obviously unattainable by REALs.

4. REAL also may contain specific entities (such as -0.0) not in R.

5. Because of finite range limitations REAL further does not consistently "cover" R.
Sometimes this is dealt with as an error, sometimes with the introduction of non-analytic
semantics (eg setting underflows to zero), sometimes by introducing non-standard entities
partially or wholly outside R (eg the various "infinities", or the IEEE "Not-A-Number"s which
(at least in Symbolics CL) paradoxically satisfy NUMBERP!).

6. Since there is no "floating canonicalization", the type REAL contains multiple distinct
images of certain elements of R (notably zero, many rationals, and many flonums which exist in
more than one so-called "precision").

      This class is important because it is all the numbers which can be ordered.

Agreed that the ordering property of R is important.  It might be possible to have CL so
define REAL specifically as some kind of maximal well-ordered set (though this might be
tricky, in order to exclude characters as potential numbers, for example).

(And, mathematically anyway, one might even ask for more rigor regarding the term "ordered",
considering, for example, Conway numbers.  This would be a gratuitous comment except for IEEE
having already opened the Pandora's box of non-standard numbers.)

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

Presumably this is to be read as a proposal to substitute "real" for "non-complex number"?
Note that these restrictions are apparently motivated by different properties: in some cases
ordering, in others an aversion to imaginary algebra (eg the mystifying restrictions on CIS,
COMPLEX et al).  Depending on the extension policy adopted that substitution might or might
not retain its validity under an extension (eg symbols for rational multiples of mathematical
pi aren't (OR RATIONAL FLOAT) but might be an acceptable, indeed useful, subdomain for CIS).

    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.

Arguable.

      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]

As noted above, the policy regarding possible extensions, either as future CL standards or
per-implementation, should be clarified in several respects.

      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.

This needs clarification.  If by "equivalent Fortran program" is meant a FORTRAN program that
was specifically (heroically?) written to carefully model a CL program, then this begs the
question.  If it means "a naive translation" between languages, then this is far from obvious
(eg a CL implementation might generate rationals, thereby maintain different information
through subsequent operations, and finally get results diverging significantly from the
FORTRAN program).

One could also easily imagine some careful conventional flonum-based numerical analysis being
thrown off by the introduction of a non-zero rational smaller than CL "epsilon", for example.
The assignation of "more accurate" is application-dependent and implementation-dependent.

      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.

Agreed, the proposed type is an extension of what's commonly meant by the name REAL.
(Although there exist unusual systems where REALs are implemented by decimal rationals!)
While the "average programmer" may be comfortable, the differences between CL REALs and
conventional REALs and their implications should be carefully and thoroughly documented in the
standard (leaving aside the quagmire of confusion with regards to R).

∂09-Jan-89  1913	CL-Cleanup-mailer 	Re: Issue: OUTPUT-STREAM-P-EXAMPLE  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  19:13:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 15:42:08 PST
Date: 9 Jan 89 15:35 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: OUTPUT-STREAM-P-EXAMPLE
In-reply-to: ROSENKING@A.ISI.EDU's message of 26 Oct 88 16:48 EDT
To: ROSENKING@A.ISI.EDU
cc: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <890109-154208-4993@Xerox>

I wish I had a better justification for saying (output-stream-p
(make-concatenated-stream) ) should return NIL.

I think part of it is lack of a theory of what OUTPUT-STREAM-P really
means.

∂09-Jan-89  1914	CL-Cleanup-mailer 	Issue: SETF-SUB-METHODS (Version 5) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  19:13:42 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 18:18:40 PST
Date: 9 Jan 89 18:16 PST
From: masinter.pa@Xerox.COM
Subject: Issue: SETF-SUB-METHODS (Version 5)
To: cperdue@Sun.COM (Cris Perdue)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890109-181840-5085@Xerox>

In your ballot, you said: 

This does not seem to be the "right" choice of semantics, and I
believe that the presentation of the proposal needs substantial work
even if it is "right".

Can you help us? in what way is it wrong? what might be better? what
cases are unclear that we need to clarify?

∂09-Jan-89  1913	CL-Cleanup-mailer 	re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  19:13:29 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 17:25:29 PST
Date: 9 Jan 89 17:24 PST
From: masinter.pa@Xerox.COM
Subject: re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 3)
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of 2 Jan 89 15:23
 PST
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890109-172529-5043@Xerox>

Kim:

The proposal only implies that PEEK-CHAR is no longer equivalent to
READ-CHAR followed by UNREAD-CHAR when the stream in question is stream
created by MAKE-ECHO-STREAM. Certainly for any other stream, a string
stream, and any other stream that doesn't have ECHO behavior, PEEK-CHAR
could be implemented by READ-CHAR followed by UNREAD-CHAR. It probably
implies that synonym streams should "pass on" the PEEK-CHAR operation, and
that concatenated streams should also do so, but I'd be suprised if many
implementations didn't already do that.

This proposal does *not* necessarily affect what *TERMINAL-IO* does; only
with streams created by MAKE-ECHO-STREAM. 

FYI, hardcopy & online versions have the typo "echos" fixed. Are there
others?

∂09-Jan-89  1913	CL-Cleanup-mailer 	Re: Issue: REST-LIST-ALLOCATION (Version 3)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  19:13:36 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JAN 89 17:53:34 PST
Date: 9 Jan 89 17:52 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: REST-LIST-ALLOCATION (Version 3)
In-reply-to: gz@spt.entity.com (Gail Zacharias)'s message of 5 Jan 89
 18:06:05 EST (Thu)
To: gz@spt.entity.com (Gail Zacharias)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890109-175334-5056@Xerox>

My reading of CLtL is that no setting of the OPTIMIZE/SAFETY setting
requires checking for invalid arguments to CADR.

The only thing that SAFETY 0 does is allow you to turn off some of the
error checking that CLtL requires you normally to enforce.


∂09-Jan-89  1943	CL-Cleanup-mailer 	Re: Issue: TAGBODY-CONTENTS (Version 5)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  19:43:03 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 19:41:00 PST
Date: 9 Jan 89 19:40 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TAGBODY-CONTENTS (Version 5)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Tue, 3 Jan 89 00:25 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <890109-194100-5316@Xerox>

I wrote up this proposal in the current form, but I've had some second
thoughts as I'm trying to deal the ballot comments. 

I've forgotten the reasons for allowing other types of objects in TAGBODY
bodies. I still like the part about duplicate elements was the part about
duplication, viz: duplicates are OK if there's no GO.

Walter's objections were not included in the proposal writeup, I've
discovered:

"I strongly disagree with the version 4 change to allow duplicate
tags as long as there is no GO to them.  If one really wants to be
able to use NIL as a statement because of the way many people write
macros, then let's change the proposal to treat NIL as a statement,
and not as a tag.  And the rationale about using symbols as dividers
in code sounds pretty weak to me--that what comments are for.

I never saw version 3 of the proposal, but it sounds more like what
I'd find reasonable, judging by the change history.

			---Walter

"


I guess we can talk about this next week. I'm just saying I've probably
changed my mind -- not that this is an important issue.

∂09-Jan-89  1952	CL-Cleanup-mailer 	Re: Ballots, please  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  19:52:28 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 19:51:21 PST
Date: 9 Jan 89 19:50 PST
From: masinter.pa@Xerox.COM
Subject: Re: Ballots, please
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
 message of Mon, 9 Jan 89 23:42:09 GMT
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
Message-ID: <890109-195121-5331@Xerox>

>>Message<<

∂09-Jan-89  1956	CL-Cleanup-mailer 	Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Jan 89  19:56:40 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01625g; Mon, 9 Jan 89 19:51:50 PST
Received: by bhopal id AA11931g; Mon, 9 Jan 89 19:54:06 PST
Date: Mon, 9 Jan 89 19:54:06 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901100354.AA11931@bhopal>
To: masinter.pa@Xerox.COM
Cc: Gray@DSG.csc.ti.com, KMP@STONY-BROOK.SCRC.Symbolics.COM,
        CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 8 Jan 89 00:31 PST <890108-003143-3022@Xerox>
Subject: Issue: BACKQUOTE-COMMA-ATSIGN-DOT-COMMA (Version 1)

re: The meta-rules for backquote were derived "after the fact" as a way to
    explain what backquote did; the use of APPEND and the equivalences there
    were based on the old semantics of APPEND. Now that we've extended APPEND,
    we have to change the meta-rules of backquote, . . . 

Your assumption here can't be true -- The MacLisp implementation (and
others) carried out the now-debased optimization; yet the meta-rules
stand.  I'm very leery of changing these meta rules unless QUUX signs
off on it -- every time I've been tempted to dicker with them, I find
out that they are much deeper than a cursory glanch would suspect.  [I
thought Guy devised those "meta" rules -- if he didn't then the author
ought to be consulted.]


re: This requires fixing the example, so that 
     `((,a b) ,c ,@d)
    will be interpreted as
      (append (list (append (list a) (list 'b))) (list c) d)
    As far as I can tell, this is consistent with the way that Lucid Common
    Lisp's backquote works anyway.

But that's precisely what Greenwald reported as a bug!  As I explained
in previous mail, Lucid has the bug because when the decision to
reaffirm the "new" semantics for APPEND was made, no one noticed (or
cared about?)  the implications for backquote.

I think it would be putting the cart before the horse to try to 
institutionalize the now-debased optimization into the semantics of
backquote, as a way around the bug.  The advantage of not performing
this optimization is that the user need never be confused as to whether
or not ",@" will copy its argument, or share; currently a user can't be
sure because of the permitted ambiguity.

Note that Guy himself also acknowledged the validity of Greenwald's
complaint -- he claims that the _examples_ are invalid rather than
the rules.  Your proposal is just the opposite -- to keep the examples
valid and alter the rules to contain the essence of the "optimization".

    Date: Tue, 29 Nov 88 17:12:40 EST
    From: gls@Think.COM
    To: Greenwald@stony-brook.scrc.symbolics.com
    Cc: gls@Think.COM, Greenwald@stony-brook.scrc.symbolics.com,
	    common-lisp@sail.stanford.edu
    In-Reply-To: Michael Greenwald's message of Tue, 29 Nov 88 14:05 EST <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
    Subject: inconsistency in backquote spec?
    . . . 
    Because you sent the mail out to common-lisp@sail and not to
    any of the X3J13 mailing lists, I assumed that you were asking
    a question about the language as defined solely by the book.
    In other words, I assume that the audience for the common-lisp
    mailing list has not necessarily followed all of the X3J13 work.
    It is true that eventual adoption of this cleanup item [APPEND-DOTTED?]
    would invalidate the examples.

    --Guy


Guy,  wanna comment?


-- JonL --

∂09-Jan-89  2142	CL-Cleanup-mailer 	Issue: FORMAT-ROUNDING (Version 1)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Jan 89  21:42:17 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01686g; Mon, 9 Jan 89 21:37:44 PST
Received: by bhopal id AA12145g; Mon, 9 Jan 89 21:40:00 PST
Date: Mon, 9 Jan 89 21:40:00 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901100540.AA12145@bhopal>
To: masinter.pa@Xerox.COM
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 8 Jan 89 23:53 PST <890108-235426-3563@Xerox>
Subject: Issue: FORMAT-ROUNDING (Version 1)

re: My belief is that we've decided we don't like this issue as stated. Would
    it be appropriate to require that IEEE-FLOATING-POINT on *features* implies
    the round-to-nearest algorithm? 

"round-to-nearest" isn't sufficient; it should be "IEEE round-to-nearest",
which has implications for "ties".

However, both Moon and I seemed to prefer not trying to specify something 
in the standard for the case this issue is addressing.


-- JonL --

∂09-Jan-89  2203	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 5)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 9 Jan 89  22:03:35 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01692g; Mon, 9 Jan 89 21:59:21 PST
Received: by bhopal id AA12192g; Mon, 9 Jan 89 22:01:37 PST
Date: Mon, 9 Jan 89 22:01:37 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901100601.AA12192@bhopal>
To: masinter.pa@Xerox.COM
Cc: IIM%ECLA@ECLC.USC.EDU, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 9 Jan 89 11:19 PST <890109-112039-4344@Xerox>
Subject: Issue: EQUAL-STRUCTURE (Version 5)

Some months back, John Rose made a suggestion that two hashtables should
only be considered "equivalent" (for constant coalescing purposes) if
there are equal on a component-by-component basis; _and_ where component
indexing is by the set of hash-table keys.  Several people (including
myself) supported this view, even though it makes descent into hash
tables a bit more complex than descent into simpler structures.

-- JonL --

∂09-Jan-89  2230	CL-Cleanup-mailer 	ballot
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 9 Jan 89  22:30:41 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA00602@EDDIE.MIT.EDU>; Tue, 10 Jan 89 01:28:10 EST
Received: by spt.entity.com (smail2.5); 9 Jan 89 22:54:47 EST (Mon)
To: cl-cleanup@sail.stanford.edu
Subject: ballot
Message-Id: <8901092254.AA08704@spt.entity.com>
Date: 9 Jan 89 22:54:47 EST (Mon)
From: gz@spt.entity.com (Gail Zacharias)

This ballot is the official position of Apple Computer.

"Yes if" means we won't vote for the proposal unless a condition is satisfied.
"Yes" with a comment means we'd like to see a change, but will vote for it
anyway.

Yes	ARGUMENTS-UNDERSPECIFIED:SPECIFY
	Version 4, 21-Sep-88, Mailed 4 Dec 88

Yes if	ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
	Version 9, 31-Oct-88, Mailed 5 Dec 88
Flush the UPGRADED-xxx functions.

Yes	CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
	Version 5,  5-Dec-88, Mailed 5 Dec 88
Would prefer to specify a value for CLOSE on closed streams.  What's the
point of leaving it undefined?

Yes	CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
	Version 1, 14-Sep-88, Mailed 6 Oct 88

No	DECLARE-TYPE-FREE:ALLOW
	Version 8, 7-Dec-88, Mailed 9-Dec-88
We'll probably support the LEXICAL option (not on the ballot).

Yes	DECLARATION-SCOPE:NO-HOISTING
No	DECLARATION-SCOPE:LIMITED-HOISTING
	Version 4, 15-Nov-88, Mailed 9-Dec-88

Yes	DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
	Version 4,  5-Dec-88, Mailed  5-Dec-88

A	DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
	Version 2, 30-Sep-88, Mailed 6 Oct 88

Yes	DEFPACKAGE:ADDITION
	Version 7, 2-Nov-88, Mailed 5 Dec 88

Yes if	DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
	Version 4, 31-Oct-88, Mailed 12-Dec-88
The proposal should state that the constraint applies only to the
arguments to the DEFSTRUCT macro.  It does not constrain the STRUCTURE-CLASS
metaclass to require all slots to have STRING/= names.

Yes	DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
	Version 2, 21-Sep-88, Mailed 6 Oct 88
Needs to specify whether the keyword or variable name is the slot name.

Yes	DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
	Version 3, 7 Dec 88, Mailed 12-Dec-88

A	DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
A	DESCRIBE-INTERACTIVE:NO
	Version 4, 15-Nov-88	, Mailed 7-Dec-88

No	DOTTED-MACRO-FORMS:ALLOW
	Version 3, 15-Nov-88, Mailed 7-Dec-88

A	EQUAL-STRUCTURE:STATUS-QUO
	Version 5, 1-Oct-88, Mailed 8 Oct 88

No	EXIT-EXTENT:MINIMAL
Yes	EXIT-EXTENT:MEDIUM
	Version 5, 12-Dec-88, Mailed 12-Dec-88

Yes	EXPT-RATIO:P.211
	Version 3, 31-Oct-88, Mailed 7 Dec 88

Yes if	FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
Yes	FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
	Version 4, 7-Dec-88, Mailed 12-Dec-88
We'll support TIGHTEN-DEFINITION iff TIGHTEN-FIXNUM-TOSS-BIGNUM fails.

A	FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
	Version 2, 2 Oct 88, Mailed 6 Oct 88

Yes	FORMAT-PRETTY-PRINT:YES
	Version 7, 15 Dec 88, Mailed 7 Dec 88

A	FUNCTION-COMPOSITION:NEW-FUNCTIONS
Yes if	FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
	Version 4, 12 Dec 88, Mailed 12 Dec 88
If ALWAYS is renamed to CONSTANT or CONSTANTLY.

A	FUNCTION-DEFINITION:FUNCTION-SOURCE
	Version 2, 09-Dec-88	, Mailed 9 Dec 88

Yes	FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
	Version 3, 7-Dec-88, Mailed  12-Dec-88

No	FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
	Version 5, 14-Nov-88	, Mailed 8-Dec-88

No	HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
	Version 7, 8-Dec-88, Mailed 9-Dec-88
Should be functions.

C	HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
	Version 1, 11-Nov-88	, Mailed 12 Dec 88
As best we can tell, all this proposal says is that it is an error to 
destructively modify elements of equal hash tables but ok to do so for eq
hash tables.  We would support a simpler proposal stating this.

Yes	HASH-TABLE-TESTS:ADD-EQUALP
	Version 2, 8-Dec-88, Mailed 8 Dec 88

Yes	IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
	Version 4, 12-Dec-88, Mailed 12-Dec-88

Yes	LAMBDA-FORM:NEW-MACRO
	Version 4, 22-Nov-88, Mailed 8-Dec-88
New special form would be even better.

Yes	LCM-NO-ARGUMENTS:1
	Version 1, 17 Oct 88, Mailed 8 Dec 88

Yes	GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
	Version 2, 8 Dec 88, Mailed 8 Dec 88

Yes	LISP-SYMBOL-REDEFINITION:DISALLOW
	Version 5, 22-Nov-88, Mailed 8 Dec 88

No	MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
	Version 2, 8 Oct 88, Mailed 12-Dec-88

Yes	MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
	Version 2, 09-Jun-88, Mailed 8 Oct 88

Yes	NTH-VALUE:ADD
	Version 4, 8-Dec-88, Mailed 8 Dec 88
Clarify that NIL should be returned when index is larger than number of values

Yes	PACKAGE-CLUTTER:REDUCE
	Version 6, 12-Dec-88, Mailed 12-Dec-881

Yes if	PACKAGE-DELETION:NEW-FUNCTION
	Version 5, 21 nov 88, Mailed 8 Dec 88
Remove the description of "correctable" error to be signalled and handled.
This sort of detailed error protocol is not specified for any other function
and is not appropriate here.

Yes	PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
	Version 1 27-Jun-88, Mailed 7 Oct 88

Yes	PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
	Version 3, 8-Oct-88, Mailed 8 Oct 88

Yes	PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
	Version 3, 20 Sep 88, Mailed 8 Oct 88

No	PROCLAIM-LEXICAL:LG
	Version 9, 8-Dec-88, Mailed 12-Dec-88

Yes	RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
	Version 3, 9-Oct-88, Mailed 14-Oct-88

Yes	RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
	Version 1, 14-Sep-88, Mailed 7 Oct 88
NIL should be allowed for start, allowing it for some arguments (count,
end) and not others (start) is too obscure.

Yes	REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
	Version 6, 9 Dec 88, mailed 09 Dec 88

Yes	REST-LIST-ALLOCATION:NEWLY-ALLOCATED
No	REST-LIST-ALLOCATION:MAY-SHARE
No	REST-LIST-ALLOCATION:MUST-SHARE
	Version 3, 12-Dec-88, mailed 12-Dec-88

Yes	RETURN-VALUES-UNSPECIFIED:SPECIFY
	Version 6,  9 Dec 88 mailed  9-Dec-88

No	ROOM-DEFAULT-ARGUMENT:NEW-VALUE
	Version 1 12-Sep-88 mailed 8 Oct 88

    [The following are mutually exclusive]
No	SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
	Version 3, 4-Nov-87, mailed Nov 87
No	SETF-PLACES:ADD-SETF-FUNCTIONS
	Version 1, 11-Nov-88, mailed 9-Dec-88

Yes	SETF-SUB-METHODS:DELAYED-ACCESS-STORES
	Version 5, 12-Feb-88 mailed 8 Oct 88

Yes	STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
	Version 8, 8 Jul 88, Mailed 7 Oct 88

Yes	STEP-ENVIRONMENT:CURRENT
	Version 3, 20-Jun-88, mailed  7 Oct 88

Yes if	STREAM-ACCESS:ADD-TYPES-ACCESSORS
No	STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
No	STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
	version 2, 30-Nov-88 mailed  9 Dec 88
    	(expect amendment T => "true")
The following paragraph from the description of OPEN-STREAM-P may
be misleading:
   Streams are "open" until they have been closed with CLOSE, or, the
   dynamic context of the creating/accessing macros of WITH-OUTPUT-TO-STRING,
   WITH-OPEN-FILE, WITH-INPUT-FROM-STRING, WITH-OPEN-STREAM, have been
   exited.
This may be taken to imply that the stream still exists (as a closed stream)
even after the dynamic extent of the WITH-xxx form is exited.  Because these
stream objects have dynamic extent, they cannot be referenced in any way once
the WITH-xxx form exits.  (They can't even be passed to OPEN-STREAM-P.) As a
practical example, the streams could be stack-consed, and future use could
cause crashes.  The reference to exited WITH-xxx forms should be deleted, or
explanatory text should be added.

No	STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
	Version 6, 30-Nov-88, mailed 9 dec 88
    	expect amendment:
    		LINE-WIDTH   ==> STREAM-LINE-WIDTH
    		LINE-POSITION ==> STREAM-LINE-POSITION
    		PRINTED-WIDTH ==> STREAM-STRING-WIDTH
Our opposition is based on the following points:
1) The defining property of WRITE-SPACE (that it must write exactly the number
of units given) is too restrictive.  For example it may not be possible to
write whitespace to a stream in units smaller than a #\space character, if the
stream is associated with a (multi-font) ascii file or editor buffer (since
there may be no ascii character available that can be inserted in the
file/buffer to represent the whitespace).  An implementation cannot simply
make the unit size equal to the width of a #\space character, because a
subsequent increase in font-size would again make the unit smaller than a
current #\space character.

2) The "additional properties" of PRINTED-WIDTH (i.e. 8 and 9, stating that
printed-widths are additive) are incompatible with some non-Roman scripts. For
example, in the Arabic language the glyphs used for characters are dependent
on the surrounding characters: in our Arabic implementation of Object Logo,
editing causes surrounding characters to change shape (and width) according to
their new context.  The restrictions on PRINTED-WIDTH would make it difficult
to similarly incorporate the context-sensitive character portrayal features of
the Macintosh into our Common Lisp implementation.

3) In general we feel that the proposal is premature, given the current state
of i/o standards.  We would prefer to wait for a complete solution (i.e. a
real graphics standard and extended characters set standard).  We feel that
the current proposal is too specific and problematical for a proper place in
Common Lisp.  For now, the desired features are probably best obtained via
implementation-specific functions.

Yes	SUBTYPEP-TOO-VAGUE:CLARIFY
	Version 4,  7-Oct-88, mailed 7 Oct 88 

Yes	SYMBOL-MACROLET-DECLARE:ALLOW
	Version 2,  9-Dec-88, mailed 9 Dec 88

Yes	SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
	Version 5, 30-Nov-88, mailed 9 Dec 88

Yes if	TAGBODY-CONTENTS:FORBID-EXTENSION
	Version 5, 9-Dec-88 mailed 9 Dec 88
We support forbidding extensions, but oppose allowing duplicate and
unreachable tags.  Instead we would prefer clarifying that () is a form
and not a valid tag.

Yes	TAILP-NIL:T
	Version 5, 9-Dec-88, mailed 12-Dec-88

Yes	TEST-NOT-IF-NOT:FLUSH-ALL
Yes	TEST-NOT-IF-NOT:FLUSH-TEST-NOT
	Version 3, 1 Dec 88 mailed 9 dec 

Yes	TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
	Version 3, 12-Dec-88, mailed 12 Dec 88
    	(some "bugs" in the proposal)

Yes	UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
	Version 2, 2-Dec-88, mailed 12-Dec-88

Yes	VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
	Version 3, 08-Oct-88, mailed 9 Dec 88

∂09-Jan-89  2233	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 5)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  22:33:07 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 22:30:56 PST
Date: 9 Jan 89 22:30 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EQUAL-STRUCTURE (Version 5)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Mon, 9 Jan 89
 22:01:37 PST
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, IIM%ECLA@ECLC.USC.EDU,
 cl-cleanup@sail.stanford.edu
Message-ID: <890109-223056-5490@Xerox>

What is current practice in this area? What does EQUALP do in current
implementations on hash tables?

I'd wouldn't want to make everybody extend EQUALP where nobody does it.


∂09-Jan-89  2238	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  22:38:31 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 09 JAN 89 22:37:25 PST
Date: 9 Jan 89 22:36 PST
From: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 4)
To: alarson@src.honeywell.com (Aaron Larson)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890109-223725-5504@Xerox>


Re: "Confused, why string= on the names.  Does that mean that foo:a and
bar:a cannot both be slots in the same structure?  (check where accessors
are interned)."

Yes, DUPLICATES-ERROR means that you cannot have FOO:A and BAR:A both a
slot in the same DEFSTRUCT structure.

I think this is an implication of the wording there and no amendement is
needed, but will add this clarification if there is disagreement.



∂09-Jan-89  2335	CL-Cleanup-mailer 	[chapman%aitg.DEC@decwrl.dec.com: vote]  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  23:35:48 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 23:34:40 PST
Date: 9 Jan 89 23:33 PST
From: masinter.pa@Xerox.COM
Subject: [chapman%aitg.DEC@decwrl.dec.com: vote]
To: cl-cleanup@sail.stanford.edu
Message-ID: <890109-233440-5555@Xerox>



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

From: chapman%aitg.DEC@decwrl.dec.com
Date: 9 Jan 89 10:22
To: masinter.pa
Subject: vote

Larry, I thought I sent these to you, so if it's a repeat, just
discard. 

Also, I grouped these issues loosely (but I didn't check them after
I grouped them, so some issues could be misplaced). I thought that
voting in alphabetic order was very painful and we didn't give enough
time to some issues just because of their position in the alphabet.

These votes don't represent the vote of DEC. Also, I gave more thought
to the no votes than to the yes ones.
kc



Single function change:						My vote:

DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION		y
DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE                      y
DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY                     y
DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES                        y
DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR               y
DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE                           y
DESCRIBE-INTERACTIVE:NO                                         n
EQUAL-STRUCTURE:STATUS-QUO                                      y
EXPT-RATIO:P.211                                                y
FORMAT-E-EXPONENT-SIGN:FORCE-SIGN                               y
FORMAT-PRETTY-PRINT:YES                                         y
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY                            y
LCM-NO-ARGUMENTS:1                                              y
MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT               y
PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN                              y
PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR                        y
PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK                      y
ROOM-DEFAULT-ARGUMENT:NEW-VALUE                                 y
SYMBOL-MACROLET-DECLARE:ALLOW                                   y
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM                          y(1)
TAGBODY-CONTENTS:FORBID-EXTENSION                               y(1)
TAILP-NIL:T                                                     y
STEP-ENVIRONMENT:CURRENT                                        y
TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS                        n
UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW                          y

Documentation clarification:

FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION                          y
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM                  n
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS                 n
LISP-SYMBOL-REDEFINITION:DISALLOW                               y
STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS                y
SUBTYPEP-TOO-VAGUE:CLARIFY                                      y

New functions:

DEFPACKAGE:ADDITION                                             y
FUNCTION-COMPOSITION:NEW-FUNCTIONS                              n
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS                      n
HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER                  n
LAMBDA-FORM:NEW-MACRO                                           y
NTH-VALUE:ADD                                                   n
PACKAGE-DELETION:NEW-FUNCTION                                   n
STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS                    y(2)
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS                           n

Multiple function change:

ARGUMENTS-UNDERSPECIFIED:SPECIFY                                y
CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY                          y
GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD                      y
RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER                           y
RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL       y
REQUIRE-PATHNAME-DEFAULTS:ELIMINATE                             n(3)
RETURN-VALUES-UNSPECIFIED:SPECIFY                               y
TEST-NOT-IF-NOT:FLUSH-ALL                                       n(3)
TEST-NOT-IF-NOT:FLUSH-TEST-NOT                                  n(3)

Concept change:

ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING               y
CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE                   y
DECLARATION-SCOPE:NO-HOISTING                                   n
DECLARATION-SCOPE:LIMITED-HOISTING                              y
DECLARE-TYPE-FREE:ALLOW                                         y
DOTTED-MACRO-FORMS:ALLOW                                        y
EXIT-EXTENT:MINIMAL                                             n
EXIT-EXTENT:MEDIUM                                              n
FUNCTION-DEFINITION:FUNCTION-SOURCE                             y
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE               y
FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE        n
HASH-TABLE-TESTS:ADD-EQUALP                                     y
MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE                y
PACKAGE-CLUTTER:REDUCE                                          y
PROCLAIM-LEXICAL:LG                                             y
REST-LIST-ALLOCATION:NEWLY-ALLOCATED                            n
REST-LIST-ALLOCATION:MAY-SHARE                                  n
REST-LIST-ALLOCATION:MUST-SHARE                                 n
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS                           y
SETF-PLACES:ADD-SETF-FUNCTIONS                                  n
SETF-SUB-METHODS:DELAYED-ACCESS-STORES                          y
VARIABLE-LIST-ASYMMETRY:SYMMETRIZE                              y


(1) Need more clarification
(2) Two changes to proposal
(3) Should deprecate, not delete


New since last meeting:

GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
	Version 2, 8 Dec 88, Mailed 8 Dec 88
 
HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
	Version 1, 11-Nov-88	, Mailed 12 Dec 88

LCM-NO-ARGUMENTS:1
	Version 1, 17 Oct 88, Mailed 8 Dec 88
 
REST-LIST-ALLOCATION:NEWLY-ALLOCATED
REST-LIST-ALLOCATION:MAY-SHARE
REST-LIST-ALLOCATION:MUST-SHARE
	Version 3, 12-Dec-88, mailed 12-Dec-88
 
SETF-PLACES:ADD-SETF-FUNCTIONS
	Version 1, 11-Nov-88, mailed 9-Dec-88

TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
	Version 3, 12-Dec-88, mailed 12 Dec 88
	(some "bugs" in the proposal)
 


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

∂09-Jan-89  2341	CL-Cleanup-mailer 	Re: revised ISO discussion, revised DRAFT Gegenda and Subcommittee
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Jan 89  23:41:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 09 JAN 89 23:40:26 PST
Date: 9 Jan 89 23:39 PST
From: masinter.pa@Xerox.COM
Subject: Re: revised ISO discussion, revised DRAFT Gegenda and Subcommittee
 meetings
In-reply-to: Jan Zubkoff <jlz@lucid.com>'s message of Mon, 9 Jan 89
 12:55:22 PST
To: Jan Zubkoff <jlz@lucid.com>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890109-234026-5560@Xerox>

We'll need a meeting room on Sunday-- late afternoon & evening.  Will there
be a conference table and overhead projector? (You say "Guest Room 120"). 

The cleanup subcommittee meeting in DC was pretty big, but I've sofar only
heard from about 5 people this time.


∂10-Jan-89  0022	CL-Cleanup-mailer 	Issue: STREAM-ACCESS (Version 2)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89  00:22:01 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 00:20:54 PST
Date: 10 Jan 89 00:20 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: STREAM-ACCESS (Version 2)
To: cl-cleanup@sail.stanford.edu
From: gz@spt.entity.com (Gail Zacharias)
Message-ID: <890110-002054-5595@Xerox>

The following paragraph from the description of OPEN-STREAM-P may
be misleading:
   Streams are "open" until they have been closed with CLOSE, or, the
   dynamic context of the creating/accessing macros of WITH-OUTPUT-TO-STRING,
   WITH-OPEN-FILE, WITH-INPUT-FROM-STRING, WITH-OPEN-STREAM, have been
   exited.
This may be taken to imply that the stream still exists (as a closed stream)
even after the dynamic extent of the WITH-xxx form is exited.  Because these
stream objects have dynamic extent, they cannot be referenced in any way once
the WITH-xxx form exits.  (They can't even be passed to OPEN-STREAM-P.) As a
practical example, the streams could be stack-consed, and future use could
cause crashes.  The reference to exited WITH-xxx forms should be deleted, or
explanatory text should be added.

∂10-Jan-89  0024	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 6) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89  00:23:57 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 00:22:51 PST
Date: 10 Jan 89 00:22 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: STREAM-INFO (Version 6)
To: cl-cleanup@sail.stanford.edu
From: gz@spt.entity.com (Gail Zacharias)
Message-ID: <890110-002251-5597@Xerox>

Our opposition is based on the following points:
1) The defining property of WRITE-SPACE (that it must write exactly the number
of units given) is too restrictive.  For example it may not be possible to
write whitespace to a stream in units smaller than a #\space character, if the
stream is associated with a (multi-font) ascii file or editor buffer (since
there may be no ascii character available that can be inserted in the
file/buffer to represent the whitespace).  An implementation cannot simply
make the unit size equal to the width of a #\space character, because a
subsequent increase in font-size would again make the unit smaller than a
current #\space character.

2) The "additional properties" of PRINTED-WIDTH (i.e. 8 and 9, stating that
printed-widths are additive) are incompatible with some non-Roman scripts. For
example, in the Arabic language the glyphs used for characters are dependent
on the surrounding characters: in our Arabic implementation of Object Logo,
editing causes surrounding characters to change shape (and width) according to
their new context.  The restrictions on PRINTED-WIDTH would make it difficult
to similarly incorporate the context-sensitive character portrayal features of
the Macintosh into our Common Lisp implementation.

3) In general we feel that the proposal is premature, given the current state
of i/o standards.  We would prefer to wait for a complete solution (i.e. a
real graphics standard and extended characters set standard).  We feel that
the current proposal is too specific and problematical for a proper place in
Common Lisp.  For now, the desired features are probably best obtained via
implementation-specific functions.

∂10-Jan-89  0039	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 1)  
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 10 Jan 89  00:39:28 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab02627; 10 Jan 89 0:57 EST
Received: from draper.com by RELAY.CS.NET id ac29577; 10 Jan 89 0:44 EST
Date: Tue, 10 Jan 89 00:16 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: REAL-NUMBER-TYPE (version 1)
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525

re: Surely it must use the same mechanism that <= and < do...
  
OK, but is this really appropriate for type checking?

∂10-Jan-89  0039	CL-Cleanup-mailer 	Revised draft issue status
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89  00:39:32 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 00:38:20 PST
Date: 10 Jan 89 00:37 PST
From: masinter.pa@Xerox.COM
Subject: Revised draft issue status
To: cl-cleanup@sail.stanford.edu
Message-ID: <890110-003820-5607@Xerox>

There are a number of people/organizations that have indicated that they
have yet to send in their votes, so the "tally" isn't final.

While it would be asking too much to have final drafts of all cleanup
issues by next Monday, I'm hoping to print out, and bring copies of, the
Ready for release issues, and the expected amendments. So: if you can spare
some time, some new drafts of issues would help a lot. 

I'll start the final alphabetical order pass tomorrow morning.

- - - - file arisia:cl-cleanup/issue-status

Voters:
1 David N Gray (TI)
2 Kim A. Barrett (IIM)
3 David Bartley (TI)
4 Sandra J Loosemore (Utah)
5 David Moon (Symbolics)
6 Dan Pierson (Encore)
7 Chris Perdue (Sun)
8 Aaron Larson (Honeywell)
9 Kathy Chapman (DEC)
10 Gail Zacharias (Apple)

In some cases I have changed a vote from Y to "I" (conditional) if the
comments said "Only if...." In a couple of cases I changed an "Abstain" to
"Conditional" where the associated comment indicated that as the intent.

ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 3, 2-Dec-88
Comments: reword to avoid "Status Quo" debate?
Status: needs new version

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

APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 1, 6-Jan-89
Comments: Fix *APPLYHOOK* too
Status: needs revision

ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Vote: 1y2y3y4y5y6y7y8y9y10y SPECIFY
Status: block vote

ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Vote: 1y3y4y5y*6y7y8y9y10i UNIFY-UPGRADING
Comments: 10: if remove UPGRADED-ARRAY-ELEMENT-TYPE and
UPGRADED-COMPLEX-PART-TYPE?
Status: vote separate with amendment

BACKQUOTE-COMMA-ATSIGN-DOT
Synopsis:  `(... ,@x) vs `(... . ,x). Same, or different?
Version 1, 22-Dec-88
Comments: Two proposals. Connection w/APPEND-DOTTED? 
Status: needs new version

CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, Released 5 Dec 88
Vote: 1y3y4y5y6y7y8y9y10y
Comments: 10: Would prefer to specify a value for CLOSE on closed streams.
What's the
point of leaving it undefined?
Status: block vote
α∂
CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 1, 6-Jan-89
Comments: Too many proposals, not all there.

COERCE-INCOMPLETE
Synopsis: Extend COERCE to handle default coercions? take an optional
FROM-TYPE?
Version 2, 21-Nov-88
Status: needs new version

COMPILE-AND-LOAD-VERBOSITY
Synopsis: how much typeout when :VERBOSE given to COMPILE and LOAD
Comment: is there an issue?
Status: not submitted?

COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88
Status: ready for release?

CONSTANT-SIDE-EFFECT
Synopsis: It is an error to do destructive operations on constants in code,
defconstant.
Version: not submitted
Status: => CONSTANT-MODIFICATION (compiler committee)

CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Vote: 1n2y3n4y5y6y7y8y9y10y TRANSITIVE
Status: block vote

DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Vote: 1n2n3n4y5n6y7i8y9n10y NO-HOISTING
Vote: 1y2n3y4n5y6i7y8i9y10n LIMITED-HOISTING
Comments: NO-HOISTING is too incompatible...could live with
LIMITED-HOISTING,
    but unconvinced of the need for incompatible change.  All problem
examples
    easily solved by changing some variable names
 6,8: support LIMITED-HOISTING if NO-HOISTING fails.
    Either is better than nothing.
 7: NO-HOISTING if cases hoisted by 2nd alternatives are treated as errors
and
    LIMITED-HOISTING fails
Status: separate vote

DECLARE-FUNCTION-AMBIGUITY
Version 4,  5-Dec-88, Released  5-Dec-88
Vote: 1n3y4y5y*6y7y8y9y10y DELETE-FTYPE-ABBREVIATION
Comments:
  5: Moon is mildly opposed; gratuitously incompatible. Pitman favors 
     because benefit of making things regular outweighs costs
Status: block vote

DECLARE-TYPE-FREE
Version 8, 7-Dec-88, Released 9-Dec-88
Vote: 1a3y4y5n*6n7y8y9y10n ALLOW
Version 9, 2-Jan-89, Released 6-Jan-89
Comments: cleanup members voted
     5,10: DECLARE-TYPE-FREE:LEXICAL(9, unreleased) Yes.
     6: Y       Version 9, ALLOW
        N       Version 9, LEXICAL
Status: separate voting on Version 9

DECLARE-TYPE-USER-DEFINED
Synopsis: allow (declare ((signed-byte 8) x y z)) for all type specifiers?
Status: Not submitted

DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Vote: 1y3y4a5y6y7y8i9y10a LIKE-ENCODE
Status: block vote

DEFINITION-DELETE
Synopsis: provide a way to get rid of structures, etc. 
Status: not submitted

DEFMACRO-BODY-LEXICAL-ENVIRONMENT
Synopsis: Allow DEFMACRO at non-top-level to capture environment.
Status: not submitted to cleanup; in compiler committee

DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Vote: 1y3y4y5y*6y7i8y9y10y ADDITION
Comments:  Spell out "at variance"; define semantics in terms of existing
	package functions. Mail 6-Jan-89
 7: If we allow time for more experimental usage of this before adopting it
 8:  believe that "should signal an error" should be "will signal an error"
Status: separate vote

DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
Synopsis: defstruct accessors are proclaimed inline
Version 2,  7-Jan-89
Status: ready for release? 

DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 2, 21-Sep-88, Released 6 Oct 88
Vote: 1y2i3y4y5y6y7i8y9y10y ALLOW-KEY
Comments: 7: If the proposal is fixed as suggested by Kim Barrett
Version 3, 8-Jan-88
Status: ready for release?

DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Vote: 1y2y3y4y5y6y7y8y9y10y YES
Status: block vote

DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 2, 7-Jan-89
Status: ready for release??

DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 4, 31-Oct-88, Released 12-Dec-88
Vote: 1y2y3y4y5y6y7y8c9y10i DUPLICATES-ERROR
Comment: 8 Why string= on the names.  Does that mean that foo:a and bar:a
cannot both be slots in the same structure?  (check where accessors are
interned).
	10: only DEFSTRUCT macro, not STRUCTURE-CLASS.
Status: vote separate

DELETE-FILE-NONEXISTENT 
Version 1, 5-Oct-88
Comments: should just signal different errors?
Status: awaiting new version

DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Vote: 1n2a3n4n5y6n7n8a9y10a EXPLICITLY-VAGUE
Vote: 1y2y3y4y5i6y7y8y9n10a NO
Comments: 5: "Yes" for the NO option iff EXPLICITLY-VAGUE fails.
Status: separate vote

DOTTED-MACRO-FORMS
Vote: 1y2y3y4y5y6y7y8y9y10n ALLOW
Version 3, 15-Nov-88, Released 7-Dec-88
Status: block vote

DYNAMIC-EXTENT
Version 2, 15-Nov-88
Comments: Mail from Moon 2-Jan-89 outlines good solution 
Status: need new proposal writeup

ELIMINATE-FORCED-CONSING
Synopsis: Add :RECYCLE or :MODIFY keyword arguments to sequence,
	list & string functions where such arguments are useful.
Version 3, 31-Aug-88
Status: Need volunteer to pursue

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

EQUAL-STRUCTURE
Version 5, 1-Oct-88, Released 8 Oct 88
Vote: 1y2i3y4a5i*6y7y8y9y10a STATUS-QUO
Comments: Errors in EQUALP summary. EQUALP on hash-tables?
Status: need new version

ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88
Status: separate vote

EXIT-EXTENT
Summary: What happens with non-local exits out of UNWIND-PROTECT cleanup
clauses?
Version 5, 12-Dec-88, Released 12-Dec-88
Vote: 1a2n3a4n5n*6c7n8n9n10n MINIMAL
Vote: 1a2i3y4y5n*6c7y8y9n10y MEDIUM
Version 6,  8-Jan-89
Status: ready for release?

EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Vote: 1y2y4y5y6y7y8y9y10y P.211
Status: block vote

FILE-LENGTH-PATHNAME 
Comments: Some people didn't seem to think
  this was appropriate. No one seemed very interested in writing it up.
Status: not submitted

FILE-WRITE-DATE-IF-NOT-EXISTS
Synopsis: What does FILE-WRITE-DATE do if no such file?
Version: no proposal
Status:  => non-existant "error signalling" committee

FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Vote: 1n2n3n4i5y6y7n8n9y10i TIGHTEN-DEFINITION
Vote: 1y2n3y4y5n6a7n8n9n10y TIGHTEN-FIXNUM-TOSS-BIGNUM
Comments: TOSS-FIXNUM-TOSS-BIGNUM
	4, 10: TIGHTEN-DEFINITION if TIGHTEN-FIXNUM-TOSS-BIGNUM is voted down
    I don't think either proposal really addresses the problem adequately
	doesn't do much for anyone & will break some implementations.
    8: BIGNUM not useful, but there are other non useful aspects; changing
requires better justification.
Status: separate vote

FOLLOW-SYNONYM-STREAM
Status: Not Submitted; lost in STREAM-ACCESS

FORMAT-E-EXPONENT-SIGN
Vote: 1y2y3y4a5y6y7y9y10a FORCE-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: block vote

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: need volunteer

FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Vote: 1y2y3y4y5y6y7y9y10y YES
Comments: remaining questions:
   - Is PRINT-OBJECT used to print things of type FLOAT in any cases
     where ~$, ~E, ~F, or ~G is used?
   - Can users write any methods (including :AROUND, :BEFORE, etc) for
     PRINT-OBJECT on type FLOAT?
 If Yes and Yes, it  matters whether any of those format ops bind
 *PRINT-BASE* in order to achieve the effect prescribed by CLtL of
 always printing floats in base 10. If the answer to either of those
 questions is "No", then it doesn't matter.
Status: separate vote (amend to No and No?)

FORMAT-ROUNDING
Synopsis: specify that ~F rounds up
Version 1, 5-Oct-88
Comments: we don't like the proposal
    recommend  #+IEEE-FLOATING-POINT => round-to-nearest?
Status: withdrawn?

FUNCTION-ARGUMENT-LIST
Synopsis: want way to get argument list
Status: not submitted

FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88
Status: need new version

FUNCTION-COMPOSITION
Synopsis: Add new functions for composing function values
Version 4, 12 Dec 88, Released 12 Dec 88
Vote: 1n2n3n4n5y*6a7n8n9n10a NEW-FUNCTIONS
Vote: 1n2y3n4y5i*6y7i8n9n10i COMPLEMENT-AND-ALWAYS
Comments: fix Barry Margolin's complaint about the degenerate case of
COMPOSE
	6: We would vote "Yes" for COMPLEMENT-AND-ALWAYS iff NEW-FUNCTIONS fails.
	7,10: If a name better than "ALWAYS" can be found,
		or if only COMPLEMENT were in the proposal
	Amend ALWAYS => CONSTANTLY?
	8: error in the proposal, the example for find-if specifies AND and
DISJOIN to be equivalent
Status: separate vote (w/amendment(s))

FUNCTION-DEFINITION
Version 2, 09-Dec-88, Released 9 Dec 88
Vote: 1y3y4y5y6y7y8a9y10a FUNCTION-SOURCE
Status: block vote

FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released  12-Dec-88
Vote: 1y2y3y4y5y6y7y8y9y10y RESTRICTIVE
Status: block vote

FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Vote: 1y2n3y4a5y*6y7y8na9n10n USE-ACTUAL-ARGUMENT-TYPE
Status: block vote?

GC-MESSAGES
Synopsis: What about unsolicited GC messages?
Version 2, 14-Nov-88
Status: editorial UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS?

GET-MACRO-CHARACTER-DISPATCHING
Synopsis: What does GET-MACRO-CHARACTER return for dispatching macros?
Status: not submitted

GET-MACRO-CHARACTER-READTABLE
Vote: 1y3y4y5y*6y7y8y9y10y NIL-STANDARD
Version 2, 8 Dec 88, Released 8 Dec 88
Comments: test case says GET-DISPATCH-MACRO-CHARACTER returns EQ
     functions; not required. Fix test case.
Status: separate vote (with amendment)

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
status: awaiting new version 

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
Vote: 1a3a4n5y*6y7y8a9n10n ADD-WITH-WRAPPER
Comments: The test-package-iterator example has the values
 from the generator in  the wrong order.
  10: should be functions
Status: separate vote (with amendment)

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
Vote: 1a2y3y4c5n*6a7n8c9?10c KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88, Released 12 Dec 88
Comments: is this necessary? I won't oppose if others think it's important.
	Agree with "additional comment"
	Not at this time. No time to understand.
     8: Check SXHASH, I thought it was supposed to work accross different
invocations of lisp.  This appears to not be the case according to the
proposal.  Since the proposal really isn't changing the language (I hope),
then it is really only a clarification of existing status, but I'm not sure
I understand the issue any more now than before I read it.
    10: As best we can tell, all this proposal says is that it is an error
to 
	destructively modify elements of equal hash tables but ok to do so for eq
	hash tables.  We would support a simpler proposal stating this.
Status: separate vote?

HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 8 8
Vote: 1y3y4n5y*6y7y8y9y10y ADD-EQUALP
Comments: "We would really like to see = hash tables, too."
Status: block vote

IEEE-ATAN-BRANCH-CUT
Version 1, 13-Dec-88
Status: ready for release?

IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Vote: 1y2y3y4n5y6y7i8i9y10y SELECT-ONLY
Comments: 7, 8: "Yes" if DEFPACKAGE
	     If we allow time for more experimental use of DEFPACKAGE before
     	  adopting this.
Status: block vote

IN-SYNTAX
Synopsis: like IN-PACKAGE but for readtables
Version 1, 21-Oct-88
Comments: too narrowly focused?
Status: needs new version

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: ready for release?

LAMBDA-FORM:NEW-MACRO
Vote: 1y3y4n5y6a7n8a9y10y
Version 4, 22-Nov-88, Released 8-Dec-88
Comments: 10 New special form would be even better.
Status: separate vote

LAMBDA-LIST-DUPLICATES
Status: withdrawn

LCM-NO-ARGUMENTS
Vote: 1y3y4y5y6y7y8y9y10y [Returns] 1
Version 1, 17 Oct 88, Released 8 Dec 88
Status: block vote

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

LET-TOP-LEVEL
Synopsis: What's top level?
Status:  => clcompiler

LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88
Status: ready for release?

LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Vote: 1y3y4y5i6y7n8y9y10y DISALLOW
Comments: Don't like (DEFVAR CAR ...) example

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 1, 2-Jan-89
Status: need new version?

LOAD-TIME-EVAL 
Synopsis: #, semantics not in read macro
Status: => clcompiler

LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Comments: same arguments as REQUIRE-PATHNAME-DEFAULTS?
Status: not 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
Vote: 1y2n3y4n5n*6y7n8y9y10n IMPLEMENTATION-DEPENDENT
Comments: Decreases portability, incompatible, special-case, has other ways
	rationale incorrect, current practice incorrect
	8: People writing portable code have more subtle problems to worry
       about than the default :USE list anyhow
Status: separate vote 

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

MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Vote: 1y2y3y4y5y6y7y8y9y10y EXPLICITLY-VAGUE

NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Vote: 1a3n4n5y*6y7y8an9n10y ADD
Comments: OK, but of marginal value.
	The proposal should clarify the treatment of n when it is out of range.
	Any non-negative integer index values should be permitted.
	NIL should result if the index argument is too large.

OUTPUT-STREAM-P-EXAMPLE
Synopsis: Clarify (output-stream-p (make-concatenated-stream)) is NIL?
Version 1, 26-Oct-88
Status: ready for release? Comments?

PACKAGE-CLUTTER
Vote: 1y2y3y4i5y6y7y8y9y10y REDUCE
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: stronger on properties; "implimentation"
	Symbols that are special forms can have macros, be FBOUNDP
	I don't see any need to restrict the use of internal symbols in
    the CL package as property indicators
	Stronger: implementation will not use any property names
    which are on user-created packages (except by inheritance.)
	Allow SETF of GET, GETF, and SYMBOL-PLIST?
	Other properties also should be spelled out, as per Moon.
Status: separate vote with amendments

PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Vote: 1y3y4a5y6y7a8y9n10i NEW-FUNCTION
Comments: Minor glitches
	10: Remove the description of "correctable" error to be signalled and
handled.
	This sort of detailed error protocol is not specified for any other
function
	and is not appropriate here
Status: separate vote with amendment

PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 1, 21-Oct-88
Comment: extend package accessors PACKAGE-NAME etc. to take strings too.
Status: need new version

PATHNAME-CANONICAL-TYPE
Status: => "pathname" committee?

PATHNAME-COMPONENT-CASE
Status: => "pathname" committee?

PATHNAME-LOGICAL
Status: => "pathname" committee?

PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous comments, all over the map
Status: need new version

PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Status: => "pathname" committee

PATHNAME-SYNTAX-ERROR-TIME
Status: => "pathname" committee

PATHNAME-TYPE-UNSPECIFIC
Vote: 1y3y4i5y6y7n9y10y NEW-TOKEN
Version 1 27-Jun-88, Released 7 Oct 88
Comments: ":UNSPECIFIC should be legal in all pathname fields, not just in
the
    type field."
	No Unix convention I know of requires this new concept.  Perhaps a
	couple of good examples would convince me.
Status:  block vote? "amend" to be PATHNAME-UNSPECIFIC-COMPONENT?

PATHNAME-WILD
Status: => "pathname" committee

PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: How to deal with logical devices, :unspecific components, etc in
pathname functions
Comments: extension of PATHNAME-TYPE-UNSPECIFIC handled part
Status: ready for release?

PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM
Vote: 1y2y3y4n5y*6y7y8y9y10y FIRST-READ-CHAR
Comments: "All metastreams must now support PEEK-CHAR directly..."
	conflict with the rationale for issue UNREAD-CHAR-AFTER-PEEK-CHAR,
    which is to legitimize implementing PEEK-CHAR as READ-CHAR/UNREAD-CHAR?
Status: separate vote; amendment?

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
Vote: 1y3y4i5y6y7y8y9y10y USER-FUNCTIONS-WORK
Comments: This proposal would be OK if it specified that circularity only
    had to be detected for objects that are contained in slots of the
    structure, not random objects that are printed out by the structure
    print function.  Rationale: one way to handle circular printing is
    to traverse the structure to detect circularities before
    printing anything.

PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Vote: 1n3c4n5y*6y7n8i9y10n LG
Comments: change "Clarify" => "Define"
	Good idea, but insufficient experience implementing&using.
	Favor in principle, but want discussion to ensure we're talking about same
thing.
	No fundamental complaint, but more experience needed before standard.
	Define the status of unproclaimed free variables.
       Presumably, they are an error;  compilers should issue a warning.
	I don't believe in separate "dynamic" environment, don't believe it
    makes sense to support rapid access to Globals on stock hardware,
   and don't understand what Scheme practices don't work in Common Lisp. 
   Perhaps I can be dissuaded about some or all of these opinions.
	8: If it can be implemented easily then I'm for it.

PROCLAIM-SCOPE
Synopsis: PROCLAIM's scope can end at "file" boundaries?
Status: => clcompiler

PROMPT-FOR
Synopsis: Add function to ask user for a value
Status: awaiting resubmission

RANGE-OF-COUNT-KEYWORD
Version 3, 9-Oct-88, Released 14-Oct-88
Vote: 1y3y4y5y6y7y9y10y NIL-OR-INTEGER
Status: block vote

RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Vote: 1y2y3y4y5y6y7y8y9y10y INTEGER-AND-INTEGER-NIL
Status: block vote

READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Status: Not submitted

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 2, 08-Jan-89
Comment: lengthy dissent from Le Brun
Status: ready for release?

REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 4, 29-Nov-88
Comments: want in-between version where sequence & N-set functions
	are vague, but others are specified.
Status: needs new version

REMF-MULTIPLE 
Synopsis: What does REMF do if it sees more than one INDICATOR?
Version 1, 26-Jan-88
Status: need new version

REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Vote: 1y2y3y4y5y6y7n8y9n*10y ELIMINATE
Comments: Deprecate instead.  Do not remove from the Lisp package.

REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Vote: 1n2n3n4n5n6n7n8a9n10y NEWLY-ALLOCATED
Vote: 1y2y3y4y5y6y7y8a9n10n MAY-SHARE
Vote: 1n2n3n4n5n6n7n8a9n10n MUST-SHARE
Comments: Add a new kind of declaration?
	8: All three stink. No idea what to do.
Status: vote separately

REST-LIST-EXTENT
Status: incorporated in issue DYNAMIC-EXTENT

RETURN-VALUES-UNSPECIFIED
Vote: 1y3y4y5y6y7y8y9y10y SPECIFY
Version 6, 9 Dec 88, Released  9-Dec-88
Status: block vote

ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Vote: 1y2y3y4a5y6y8a9y10n NEW-VALUE
Comments: "I liked KMP's suggestion of defining additional synonyms"
Status: block vote

SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Version 6, 06-Oct-88
Comments: New version scales down rejected version
Status: ready for release?

SETF-FUNCTION-VS-MACRO
Version 3, 4-Nov-87, Released Nov 87
Vote: 1y3y4n5n*6y7i8i9y10n SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
SETF-PLACES
Version 1, 11-Nov-88, Released 9-Dec-88
Vote: 1n3n4i5n*6i7y8n9n10n SETF-PLACES:ADD-SETF-FUNCTIONS
Comments: premature to vote on this issue
 		want unified issue
 		7: If SETF-PLACES:ADD-SETF-FUNCTIONS fails.
		other options?
		8: SFVM:SF much better than before. What about
			(defmacro (setf name) ?) Yes if nothing better
			comes along.
		   SP:ASF would require code to have ugly #.
Status: vote separate, with amendments

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: more careful definition of order of evaluation inside (SETF (GETF
...) ...) 
Vote: 1a2y4y5y6y7n8y9y10y DELAYED-ACCESS-STORES
	7: not "right" semantics? presentation needs work even if right.
Status: separate vote

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

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
Vote: 2y3y4y5y6y7y8y9y10y DEFINED-CONTRACTS
Status: block vote

STANDARD-VALUE
Synopsis: user can say binding is "temporary" 
Version 1, 21-Oct-88
Status: ready for release?

STEP-ENVIRONMENT
Vote: 1y2c3y4y5i6y7y8y9?10y CURRENT
Version 3, 20-Jun-88, Released  7 Oct 88
Comments: need clarification: compiled STEP only interprets
	what would have already been interpreted if STEP wasn't there.
Status: separate vote with amendment

STREAM-ACCESS
Version 2, 30-Nov-88, Released  9 Dec 88
Vote: 1n3n4i5n*6y7y8i9y*10i ADD-TYPES-PREDICATES-ACCESSORS
Vote: 1n3n4?5y*6n7y8y10n ADD-TYPES-ACCESSORS 
Vote: 1y3y4?5n*6n7y8a10n ADD-PREDICATES-ACCESSORS
Comments: Although requiring types instead of predicates forces the
implementation
 of these streams as separate types, there is no obvious serious problem
 which can result from that, and it leaves open the possibility of writing
 methods on particular types -- if they are also classes -- are they? The
 proposal should spell this out.
 Having both the types and the predicates is unnecessary clutter.
 Omitting the predicates makes for less overhead with no lost
functionality.
 8: TYPES-ACCESSORS, then TYPES-PREDICATES-ACCESSORS, then abstain
Status: separate vote with amendment T => "true"
 9: two changes to proposal


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
Vote: 1y3y4y5i*6y7y8y9?10n ONE-DIMENSIONAL-FUNCTIONS
Comments: 5: We vote "Yes" only if the name-changing amendment mentioned in
the mail passes.
 Also, the writeup incorrectly states that Newline is not a standard
character;
 Perhaps someone has confused "standard" with "graphic".
	Change: 		LINE-WIDTH   ==> STREAM-LINE-WIDTH
		LINE-POSITION ==> STREAM-LINE-POSITION
		PRINTED-WIDTH ==> STREAM-STRING-WIDTH
  8: prefer amendment. Can NIL be returned?
  7: complex proposal; maybe changes in detail after experience?
  10: inappropriate (examples in mail)
Status: separate vote

SUBTYPEP-TOO-VAGUE
Version 4,  7-Oct-88, Released 7 Oct 88
Vote: 1y2y3y5y*6y7y10y CLARIFY
Comments: complicated; not sure
Status: block vote

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
Vote: 1y3y4i5y6y7y8y9y10y ALLOW
Comments: 4: Only if SYMBOL-MACROLET-SEMANTICS passes
Status: block vote

SYMBOL-MACROLET-SEMANTICS
Vote: 1y2y3y4a5y6y7y8y*9y*10y SPECIAL-FORM
Version 5, 30-Nov-88, Released 9 Dec 88
Comments: 9: need more clarification
Status: block vote

SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
=> clcompiler

TAGBODY-CONTENTS
Version 5, 9-Dec-88, Released 9 Dec 88
Vote: 1y3y4y5i6y7y8y9y10i FORBID-EXTENSION
Comments: "The term "data element" is too vague in paragraph 2 of the
proposal.
 Our "Yes" vote is contingent on correcting this.
 lmm changed mind.
  10: We support forbidding extensions, but oppose allowing duplicate and
unreachable tags.  Instead we would prefer clarifying that () is a form
and not a valid tag.
Status: separate vote (with amendment?)

TAIL-RECURSION-OPTIMIZATION
Version 2
Status: => cl-compiler?

TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Vote: 1y2y3y4y5y*6y7a8y9y10y T
Comments: Current practice is wrong. Expand to LDIFF? Add :TEST?
 The EQ -> EQL change at the last minute means this is not Genera current
 practice, contrary to the current practice section.
Status: separate vote

TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec 
Vote: 1n3n4y5y*6a7n*8na9n*10y FLUSH-ALL
Vote: 1n3n4i5y*6a7y8na9n*10y FLUSH-TEST-NOT
Comments: Unnecessary incompatible change
	4: Flushing some is better than not flushing all
	5: mostly happy with either,slight preference to FLUSH-ALL.
     "Yes" contingent on:
   - changing "remove" to "deprecate", and coming up with a
     suitable policy for deprecation which allows a comfortable
     transition from current practice.
   - either of the FUNCTION-COMPOSITION proposals passing.
	7: Perhaps deprecate these instead.  They need to remain in
     the LISP package. The functionality of REMOVE-IF-NOT is needed,
     perhaps use the name KEEP-IF.
	9: deprecate
Status: separate vote

THE-AMBIGUITY
Version 1, 21-Oct-88
Comments: typo, sense wrong
Status: ready for release with amendment

TRACE-ERROR
Synopsis: TRACE should signal errors if it doesn't understand
Version 1, 20-Jun-88
Comments: is this a cleanup?
Status: ready for release?

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
Vote: 1y2c3y4y5i6y7i8y9n10y ADD-CONSTRAINTS
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: some "bugs" in the proposal
 5: "Our "Yes" vote is contingent on the following issues being addressed:
  - RANDOM-STATE should be added to the list of built-in types.
  - (subtypep (type-of x) (class-of x)) => T T for all x, seems to have
    been intended but is not actually said. It should be added.
  - The implementation recommendation in the discussion about returning
    only portable type specifiers should be discarded.
  - Shouldn't this refer to classes with proper names rather than just
    ones with names?
  7: If fix scope of quantifiers in (a)
  Amend: for all x, for all bt
	(when (built-in-type-p bt)
	 (when (typep x bt) (assert (subtypep (type-of x) bt)))).
Status: separate vote with amendment

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: discussion on common lisp mailing list.
Status: Not yet submitted

UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens when you call an undefined function, use
	an unbound variable?
Version 1, 29-Nov-88
Status: ready for release?

UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Vote: 1y2y3y4y5y6y7y8y9y10y DONT-ALLOW
Status: block vote

UNWIND-PROTECT-NON-LOCAL-EXIT
Status: renamed to EXIT-EXTENT

VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Vote: 1y3y4y5y6y7y8n9y10y SYMMETRIZE
Comments: Error checking gained by disallowing (var) is more important to
me than symmetry.  If anything (var) should be disallowed in all forms.
Status: block vote

WRITE-NEWLINE
Synopsis: Add a :NEWLINE keyword to WRITE
Version 1, 20-Oct-80
Comments: we don't like it
Status: withdrawn?

∂10-Jan-89  0149	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 5)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Jan 89  01:49:51 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01844g; Tue, 10 Jan 89 01:45:37 PST
Received: by bhopal id AA12606g; Tue, 10 Jan 89 01:47:53 PST
Date: Tue, 10 Jan 89 01:47:53 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901100947.AA12606@bhopal>
To: masinter.pa@Xerox.COM
Cc: IIM%ECLA@ECLC.USC.EDU, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 9 Jan 89 22:30 PST <890109-223056-5490@Xerox>
Subject: Issue: EQUAL-STRUCTURE (Version 5)

re: What is current practice in this area? What does EQUALP do in current
    implementations on hash tables?

Lucid does something slightly wrong -- it descends component-wise using
an arbitrary indexing into each table.  Thus it will be guaranteed to
get the wrong answer when the two tables contain the same data, but
were built up in differing orders such that the collision chains
are different [for any reasonable hashing implementation, you can
find an example of this].

It would be about a 5-minute job to fix it (i.e. to do the coding
for a fix, and minimal checkout).  Of course this would require a QA
step for any commercial implementation, so that is the painful part.

I suspect the reason we have never fixed it is that:
  -- So far, no customer/user has discovered the anomaly; or at least,
      no one is aware of a bug in their program due to this anomaly.
  -- Neither CLtL, nor Guy's "Clarifications" of 6-Dec-85, nor current
     Cl-cleanup discussions, have brought a sense of inevitability to
     the issue yet.

In short, I don't recommend Lucid's current practice or experience as
having any informational value here.


-- JonL --

∂10-Jan-89  0413	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Jan 89  04:13:09 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01880g; Tue, 10 Jan 89 04:09:02 PST
Received: by bhopal id AA12797g; Tue, 10 Jan 89 04:11:19 PST
Date: Tue, 10 Jan 89 04:11:19 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901101211.AA12797@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@Sail.Stanford.Edu, masinter.pa@Xerox.COM
In-Reply-To: masinter.pa@Xerox.COM's message of 6 Jan 89 11:57 PST <890106-115801-255@Xerox>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)

re:  'Eliminate the distinction between types "for declaration" and "for 
        discrimination".'

In the initial proposal, I thought it was clear from the context that 
this applied only to ARRAY type specifiers (and the later added COMPLEX 
specifiers); but if someone was confused about it, it wouldn't hurt to 
make it explicit.   


re: Stylisticly, this can be accomplished quickly if a bit awkwardly, by saying
    "The proposal is written using the following two functions, although these
    functions are not added to the standard." [UPGRADE-ARRAY-ELEMENT-TYPE ...]

The whole point of proposing these two functions is the acknowledgement that
every implementation must have them under one name or the other.  So why
not use the same name, so that  user code can access them?   The alternative
of a portable definition is not functinoally equivalent, since it conses.


-- JonL --

∂10-Jan-89  0624	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89  06:24:17 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 518333; Tue 10-Jan-89 09:22:23 EST
Date: Tue, 10 Jan 89 09:22 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 2)
To: MLB@WHITE.SWW.Symbolics.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,
    rwg@WHITE.SWW.Symbolics.COM
In-Reply-To: <19890110015752.6.MLB@METAL-FLAKE.SWW.Symbolics.COM>
Message-ID: <890110092213.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

Would your concerns be addressed if CL adopted REAL with the provision
that RATIONAL and FLOAT might not be an exhaustive partition of real?
In that way, an IRRATIONAL type (and/or perhaps others) could be added
by implementations wanting to.

Your remarks about the possibility of an irrational amount to a 
strengthening of the need for REAL, since it points up the fact that
anyone now using the indicated OR type is setting themselves up to be
confused by other number types which come along (either in future CL's
or in some particular present-day CL sub-dialect) which actually might
be perfectly ok for their application. If they could say REAL, they
could permit these unexpected types in a natural way.

The practical impact on CL programmers would be that they were advised
to do:
 (TYPECASE number
   (REAL
     (ETYPECASE number
       (FLOAT ...)
       (RATIONAL ...)))
   ...)
rather than:
 (TYPECASE number
   (REAL
     (TYPECASE number
       (FLOAT ...)
       (OTHERWISE ;presumably RATIONAL
	 ...)))
   ...)

By the way, I'm surprised by your reaction partly because there are already
other things in CL (most notably a definition of COMPLEX such that RATIONAL
is not a subtype, and such that the real and imaginary parts must be of the
same machine representation) which are not true to mathematics already. 
Given this, I'm surprised you even care whether the rest of the type system
corresponds. I would assume that any serious mathematics would want to be 
reconstructed atop CL rather than rely on its native partitionings, which 
already seem off base, as (for example) Macsyma has done. 

It seems clear to me that CL is not going to provide true representations
of mathematics. The real question is, should CL be permitted to provide
approximate representations? I think the answer is yes. I keep coming back 
to the following analogy in my mind: CL's type system is to a mathematical
type system as floats are to reals in math ... some may legitimately say
the two have nothing to do with each other, yet you can still get useful
work done even with the crude approximations. 

Indeed, the more you let the approximation -be- an approximation, the
more work you're likely to get done. I think programmers don't mind making
exceptions for things Lisp might really do, but I also think the more you
force the programmer into thinking about abstract concepts which in fact 
do not exist in any implementation, the more the programmer can feel
you're just wasting his time and the less likely he's going to be to use
this language the next time. If CL really -had- irrationals, we would modify
the definitions of things to suit irrationals. But if CL is not going to
have irrationals, there's a fine line between the extensibility issues
you raise and the practical day-to-day overhead of a programmer who may
wonder if by the time it comes to extend the language he won't be programming
in some other language anyway...

So I guess I'm willing to see a compromise, stating that RATIONAL and FLOAT
are not an exhaustive partition of REAL, but I'm observing that that 
compromise is not without cost. 

Beyond that, the issue is simple: programmers want a word to use. REAL is
the word which is used by other languages. We can avoid REAL if there is a
strong reason to do so, but we should then have some other word. 

Your critical suggestions are interesting and somewhat helpful, but if you
now make a constructive suggestion -- ``how should we proceed?'' -- it 
might be more helpful. My reading is that people are not yet so wedded to
this proposal that they wouldn't be willing to change if someone made a
reasonable, concrete, alternative proposal. What we most lack is time.

∂10-Jan-89  0733	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 6) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89  07:33:07 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 518365; Tue 10-Jan-89 10:31:24 EST
Date: Tue, 10 Jan 89 10:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 6)
To: gz@spt.entity.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890110-002251-5597@Xerox>
Message-ID: <890110103117.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

    From: gz@spt.entity.com (Gail Zacharias)
    Date: 10 Jan 89 00:22 PST

    ... it may not be possible to write whitespace to a stream in units
    smaller than a #\space character, if the stream is associated with a
    (multi-font) ascii file or editor buffer (since there may be no ascii
    character available that can be inserted in the file/buffer to
    represent the whitespace). ...

This is a good point. I think the wording should be loosened to indicate
the obvious -- that an implementation should not be branded non-conforming
if it does the closest approximation to the right thing for the stream,
font, device, operating system, etc. that it is dealing with.

To the extent that this hook is primarily to support portable pretty
printers My belief is that people would quickly learn to use a fixed
width font for pretty printed code if the approximate behavior bothered
them, but those who insisted on using bold would be happier with an
approximation to pretty printing than none at all. Of course, nothing
prevents a particular vendor in this mess from providing a proprietary
pretty printer which deals better -- and I'm sure people would use it --
but the idea is to provide a means to save a lot of vendors that work.

How about if the function returned information saying whether it
believed it had correctly achieved its stated goal?

    ... In general we feel that the proposal is premature, given the
    current state of i/o standards. ...

This is the sort of reasoning that led us to not have a way to clear
the screen in portable code under CLtL. [A situation we should probably
rectify even now...]

My belief is that the needs of the Common Lisp community are better
served by a slightly faulty implementation that tries to win as much
as it can than by no implementation.

If and when a better solution exists (eg, some window system spec),
the window system spec can contain advice to its users that they should
no longer use the clumsy primitives provided by ANSI Common Lisp.

∂10-Jan-89  0906	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 10 Jan 89  09:06:18 PST
Received: by ti.com id AA04983; Tue, 10 Jan 89 11:06:01 CST
Received: from Kelvin by tilde id AA10141; Tue, 10 Jan 89 10:54:55 CST
Message-Id: <2809443435-15097074@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 10 Jan 89  10:57:15 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>, masinter.pa@Xerox.COM
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
In-Reply-To: Msg of Wed, 4 Jan 89 01:39:19 PST from Jon L White <jonl@lucid.com>

> re: I'd like to see the writeup make it clear that the following is subsumed;
>       . . . 
>       Proposal SPECIAL-TYPE-SHADOWING:CLARIFY
...
> I don't think it is subsumed.  The various versions of DECLARE-TYPE-FREE
> permitted an inner nested declaration to be merely overlapping with
> an outer declaration; but Gray's proposal requires local (read: "inner")
> declarations to be subtypes of the global proclamations (read: "outter")

I don't think it is subsumed, but not for that reason.   The treatment
of overlapping declarations is intended to be consistent; but
DECLARE-TYPE-FREE still makes no mention of type proclamations.  Also,
the proposal section of DECLARE-TYPE-FREE seems to have lost a clear
definition of the semantics of overlapping declarations, although it is
clarified in the discussion section.  The proposal needs to explicitly
say that nested type declarations combine rather than being shadowed.

∂10-Jan-89  0948	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 2)  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 10 Jan 89  09:46:31 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa06415; 10 Jan 89 17:39 GMT
Date: Tue, 10 Jan 89 17:41:48 GMT
Message-Id: <14751.8901101741@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: REAL-NUMBER-TYPE (version 2)
To: Marc Le Brun <MLB%white.sww.symbolics.com@NSS.Cs.Ucl.AC.UK>
Cc: CL-Cleanup@sail.stanford.edu

   There are dangers in introducing the term REAL.  It encourages the
   widespread confusion between a computer type, REAL, which of necessity
   denotes a countable class of symbols, with the mathematical object (which
   I'll call R), which is non-denumerable.

Don't we already have such problems with COMPLEX?

Hummm, maybe you're right, and we shouldn't have REAL.  Common Lisp
COMPLEX seems to mean the representastion rather than the set, so that

     (subtypep 'rational 'complex) => NIL, T

So adding REAL seems to imply further revisions.

∂10-Jan-89  1019	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-COPY-PLIST  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89  10:19:41 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 10 Jan 89 13:11:50 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 10 Jan 89 13:16:52 EST
Date: Tue, 10 Jan 89 13:17 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: COPY-SYMBOL-COPY-PLIST
To: cl-cleanup@sail.stanford.edu
Message-Id: <19890110181742.7.BARMAR@OCCAM.THINK.COM>

Issue:		COPY-SYMBOL-COPY-PLIST
References:	COPY-SYMBOL (p 169), COPY-LIST (p 268), COPY-TREE (p
		269).
Category:	CLARIFICATION
Edit history:	10-Jan-89, Version 1 by Margolin

Problem Description:

The description of COPY-SYMBOL, where the COPY-PROPS optional argument
is non-NIL, says that a copy of the property list is used as the new
symbol's property list.  However, there are several ways in which a list
may be copied, most notably COPY-LIST and COPY-TREE, and the description
doesn't say which mechanism should be used.

Proposal (COPY-SYMBOL-COPY-PLIST:COPY-LIST)

Clarify that when COPY-SYMBOL copies the property list of the symbol, it
is as if (COPY-LIST (SYMBOL-PLIST sym)) were used as the new symbol's
property list.

Rationale:

COPY-LIST is the simplest list-copying primitive.  The result of this
copy is that GET returns EQL results for the two symbols until one of
the property lists is altered, but altering either of the property lists
doesn't affect the other.  This is current practice in the
implementations I tested, and probably what most users assume.

Current Practice:

Symbolics Genera and Sun Common Lisp currently implement this.  I
suspect most others do, too.

Cost to Implementors:

Little or none.

Cost to Users:

None unless they've been assuming some other type of copy.

Benefits:

Less ambiguity.

Aesthetics:

Well, I like it.

∂10-Jan-89  1042	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89  10:42:17 PST
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 518546; 10 Jan 89 13:40:31 EST
Date: Tue, 10 Jan 89 13:40 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 2)
To: MLB@WHITE.SWW.Symbolics.COM, Cassels@STONY-BROOK.SCRC.Symbolics.COM
cc: 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, rwg@WHITE.SWW.Symbolics.COM
In-Reply-To: <19890110015752.6.MLB@METAL-FLAKE.SWW.Symbolics.COM>
Message-ID: <19890110184025.0.CASSELS@GROUSE.SCRC.Symbolics.COM>

    Date: Mon, 9 Jan 89 17:57 PST
    From: Marc Le Brun <MLB@WHITE.SWW.Symbolics.COM>

	Date: Sun, 8 Jan 89 11:29 EST
	From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>

	Issue:        REAL-NUMBER-TYPE
        [...]

    I apologize for the size of this response, but since this is sort of a "dissenting opinion" I
    felt it would be good to document the arguments as carefully as I could.

    There are dangers in introducing the term REAL.  It encourages the widespread confusion
    between a computer type, REAL, which of necessity denotes a countable class of symbols, with
    the mathematical object (which I'll call R), which is non-denumerable.  This identification of
    incommensurables has many unfortunate consequences, including ambiguous and inconsistent use
    of "intuitive" models.  Further, members of these sets which are commonly identified with
    eachother (ie real numbers and their computer images) often have incompatible semantics.

    The original Common Lisp specification did the world a service by eliminating this source of
    potential confusion.  If the term is to be reintroduced for pragmatic reasons, then it should
    at least done very carefully, so as not to result in further propagation, even amplification,
    of these problems.  It doesn't seem either responsible or forward-looking to gloss over these
    difficult issues.

	  Add a standard type specifier
	   (REAL low high)
	  which means
	   (OR (RATIONAL low high) (FLOAT low high))

    The Discussion section below implies that future extensions should be considered here.

    Suppose an implementation introduces new types which model members of R but which do not
    satisfy this predicate.  (For example, quadratic fields, or symbols denoting rational
    multiples of (mathematical) pi, say).  Is the implementation allowed to extend the type REAL
    or not?  I'd vote to allow extension, but in any case this should be stated.  (Further, must
    it so extend it?)

CL currently does not try to carefully restrict extensions to itself.
Overall, this is probably good although there are reasons to want a
strict language, too.  I think that the best we can do for any given
point in the development of the language is to describe what it *is* and
pick the sharpest possible terms for all the concepts, so that we don't
*preclude* interesting extensions.

	  As with other such type specifiers, define that if the low and high
	  are omitted, the atomic specifier REAL may be used.

	  Clarify that NUMBER is equivalent to (OR REAL COMPLEX).

... in the existing language.

    Suppose an implementation introduces new types which could considered numeric but which do not
    satisfy this predicate.  (For example, quaternions, as mentioned in the Discussion).  Is the
    implementation allowed to extend the type NUMBER or not?  I'd vote to allow extension, but in
    any case this should be stated.  (Further, must it so extend it?)

Again, I don't think we should try to guess what extensions might be
interesting.  An extension should be made "the right way."

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

    No.  

    1. As noted above R contains many "useful" elements (eg surds, mathematical pi or e) which can
    have discrete symbolic representations but whose behavior is not accurately modeled by any
    REAL element.

    2. Under many circumstances the semantics of "typical" elements of REAL are quite distinct
    from the elements of R with which they are commonly identified, leading to a variety of
    situational interpretations as "intervals", "fuzzy numbers", etc which clearly do not belong
    to the theory of R.

    3. Conversely operations on elements of R conform to a semantics of "infinite precision"
    obviously unattainable by REALs.

    4. REAL also may contain specific entities (such as -0.0) not in R.

    5. Because of finite range limitations REAL further does not consistently "cover" R.
    Sometimes this is dealt with as an error, sometimes with the introduction of non-analytic
    semantics (eg setting underflows to zero), sometimes by introducing non-standard entities
    partially or wholly outside R (eg the various "infinities", or the IEEE "Not-A-Number"s which
    (at least in Symbolics CL) paradoxically satisfy NUMBERP!).

    6. Since there is no "floating canonicalization", the type REAL contains multiple distinct
    images of certain elements of R (notably zero, many rationals, and many flonums which exist in
    more than one so-called "precision").

	  This class is important because it is all the numbers which can be ordered.

    Agreed that the ordering property of R is important.  It might be possible to have CL so
    define REAL specifically as some kind of maximal well-ordered set (though this might be
    tricky, in order to exclude characters as potential numbers, for example).

    (And, mathematically anyway, one might even ask for more rigor regarding the term "ordered",
    considering, for example, Conway numbers.  This would be a gratuitous comment except for IEEE
    having already opened the Pandora's box of non-standard numbers.)

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

    Presumably this is to be read as a proposal to substitute "real" for "non-complex number"?
    Note that these restrictions are apparently motivated by different properties: in some cases
    ordering, in others an aversion to imaginary algebra (eg the mystifying restrictions on CIS,
    COMPLEX et al).  Depending on the extension policy adopted that substitution might or might
    not retain its validity under an extension (eg symbols for rational multiples of mathematical
    pi aren't (OR RATIONAL FLOAT) but might be an acceptable, indeed useful, subdomain for CIS).

        [...]
	Benefits:

	  Mathematical clarity.

    Arguable.

	  Ability to do CLOS method dispatch on the type.

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

    As noted above, the policy regarding possible extensions, either as future CL standards or
    per-implementation, should be clarified in several respects.

As noted above, there should be no "policy" on future extensions.

	  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.

    This needs clarification.  If by "equivalent Fortran program" is meant a FORTRAN program that
    was specifically (heroically?) written to carefully model a CL program, then this begs the
    question.  If it means "a naive translation" between languages, then this is far from obvious
    (eg a CL implementation might generate rationals, thereby maintain different information
    through subsequent operations, and finally get results diverging significantly from the
    FORTRAN program).

    One could also easily imagine some careful conventional flonum-based numerical analysis being
    thrown off by the introduction of a non-zero rational smaller than CL "epsilon", for example.
    The assignation of "more accurate" is application-dependent and implementation-dependent.

Any program which depends in any significant way on range or precision
must *always* be translated carefully -- even when moving from one
Fortran implementation to another.  Experts always need to know
*exactly* how a particular computation will be done, and will always
have to read reference manuals carefully.

	  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.

    Agreed, the proposed type is an extension of what's commonly meant by the name REAL.
    (Although there exist unusual systems where REALs are implemented by decimal rationals!)
    While the "average programmer" may be comfortable, the differences between CL REALs and
    conventional REALs and their implications should be carefully and thoroughly documented in the
    standard (leaving aside the quagmire of confusion with regards to R).

We're not adamant about the name "real".  We do believe strongly that
the concept should be a part of the language as a distinct named type.
Suggestions for a better name are welcome.

You can't seriously expect a language definition to "carefully and
thoroughly" document all the differences between all other uses of a
word and the use in that language.  You are certainly right that a
"compatibility note" of the sort already in CLtL is warranted.  A
distilled version of your comments here would be quite appropriate.

∂10-Jan-89  1042	CL-Cleanup-mailer 	Re:  Issue: SETF-SUB-METHODS (Version 5) 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89  10:42:31 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA07207; Tue, 10 Jan 89 10:44:11 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA26417; Tue, 10 Jan 89 10:40:43 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA13760; Tue, 10 Jan 89 10:41:42 PST
Date: Tue, 10 Jan 89 10:41:42 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901101841.AA13760@clam.sun.com>
To: cperdue@Sun.COM, masinter.pa@Xerox.COM
Subject: Re:  Issue: SETF-SUB-METHODS (Version 5)
Cc: cl-cleanup@sail.stanford.edu

> In your ballot, you said: 
> 
> This does not seem to be the "right" choice of semantics, and I
> believe that the presentation of the proposal needs substantial work
> even if it is "right".
> 
> Can you help us? in what way is it wrong? what might be better? what
> cases are unclear that we need to clarify?

Right.  I didn't feel I could do justice to this issue before the January
X3J13 meeting.  

Perhaps these comments will be of some use:

Consider example 6.

(setq s (setq r (list 'a 1 'b 2 'c 3)))
(setf (getf r 'b) (progn (setq r nil) 6))
r ==> (b 6)
s ==> (a 1 b 2 c 3)

I find the SETF expression naturally maps to:

(setf r (put-plist r 'b (progn (setq r nil) 6)))

where put-plist is a destructive function on lists in the usual
Common Lisp style, where it must be used for its value.

With this expansion,

r ==> (a 1 b 6 c 3)
s ==> (a 1 b 6 c 3)

Perhaps I am wrong, but I think others will realize that they find
this more natural also.

Concerning the statement of the proposal, it seems to me that 3
half-page discussions -- one for CHAR-BIT, one for GETF, and one
for LDB and MASK-FIELD, is far too much to have to say about such
a fine point in the language.

∂10-Jan-89  1050	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 6) 
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 10 Jan 89  10:50:07 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA13470@EDDIE.MIT.EDU>; Tue, 10 Jan 89 13:48:01 EST
Received: by spt.entity.com (smail2.5); 10 Jan 89 12:58:22 EST (Tue)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Tue, 10 Jan 89 10:31 EST <890110103117.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 6)
Message-Id: <8901101258.AA10804@spt.entity.com>
Date: 10 Jan 89 12:58:22 EST (Tue)
From: gz@spt.entity.com (Gail Zacharias)

   Date: Tue, 10 Jan 89 10:31 EST
   From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
   To the extent that this hook is primarily to support portable pretty
   printers My belief is that people would quickly learn to use a fixed
   width font for pretty printed code if the approximate behavior bothered
   them, but those who insisted on using bold would be happier with an
   approximation to pretty printing than none at all. Of course, nothing
   prevents a particular vendor in this mess from providing a proprietary
   pretty printer which deals better -- and I'm sure people would use it --
   but the idea is to provide a means to save a lot of vendors that work.

Then vendors who wish to do so, and who find a model such as presented by this
proposal appropriate for their implementation, can provide the hooks as
implementation-dependent extensions.  The simple fact is that this proposal is
not universally implementable as stated, and loosening the restrictions would
mean that you still cannot write a portable pretty printer, i.e. one that
works correctly in all conforming implementations.

A pretty printer which assumes fixed width fonts by default, but allows
customization in ways appropriate for the text display model used by specific
implementations, is a better solution to this problem than putting functions
in the standard which are already known to be inappropriate for some existing
display models.  I don't think it's the responsibility of the standard to
provide hooks that give the illusion of portability to non-portable programs.

∂10-Jan-89  1101	CL-Cleanup-mailer 	Issue: REAL-NUMBER-TYPE (version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89  11:01:20 PST
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 518575; 10 Jan 89 13:59:30 EST
Date: Tue, 10 Jan 89 13:59 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 2)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, MLB@WHITE.SWW.Symbolics.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, rwg@WHITE.SWW.Symbolics.COM
In-Reply-To: <890110092213.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890110185930.1.CASSELS@GROUSE.SCRC.Symbolics.COM>

    Date: Tue, 10 Jan 89 09:22 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    [..]
    Beyond that, the issue is simple: programmers want a word to use.

We could note here that the Symbolics Common Lisp system already has a
name for the concept, and that since users have sent bug reports about
how poorly it's implemented, they must find it useful.  The way this
concept appears in SCL is embarrassingly wrong, so I've refrained from
mentioning it so far.  But now's the time....

  (NUMBER <low> <high>) is treated as equivalent to
  (OR (RATIONAL <low> <high>) (FLOAT <low> <high>))

Through some implementational fluke, (NUMBER * *) is equivalent to
NUMBER.  Thus #C(1 2) satisfies (NUMBER * *) but not
(NUMBER <IEEE minus infinity> <IEEE plus infinity>).

								      REAL is
    the word which is used by other languages. We can avoid REAL if there is a
    strong reason to do so, but we should then have some other word. 

Right.  The concept is demonstrably used and useful.

∂10-Jan-89  1429	CL-Cleanup-mailer 	Issue: STREAM-INFO (Version 6) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89  14:28:55 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 518773; 10 Jan 89 17:26:38 EST
Date: Tue, 10 Jan 89 17:26 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 6)
To: gz@spt.entity.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: <8901101258.AA10804@spt.entity.com>
Message-ID: <890110172620.2.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 10 Jan 89 12:58:22 EST (Tue)
    From: gz@spt.entity.com (Gail Zacharias)

    ...
    Then vendors who wish to do so, and who find a model such as presented
    by this proposal appropriate for their implementation, can provide the
    hooks as implementation-dependent extensions.

In practice, vendors don't do this. They each think their own theory of how
to provide the hooks is best, each insisting that other vendors' views of
the world are wrong. In the absence of an external agency (like ANSI) to 
force agreement, each feels entitled to disagree, believing it is right.
The advantage of a standard is that it enforces a little agreement.

    The simple fact is that this proposal is
    not universally implementable as stated, and loosening the restrictions would
    mean that you still cannot write a portable pretty printer, i.e. one that
    works correctly in all conforming implementations.

Technically, no, but for the universe of programmers we can reasonably
expect to sell to in the commercial community which ANSI influences, you
can do awfully good. If someone has a CL that supports Hebrew, let them
write their own pretty printer. I'd be surprised if they didn't plan to
do so anyway, so I doubt I'm asking them to do extra work. 

On the other hand, experience shows that Dick Water's very interesting
pretty printer did not reach all the target audiences that would have liked
to have it because he didn't have the time to adapt it to everyone's
idiosyncratic view of thew world, and they didn't have enough time to 
look over his code and realize how little work it would take to get it up
and running.

That's a real shame. This change comes to us from the CL user community
from Waters himself, who tried to use those hooks which you assert
everyone has, and who found it too much work. I think it's our obligation
to try to address his need in some way if we can.

    A pretty printer which assumes fixed width fonts by default, but allows
    customization in ways appropriate for the text display model used by specific
    implementations, is a better solution to this problem than putting functions
    in the standard which are already known to be inappropriate for some existing
    display models.  I don't think it's the responsibility of the standard to
    provide hooks that give the illusion of portability to non-portable programs.

How about if we permit an ERROR-P argument which controls whether you signal
an error or just continue if you are in a variable width font and can't support
the indicated operation. That way you'd get the benefits of your supposed
improvement (which is that fixed-width fonts would work) and implementations
which supported variable width fonts and arbitrary addressing would not be 
penalized. In a few years, we could take some polls and find out if people
were mostly willing to set ERROR-P to T and let their application fall on the
floor when it ran up against a hard problem, or if they were mostly willing
to set ERROR-P NIL, so that their application would do the best it could do
rather than just falling apart in an obviously difficult situation. This would
have no illusion of portability since in reading about the ERROR-P argument and
deciding what to set it to, it would be clear to the programmer how the behavior
might vary between implementations.

∂10-Jan-89  1441	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; 10 Jan 89  14:36:11 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 518783; Tue 10-Jan-89 17:33:14 EST
Date: Tue, 10 Jan 89 17:33 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-COPY-PLIST
To: barmar@Think.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <19890110181742.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <890110173307.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Tue, 10 Jan 89 13:17 EST
    From: Barry Margolin <barmar@Think.COM>

    ...
    Rationale:

    COPY-LIST is the simplest list-copying primitive.
    ...

In my book it's the -only- list-copying primitive. COPY-TREE doesn't
copy lists, it copies trees. Abstractly, there is no relationship
between the two except for people who think it's a bug that
 (MEMBER 'A '(B (A) C))
doesn't find A in the given list.

I don't think there's much issue here, but I'm happy to go along with it
if you think there is.

If we do proceed, I'd go so far as to say that Kathy might want to
document that wherever in plain text the phrase "copy the list" is used,
the equivalent of COPY-LIST is intended, that wherever in plain text the
phrase "copy the tree" is used, the equivalent of COPY-TREE is intended,
and that wherever in plain text the phrase "copy the alist" is used, the
equivalent of COPY-ALIST is intended.  This would save us having 42 more
of these issues come up now that you've opened this particular box
marked "Pandora"...

∂10-Jan-89  1443	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89  14:43:27 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 14:41:53 PST
Date: 10 Jan 89 14:41 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Tue, 10 Jan 89
 04:11:19 PST
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, cl-cleanup@Sail.Stanford.Edu
Message-ID: <890110-144153-6753@Xerox>

Even though all implementations "must have some code" that does the
upgrading, the code need not be a Lisp function. For example, KCL might do
the upgrading in C, or an implementation might simply upgrade all array
element types to T. 

There's a cost associated with adding functions to the LISP package,
including them in the documentation and specification beyond the cost of
requiring all implementations to write them -- the cost is in the overhead
of testing, documentation, user understanding, burden on implementation
model. The benefit of UPGRADE-ARRAY-ELEMENT-TYPE--namely, that it doesn't
CONS as much as the portable definition--seems very small and I don't think
it outweighs the cost.


∂10-Jan-89  1458	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89  14:58:47 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 518809; 10 Jan 89 17:55:48 EST
Date: Tue, 10 Jan 89 17:55 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
To: Masinter.PA@Xerox.COM
cc: JonL@Lucid.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890110-144153-6753@Xerox>
Message-ID: <890110175533.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

Also, for any given application, you usually know what types you care
about, so you can write a special-purpose, non-consing version for
that purpose by pre-caching the results at load time. For trivial
extra cost, you can have a table incrementally updated only on the
first call to the portable function with a particular argument, so the
end effect is negligible consing even in the general case.

∂10-Jan-89  1506	CL-Cleanup-mailer 	revised ISO discussion, revised DRAFT Gegenda and Subcommittee    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Jan 89  15:06:26 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA02617g; Tue, 10 Jan 89 15:02:13 PST
Received: by challenger id AA01019g; Tue, 10 Jan 89 14:58:08 PST
Date: Tue, 10 Jan 89 14:58:08 PST
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8901102258.AA01019@challenger>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu, jlz@challenger
In-Reply-To: masinter.pa@Xerox.COM's message of 9 Jan 89 23:39 PST <890109-234026-5560@Xerox>
Subject: revised ISO discussion, revised DRAFT Gegenda and Subcommittee
 meetings

Room 120 will be set up Sunday with an overhead.  Larry, you'll have to ask
the front desk for the key.  I've reserved it from 2:00 on. 
---jan---

∂10-Jan-89  1508	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89  15:07:58 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 15:04:53 PST
Date: 10 Jan 89 15:04 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
In-reply-to: David N Gray <Gray@DSG.csc.ti.com>'s message of Tue, 10 Jan 89
 10:57:15 CST
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Jon L White <jonl@lucid.com>, masinter.pa@Xerox.COM,
 CL-Cleanup@sail.stanford.edu
Message-ID: <890110-150453-6808@Xerox>

I don't think it is subsumed now either; I've left SPECIAL-TYPE-SHADOWING
as a separate issue.


∂10-Jan-89  1527	CL-Cleanup-mailer 	Re: Issue: STREAM-INFO (Version 6)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89  15:26:47 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 15:23:04 PST
Date: 10 Jan 89 15:22 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: STREAM-INFO (Version 6)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Tue, 10 Jan 89 17:26 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: gz@spt.entity.com, cl-cleanup@sail.stanford.edu
Message-ID: <890110-152304-6870@Xerox>

Maybe these belong in a category of "optional extensions", i.e., you either
provide them all or don't. We've avoided options so far, because we
couldn't see any good reason for providing them, but this seems like it
might be a good reason.

I'm of the mind, though, that streams for which this is not a good model
should behave exactly like the default implementation "fixed-width"
implementation:  every graphic character is of width 1 and the line width
is 80.

I'd think that would be more appropriate for a Mac implementation where it
is possible to change the font after-the-fact than actually paying
attention to the "real" width.


∂10-Jan-89  1536	CL-Cleanup-mailer 	Re: New proposed issue APPEND-ATOM  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89  15:36:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 10 JAN 89 15:35:10 PST
Date: 10 Jan 89 15:34 PST
From: masinter.pa@Xerox.COM
Subject: Re: New proposed issue APPEND-ATOM
In-reply-to: masinter.pa's message of 6 Dec 88 17:57 PST
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890110-153510-6915@Xerox>

I have apparently misplaced:

Guy Steele <gls@Think.COM>'s message of Tue, 6 Dec 88 14:29:22  EST
Subject: New proposed issue APPEND-ATOM

Do you have it?
If you find it, would you mail it to me?

∂10-Jan-89  1551	CL-Cleanup-mailer 	New proposed issue APPEND-ATOM 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89  15:50:51 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 518869; Tue 10-Jan-89 18:48:25 EST
Return-path: <CL-Cleanup-mailer@SAIL.STANFORD.EDU>
Received: from SAIL.STANFORD.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 504032; 6 Dec 88 14:43:29 EST
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Dec 88  11:32:31 PST
Received: from fafnir.think.com by Think.COM; Tue, 6 Dec 88 13:52:42 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 6 Dec 88 14:30:50 EST
Received: by verdi.think.com; Tue, 6 Dec 88 14:29:22 EST
Date: Tue, 6 Dec 88 14:29:22 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8812061929.AA12814@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: New proposed issue APPEND-ATOM
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Tue, 10 Jan 89 18:47 EST
Resent-Message-ID: <890110184752.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

Issue:        APPEND-ATOM
References:   APPEND (p268)
	      Issue APPEND-DOTTED
Category:     CHANGE/CLARIFICATION
Edit history: 06-Dec-88 by Steele

Problem Description:

The issue APPEND-DOTTED, as passed by X3J13, contains a minor technical
flaw: it can be construed as leaving undefined the case where an argument
to APPEND other than the last is an atom.  The relevant paragraph of that
issue proposal is:

   In the degenerate case where there is no last cons (i.e., the argument is
   NIL) in any but the last list argument, clarify that the entire argument is
   effectively ignored. Point out that in this situation, if the last argument
   is a non-list, the result of APPEND or NCONC can be a non-list.

Here is the nit: the use of "i.e." leads one to believe that the
only degenerate case defined is that where the argument is NIL.
I suspect that "e.g." was intended, so as to make all atomic objects
ignored in other than the last argument.


Proposal (APPEND-ATOM:IGNORE):

In the degenerate case where there is no last cons (i.e., the argument
is an atom) in any but the last list argument, clarify that the entire
argument is effectively ignored. Point out that in this situation, if
the last argument is a non-list, the result of APPEND or NCONC can be
a non-list.

Proposal (APPEND-ATOM:ERROR)

In the degenerate case where there is no last cons (i.e., the argument
is an atom) in any but the last list argument, clarify that a value of
NIL is treated as an empty list and therefore effectively ignored, and
any other atom is an error. Point out that in this situation, if the
last argument is a non-list, the result of APPEND or NCONC can be a
non-list.


Examples (APPEND-ATOM:DOTTED):

(APPEND '(a b) 'MOOSE '(c . d)) => (a b c . d)	;Proposed
(NCONC '(a b) 'MOUSSE '(c . d)) => (a b c . d)	;Proposed

(APPEND 'GUACAMOLE 17) => 17			;Proposed
(NCONC 'SAUERKRAUT 17) => 17			;Proposed

Under APPEND-ATOM:ERROR these cases would all be errors.


Rationale: 

APPEND-ATOM:IGNORE makes a boundary case (a "zero-length dotted list")
consistent with other cases handled by the proposal APPEND-DOTTED:REPLACE.

APPEND-ATOM:ERROR would at least resolve a possible ambiguity.


Current Practice:

Lucid Lisp, KCL, and Symbolics Common Lisp all signal an error in both
interpreted and compiled code.


Cost to implementors:

Technically, the change for APPEND-ATOM:IGNORE should be relatively
small for those implementations which don't already implement it.
However, implementations which have microcoded APPEND or NCONC
incompatibly may find the small change somewhat painful.

Some implementations may have optimized their APPEND or NCONC to expect only
NIL when SAFETY is 0. In this case, depending on implementation details,
requiring an ATOM check rather than a NULL check may slow things down.


Cost to users:

Each proposal is upward compatible.


Benefits:

Since dotted lists are allowed as a non-last argument, readers will
probably assume that the boundary case of a zero-length dotted list
(that is, an atom) also works, something that doesn't appear to be
guaranteed by a strict reading. Proposal APPEND-ATOM:IGNORE would
happen to legitimize such assumptions.

Aesthetics:

Whether or not users will think this improves the aesthetics of the language
will depend largely on how they view the relation between lists and dotted
lists. Those who view dotted lists as a special kind of list may feel
differently than those who view lists as a special kind of dotted list.

The downside of APPEND-ATOM:IGNORE is that APPEND is supposed to
operate on lists, and it is mildly offensive to let it accept atoms,
and worse yet to ignore them.  Furthermore, a certain amount of useful
error checking may be lost.

Discussion:

Guy Steele supports proposal APPEND-ATOM:IGNORE, but with some qualms.
He raises it mainly because of the possibility that
APPEND-DOTTED:REPLACE was not worded exactly as intended.

∂10-Jan-89  1551	CL-Cleanup-mailer 	Re: New proposed issue APPEND-ATOM  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89  15:51:15 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 518871; 10 Jan 89 18:49:30 EST
Return-path: <CL-Cleanup-mailer@SAIL.STANFORD.EDU>
Received: from SAIL.STANFORD.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 504326; 6 Dec 88 21:21:40 EST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Dec 88  18:08:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 06 DEC 88 17:58:06 PST
Date: 6 Dec 88 17:57 PST
From: masinter.pa@Xerox.COM
Subject: Re: New proposed issue APPEND-ATOM
In-reply-to: Guy Steele <gls@Think.COM>'s message of Tue, 6 Dec 88 14:29:22
 EST
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881206-175806-7312@Xerox>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Tue, 10 Jan 89 18:49 EST
Resent-Message-ID: <890110184912.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

For Current Practice, Envos Medley implements APPEND-ATOM:IGNORE; it was
more compatible with the Interlisp definition of APPEND.


∂10-Jan-89  1552	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-COPY-PLIST  
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89  15:52:01 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 10 Jan 89 18:42:52 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 10 Jan 89 18:48:05 EST
Date: Tue, 10 Jan 89 18:48 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: COPY-SYMBOL-COPY-PLIST
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890110173307.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-Id: <19890110234853.0.BARMAR@OCCAM.THINK.COM>

    Date: Tue, 10 Jan 89 17:33 EST
    From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>

	Date: Tue, 10 Jan 89 13:17 EST
	From: Barry Margolin <barmar@Think.COM>

	...
	Rationale:

	COPY-LIST is the simplest list-copying primitive.
	...

    In my book it's the -only- list-copying primitive. COPY-TREE doesn't
    copy lists, it copies trees. Abstractly, there is no relationship
    between the two except for people who think it's a bug that
     (MEMBER 'A '(B (A) C))
    doesn't find A in the given list.

If you're going to play semantic games, MEMBER searches sets, not lists.

If the definition of what it means to "copy a list" were obvious, CLtL
wouldn't need three sentences to describe it, it could simply say
"copies the list and returns the copy."  Also, the description of
COPY-LIST doesn't mention that it is THE copier for the abstract type
"list" (the first sentences of the COPY-ALIST and COPY-TREE descriptions
DO say something to that effect for their respective abstract types), it
merely describes the operation of the function.  Readers of standards
are not supposed to make assumptions based on names, so one can't assume
that copying lists in general implies COPY-LIST.

    I don't think there's much issue here, but I'm happy to go along with it
    if you think there is.

    If we do proceed, I'd go so far as to say that Kathy might want to
    document that wherever in plain text the phrase "copy the list" is used,
    the equivalent of COPY-LIST is intended, that wherever in plain text the
    phrase "copy the tree" is used, the equivalent of COPY-TREE is intended,
    and that wherever in plain text the phrase "copy the alist" is used, the
    equivalent of COPY-ALIST is intended.  This would save us having 42 more
    of these issues come up now that you've opened this particular box
    marked "Pandora"...

I agree with you in principle, but I don't think this particular case is
so obvious that it goes without saying.  What CLtL actually says in this
case is "the property list of the new symbol will be a copy of SYM's."
The problem is that COPY-TREE produces a result that has many of the
same properties as that produced by COPY-LIST, and in the case of
copying property lists it may not be so obvious which of these
properties are important.  If there were a COPY-PLIST function it would
be pretty obvious that its semantics were intended; if there were such a
function, it might conceivably copy even elements differently from odd
elements, if we were to decide that indicators and values had different
important properties.  An implementor of COPY-SYMBOL might think that
such different semantics are necessary even without the existence of
such a function.

I don't think the Pandora's box is that big.  I don't think there are
many places where lists or trees are automatically copied.  I can't
think offhand of ANY place where it might say "copy the tree" (I think
the only standard functions that know about trees as an abstract object
are TREE-EQUAL, COPY-TREE, SUBST and its variants, and SUBLIS and its
variants).

The Pandora's box isn't empty, though.  I just noticed that COPY-SEQ
doesn't specify precisely how the sequence is copied.  In fact, COPY-SEQ
says that it is equivalent to (SUBSEQ sequence 0), and the description
of SUBSEQ says "it never shares storage with an old sequence."  You and
I know that the latter means "it never shares top-level storage", but it
could easily be interpreted to mean that none of the storage of the
original object is shared.  We know that because we understand how Lisp
differentiates between a structured object and its contents, but most
traditional languages don't make such a distinction, so I think it is
important that the CL standard not presume this abstract understanding.

I'm currently writing a paper about copying and equality that I hope to
have done in time to distribute at the meeting, and it has sensitized me
to the need to specify these things explicitly.  Also, if we don't
correct them now, I'll wager we'll have to after the standard goes out
for public review (I've seen the kinds of comments that come back from
ANSI public reviews, and they can find an amazing number of nits to
pick).

                                                barmar

∂10-Jan-89  1556	CL-Cleanup-mailer 	Possible issue: GCD-NO-ARGUMENTS    
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 10 Jan 89  15:54:01 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa09063; 10 Jan 89 23:35 GMT
Date: Tue, 10 Jan 89 23:37:00 GMT
Message-Id: <15927.8901102337@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Possible issue: GCD-NO-ARGUMENTS
To: cl-cleanup@sail.stanford.edu, gls@think.com
Cc: richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK

Richard Tobin, who shares my office, has mentioned from time to time
that both (LCM) and (GCD) are wrong in CLtL, because LCM should allow
zero arguments and GCD should not.  I see there is a cleanup issue for
LCM, and, if he is right, we should also chage GCD.  So I asked for a
message stating his views on GCD.  Here it is:

---- Start of forwarded text ----

Date: Tue, 10 Jan 89 20:52:26 GMT
From: Richard Tobin <R.Tobin@uk.ac.ed>
To: jeff@ed.aiai
Subject: GCD in CLtL

CLtL defines (gcd) as zero, which seems bogus to me.  It should be
undefined, as should (gcd 0).  The reasoning goes like this:

Let f be a function that takes an arbitrary number of arguments.  If
there is an "identity" i, such that (f -some-args- i) is always the
same as (f -some-args-), then the value of (f) should be the same as
(f i), if that is defined.  So far, so good.

But 0 is certainly not the greatest common divisor of 0.  All integers
divide 0.  Furthermore, (gcd -some-args- -another-arg-) should never be
greater than (gcd -some-args-), since it adds a constraint to the set of
numbers of which we are computing the greatest.  But if (gcd 0) is 0,
(gcd 4 0) (ie 4) is greater then (gcd 0).

The only reasonable value for (gcd 0) would be some representation of
infinity, but we don't have one, so it should be undefined.

-- Richard

---- End of forwarded text ----

∂10-Jan-89  1610	CL-Cleanup-mailer 	cleanup ballot  
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 10 Jan 89  16:10:28 PST
Posted-Date: Tue, 10 Jan 89 16:10:16 PST
Message-Id: <8901110010.AA02905@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
	id AA02905; Tue, 10 Jan 89 16:10:22 PST
To: cl-cleanup@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: cleanup ballot
Date: Tue, 10 Jan 89 16:10:16 PST
Sender: goldman@vaxa.isi.edu

Ballot submitted by Neil Goldman (Goldman@vaxa.isi.edu)
Organization:  USC/Information Sciences Institute
Status:  Interested Party -- not official position of organization


ARGUMENTS-UNDERSPECIFIED:SPECIFY
	Version 4, 21-Sep-88, Mailed 4 Dec 88
YES

ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
	Version 9, 31-Oct-88, Mailed 5 Dec 88
YES

CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
	Version 5,  5-Dec-88, Mailed 5 Dec 88
YES

CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
	Version 1, 14-Sep-88, Mailed 6 Oct 88
YES

DECLARATION-SCOPE:NO-HOISTING
YES
DECLARATION-SCOPE:LIMITED-HOISTING
NO
	Version 4, 15-Nov-88, Mailed 9-Dec-88

DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
	Version 4,  5-Dec-88, Mailed  5-Dec-88
YES

DECLARE-TYPE-FREE:ALLOW
	Version 8, 7-Dec-88, Mailed 9-Dec-88
YES

DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
	Version 2, 30-Sep-88, Mailed 6 Oct 88
YES

DEFPACKAGE:ADDITION
	Version 7, 2-Nov-88, Mailed 5 Dec 88
YES

DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
	Version 2, 21-Sep-88, Mailed 6 Oct 88
YES

DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
	Version 3, 7 Dec 88, Mailed 12-Dec-88
NO

DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
	Version 4, 31-Oct-88, Mailed 12-Dec-88
NO

DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE 
YES
DESCRIBE-INTERACTIVE:NO
NO
	Version 4, 15-Nov-88	, Mailed 7-Dec-88

DOTTED-MACRO-FORMS:ALLOW
	Version 3, 15-Nov-88, Mailed 7-Dec-88
YES

EQUAL-STRUCTURE:STATUS-QUO
	Version 5, 1-Oct-88, Mailed 8 Oct 88
YES

EXIT-EXTENT:MINIMAL
NO
EXIT-EXTENT:MEDIUM
YES
	Version 5, 12-Dec-88, Mailed 12-Dec-88

EXPT-RATIO:P.211
	Version 3, 31-Oct-88, Mailed 7 Dec 88
ABSTAIN

FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
NO
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
YES
	Version 4, 7-Dec-88, Mailed 12-Dec-88

FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
	Version 2, 2 Oct 88, Mailed 6 Oct 88
ABSTAIN

FORMAT-PRETTY-PRINT:YES
	Version 7, 15 Dec 88, Mailed 7 Dec 88
YES

FUNCTION-COMPOSITION:NEW-FUNCTIONS
NO
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
NO
	Version 4, 12 Dec 88, Mailed 12 Dec 88

FUNCTION-DEFINITION:FUNCTION-SOURCE
	Version 2, 09-Dec-88	, Mailed 9 Dec 88
NO

FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
	Version 3, 7-Dec-88, Mailed  12-Dec-88
YES

FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
	Version 5, 14-Nov-88	, Mailed 8-Dec-88
NO

GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
	Version 2, 8 Dec 88, Mailed 8 Dec 88
YES

HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
	Version 7, 8-Dec-88, Mailed 9-Dec-88
YES

HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
	Version 1, 11-Nov-88	, Mailed 12 Dec 88
NO

HASH-TABLE-TESTS:ADD-EQUALP
	Version 2, 8-Dec-88, Mailed 8 Dec 88
YES

IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
	Version 4, 12-Dec-88, Mailed 12-Dec-88
YES

LAMBDA-FORM:NEW-MACRO
	Version 4, 22-Nov-88, Mailed 8-Dec-88
NO

LCM-NO-ARGUMENTS:1
	Version 1, 17 Oct 88, Mailed 8 Dec 88
YES

LISP-SYMBOL-REDEFINITION:DISALLOW
	Version 5, 22-Nov-88, Mailed 8 Dec 88
YES

MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
	Version 2, 8 Oct 88, Mailed 12-Dec-88
NO

MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
	Version 2, 09-Jun-88, Mailed 8 Oct 88
YES

NTH-VALUE:ADD
	Version 4, 8-Dec-88, Mailed 8 Dec 88
YES

PACKAGE-CLUTTER:REDUCE
	Version 6, 12-Dec-88, Mailed 12-Dec-881
YES

PACKAGE-DELETION:NEW-FUNCTION
	Version 5, 21 nov 88, Mailed 8 Dec 88
YES

PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
	Version 1 27-Jun-88, Mailed 7 Oct 88
YES

PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
	Version 3, 8-Oct-88, Mailed 8 Oct 88
YES

PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
	Version 3, 20 Sep 88, Mailed 8 Oct 88
YES

PROCLAIM-LEXICAL:LG
	Version 9, 8-Dec-88, Mailed 12-Dec-88
YES

RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
	Version 3, 9-Oct-88, Mailed 14-Oct-88
YES

RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
	Version 1, 14-Sep-88, Mailed 7 Oct 88
YES

REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
	Version 6, 9 Dec 88, mailed 09 Dec 88
NO

REST-LIST-ALLOCATION:NEWLY-ALLOCATED
NO
REST-LIST-ALLOCATION:MAY-SHARE
YES
REST-LIST-ALLOCATION:MUST-SHARE
	Version 3, 12-Dec-88, mailed 12-Dec-88
NO

RETURN-VALUES-UNSPECIFIED:SPECIFY
	Version 6,  9 Dec 88 mailed  9-Dec-88
YES

ROOM-DEFAULT-ARGUMENT:NEW-VALUE
	Version 1 12-Sep-88 mailed 8 Oct 88
YES

[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
	Version 3, 4-Nov-87, mailed Nov 87
YES

SETF-PLACES:ADD-SETF-FUNCTIONS
	Version 1, 11-Nov-88, mailed 9-Dec-88
NO

SETF-SUB-METHODS:DELAYED-ACCESS-STORES
	Version 5, 12-Feb-88 mailed 8 Oct 88
YES

STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
	Version 8, 8 Jul 88, Mailed 7 Oct 88
YES

STEP-ENVIRONMENT:CURRENT
	Version 3, 20-Jun-88, mailed  7 Oct 88
YES

STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
NO
STREAM-ACCESS:ADD-TYPES-ACCESSORS
YES
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
NO
	version 2, 30-Nov-88 mailed  9 Dec 88
	(expect amendment T => "true")


STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
	Version 6, 30-Nov-88, mailed 9 dec 88
	expect amendment:
		LINE-WIDTH   ==> STREAM-LINE-WIDTH
		LINE-POSITION ==> STREAM-LINE-POSITION
		PRINTED-WIDTH ==> STREAM-STRING-WIDTH
YES

SUBTYPEP-TOO-VAGUE:CLARIFY
	Version 4,  7-Oct-88, mailed 7 Oct 88 
YES

SYMBOL-MACROLET-DECLARE:ALLOW
	Version 2,  9-Dec-88, mailed 9 Dec 88
YES

SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
	Version 5, 30-Nov-88, mailed 9 Dec 88
YES

TAGBODY-CONTENTS:FORBID-EXTENSION
	Version 5, 9-Dec-88 mailed 9 Dec 88
ABSTAIN

TAILP-NIL:T
	Version 5, 9-Dec-88, mailed 12-Dec-88
ABSTAIN

TEST-NOT-IF-NOT:FLUSH-ALL
NO
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
YES
	Version 3, 1 Dec 88 mailed 9 dec 

TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
	Version 3, 12-Dec-88, mailed 12 Dec 88
	(some "bugs" in the proposal)
YES

UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
	Version 2, 2-Dec-88, mailed 12-Dec-88
YES

VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
	Version 3, 08-Oct-88, mailed 9 Dec 88
YES

∂10-Jan-89  1610	CL-Cleanup-mailer 	cleanup ballot  
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 10 Jan 89  16:10:28 PST
Posted-Date: Tue, 10 Jan 89 16:10:16 PST
Message-Id: <8901110010.AA02902@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
	id AA02902; Tue, 10 Jan 89 16:10:20 PST
To: cl-cleanup@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: cleanup ballot
Date: Tue, 10 Jan 89 16:10:16 PST
Sender: goldman@vaxa.isi.edu

Ballot submitted by Neil Goldman (Goldman@vaxa.isi.edu)
Organization:  USC/Information Sciences Institute
Status:  Interested Party -- not official position of organization


ARGUMENTS-UNDERSPECIFIED:SPECIFY
	Version 4, 21-Sep-88, Mailed 4 Dec 88
YES

ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
	Version 9, 31-Oct-88, Mailed 5 Dec 88
YES

CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
	Version 5,  5-Dec-88, Mailed 5 Dec 88
YES

CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
	Version 1, 14-Sep-88, Mailed 6 Oct 88
YES

DECLARATION-SCOPE:NO-HOISTING
YES
DECLARATION-SCOPE:LIMITED-HOISTING
NO
	Version 4, 15-Nov-88, Mailed 9-Dec-88

DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
	Version 4,  5-Dec-88, Mailed  5-Dec-88
YES

DECLARE-TYPE-FREE:ALLOW
	Version 8, 7-Dec-88, Mailed 9-Dec-88
YES

DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
	Version 2, 30-Sep-88, Mailed 6 Oct 88
YES

DEFPACKAGE:ADDITION
	Version 7, 2-Nov-88, Mailed 5 Dec 88
YES

DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
	Version 2, 21-Sep-88, Mailed 6 Oct 88
YES

DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
	Version 3, 7 Dec 88, Mailed 12-Dec-88
NO

DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
	Version 4, 31-Oct-88, Mailed 12-Dec-88
NO

DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE 
YES
DESCRIBE-INTERACTIVE:NO
NO
	Version 4, 15-Nov-88	, Mailed 7-Dec-88

DOTTED-MACRO-FORMS:ALLOW
	Version 3, 15-Nov-88, Mailed 7-Dec-88
YES

EQUAL-STRUCTURE:STATUS-QUO
	Version 5, 1-Oct-88, Mailed 8 Oct 88
YES

EXIT-EXTENT:MINIMAL
NO
EXIT-EXTENT:MEDIUM
YES
	Version 5, 12-Dec-88, Mailed 12-Dec-88

EXPT-RATIO:P.211
	Version 3, 31-Oct-88, Mailed 7 Dec 88
ABSTAIN

FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
NO
FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
YES
	Version 4, 7-Dec-88, Mailed 12-Dec-88

FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
	Version 2, 2 Oct 88, Mailed 6 Oct 88
ABSTAIN

FORMAT-PRETTY-PRINT:YES
	Version 7, 15 Dec 88, Mailed 7 Dec 88
YES

FUNCTION-COMPOSITION:NEW-FUNCTIONS
NO
FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
NO
	Version 4, 12 Dec 88, Mailed 12 Dec 88

FUNCTION-DEFINITION:FUNCTION-SOURCE
	Version 2, 09-Dec-88	, Mailed 9 Dec 88
NO

FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
	Version 3, 7-Dec-88, Mailed  12-Dec-88
YES

FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
	Version 5, 14-Nov-88	, Mailed 8-Dec-88
NO

GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
	Version 2, 8 Dec 88, Mailed 8 Dec 88
YES

HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
	Version 7, 8-Dec-88, Mailed 9-Dec-88
YES

HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
	Version 1, 11-Nov-88	, Mailed 12 Dec 88
NO

HASH-TABLE-TESTS:ADD-EQUALP
	Version 2, 8-Dec-88, Mailed 8 Dec 88
YES

IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
	Version 4, 12-Dec-88, Mailed 12-Dec-88
YES

LAMBDA-FORM:NEW-MACRO
	Version 4, 22-Nov-88, Mailed 8-Dec-88
NO

LCM-NO-ARGUMENTS:1
	Version 1, 17 Oct 88, Mailed 8 Dec 88
YES

LISP-SYMBOL-REDEFINITION:DISALLOW
	Version 5, 22-Nov-88, Mailed 8 Dec 88
YES

MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
	Version 2, 8 Oct 88, Mailed 12-Dec-88
NO

MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
	Version 2, 09-Jun-88, Mailed 8 Oct 88
YES

NTH-VALUE:ADD
	Version 4, 8-Dec-88, Mailed 8 Dec 88
YES

PACKAGE-CLUTTER:REDUCE
	Version 6, 12-Dec-88, Mailed 12-Dec-881
YES

PACKAGE-DELETION:NEW-FUNCTION
	Version 5, 21 nov 88, Mailed 8 Dec 88
YES

PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
	Version 1 27-Jun-88, Mailed 7 Oct 88
YES

PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
	Version 3, 8-Oct-88, Mailed 8 Oct 88
YES

PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
	Version 3, 20 Sep 88, Mailed 8 Oct 88
YES

PROCLAIM-LEXICAL:LG
	Version 9, 8-Dec-88, Mailed 12-Dec-88
YES

RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
	Version 3, 9-Oct-88, Mailed 14-Oct-88
YES

RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
	Version 1, 14-Sep-88, Mailed 7 Oct 88
YES

REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
	Version 6, 9 Dec 88, mailed 09 Dec 88
NO

REST-LIST-ALLOCATION:NEWLY-ALLOCATED
NO
REST-LIST-ALLOCATION:MAY-SHARE
YES
REST-LIST-ALLOCATION:MUST-SHARE
	Version 3, 12-Dec-88, mailed 12-Dec-88
NO

RETURN-VALUES-UNSPECIFIED:SPECIFY
	Version 6,  9 Dec 88 mailed  9-Dec-88
YES

ROOM-DEFAULT-ARGUMENT:NEW-VALUE
	Version 1 12-Sep-88 mailed 8 Oct 88
YES

[The following are mutually exclusive]
SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
	Version 3, 4-Nov-87, mailed Nov 87
YES

SETF-PLACES:ADD-SETF-FUNCTIONS
	Version 1, 11-Nov-88, mailed 9-Dec-88
NO

SETF-SUB-METHODS:DELAYED-ACCESS-STORES
	Version 5, 12-Feb-88 mailed 8 Oct 88
YES

STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
	Version 8, 8 Jul 88, Mailed 7 Oct 88
YES

STEP-ENVIRONMENT:CURRENT
	Version 3, 20-Jun-88, mailed  7 Oct 88
YES

STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
NO
STREAM-ACCESS:ADD-TYPES-ACCESSORS
YES
STREAM-ACCESS:ADD-PREDICATES-ACCESSORS
NO
	version 2, 30-Nov-88 mailed  9 Dec 88
	(expect amendment T => "true")


STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
	Version 6, 30-Nov-88, mailed 9 dec 88
	expect amendment:
		LINE-WIDTH   ==> STREAM-LINE-WIDTH
		LINE-POSITION ==> STREAM-LINE-POSITION
		PRINTED-WIDTH ==> STREAM-STRING-WIDTH
YES

SUBTYPEP-TOO-VAGUE:CLARIFY
	Version 4,  7-Oct-88, mailed 7 Oct 88 
YES

SYMBOL-MACROLET-DECLARE:ALLOW
	Version 2,  9-Dec-88, mailed 9 Dec 88
YES

SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
	Version 5, 30-Nov-88, mailed 9 Dec 88
YES

TAGBODY-CONTENTS:FORBID-EXTENSION
	Version 5, 9-Dec-88 mailed 9 Dec 88
ABSTAIN

TAILP-NIL:T
	Version 5, 9-Dec-88, mailed 12-Dec-88
ABSTAIN

TEST-NOT-IF-NOT:FLUSH-ALL
NO
TEST-NOT-IF-NOT:FLUSH-TEST-NOT
YES
	Version 3, 1 Dec 88 mailed 9 dec 

TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
	Version 3, 12-Dec-88, mailed 12 Dec 88
	(some "bugs" in the proposal)
YES

UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
	Version 2, 2-Dec-88, mailed 12-Dec-88
YES

VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
	Version 3, 08-Oct-88, mailed 9 Dec 88
YES

∂10-Jan-89  2248	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 9)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 10 Jan 89  22:48:18 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03151g; Tue, 10 Jan 89 22:44:06 PST
Received: by bhopal id AA03335g; Tue, 10 Jan 89 22:46:24 PST
Date: Tue, 10 Jan 89 22:46:24 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901110646.AA03335@bhopal>
To: Gray@DSG.csc.ti.com
Cc: masinter.pa@Xerox.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: David N Gray's message of Tue, 10 Jan 89  10:57:15 CST <2809443435-15097074@Kelvin>
Subject: Issue: DECLARE-TYPE-FREE (Version 9)

Well, one of two things needs to be done (and fast!).  Either:

  1. merge SPECIAL-TYPE-SHADOWING:CLARIFY into DECLARE-TYPE-FREE, 
     enlarging the latter to cover PROCLAIM as well as DECLARE.

  2. keep two separate issues, but reconcile the semantics of
     nested, non-identical declarations.

Either way, the "reconcilation" will have to be done [I tend to
favor two separate issues at this point.]

I think you are right that the matter of semantics for nested declarations
isn't adequately treated in the DECLARE-TYPE-FREE proposal.  Sigh.  In
order to accommodate those who argued that mechanical code production
might not be able to guarantee a true SUBTYPE relation for the inner
declarations, I would go for a version that treated an inner declaration
as if it were the intersection of the outter one.  How about you?  In
the example:
   (proclaim '(type some-var (or symbol integer)))
   (let ((x (mumble)))
     (declare (type x number))
     ...
     (locally (declare (type x (or bit character)))
       ;; 'x' is effectively declared to be of type BIT here
     ))
the inner declarations are not subtypes of the outter ones, but at
least the intersections are non-null.


-- JonL --

∂11-Jan-89  0004	CL-Cleanup-mailer 	Issue: SETF-SUB-METHODS (Version 5) 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Jan 89  00:04:40 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03190g; Wed, 11 Jan 89 00:00:30 PST
Received: by bhopal id AA03531g; Wed, 11 Jan 89 00:02:47 PST
Date: Wed, 11 Jan 89 00:02:47 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901110802.AA03531@bhopal>
To: cperdue@Sun.COM
Cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: Cris Perdue's message of Tue, 10 Jan 89 10:41:42 PST <8901101841.AA13760@clam.sun.com>
Subject:  Issue: SETF-SUB-METHODS (Version 5)

re: Consider example 6.
      (setq s (setq r (list 'a 1 'b 2 'c 3)))
      (setf (getf r 'b) (progn (setq r nil) 6))
      r ==> (b 6)
      s ==> (a 1 b 2 c 3)
    I find the SETF expression naturally maps to:
    (setf r (put-plist r 'b (progn (setq r nil) 6)))

This is the conceptual bug you make if you fail to notice the
distinction between evaluating the "value-producing subforms"  and
"reading the value" out of the generalized location.  The top part
of the second page of the proposal tries to warn the reader about
this by saying:
   "``reading the value'' of a generalized variable reference is not
    part of the series of evaluatons that must be done in left-to-right
    order."
Of course, Test Case 6 is a worst-case pun of sorts, since "reading
the value" is exactly the same set of computer instructions as
"evaluating the value-producing subforms".  It is a malice-aforethough
worst-case test, just to illustrate the point.  [Incidentally, these are 
Test Cases rather than Examples.]

We are fully aware that this is (A) a "fine point" and (B) a very
detailed point.  However, failure to specify the details correctly will
lead to an incorrect implementation, especially in regard to the Test
Case 2.  A previous proposal had that flaw, and we didn't notice until
actually coding it up and observing some previously working code
breaking.  At least it isn't three pages of dense specification, since
most all of the three parts are isomorphic.  But someone on the
subcommittee objected to a specification that was loosely worded like
"and similarly for CHAR-BIT and LDB etc.".


Since this is a Clarification (not an addition or change) of what we 
think CLtL already says or implies, then a "No" vote is not nearly so
meaningful as an alternate clarification.  I think you will find it
is not so easy a task to specify a general rule for sub-form semantics
if you base it only on the more limited reading of Test Case 6.
Test Case 2 must be accommodated also.



-- JonL --

∂11-Jan-89  0126	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Jan 89  01:26:22 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03246g; Wed, 11 Jan 89 01:22:16 PST
Received: by bhopal id AA03698g; Wed, 11 Jan 89 01:24:32 PST
Date: Wed, 11 Jan 89 01:24:32 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901110924.AA03698@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@Sail.Stanford.Edu
In-Reply-To: masinter.pa@Xerox.COM's message of 10 Jan 89 14:41 PST <890110-144153-6753@Xerox>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)

re: The benefit of UPGRADE-ARRAY-ELEMENT-TYPE--namely, that it doesn't
    CONS as much as the portable definition--seems very small and I don't think
    it outweighs the cost.

No, Larry, the issue isn't that it "doesn't CONS as much", but that it
"doesn't CONS *at all*".  This kind of issue is critical to some vendors,
such as Inference (which is why Joe Ginder was worrying about the
implicit consing in &rest args and in the sequence functions.)

See CLtL, p292, definition of ARRAY-DIMENSION.  Applying the reasoning
that I am now trying to rebut, you would wind up with:

   (defun array-dimension (array axis-number)
     (elt (array-dimensions array) axis-number))

Why do you suppose that CLtL included ARRAY-DIMENSION in the standard?
How about ARRAY-TOTAL-SIZE? and ARRAY-ROW-MAJOR-INDEX?


-- JonL --

∂11-Jan-89  1217	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Jan 89  08:08:19 PST
Received: by ti.com id AA09880; Wed, 11 Jan 89 10:21:03 CST
Received: from Kelvin by tilde id AA22744; Wed, 11 Jan 89 10:08:23 CST
Message-Id: <2809527001-3602765@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 11 Jan 89  10:10:01 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Jon L White <jonl@lucid.com>
Cc: masinter.pa@Xerox.COM, CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
In-Reply-To: Msg of Tue, 10 Jan 89 22:46:24 PST from Jon L White <jonl@lucid.com>

> I think you are right that the matter of semantics for nested declarations
> isn't adequately treated in the DECLARE-TYPE-FREE proposal.  Sigh.  In
> order to accommodate those who argued that mechanical code production
> might not be able to guarantee a true SUBTYPE relation for the inner
> declarations, I would go for a version that treated an inner declaration
> as if it were the intersection of the outter one.  How about you?

Agreed.  That's what version 6 of DECLARE-TYPE-FREE said:

    Clarify that if nested type declarations refer to the same variable,
    then the value of the variable must be a member of the intersection of
    the declared types.

∂11-Jan-89  1429	CL-Cleanup-mailer 	Issue: EQUAL-STRUCTURE (Version 6)  
Received: from SAPSUCKER.SCRC.Symbolics.COM ([128.81.41.223]) by SAIL.Stanford.EDU with TCP; 11 Jan 89  12:22:39 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 268293; Wed 11-Jan-89 14:42:07 EST
Date: Wed, 11 Jan 89 14:39 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 6)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890111143950.8.KMP@BOBOLINK.SCRC.Symbolics.COM>

Here's another draft. I changed only the proposal part. It tries
to correct the EQUALP problem we and others mentioned in mail.

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.

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

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: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			descends
   other Array			uses EQ			descends
   Instance (Standard-Object)	uses EQ			descends
   Hash-Table    		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.

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

∂11-Jan-89  1430	CL-Cleanup-mailer 	Issue: APPLYHOOK-ENVIRONMENT (Version 2) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89  12:24:55 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 519255; 11 Jan 89 12:08:07 EST
Date: Wed, 11 Jan 89 12:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: APPLYHOOK-ENVIRONMENT (Version 2)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <890110-154231-6930@Xerox>
Message-ID: <890111120758.5.KMP@BOBOLINK.SCRC.Symbolics.COM>

[X3J13 removed.]

For compatibility, we might want to consider either explicitly
permitting implementations to accept a third optional argument
to APPLYHOOK, which would be defined to be ignored, or else
actually require implementations to accept such an argument.

In the Cost to Users, you should highlight that the reason for
making the third argument optional is only for source compatibility
with CLtL. There should be no doubt that the value of *APPLYHOOK*
will only receive only two arguments.

Anyway, I approve of this proposal, whether the writeup is 
ultimately ammended or not.

∂11-Jan-89  1431	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89  12:25:07 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 519258; 11 Jan 89 12:20:25 EST
Date: Wed, 11 Jan 89 12:20 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 9)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19890103003245.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <890111122017.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

Btw, I spoke last week on the phone to Jonathan Rees about this. He's not
yet gotten around to sending mail but he said...
  - he doesn't think the ALLOW proposal is a good idea
  - the ALLOW proposal is inconsistent with the proposal in
    SYMBOL-MACROLET-SEMANTICS
He hadn't seen the actual LEXICAL proposal yet, but from my description
of the differences, he seemed pretty firm on the idea that it was the
right idea.

∂11-Jan-89  1430	CL-Cleanup-mailer 	Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 4) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89  12:24:38 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 519251; Wed 11-Jan-89 11:57:21 EST
Date: Wed, 11 Jan 89 11:57 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 4)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.edu
In-Reply-To: <890106-114801-253@Xerox>
Message-ID: <890111115708.4.KMP@BOBOLINK.SCRC.Symbolics.COM>

A new proposal follows this initial commentary...

Current practice is ammended for Lucid and IIM. Please check for
accuracy.

The proposal is ammended per my responses to the following mail
from Larry:

    Date: 6 Jan 89 11:37 PST
    From: masinter.pa@Xerox.COM

    I'd like to see the following changes to the proposal:

    a) I don't like saying that the effect of adjusting an array which "is not
    adjustable" is not defined. I don't see any reason not to say that it
    signals an error. 

It actually said this already (last paragraph), but it also had a
conflicting paragraph which I removed. Please check the result to see that
it is coherent.

    b) I like defining clearly that "is not adjustable" means
    "ADJUSTABLE-ARRAY-P returns false", and clarifying that MAKE-ARRAY may
    return an adjustable array even if the :ADJUSTABLE array is given NIL.

Right. I think I made this more clear.

    c) I would like to say that either all arrays are adjustable, or else only
    those that are specified with :ADJUSTABLE true, and that a conformal
    implementation will document which behavior it uses.

I think this complicates the user model because it suggests that there is
advantage to be had from knowing that all arrays are adjustable. I can't
imagine any serious way in which a truly portable program could take
advantage of this information even if we could guarantee it.

In fact, though, the Symbolics implementation makes -most- but not all
arrays adjustable. There are some odd situations involving displaced arrays
where I'm told the arrays are not adjustable. So we couldn't be conforming if
you did this. I therefore made no change.

    d) Rename the proposal name from "STATUS-QUO" to "MAY-BE-ADJUSTABLE" and
    change  "Document clearly" to "Specify". 

It wasn't clear what the noun was in "may be adjustable", so I avoided this
name and tried to pick a name that had no connotations at all: DONKEY.
(Surely there's no chance anyone will even think to connect the spirit of
this proposal or the character of its author with derogatory synonyms,
stubborn animals, or Massachusetts liberal democrats... :-) Anyway, hopefully
this will avoid wasted discussion on a supposedly semantics-free symbol.

    Is this OK?

Except for item C, I think I've done the best I could. Proposal follows...

-----
Issue:        ADJUST-ARRAY-NOT-ADJUSTABLE
References:   ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
	      MAKE-ARRAY (pp286-289)
Category:     CLARIFICATION/CHANGE
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
Status:	      For Internal Discussion

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.

  Some of the original Common Lisp designers assert that the
  :ADJUSTABLE option exists in order to allow a user to select
  between getting adjustable and non-adjustable arrays.
  
  Others of the original Common Lisp designers assert that the
  :ADJUSTABLE option existed to permit implementations in which
  making all arrays adjustable was very expensive to make some
  arrays not adjustable.

  The former camp therefore believes that :ADJUSTABLE NIL means
  that the array MUST be non-adjustable. The latter camp believes
  that :ADJUSTABLE NIL means that the array MIGHT be non-adjustable.

  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.'' Although this sentence
  is slightly ambiguous (one might argue that :ADJUSTABLE NIL
  involves supplying the :ADJUSTABLE option), it is generally
  interpreted to mean that ``... with :ADJUSTABLE T.'' 

  One problem is that since ADJUSTABLE-ARRAY-P does not predicate
  whether the :ADJUSTABLE option was provided, then
  ADJUSTABLE-ARRAY-P is not an appropriate predicate in all
  implementations to determine whether an array is adjustable.
  Technically, :ADJUSTABLE NIL could create and adjustable array
  (one for which ADJUSTABLE-ARRAY-P returns true), and yet 
  ADJUST-ARRAY might refuse to adjust it (if it had recorded a
  separate bit saying whether :ADJUSTABLE T had been specified
  and used that bit for ADJUST-ARRAY). Fortunately, this problem
  has not been observed to occur in practice, but it is present
  in principle.
  
  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. That expectation is violated by
  legitimate implementations, since it is permissible for an 
  implementation to create an adjustable array even though it has
  not been asked for, and since calling adjust array on such an
  array "is an error" (and hence the behavior can be extended).

  This perceived lack of error checking may become a legitimate
  portability error to someone who has debugged his code in a 
  an implementation where :ADJUSTABLE NIL arrays might still be
  adjustable and then tried ported his code to an implementation
  which is more conservative in its interpretation.

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

  Define that omitting the :ADJUSTABLE option to MAKE-ARRAY or
  explicitly supplying :ADJUSTABLE NIL may not guarantee a
  non-adjustable array.

  Define that ADJUSTABLE-ARRAY-P -must- be true of an array created
  using :ADJUSTABLE T.

  Define that ADJUSTABLE-ARRAY-P -might- be true of an array created
  with no :ADJUSTABLE option or with :ADJUSTABLE NIL, but that it
  -might- return false.

  Clarify that the implication of the above is that saying that an
  array A "is adjustable" means that (ADJUSTABLE-ARRAY-P A) => true.
  Further clarify that the adjustability of an array has no necessary
  relation to any value was given (or not given) as the :ADJUSTABLE
  option in the call to MAKE-ARRAY which created the array A.

  Clarify that there is no portable way to create a non-adjustable
  array (that is, an array for which ADJUSTABLE-ARRAY-P is
  guaranteed to return false).

  Change the description of ADJUST-ARRAY to say that if an attempt
  is made to adjust an array which is not adjustable (that is, an
  array for which ADJUSTABLE-ARRAY-P would return false), an error
  will be signalled.

  Clarify that this legitimizes ADJUSTABLE-ARRAY-P as an appropriate
  predicate to determine whether ADJUST-ARRAY will reliably succeed.

Rationale:

  This effectively makes the status quo explicit.

  While changing this to a tighter interpretation would be desirable, some
  implementations have suggested that such a change might be very expensive
  or impossible given their existing data storage layouts.

  Although technically the changes to ADJUST-ARRAY are incompatible changes
  from the spec, it's not believed that there are any implementations which
  deviate, so we're still categorizing this as a clarification.

Current Practice:

  Probably everyone is compatible with this proposal. 

  Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
  and is compatible with this proposal.

  Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
  in all cases, 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.

Discussion:

  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.

∂11-Jan-89  1431	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89  12:25:42 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 519282; Wed 11-Jan-89 13:09:06 EST
Date: Wed, 11 Jan 89 13:08 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890105-221446-191@Xerox>
Message-ID: <890111130857.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 5 Jan 89 22:14 PST
    From: masinter.pa@Xerox.COM

    The example I keep coming back to is one where it isn't so much that the
    local declaration is easy to enforce as it is where it is difficult *not*
    to enforce it.

    Suppose I have

    (defun frob (delta)
     (flet ((more (x) (+ x delta)))
	    ;; if you like, put (declare (inline more)) here
       (typecase delta
	    (float (locally (declare (type float delta))
		    ... (more rho ) ... ))

	   ((signed-byte 8)
		    (locally (declare (type (signed-byte 8) delta))
		    ... (more zz) ... ))
	...)))

[Parens added.]

    Even without the inline, it is a common & legal transformation to do inline
    substitution on "small" fletted functions.

Absolutely. But not textually. Semantically. For example, you already
have to watch for:

(defun add (x y) (+ x y))

(defun frob (delta)
  (flet ((more (x) (add x delta)))
    (flet ((add (x y) (- x y)))
      ... (more x) ...)))

    Even though the reference "delta" in the definition of more isn't
    within the lexical scope of the local declaration, it *is* the same
    delta.

Right. But that itself implies nothing.

    While its not impossible to maintain a separate contour in order to
    segregate the type declarations, it seems like unnecessary work, 

It is not unnecessary. You cannot just substitute a piece of unadorned
text. You have to do the substitution at a lower level using an adorned
call tree or else you have to have resolved out all the relevant lexical 
things before you start merging source (ie, you have to have assured that
the flet problem is not going to happen). If your approach is the former,
it's possible (maybe even "easy" or at least "standard practice") to
represent every reference to a variable with a pointer to the lexical
environment it came from, so you can get the lookup right. If your
approach is the latter, then it's possible to make all the declarations
explicit as you do the code-walk looking for flets and whatnot so that
you don't have to rely on DECLARE info afterward. In that case, the result
of your traversal should be:

 (defun frob (delta)
   (typecase delta
     (float ... ((lambda (x) (+ x delta)) rho) ...)
     ((signed-byte 8)
      ... ((lambda (x) (+ x delta)) zz) ... )
     ...))

    ... and in fact, the declaration is quite useful if "more" is inlined.

Actually, in this case it doesn't provide any information that
the compiler can't figure out from the TYPECASE. A good compiler
is not limited in its type inferencing to what has been declared.
It can tell that no SETQ is going on, so it can propagate the type
from the TYPECASE directly without even the aid of the DECLARE.

Let's look at a better example which is opaque to the compiler:

(defun frob (n m)
  (frob1 (cond ((and (typep n 'fixnum) (typep m 'fixnum)) 'fixnum)
	       ((and (typep n 'float)  (typep m 'float))  'float)
	       (t 't))
	 n m))

(defun frob1 (type n m)
  (flet ((zap () (+ n m)))
    (case type
      (fixnum (locally (declare (fixnum n m)) (zap)))
      (float  (locally (declare (float  n m)) (zap)))
      (otherwise (zap)))))

In this case, I agree you're potentially losing some slight amount
of efficiency, but ...

 (a) You could use MACROLET instead to get back that efficiency.
     I personally believe that it is stylistically the correct
     thing for this situation.

 (b) There is a twin brother of this example which I don't want to
     let through, and which your proposal would force me to reckon
     with:

     (defun frob (n m)
       (frob1 (cond ((and (typep n 'fixnum) (typep m 'fixnum)) 'fixnum)
		    ((and (typep n 'float)  (typep m 'float))  'float)
		    (t 't))
	      #'(lambda () 
	          (declare (special n m))
		  (let ((nn n) (mm m))
		    (setq n nil m nil)
		    (setq n nn  m mm)
		    (+ n m)))
	      n m))
     
     (defun frob1 (type fn n m)
       (declare (special n m))
       (flet ((zap () (funcall fn)))
	 (case type
	   (fixnum (locally (declare (fixnum n m)) (zap)))
	   (float  (locally (declare (float  n m)) (zap)))
	   (otherwise (zap)))))

     In your interpretation, this code is in error, while in my
     interpretation, this code is valid. I consider it a gross
     modularity violation for the effect of a type declaration to
     have other than lexical scope.

     The only alternatives seem to me to be:

	- Don't do local type declarations on special variables.
	  [This costs efficiency in other places, so your proposal
	   would be trading one kind of efficiency barrier for
	   another.]

	- Scope type declarations for special variables differently
	  for lexical and dynamic variables. Curiously, you would
	  have lexical variables enforce their type declarations
	  dynamically, and dynamic variables enforce their type
	  declarations lexically.

	- Scope all type declarations lexically.

     The only one I have any support for is still the third, which
     is Moon's LEXICAL proposal.

∂11-Jan-89  1458	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89  14:46:01 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 519656; Wed 11-Jan-89 17:44:14 EST
Date: Wed, 11 Jan 89 17:44 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 9)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19890103003245.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Supersedes: <890111122017.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890111174402.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Wed, 11 Jan 89 12:20 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    Btw, I spoke last week on the phone to Jonathan Rees about this. He's not
    yet gotten around to sending mail but he said...
      - he doesn't think the ALLOW proposal is a good idea
      - the ALLOW proposal is inconsistent with the proposal in
	SYMBOL-MACROLET-SEMANTICS

Oops. I meant to say "SYMBOL-MACROLET-DECLARE", of course.

    He hadn't seen the actual LEXICAL proposal yet, but from my description
    of the differences, he seemed pretty firm on the idea that it was the
    right idea.

∂11-Jan-89  1513	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  14:54:11 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JAN 89 14:47:55 PST
Date: 11 Jan 89 14:47 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Wed, 11 Jan 89
 01:24:32 PST
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, cl-cleanup@Sail.Stanford.Edu
Message-ID: <890111-144755-10740@Xerox>

I'll rephrase my statement:

The benefit of UPGRADE-ARRAY-ELEMENT-TYPE--namely, that it doesn'tCONS
while the simple portable definition does--seems very small; I don't think
it outweighs the costs of adding it to the existing language. If
UPGRADE-ARRAY-ELEMENT-TYPE were already part of Common Lisp, I don't I
probably would not vote to take it out, even though it seems of limited
utility. Since it isn't in the language, I vote against adding it.

I also think that UPGRADE-ARRAY-ELEMENT-TYPE is strictly less useful than
ARRAY-DIMENSION and ARRAY-TOTAL-SIZE and that a first-principle argument
would be made against it. UPGRADE-ARRAY-ELEMENT-TYPE answers only a
hypothetical issue, viz: what *would* the type of this array be if I *were*
to upgrade it.

As I think about it, I'm not sure why we rule out the possibility that the
upgrading of arrays might happen differently for different arrays: for
example, I might have an algorithm that "upgraded" all simple
non-adjustable arrays with ARRAY-TOTAL-SIZE less than 2 to ELEMENT-TYPE T,
but be more strict about larger arrays.  The major part of the proposal
("Change the meaning of (TYPEP <x> '(ARRAY <type>)), where <type> is not
*, to be true if and only if <x> is an array that could be the result of
giving <type> as the :element-type argument to MAKE-ARRAY.") could be kept,
and the part that talks about upgrading (Clarify that "upgrading" implies a
movement upwards in the type- hierarchy lattice.) would just have to be
recast in terms of a specific array. 

This is counter to the part that says "Clarify that upgrading an array
element-type is independent of any 
    other property of arrays, such as rank, adjustability, fill-pointers, 
    displacement etc."

but I wonder now if that is a clarification -- is it a Change? -- and if it
is necessary.

∂11-Jan-89  1514	CL-Cleanup-mailer 	Re: Issue: SETF-SUB-METHODS (Version 5)  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 11 Jan 89  12:51:37 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa07416; 11 Jan 89 20:14 GMT
Date: Wed, 11 Jan 89 20:16:22 GMT
Message-Id: <18372.8901112016@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: SETF-SUB-METHODS (Version 5)
To: Jon L White <@sail.stanford.edu:jonl@lucid.com>, cperdue@sun.com
In-Reply-To: Jon L White's message of Wed, 11 Jan 89 00:02:47 PST
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu

I thought about this issue for a long time this morning and found
it very confusing.  Eventualy, I decided that the proposal was
probably right, but it could have been better explained.  What
finally convinced me was the thinking below (which I do not think
is necessarily the better explanation).

(setf (getf -variable- -expr1-) -expr2-)

expands into something like:

(let* ((#:temp0 -variable-) ;let's assume we do this binding for now.
       (#:temp1 -expr1-)    ;in the example, -expr2- is just 'B.
       (#:temp2 -expr2-))   ;in the example, this does the setq.
  (setq -variable-
        (list-putprop [ ? ] #:temp1 #:temp2))
  #:temp2)

Let's assume LIST-PUTPROP returns the entire plist, which may be a new
list or a modification of the old.

Now the question is: what goes in [ ? ]?  If it's #:temp0, then in

     (setq s (setq r (list 'a 1 'b 2 'c 3)))
     (setf (getf r 'b) (progn (setq r nil) 6))

LIST-PUTPROP would get the original value or R (before it was set to
NIL), and the results would be:

     r ==> (a 1 b 6 c 3)
     s ==> (a 1 b 6 c 3) or (a 1 b 2 c 3)

The other alternative is that [ ? ] is R.  Then LIST-PUTPROP gets the
new value of R (i.e., nil), and the results are:

     r ==> (b 6)
     s ==> (a 1 b 2 c 3)

Now suppose we're doing 

   (setf (getf (car -variable-) -expr1-) -expr2-)

This expands into

   (let* ((#:temp0 -variable-)
          (#:temp1 -expr1-)
          (#:temp2 -expr2-))
     (setf (car #:temp0)
           (list-putprop (car #:temp0) #:temp1 #:temp2))
     #:temp2)

Here, (car #:temp0) acts as a sort of pointer to what we want to
change.  We can't point to a car (only to a whole cons), but we
want the car of that cons, not the cons that happens to be the
value of the variable later on.  That's what (car ...) means as
a place.  But a variable as a place wants a "pointer" to that
variable, not to it's value, because that's what a variable means
as a place.  And such a "pointer" is just the variable itself.

This suggests that [ ? ] should be R.  That is, we should dereference
the "pointer" when calling LIST-PUTPROP.

-- Jeff

∂11-Jan-89  1515	CL-Cleanup-mailer 	Re:  Issue: SETF-SUB-METHODS (Version 5) 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  13:18:01 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA07029; Wed, 11 Jan 89 13:19:36 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA12243; Wed, 11 Jan 89 13:16:14 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA01716; Wed, 11 Jan 89 13:17:20 PST
Date: Wed, 11 Jan 89 13:17:20 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901112117.AA01716@clam.sun.com>
To: jonl@lucid.com
Subject: Re:  Issue: SETF-SUB-METHODS (Version 5)
Cc: cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM

I have read Jeff Dalton's recent discussion as well as JonL's
email, and it is quite possible that I will change my
view as to what the semantics should be stated to be.

I'm not going to vote now for this proposal as it stands --
will think about it harder after X3J13.

				-Cris

∂11-Jan-89  1516	CL-Cleanup-mailer 	Re: New proposed issue APPEND-ATOM  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  13:38:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 11 JAN 89 13:34:46 PST
Date: 11 Jan 89 13:33 PST
From: masinter.pa@Xerox.COM
Subject: Re: New proposed issue APPEND-ATOM
In-reply-to: Guy Steele <gls@Think.COM>'s message of Tue, 6 Dec 88 14:29:22
 EST
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890111-133446-10438@Xerox>

The proposal labelled

Proposal (APPEND-ATOM:IGNORE):

is referred to by Examples (APPEND-ATOM:DOTTED).


The last sentence of the APPEND-ATOM:IGNORE is hard for to parse. I'd say 

"Point out that if all of the arguments are non-lists, the result of APPEND
or NCONC can be a non-list."

We've gotten no opinions on this issue. If I believe the phrase in CLtL
that says that "unless otherwise specified, a 'list' is a proper list",
then APPEND-ATOM:ERROR is a clarification and APPEND-ATOM:DOTTED is a
change.


∂11-Jan-89  1517	CL-Cleanup-mailer 	Re:  Issue: SETF-SUB-METHODS (Version 5) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  14:18:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 13:59:43 PST
Date: 11 Jan 89 13:59 PST
From: masinter.pa@Xerox.COM
Subject: Re:  Issue: SETF-SUB-METHODS (Version 5)
In-reply-to: cperdue@Sun.COM (Cris Perdue)'s message of Wed, 11 Jan 89
 13:17:20 PST
To: cperdue@Sun.COM (Cris Perdue)
cc: jonl@lucid.com, cl-cleanup@sail.stanford.edu, masinter.pa@Xerox.COM
Message-ID: <890111-135943-10535@Xerox>

I believe that this will get voted on at this meeting unless there is a
successful motion to table it.


∂11-Jan-89  1522	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  15:21:49 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 15:20:33 PST
Date: 11 Jan 89 15:20 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Wed, 11 Jan 89 17:44 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890111-152033-10869@Xerox>

I've been convinced that LEXICAL is reasonable ... 

Version 9 was released to X3J13 & I think we can probably vote on the
LEXICAL proposal at the meeting.

∂11-Jan-89  1514	CL-Cleanup-mailer 	Ballot response 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  12:48:30 PST
Return-Path: <barmar@fafnir.think.com>
Received: from sauron.think.com by Think.COM; Wed, 11 Jan 89 11:14:14 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 11 Jan 89 11:25:35 EST
Date: Wed, 11 Jan 89 11:26 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Ballot response
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881212-181649-5908@Xerox>
Supersedes: <19890109165147.5.BARMAR@OCCAM.THINK.COM>
Message-Id: <19890111162622.3.BARMAR@OCCAM.THINK.COM>

Guy, here are my X3J13 ballot responses.  Please review them ASAP and
let me know if you have any objections.  I'd like to mail these to
cl-cleanup by Tuesday morning.
						barmar

Y    ARGUMENTS-UNDERSPECIFIED:SPECIFY
	    Version 4, 21-Sep-88, Mailed 4 Dec 88

Y    ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
	    Version 9, 31-Oct-88, Mailed 5 Dec 88

Y    CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
	    Version 5,  5-Dec-88, Mailed 5 Dec 88

Y    CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
	    Version 1, 14-Sep-88, Mailed 6 Oct 88

Y    DECLARATION-SCOPE:NO-HOISTING
N    DECLARATION-SCOPE:LIMITED-HOISTING
	    Version 4, 15-Nov-88, Mailed 9-Dec-88
Reason: LOCALLY can always be used to hoist a declaration around an
initial value form.

A    DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
	    Version 4,  5-Dec-88, Mailed  5-Dec-88

C    DECLARE-TYPE-FREE:ALLOW
C    DECLARE-TYPE-FREE:LEXICAL
	    Version 9, 2-Jan-89, Mailed 7-Jan-89
I'd like to see more discussion of the relative merits of the two
different proposals.  All of the benefit/cost section merely addresses
whether free type declarations should be allowed; I agree with this
part, but I'm unsure about which of the versions is better.

Y    DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
	    Version 2, 30-Sep-88, Mailed 6 Oct 88

Y    DEFPACKAGE:ADDITION
	    Version 7, 2-Nov-88, Mailed 5 Dec 88

Y    DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
	    Version 2, 21-Sep-88, Mailed 6 Oct 88

Y    DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
	    Version 3, 7 Dec 88, Mailed 12-Dec-88

Y    DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
	    Version 4, 31-Oct-88, Mailed 12-Dec-88

A    DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
A    DESCRIBE-INTERACTIVE:NO
	    Version 4, 15-Nov-88	, Mailed 7-Dec-88

Y    DOTTED-MACRO-FORMS:ALLOW
	    Version 3, 15-Nov-88, Mailed 7-Dec-88

Y    EQUAL-STRUCTURE:STATUS-QUO
	    Version 5, 1-Oct-88, Mailed 8 Oct 88


N    EXIT-EXTENT:MINIMAL
Y    EXIT-EXTENT:MEDIUM
	    Version 5, 12-Dec-88, Mailed 12-Dec-88
Reason: MEDIUM provides more useful semantics in one important case: if
an application has a top-level catch tag, and a cleanup handler does a
(throw 'top-level ...) while cleaning up during such a throw.  Lack of
these semantics in Maclisp results in problems in Multics Emacs, whose
error handler prints a minibuffer message and then throws to the top
level, but if an error happens during a cleanup, the top-level catch is
no longer available, resulting in an infinite loop of "throw to
nonexistent tag" errors.  This seems like it would be a common paradigm,
but unless there is a way for a cleanup handler to determine the context
of its invocation, MINIMAL makes this non-portable.

Y    EXPT-RATIO:P.211
	    Version 3, 31-Oct-88, Mailed 7 Dec 88

Y    FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
N    FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
	    Version 4, 7-Dec-88, Mailed 12-Dec-88
Reason: Tossing BIGNUM is a gratuitous incompatibility.

Y    FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
	    Version 2, 2 Oct 88, Mailed 6 Oct 88

Y    FORMAT-PRETTY-PRINT:YES
	    Version 7, 15 Dec 88, Mailed 7 Dec 88

I    FUNCTION-COMPOSITION:NEW-FUNCTIONS
I    FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
	    Version 4, 12 Dec 88, Mailed 12 Dec 88
In both cases, only if one of the TEST-NOT-IF-NOT proposals passes.

Y    FUNCTION-DEFINITION:FUNCTION-SOURCE
	    Version 2, 09-Dec-88	, Mailed 9 Dec 88

Y    FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
	    Version 3, 7-Dec-88, Mailed  12-Dec-88

Y    FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
	    Version 5, 14-Nov-88	, Mailed 8-Dec-88

Y    GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
	    Version 2, 8 Dec 88, Mailed 8 Dec 88

Y    HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
	    Version 7, 8-Dec-88, Mailed 9-Dec-88

Y    HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
	    Version 1, 11-Nov-88	, Mailed 12 Dec 88

Y    HASH-TABLE-TESTS:ADD-EQUALP
	    Version 2, 8-Dec-88, Mailed 8 Dec 88

Y    IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
	    Version 4, 12-Dec-88, Mailed 12-Dec-88

Y    LAMBDA-FORM:NEW-MACRO
	    Version 4, 22-Nov-88, Mailed 8-Dec-88

Y    LCM-NO-ARGUMENTS:1
	    Version 1, 17 Oct 88, Mailed 8 Dec 88

Y    LISP-SYMBOL-REDEFINITION:DISALLOW
	    Version 5, 22-Nov-88, Mailed 8 Dec 88

N    MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
	    Version 2, 8 Oct 88, Mailed 12-Dec-88
Reason: When using the implementation's extensions, it is better to make
this obvious by having to specify the implementation-dependent package.

Y    MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
	    Version 2, 09-Jun-88, Mailed 8 Oct 88

N    NTH-VALUE:ADD
	    Version 4, 8-Dec-88, Mailed 8 Dec 88
Reason: Naming values using a numeric index is like using arrays instead
of DEFSTRUCT.  If there were a way to specify a value by a symbolic name
I'd go for that.

Y    PACKAGE-CLUTTER:REDUCE
	    Version 6, 12-Dec-88, Mailed 12-Dec-881

Y    PACKAGE-DELETION:NEW-FUNCTION
	    Version 5, 21 nov 88, Mailed 8 Dec 88

Y    PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
	    Version 1 27-Jun-88, Mailed 7 Oct 88

Y    PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
	    Version 3, 8-Oct-88, Mailed 8 Oct 88

Y    PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
	    Version 3, 20 Sep 88, Mailed 8 Oct 88

Y    PROCLAIM-LEXICAL:LG
	    Version 9, 8-Dec-88, Mailed 12-Dec-88

Y    RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
	    Version 3, 9-Oct-88, Mailed 14-Oct-88

Y    RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
	    Version 1, 14-Sep-88, Mailed 7 Oct 88

Y    REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
	    Version 6, 9 Dec 88, mailed 09 Dec 88

N    REST-LIST-ALLOCATION:NEWLY-ALLOCATED
Y    REST-LIST-ALLOCATION:MAY-SHARE
N    REST-LIST-ALLOCATION:MUST-SHARE
	    Version 3, 12-Dec-88, mailed 12-Dec-88
Reason: Allow implementation flexibility and useful optimization.

Y    RETURN-VALUES-UNSPECIFIED:SPECIFY
	    Version 6,  9 Dec 88 mailed  9-Dec-88

Y    ROOM-DEFAULT-ARGUMENT:NEW-VALUE
	    Version 1 12-Sep-88 mailed 8 Oct 88

    [The following are mutually exclusive]
Y    SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
	    Version 3, 4-Nov-87, mailed Nov 87
N    SETF-PLACES:ADD-SETF-FUNCTIONS
	    Version 1, 11-Nov-88, mailed 9-Dec-88
Reason: I don't think it's possible to define a version UNDERLYING-NAME
that returns a symbol and meets all the requirements.

Y    SETF-SUB-METHODS:DELAYED-ACCESS-STORES
	    Version 5, 12-Feb-88 mailed 8 Oct 88

Y    STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
	    Version 8, 8 Jul 88, Mailed 7 Oct 88

Y    STEP-ENVIRONMENT:CURRENT
	    Version 3, 20-Jun-88, mailed  7 Oct 88

Y    STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
	    version 2, 30-Nov-88 mailed  9 Dec 88
	    (expect amendment T => "true")

Y    STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
	    Version 6, 30-Nov-88, mailed 9 dec 88
	    expect amendment:
		    LINE-WIDTH   ==> STREAM-LINE-WIDTH
		    LINE-POSITION ==> STREAM-LINE-POSITION
		    PRINTED-WIDTH ==> STREAM-STRING-WIDTH


Y    SUBTYPEP-TOO-VAGUE:CLARIFY
	    Version 4,  7-Oct-88, mailed 7 Oct 88 

Y    SYMBOL-MACROLET-DECLARE:ALLOW
	    Version 2,  9-Dec-88, mailed 9 Dec 88

Y    SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
	    Version 5, 30-Nov-88, mailed 9 Dec 88

Y    TAGBODY-CONTENTS:FORBID-EXTENSION
	    Version 5, 9-Dec-88 mailed 9 Dec 88

Y    TAILP-NIL:T
	    Version 5, 9-Dec-88, mailed 12-Dec-88

N    TEST-NOT-IF-NOT:FLUSH-ALL
N    TEST-NOT-IF-NOT:FLUSH-TEST-NOT
	    Version 3, 1 Dec 88 mailed 9 dec 
Reason: Gratuitous incompatibility.

Y    TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
	    Version 3, 12-Dec-88, mailed 12 Dec 88
	    (some "bugs" in the proposal)

Y    UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
	    Version 2, 2-Dec-88, mailed 12-Dec-88

Y    VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
	    Version 3, 08-Oct-88, mailed 9 Dec 88
To: gls
bcc: barmar-archived
Subject: Ballot response
In-Reply-To: <881212-181649-5908@Xerox>

Here are Thinking Machine's ballot responses.  For all my No responses
I've included some justification.

Y    ARGUMENTS-UNDERSPECIFIED:SPECIFY
	    Version 4, 21-Sep-88, Mailed 4 Dec 88

Y    ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
	    Version 9, 31-Oct-88, Mailed 5 Dec 88

Y    CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
	    Version 5,  5-Dec-88, Mailed 5 Dec 88

Y    CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
	    Version 1, 14-Sep-88, Mailed 6 Oct 88

Y    DECLARATION-SCOPE:NO-HOISTING
N    DECLARATION-SCOPE:LIMITED-HOISTING
	    Version 4, 15-Nov-88, Mailed 9-Dec-88
Reason: LOCALLY can always be used to hoist a declaration around an
initial value form.

A    DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
	    Version 4,  5-Dec-88, Mailed  5-Dec-88

C    DECLARE-TYPE-FREE:ALLOW
C    DECLARE-TYPE-FREE:LEXICAL
	    Version 9, 2-Jan-89, Mailed 7-Jan-89
I'd like to see more discussion of the relative merits of the two
different proposals.  All of the benefit/cost section merely addresses
whether free type declarations should be allowed; I agree with this
part, but I'm unsure about which of the versions is better.

Y    DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
	    Version 2, 30-Sep-88, Mailed 6 Oct 88

Y    DEFPACKAGE:ADDITION
	    Version 7, 2-Nov-88, Mailed 5 Dec 88

Y    DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
	    Version 2, 21-Sep-88, Mailed 6 Oct 88

Y    DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
	    Version 3, 7 Dec 88, Mailed 12-Dec-88

Y    DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
	    Version 4, 31-Oct-88, Mailed 12-Dec-88

A    DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
A    DESCRIBE-INTERACTIVE:NO
	    Version 4, 15-Nov-88	, Mailed 7-Dec-88

Y    DOTTED-MACRO-FORMS:ALLOW
	    Version 3, 15-Nov-88, Mailed 7-Dec-88

Y    EQUAL-STRUCTURE:STATUS-QUO
	    Version 5, 1-Oct-88, Mailed 8 Oct 88


N    EXIT-EXTENT:MINIMAL
Y    EXIT-EXTENT:MEDIUM
	    Version 5, 12-Dec-88, Mailed 12-Dec-88
Reason: MEDIUM provides more useful semantics in one important case: if
an application has a top-level catch tag, and a cleanup handler does a
(throw 'top-level ...) while cleaning up during such a throw.  Lack of
these semantics in Maclisp results in problems in Multics Emacs, whose
error handler prints a minibuffer message and then throws to the top
level, but if an error happens during a cleanup, the top-level catch is
no longer available, resulting in an infinite loop of "throw to
nonexistent tag" errors.  This seems like it would be a common paradigm,
but unless there is a way for a cleanup handler to determine the context
of its invocation, MINIMAL makes this non-portable.

Y    EXPT-RATIO:P.211
	    Version 3, 31-Oct-88, Mailed 7 Dec 88

Y    FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
N    FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
	    Version 4, 7-Dec-88, Mailed 12-Dec-88
Reason: Tossing BIGNUM is a gratuitous incompatibility.

Y    FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
	    Version 2, 2 Oct 88, Mailed 6 Oct 88

Y    FORMAT-PRETTY-PRINT:YES
	    Version 7, 15 Dec 88, Mailed 7 Dec 88

I    FUNCTION-COMPOSITION:NEW-FUNCTIONS
I    FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
	    Version 4, 12 Dec 88, Mailed 12 Dec 88
In both cases, only if one of the TEST-NOT-IF-NOT proposals passes.

Y    FUNCTION-DEFINITION:FUNCTION-SOURCE
	    Version 2, 09-Dec-88	, Mailed 9 Dec 88

Y    FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
	    Version 3, 7-Dec-88, Mailed  12-Dec-88

Y    FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
	    Version 5, 14-Nov-88	, Mailed 8-Dec-88

Y    GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
	    Version 2, 8 Dec 88, Mailed 8 Dec 88

Y    HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
	    Version 7, 8-Dec-88, Mailed 9-Dec-88

Y    HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
	    Version 1, 11-Nov-88	, Mailed 12 Dec 88

Y    HASH-TABLE-TESTS:ADD-EQUALP
	    Version 2, 8-Dec-88, Mailed 8 Dec 88

Y    IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
	    Version 4, 12-Dec-88, Mailed 12-Dec-88

Y    LAMBDA-FORM:NEW-MACRO
	    Version 4, 22-Nov-88, Mailed 8-Dec-88

Y    LCM-NO-ARGUMENTS:1
	    Version 1, 17 Oct 88, Mailed 8 Dec 88

Y    LISP-SYMBOL-REDEFINITION:DISALLOW
	    Version 5, 22-Nov-88, Mailed 8 Dec 88

N    MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
	    Version 2, 8 Oct 88, Mailed 12-Dec-88
Reason: When using the implementation's extensions, it is better to make
this obvious by having to specify the implementation-dependent package.

Y    MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
	    Version 2, 09-Jun-88, Mailed 8 Oct 88

N    NTH-VALUE:ADD
	    Version 4, 8-Dec-88, Mailed 8 Dec 88
Reason: Naming values using a numeric index is like using arrays instead
of DEFSTRUCT.  If there were a way to specify a value by a symbolic name
I'd go for that.

Y    PACKAGE-CLUTTER:REDUCE
	    Version 6, 12-Dec-88, Mailed 12-Dec-881

Y    PACKAGE-DELETION:NEW-FUNCTION
	    Version 5, 21 nov 88, Mailed 8 Dec 88

Y    PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
	    Version 1 27-Jun-88, Mailed 7 Oct 88

Y    PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
	    Version 3, 8-Oct-88, Mailed 8 Oct 88

Y    PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
	    Version 3, 20 Sep 88, Mailed 8 Oct 88

Y    PROCLAIM-LEXICAL:LG
	    Version 9, 8-Dec-88, Mailed 12-Dec-88

Y    RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
	    Version 3, 9-Oct-88, Mailed 14-Oct-88

Y    RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
	    Version 1, 14-Sep-88, Mailed 7 Oct 88

Y    REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
	    Version 6, 9 Dec 88, mailed 09 Dec 88

N    REST-LIST-ALLOCATION:NEWLY-ALLOCATED
Y    REST-LIST-ALLOCATION:MAY-SHARE
N    REST-LIST-ALLOCATION:MUST-SHARE
	    Version 3, 12-Dec-88, mailed 12-Dec-88
Reason: Allow implementation flexibility and useful optimization.

Y    RETURN-VALUES-UNSPECIFIED:SPECIFY
	    Version 6,  9 Dec 88 mailed  9-Dec-88

Y    ROOM-DEFAULT-ARGUMENT:NEW-VALUE
	    Version 1 12-Sep-88 mailed 8 Oct 88

    [The following are mutually exclusive]
Y    SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
	    Version 3, 4-Nov-87, mailed Nov 87
N    SETF-PLACES:ADD-SETF-FUNCTIONS
	    Version 1, 11-Nov-88, mailed 9-Dec-88
Reason: I don't think it's possible to define a version UNDERLYING-NAME
that returns a symbol and meets all the requirements.

Y    SETF-SUB-METHODS:DELAYED-ACCESS-STORES
	    Version 5, 12-Feb-88 mailed 8 Oct 88

Y    STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
	    Version 8, 8 Jul 88, Mailed 7 Oct 88

Y    STEP-ENVIRONMENT:CURRENT
	    Version 3, 20-Jun-88, mailed  7 Oct 88

Y    STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
	    version 2, 30-Nov-88 mailed  9 Dec 88
	    (expect amendment T => "true")

Y    STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
	    Version 6, 30-Nov-88, mailed 9 dec 88
	    expect amendment:
		    LINE-WIDTH   ==> STREAM-LINE-WIDTH
		    LINE-POSITION ==> STREAM-LINE-POSITION
		    PRINTED-WIDTH ==> STREAM-STRING-WIDTH


Y    SUBTYPEP-TOO-VAGUE:CLARIFY
	    Version 4,  7-Oct-88, mailed 7 Oct 88 

Y    SYMBOL-MACROLET-DECLARE:ALLOW
	    Version 2,  9-Dec-88, mailed 9 Dec 88

Y    SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
	    Version 5, 30-Nov-88, mailed 9 Dec 88

Y    TAGBODY-CONTENTS:FORBID-EXTENSION
	    Version 5, 9-Dec-88 mailed 9 Dec 88

Y    TAILP-NIL:T
	    Version 5, 9-Dec-88, mailed 12-Dec-88

N    TEST-NOT-IF-NOT:FLUSH-ALL
N    TEST-NOT-IF-NOT:FLUSH-TEST-NOT
	    Version 3, 1 Dec 88 mailed 9 dec 
Reason: Gratuitous incompatibility.

Y    TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
	    Version 3, 12-Dec-88, mailed 12 Dec 88
	    (some "bugs" in the proposal)

Y    UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
	    Version 2, 2-Dec-88, mailed 12-Dec-88

Y    VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
	    Version 3, 08-Oct-88, mailed 9 Dec 88

∂11-Jan-89  1522	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 3)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  15:21:37 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 15:18:27 PST
Date: 11 Jan 89 15:17 PST
From: masinter.pa@Xerox.COM
Subject: Issue: DYNAMIC-EXTENT (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
line-fold: NO
cc: masinter.pa@Xerox.COM
Message-ID: <890111-151827-10863@Xerox>

<<version number wrong, missing line-fold: NO>>
I don't have the time to "wordsmith" this issue, but I think it
is important enough to bring before X3J13; I think the idea
in the proposal is fine, but I just clipped some of David's words
into the old one.

I'd like to release this in DRAFT form, I'm less sure what
we can vote on. 

Opinions? Volunteers to edit this further?
!
Status:	        For Internal Discussion
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)
Related-Issues: REST-ARGUMENT-EXTENT, WITH-DYNAMIC-EXTENT

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. The declaration asserts that
  the value which is initially held by the indicated variable will have
  dynamic extent. [In the case of an iteration variable, the declaration
  asserts that on every iteration, the initial value of that variable
  for the iteration will have dynamic extent.]

  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.

  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.

   The meaning of a dynamic extent declaration is that execution of the
   forms in the scope of the declaration will not "save" any "proper part"
   of the initial value of the declared variable.  To "save" an object
   means to cause a reference to that object to be accessible outside the
   dynamic extent of the form at the beginning of whose body the
   declaration appears.  An object can be "saved" by storing it with a
   side-effecting operation and not replacing it with a different value
   before the end of the dynamic extent, by using it as a component of a
   freshly-allocated object that is itself "saved," by capturing it in a
   function closure that is itself "saved," by returning it as a value, or
   by transmitting it outside the dynamic extent with THROW.  A "proper
   part" of an object A is any object that is accessible at the beginning
   of the scope of the declaration -only- by applying a function to A or to
   a "proper part" of A.  This means that any objects freshly allocated
   during the construction of the initial value of the declared variable,
   and not "saved" during the construction of that value, are "proper
   parts" and can be allocated on a stack.

Examples:

In
            (LET ((X (LIST 'A1 'B1 'C1))
                  (Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
              (DECLARE (DYNAMIC-EXTENT X Y))
              ...)
The "proper parts" of X are three conses, and the "proper parts" of Y
are three other conses.  None of the symbols A1, B1, C1, A2, B2, C2, or
NIL is a "proper part" of X or Y.  However, if a freshly allocated
uninterned symbol had been used, it would have been a "proper part."

- - - - - - - -
          (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 "proper parts" 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 a "proper part" 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 a "proper part", 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.

  Pitman supports the DYNAMIC-EXTENT:NEW-DECLARATION.

  Actually, a blurry issue is whether
   (LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
   => 1
  is well-defined. I refer to these stack-allocated things as being invalid
  return values, but in fact we might want to say that they're ok to return
  but that you just can't do any serious operations on them (ie, you can't
  expect them to still be lists, etc.) Can anyone imagine a pointer into
  unallocated stack causing problems for their GC? If so, we could be more
  clear on this point.

The examples are tricky:

"I hope no one misreads the above as an argument that my proposal is too
complicated, since it does not derive at all from my proposal, but only
from the way Common Lisp works."

∂11-Jan-89  1522	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 2)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  15:21:22 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 15:17:08 PST
Date: 11 Jan 89 15:16 PST
From: masinter.pa@Xerox.COM
Subject: Issue: DYNAMIC-EXTENT (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890111-151708-10854@Xerox>

I don't have the time to "wordsmith" this issue, but I think it
is important enough to bring before X3J13; I think the idea
in the proposal is fine, but I just clipped some of David's words
into the old one.

I'd like to release this in DRAFT form, I'm less sure what
we can vote on. 

Opinions? Volunteers to edit this further?
!
Status:	        For Internal Discussion
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)
Related-Issues: REST-ARGUMENT-EXTENT, WITH-DYNAMIC-EXTENT

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. The declaration asserts that
  the value which is initially held by the indicated variable will have
  dynamic extent. [In the case of an iteration variable, the declaration
  asserts that on every iteration, the initial value of that variable
  for the iteration will have dynamic extent.]

  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.

  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.

   The meaning of a dynamic extent declaration is that execution of the
   forms in the scope of the declaration will not "save" any "proper part"
   of the initial value of the declared variable.  To "save" an object
   means to cause a reference to that object to be accessible outside the
   dynamic extent of the form at the beginning of whose body the
   declaration appears.  An object can be "saved" by storing it with a
   side-effecting operation and not replacing it with a different value
   before the end of the dynamic extent, by using it as a component of a
   freshly-allocated object that is itself "saved," by capturing it in a
   function closure that is itself "saved," by returning it as a value, or
   by transmitting it outside the dynamic extent with THROW.  A "proper
   part" of an object A is any object that is accessible at the beginning
   of the scope of the declaration -only- by applying a function to A or to
   a "proper part" of A.  This means that any objects freshly allocated
   during the construction of the initial value of the declared variable,
   and not "saved" during the construction of that value, are "proper
   parts" and can be allocated on a stack.

Examples:

In
            (LET ((X (LIST 'A1 'B1 'C1))
                  (Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
              (DECLARE (DYNAMIC-EXTENT X Y))
              ...)
The "proper parts" of X are three conses, and the "proper parts" of Y
are three other conses.  None of the symbols A1, B1, C1, A2, B2, C2, or
NIL is a "proper part" of X or Y.  However, if a freshly allocated
uninterned symbol had been used, it would have been a "proper part."

- - - - - - - -
          (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 "proper parts" 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 a "proper part" 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 a "proper part", 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.

  Pitman supports the DYNAMIC-EXTENT:NEW-DECLARATION.

  Actually, a blurry issue is whether
   (LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
   => 1
  is well-defined. I refer to these stack-allocated things as being invalid
  return values, but in fact we might want to say that they're ok to return
  but that you just can't do any serious operations on them (ie, you can't
  expect them to still be lists, etc.) Can anyone imagine a pointer into
  unallocated stack causing problems for their GC? If so, we could be more
  clear on this point.

The examples are tricky:

"I hope no one misreads the above as an argument that my proposal is too
complicated, since it does not derive at all from my proposal, but only
from the way Common Lisp works."

∂11-Jan-89  1534	CL-Cleanup-mailer 	Issue: EXIT-EXTENT (Version 6) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  15:33:53 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 15:32:33 PST
Date: 11 Jan 89 15:32 PST
From: masinter.pa@Xerox.COM
Subject: Issue: EXIT-EXTENT (Version 6)
To: cl-cleanup@sail.stanford.edu
Message-ID: <890111-153233-10914@Xerox>

N    EXIT-EXTENT:MINIMAL
Y    EXIT-EXTENT:MEDIUM
	    Version 5, 12-Dec-88, Mailed 12-Dec-88
Reason: MEDIUM provides more useful semantics in one important case: if
an application has a top-level catch tag, and a cleanup handler does a
(throw 'top-level ...) while cleaning up during such a throw.  Lack of
these semantics in Maclisp results in problems in Multics Emacs, whose
error handler prints a minibuffer message and then throws to the top
level, but if an error happens during a cleanup, the top-level catch is
no longer available, resulting in an infinite loop of "throw to
nonexistent tag" errors.  This seems like it would be a common paradigm,
but unless there is a way for a cleanup handler to determine the context
of its invocation, MINIMAL makes this non-portable.

∂11-Jan-89  1558	CL-Cleanup-mailer 	Re: Issue: EXIT-EXTENT (Version 6)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  15:58:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 15:52:48 PST
Date: 11 Jan 89 15:52 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXIT-EXTENT (Version 6)
In-reply-to: masinter.pa's message of 11 Jan 89 15:32 PST
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890111-155248-10971@Xerox>

That message should have been marked "From: Barmar@think.com"


∂11-Jan-89  1601	CL-Cleanup-mailer 	Re:  Issue: SETF-SUB-METHODS (Version 5) 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  16:01:10 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA11476; Wed, 11 Jan 89 16:02:34 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA19952; Wed, 11 Jan 89 15:58:45 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA02137; Wed, 11 Jan 89 15:59:45 PST
Date: Wed, 11 Jan 89 15:59:45 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8901112359.AA02137@clam.sun.com>
To: cperdue@Sun.COM, masinter.pa@Xerox.COM
Subject: Re:  Issue: SETF-SUB-METHODS (Version 5)
Cc: cl-cleanup@sail.stanford.edu, jonl@lucid.com

> I believe that this will get voted on at this meeting unless there is a
> successful motion to table it.

If so I'll vote against but with willingness to reconsider,
especially if the proposal can be stated much more simply.

∂11-Jan-89  1614	CL-Cleanup-mailer 	Re: Issue: DECLARE-TYPE-FREE (Version 9) 
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 11 Jan 89  16:13:07 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa08811; 11 Jan 89 23:55 GMT
Date: Wed, 11 Jan 89 23:58:03 GMT
Message-Id: <18529.8901112358@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 9)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, Moon@scrc-stony-brook.arpa
In-Reply-To: Kent M Pitman's message of Wed, 11 Jan 89 12:20 EST
Cc: CL-Cleanup@sail.stanford.edu

> Btw, I spoke last week on the phone to Jonathan Rees about this. He's not
> yet gotten around to sending mail but he said...
>   - he doesn't think the ALLOW proposal is a good idea
>   - the ALLOW proposal is inconsistent with the proposal in
>     SYMBOL-MACROLET-SEMANTICS
> He hadn't seen the actual LEXICAL proposal yet, but from my description
> of the differences, he seemed pretty firm on the idea that it was the
> right idea.

I agree.  The SYMBOL-MACROLET proposal expalins type declarations as
equiv to adding THE <type> to the expansion; and that's also the
explanation for LEXICAL.  I support both.  And votes on these issues
should at least be consistent.

∂11-Jan-89  1652	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 2)  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Jan 89  16:51:54 PST
Received: by ti.com id AA12442; Wed, 11 Jan 89 18:51:07 CST
Received: from Kelvin by tilde id AA06197; Wed, 11 Jan 89 18:35:47 CST
Message-Id: <2809557489-5434538@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 11 Jan 89  18:38:09 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Robert A. Cassels" <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@Sail.Stanford.EDU
Subject: Re: Issue: REAL-NUMBER-TYPE (version 2)
In-Reply-To: Msg of Sun, 8 Jan 89 11:29 EST from Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>

> Proposal (REAL-NUMBER-TYPE:REAL):
> 
>   Add a standard type specifier
>    (REAL low high)
>   which means
>    (OR (RATIONAL low high) (FLOAT low high))
...
> Proposal (REAL-NUMBER-TYPE:REALP):
> 
>   Add a specific data type predicate REALP which tests for membership in
>   this type.  [By analogy with NUMBERP.]
...
> Current Practice:
> 
>   Probably nobody does this.

Actually, both the REAL type and REALP predicate are already supported on the
TI Explorer and LMI Lambda.

∂11-Jan-89  1722	CL-Cleanup-mailer 	Re: Issue: REAL-NUMBER-TYPE (version 1)  
Received: from ti.com by SAIL.Stanford.EDU with TCP; 11 Jan 89  17:22:44 PST
Received: by ti.com id AA12536; Wed, 11 Jan 89 19:20:41 CST
Received: from Kelvin by tilde id AA06891; Wed, 11 Jan 89 19:15:14 CST
Message-Id: <2809559853-5576593@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 11 Jan 89  19:17:33 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Cc: Cassels@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: REAL-NUMBER-TYPE (version 1)
In-Reply-To: Msg of Mon, 9 Jan 89 08:38 EST from "Steve Bacher (Batchman)" <SEB1525@draper.com>

> Hold on.  How should the following be handled:
>  (declare (type (real 3.1415926 71/7) x))
> ...or (typep x '(real 3.1415926 71/7))?
> When the type determination is made, how is the coercion of x to be done?
> Must x be coerced from rational to float, or from float to rational, in 
> order to do the type check?  Should RATIONAL or RATIONALIZE be used?  ETc.,
> etc., etc.

On the Explorer,  (TYPEP X '(REAL 3.1415926 71/7))  is expanded by the
compiler to  (AND (REALP X) (>= X 3.1415926) (<= X 71/7))  and then follows
the normal rules for numerical comparison from there.

∂11-Jan-89  1750	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Jan 89  17:50:21 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04314g; Wed, 11 Jan 89 17:46:15 PST
Received: by bhopal id AA07016g; Wed, 11 Jan 89 17:48:32 PST
Date: Wed, 11 Jan 89 17:48:32 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901120148.AA07016@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@Sail.Stanford.Edu
In-Reply-To: masinter.pa@Xerox.COM's message of 11 Jan 89 14:47 PST <890111-144755-10740@Xerox>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)

re: As I think about it, I'm not sure why we rule out the possibility that the
    upgrading of arrays might happen differently for different arrays: for
    example, I might have an algorithm that "upgraded" all simple
    non-adjustable arrays with ARRAY-TOTAL-SIZE less than 2 to ELEMENT-TYPE T,
    but be more strict about larger arrays. 

Lucid would certainly oppose that change.  Our compiler optimizations
work on simple-arrays of known element type; and good reasons exist
as to why the simple/non-simple distinction and the element-type
distinctions are important (other "stock hardware" implmentations 
have similar open-coding techniques).  I see no benefit to further 
discrimination based on rank or array total size.


-- JonL --

∂11-Jan-89  1812	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jan 89  18:12:11 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 519869; Wed 11-Jan-89 21:09:25 EST
Date: Wed, 11 Jan 89 21:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
To: masinter.pa@Xerox.COM
cc: Jon L White <jonl@lucid.com>, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <890111-144755-10740@Xerox>
Message-ID: <19890112020914.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No

    Date: 11 Jan 89 14:47 PST
    From: masinter.pa@Xerox.COM

    ....
    As I think about it, I'm not sure why we rule out the possibility that the
    upgrading of arrays might happen differently for different arrays: for
    example, I might have an algorithm that "upgraded" all simple
    non-adjustable arrays with ARRAY-TOTAL-SIZE less than 2 to ELEMENT-TYPE T,

Actually you couldn't do that, because Common Lisp mandates the separate
existence of strings and bit-vectors.  But we get the idea.

    but be more strict about larger arrays.  The major part of the proposal
    ("Change the meaning of (TYPEP <x> '(ARRAY <type>)), where <type> is not
    *, to be true if and only if <x> is an array that could be the result of
    giving <type> as the :element-type argument to MAKE-ARRAY.") could be kept,

No, because you would have to say what the other arguments to MAKE-ARRAY were.

If you can prove that the statement I just said is false, then I will change
my mind and agree with you, since it would considerably simplify the proposal.
I spent some time just now unsuccessfully trying to prove that the statement
is true.  The place to think about is SUBTYPEP.

    and the part that talks about upgrading (Clarify that "upgrading" implies a
    movement upwards in the type- hierarchy lattice.) would just have to be
    recast in terms of a specific array. 

    This is counter to the part that says "Clarify that upgrading an array
    element-type is independent of any 
	other property of arrays, such as rank, adjustability, fill-pointers, 
	displacement etc."

    but I wonder now if that is a clarification -- is it a Change? -- and if it
    is necessary.

You're probably right that it is a change, although I think JonL was
unable to find any current practice that it contradicts.

∂11-Jan-89  1821	CL-Cleanup-mailer 	Re: Issue: DEFPACKAGE (Version 7)   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  18:21:40 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA14739; Wed, 11 Jan 89 18:22:25 PST
Received: from denali.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA25540; Wed, 11 Jan 89 18:19:03 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
	id AA08867; Wed, 11 Jan 89 18:21:44 PST
Message-Id: <8901120221.AA08867@denali.sun.com>
To: masinter.pa@Xerox.COM
Cc: Jon L White <jonl@lucid.com>
Cc: barmar@Think.COM, CL-CLEANUP@sail.stanford.edu
Subject: Re: Issue: DEFPACKAGE (Version 7) 
In-Reply-To: Your message of 06 Jan 89 23:47:00 -0800;
	<890106-234746-2045@Xerox> .
Date: Wed, 11 Jan 89 18:21:37 PST
From: peck@Sun.COM

>After re-reading the discussion, I think the only issue is to define
>explicitly what "at variance with the current state of that package" means.

I'd like to make sure that it is possible to define mutually
dependent packages using DEFPACKAGE.

What i envision is using TWO passes with DEFPACKAGE for each package.
The first pass defines symbols that are interned (home-package) in that package,
 ie, using :SHADOW, :INTERN, :EXPORT
and a second pass which enables access to symbols homed in other packages
 ie, using :SHADOWING-IMPORT-FROM, :USE, :IMPORT-FROM,
     and possibly :EXPORT them to users of this package

Yes, i have seen applications where this is used and useful.

This disciplined used of two DEFPACKAGE forms on the same package
should enable creating the desired package and symbol-inheritance structure.

Doing this with two DEFPACKAGE forms should not produce any state
which is "at variance" with the state of the package, no?

For example of a small fragment:
(DEFPACKAGE main	; pass 1, intern symbols homed in MAIN and UTIL
	(:export 'main1))		; for :USE and :IMPORT-FROM

(DEFPACKAGE util
	(:export 'util1))		; create and export to USEr's of util

(DEFPACKAGE util	; pass 2, now import or otherwise inherit symbols
	(:import-from main 'main1)	; inherit main:main1
					; for programmers in-package UTIL

(DEFPACKAGE main
	(:use 'util)	; programmers in MAIN will want access to all UTIL:syms
	(:export 'util)); USEr's of MAIN will expect access to UTIL1.
			; and may not even know of package UTIL!


I strongly support the view that DEFPACKAGE should be constructed
out of the existing primitives, and let the concept of "at variance"
be determined by when those primitives detect incompatible package changes.

[it is true that in this example the two forms for (DEFPACKAGE util...)
 could be coalesced into one.]
 

∂11-Jan-89  1928	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 7)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Jan 89  19:27:55 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04418g; Wed, 11 Jan 89 19:22:25 PST
Received: by bhopal id AA07308g; Wed, 11 Jan 89 19:24:39 PST
Date: Wed, 11 Jan 89 19:24:39 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901120324.AA07308@bhopal>
To: masinter.pa@Xerox.COM
Cc: barmar@Think.COM, CL-CLEANUP@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 6 Jan 89 23:47 PST <890106-234746-2045@Xerox>
Subject: Issue: DEFPACKAGE (Version 7)

re  A DEFPACKAGE is "at variance with the current state of a pre-existing
    package" if the result of executing the DEFPACKAGE with a different name
    would create a package with a different set of exported symbols, a
    different set of USEd packages, with any *more* shadowing symbols, or a
    different set of nicknames.

    A DEFPACKAGE is not at variance with the current state of a pre-existing
    package even if the size of the pre-existing package differs from the :SIZE
    of the DEFPACKAGE form, or if it the pre-existing package has more internal
    symbols.

The second paragraph is fine.  The first is questionable.  I think the
only way to say it is that a DEFPACKAGE form is "at variance" with an
existing package (of the specified name) if any of the following holds:
  (1) the set of used packages specified by the form is different from
      that of the existing package;
  (2) the set of nicknames specified by the form is different from
      that of the existing package;
  (3) the set of exported symbols specified ... ;
  (4) the set of shadowing symbols specified ... ;
  (5) the set of "foreign" symbols specified ... ; [I will use "foreign"
      here to mean a symbol present in a package, but "homed" in some
      other package; these are created via :IMPORT-FROM etc.]
[I hope this is clear enough, and we don't have to explain what it 
means for "the set of used packages" to be different!!!]

Perhaps a better alternative is to give a standard canonical macro-
expansion of DEFPACKAGE into calls on existing functions (such as EXPORT,
FIND-SYMBOL, etc).  This is perfectly doable now, since the proposal 
fully specifies ordering constraints for the subparts that matter.
Of course, an implementation wouldn't be required to use that canonical
expansion, but the semantics would be required to be the same.  The
advantage of this is that it allows for redefinitions using the already
existing notions of name-conflicts etc, without having to specify that
every possible significant change has "undefined" consequences.


Tactical point:  we are nearing the wire for having presentable
proposals.  Some of the feedback of the past two weeks seems reasonable
to incorporate and some of it is "unclear" (to say the least).  Do
you really want to tinker with the wording of any issue already mailed
out between now and net Tuesday?  I would think the safer thing to do
would be to collect a bunch of "amendments" and bring them to the
meeting.  There are probably two dozen minor, non-controversial
amendments, and maybe two or three majorly controversial ones.  But
I'm leary of us "digging a hole" similar to the one opened up at the
very last minute on DECLARE-TYPE-FREE.


-- JonL --

∂11-Jan-89  1957	CL-Cleanup-mailer 	Issue: COPY-SYMBOL-COPY-PLIST  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Jan 89  19:49:29 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04432g; Wed, 11 Jan 89 19:44:42 PST
Received: by bhopal id AA07369g; Wed, 11 Jan 89 19:47:00 PST
Date: Wed, 11 Jan 89 19:47:00 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901120347.AA07369@bhopal>
To: barmar@Think.COM
Cc: KMP@stony-brook.scrc.symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 10 Jan 89 18:48 EST <19890110234853.0.BARMAR@OCCAM.THINK.COM>
Subject: Issue: COPY-SYMBOL-COPY-PLIST

re:  We know that because we understand how Lisp
    differentiates between a structured object and its contents, but most
    traditional languages don't make such a distinction, so I think it is
    important that the CL standard not presume this abstract understanding.

I agree with you here.  And I don't think it is that painful to be
correct and exact in the specification.

-- JonL --

∂11-Jan-89  1957	CL-Cleanup-mailer 	Possible issue: GCD-NO-ARGUMENTS    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 11 Jan 89  19:57:48 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04451g; Wed, 11 Jan 89 19:53:31 PST
Received: by bhopal id AA07394g; Wed, 11 Jan 89 19:55:47 PST
Date: Wed, 11 Jan 89 19:55:47 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901120355.AA07394@bhopal>
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Cc: cl-cleanup@sail.stanford.edu, gls@think.com,
        richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
In-Reply-To: Jeff Dalton's message of Tue, 10 Jan 89 23:37:00 GMT <15927.8901102337@subnode.aiai.ed.ac.uk>
Subject: Possible issue: GCD-NO-ARGUMENTS

The LCM issue even appeared on Guy's "Clarifications" of 6-Dec-85".

Tobin's reasoning about GCD looks ok to me, but it might not be that
bad simply to say that 0 is a singluar point for GCD.

Not too long ago, I proposed adding rational infinities to CL (to the
general common-lisp mailing list, I think, rather than to Cl-cleanup);
by analogy to IEEE floating infinities, we could have -1/0 and 1/0 as
rational infinities.  There are a number of other reasons for wanting
these objects besides (GCD 0).


-- JonL --

∂11-Jan-89  2007	CL-Cleanup-mailer 	Issue: DYNAMIC-EXTENT (Version 2)   
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Jan 89  20:07:01 PST
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA16343@EDDIE.MIT.EDU>; Wed, 11 Jan 89 22:36:07 EST
Received: by spt.entity.com (smail2.5); 11 Jan 89 22:17:19 EST (Wed)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 11 Jan 89 15:16 PST <890111-151708-10854@Xerox>
Subject: Issue: DYNAMIC-EXTENT (Version 2)
Message-Id: <8901112217.AA15621@spt.entity.com>
Date: 11 Jan 89 22:17:19 EST (Wed)
From: gz@spt.entity.com (Gail Zacharias)

     Actually, a blurry issue is whether
      (LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
      => 1
     is well-defined. I refer to these stack-allocated things as being invalid
     return values, but in fact we might want to say that they're ok to return
     but that you just can't do any serious operations on them (ie, you can't
     expect them to still be lists, etc.) Can anyone imagine a pointer into
     unallocated stack causing problems for their GC? If so, we could be more
     clear on this point.

Yes, this would lose badly in our system if the outer call to LIST were to gc.
It's not pointing into unallocated stack that's the problem, it's pointing to
reallocated stack.

∂11-Jan-89  2016	CL-Cleanup-mailer 	Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)    
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 11 Jan 89  20:16:35 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 258908; Wed 11-Jan-89 23:12:43 EST
Date: Wed, 11 Jan 89 23:12 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
To: jonl@lucid.com, masinter.pa@Xerox.COM
cc: cl-cleanup@Sail.Stanford.Edu
In-Reply-To: <8901120148.AA07016@bhopal>
Message-ID: <19890112041220.9.GSB@GANG-GANG.SCRC.Symbolics.COM>

    Date: Wed, 11 Jan 89 17:48:32 PST
    From: Jon L White <jonl@lucid.com>

    re: As I think about it, I'm not sure why we rule out the possibility that the
	upgrading of arrays might happen differently for different arrays: for
	example, I might have an algorithm that "upgraded" all simple
	non-adjustable arrays with ARRAY-TOTAL-SIZE less than 2 to ELEMENT-TYPE T,
	but be more strict about larger arrays. 

    Lucid would certainly oppose that change.  Our compiler optimizations
    work on simple-arrays of known element type; and good reasons exist
    as to why the simple/non-simple distinction and the element-type
    distinctions are important (other "stock hardware" implmentations 
    have similar open-coding techniques).  I see no benefit to further 
    discrimination based on rank or array total size.


    -- JonL --

Right.  If you can't determine the upgraded type from a declaration, the
declaration is next to useless.  (It just is not reasonable to have to,
for instance, know the size of an array in order to be able to determine
how to access it.)

∂11-Jan-89  2138	CL-Cleanup-mailer 	Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  21:37:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 21:36:44 PST
Date: 11 Jan 89 21:34 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 9)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Wed, 11 Jan 89
 17:48:32 PST
To: Jon L White <jonl@lucid.com>
cc: Masinter.pa@Xerox.COM, cl-cleanup@Sail.Stanford.Edu
Message-ID: <890111-213644-11560@Xerox>

JonL, I was not suggesting a requirement that implementors would have to
upgrade different arrays differently. Why would Lucid oppose allowing other
implementors to take a different implementation strategy? Certainly your
compiler optimizations could continue to work based on your assertions
about your own array implementation types.

>    but be more strict about larger arrays.  The major part of the
proposal
>    ("Change the meaning of (TYPEP <x> '(ARRAY <type>)), where <type> is
not
>    *, to be true if and only if <x> is an array that could be the result
of
>    giving <type> as the :element-type argument to MAKE-ARRAY.") could be
kept,
>
>No, because you would have to say what the other arguments to MAKE-ARRAY
were.
>
>

You know what the other arguments to MAKE-ARRAY are by looking at <x>.
Imagine:

Implementation A upgrades integer ranges to (SIGNED-BYTE n) for n a power
of 2 up to 32, and then T.
Implementation B upgrades integer ranges to (SIGNED-BYTE 32) and then to T.
Implementation C upgrades simple small (say, less than total-size 2) arrays
like B, and other arrays like A.  

You can implement (C:TYPEP object type) by (if (simple-small-p object)
(b:typep object type) (a:typep object type)). I.e., TYPEP need not merely
be implemented by ARRAYP + a test on ARRAY-ELEMENT-TYPE. 

∂11-Jan-89  2148	CL-Cleanup-mailer 	New versions vs amendments
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  21:48:16 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 21:46:41 PST
Date: 11 Jan 89 21:45 PST
From: masinter.pa@Xerox.COM
Subject: New versions vs amendments
In-reply-to: Jon L White <jonl@lucid.com>'s message of Wed, 11 Jan 89
 19:24:39 PST
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, barmar@Think.COM, CL-CLEANUP@sail.stanford.edu
Message-ID: <890111-214641-11567@Xerox>

The problem with DECLARE-TYPE-FREE is that people only had a chance to see
the "wrong" version. If there are issues that have been released, and we
think we will want to amend them, we can bring along copies of the
amended/edited issues; I think it will actually make it easier than trying
to edit them on the fly. 

Better still would be to have the amendment *and* the amended version. I
think that would allow people who made up their mind about an earlier
version to see what was different. 

We also have to be more conservative about wording changes to minimize the
differences. 

∂11-Jan-89  2222	CL-Cleanup-mailer 	Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jan 89  22:22:27 PST
Received: from Semillon.ms by ArpaGateway.ms ; 11 JAN 89 22:21:18 PST
Date: 11 Jan 89 22:20 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
In-reply-to: David N Gray <Gray@DSG.csc.ti.com>'s message of Tue, 3 Jan 89
 10:46:29 CST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890111-222118-11592@Xerox>

I hadn't given much thought to this issue before. In Medley, we represented
"unspecific" components by the empty string. 

I.e., "foo." => (host nil device nil directory nil name "foo" type ""
version nil), 

while "foo" => (host nil device nil directory nil name "foo" type nil
version nil).

Why do you need a separate keyword?

∂12-Jan-89  0033	CL-Cleanup-mailer 	Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89  00:33:05 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 00:31:54 PST
Date: 12 Jan 89 00:30 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: cl-cleanup@sail.stanford.edu
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Message-ID: <890112-003154-11895@Xerox>

[lmm: from Ballot]

    I can understand why someone might find the need for :UNSPECIFIC
    in Unix unclear, but I think that is because it is not clear what
    filenames would be parsed as pathnames with :UNSPECIFIC type [*];
    :UNSPECIFIC is nonetheless useful for building pathnames directly
    when you know which case you want and need a way to specify it.

    [*] Does a name without "." parse as type NIL or :UNSPECIFIC?
    Different Unix programs use different conventions.  Some are
    willing to merge in a type field, others, such as the C compiler,
    leave names as-is.  So the "right" answer may vary.    

∂12-Jan-89  0037	CL-Cleanup-mailer 	Issue: PROCLAIM-SPECIAL (Version 9) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89  00:37:52 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 00:34:46 PST
Date: 12 Jan 89 00:34 PST
Sender: masinter.pa@Xerox.COM
Subject: Issue: PROCLAIM-SPECIAL (Version 9)
To: cl-cleanup@sail.stanford.edu
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
line-fold: NO
Message-ID: <890112-003446-11899@Xerox>



[From Ballot]
    Under this proposal, special proclamations establish a default for
    a name but, because of the lexical declaration, no longer force it
    to be special everywhere.  It also allows the programmer to say
    that a global name is intended as a variable (i.e., references to
    it are not spelling mistakes) without proclaiming it special.  I
    think these are important changes that should be preserved even if
    this proposal fails.  Another important feature is that LG references
    to global variables can be fast in deep-bound implementations (since
    L "searches" can be compiled away) while DG references (the only
    global variables we have now) first have to look in D.  Finally,
    the current semantics are subtly confusing, because the specialness
    of global variables occasionally shows through.  For all of these
    reasons, I support this proposal.

    I think the most controversial change is the introduction of a
    separate global environment, where before the only globals were
    effectively just the global end of the dynamic env.  Most of the
    implementation complexity stems from this change, and it is likely
    that it lies behind most objections.
    
    A reasonable fallback, if this proposal does not pass, would be
    to say that variables that are proclaimed lexical can never by
    given dynamic bindings.  That is, the global value would be taken
    after searching L or D but not both and so would effectively be
    an extension of the L or D env, case by case.  This would be
    somewhat unfortunate, because local lexical bindings for names
    proclaimed special would still make sense (because they could be
    declared lexical) but we wouldn't allow local special declarations
    for names proclaimed lexical.  The full proposal is better.    

∂12-Jan-89  0048	CL-Cleanup-mailer 	Issue: TAGBODY-CONTENTS (Version 5) 
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89  00:48:21 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 00:45:14 PST
Date: 12 Jan 89 00:44 PST
From: masinter.pa@Xerox.COM
Subject: Issue: TAGBODY-CONTENTS (Version 5)
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
 message of Thu, 12 Jan 89 03:57:03 GMT
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890112-004514-11904@Xerox>

On your ballot, you said:

"Contents should be valid forms (including self-evaluating) or valid tags.
Duplicate tags should be an error (as in the proposal)."

However, the EVAL-OTHER proposal passed at the last meeting makes all
"other" objections self-evaluating.

∂12-Jan-89  0309	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 9)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Jan 89  03:09:23 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04762g; Thu, 12 Jan 89 03:05:07 PST
Received: by bhopal id AA01044g; Thu, 12 Jan 89 03:07:24 PST
Date: Thu, 12 Jan 89 03:07:24 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901121107.AA01044@bhopal>
To: Gray@DSG.csc.ti.com
Cc: masinter.pa@Xerox.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: David N Gray's message of Wed, 11 Jan 89  10:10:01 CST <2809527001-3602765@Kelvin>
Subject: Issue: DECLARE-TYPE-FREE (Version 9)

re: [JonL] I would go for a version that treated an inner declaration
           as if it were the intersection of the outter one.  How about you?
    [Gray] Agreed.  That's what version 6 of DECLARE-TYPE-FREE said:

      Clarify that if nested type declarations refer to the same variable,
      then the value of the variable must be a member of the intersection of
      the declared types.

Version 2 (but not Version 1) also had that phraseology in it.   Looks 
like that paragraph fell into "Masinter's Hole" (that's the hole that 
Larry said he hoped he wouldn't dig himself into when he began tinkering
with it late at night, just before Releasing it to X3J13).  Probably Moon
lost track of it when he added the LEXICAL proposal (i.e., trying to fill
in the "Hole").  

We definitely need that phrase.


-- JonL --

∂12-Jan-89  0420	CL-Cleanup-mailer 	Issue: DEFPACKAGE (Version 7)  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Jan 89  04:20:19 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04802g; Thu, 12 Jan 89 04:14:35 PST
Received: by bhopal id AA01212g; Thu, 12 Jan 89 04:16:52 PST
Date: Thu, 12 Jan 89 04:16:52 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901121216.AA01212@bhopal>
To: peck@Sun.COM
Cc: masinter.pa@Xerox.COM, barmar@Think.COM, CL-CLEANUP@sail.stanford.edu
In-Reply-To: peck@Sun.COM's message of Wed, 11 Jan 89 18:21:37 PST <8901120221.AA08867@denali.sun.com>
Subject: Issue: DEFPACKAGE (Version 7) 

Here's an excerpt from Version 7:

  It is noted that DEFPACKAGE cannot be used to create two "mutually
  recursive" packages, such as:
   (defpackage my-package
     (:use lisp your-package)           ;requires 'your-package' to exist first
     (:export "MY-FUN"))
   (defpackage your-package
     (:use lisp)
     (:import-from my-package "MY-FUN") ;requires 'my-package' to exist first
     (:export "MY-FUN"))
  However, nothing prevents one from using the package-effecting functions 
  such as USE-PACKAGE, IMPORT, and EXPORT to establish such links (which
  ought to be very rare) after a more standard use of DEFPACKAGE.


The problem is similar to "defining" a circular list; typically you
have to start out with a non-circular "definition" [e.g., such as
by (CONS 'A NIL)] and then make a circularizing step [e.g., such as
(RPLACD X X)].

Your two-pass approach would *probably* work in many reasonable 
implementations, even though the two passes would be "at variance"
by the definitions given previously.  The problem still seems to
be that we "ran out of time" before agreeing on how to reconcile
two defpackage calls that weren't basically the same.


-- JonL --

∂12-Jan-89  0520	CL-Cleanup-mailer 	** BALLOT ** BALLOT ** BALLOT ** BALLOT **    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 12 Jan 89  05:20:12 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04822g; Thu, 12 Jan 89 05:16:01 PST
Received: by bhopal id AA01326g; Thu, 12 Jan 89 05:18:18 PST
Date: Thu, 12 Jan 89 05:18:18 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901121318.AA01326@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 12 Dec 88 18:16 PST <881212-181649-5908@Xerox>
Subject: ** BALLOT ** BALLOT ** BALLOT ** BALLOT **

This ballot represents the consensus of senior "wizards" at Lucid; we
hope the information helps in deciding what issues to "bundle" together.

We recognize this ballot as a "straw poll" rather than an official X3 
ballot; our official votes will be given in the ususal channels (e.g., 
by Dick or myself at the X3J13 meeting), most likely along the lines 
indicated below. 


-- JonL --



Y   ARGUMENTS-UNDERSPECIFIED:SPECIFY
	    Version 4, 21-Sep-88, Mailed 4 Dec 88


Y   ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING
	    Version 9, 31-Oct-88, Mailed 5 Dec 88


Y   CLOSED-STREAM-OPERATIONS:ALLOW-INQUIRY
	    Version 5,  5-Dec-88, Mailed 5 Dec 88


Y   CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE
	    Version 1, 14-Sep-88, Mailed 6 Oct 88


Y   DECLARATION-SCOPE:NO-HOISTING
Y   DECLARATION-SCOPE:LIMITED-HOISTING
	    Version 4, 15-Nov-88, Mailed 9-Dec-88


Y   DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION
	    Version 4,  5-Dec-88, Mailed  5-Dec-88


N   DECLARE-TYPE-FREE:ALLOW
	    Version 8, 7-Dec-88, Mailed 9-Dec-88
  We wish to vote yes on a corrected, extended version of "LEXICAL"


Y   DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE
	    Version 2, 30-Sep-88, Mailed 6 Oct 88


Y   DEFPACKAGE:ADDITION
	    Version 7, 2-Nov-88, Mailed 5 Dec 88


Y   DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
	    Version 2, 21-Sep-88, Mailed 6 Oct 88


Y   DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
	    Version 3, 7 Dec 88, Mailed 12-Dec-88


Y   DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR
	    Version 4, 31-Oct-88, Mailed 12-Dec-88
  And we think there should be a more detailed explanation of
  why the current state has a problem.


N   DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE
N   DESCRIBE-INTERACTIVE:NO
	    Version 4, 15-Nov-88	, Mailed 7-Dec-88

Y   DOTTED-MACRO-FORMS:ALLOW
	    Version 3, 15-Nov-88, Mailed 7-Dec-88


N   EQUAL-STRUCTURE:STATUS-QUO
	    Version 5, 1-Oct-88, Mailed 8 Oct 88


N   EXIT-EXTENT:MINIMAL
N   EXIT-EXTENT:MEDIUM
	    Version 5, 12-Dec-88, Mailed 12-Dec-88
   [I think we felt that the current vague state is better than
    a muddled attempt to fix it; we are currently in the process of 
    doing extensive work on this question for QLISP  -- JonL --]


Y   EXPT-RATIO:P.211
	    Version 3, 31-Oct-88, Mailed 7 Dec 88


N   FIXNUM-NON-PORTABLE:TIGHTEN-DEFINITION
N   FIXNUM-NON-PORTABLE:TIGHTEN-FIXNUM-TOSS-BIGNUM
	    Version 4, 7-Dec-88, Mailed 12-Dec-88
  We feel that fixnums could be made portably useful only if they were
  required to be large enough to cover both array indices and object
  counts; neither proposal is strong enough about these points.


Y   FORMAT-E-EXPONENT-SIGN:FORCE-SIGN
	    Version 2, 2 Oct 88, Mailed 6 Oct 88


Y   FORMAT-PRETTY-PRINT:YES
	    Version 7, 15 Dec 88, Mailed 7 Dec 88


N   FUNCTION-COMPOSITION:NEW-FUNCTIONS
N   FUNCTION-COMPOSITION:COMPLEMENT-AND-ALWAYS
	    Version 4, 12 Dec 88, Mailed 12 Dec 88


N   FUNCTION-DEFINITION:FUNCTION-SOURCE
	    Version 2, 09-Dec-88	, Mailed 9 Dec 88
  The name FUNCTION-SOURCE sounds too much like a source-file facility
  [Lucid has such a thing].  We might accept the proposal if the name
  were SOURCE-CODE; unfortunately, though this is in Lucid's documentation,
  we are not really happy with that name either.


Y   FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE
	    Version 3, 7-Dec-88, Mailed  12-Dec-88


Y   FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE
	    Version 5, 14-Nov-88	, Mailed 8-Dec-88


Y   GET-MACRO-CHARACTER-READTABLE:NIL-STANDARD
	    Version 2, 8 Dec 88, Mailed 8 Dec 88


Y   HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER
	    Version 7, 8-Dec-88, Mailed 9-Dec-88
  And fix the typo in the example.


Y   HASH-TABLE-STABILITY:KEY-TRANSFORM-RESTRICTIONS
	    Version 1, 11-Nov-88	, Mailed 12 Dec 88


Y   HASH-TABLE-TESTS:ADD-EQUALP
	    Version 2, 8-Dec-88, Mailed 8 Dec 88


Y   IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY
	    Version 4, 12-Dec-88, Mailed 12-Dec-88


N   LAMBDA-FORM:NEW-MACRO
	    Version 4, 22-Nov-88, Mailed 8-Dec-88


Y   LCM-NO-ARGUMENTS:1
	    Version 1, 17 Oct 88, Mailed 8 Dec 88


N   LISP-SYMBOL-REDEFINITION:DISALLOW
	    Version 5, 22-Nov-88, Mailed 8 Dec 88
  We prefer a much simpler statement, such as "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)."
  

Y   MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
	    Version 2, 8 Oct 88, Mailed 12-Dec-88


Y   MAPPING-DESTRUCTIVE-INTERACTION:EXPLICITLY-VAGUE
	    Version 2, 09-Jun-88, Mailed 8 Oct 88


N   NTH-VALUE:ADD
	    Version 4, 8-Dec-88, Mailed 8 Dec 88


Y   PACKAGE-CLUTTER:REDUCE
	    Version 6, 12-Dec-88, Mailed 12-Dec-881


Y   PACKAGE-DELETION:NEW-FUNCTION
	    Version 5, 21 nov 88, Mailed 8 Dec 88


Y   PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN
	    Version 1 27-Jun-88, Mailed 7 Oct 88
  But the Cost to Implementors is wrong -- it will cost us something.


Y   PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR
	    Version 3, 8-Oct-88, Mailed 8 Oct 88
  But we feel that the proposal could be reduced from three pages
  to three sentences.


Y   PRINT-CIRCLE-STRUCTURE:USER-FUNCTIONS-WORK
	    Version 3, 20 Sep 88, Mailed 8 Oct 88


N   PROCLAIM-LEXICAL:LG
	    Version 9, 8-Dec-88, Mailed 12-Dec-88
  We could only accept this if it is clearly spelled out that it is
  an error to make a dynamic binding of a proclaimed lexical variable;
  we could not find such a statement in the proposal.


Y   RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER
	    Version 3, 9-Oct-88, Mailed 14-Oct-88


Y   RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL
	    Version 1, 14-Sep-88, Mailed 7 Oct 88


A   REQUIRE-PATHNAME-DEFAULTS:ELIMINATE
	    Version 6, 9 Dec 88, mailed 09 Dec 88
  [This is not a "dont care"; we were unable to decide what to do. --JonL --]


Y   REST-LIST-ALLOCATION:NEWLY-ALLOCATED
N   REST-LIST-ALLOCATION:MAY-SHARE
N   REST-LIST-ALLOCATION:MUST-SHARE
	    Version 3, 12-Dec-88, mailed 12-Dec-88
  We "buy" Will Clinger's argument about the semantics of APPLY.


Y   RETURN-VALUES-UNSPECIFIED:SPECIFY
	    Version 6,  9 Dec 88 mailed  9-Dec-88


N   ROOM-DEFAULT-ARGUMENT:NEW-VALUE
	    Version 1 12-Sep-88 mailed 8 Oct 88
  We do not feel that ROOM is so much different than any other function
  which has optional arguments; perhaps a much more general proposal is
  called for that would address the question of "explicitly" not supplying
  optional and keyword arguments.


    [The following are mutually exclusive]
I   SETF-FUNCTION-VS-MACRO:SETF-FUNCTIONS
	    Version 3, 4-Nov-87, mailed Nov 87
Y   SETF-PLACES:ADD-SETF-FUNCTIONS
	    Version 1, 11-Nov-88, mailed 9-Dec-88
  We could live with either proposal; however the earlier one fails to
  address several necessary issues of cleanup for the CLOS document; it
  would be acceptable to us if it simply incorporated the wording from 
  the later proposal.


Y   SETF-SUB-METHODS:DELAYED-ACCESS-STORES
	    Version 5, 12-Feb-88 mailed 8 Oct 88


Y   STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS
	    Version 8, 8 Jul 88, Mailed 7 Oct 88


Y   STEP-ENVIRONMENT:CURRENT
	    Version 3, 20-Jun-88, mailed  7 Oct 88


Y   STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS
	    version 2, 30-Nov-88 mailed  9 Dec 88
	    (expect amendment T => "true")
  We vote Yes for all three proposals on this issue, but really prefer
  the first one, namely STREAM-ACCESS:ADD-TYPES-PREDICATES-ACCESSORS.


N   STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS
	    Version 6, 30-Nov-88, mailed 9 dec 88
	    expect amendment:
		    LINE-WIDTH   ==> STREAM-LINE-WIDTH
		    LINE-POSITION ==> STREAM-LINE-POSITION
		    PRINTED-WIDTH ==> STREAM-STRING-WIDTH
  We "buy" Gail Zacharias' arguments about a false illusion of portability.


Y   SUBTYPEP-TOO-VAGUE:CLARIFY
	    Version 4,  7-Oct-88, mailed 7 Oct 88 


Y   SYMBOL-MACROLET-DECLARE:ALLOW
	    Version 2,  9-Dec-88, mailed 9 Dec 88


Y   SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM
	    Version 5, 30-Nov-88, mailed 9 Dec 88


Y   TAGBODY-CONTENTS:FORBID-EXTENSION
	    Version 5, 9-Dec-88 mailed 9 Dec 88


N   TAILP-NIL:T
	    Version 5, 9-Dec-88, mailed 12-Dec-88
  It's a waste of time to worry about TAILP; it's not worth bothering about.


N   TEST-NOT-IF-NOT:FLUSH-ALL
N   TEST-NOT-IF-NOT:FLUSH-TEST-NOT
	    Version 3, 1 Dec 88 mailed 9 dec 


Y   TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS
	    Version 3, 12-Dec-88, mailed 12 Dec 88
	    (some "bugs" in the proposal)


Y   UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW
	    Version 2, 2-Dec-88, mailed 12-Dec-88


Y   VARIABLE-LIST-ASYMMETRY:SYMMETRIZE
	    Version 3, 08-Oct-88, mailed 9 Dec 88

∂12-Jan-89  0924	CL-Cleanup-mailer 	Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Jan 89  09:24:48 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 520199; Thu 12-Jan-89 12:22:52 EST
Date: Thu, 12 Jan 89 12:22 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890112-003154-11895@Xerox>
Message-ID: <890112122239.6.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: 12 Jan 89 00:30 PST
    From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>

    [lmm: from Ballot]

	I can understand why someone might find the need for :UNSPECIFIC
	in Unix unclear, but I think that is because it is not clear what
	filenames would be parsed as pathnames with :UNSPECIFIC type [*];
	:UNSPECIFIC is nonetheless useful for building pathnames directly
	when you know which case you want and need a way to specify it.

	[*] Does a name without "." parse as type NIL or :UNSPECIFIC?
	Different Unix programs use different conventions.  Some are
	willing to merge in a type field, others, such as the C compiler,
	leave names as-is.  So the "right" answer may vary.    

Symbolics systems have a consistent rule for use in the absence of a file
system specific convention: assume that the last dot (if any) separates the
name from the type.

If there is no last dot, then the type is :UNSPECIFIC. If there is a last
dot, then the text to the right (even if null) is the type and the text to
the left (even if null) is the name.

This rule means that:
 "." has name "" and type "".
 ".." has name "." and type "".

You might say that this is not the optimal mapping, but after all:
"." and ".." were quite obviously chosen to be screwy file names so 
they wouldn't get in the way of other more important namespaces.
If you look at it that way, it's quite appropriate that they get
internal names which are not "easy" to generate.

Whether "." was name "." and type :unspecific (as I mentioned
is possible) or name "" and type "" (as we implement), it would not
merge a type. In either case, you could make a new pathname with
the same fields but with :TYPE NIL and then it would merge a type.

Anyway, just to flesh this out,
 "Foo"  has name "Foo" and type :UNSPECIFIC.
 "Foo." has name "Foo" and type ""
 "Foo.Bar.Lisp" has name "Foo.Bar" and type "Lisp"
 ".Lisp" has name "" and type "Lisp"

I wasn't involved in the choice of how this was partitioned and I admit
to being surprised at the partitioning, but I've come to believe that it
was the correct thing. For example, it would be very much the wrong thing
if a double-dot made for a dotted extension (ie, "Foo.Bar.Lisp" had name
"Foo" and type "Bar.Lisp") so you have to take the dots from the right.

It would not cause internal confusion to exempt "." and ".." and say
that they parsed as name "." and type :unspecific,etc. since in fact
there is no namestring which will parse to that. On the other hand, while
it might appease some people, it would make the rule harder to remember.

Anyway, I'm not so much proposing that we standardize this kind of thing
because personally I think it's very inappropriate for a generic
standard like the one we're making to favor some vendors over others
(since it's clear that we can't have info on everyone).  I was just trying
to give you a flavor of where I'm coming from in all this.

By the way -- someone asked about why "Foo" can't be parsed as 
name "Foo" and type NIL. The answer is that it doesn't merge correctly.
If your file defaults are something with an extension (eg, name "Foo"
and type "Lisp"), and you do (OPEN "Baz"), you should to open "Baz",
not "Baz.Lisp". If you don't, there is no way to open "Baz" without 
putting NIL in the standard pathname defaults before you do the open
to make sure that merge doesn't succeed in removing all NILs, and it's
my impression you're not supposed to be doing that kind of thing.
If  #S(PATHNAME :NAME "Foo" :TYPE :UNSPECIFIC) keeps a type from merging
and #S(PATHNAME :NAME "Foo" :TYPE NIL) allows a type to merge, then
you have the best of both worlds.

∂12-Jan-89  0937	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 5)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 12 Jan 89  09:37:16 PST
Received: by ti.com id AA15485; Thu, 12 Jan 89 11:36:17 CST
Received: from Kelvin by tilde id AA22767; Thu, 12 Jan 89 11:18:47 CST
Message-Id: <2809617663-9049854@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 12 Jan 89  11:21:03 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: masinter.pa@Xerox.COM
Cc: Jon L White <jonl@lucid.com>, IIM%ECLA@ECLC.USC.EDU,
        cl-cleanup@sail.stanford.edu
Subject: Re: Issue: EQUAL-STRUCTURE (Version 5)
In-Reply-To: Msg of 9 Jan 89 22:30 PST from masinter.pa@Xerox.COM

> What is current practice in this area? What does EQUALP do in current
> implementations on hash tables?

It turns out that the Explorer attempts to compare the contents of non-EQ hash
tables of the same size but gets an error in the process.  Since no one has
reported this bug before, it appears that no one has been trying to use EQUALP
on hash tables.  Might as well take the easy way out and specify that hash
tables are only compared by EQ.

∂12-Jan-89  0953	CL-Cleanup-mailer 	Re: Issue: EQUAL-STRUCTURE (Version 6)   
Received: from ti.com by SAIL.Stanford.EDU with TCP; 12 Jan 89  09:53:43 PST
Received: by ti.com id AA15540; Thu, 12 Jan 89 11:52:41 CST
Received: from Kelvin by tilde id AA23022; Thu, 12 Jan 89 11:32:26 CST
Message-Id: <2809618485-9099259@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 12 Jan 89  11:34:45 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: EQUAL-STRUCTURE (Version 6)
In-Reply-To: Msg of Wed, 11 Jan 89 14:39 EST from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

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

It is also true on the Explorer that Flavor instances are not descended by
EQUALP.  However, I imagine that this was just an oversight in the addition of
EQUALP to the implementation, and am of the opinion that it would be better if
it did compare the components.  The only problem I can think of with doing that
is handling unbound slots; perhaps it needs to be specified that two unbound
slots are EQUALP and an unbound slot is never EQUALP to a bound slot.

∂12-Jan-89  1038	CL-Cleanup-mailer 	Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Jan 89  10:38:12 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 520273; Thu 12-Jan-89 13:36:09 EST
Date: Thu, 12 Jan 89 13:35 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890111-222118-11592@Xerox>
Message-ID: <890112133559.7.KMP@BOBOLINK.SCRC.Symbolics.COM>

Ah, I thought I'd dropped my pointer to this message. Even though I answered
it in mail to Jeff a bit ago, I want to make sure it's filed where the answer
can be found, since it's important:

    Date: 11 Jan 89 22:20 PST
    From: masinter.pa@Xerox.COM

    I hadn't given much thought to this issue before. In Medley, we represented
    "unspecific" components by the empty string. 

The null type is not what we call an unspecific component.

    I.e., "foo." => (host nil device nil directory nil name "foo" type ""
    version nil), 

This is a null type.

    while "foo" => (host nil device nil directory nil name "foo" type nil
    version nil).

This is an unspecific type, but it cannot be represented this way because of
reasons outlined in the problem description of this proposal.

    Why do you need a separate keyword?

It doesn't merge right. If I have two Unix files "stuff" and "stuff.l" and I do
(OPEN "stuff") from within Lisp while the file defaults are for "/joe/foo.l"
then, you will open "stuff.l" rather than "stuff" if you have represented the
unspecific type as NIL because of the way Lisp pathname merging is defined to
work.

Since Unix allows you to create files which deliberately have no type (and so
do not want to have a type merged into them), there must be a way to distinguish
 "This pathname has no type but wants one." (type = NIL)
from
 "This pathname has not type for a reason." (type = :UNSPECIFIC)
from
 "This pathname has a type which is null." (type = "")

I hope this helps clarify things.

∂12-Jan-89  1054	CL-Cleanup-mailer 	Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89  10:53:58 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 10:51:24 PST
Date: 12 Jan 89 10:49 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-UNSPECIFIC-COMPONENT (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
 of Thu, 12 Jan 89 13:35 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890112-105124-12781@Xerox>

Yes, I remember this now, sorry. 




∂12-Jan-89  1106	CL-Cleanup-mailer 	Re: Issue: PROCLAIM-SPECIAL (Version 9)  
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89  11:05:57 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 11:02:42 PST
Date: 12 Jan 89 11:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PROCLAIM-SPECIAL (Version 9)
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
 message of 12 Jan 89 00:34 PST
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890112-110242-12820@Xerox>

I made a mistake when sending out the message; the Subject is incorrect.
The issue name  is PROCLAIM-LEXICAL, of course.


∂12-Jan-89  1106	CL-Cleanup-mailer 	Issue: DECLARE-TYPE-FREE (Version 10)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89  11:05:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 10:56:13 PST
Date: 12 Jan 89 10:55 PST
From: masinter.pa@Xerox.COM
Subject: Issue: DECLARE-TYPE-FREE (Version 10)
To: cl-cleanup@Sail.Stanford.Edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890112-105613-12795@Xerox>

I'm not distributing this to X3J13 just in case there are *more*
edits necessary.

!
Forum:         Cleanup
Issue:         DECLARE-TYPE-FREE
References:    CLtL p.158
               DECLARATION-SCOPE
Related issues: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
               DECLARATION-SCOPE
               SPECIAL-TYPE-SHADOWING
Category:      CLARIFICATION/ADDITION

Edit history:  Version 1, 18-Sep-88, Moon
               Version 2, 22-Sep-88, Moon
                (small edits to reflect mail discussion)
               Version 3, 22-Sep-88, Masinter
               Version 4, 27-Sep-88, JonL 
               Version 5, 30-Sep-88, Masinter (cost to implementors)
               Version 6, 06-Oct-88, Pitman (minor edits in Discussion)
               Version 7,  5-Dec-88, Masinter (scope->extent)
               Version 8,  7-Dec-88, Masinter (back to scope)
               Version 9,  2-Jan-89, Moon (2 proposals, to clarify discussion)
               Version 10, 12-Jan-89, Masinter (add back lost v.6 phrase 
                                                re nested declarations)


Problem description:

  Section 9.2 of CLtL, p158, says that a declaration specifier like
  (TYPE type var1 var2 ...) "... affects only variable bindings".  
  Since declarations can occur in contexts other than establishing 
  "variable bindings", most people interpret this statement to mean 
  that type declarations not in such context are either (1) completely 
  to be ignored, or (2) invalid CL  syntax.  Thus both of the following 
  forms would be suspect in that the type declarations could not have 
  any effect:

    (if (and (typep x 'fixnum) (typep y 'fixnum))
        (locally (declare (fixnum x y))             ;LOCALLY does not bind
          ...algorithm using x and y...)            ; any variables.
        ...similar algorithm using x and y...)

    (let ((y 'foo))
      (setq y 10)
      (let ((x 5))                                  ;'y' is not being bound in
        (declare (fixnum y))                        ; this particular context.
        (incf y)
         ...random algorithm...))


Proposal (DECLARE-TYPE-FREE:ALLOW):
  
  Specify that a type declaration does not only "affect variable bindings";
  rather, type declarations are legal in all declarations. The interpretation
  of a type declaration is that, during the execution of any expression 
  within the scope of the declaration,  it is an error for the value of
  the declared variable not to be of the declared type. For declarations
  that are associated with variable bindings, the type declaration also
  applies to the initial binding of the variable. In the special case
  of a declaration for which there are no executable expressions
  within the scope of the declaration (e.g., (locally (declare (integer x)))),
  the result is as if there were executable expressions.

  In this proposal, a type declaration affects not only variable
  references within its scope, but also affects variable references that
  are outside the scope of the declaration but dynamically inside the
  execution of a form that is itself inside the scope of the
  declaration.  Such references can exist when the variable is SPECIAL
  or when the declaration is not attached to the variable's binding, so
  that the scope of the declaration does not include the entire scope
  of the variable.

  Clarify that if nested type declarations refer to the same variable,
  then the value of the variable must be a member of the intersection of
  the declared types.


Proposal (DECLARE-TYPE-FREE:LEXICAL):

  Specify that a type declaration does not only "affect variable bindings";
  rather, type declarations are legal in all declarations. The interpretation
  of a type declaration is that, during the execution of any reference to the
  declared variable within the scope of the declaration, it is an error for
  the value of the declared variable not to be of the declared type; and
  during the execution of any SETQ of the declared variable within the scope
  of the declaration, it is an error for the newly assigned value of the
  declared variable not to be of the declared type; and at the moment the
  scope of the declaration is entered, it is an error for the value of the
  declared variable not to be of the declared type.

  In this proposal, a type declaration affects only variable references within
  its scope, and the meaning of "free" and "variable-binding-associated" type
  declarations can be described identically.

  This proposal is equivalent to saying that the meaning of a type declaration
  is equivalent to changing each reference to <var> within the scope of the
  declaration to (THE <type> <var>), changing each expression assigned to the
  variable within the scope of the declaration to (THE <type> <new-value>),
  and executing (THE <type> <var>) at the moment the scope of the declaration
  is entered.

  Clarify that if nested type declarations refer to the same variable,
  then the value of the variable must be a member of the intersection of
  the declared types.

Examples:

;; this is an error under DECLARE-TYPE-FREE:ALLOW:
;; the assertion that x is a fixnum is violated between the two 
;; calls to (zap)
;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL

        (let ((x 12) (y 'foo))
          (flet ((zap () (rotatef x y)))
            (locally (declare (fixnum x))
              (zap)
              (zap)
              x)))

;; this is an error under both proposals

        (let ((x 12) (y 'foo))
          (flet ((zap () (rotatef x y)))
            (locally (declare (fixnum x))
              (zap)
              (print x)
	      (zap)
              x)))

;; this is an error under DECLARE-TYPE-FREE:ALLOW, because
;; the assertion that x is a fixnum
;; is violated during the call to zap, even though few 
;; implementations will be able to check:
;; this is a valid program under DECLARE-TYPE-FREE:LEXICAL

        (let ((x 12) (y 'foo))
          (flet ((zap ()
                   (rotatef x y)
                   (rotatef x y)))
            (locally (declare (fixnum x))
              (zap)
              x)))

;; this is an error under both proposals, even though the
;; violation of the type constraint happens after the form
;; with the declaration is exited.

   (let ((f (let ((x 3))
              (declare (fixnum x))
              #'(lambda (z) (incf x z)))))
     (funcall f 4.3))


Rationale:

  This proposal enables optimizing compilers to make use of the otherwise
  ignored type information.  Many people have often asked for it, and
  there is no strong reason to forbid it.
  
  DECLARE-TYPE-FREE:ALLOW is more restrictive on programs and hence allows
  more freedom for optimizing compilers.  DECLARE-TYPE-FREE:LEXICAL is easier
  to understand but allows a specialized representation only where the scope
  of the variable is the same as the scope of the declaration or the compiler
  can prove that there are no relevant other references to the variable.

Current practice:

  Lucid Common Lisp allows "free" type declarations;  under some 
  circumstances the compiler issues a warning message that such usage 
  is an extension to Common Lisp.

Cost to Implementors:

  Implementations that might currently warn about such declarations
  would have to remove the warning; otherwise, it is valid to ignore 
  type declarations.

Cost to Users:

  None, this is a compatible addition.

Cost of non-adoption:

  Common Lisp will be less self-consistent.

Benefits:

  Programmers will be able to use type declaration to express their
  intent, rather than having to manually insert THE wrappers around 
  every reference.


Esthetics:

  It is a simpler interpretation for type declaration specifiers, with
  fewer special cases; hence reduces the number of exceptions in the
  language.

Discussion:

  Another cleanup issue, DECLARATION-SCOPE, addresses the scope of 
  declarations. This proposal carefully uses the phrase "within the 
  scope of the declaration" to avoid confounding the two issues. 

  This issue has been discussed at the Fort Collins X3J13 meeting in
  November 1987, and at length on the various electronic mailing lists.

  At least one current implementation is able to generate more efficient
  code when declarations are associated with a particular binding, since
  it then has the option to choose type-specific specialized storage for 
  the runtime value of the variable.  So, for example, 

      (let ((x v)) (declare (type float x)) (+ x x))

  is sometimes more efficient than

      (let ((x v)) (locally (declare (type float x)) (+ x x)))

  However, the local type declarations allowed by this proposal do
  provide some useful information, even if it is not the *most* useful.
  It is possible for a sufficiently "smart" compiler to infer the 
  equivalent of a "binding declaration" when it can ascertain that the 
  type of the binding value -- 'v' above -- is commensurate with the 
  type locally declared over the scope of usage of the variable.

  It may be useful for a compiler to issue a warning whenever it finds
  nested type declarations referring to the same variable and the
  intersection of the declared types is null.

  Documentation might want to discuss the style implications of
  nested declarations intersecting. The interesting cases are:
   - An inner declaration could be a subtype of an outer one.
     This is the most useful case and probably the only one to
     be encouraged in code written by humans. e.g.,
       (locally (declare (type number x))
         (locally (declare (type integer x))
           ...use X as integer...))
   - An outer declaration could be a subtype of an inner one.
     This is useless but harmless. It might happen as the result
     of certain macro situations. e.g.,
       (locally (declare (type integer x))
         (locally (declare (type number x))
           ...use X as integer...))
   - Two types may only partially overlap. This would presumably
     happen only as the result of a macro expansion.
       (locally (declare (type fixnum x))
         (locally (declare (type (or bit package) x))
           ...use X as BIT...))

∂12-Jan-89  1124	CL-Cleanup-mailer 	Issue: NTH-VALUE (Version 4)   
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Jan 89  11:24:46 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 520320; Thu 12-Jan-89 14:23:03 EST
Date: Thu, 12 Jan 89 14:22 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: NTH-VALUE (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890112142253.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

Some additional data on this topic, based on practical experience with
people using multiple values over the past year.

Since there is no convention for use of IGNORE or NIL in multiple-value
argument lists in Common Lisp, it is a common complaint that Cloe gets
from users of Genera that they must rewrite:

 (MULTIPLE-VALUE-BIND (IGNORE Y)
     (SEND FROB :READ-CURSORPOS)
   ...)

to do

 (MULTIPLE-VALUE-BIND (IGNORE Y)
     (SEND FROB :READ-CURSORPOS)
   (DECLARE (IGNORE IGNORE))
   ...)

I usually tell them that Common Lisp is considering an NTH-VALUE
primitive so they could write

 (LET ((Y (NTH-VALUE (SEND FROB :READ-CURSORPOS) 1)))
   ...)

and they are mostly appeased.

Recently, however, someone asked me how he could do what in
Symbolics Lisp would be written as:

 (MULTIPLE-VALUE-SETQ (IGNORE Y) (SEND FROB :READ-CURSORPOS))

The only rewrites I could think of for this were much yuckier, so I
thought I'd raise the issue. With NTH-VALUE it would be 

 (SETQ Y (NTH-VALUE (SEND FROB :READ-CURSORPOS) 1))

but without it, all I could come up with were:

 (MULTIPLE-VALUE-BIND (XX YY)
     (SEND FROB :READ-CURSORPOS)
   (DECLARE (IGNORE XX))
   (SETQ Y YY))

or

 (SETQ Y (MULTIPLE-VALUE-BIND (XX YY)
             (SEND FROB :READ-CURSORPOS)
             (DECLARE (IGNORE XX))
	     YY))

or

 (SETQ Y (CADR (MULTIPLE-VALUE-LIST (SEND FROB :READ-CURSORPOS))))

I consider this case to be much yuckier than previous examples I've
seen, and it strengthens my belief in the need for NTH-VALUE.

In the absence of NTH-VALUE, we should consider the possibility
of permitting NIL in the argument list to MULTIPLE-VALUE-BIND and
MULTIPLE-VALUE-SETQ to denote an argument which is not to be assigned.
The good points of that would be
 - it is fairly concise syntactically.
 - it doesn't accomodate a variable index like NTH-VALUE does.
   Some implementors might prefer not to have to write that code.
The bad points of that would be
 - NIL can fall through from lots of places in macros, etc. so error
   checking is reduced.
 - it's a special case, and so aesthetically ugly to some.
 - it doesn't accomodate a variable index like NTH-VALUE does.
   Some users might prefer not to have to write that code.

∂12-Jan-89  1143	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89  11:43:23 PST
Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 11:36:09 PST
Date: 12 Jan 89 11:34 PST
From: masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 5)
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <890112-113609-12932@Xerox>

Changes from Version 4 are: 

Clarify that foo:a and bar:a cannot both be slots in the same structure.
Clarify that this only affects DEFSTRUCT macro, not STRUCTURE-CLASS.
Extend Problem Description & Rationale.


!
Issue:          DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References:     CLtL p.308 & 86-003 p.4
Category:       CLARIFICATION

Edit history:   Version 1 by Skona Brittain 05/13/88
                Version 2, Masinter, 14-Sep-88
                Version 3, Masinter, 23-Sep-88
                Version 4, Masinter, 31-Oct-88
                Version 5, Masinter, 12-Jan-89

Problem Description:

The case of two slots of a structure having the same name is not 
discussed in CLtL. Is it allowed?  The problem is that the
name of slot accessors and the keyword arguments of the 
constructor function is determined only by the SYMBOL-NAME
of the slot designator; the meaning of slot accessors and
the constructor function is unspecified.

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

It is an error for two slots in a structure type to have the same symbol-name;
that is, the SYMBOL-NAME of the slot names should not be STRING=.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.

The situation of expanding a DEFSTRUCT macro with a duplicate name "should
signal an error." (While not yet formally defined, the intent is that 
the error signalling may occur when compiling a file that contains
duplicate names or when evaluating a DEFSTRUCT form with duplicate names
in an interpreter.)

This proposal only affects the operation of the DEFSTRUCT
macro, and not the STRUCTURE-CLASS or structures defined
with DEFCLASS>

Examples:

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

(defstruct struct package-1:slot package-2:slot) is also an
error. Slot accessors are interned in the current *PACKAGE*
at the time of the evalution of the DEFSTRUCT. 

Rationale:

Since it would be difficult to prescribe reasonable behavior for
DEFSTRUCT, it should be considered an error.

Current Practice:

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

Cost to Implementors:

None.

Cost to Users:

None.

Cost of Non-Adoption:

Possible confusion.

Benefits:

Clarity.

Aethetics:

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

Discussion: 

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

This issue was first circulated to X3J13 June 1988.

This proposal does not address the issue of whether NIL is a legitimate
slot name. There seems to be no current reason why it might be prohibitied.

The compiler committee is proposing to address generally the issue 
of how macro-expansion errors during compile-file might be caught and
turned into compiler warnings.


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

∂12-Jan-89  1505	CL-Cleanup-mailer 	Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 12 Jan 89  15:04:26 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa09068; 12 Jan 89 22:56 GMT
Date: Thu, 12 Jan 89 22:59:13 GMT
Message-Id: <21697.8901122259@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: cl-cleanup@edu.stanford.sail's message of 11 Jan 89 22:30 PST
Cc: masinter.pa@xerox.com

I would prefer to have no sequence functions take arrays than to
divide the sequence functions into two classes in this way.

∂12-Jan-89  1518	CL-Cleanup-mailer 	Re: Issue: TAGBODY-CONTENTS (Version 5)  
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 12 Jan 89  15:17:44 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa09212; 12 Jan 89 23:08 GMT
Date: Thu, 12 Jan 89 23:11:35 GMT
Message-Id: <21725.8901122311@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: TAGBODY-CONTENTS (Version 5)
To: masinter.pa@xerox.com
In-Reply-To: masinter.pa@com.xerox's message of 12 Jan 89 00:44 PST
Cc: cl-cleanup@sail.stanford.edu

> On your ballot, you said:
> 
> "Contents should be valid forms (including self-evaluating) or valid tags.
> Duplicate tags should be an error (as in the proposal)."
> 
> However, the EVAL-OTHER proposal passed at the last meeting makes all
> "other" objections self-evaluating.

Right, I'd forgotten that.  I'd still prefer that the contents be
described as forms rather than data.

∂12-Jan-89  1524	CL-Cleanup-mailer 	Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89  15:24:42 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 14:53:39 PST
Date: 12 Jan 89 14:36 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SETF-MULTIPLE-STORE-VARIABLES (Version 1)
In-reply-to: Pavel.pa's message of Mon, 02 Jan 89 18:20:37 PST
To: Pavel.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.Edu
Message-ID: <890112-145339-1095@Xerox>

I'm bringing hardcopy of the "latest" drafts of issues for discussion at
X3J13. If you want me to bring this one, I'll need it by tonight.

∂12-Jan-89  1536	CL-Cleanup-mailer 	Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME , Version 4
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 12 Jan 89  15:36:32 PST
Posted-Date: Thu, 12 Jan 89 15:36:28 PST
Message-Id: <8901122336.AA23770@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
	id AA23770; Thu, 12 Jan 89 15:36:31 PST
To: cl-cleanup@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME , Version 4
Cc: goldman@vaxa.isi.edu
Date: Thu, 12 Jan 89 15:36:28 PST
Sender: goldman@vaxa.isi.edu

I think this proposal is too weak in its criterion for considering
slot name "conflict" to be an error.  The ONLY effects of slot name choice
over which the programmer has no control are:
1) the determination of the slot accessor function symbol
   (but this is determined not solely by the print name of the symbol; the
    :conc-name and value of *package* also come into play.)

2) the keyword arguments for a keyword constructor.  Maybe the parameters
for a BOA constructor as well, but CLTL is mute about whether the
correspondence between the BOA constructor formal parameters and the
symbols used to designate slot names is by name equality (string=), or
by EQ, in which case the package matters.  In

3) the way the default #S printer prints things.

I prefer to think of slot names as symbols, not strings.  CLtL in fact
says the slot name must be a symbol.  This proposal seems to move toward
saying that all that matters is the symbols symbol-name, in which case why
not allow a string as the slot name in DEFSTRUCT?  I had always assumed
that, with a conc-name of NIL, the accessor for the slot would be the symbol
I used as the slot name; not a symbol in *package* with the same name.  If
I am right, then the fact that two slots have the same symbol-name does not
imply any conflict in the accessor.

I think something should be considered an error only if we are unable or 
unwilling to specify its effects -- not because we consider it bad style.
So, I would be happy to say that "it is an error" to hand the reader
#S<C ... :foo value ...> for a defstruct class C having multiple slots named
FOO.  
I would also be happy with -- in fact I would like it -- a proposal that
said "it is an error" for defstructs of two different classes or two slots
of the same class to yield the same accessor functions (in the case of
two different classes regardless of whether one includes the other).  Notice
that this can occur even if the slot names differ:
(defstruct (fab (:conc-name "FAB")) junk cd)
(defstruct (fa (:conc-name "FA")) bcd more-junk)
 both of these are specified to create an accessor FABCD in *package*.  Should
we just say that whichever one happens last is the definer of FABCD, or call it
a (not necessaily signalled)  error?

Since another cleanup proposal has proposed allowing defstruct constructors
to have &key in their lambda lists, even two slots of the same structure
with the same name (but different pkgs) could be suitably distinguished,
since &key allows you to specify the formal parameter name and the 
"keyword" used in calls differentially.

I wouldn't object to the proposal if the
criterion for conflict were simply symbol equality, rather than name equality, 
although it would still leave unaddressed accidental conflicts like the one 
mentioned above.


Neil

∂12-Jan-89  1745	CL-Cleanup-mailer 	Issue Status    
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89  17:44:33 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JAN 89 17:33:59 PST
Date: 12 Jan 89 17:33 PST
From: masinter.pa@Xerox.COM
Subject: Issue Status
To: cl-cleanup@sail.stanford.edu
Message-ID: <890112-173359-1602@Xerox>

I'm going to have to stop if I'm going to get copies made & ready for
shipping to the meeting. 

We will have to decide on which issues we will present to X3J13 for voting
in which order. I propose the following, in order:

* "block vote" only those for which there is no dissent (all Y) or no
comments on released proposal.
* Separate vote on all "ballot" issues for which no comments were recieved
(even if some N votes.)
* Discussion, possibly amendments, for "old" issues for which there is no
controversy but minor changes are necessary.
* Discussion and possibly voting (if no 2-week rule) on "new" issues we
believe are not controversial.
* Discussion of issues with great controversy or some opinion that "we're
not ready to vote on this yet".

I'm thinking about proposing that we should add an Appendix to the Draft
Standard which lists the pending issues; e.g., for each issue which is not
resolved by the last hour reserved for "cleanup", we should have a simple
majority vote / no discussion about whether the issue should be "dropped."

!
Issue status:   

who mailed the vote:
1 David N Gray (TI)
2 Kim A. Barrett (IIM)
3 David Bartley (TI)
4 Sandra J Loosemore (Utah)
5 David Moon (Symbolics)
6 Dan Pierson (Encore)
7 Chris Perdue (Sun)
8 Aaron Larson (Honeywell)
9 Kathy Chapman (DEC)
10 Gail Zacharias (Apple)
11 Neil Goldman (ISI)
12 Barry Margolin (TM)
13 Jeff Dalton (U Edinburgh)
14 JonL White (Lucid)

In some cases I have changed a vote from Y to "I" (conditional) if the
comments said "Only if...." In a couple of cases I changed an "Abstain" to
"Conditional" where the associated comment indicated that as the intent. I
have frequently paraphrased comments beyond recognition. The "Comments" are
more reminders to me than to you.I didn't mark which ballots were
"official". I think I missed or miscounted some votes, but I don't think it
is crucial.



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: new/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: new/vote?

APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Comments: require APPLYHOOK to accept optional ignored 3rd arg?
		make explicit *APPLYHOOK* value will only get two arguments
Status: New/vote?

ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Vote: 1y2y3y4y5y6y7y8y9y10y11y12y13y14y SPECIFY
Status: block vote

ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Vote: 1y3y4y5y6y7y8y9y10i11y12y13y14y UNIFY-UPGRADING
Comments: 10: if remove UPGRADED-ARRAY-ELEMENT-TYPE and
UPGRADED-COMPLEX-PART-TYPE
          Discussion: Must upgrading be uniform?
Status: separate vote; amendment?

BACKQUOTE-COMMA-ATSIGN-DOT
Synopsis:  `(... ,@x) vs `(... . ,x). Same, or different?
Version 1, 22-Dec-88, DRAFT released
Comments: proposals INTERCHANGABLE and DIVERGENT
	comments not in writeup 
Status: new/vote?

CLOSED-STREAM-OPERATIONS
Version 5, 5-Dec-88, Released 5 Dec 88
Synopsis: What operations are legal on closed streams?
Vote: 1y3y4y5y6y7y8y9y10y11y12y13y14y ALLOW-INQUIRY
Comments: 10: Want to spec value for CLOSE on closed streams.  Why
undefined?
Status: vote separate
α∂
CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Comments: Too many proposals
Status: new/vote?

COERCE-INCOMPLETE
Synopsis: Extend COERCE to handle default coercions? take an optional
FROM-TYPE?
Version 2, 21-Nov-88
Status: Substantial discussion, little convergence
	needs new version

COMPILE-AND-LOAD-VERBOSITY
Synopsis: how much typeout when :VERBOSE given to COMPILE and LOAD
Comment: is there an issue?
Status: not submitted?

COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: new/vote?

CONSTANT-SIDE-EFFECT
Synopsis: It is an error to do destructive operations on constants in code,
defconstant.
Version: not submitted
Status: => CONSTANT-MODIFICATION (compiler committee)

CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Vote: 1n2y3n4y5y6y7y8y9y10y11y12y12y13y14y TRANSITIVE
Comments: "not worth implementation effort"
Status: block vote

DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Vote: 1n2n3n4y5n6y7i8y9n10y11y12y13y14y NO-HOISTING
Vote: 1y2n3y4n5y6i7y8i9y10n11n12n13n14y LIMITED-HOISTING
Comments: NO-HOISTING too incompatible LIMITED-HOISTING ok, but
    unconvinced of need.  All examples easily solved by changing
   some variable names.
 6,8: support LIMITED-HOISTING if NO-HOISTING fails.
    Either is better than nothing.
 7: NO-HOISTING if cases hoisted by 2nd alternatives are treated as
    errors and LIMITED-HOISTING fails
 12: LOCALLY can always be used to hoist a declaration around an
	initial value form
 13: NO brings LET closer to application of LAMBDA-expressions.
    The "en passant" capture in LIMITED is a bit too strange.
Status: vote on LIMITED first, NO second (if LIMITED fails)

DECLARE-FUNCTION-AMBIGUITY
Version 4,  5-Dec-88, Released  5-Dec-88
Vote: 1n3y4y5y6y7y8y9y10y11y12a13a14y DELETE-FTYPE-ABBREVIATION
Comments:
  5: Moon mildly opposed; gratuitously incompatible. Pitman favors 
     benefit of making regular outweighs costs
Status: separate vote

DECLARE-TYPE-FREE
Version 8, 7-Dec-88, Released 9-Dec-88
Vote: 1a3y4y5n6n7y8y9y10n11y13n14n ALLOW
Version 9, 2-Jan-89, Released 6-Jan-89
Vote: 5y6n10y13y14y LEXICAL
Vote: 5n6y10n13n14n ALLOW
Comments: 12: Want more discussion of merits of ALLOW vs LEXICAL
		LEXICAL is consistent with SYMBOL-MACROLET-DECLARE:ALLOW
Version 10, 12-Jan-89
Status: separate voting on Version 10

---

DECLARE-TYPE-USER-DEFINED
Synopsis: allow (declare ((signed-byte 8) x y z)) for all type specifiers?
Status: Not submitted

DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Vote: 1y3y4a5y6y7y8i9y10a11y12y13a14y LIKE-ENCODE
Status: block vote

DEFINITION-DELETE
Synopsis: provide a way to get rid of structures, etc. 
Status: not submitted

DEFMACRO-BODY-LEXICAL-ENVIRONMENT
Synopsis: Allow DEFMACRO at non-top-level to capture environment.
Status: not submitted to cleanup; in compiler committee

DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Vote: 1y3y4y5y6y7i8y9y10y11y12y13y14y ADDITION
Comments:  Spell out "at variance"; define semantics in terms of existing
	package functions. Mail 6-Jan-89
 7: If we allow time for more experimental usage of this before adopting it
 8:  believe that "should signal an error" should be "will signal an error"
Status: separate vote

DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
Synopsis: defstruct accessors are proclaimed inline
Version 2,  7-Jan-89, released 10-Jan-89
Status: New/vote? 

DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 2, 21-Sep-88, Released 6 Oct 88
Vote: 1y2i3y4y5y6y7i8y9y10y11y12y13i14y ALLOW-KEY
Comments: 7, 13: If the proposal is fixed as suggested by Kim Barrett
Version 3, 8-Jan-88, Released 11-Jan-89
Status: new/vote on 2 vs 3?

DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Vote: 1y2y3y4y5y6y7y8y9y10y11n12y13y14y YES
Status: block vote?

DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 2, 7-Jan-89
Status: ready for release??

DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 4, 31-Oct-88, Released 12-Dec-88
Vote: 1y2y3y4y5y6y7y8c9y10i12y13y14y DUPLICATES-ERROR
Version 5, 12-Jan-89
Status: vote separate

DELETE-FILE-NONEXISTENT 
Version 1, 5-Oct-88
Comments: should just signal different errors?
Status: awaiting new version

DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Vote: 1n2a3n4n5y6n7n8a9y10a11y12a13a14n EXPLICITLY-VAGUE
Vote: 1y2y3y4y5i6y7y8y9n10a11n12a13a14n NO
Comments: 5: "Yes" for the NO option iff EXPLICITLY-VAGUE fails.
Status: separate vote

DOTTED-MACRO-FORMS
Vote: 1y2y3y4y5y6y7y8y9y10n11y12y13y14y ALLOW
Version 3, 15-Nov-88, Released 7-Dec-88
Status: block vote

DYNAMIC-EXTENT
Version 3, 11-Jan-89
Status: DRAFT, ready for release?

ELIMINATE-FORCED-CONSING
Synopsis: Add :RECYCLE or :MODIFY keyword arguments to sequence,
	list & string functions where such arguments are useful.
Version 3, 31-Aug-88
Status: Need volunteer to pursue

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

EQUAL-STRUCTURE
Version 5, 1-Oct-88, Released 8 Oct 88
Vote: 1y2i3y4a5i6y7y8y9y10a11y12y14n STATUS-QUO
Version 6, 11-Jan-89, Released 12-Jan-89
Comments: needs amendments
Status: vote separate

ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88
Status: separate vote

EXIT-EXTENT
Summary: What happens with non-local exits out of UNWIND-PROTECT cleanup
clauses?
Version 5, 12-Dec-88, Released 12-Dec-88
Vote: 1a2n3a4n5n6c7n8n9n10n11n12n13n14n MINIMAL
Vote: 1a2i3y4y5n6c7y8y9n10y11y12y13y14n MEDIUM
Comments: MEDIUM more useful in one important case
	Current vague state better than muddled attempt to fix it.
Version 6,  8-Jan-89
Status: ready for release?

EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Vote: 1y2y4y5y6y7y8y9y10y11a12y13y14y P.211
Status: block vote

FILE-LENGTH-PATHNAME 
Comments: Some people didn't seem to think
  this was appropriate. No one seemed very interested in writing it up.
Status: not submitted

FILE-WRITE-DATE-IF-NOT-EXISTS
Synopsis: What does FILE-WRITE-DATE do if no such file?
Version: no proposal
Status:  => non-existant "error signalling" committee

FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Vote: 1n2n3n4i5y6y7n8n9y10i11n12y13y14n TIGHTEN-DEFINITION
Vote: 1y2n3y4y5n6a7n8n9n10y11y12n13n14n TIGHTEN-FIXNUM-TOSS-BIGNUM
Comments: TOSS-FIXNUM-TOSS-BIGNUM
	4, 10: TIGHTEN-DEFINITION if TIGHTEN-FIXNUM-TOSS-BIGNUM is voted down
    I don't think either proposal really addresses the problem adequately
	doesn't do much for anyone & will break some implementations.
    8: BIGNUM not useful, but there are other non useful aspects; changing
requires better justification.
	12: Tossing BIGNUM is a gratuitous incompatibility
	13: frequently fixnum is bigger than address/can index or count.
	    more portable than explicit subrange
	14: We feel that fixnums could be made portably useful only if they were
  required to be large enough to cover both array indices and object
  counts; neither proposal is strong enough about these points
Status: separate vote

FOLLOW-SYNONYM-STREAM
Status: Not Submitted; lost in STREAM-ACCESS

FORMAT-E-EXPONENT-SIGN
Vote: 1y2y3y4a5y6y7y9y10a11a12y13y14y FORCE-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: block vote

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: need volunteer

FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Vote: 1y2y3y4y5y6y7y9y10y11y12y13y14y YES
Comments: remaining questions:
   - Is PRINT-OBJECT used to print things of type FLOAT in any cases
     where ~$, ~E, ~F, or ~G is used?
   - Can users write any methods (including :AROUND, :BEFORE, etc) for
     PRINT-OBJECT on type FLOAT?
 If Yes and Yes, it  matters whether any of those format ops bind
 *PRINT-BASE* in order to achieve the effect prescribed by CLtL of
 always printing floats in base 10. If the answer to either of those
 questions is "No", then it doesn't matter.
Status: separate vote (amend to No and No?)

FORMAT-ROUNDING
Synopsis: specify that ~F rounds up
Version 1, 5-Oct-88
Comments: we don't like the proposal
    recommend  #+IEEE-FLOATING-POINT => round-to-nearest?
Status: withdrawn?

FUNCTION-ARGUMENT-LIST
Synopsis: want way to get argument list
Status: not submitted

FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88
Status: need new version

FUNCTION-COMPOSITION
Synopsis: Add new functions for composing function values
Version 4, 12 Dec 88, Released 12 Dec 88
Vote: 1n2n3n4n5y6a7n8n9n10a11n12i13y14n NEW-FUNCTIONS
Vote: 1n2y3n4y5i6y7i8n9n10i11n12i13i14n COMPLEMENT-AND-ALWAYS
Comments: fix Barry Margolin's complaint about the degenerate case of
COMPOSE
	6, 13: COMPLEMENT-AND-ALWAYS if NEW-FUNCTIONS fails
	7,10: If a name better than "ALWAYS" can be found,
		or if only COMPLEMENT were in the proposal
	Amend ALWAYS => CONSTANTLY?
	8: error in the proposal, the example for find-if specifies AND and
DISJOIN to be equivalent
   12: if one of TEST-NOT-IF-NOT passes
Status: separate vote (w/amendment(s))

FUNCTION-DEFINITION
Version 2, 09-Dec-88, Released 9 Dec 88
Vote: 1y3y4y5y6y7y8a9y10a11n12y13y14n FUNCTION-SOURCE
Comments: The name FUNCTION-SOURCE sounds too much like a source-file
facility
  [Lucid has such a thing].  We might accept the proposal if the name
  were SOURCE-CODE; unfortunately, though this is in Lucid's documentation,
  we are not really happy with that name either.
Status: vote separate

FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released  12-Dec-88
Vote: 1y2y3y4y5y6y7y8y9y10y11y12y13y14y RESTRICTIVE
Comments: "explanation of exactly what changes could be clearer,
    and I am not completely sure I understand it"
Status: block vote

FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Vote: 1y2n3y4a5y6y7y8na9n10n11n12y13y14y USE-ACTUAL-ARGUMENT-TYPE
Status: separate vote

GC-MESSAGES
Synopsis: What about unsolicited GC messages?
Version 2, 14-Nov-88
Status: editorial UNSOLICITED-MESSAGES:NOT-TO-SYSTEM-USER-STREAMS?

GET-MACRO-CHARACTER-DISPATCHING
Synopsis: What does GET-MACRO-CHARACTER return for dispatching macros?
Status: not submitted

GET-MACRO-CHARACTER-READTABLE
Vote: 1y3y4y5y6y7y8y9y10y11y12y12y13y13y14y NIL-STANDARD
Version 2, 8 Dec 88, Released 8 Dec 88
Comments: test case says GET-DISPATCH-MACRO-CHARACTER returns EQ
     functions; not required. Fix test case.
Status: separate vote (with amendment)

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
status: awaiting new version 

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
Vote: 1a3a4n5y6y7y8a9n10n11y12y13n14y ADD-WITH-WRAPPER
Comments: The test-package-iterator example has the values
 from the generator in  the wrong order.
  10: should be functions
  13: proposal premature. Wait until need more firm
	Bothered by use of macrolet; why not INLINE function?
Status: separate vote (with amendment)

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
Vote: 1a2y3y4c5n6a7n8c9?10c11y12y13y14y KEY-TRANSFORM-RESTRICTIONS
Version 1, 11-Nov-88, Released 12 Dec 88
Comments: Is this necessary? No time to understand.
     8: Is SXHASH supposed to work accross different invocations?  proposal
implies 
     implies otherwise?
    10: Would support a simpler proposal that it is an error to 
	destructively modify elements of equal hash tables but ok to do so for eq
	hash tables.
    13: important clarification even though it may
       not lead to extensive changes in practice; disagree with the
       suggestions that it be shortened
Status: separate vote?

HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 8 8
Vote: 1y3y4n5y6y7y8y9y10y11y12y13y14y ADD-EQUALP
Comments: "We would really like to see = hash tables, too."
	SXHASH is not quite suitable for use with
    EQUALP, and so I would like the key transformation function that
    is used with EQUALP to made available to the user.
Status: vote separate? Requires EQUALP clarification to work.

IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: new/vote?

IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Vote: 1y2y3y4n5y6y7i8i9y10y11y12y13y14y SELECT-ONLY
Comments: 7, 8: "Yes" if DEFPACKAGE
	     ?: If we allow time for more experimental use of DEFPACKAGE before
     	  adopting this.
Status: block vote

IN-SYNTAX
Synopsis: like IN-PACKAGE but for readtables
Version 1, 21-Oct-88
Comments: too narrowly focused?
Status: needs new version

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?

LAMBDA-FORM
Vote: 1y3y4n5y6a7n8a9y10y11n12y13y14n NEW-MACRO
Version 4, 22-Nov-88, Released 8-Dec-88
Comments: 10 New special form would be even better.
Status: separate vote

LAMBDA-LIST-DUPLICATES
Status: withdrawn

LCM-NO-ARGUMENTS
Vote: 1y3y4y5y6y7y8y9y10y11y12y13y14y [Returns] 1
Version 1, 17 Oct 88, Released 8 Dec 88
Status: block vote

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

LET-TOP-LEVEL
Synopsis: What's top level?
Status:  => clcompiler

LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: New/vote?

LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Vote: 1y3y4y5i6y7n8y9y10y11y12y13y14n DISALLOW
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: separate vote (with amendment?)

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 1, 2-Jan-89
Status: need new version?

LOAD-TIME-EVAL 
Synopsis: #, semantics not in read macro
Status: => clcompiler

LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Comments: same arguments as REQUIRE-PATHNAME-DEFAULTS?
Status: not 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
Vote: 1y2n3y4n5n6y7n8y9y10n11n12n13n14y IMPLEMENTATION-DEPENDENT
Comments: Decreases portability, incompatible, special-case, has other ways
	rationale incorrect, current practice incorrect
	8: People writing portable code have more subtle problems to worry
       about than the default :USE list anyhow
    12: When using the implementation's extensions, it is better to make
      this obvious by having to specify the implementation-dependent
package
Status: separate vote 

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

MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Vote: 1y2y3y4y5y6y7y8y9y10y11y12y14y EXPLICITLY-VAGUE
Status: block vote

NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Vote: 1a3n4n5y6y7y8an9n10y11y12n13n14n ADD
Comments: OK, but of marginal value.
	The proposal should clarify the treatment of n when it is out of range.
	Any non-negative integer index values should be permitted.
	NIL should result if the index argument is too large.
	12: Naming values using a numeric index is like using arrays
	instead	of DEFSTRUCT.  If there were a way to specify a
	value by a symbolic name I'd go for that
	13: does not complete the set of operations=>not needed for completeness
Status: separate vote

OUTPUT-STREAM-P-EXAMPLE
Synopsis: Clarify (output-stream-p (make-concatenated-stream)) is NIL?
Version 1, 26-Oct-88
Status: already clear; just bug report for one implementation

PACKAGE-CLUTTER
Vote: 1y2y3y4i5y6y7y8y9y10y11y12y13y14y REDUCE
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: stronger on properties; "implimentation"
	Symbols that are special forms can have macros, be FBOUNDP
	I don't see any need to restrict the use of internal symbols in
    the CL package as property indicators
	Stronger: implementation will not use any property names
    which are on user-created packages (except by inheritance.)
	Allow SETF of GET, GETF, and SYMBOL-PLIST?
	Other properties also should be spelled out, as per Moon.
Status: separate vote with amendments?

PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Vote: 1y3y4a5y6y7a8y9n10i11y12y13a14y NEW-FUNCTION
Comments: Minor glitches
	10: Remove the description of "correctable" error to be signalled and
handled.
	This sort of detailed error protocol is not specified for any other
function
	and is not appropriate here
Status: separate vote with amendment

PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: extend package accessors PACKAGE-NAME etc. to take strings too.
Status: need new version

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-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
Vote: 1y3y4i5y6y7n9y10y11y12y13y14y NEW-TOKEN
Version 1 27-Jun-88, Released 7 Oct 88
Comments: may be subsumed
Status:  block vote

PATHNAME-UNSPECIFIC-COMPONENT
Version 1, 29-Dec-88, Released 12-Jan-89
Synopsis: More extensions to :UNSPECIFIC
Status: new/vote?


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
Vote: 1y2y3y4n5y6y7y8y9y10y11y12y13y14y FIRST-READ-CHAR
Comments: "All metastreams must now support PEEK-CHAR directly..."
	conflict with the rationale for issue UNREAD-CHAR-AFTER-PEEK-CHAR,
    which is to legitimize implementing PEEK-CHAR as READ-CHAR/UNREAD-CHAR?
	14: "proposal could be reduced from three pages to three sentences"
Status: separate vote

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
Vote: 1y3y4i5y6y7y8y9y10y11y12y13y14y USER-FUNCTIONS-WORK
Comments: This proposal would be OK if it specified that circularity only
    had to be detected for objects that are contained in slots of the
    structure